Magecart Turns Trusted GTM Into a Launchpad for Smarter Skimmers
Payment-skimming attacks are continuing to abuse Google Tag Manager (GTM) as a trusted path into checkout pages, while changing what happens after the malicious code reaches the browser. Recent findings included chained GTM containers, payload delivery through Google Firestore, long-running campaigns rotating through new containers, WebRTC-based communication, and a skimmer that replaced a legitimate Stripe Payment Element with a counterfeit form. The risk is not that GTM itself was necessarily compromised, but that attackers can use GTM-delivered code as a flexible browser-side launch point. A familiar Google-hosted request may therefore be only the first step in an attack that later loads attacker-controlled JavaScript, manipulates a payment interface, accesses sensitive data, or transfers it through less conventional channels. The findings show that GTM abuse remains an active and adaptable Magecart delivery technique.
Attack details
GTM remains a major entry vector for Magecart code into the browser. These five recent findings were not part of a single campaign, but each used GTM as the trusted launch point for a different delivery, persistence, communication, or skimming technique:
- A second GTM hop concealed Firestore-hosted payloads. Two separate chains—GTM-MHGCKQ3W loading GTM-KX9MJVVF, and GTM-MPQMJQJH loading GTM-N6RJG8Q9—ultimately retrieved Magecart payloads from Google Firestore. This evolved an earlier campaign architecture by adding another GTM layer between the website and Firestore. The first container could act as a bootstrapper while the second handled later attack logic, making investigations focused only on the GTM ID embedded in the page more likely to miss the complete execution chain.
- A two-year-old campaign reached its ninth GTM container. GTM-PMT5JBWP loaded code from static5-jquery[.]com, becoming the ninth container observed delivering an attack active for at least two years. The skimmer did not need to be redesigned each time its infrastructure was exposed; operators could replace individual containers and continue the campaign. The finding demonstrates why a malicious GTM ID can be a useful but short-lived indicator.
- A recurring attack resurfaced through a second container. GTM-THXQ6LRM contacted onlinechatusbot[.]com, marking the second GTM container associated with this attack. The container changed while the malicious domain remained. Its chat-related name also gave the request a plausible appearance in website logs, particularly when the chain began with a familiar Google-hosted request.
- GTM launched a WebRTC-based attack path. GTM-KKJKMS2 initiated activity involving 172.86.119[.]16 and WebRTC, bringing two recurring Magecart techniques into the same chain. GTM provided browser-side execution and the ability to activate under selected conditions, while WebRTC offered a communication path outside commonly monitored HTTP-based channels such as fetch, XMLHttpRequest, image requests, or sendBeacon. The finding does not establish a connection to earlier WebRTC campaigns, but it shows that the technique is becoming part of the broader Magecart toolkit.
- A GTM-delivered skimmer replaced Stripe at checkout. GTM-NSKCVNFJ loaded an obfuscated skimmer from sallexyhub[.]com. The malware replaced the legitimate Stripe Payment Element with a counterfeit form, captured the payment information entered by the shopper, and sent it to fontuse[.]com. Stripe itself was not compromised. The attacker manipulated the surrounding merchant page so the shopper entered data into a fake interface before Stripe could receive it.
The containers, infrastructure, and skimming methods differed, but the opportunity remained the same: GTM gave each attack a trusted, remotely configurable route into the shopper’s browser. Blocking individual container IDs may stop a known instance; detecting and controlling what GTM-delivered code does at runtime is what addresses the continuing threat.
How Source Defense protects you
Source Defense operates inside the browser, where it can identify malicious script behavior and enforce protection policies in real time such as preventing unauthorized scripts from accessing payment, personal, credential data or all data.
This behavior-based protection does not depend on a permanent GTM ID, payload URL, or communication method. As attackers rotate containers, add GTM layers, move payloads through services such as Firestore, or adopt channels such as WebRTC, Source Defense can continue controlling what scripts are permitted to do—blocking malicious actions at the point of execution.
How Source Defense alerts you
Source Defense surfaces alerts tied to the third-party script behaviors observed across these different attack paths. Depending on the specific implementation, relevant alerts may include
- Loaded from a blacklisted domain
- Sending data to a blacklisted domain
- Accessing PCI data, Accessing PII data
- Accessing credential data
- Accessing data
- Sending data to other
- Executing risky actions: eval, setTimeout, new Function, setInterval
- Using browser storage.
These alerts can help distinguish a trusted delivery service from the actions of the code it ultimately introduces. Relevant findings appear in the bell notification center and dashboard summaries, with blacklist-related activity shown under “Found in blacklists” and behavioral findings under “Script behaviors.” Notifications can also be routed through email and webhook options so security teams can respond without relying on periodic manual review.
Key takeaways
Trusted infrastructure does not guarantee trusted behavior. These attacks used GTM as a consistent launch point while changing nearly everything that followed: containers were chained and rotated, payloads moved through Firestore, communication shifted to WebRTC, and a legitimate Stripe Payment Element was replaced with a counterfeit form.
CSP and SRI remain valuable browser-enforced controls, but they are not designed to continuously evaluate and control changing script behavior at runtime. WAFs, firewalls, backend logs, and other server-side defenses may never see an attack that intercepts and transfers data entirely within the shopper’s browser.
Blocking known GTM IDs, domains, or payload URLs can disrupt individual campaigns, but it cannot provide durable protection against infrastructure that keeps changing. Defending against these attacks requires continuous visibility into what scripts actually do, combined with real-time browser controls that can stop unauthorized data access before customer information is stolen.
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.