Blockchain C2 and Fileless Execution Make Magecart Harder to Disrupt

A compromised checkout page can now take instructions from the blockchain, allowing Magecart operators to change malicious infrastructure without touching the infected website again. In this campaign, attackers used a Polygon smart contract to dynamically resolve the domain hosting the next-stage skimmer, making the operation more resilient when individual domains are discovered or blocked. They combined that decentralized command-and-control method with administrator evasion, delayed execution, Blob-based JavaScript delivery, payment card validation, and image-based data exfiltration. The result is a skimming operation designed to stay quiet until a shopper reaches checkout, collect high-value payment data, and move it out of the browser in traffic that can resemble an ordinary image request.

Attack details

The attack begins with a heavily obfuscated inline JavaScript snippet injected into the compromised ecommerce page. Its first objective is avoiding detection. The code checks the DOM for the WordPress administrator interface and immediately stops if an administrator appears to be logged in, reducing the chance that site owners will notice suspicious behavior while managing the store. It then removes its own script element from the DOM and uses a MutationObserver to wait until the checkout payment element is rendered.

Only after the payment interface appears does the dropper begin resolving the next stage of the attack. Instead of embedding a fixed malicious domain, it queries public Web3 RPC services, including infrastructure such as Alchemy, Infura, and Ankr, to interact with a smart contract on the Polygon network. An eth_call retrieves an encoded value that the script converts from hexadecimal and decodes with an XOR key. The resulting domains, woocompay.com and wpguarding.com, point to the infrastructure used to deliver the Stage-2 skimmer.

This design gives the attackers a useful resilience mechanism. If one malicious domain is identified or blocked, they can update the value returned by the smart contract rather than modifying every compromised website individually. Infected stores can then resolve the new destination the next time the code runs.

The dropper fetches the Stage-2 JavaScript as raw text, converts it into a JavaScript Blob, creates a local blob: URL, and executes it in the browser. The technique avoids a conventional external script insertion and can make enforcement more difficult in environments where Blob execution is permitted. The findings provided do not establish a universal Content Security Policy bypass such as nonce reuse or an overly broad allowlist, so the technique is better understood as CSP-sensitive evasion rather than an automatic bypass of a correctly configured policy.

Once active, the skimmer monitors the dynamically rendered payment interface and attaches collection logic to credit card fields. It also validates captured card numbers before exfiltration, using Bank Identification Number information to identify card brand and the Luhn algorithm to reject invalid values. The harvested payload includes PCI data such as card number, CVV, and expiry date, along with billing information that may also contain PII.

For exfiltration, the skimmer avoids fetch and XMLHttpRequest. It XOR-encrypts the stolen payload using the current timestamp as a key, Base64-encodes the result, and places the data into query parameters on a URL that resembles a normal image asset. A hidden image element then causes the browser to request a resource such as an icon.gif from the attacker-controlled domain.

This image-based technique is effective because cross-origin image loads are commonly permitted by browsers and are not governed by CORS in the same way as many scripted data requests. In network activity, the transfer can resemble a routine request for a web asset with a timestamp-like query parameter rather than an obvious payment-data exfiltration event.

How Source Defense protects you

Source Defense extends security into the browser, where the skimmer is collecting and transferring payment data. Browser-side runtime visibility and control make it possible to evaluate what scripts actually do after they execute, including access to sensitive fields, unauthorized data transfers, risky execution patterns, and suspicious activity associated with externally loaded code.

That behavioral perspective is particularly relevant here because several stages are designed to defeat static assumptions. The Stage-2 destination is resolved dynamically through blockchain infrastructure, the malicious JavaScript is executed from a Blob rather than through a conventional external script tag, and exfiltration is disguised as an image load. Source Defense protects the point where these behaviors affect the shopper, helping secure payment data before it leaves the browser.

How Source Defense alerts you

Source Defense can surface browser-side behaviors associated with this attack, including:

• Loaded from a blacklisted domain
• Sending data to a blacklisted domain
• Accessing PCI data
• Accessing PII data

Relevant activity can be reviewed through the bell notification center and dashboard summaries. Blacklist-related findings can appear under “Found in blacklists,” while observed runtime activity can be reviewed under “Script behaviors.” Notifications can also be delivered through configured email and webhook options, helping security teams respond when suspicious browser activity is detected.

Key takeaways

This campaign pushes Magecart resilience beyond simply rotating malicious domains. By using a public blockchain to distribute the current skimmer location, attackers can redirect compromised stores to new infrastructure without reinjecting code into each site. Blob-based execution, delayed activation, card validation, and image-based exfiltration make the attack even harder to identify through conventional indicators.

Controls such as CSP and SRI would not, by themselves, stop the full attack chain described here. CSP is browser-enforced, but its effectiveness depends on the exact policy, and Blob execution or broadly permitted destinations can leave room for malicious behavior. SRI is designed to verify the integrity of known external resources, but it does not address malicious inline code, dynamically retrieved script content, or behavior that changes at runtime. WAFs, firewalls, and server-side logging operate outside the browser, so they can miss the point where JavaScript reads payment fields and sends stolen data through an image request.

That is the core lesson from this attack: protecting the checkout page requires visibility into what code is actually doing in the shopper’s browser, not just where it came from or whether it matched a predefined file hash. Browser-side runtime monitoring and control can identify sensitive-data access, unexpected transfers, and suspicious script behavior even when attackers change domains, delivery methods, and exfiltration techniques.