From Firebase to GTM: How Magecart Moved Deeper Into Google Infrastructure

FROM FIREBASE TO GTM: HOW MAGECART MOVED DEEPER INTO GOOGLE INFRASTRUCTURE

A persistent Magecart actor has steadily moved its client-side attack chain deeper into trusted Google infrastructure, making the campaign harder to spot with tools that look mainly for suspicious domains. Earlier versions used Google Firebase Storage to host skimming scripts and Google Cloud Run endpoints to receive stolen data. The newer version is more mature: it uses Google Tag Manager (GTM), a tool many businesses rely on to manage website tags, to trigger the attack, and Google Firestore, a cloud database service, to deliver and collect the payload. The actor was already hiding inside reputable Google infrastructure in 2024. The newer version refines that approach by shifting from Google-hosted skimming assets and Cloud Run endpoints to GTM-driven orchestration and Firestore-backed payload delivery, activity that can appear closer to normal website operations on a production checkout page.

Attack details

The technical trail shows the same blending strategy becoming more integrated over time. In the 2024 phase, the actor used Firebase Storage paths with Google-themed file names such as google_ad_collect.js and google_ad_verification.js, then sent harvested data to Cloud Run infrastructure. The newer version keeps the same camouflage strategy, but distributes the attack across GTM and Firestore: GTM handles checkout targeting and exfiltration, while Firestore delivers the skimming payload and receives the stolen data.

A malicious or compromised GTM container first checks whether the shopper is on a checkout page, with some variants avoiding cart pages to reduce exposure during testing. When the right page is detected, the container fetches an obfuscated payload from a Firestore REST API endpoint and executes it in the browser using new Function().

That Firestore-delivered script then continuously scans the page for Magento 2 checkout indicators and payment form frameworks. In advanced variants, it hides the legitimate card form and renders a convincing fake payment interface using Shadow DOM. The script captures card number, expiration date, CVV, ZIP code, billing details, names, and email addresses, encrypts the data with an XOR cipher, and stages the ciphertext in localStorage under deceptive CAPTCHA-like keys. A persistent GTM loop then checks browser storage across the site and posts the staged packet back to the attacker’s Firestore collection. The naming patterns, Google-themed project names, reused collection structures, and matching cryptographic tags suggest a deliberate progression by the same actor rather than an isolated infrastructure change.

How Source Defense protects you

Source Defense extends security to the client side, where this attack takes place, by monitoring and controlling script behavior in the browser before payment data can be stolen. In this case, the attack is especially risky because a site-authorized GTM container orchestrates payload delivery and exfiltration through trusted Google services, making malicious behavior harder to distinguish from normal checkout-page activity. Source Defense helps protect checkout pages by identifying unauthorized script behavior, controlling what scripts can access, and detecting risky actions such as dynamic code execution, payment-data access, browser storage abuse, and unauthorized data transfer. This behavior-based approach is critical when the domain itself may look trusted but the script’s activity violates its intended purpose. 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, detect unauthorized changes, and protect data at the point of input, before it reaches the web server.

How Source Defense alerts you

Alerts apply in both block and monitor modes and give security teams visibility into the browser behaviors that matter most for this campaign. Relevant alerts include:

• Accessing PCI data
• Accessing PII data
• Accessing data
• Transferring data
• Executing risky actions, including new Function() and setInterval
• Using browser storage

These alerts appear in the bell notification center, dashboard summaries and in the “Script behaviors” widget. Depending on configuration, alerts can also be sent by email and/or webhook so browser-side threats can be routed into existing response workflows.

Key takeaways

WAFs and server-side logs may miss the theft because the skimmer runs in the shopper’s browser before data reaches the server. CSP and SRI can help in some cases, but broad allowlisting of Google services, dynamic tag management, and frequently changing scripts can limit the effectiveness of static controls. Source Defense gives organizations the visibility, behavior-based protection, and alerting needed to detect and block unauthorized script behavior in real time, helping reduce eSkimming risk, protect customers, and support payment-page compliance even when the domains involved look trusted and the activity appears to blend into normal Google-powered website operations.