When Trusted GTM Turns WebRTC Into a Stealth Magecart Pipeline

WHEN TRUSTED GTM TURNS WEBRTC INTO A STEALTH MAGECART PIPELINE

Attackers found a new way to steal payment data without ever loading a visible malicious script from the web. In this attack, Google Tag Manager, a trusted tool many sites already allow to run in the browser, was used as the starting point, while WebRTC, a browser feature built for real-time communications, was abused to stream the real skimmer directly into the page. That makes the attack especially risky because many traditional defenses look for suspicious script files, known domains, or obvious network requests, and this technique avoids all three. The result is a quieter form of Magecart that can execute inside the browser, target checkout data, and leave far less evidence in the controls many teams depend on.

Attack details

The attack begins with a malicious tag injected into Google Tag Manager, giving the attacker code execution through a trusted third-party platform already allowed on the site. That initial loader does not contain the full skimmer. Instead, it creates a WebRTC connection, opens a data channel to attacker-controlled infrastructure, and receives the second-stage JavaScript dynamically through that peer-to-peer session rather than over a standard HTTP request. Once the payload arrives, it is decoded, decrypted, decompressed, and executed directly in the page, allowing it to access checkout data without ever appearing as a conventional external script. In the observed attack, the loader reuses a valid nonce already present on the page, making malicious code appear trusted to the browser and bypassing strict CSP protections.

How Source Defense protects you

This attack shows why client-side security must focus on what happens inside the browser after code begins to run, not just where a script appears to come from. When a trusted platform such as Google Tag Manager is used as the foothold and the real payload is later delivered over WebRTC, the most important control is immediate visibility into the malicious behavior that follows. Source Defense helps security teams identify suspicious browser activity tied to this kind of attack, including access to sensitive checkout data, risky runtime execution, and the transfer of data out of the page. These behaviors are surfaced directly in the platform through the bell notification center, dashboard summaries, and the relevant “Script behaviors” and “Found in blacklists” widgets when applicable, and they can also be sent by email and/or webhook based on configuration. Relevant alerts for this pattern can include:

• Accessing PCI data
• Accessing data
• Transferring data
• Executing risky actions

This gives organizations meaningful detection coverage for stealthy client-side attacks that avoid normal script loading, reduce forensic visibility, and weaken traditional controls such as CSP, WAF inspection, and server-side logging alone.

Key takeaways

This attack shows how Magecart is evolving from visible external skimmers into staged browser-side threats that abuse trusted third-party tools and covert transport channels. Controls such as CSP, SRI, WAFs, and server-side logging still matter, but they may miss attacks that start from approved browser code, avoid traditional script loading, and execute dynamically in memory. That is why client-side security controls offered by Source Defense are essential for modern payment pages: they extend protection to the point where data is actually handled, provide visibility into malicious browser behavior, and help reduce fraud, compliance, and operational risk before stolen payment data becomes a larger business problem.