# Magecart Gang Weaponizes Stripe and Google Infrastructure to Hide Credit Card Theft at Scale


A sophisticated credit card skimming campaign discovered by ecommerce security researchers is exploiting trusted third-party services to steal payment data while evading detection. The operation abuses both Stripe's payment API and Google Tag Manager to deliver card-stealing malware, turning legitimate payment infrastructure into a data exfiltration pipeline that blends seamlessly into normal e-commerce traffic.


## The Threat: Hiding in Plain Sight


Researchers at Sansec, a leading ecommerce security firm, uncovered a new variant of Magecart—the notorious attack group known for injecting malicious code into checkout pages. What makes this campaign distinctive is its brazen reliance on trusted domains to bypass virtually all conventional security defenses.


The attackers exploit two critical trust assumptions:

  • Google Tag Manager (googletagmanager.com): Used legitimately by thousands of online stores to manage analytics and tracking scripts
  • Stripe API (api.stripe.com): The payment processing platform explicitly whitelisted by most ecommerce sites

    • "Both the payload and the stolen cards move through api.stripe.com," Sansec reports. "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."


    This approach is devastating because it exploits what security teams trust most—infrastructure so ubiquitous that blocking it would break legitimate business operations.


    ## How the Attack Works: Technical Breakdown


    The attack chain relies on a carefully orchestrated sequence of legitimate-looking requests that hide malicious functionality:


    ### Payload Delivery

    The malicious code is embedded in what appears to be a standard Google Tag Manager container. When a customer reaches a checkout page, the code executes automatically—a normal behavior for GTM but weaponized here to run the skimmer.


    ### Data Collection and Obfuscation

    Once activated on a checkout page, the skimmer targets Magento/Adobe Commerce installations and captures:

  • Credit card numbers
  • Expiration dates
  • CVV codes
  • Customer names and billing addresses
  • Email addresses and phone numbers

    • Rather than immediately transmitting this data, the malware stores it locally and obscures it using XOR obfuscation—a simple but effective technique that makes quick signature-based detection difficult.


    ### The Clever Exfiltration Layer

    This is where the operation becomes particularly ingenious. The stolen data isn't sent to an attacker-controlled server. Instead, a separate routine executes upon page load and every minute thereafter to:


    1. Split the stolen data into chunks

    2. Create a new fake Stripe customer record in the attacker's account

    3. Store the stolen payment data in the metadata fields of that customer object


    As Sansec explains, "Every stolen payment card becomes a fake customer record in the attacker's Stripe account, turning Stripe into a storage backend for stolen data."


    The attacker's infrastructure interacts with Stripe using a legitimately created account, making the traffic appear identical to normal payment processing activity. After data is copied, local files are wiped to eliminate forensic traces and prevent duplicate uploads.


    ### The Firestore Variant

    Researchers also discovered an alternative version using Google Firestore, a cloud database service. In this variant:

  • The skimmer payload comes from a Firestore document named tracking/captcha
  • The project is named braintree-payment-app (designed to blend with legitimate payment software)
  • Stolen data is stored in a localStorage key called _d_data_customer_

    • The naming convention is deliberately misleading—another layer of obfuscation designed to appear legitimate during cursory security reviews.


    ## Background and Context: The Magecart Threat Landscape


    Magecart is not a single group but a loosely affiliated ecosystem of card-stealing operations, many of whom have targeted ecommerce sites since at least 2015. Previous Magecart campaigns have:


  • Compromised supply chain vendors to inject code across thousands of sites simultaneously
  • Infected payment card processors handling millions of transactions
  • Remained undetected for months or years due to their ability to blend into legitimate traffic

    • The use of trusted third-party services in skimming campaigns isn't new, but the sophistication of this particular variant—leveraging both GTM and Stripe in tandem—represents an escalation. By using payment processor infrastructure as a data storage backend, attackers sidestep the need to operate visible infrastructure, dramatically reducing the forensic footprint of their operation.


    The Stripe customer record containing the skimmer was created on December 24, 2025, suggesting the campaign has been active for at least six months before discovery.


    ## Security Implications: Why This Matters to Online Stores


    This attack exposes critical vulnerabilities in the trust model that ecommerce sites depend on:


    | Trust Assumption | Reality |

    |---|---|

    | Google Tag Manager domains are safe | Trusted implicitly, but can be compromised or abused by legitimate users |

    | Stripe API traffic is legitimate | All traffic appears identical to normal payment processing |

    | Content Security Policy (CSP) protects us | Meaningless if trusted domains themselves host malicious code |

    | Web Application Firewalls (WAF) catch skimmers | Rules tuned to ignore traffic from whitelisted domains |


    Organizations running Magento/Adobe Commerce are at elevated risk, as the skimmer is specifically designed for this platform's checkout architecture. However, the fundamental weakness—abusing trust in third-party infrastructure—could be adapted to other ecommerce platforms.


    The financial impact is severe: each stolen card represents potential fraud liability, chargeback losses, regulatory fines, and reputational damage. Payment Card Industry (PCI) compliance becomes a moving target when even compliant infrastructure is weaponized by attackers.


    ## Recommendations for Defenders


    ### Immediate Actions

  • Audit GTM containers: Review every tag and trigger in your Google Tag Manager configuration. Verify that each one is legitimate and that container access is properly restricted.
  • Monitor Stripe integrations: Use Stripe's activity logging to flag any unusual customer object creation or metadata modifications by your integrations.
  • Review CSP policies: CSP cannot stop this attack, but it can mitigate related skimmers. Ensure your policy is as restrictive as practical.
  • Check for compromised checkout: Look for unauthorized modifications to Magento checkout templates or custom modules.

    • ### Detection and Monitoring

  • Monitor browser console errors and network activity during checkout to catch anomalous JavaScript execution
  • Implement subresource integrity (SRI) for any third-party scripts you control
  • Use ecommerce-specific endpoint detection and response (EDR) tools designed to catch skimmers
  • Review checkout page source code and JavaScript execution in staging environments before deploying to production

    • ### Long-Term Defense

  • Implement tokenization: Replace full credit card handling with token-based payment methods that reduce the data exposed to the checkout page
  • Use virtual card numbers or one-time card tokens for payment processing—a technique that renders stolen card data useless after a single transaction
  • Shift toward payment methods that don't expose card data client-side, such as Apple Pay or Google Pay
  • Regularly audit and update all third-party integrations and dependencies

    • ---


    ## HackWire Analysis


    This campaign represents a watershed moment in how attackers think about infrastructure. Rather than building their own C2 servers, malware repositories, and data storage, this operation leverages the legitimate digital supply chain that defenders consider sacrosanct. The genius lies not in technical innovation—XOR obfuscation and GTM injection are well-understood techniques—but in operational tradecraft.


    By routing everything through api.stripe.com and googletagmanager.com, attackers force a choice between security and usability: block these domains and your ecommerce site breaks; allow them and your CSP, WAF, and network monitoring become theater.


    This also exposes a blind spot in how the payments industry thinks about risk. Stripe's infrastructure wasn't compromised—it was used *legitimately* by an attacker who created a real account and used real API calls. From Stripe's perspective, this is normal customer activity. The company has no way to distinguish between a legitimate payment processor using customer metadata fields and a criminal doing the same thing. The abuse lies in *intent*, not in technical exploitation.


    The financial impact compounds the urgency. A single compromised checkout page can steal dozens of cards daily across hundreds or thousands of victims. Six months of undetected operation—from December 2025 to now—suggests thousands of stolen payment records, each a liability for the victim stores and a revenue stream for the attackers.


    For defenders, the lesson is hard: you cannot out-whitelist an attacker who understands which domains your security team will never block. The path forward requires moving payment data outside the browser entirely, embracing tokenization, and accepting that trust in third parties must be paired with continuous monitoring of their actual behavior in your environment. — HackWire Editorial


    ---


    ## Related Coverage


  • Read more in our [Breaches](https://www.hackwire.news/category/breaches) coverage
  • Cross-reference with [Vulnerabilities](https://www.hackwire.news/category/vulnerabilities) and [Malware](https://www.hackwire.news/category/malware)
  • Stay current via the [HackWire homepage](https://www.hackwire.news/)