Introduction to the Threat
A newly discovered Magecart campaign has been found to be abusing Stripe's API infrastructure to host credit card-stealing payloads and the data exfiltrated from checkout pages. This malicious activity relies heavily on Google Tag Manager and Stripe domains, which are implicitly trusted by online stores.
The campaign was discovered by researchers at ecommerce security company Sansec, who noted that the malicious code is loaded from a Google Tag Manager (GTM) container and executes on every page that loads it. Sansec explains that both the payload and the stolen cards move through api.stripe.com, a domain that stores allow by default, thus allowing the skimmer to slip past Content Security Policy rules and network filters.
How the Malware Works
Google Tag Manager (GTM) is a management system that allows website owners to add and manage scripts used for analytics, ads, and tracking without modifying the site's source code. Stripe, on the other hand, is a payment processing platform widely used by online stores to accept credit cards, manage customer orders, and handle billing.
According to Sansec, the malicious code is embedded in legitimate-looking GTM containers, which activate when a shopper reaches a checkout page. The code then queues Stripe's API for a specific customer record and reads JavaScript code from the metadata fields of the record, reassembling and executing it using new Function().
Target and Data Capture
The card skimmer specifically targets Magento/Adobe Commerce checkout pages and attempts to capture payment data, including credit card numbers, expiration dates, CVV codes, customer names, billing and email addresses, and phone numbers.
The stolen data is concatenated into a single string, obfuscated using the XOR operation, and stored locally instead of being immediately exfiltrated. The data retrieval is done through a separate routine that executes right after a page load and every minute thereafter, by splitting the data blob in half, creating a new Stripe customer object, and storing the stolen data in metadata fields.
Data Exfiltration and Storage
Every stolen payment card becomes a fake customer record in the attacker's Stripe account, effectively turning Stripe into a storage backend for stolen data. Once the data is copied, the local file is wiped to eliminate traces of the attack and prevent duplicate uploads.
Sansec also discovered a variant of the attack where Google Firestore, a cloud database service for data storage and real-time retrieval, is used instead of Stripe. In this version, the payload is retrieved from a Firestore document named tracking/captcha in a project called braintree-payment-app, and the stolen data is stored in a different localStorage key (_d_data_customer_).
Protection and Mitigation
Customers can protect themselves from such risks by using one-time virtual cards with set limits. Furthermore, security teams are advised to test every layer before attackers do, as 54% of successful attacks are logged and only 14% are alerted on, with the rest moving through the environment unseen.
A whitepaper by Picus shows how breach and attack simulation tests SIEM and EDR rules so threats stop slipping by detection, providing a valuable resource for enhancing security measures.
Source: BleepingComputer