MAJOR US AUTO BRAND SITES HIT BY MAGECART
If you recently visited the online storefront of a major US car manufacturer, your credit card data may have been at risk.
Source Defense Research uncovered a sophisticated Magecart campaign targeting leading US automotive brand sites where visitors could purchase items such as branded products and auto parts. After earlier defenses were added, the attackers adapted, hiding their malicious activity inside trusted tools like Google Tag Manager and Google Analytics 4.
To most security tools, this could look like normal business traffic.
To Source Defense, it looked like an attack.
This is exactly why client-side security cannot rely only on trusted domains or static allowlists. Modern attackers abuse the tools businesses already depend on.
Attack details
The attack was delivered through a shared Google Tag Manager container, GTM-MX8L362L, used across multiple related merchandise storefronts for major US automotive brands. Because GTM is commonly treated as trusted business infrastructure, the malicious logic could scale across several checkout flows from one central point. The skimmer activated during checkout interactions, focusing execution at the moment shoppers were most likely to have entered high-value payment and identity data.
Once triggered, the GTM-hosted logic looked for specific checkout form fields rather than scraping the page indiscriminately. It targeted payment and identity fields, including card number, expiration date, CVV/CID, first and last name, street address, city, state or region, postal code, country, phone number, and email. In the original evidence, the skimmer was tailored to the Authorize.Net CIM checkout flow and watched for submission activity around the payment button before harvesting the relevant field values.
The collected values were combined into a structured, pipe-delimited string, then obfuscated with an XOR-style routine using the key 5d7845ac6ee7cfffafc5fe5f35cf666d. The result was Base64-encoded so the payload would not appear as readable cardholder data in transit. The attacker then split the encoded payload into three fragments and placed them into custom Google Analytics 4 event parameters: ep.fields_p1, ep.fields_p2, and ep.fields_p3.
This is what made the exfiltration especially stealthy. Instead of sending stolen data to an unfamiliar attacker-controlled domain, the browser sent what appeared to be ordinary analytics traffic to the GA4 collection endpoint:
https://www.google-analytics.com/g/collect
The requests used the attacker-controlled GA4 Measurement ID G-7DTFFTL7Y8 and the event name ga4_event. That combination allowed the traffic to resemble legitimate business telemetry, while the fragmented and encoded payload reduced the chance that simple inspection would reveal a complete card number, CVV, or billing record.
The key point is that this was third-party execution through a trusted third-party tag management system, followed by third-party exfiltration through a trusted analytics endpoint. The earlier attack reportedly used an obviously suspicious external domain, but the later campaign evolved into a “living off the land” approach by abusing infrastructure that many CSP policies already permit.
How Source Defense protects you
Source Defense extends security to the client side, where Magecart and eSkimming attacks actually execute, and protects data at the point of input before it reaches the security of the web server. In this type of GTM-driven campaign, Source Defense can control third-party script behavior in the browser, preventing unauthorized access to sensitive checkout fields and blocking unauthorized data transfers before cardholder data is exfiltrated. This matters because a domain may be trusted while the behavior is not. A Google-hosted script can still attempt to read payment fields, package sensitive data, and send it somewhere it does not belong. Source Defense focuses on that runtime behavior, helping organizations detect and block unauthorized scripts before data exfiltration while supporting PCI DSS 4.0.1 requirements for payment page script inventory, authorization, integrity, and change detection.
How Source Defense alerts you
For a GTM-based attack like this, alerts surface in the bell notification center, dashboard summaries, and the “Script behaviors” widget. Depending on configuration, alerts can also be sent by email and/or webhook. Relevant alert types include:
- Accessing PCI data
- Accessing PII data
- Accessing credential data
- Accessing data
- Transferring data
- Executing risky actions
Key takeaways
This campaign is a clear example of why client-side security cannot rely on CSP, SRI, WAFs, or server-side logging alone. CSP helped address the earlier malicious-domain approach, but the attackers responded by moving into trusted Google infrastructure that was likely already allowlisted. SRI is difficult to apply to dynamic third-party services like tag managers, and WAFs or server logs may never see the browser-side field access that happens before submission. Source Defense provides the visibility and control needed for modern eSkimming defense: which scripts are running, what data they touch, what actions they take, and whether sensitive information is being transferred in ways that put customers and the business at risk.
PCI DSS 4.0 makes client-side security a priority.
Source Defense delivers a solution for 6.4.3 and 11.6.1 without adding a burden to your security teams.