HexMage: the card skimmer dressed up as Google Tag Manager

• The loader goes into the store's own page code. It is wrapped in the usual Google Tag Manager comments and starts like a real snippet, with an ID in the GTM- format. Everything else is base64-encoded.
• It never loads Google Tag Manager. The ID is not a container. It points to the attacker's contract, and no request to Google's tag manager is ever made.
• It loads a crypto library from a public CDN. The loader pulls ethers.js, a legitimate open source library, from a public JavaScript CDN.
• It asks the blockchain where to go. Through a public node on Sepolia, an Ethereum test network, it reads one text value from a contract. The value is the hostname that serves the skimmer. Since May 2026 that value is encrypted, so reading the contract alone no longer reveals it.
• It downloads the skimmer from that host. The file name looks like an ordinary minified script.
• It waits for the card option. When the shopper chooses to pay by card, the skimmer shows its own card form in place of the real one, with the usual card-brand icons so it looks right.
• It takes the details and steps aside. Card number, expiry, CVV, name and email are base64-encoded and sent to the attacker. The real form comes back and the order goes through, so the shopper has no reason to suspect anything.

The skimmer also checks whether a logged-in WordPress admin is viewing the page, and if so does nothing. A store owner who tests their own checkout while logged in sees a clean page.

A typical skimmer has its server address written into its code. Once someone finds it, the domain is blocked or taken down and the skimmer goes quiet. Here the address lives in the contract. When a host is blocked, the attacker writes a new value to the contract or points to another contract, and every infected store picks up the new host on the next page load, without the attacker touching the stores again.

Confiant traced the contracts it saw to a single wallet, which deployed 144 contracts between 28 March and 21 July 2026. It also found a simpler version on two stores that skips the blockchain and carries the skimmer's address in the encoded block itself. Detection that looks only for the blockchain lookup misses that version.

Each control below either trusts what the loader pretends to be, or blocks something the attacker can replace.

See tag manager security for the risks of real tag manager containers, and skimmers in your own JavaScript for skimmers that hide in a site's own files.

The disguise is good, but what the code does on checkout is unusual. Four signals stand out:

• A GTM snippet with no GTM request. Real Google Tag Manager always fetches its container script, gtm.js, from Google or from your own tagging server. A block that sets up GTM and never fetches gtm.js is not GTM.
• A crypto library on checkout. ethers.js on a shop that does not take crypto has no business being there.
• Calls to a blockchain node from the browser. JSON-RPC requests from a checkout page to a public Ethereum node are rare on an ordinary store.
• Card data going somewhere new. Checkout pages send data to a small, stable set of places: your payment provider, your own servers and a few known services. A new host receiving form data is the clearest signal of all.

6.4.3 asks for an inventory of every script on the payment page with a business justification, and a way to confirm each one is authorised and has not been tampered with. The fake GTM block, ethers.js and the downloaded skimmer are all scripts executing in the shopper's browser, so none of them could be justified. 11.6.1 asks for a mechanism that alerts on unauthorised changes to the payment page's script contents and security-impacting HTTP headers as the browser receives them, at least weekly. A loader added to the page is exactly that kind of change.

• Search your page templates and theme files for Google Tag Manager blocks, and check each container ID against the containers you actually use
• Flag any GTM snippet that never fetches gtm.js, and any ethers.js or Web3 library on a store that does not take crypto
• Test checkout logged out, in a private window, and choose each payment option, card included
• Watch where your checkout sends data, and alert on new destinations
• Restrict connect-src and form-action in your CSP to the destinations you expect, and remove 'unsafe-inline' where you can
• Patch WordPress, WooCommerce and plugins, and rotate admin passwords: someone had write access to add the loader to your page code

Script Monitoring records every script that runs on your payment pages in real customer sessions, so the skimmer cannot hide behind the admin check: real shoppers are not logged in. The ethers.js library shows up as a new script on checkout, and every host the page talks to, including the blockchain node, the skimmer's server and the attacker's collector, appears as a new network destination. You can block a script at runtime by URL, host, domain or vendor on every plan. On Pro, AI script analysis reads new code on the page and is built to flag card-stealing code as a payment skimmer, and guardrails can stop your own inline code from reading card fields. The same record is your evidence for PCI DSS 6.4.3 & 11.6.1. Read more on Magecart protection and AI script analysis.

Where it does not help. Our GTM containers allowlist would not fire here, because no real container loads. We see what the loader does in the browser, not how it got into your site: finding and closing that hole is work on your server. And blocking the current delivery host only lasts until the attacker rewrites the contract, which is why watching for new code and new destinations matters more than any single block.

The technical details, dates and counts are from Confiant's report "Skimming on the Blockchain: A Magecart Campaign That Uses EtherHiding, Found by Malvertising Scanning" (28 August 2026), with counts as of 25 August 2026. Later reports of a higher number of affected stores could not be confirmed independently, so this post uses Confiant's figure. No affected store is named. Requirement descriptions are paraphrased from PCI DSS v4.0.1, published by the PCI Security Standards Council. Written on 13 November 2026 and will be updated if new research is published.