WHEN GTM ISN’T GTM: MAGECART’S TWO-STAGE TRICK
A recent Magecart campaign cleverly hid in plain sight by disguising itself as part of a trusted tool — the Google Tag Manager (GTM). What makes this attack unique is how it breaks up the malicious activity into two parts to avoid detection.
First, the attacker injects a small, encoded payload into the page at runtime via a first-party script. Since this action does not execute an additional script, it doesn’t arouse suspicion. Then, a second piece of code designed to look like a legitimate GTM loader – finds that hidden code in the page and activates the real attack by calling a malicious service to fetch the actual data-skimming script. This service rotates different skimmer domains over time, making it hard to track, detect, or block using traditional blacklist-based methods.
Overview — why this is dangerous
- The loader looks like a normal GTM embed, so cursory inspections and simple whitelist checks are unlikely to flag it.
- The compromise is first-party (hosted in the site’s own assets), so it bypasses many protections that only block third-party scripts.
- Skimmers URLs are fetched dynamically as a response from the attacker-controlled service, allowing domain rotation and rapid evasion.
- Many sites can be hit simultaneously via the same upstream compromise.
Technical details of the 2-step attack
Step 1 — Encoded payload inserted at runtime
An encoded snippet is embedded in the page by a first‐party script and appended to the DOM as a script element at runtime. That snippet contains a request template that will be used in the next step to call the malicious domain.
Step 2 — GTM mimicry and payload retrieval
A second script intentionally mimics the GTM loader pattern (dataLayer, gtm.start, createElement(‘script’), etc.). Instead of loading the real googletagmanager[.]com/gtm.js resource, it reads the encoded payload injected in step 1 (see window.gtmKey[…] etc. below) from the DOM, decodes it, and calls the malicious service.
Skimmer returned on demand
The malicious service responds with the skimmer URL. The loader then dynamically inserts that skimmer into the page. Because the skimmer URL is returned by the service, the attacker can change skimmer hosting domains frequently.
Domain rotation & multi-stage obfuscation
Multiple domains and indirect lookups are used (so blacklist entries rapidly age out). Payloads and responses are encoded to hinder static analysis.
Observed malicious domains (examples):
- evasel[.]online
- dewoper[.]click
- birtec[.]quest
- gbleylot[.]quest
- cholmob[.]store
- Additional short-lived domains rotated over time
Indicators of risky behavior to watch for:
- A GTM-style snippet where the created script’s src does not match the legitimate GTM URL, but instead references a local/encoded DOM value or a non-GTM domain page.
- atob()/eval() or runtime DOM insertion of decoded strings that subsequently produce network calls.
- Script sequences that: inject a small loader, then immediately fetch another remote resource and insert it into the page.
- Network requests to unusual domains that have never been seen before in your network traffic.
How Source Defense would detect & block this
Behavioral detection flag scripts that:
- Execution of eval(), indicating risky behavior
- Attempt to access sensitive values, including payment data
- Transfers data to new domains
- Load script from blacklisted domains
- Sends data to blacklisted domains
These alerts are surfaced in the dashboard, notification center and via configured integrations (SIEM, email, etc.).
- Protection via dynamic blacklist + auto-policy – when our system observes a new suspicious script loaded, we push an automatic block policy for the loader and any response domains – even if they rotate.
Source Defense provides runtime protection against this type of advanced client-side threat—even when malicious code is injected into a first-party bundle. Our solution monitors and blocks unauthorized behaviors such as:
- Unexpected DOM manipulation or cloning of HTML elements
- Scripts attempting to serialize and extract PCI or other sensitive data.
- Data transfers to suspicious or previously unseen domains, even when hidden behind trusted CDNs.
Through script isolation and behavior analysis, Source Defense would prevent this attack from capturing or transmitting sensitive data.
Key takeaways
- Mimicking trusted patterns works. Attackers intentionally copy legitimate loaders (GTM) to blend into expected client-side behavior.
- Two-stage loaders + on-demand skimmers = rotatable infrastructure. Because the skimmer is fetched as a response, the attacker can swap domains quickly and bypass static blacklists.
- First-party hosting is the new preferred vector. When attackers can modify a first-party bundle, traditional third-party blocking and CSP allowlisting fail.
- Defenses must be runtime and behavior-based. Preventing this class of attack requires real-time client-side monitoring, script isolation, and the ability to automatically quarantine suspicious scripts — not only after-the-fact blacklisting.
To summarize: Only behavior-based, real-time protection can stay ahead of these evolving attack techniques — without it, your organization remains exposed.
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.