NEXT-GEN MAGECART: TWO WEBSOCKETS, FAKE CHECKOUT, SILENT SKIMMER VIA GTM
Attackers found a clever way to steal payment and personal data by hiding inside a trusted Google Tag Manager container. To shoppers, the checkout page looks normal, but the injected script is built to operate in two modes: on some sites it can fully impersonate the checkout with a fake payment form, while on others it quietly skims what users type into the real fields.
In both cases, the browser session is doing the attacker’s work in real time, while most traditional defenses—including WAFs, server-side logging, and static or integrity-based controls like CSP and SRI—remain focused on server traffic or fixed script inventories and never see the activity happening in the shopper’s browser.
Attack details
The attack starts with a tiny, obfuscated script delivered through a compromised Google Tag Manager HTML tag that fires only on checkout pages. This loader opens a persistent WebSocket to an attacker-controlled server, pulls down a larger second-stage skimmer, runs it in the browser, and then removes its own markup to reduce visible traces.
The main payload is engineered with two paths that are both present but become active under different conditions. First, it looks for a checkout button and surrounding page structure that match the attacker’s template. When it finds what it expects, it can hijack that button’s behavior, disable the real action, and display a polished, full-screen fake checkout view that copies the real page. Shoppers are prompted to enter card details, contact data, and other high-value fields, creating a “double entry” moment that feels like a simple retry, while a background skimmer continues to run as a secondary channel.
If the page structure does not match the attacker’s template and the fake overlay cannot be cleanly injected, the attack falls back to a stealthy mode where the DOM skimmer quietly becomes the primary theft method. In that path, the script continually scans input boxes, dropdowns, and text areas across the page and same-origin iframes, tracks changes, stores values locally, and then exfiltrates stolen PCI and PII data through a second WebSocket dedicated to data transfer. The merchant’s DOM effectively decides which mode dominates on a given site, allowing the same campaign to support both visible fake checkouts and silent skimming in a single framework.
It is rare to see one operation built for this kind of dual behavior and dual WebSocket use; although Source Defense has previously documented a similar blended pattern using a 1×1 SVG and WebSockets in an earlier Magecart case, this new attack is far more advanced because it automatically scans each page and dynamically chooses between a fake form and silent skimming based on technical fit rather than a static, manually chosen pattern.
How Source Defense protects you
Source Defense is built to monitor and control how scripts behave in the browser, including those loaded through Google Tag Manager, rather than simply trusting them because they come from a familiar platform.
In a case like this, our technology can detect when JavaScript on a payment page starts accessing PCI data such as card numbers and CVV, as well as PII such as names, addresses, emails, and phone numbers. At the same time, Source Defense tracks attempts to transfer data out of the browser, including over WebSocket connections, and correlates those target domains with attacker domains identified by our research team and added to internal blacklists.
That means this attack would trigger protections around accessing PCI and PII, helping stop theft at the point of entry, in addition to sending data to a blacklisted domain. By protecting and monitoring third-party and tag-delivered scripts in real time, Source Defense helps customers reduce client-side risk, support PCI DSS 4.0.1 requirements for script monitoring, and keep checkout pages safe without slowing down development.
How you’d be alerted
When this type of campaign runs, Source Defense raises clear, behavior-based alerts regardless of whether you are in monitor or protect mode.
In this scenario, customers would see alerts for scripts:
- Accessing data – PCI and PII – as the skimmer reads payment and personal information.
- Transferring data (WebSocket) – as stolen details are pushed over live browser connections.
- Sending data to blacklisted domain – once added to our blacklist.
These alerts appear in the bell notification center and are summarized on the main dashboard, with more detail visible in the “Found in blacklists” and “Script behaviors” widgets to pinpoint the specific script, tag, or GTM container involved.
Based on configuration, the same alerts can also be sent by email or webhook into SIEM, SOAR, or ticketing tools, so security, fraud, and compliance teams can investigate quickly, document impact, and align with PCI DSS 4.0.1 monitoring and response processes.
Summary
This campaign shows how modern eSkimming has moved far beyond simple form grabbers. Attackers now run modular, browser-resident frameworks that mix fake checkouts, silent skimming, and dual WebSocket channels, often delivered through trusted tools like Google Tag Manager. Traditional defenses like CSP, SRI, WAFs, and server-side logging focus on server traffic and static code, not on what third-party or tag-delivered scripts actually do in the shopper’s browser. That leaves a major blind spot on the client side, further proving how a dedicated client-side security is essential for protecting checkout flows, revenue, brand, and compliance.
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.