THE FIVE-YEAR GHOST SKIMMER ON A MAJOR ECOMMERCE PLATFORM
For nearly five years, a coordinated Magecart-style credit card skimmer quietly sat on multiple sites on one of the top ecommerce platforms in the market, waiting for shoppers to check out and expecting payment providers to stay the same.
Attackers injected obfuscated JavaScript into several merchants in mid-2021, aiming to hijack legacy Stripe, Square, and Braintree payment forms and siphon off card data to attacker-controlled domains.
Over time, those payment integrations were upgraded or replaced, and the specific hooks the malware depended on simply disappeared, leaving the skimmer “alive” in the page but no longer able to see or steal anything.
The real story is not that the attack died on its own, but that invasive, payment-page malware was left in production code for years without being noticed. This is exactly the kind of long-lived, client-side exposure that traditional, server-focused tools miss.
Attack details
The injected script followed a familiar Magecart pattern: it used array-rotation obfuscation to disguise its logic, loaded a known jQuery library inside the malicious block for easy DOM manipulation, and then tried to hook into payment form elements from legacy Stripe.js v2, Square Payment Form v1, and Braintree hosted fields across affected sites.
We know this activity dates back to 2021 because historical snapshots from the Wayback Machine (Archive.org) clearly show the malicious block present in the page source during that period.
Once it found the expected card-number and CVV fields, it would hide or replace legitimate interface elements, inject lookalike fields, and capture primary account numbers, expiration dates, and security codes as shoppers typed.
To avoid reliance on a single command-and-control endpoint, the skimmer implemented a simple domain generation algorithm (DGA), building unique exfiltration domains under a “.top” extension using a seed string plus a counter stored in browser localStorage, and rotating through them as each infection “succeeded.”
The same storage was also used to track infection status so the script did not repeatedly trigger on the same browser.
Ultimately, the campaign failed not because anyone removed the malware, but because Payment Service Providers (PSP) SDKs’ evolved: Stripe and Square retired the specific field IDs the script was looking for, one site migrated from Braintree to Stripe, and new payment SDKs used container-style integrations that never exposed the legacy IDs the skimmer depended on, leaving its DOM queries to return nothing and its logic effectively dormant.
How Source Defense protects you
This skimmer lives inside the site’s own code, and therefore, continuous visibility into what that first-party JavaScript is doing in real shoppers’ browsers is of utmost importance.
Source Defense monitors the behavior of scripts running on the website and raises clear, actionable alerts whenever first-party code starts acting like a skimmer – trying to read card data, use the browser as long-term storage, or send information to suspicious destinations such as rotating “.top” domains.
Even when the malicious script hides behind obfuscation or blends in with legitimate PSP integrations, these behaviors stand out and are surfaced so security and ecommerce teams can quickly investigate, remove the injected code, and verify that the checkout page is safe.
In this scenario, the following behaviors would be highlighted:
- Accessing PCI data – attempts by the injected script to read card number, expiry, or CVV fields in the checkout flow.
- Transferring data – efforts to send captured payment details out of the browser session.
- Sending data to a blacklisted domain – exfiltration to attacker-controlled, dynamically generated “.top” domains.
- Using browser storage – suspicious use of localStorage keys (such as counters and infection flags) to track victims and rotate exfiltration endpoints.
Key takeaways
This investigation is a reminder that a Magecart skimmer does not have to be “successful” to be dangerous; the bigger problem is that invasive, browser-side code can live on payment pages for years without anyone knowing, and only become harmless by accident when PSPs change their SDKs.
Traditional controls like WAFs, CSP, SRI, and server-side logging focus on traffic and code at the edge or on the server, not on what JavaScript actually does inside a shopper’s browser, which leaves a blind spot exactly where eSkimming and formjacking happen.
Client-side security platforms such as Source Defense close that gap by continuously monitoring script behavior at the point of data entry, detecting and alerting on suspicious access to payment data or attempts to move it off the page, and giving organizations the visibility and evidence they need to quickly respond, clean up long-lived skimmers, and support PCI DSS 4.0.1 compliance.
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.