Credit card theft campaign abuses Stripe to host stolen payment info

Source: Bleeping Computer

Overview

A new Magecart campaign is abusing Stripe’s API infrastructure to host a credit‑card‑stealing payload and to store the data exfiltrated from checkout pages. The malicious activity relies on Google Tag Manager (GTM) and Stripe domains—googletagmanager.com and api.stripe.com—which are trusted by default by many online stores.

Researchers at the e‑commerce security firm Sansec discovered that the malicious code is loaded from a GTM container and executes on every page that includes the container.

“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.” – Sansec

How the Attack Works

GTM as a Delivery Mechanism

GTM allows website owners to add and manage scripts for analytics, ads, and tracking without modifying the site’s source code. The attackers embed malicious code in a legitimate‑looking GTM container. When a shopper reaches a checkout page, the container:

1. Queues Stripe’s API for a specific customer record (e.g., cus_TfFjAAZQNOYENR).
2. Reads JavaScript code stored in the record’s metadata fields.
3. Reassembles the code and executes it via new Function().

Card Skimmer

The skimmer targets Magento/Adobe Commerce checkout pages and captures:

• Credit‑card number, expiration date, CVV
• Cardholder name
• Billing address, email address, phone number

Card skimmer code – Source: Sansec

Local Storage and Obfuscation

The stolen data is concatenated into a single string, obfuscated with an XOR operation, and stored locally (in localStorage) instead of being exfiltrated immediately.

Exfiltration Routine

A separate routine runs right after page load and then every minute:

1. Splits the stored data blob in half.
2. Creates a new Stripe customer object.
3. Stores the stolen data in the new customer’s metadata fields.

Each stolen payment card becomes a fake customer record in the attacker’s Stripe account, effectively using Stripe as a storage backend. After copying the data, the local file is wiped to remove traces and prevent duplicate uploads.

Data exfiltration routine – Source: Sansec

Variant Using Google Firestore

Sansec also identified a variant that replaces Stripe with Google Firestore:

• The payload is retrieved from a Firestore document named tracking/captcha in a project called braintree-payment-app.
• Stolen data is stored in a different localStorage key (_d_data_customer_).

The document and project names are chosen to blend in with legitimate payment and bot‑protection traffic.

Timeline

The Stripe customer record containing the skimmer was created on December 24 2025, indicating that the campaign may have been active since at least that date.

Mitigation Recommendations

• Use one‑time virtual cards with set limits for online purchases.
• Implement strict Content Security Policy (CSP) rules that restrict script sources to known, trusted domains.
• Regularly audit GTM containers for unauthorized or suspicious tags.
• Monitor Stripe API usage for anomalous customer creation or metadata updates.
• Employ security tools that can detect abnormal new Function() executions and unusual localStorage activity.

---