A new **Magecart** campaign is actively exploiting the very services e-commerce sites rely on for payment processing and analytics: **Stripe** and **Google Tag Manager (GTM)**. This allows attackers to seamlessly integrate their credit card-skimming operations into legitimate web traffic, making detection significantly harder. ### The Deceptive Strategy Researchers at e-commerce security company **Sansec** uncovered this novel malware family, noting its reliance on implicitly trusted domains: `googletagmanager.com` and `api.stripe.com`. Online stores typically whitelist these domains for normal operations, inadvertently creating a blind spot for malicious activity. **Sansec** explains, "Both the payload and the stolen cards move through `api.stripe.com`. Stores allow that domain by default, so the skimmer slips past Content Security Policy rules and network filters that would otherwise flag traffic to an unknown skimmer domain." **GTM** is a widely used system that allows website owners to manage scripts for analytics, ads, and tracking without directly modifying source code. **Stripe** is a prevalent payment processing platform for online transactions. ### How the Skimmer Operates The malicious code is embedded within legitimate-looking **GTM** containers. When a shopper navigates to a checkout page, the skimmer activates, queuing **Stripe**'s API to fetch a specific customer record (e.g., `cus_TfFjAAZQNOYENR`). From the metadata fields of this record, the malware reads and reassembles JavaScript code, which it then executes using `new Function()`. This card skimmer specifically targets **Magento/Adobe Commerce** checkout pages. It attempts to capture a comprehensive range of payment and personal data, including credit card numbers, expiration dates, CVV codes, customer names, billing and email addresses, and phone numbers.  ### Covert Data Exfiltration Rather than immediate exfiltration, the stolen data is first concatenated into a single string, obfuscated using an XOR operation, and stored locally. A separate routine handles data retrieval, executing after each page load and then every minute thereafter. This routine splits the obfuscated data blob, creates a new **Stripe** customer object, and stores the stolen information within its metadata fields. Essentially, every compromised payment card becomes a fake customer record in the attacker's **Stripe** account, transforming **Stripe** itself into a storage backend for illicit data. Once the data is successfully copied to the attacker's **Stripe** account, the local file is wiped. This crucial step eliminates traces of the attack and prevents duplicate uploads, making forensic analysis more challenging.  ### The Google Firestore Variant **Sansec** also uncovered a variant of this campaign that utilizes **Google Firestore**, a cloud database service, instead of **Stripe** for data storage and retrieval. In this version, the payload is retrieved from a Firestore document named `tracking/captcha` within a project called `braintree-payment-app`. The stolen data is then stored in a different `localStorage` key (`_d_data_customer_`). The use of such innocuous-sounding names for documents and projects helps the malware further blend in with legitimate payment and bot-protection traffic. ### Timeline and Protection The **Stripe** customer record containing the skimmer payload was reportedly created on December 24, 2025, suggesting that this sophisticated operation may have been active for some time. For users, a primary defense against such risks is the use of one-time virtual cards with pre-set spending limits, which can significantly mitigate the impact of compromised payment details.