NEW MAGECART ATTACK USES BLOCKCHAIN TO HIDE SKIMMER INFRASTRUCTURE
A new Magecart campaign shows how dangerous client-side attacks become when attackers no longer need a visible malicious domain in the first piece of injected code. Instead of pointing directly to a skimmer server that defenders can quickly flag and remove, this attack uses Ethereum, a public blockchain network best known for cryptocurrency and smart contracts, as a hidden routing layer. For shoppers, the risk is straightforward: payment details, billing information, email addresses, phone numbers, and device data can be stolen directly from the browser during checkout. Our analysis found more than 15 Ethereum smart contracts connected to 100+ compromised e-commerce websites worldwide, showing this is a coordinated campaign rather than an isolated infection. For businesses, the unusual twist is that the attack hides behind decentralized infrastructure, making traditional static scans and server-side controls much less likely to see the threat before customer data is exposed.
Attack details
The attack begins with a small, heavily obfuscated script injected into compromised e-commerce sites, often hidden inside legitimate-looking containers such as a spoofed Google Tag Manager container. That first-stage script does not immediately call a known malicious skimmer domain. Instead, it sends JSON-RPC requests to public Ethereum Sepolia testnet nodes and queries attacker-controlled smart contracts. Those contracts return encrypted data that the browser decrypts locally, revealing the current command-and-control domain. Because data written to the blockchain cannot simply be removed by a hosting provider, registrar, security team, or even the original attacker, the domain reference becomes public and persistent. In our analysis, we found more than 15 Ethereum smart contracts supporting this campaign across 100+ compromised e-commerce websites worldwide. That gives the attackers a durable hiding place for the skimmer’s destination: the first-stage script can retrieve the domain from Ethereum without hardcoding it into the compromised website. Once the active domain is resolved, the browser downloads a second-stage payload, commonly named polyfill.module.js, from the attacker infrastructure. That payload behaves like a commercial-grade digital skimmer, monitoring checkout forms, cloning payment elements when protected payment flows are present, classifying card types in real time, and collecting personal and payment data. The stolen data is then encoded and sent out through a browser network request to attacker-controlled infrastructure, giving the threat actors a complete fraud-ready identity and payment profile.
How Source Defense protects you
Source Defense extends security to the client side, where this attack actually runs: inside the shopper’s browser, at the point of input, before the stolen data ever reaches the web server. By continuously monitoring and controlling script behavior on payment pages, Source Defense helps detect and block unauthorized scripts before data exfiltration. In this attack chain, that means protecting sensitive checkout fields from unauthorized access, identifying suspicious third-party activity triggered from the page, and preventing scripts from transferring PCI, PII, or credential data to unapproved destinations. Source Defense also supports PCI DSS 4.0.1 requirements 6.4.3 and 11.6.1 by helping organizations maintain visibility into payment page scripts, monitor changes, and enforce behavior-based controls that are difficult to achieve with static methods alone.
How Source Defense alerts you.
For this type of attack, Source Defense surfaces the behaviors that matter most during a Magecart infection. Alerts appear in the bell notification center, dashboard summaries, the “Found in blacklists” widget when relevant, and the “Script behaviors” widget when relevant. They can also be sent by email and/or webhook, depending on configuration. Relevant alert types include:
- Loaded from a blacklisted domain
- Sending data to a blacklisted domain
- Accessing PII data
- Accessing PCI data
- Accessing credential data
- Accessing data
- Transferring data
- Executing risky actions
Key takeaways
This campaign is a clear evolution of a pattern security teams have already seen: attackers abusing safe-looking external calls and trusted-looking infrastructure to stage malicious scripts. The difference is that the routing layer has now moved to Ethereum smart contracts, and our analysis found more than 15 contracts tied to 100+ compromised e-commerce websites worldwide. That scale makes the skimmer’s active destination harder to spot in static scans and harder to disrupt through domain takedowns alone. The difference is that the routing layer has now moved to Ethereum smart contracts, making the skimmer’s active destination harder to spot in static scans and harder to disrupt through domain takedowns alone. Once written to the blockchain, the domain reference is exposed to anyone who knows where to look, but it cannot be deleted, which gives the attacker a persistent way to hide the destination outside the website’s source code. CSP, SRI, WAFs, and server-side logging can all play useful roles, but they may miss threats that are assembled dynamically in the browser, especially when the first visible script does not contain the final skimmer domain. Source Defense gives security and compliance teams the client-side visibility and protection needed to see what scripts actually do in each browsing session, control access to sensitive data, and stop unauthorized data transfers before they become customer-impacting fraud.
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.