DOUBLE-ENTRY MAGECART STEALS CREDIT CARDS LIKE A PICKPOCKET, USING FAKE “VERIFICATION CODE” TO FOOL VICTIMS
Resilient Magecart campaign mimics payment pages in 17 languages, rotates attacker hosts, and perhaps most deviously, shows a fake verification code screen after stealing card details to keep victims feeling secure.
Attack overview
Attackers injected a malicious loader to a first-party JavaScript and split the malicious logic across multiple stages to evade detection and increase resilience. At runtime the loader randomly chooses one of several attacker hosts; this domain list is embedded as base64. If one of these domains doesn’t return the expected malicious code successfully, another one from the list is used until a tiny script is returned, as expected. This script invokes eval on a further base64-encoded payload, which in turn loads the active attack. The attack replaces the site’s payment form with a fake card checkout, exfiltrates card data to an attacker endpoint ( thisisourplace[.]site), and then displays a convincing 2-factor authentication “verification code” to the shopper — a social engineering ruse that buys time and reduces suspicion.
The combination of host rotation, multi-language support, and theatrical UX makes this campaign highly scalable and hard to detect with static blacklists or cursory code review.
Attack details
Below is a breakdown of the various strategies used in this attack to evade detection:
1. Rotating loader hosts (base64 list / randomness)
- The initial loader contains a base64-encoded array of four attacker domains and picks one at random, as seen in the image below. On failure it falls back to others. This makes takedowns and single-domain blacklists ineffective.
The involved domains are:
- https://cryptosuck[.]online
- https://freestylershop[.]space
- https://megapetshop[.]space
- https://megaappshop[.]store
In the past, this malicious loader used the following domains that are no longer active:
- https://thisisourparadise[.]site
- https://thisisourparadise[.]store
- https://thisisourparadise[.]space
- https://thisisourpeace[.]site
- https://thisisourpeace[.]store
- https://thisisourpeace[.]space
2. Two-step fetch & eval chain
The chosen host returns a short script that performs an eval() of another base64 payload. That payload then loads the attacker script from the same host. Multi-stage fetch together with the eval adds obfuscation and flexibility.
3. Global campaign design
The attack includes 17 different language strings and UI assets, indicating the operator intends to target many countries and locales, not a single region.
4. Payment-UI substitution
The injected code removes the site’s normal list of payment methods and inserts only a fake “credit card” option under the attacker’s control. This forces the victim to submit card data through the malicious flow. See below images which display the original form that includes the option of PayPal and the fake one underneath with only one option – the malicious one which captures the credit card details.
5. Fake payment form
When the user selects the (fake) payment option, a bogus payment form is displayed, mimicking the legitimate UI.
6. Skimming & exfiltration
The attack captures card number, expiry, CVC, etc., performs client-side base64 encoding, then POSTs to an attacker endpoint, thisisourplace[.]site/cdn/verify.
7. Fake verification UI = social engineering, not additional exfil
After submission the site shows a 5-digit “verification code” modal (five single-char inputs), as seen below. Our analysis finds no code path that transmits those digits to the attacker — the inputs only perform client-side validation. We infer that this modal’s purpose is to:
a) Make the transaction look legitimate.
b) Delay the user from checking bank/card activity immediately.
c) Give the attacker time to complete any page-unload exfiltration.
How Source Defense would detect & block this
- Behavioral detection: flag runtime sequences that match eval() → DOM script insertion → external fetch → form serialization/exfil.
- Runtime isolation: execute untrusted third-party scripts in an isolated context that prevents them from reading/writing PCI fields or issuing network exfiltration.
- Dynamic blacklist & auto-policy: when the loader and the attack script is observed, automatically block the loader and any response domains (including rotated hosts) even if they are new.
How Source Defense would alert on this
- Accessing PCI data
- Script load from a blacklisted domain
- Script sends data to a blacklisted domain
- Risky code execution
These alerts are surfaced in the dashboard, notification center and via configured integrations (SIEM, email, etc.).
Key takeaways
- First-party bundles are not automatically safe. A server-side compromise of your assets lets attackers fully control the client UX.
- UX deception is part of modern Magecart playbooks. Fake verification UIs are deliberate social engineering to delay detection and reduce suspicion.
- Host rotation & multi-language support = global, resilient campaigns. Single-domain takedowns and static blacklists are not enough.
- Defend at runtime. Stopping this class of attack requires runtime, behavior-based client protections (script isolation, activity correlation, auto-policy) plus hardened build/deploy controls.
In short, organizations need real-time, behavior-based client-side protection to detect and block these evolving, resilient Magecart campaigns before credit cards are stolen
PCI DSS 4.0 makes client-side security a priority.
Source Defense delivers a solution for 6.4.3 and 11.6.1 without adding a burden to your security teams.