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.
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
How Source Defense would alert on this
These alerts are surfaced in the dashboard, notification center and via configured integrations (SIEM, email, etc.). Key takeaways
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. |
