A new twist in online payment fraud is showing how cybercriminals are adapting blockchain technology for a purpose it was never designed to serve: hiding malicious infrastructure.
Security researchers at Confiant have uncovered a Magecart campaign that uses Ethereum smart contracts to help deliver card-skimming malware to compromised e-commerce websites. The operation, tracked as HexMage, combines traditional web skimming with EtherHiding, a technique that stores malicious information inside blockchain smart-contract storage.
The result is a particularly resilient attack chain.
Rather than relying entirely on a conventional malicious domain or command-and-control server, the attackers use Ethereum’s Sepolia testnet as a type of on-chain dead drop. A small malicious loader implanted on a compromised online store reads information from a smart contract, retrieves the location of the next-stage payload, and loads a payment-card skimmer directly into the shopper’s browser.
For customers, the danger is straightforward: they may enter their payment details into what appears to be a completely legitimate checkout page, complete their purchase successfully, and never realize their card information has been stolen.
For merchants, the attack creates an even more serious problem. Their legitimate websites become the delivery platform for the theft.
From Fake Updates to Stolen Payment Cards
EtherHiding is not new. The technique has previously been associated primarily with fake browser updates, ClickFix campaigns, information stealers and remote-access malware.
But HexMage demonstrates how the technique is expanding.
Instead of using blockchain infrastructure to direct victims toward malware downloads, the attackers are using it to support a Magecart-style payment skimming operation.
Magecart is the broad term used to describe attacks in which cybercriminals inject malicious JavaScript into an online store. The malicious code waits for a shopper to enter payment information and silently captures sensitive data such as:
- Card numbers
- Expiration dates
- CVV codes
- Cardholder names
- Billing details
- Email addresses
The legitimate transaction can then continue normally.
That is precisely what makes web skimming so dangerous. Neither the merchant nor the customer necessarily sees an obvious failure.
In the HexMage campaign, Confiant found that the blockchain acts as a resilient staging layer between the compromised website and the malicious infrastructure.
The malicious code embedded in the victim’s website does not need to contain a clearly visible attacker-controlled domain. Instead, it can query a smart contract and retrieve the information it needs at runtime.
More Than 40 Websites Across Multiple Countries
According to Confiant’s investigation, researchers observed more than 40 impacted websites across at least 15 countries since approximately April 2026.
The researchers analyzed:
- 25 victim storefronts
- 20 Sepolia smart contracts
- 20 skimmer-hosting domains
The investigation uncovered something particularly significant: the contracts associated with the campaign were linked to a single enumerable owner wallet.
Confiant reported that the wallet had deployed 144 related contracts between March and July 2026, with additional contracts identified by late August.
This gives defenders an important advantage.
While blockchain-based infrastructure can make traditional takedowns more difficult, the public nature of the blockchain can also expose operational patterns. Smart-contract data, ownership information and deployment activity can be examined by defenders without needing access to the attacker’s servers.
In other words, the same technology helping the attackers hide infrastructure can also help researchers map it.
The Attack Begins on a Legitimate Online Store
The victims in this campaign are not necessarily malicious websites.
They are legitimate merchants whose servers or websites have been compromised.
According to the research, the affected stores were overwhelmingly running WooCommerce, although researchers also identified victims using PrestaShop, Magento and standard WordPress installations.
The attackers inject a small JavaScript loader into the compromised website.
To avoid suspicion, the code is disguised to resemble a Google Tag Manager block.
That detail is important.
Google Tag Manager is widely used by legitimate organizations for analytics, advertising and marketing technologies. Security teams may therefore be less likely to immediately question code that appears to be part of normal advertising or analytics infrastructure.
But in this case, the fake Google Tag Manager block does not behave like the real thing.
Instead of loading the legitimate Google Tag Manager script, the malicious code uses obfuscated and Base64-encoded data to retrieve additional attack components.
Ethereum Becomes a Malicious Dead Drop
The next stage of the attack involves the Ethereum ecosystem.
The malicious loader retrieves the ethers.js library from a legitimate public content delivery network and uses it to communicate with an Ethereum RPC endpoint.
The targeted smart contracts are hosted on the Sepolia testnet.
The loader then performs a read-only query against an attacker-controlled contract and retrieves information that ultimately points to the malicious skimmer infrastructure.
In many of the cases analyzed by Confiant, the contract stored a domain name rather than the entire malware payload.
The loader already contained the path to the malicious file.
Once it retrieved the domain from the smart contract, it simply combined the two and loaded the final JavaScript payload.
This approach creates a highly flexible infrastructure model.
A traditional malicious loader may contain a hardcoded command-and-control domain. If defenders block or seize that domain, the attack chain can be disrupted.
With on-chain staging, however, the attackers can potentially update the stored value without modifying every compromised website.
The injected loader remains in place while the next-stage infrastructure changes.
That makes the blockchain component particularly useful as a resilient coordination layer.
A Fake Checkout Form Appears Only When Needed
The final payload is a sophisticated Magecart skimmer designed to target the specific payment method used by the compromised merchant.
Rather than displaying a suspicious payment form immediately, the malware often waits until the shopper selects a card payment option.
Only then does the fake payment interface appear.
The skimmer can replace or overlay the legitimate payment fields with a convincing counterfeit version.
Researchers found that the malware was tailored to a range of payment systems and gateways, including Stripe-related checkout interfaces and regional payment platforms across Europe, Asia and the Middle East.
The malicious code is designed to blend into the existing checkout experience.
In some cases, it uses legitimate payment-brand visuals and familiar interface elements to make the fake form appear authentic.
Once the shopper enters payment information and attempts to complete the purchase, the skimmer collects the data and sends it to infrastructure controlled by the attackers.
The stolen information is typically encoded before transmission.
Then comes another important step.
The malicious code can restore the original checkout form and allow the legitimate transaction to continue.
The customer receives their order confirmation.
The merchant records a successful sale.
Meanwhile, the payment information may already be in the hands of cybercriminals.
Two Victim Groups, One Attack
The HexMage campaign creates two distinct groups of victims.
The Merchant
The first victim is the online business whose website has been compromised.
A payment skimmer operating on a merchant’s checkout page can create serious legal, financial and reputational consequences.
Depending on the organization and jurisdiction, the incident may also raise questions around payment security requirements, including PCI DSS obligations.
A compromised checkout can also destroy customer trust.
For many online retailers, trust is the business model. Customers are unlikely to return to a store if they believe their payment information was exposed there.
The Customer
The second victim is the shopper.
The customer may have done everything correctly.
They may have visited a legitimate website, selected a legitimate product and entered their payment details into what appeared to be the merchant’s normal checkout page.
The problem is that the website itself has become the attack surface.
This is one of the most challenging realities of Magecart attacks: the victim is often interacting with a trusted brand and has very little ability to determine whether malicious JavaScript has been injected into the checkout process.
Designed to Hide From Website Owners
The researchers also found several techniques designed to keep the compromise hidden.
In many samples, the skimmer avoided operating when it detected a logged-in WordPress administrator.
That means a website owner investigating their own checkout while logged into the administration panel might not see the malicious payment form.
The attackers also used obfuscation to make the malicious JavaScript harder to analyze.
Some versions were tied to the hostname of the victim website, meaning the malware would only properly execute in its intended environment.
The campaign also used misleading filenames that could resemble ordinary website assets, cached files or analytics components.
This combination of techniques makes traditional visual inspection unreliable.
A website can look normal.
The source code can contain something that appears to resemble legitimate advertising or analytics technology.
The malicious behavior may only appear when a specific payment option is selected.
And the website administrator may not see the attack at all.
Why the Blockchain Changes the Defensive Equation
Blockchain infrastructure does not make cybercrime invisible.
But it can change the economics of disruption.
A conventional malicious server can potentially be taken down through a hosting provider, registrar or law-enforcement operation.
Data stored inside a public blockchain is different.
There is no traditional hosting company that can simply remove the stored value.
The information can remain available as part of the blockchain infrastructure.
That persistence is one reason attackers are increasingly experimenting with blockchain-based staging techniques.
At the same time, blockchain transparency can provide defenders with new investigative opportunities.
Confiant was able to pivot from smart contracts observed in live traffic to a shared owner wallet and a much larger set of related contracts.
This illustrates an important lesson for security teams: blockchain abuse should not be treated simply as an infrastructure problem.
It should also be treated as a source of threat intelligence.
Public blockchain records can sometimes reveal relationships between infrastructure that would otherwise remain hidden.
The Global Payment-Security Risk
The HexMage campaign should concern any organization operating an e-commerce platform.
The attack is not limited to one industry or one country.
Modern online stores rely heavily on third-party JavaScript, plugins, payment gateways, content management systems and marketing technologies.
Every additional component can increase the attack surface.
For attackers, the value is obvious.
Compromise one merchant website and they may gain access to the payment details of many customers.
For defenders, the challenge is that security cannot stop at the web server.
Organizations must understand what happens inside the customer’s browser.
A server may appear secure while the checkout page loads unexpected JavaScript from an external source.
A traditional security monitoring strategy may miss that behavior entirely.
This is why client-side security monitoring is becoming increasingly important for e-commerce organizations.
Why This Matters to the Middle East and Africa
The campaign has global implications, but the issue is also relevant to organizations across the Middle East and Africa.
Digital commerce continues to expand rapidly across the region. Governments are investing heavily in digital economies, fintech platforms and online services, while businesses are increasingly moving customer interactions and payment processes online.
That growth also creates an attractive target for cybercriminals.
E-commerce businesses across the MEA region frequently rely on:
- WordPress and WooCommerce
- Third-party payment providers
- Marketing and analytics platforms
- Cloud-hosted infrastructure
- External JavaScript libraries
- Open-source plugins and extensions
The HexMage campaign demonstrates how attackers can abuse this complex ecosystem.
For organizations in the region, the lesson is clear: protecting the web server is not enough.
Security teams must monitor the full payment journey, including what scripts execute in the customer’s browser and where those scripts communicate.
For a broader cybersecurity strategy, organizations should also strengthen their relationship with experienced cybersecurity professionals and invest continuously in security awareness, incident readiness and secure application practices through Saintynet Cybersecurity.
10 Recommended Actions for Security Teams
1. Audit every script loaded on checkout pages
Security teams should maintain an inventory of all JavaScript executing on payment and checkout pages.
Any unexpected script should be investigated immediately.
2. Monitor browser-side network connections
Look for unusual connections from checkout pages to blockchain RPC services, unfamiliar APIs or suspicious external domains.
A retail checkout page making Ethereum JSON-RPC calls should immediately raise questions.
3. Review Google Tag Manager implementations
Do not assume that every block labeled as Google Tag Manager is legitimate.
Verify that GTM code actually loads the expected official Google Tag Manager resources.
4. Deploy file-integrity monitoring
Monitor changes to checkout templates, WordPress files, plugins and server-side configuration.
Unexpected code modifications can be an early sign of a compromise.
5. Harden administrator accounts
Use multi-factor authentication, strong password policies and privileged-access controls for website administrators.
Stolen administrator credentials remain a common route into online platforms.
6. Keep CMS platforms and plugins updated
WooCommerce, WordPress, Magento, PrestaShop and their extensions should be patched promptly.
Remove abandoned or unnecessary plugins to reduce the attack surface.
7. Implement a strong Content Security Policy
A carefully configured Content Security Policy can help restrict which external domains are allowed to load scripts and communicate with the checkout page.
8. Monitor the checkout as a real customer would
Test payment flows while logged out and from clean browser sessions.
Attackers may deliberately hide malicious behavior from administrators.
9. Establish client-side threat detection
Traditional server-side security monitoring should be complemented with controls that monitor JavaScript behavior inside the customer’s browser.
Unexpected DOM manipulation, payment-form replacement and suspicious data exfiltration should trigger investigation.
10. Prepare for a payment-data incident before it happens
Organizations should have a documented incident-response plan covering website compromise, payment-card exposure, forensic investigation, customer notification and regulatory obligations.
Regular cybersecurity training and awareness exercises can help ensure technical teams and business leaders understand their responsibilities during a major incident.
The Bigger Picture
HexMage is not simply another Magecart campaign.
It is evidence of an evolving trend in cybercrime.
Attackers are combining established techniques with newer infrastructure models to make malicious operations more resilient and more difficult to detect.
The attack itself remains familiar: compromise a legitimate website, inject malicious JavaScript and steal payment information.
What is changing is the infrastructure supporting the operation.
Blockchain technology gives attackers another layer between the compromised website and the malicious payload.
At the same time, the public and transparent nature of blockchain infrastructure gives threat researchers new opportunities to map campaigns, track related contracts and identify operational patterns.
That tension may define the next stage of EtherHiding.
The technology that makes the infrastructure difficult to remove may also make parts of the attacker’s ecosystem permanently observable.
Conclusion
The HexMage campaign is a warning that web skimming continues to evolve.
By combining Magecart techniques with blockchain-based staging, attackers have created an attack chain that can hide malicious infrastructure behind legitimate websites, public CDNs and Ethereum smart contracts.
The greatest danger is not necessarily a dramatic malware infection or a visible website outage.
It is the quiet nature of the theft.
A customer visits a legitimate online store.
They select a product.
They enter their payment details.
Their purchase succeeds.
And somewhere in the background, their card data may already have been stolen.
For e-commerce organizations, the message is increasingly clear: payment security must extend beyond the server.
The modern checkout page is an active software environment running inside the customer’s browser, and every script, network request and third-party integration has become part of the security perimeter.
The blockchain may be decentralized, but responsibility for protecting customers is not.
For more cybersecurity threat intelligence, security guidance and global industry coverage, follow CyberCory and strengthen your organization’s cyber resilience with Saintynet Cybersecurity.
