Magecart Attack Uses Stripe to Command Malware

Key Takeaways

• A sophisticated Magecart attack leverages trusted payment platforms like Stripe and Google Firestore for command and control and data exfiltration.
• The malware bypasses conventional security measures by using legitimate domains (api.stripe.com, firestore.googleapis.com, googletagmanager.com) to deliver payloads and siphon stolen credit card data.
• Attackers embed card-skimming code within Stripe customer metadata and Google Tag Manager containers, making detection extremely difficult without deep inspection.
• The campaign has been active since at least December 2025, posing a significant threat to e-commerce merchants and their customers.

A new, highly evasive credit card skimming operation has been uncovered, exploiting the very infrastructure designed to secure online transactions. This Magecart attack uniquely utilizes Stripe, a ubiquitous online payment service, not just for processing payments, but as both its command-and-control server and its data exfiltration hub. A variant of this attack also leverages Google Firestore, Google’s cloud-hosted database, demonstrating a growing trend of abusing trusted cloud services.

Security researchers have detailed how this innovative approach allows threat actors to funnel stolen payment information through legitimate and whitelisted domains, effectively rendering traditional security tools blind to the malicious activity. Unlike typical skimmers that transmit data to attacker-controlled servers, this malware integrates seamlessly into the legitimate traffic flow of e-commerce sites.

Stealthy Operation Through Trusted Channels

The core of this attack’s ingenuity lies in its ability to operate under the radar of most security solutions. The malicious code is never loaded from a suspicious, attacker-owned domain. Instead, both the initial malware payload and the exfiltrated credit card details traverse api.stripe.com, a domain universally permitted by nearly all e-commerce platforms. This strategic choice allows the malicious traffic to bypass standard network filters and security policies designed to detect and block unauthorized data transfers.

Analysts at Sansec, a firm specializing in e-commerce security, were instrumental in identifying this novel Magecart family. Their findings, published on June 4, 2026, reveal a multi-stage attack. According to a Sansec report shared with Cyber Security News (CSN), attackers store the card-stealing JavaScript within a Stripe customer’s metadata fields. This code then executes on checkout pages, capturing sensitive financial information before discreetly writing it back into the same Stripe account, disguised as new, fake customer entries. This method effectively transforms Stripe into a free, robust, and trusted command infrastructure for the criminals.

The initial infection vector for this campaign relies on Google Tag Manager (GTM). Legitimate GTM containers, including one identified as GTM-P6KZMF63, are compromised and injected with a custom tag that serves the malware loader directly from googletagmanager.com. This tactic further enhances the malware’s stealth, as the loader appears alongside a store’s legitimate analytics tags, making it exceptionally difficult to identify without a meticulous manual audit of GTM configurations.

Evidence suggests this campaign has been active since at least December 2025, coinciding with the creation date of the Stripe account used by the attackers. The account was established on December 24, 2025, utilizing what appears to be a default template from Stripe’s own sample data, complete with placeholder names and email addresses, further blurring the lines between legitimate and malicious activity.

The Multi-Stage Attack Flow

The Magecart malware operates in a precise three-step sequence:

1. Loader Deployment: An infected Google Tag Manager container loads a small loader script on every page. When a checkout page is detected, this loader initiates contact with a specific attacker-controlled Stripe customer record to retrieve the main skimmer code, which is fragmented and stored across multiple metadata fields.
2. Data Capture: Once assembled and downloaded, the skimmer code attaches itself to the checkout button. The moment a user clicks to finalize a purchase, the malware intercepts and captures critical payment data, including the full credit card number, expiration date, CVV, billing address, and total order amount. This sensitive information is then XOR-encoded and temporarily stored in the browser’s local storage, rather than being immediately transmitted.
3. Delayed Exfiltration: The actual data theft occurs on a delay. A separate routine periodically checks for stored card data—one second after each page load and then every 60 seconds thereafter. Upon finding a record, the data is split and posted to Stripe’s customer API as a new, fraudulent customer entry. The attackers can then retrieve all stolen card details by simply listing customers within their own compromised Stripe account.

A Second Variant Using Google Firestore

Sansec’s investigation also uncovered a related variant of this Magecart attack that substitutes Stripe with Google Firestore, Google’s cloud-hosted NoSQL database service. This version retrieves its skimmer payload from a Firestore document located within a project named “braintree-payment-app.” The choice of this name is deliberate, designed to mimic legitimate payment processing traffic and avoid triggering security alerts.

Both the Stripe and Firestore variants exemplify the same underlying strategy: exploiting trusted, mainstream cloud services as covert channels for malware delivery and data exfiltration. This tactic bypasses standard security rules that would typically flag communication with unknown or suspicious domains. The existence of the Firestore variant underscores the attacker group’s active development of diverse delivery mechanisms for their sophisticated skimming toolkit, indicating a persistent and evolving threat landscape.

What You Should Do

• Audit Client-Side Scripts: Regularly inspect all client-side JavaScript for any Stripe secret keys. Legitimate front-end code should never contain these keys.
• Monitor API Calls: Treat any unauthorized api.stripe.com or firestore.googleapis.com calls originating from browser JavaScript as a strong indicator of compromise.
• Review Google Tag Manager: Conduct thorough, regular audits of all tags within your Google Tag Manager account. Immediately remove any tags that were not personally added or explicitly authorized.
• Implement Content Security Policy (CSP): Strengthen your website’s Content Security Policy to restrict which domains can execute scripts and load resources, thereby limiting the attacker’s ability to load malicious code.
• Enable Subresource Integrity (SRI): For all third-party scripts, implement Subresource Integrity to ensure that the files served have not been tampered with.

Indicators of Compromise (IoCs):-

Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.