GTM: FROM ESKIMMING HIDING PLACE TO CONTROL CENTER
Attackers have discovered a way to turn trusted Google Tag Manager (GTM) containers into long-lived delivery systems for Magecart skimmers, quietly riding on top of Google’s infrastructure while everything else around them changes.
Instead of burning through one malicious domain after another, they now keep reusing the same GTM IDs and simply rotate delivery domains, script names, and container chains.
Because GTM is almost always trusted by CSP policies, WAFs, and security products, these attacks slip past traditional controls, persist for months, and continue to harvest payment and personal data from unsuspecting users even after blacklists and takedowns appear to “clean up” the incident.
Attack details
In this campaign family, the GTM container itself becomes the anchor for the attack. Once an attacker injects or compromises a GTM container, the website continues to load it directly from the trusted googletagmanager.com domain, while the container in turn pulls in malicious scripts from attacker-controlled infrastructure.
Between 2023 and 2025, we have observed more than 100 distinct GTM IDs used in Magecart activity, and the latest behavior is especially worrying: the same GTM IDs (for example, TVR8FN5D and PWJCCK9B) are reused across different victim websites, while the associated delivery domains (such as fastlistcss[.]icu, analyzerai[.]icu, manuchat[.]icu, chelyad[.]icu, and others) and script resources are rotated to evade domain-based detection.
In a previous edition of our research intelligence newsletter, “Trending: Attacks via nested GTM scripts,” we documented a simpler nesting pattern where a single two-stage GTM chain (NSTTR9L → KX36TXD) was used to stepwise deliver a skimmer into checkout flows. What we now see is that same chain evolving into a more resilient, parallel structure: the original NSTTR9L → KX36TXD path has split into two independent branches (KX36TXD → WL9BCSS and NSTTR9L → W4KZD63) that both converge on the same skimmer payload (for example, N5VLRZQ → titansl[.]icu).
This shift from a linear chain to a branching “control graph” lets attackers mix and match stages, silently retire or swap a noisy branch, or rotate domains without ever touching the original GTM ID embedded on the site – while the final payload still hooks into payment and other sensitive forms in the browser to capture card data and personal information and send it off-site.
How Source Defense protects you
Source Defense is built specifically to control this kind of client-side behavior, even when it originates from a highly trusted domain like Google Tag Manager.
By extending protection into the browser, Source Defense treats GTM containers and their downstream scripts as untrusted JavaScript that must be governed by policy, not by brand reputation.
The platform inventories and governs all third-party scripts on payment and data-entry pages, including those loaded dynamically through single or nested GTM containers, and applies policies to restrict what they can see and do in the session.
When a compromised container or its child scripts attempt to access payment fields (PCI data), personal information, credentials, cookies, or browser storage, or when they try to transfer that data to suspicious or blacklisted domains, Source Defense can block that behavior in real time before data ever leaves the browser.
This behavior-based protection is domain-agnostic, so rotating delivery domains, script names, and evolving container chains do not remove coverage, and it supports PCI DSS 4.0.1 controls around continuous monitoring and change detection for payment page scripts.
How Source Defense alerts you
Source Defense will surface this GTM-based activity as clear, actionable alerts tied to what scripts are doing, not just where they come from, in addition to the proactive protection policies applied.
The alerts include:
- Loaded from blacklisted domain
- Sending to blaclistd domainAccessing PCI data
- Accessing PII data
- Executing risky actions
- Transferring data
- Using 1st party cookies
- Using browser storage
These appear in the bell notification center and dashboard summaries, and the “Script behaviors” and “Found in blacklists” widgets make it easy to pinpoint which GTM containers and downstream scripts are involved, even when multiple nested or parallel containers participate in the attack.
Alerts can also be sent via email and/or webhook into SIEM, SOAR, or ticketing systems, so security teams and partners can rapidly validate the threat, correlate it with other indicators, and decide whether to move from monitor to block mode without relying on fragile domain reputation alone.
Key takeaways
Persistent reuse of Google Tag Manager IDs, combined with rotating domains and modular, parallelized container chains, shows how quickly Magecart operators adapt to static, domain-centric defenses and the implicit trust many organizations place in popular tag managers.
Traditional tools like WAFs, CSP, SRI, and server-side logging focus on network edges or server code and often never see the dynamic JavaScript behavior running in each user’s browser session, which is exactly where these GTM-based skimmers live and evolve.
Client-side security that monitors and controls runtime script behavior is now essential to closing this gap: it helps you understand which GTM IDs are active on your site, how they relate to each other, and whether they are trying to access sensitive data.
For organizations handling online payments, this is not only a security imperative but also a key part of meeting PCI DSS 4.0.1 requirements around script inventory, authorization, integrity, and change detection.
Source Defense gives a practical way to manage that risk at scale, protect revenue and customer trust, and keep attackers from turning “trusted” GTM IDs into permanent backdoors on high-value pages.
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.