Credit card theft campaign abuses Stripe to host stolen payment info

Credit Card Theft Campaign Exploits Stripe and GTM Infrastructure

OverviewA sophisticated Magecart-style operation has been uncovered that leverages trusted cloud and tag-management channels to steal credit card data. The attackers embed their malicious payload inside legitimate-looking Google Tag Manager (GTM) containers that are loaded on checkout pages. Once loaded, the code communicates with Stripe’s API endpoints (api.stripe.com) to process and conceal stolen payment details. In a variant of the attack, Google Firestore is used as a storage backend instead of Stripe. The campaign relies on widely trusted domains to bypass common security controls, making detection more challenging for both merchants and security tooling.

Attack Surface and Delivery Mechanism

• Entry point: The malicious script is delivered through a GTM container that appears legitimate to websites and security controls.
• Activation: The skimmer activates specifically on checkout pages when a user attempts to complete a purchase.
• Targeted platform: The campaign has been observed targeting Magento and Adobe Commerce storefronts during the checkout sequence.
• Execution environment: The payload is loaded from within the GTM container and executes on the buyer’s page load.

The Role of GTM and Stripe

• GTM as delivery channel: GTM is used to inject and run the malicious code without requiring changes to the site’s core source code.
• Stripe as a storage channel: The campaign routes stolen data through Stripe’s API endpoints, effectively turning Stripe into a hidden data repository.
• Trust assumptions exploited: api.stripe.com and googletagmanager.com are domains that are commonly allowed by default in many e-commerce deployments, which the attackers exploit to slip past standard Content Security Policy checks and network filters.

How the Skimmer Works

• Payload loading: The malicious code is embedded in a normal-looking GTM container and loads on pages that include the container, queuing Stripe’s API for a specific customer record (cus_TfFjAAZQNOYENR in one observed instance).
• Code reconstruction: The script reads its main JavaScript from metadata fields, reassembles it, and then executes it via a dynamic function construction method.
• Data collected: The skimmer captures sensitive fields from the checkout process, including:
• Credit card number
• Card expiration date
• CVV
• Customer name
• Billing address
• Email address
• Phone number
• Data packaging: Collected data is concatenated into a single string and obfuscated with an XOR operation to hinder quick reading or interpretation.

Data Storage and Exfiltration

• Local storage of data: Rather than exfiltrating data immediately, the payload stores the obfuscated blob locally on the victim’s device.
• Exfiltration trigger: A separate routine runs after the page load and continues to run every minute, extracting and transferring the data by:
• Splitting the local blob in half
• Creating a new Stripe customer object
• Storing the stolen details in metadata fields attached to that customer object
• Resulting artifacts: Each stolen card is effectively rendered as a fake Stripe customer record, using Stripe as a covert storage backend for the exfiltrated data.
• Cleanup: After the data is copied, the local storage or temporary files are wiped to reduce traces and hinder re-upload attempts.

Firestore Variant: A Cloud-Based Storage Alternative

• Alternate backend: In another observed variant, the attackers use Google Firestore to store and retrieve payload and data.
• Payload source: The skimmer retrieves its payload from a Firestore document named tracking/captcha within a project named braintree-payment-app.
• Data storage location: Stolen information is saved under a different localStorage key, labeled ddatacustomer, rather than using Stripe metadata.
• Blending with legitimate traffic: The naming and use of Firestore resources are chosen to resemble ordinary payment- and bot-protection related traffic, increasing the likelihood of remaining undetected.

Timeline and Emergence

• Initial Stripe involvement: The observed Stripe-based storage setup involved a Stripe customer record created on December 24, 2025.
• Operational window: The pattern suggests the campaign has been active since at least December 2025, with ongoing activity into 2026.
• Firestore variant timeline: Firestore-based deployments appear as an alternate deployment path within the same campaign family, indicating multiple parallel tactics.

Indicators and Artifacts to Look For

• GTM container anomalies: Unusual or unknown GTM containers loaded on checkout pages without a clear business purpose.
• Traffic to Stripe endpoints: Unexpected or undocumented interactions with api.stripe.com that do not align with normal payment processing flows.
• Obfuscated data artifacts: Locally stored data blobs that show XOR-like encoding or irregular concatenation patterns before any exfiltration attempt.
• Fake Stripe customer records: New customer entries in Stripe that correspond to skimmer activity rather than legitimate purchases, often created around the same time as the observed payload activity.
• Firestore document naming: Firestore usage with documents or projects that blend with payment- and bot-protection traffic (e.g., tracking/captcha in a braintree-payment-app project).

Impact and Implications

• Merchant risk: E-commerce sites relying on GTM for analytics, marketing tags, or checkout customization may be inadvertently hosting skimmer payloads, enabling data theft during the payment process.
• Data exposure: Compromised payment details threaten customer privacy and can lead to fraudulent transactions, identity theft, and long-term reputational damage for affected merchants.
• Attack scalability: Using widely trusted services like GTM, Stripe, and Firestore allows attackers to scale their operation across multiple storefronts with minimal code changes.

Closing ThoughtsThe convergence of trusted third-party services with malicious scripts demonstrates how attackers exploit the “trust” built around commonplace web infrastructure. By embedding the skimmer in legitimate GTM containers and routing data through Stripe (or Firestore), the campaign leverages familiar, permissive pathways to harvest payment information at the checkout. Vigilance at the integration layer, continuous monitoring of unusual GTM deployments, and regular auditing of third-party scripts remain critical for detecting and mitigating these sophisticated exfiltration techniques.