SMARTER, EVOLVING SKIMMERS TURN ‘SAFE’ MAGENTO CHECKOUTS & GTM INTO A BLIND SPOT
Attackers are now using increasingly sophisticated, layered techniques to skim Magento checkout pages while staying almost invisible, combining Google Tag Manager abuse, multiple levels of obfuscation, and a hijacked legitimate printing-company domain so that both the code and the data flow look like everyday activity.
Instead of touching form fields directly, the skimmer quietly harvests the already-populated and validated payment and billing details from the page, only waking up in the checkout flow and blending into normal tag activity. The result is an attack that evades fingerprints and traditional monitoring, making it extremely difficult for standard tools to spot even as pristine card data and full customer profiles are exfiltrated straight from the shopper’s browser.
Attack details
The attack starts with an injected loader that mimics a standard Google Tag Manager snippet. It hides a malicious container identifier inside an encoded value, which is decoded only at runtime and only when the URL indicates the shopper is at checkout.
See below legitimate code example verses the malicious loader below, where the malicous container ID is obfuscated (
‘P2lkPUdUTS01N1RXTUZNSg’ + ‘==’).
That container then delivers a heavily obfuscated Magecart skimmer built from large encoded string bundles, custom decryption logic, and anti-debugging tricks that make both static and dynamic analysis very difficult.
Once running, the skimmer focuses specifically on Magento’s checkout, parsing the platform’s Knockout.js-based templates and comment bindings to read billing names, addresses, email, and phone numbers directly from the DOM, not from form inputs. By pulling data from the rendered page after Magento has already validated it, the skimmer bypasses input field monitoring, virtual keyboard protections, and other form-centric controls.
It then pulls card data from the payment step and applies strict checks before doing anything with it. The script uses the standard Luhn algorithm to make sure the card number is mathematically valid, filtering out test card numbers, typos, random sequences, and other invalid values. It only moves forward when several conditions are all true at once: the card number has the right length (15 or 16 digits), the CVV/CID length matches the card type, the expiry date is complete, and the number passes Luhn validation. This “quality control” approach reduces load on the exfiltration endpoint, minimizes suspicious failed transactions, produces cleaner data for fraud, and makes anomaly-based detection much harder.
Once all of those checks are satisfied, the skimmer assembles a comprehensive data package with the full card details and the victim’s billing and contact information. That package is then encrypted in two stages before leaving the browser: first it is run through XOR encryption with a dynamic key that is itself stored encrypted in the obfuscated string array, base64-encoded, decoded at runtime, and applied in a rotating pattern; then the result is base64-encoded for safe transmission over HTTP.
Finally, the script quietly sends this encrypted payload via a background browser request to a compromised but otherwise legitimate printing business domain over HTTPS. After identifying this behavior, the Source Defense research team reached out to the business behind this legitimate domain to notify them that their infrastructure was being abused for eSkimming activity.
The gate domain is particularly dangerous because it looks like a normal business site, likely running a receiving script on compromised infrastructure, does not raise obvious red flags, aligns geographically with the targeted Magento stores, and can be brushed off as a misconfigured analytics-style endpoint if noticed.
Combined with a triggering mechanism that continually watches for Magento checkout buttons and only fires when the page is a checkout URL, Magento-specific bindings are present, payment fields are populated, the billing address is complete, and the user actually clicks to pay, this results in an attack that extracts and encrypts a full victim profile and exfiltrates it only under ideal conditions—making the entire flow both stealthy and highly efficient.
How Source Defense protects you
Source Defense protects against this type of attack by monitoring and controlling what scripts are allowed to do in the browser on sensitive pages like the Magento checkout, regardless of whether they arrive as first-party code, from Google Tag Manager, or from another third-party service.
Instead of trying to recognize every new obfuscation trick, Source Defense continuously evaluates script behavior, including when a script attempts to access PCI data in payment forms, read personal information from the page, use first-party cookies or browser storage to enrich profiles, or transfer that information off the site.
When a GTM-delivered script on a Magento checkout suddenly starts harvesting full billing records from rendered page structures and pairing them with card data, Source Defense policies can prevent that unauthorized data access and block the transfer to the attacker’s exfiltration path, even if the destination domain appears legitimate or has historically been trusted.
This behavior-based control helps organizations close the client-side blind spot left by traditional defenses, while still allowing marketing and analytics teams to use GTM and other tools safely as part of a compliant, PCI-ready ecommerce stack.
How Source Defense alerts you
If this skimmer were present on a Magento site, Source Defense would generate clear alerts tied to the risky behaviors rather than the specific code style, including:
- “Accessing PCI data” when cardholder information is inspected
- “Accessing PII data” when billing and contact details are read from the page
- “Transferring data” when that combined payload is prepared to leave the browser
- “Sending data to blacklisted domain” due to Source Defense’s research and timelly identification of cimpromised domains.
- “Executing risky actions” when it observes aggressive, repeated execution patterns on the checkout page that suggest a script is persistently monitoring user actions in the background.
These alerts appear in the bell notification center and dashboard summaries, and the implicated scripts show in the “Script behaviors” and “Found in blacklists” widgets when relevant, making it easy for teams to pinpoint the exact context.
Alerts can also be forwarded via email and webhook into SIEM, SOAR, or ticketing systems, and they fire in both block and monitor modes for scripts from any source, ensuring that security teams have immediate visibility into this kind of silent DOM-based skimming activity.
Key takeaways
This campaign shows how modern Magecart threats have moved beyond simple form listeners and keyloggers. Attackers now target the page itself, abusing platform-specific features like Magento’s Knockout.js templates and trusted ecosystems like Google Tag Manager, while hiding exfiltration behind real business domains that easily bypass traditional allowlists, CSP rules, SRI checks, WAFs, and server-side logging alone.
Client-side security focused on script behavior – what runs in the shopper’s browser, what data it touches, and where that data is sent – is now essential to reliably stop these attacks before they leave the page. This attack reinforces the value of having continuous, automated control over scripts on payment pages, not just periodic tag audits.
Magento and GTM are powerful but highly attractive targets, which makes a concrete, browser-level way to detect and stop even highly obfuscated, DOM-focused skimmers that otherwise look like business as usual absolutely imperative.
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.