A novel Magecart campaign that weaponizes legitimate cloud services to evade detection: attackers are storing a JavaScript skimmer inside Stripe customer metadata and delivering it to victim checkouts via Google Tag Manager.
The combination makes Stripe both the command server for arbitrary code and the durable exfiltration sink for stolen card data, using domains (googletagmanager.com and api.stripe.com) that e-commerce sites routinely trust and therefore rarely block.
The attack chain is split into three concise stages. First, a legitimate-looking Google Tag Manager container (examples include GTM-P6KZMF63) is planted as a custom tag on victim sites.
That container contains a small loader that, on pages whose URL includes “checkout,” fetches a specific Stripe customer record from the attacker’s Stripe account, concatenates metadata fields that hold the skimmer in chunks, and executes the assembled payload using new Function().
Because the skimmer is staged in Stripe metadata, the attacker can update the malicious code at any time without re-injecting or touching the GTM tag on each victim site.
Second, the executed skimmer attaches to the checkout flow (Sansec observed selectors tuned for Magento and Adobe Commerce markup).
It waits for a checkout button click, extracts card number, expiry, CVV and a wide set of billing and order fields, XOR-encodes the concatenated result with a fixed key, appends a marker, and writes the blob to localStorage under a fixed key.
Magecart Abuses Stripe C2
Sansec found a Magecart family that runs its skimmer straight out of Stripe. The skimmer itself never performs network exfiltration, which reduces its footprint and helps it fly under many runtime monitors.
Third, exfiltration is handled by the loader running in the GTM container. One second after page load and then every 60 seconds it reads the localStorage blob, splits it, and POSTs the pieces as metadata fields in a new Stripe customer created in the attacker’s account.
The attacker’s script includes a hardcoded Stripe secret key (prefixed sk_test_), a telltale sign of compromise because secret keys must never appear in client-side code.
Each stolen card becomes a “customer” entry visible to the attacker via the Stripe API, providing a persistent, searchable data store behind a domain most defenses allow.
Sansec’s sample artifacts show the attacker reusing Stripe sample data (an email [email protected] and invoice prefix WLUFUAQS), and the malicious customer record was created on December 24, 2025 evidence the campaign has been active since late 2025.
A variant of the loader uses Google Firestore instead of Stripe, reading payloads and writing stolen data to project documents under paths chosen to resemble legitimate bot-protection traffic.
Both variants exploit trust in mainstream cloud endpoints to slip past Content Security Policy rules and network filters that only flag unknown skimmer domains.
This technique has serious operational implications: CSP and allowlists that include api.stripe.com and googletagmanager.com will not block these flows, and scanning for outbound requests to cloud APIs will not by itself reveal malicious intent where the request is authorized and well-formed.
Practical mitigations include treating any client-side presence of strings starting with sk_test_ or sk_live_ as an immediate compromise indicator, auditing GTM containers and third-party tags, and scanning stores with specialized skimmer detection tools.
Sansec specifically recommends deploying Sansec Shield to block exploitation attempts and running eComscan to detect injected skimmers, backdoors, and unauthorized changes.
Operators should rotate credentials, remove unexpected GTM containers and tags, and audit all front-end code for direct api.stripe.com or firestore.googleapis.com usage.
Because the attacker’s infrastructure relies on legitimate cloud APIs, defenders must couple behavioral and integrity checks with allowlist hygiene: block or closely monitor unexpected API keys, restrict GTM tag editing to trusted personnel, and validate any external script provenance before deployment.
Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.
