# WebRTC Skimmers: Magecart Exfiltration With No Request to Find A Magecart cluster that pushes stolen card data down a WebRTC data channel instead of sending a request, so monitoring built to inspect requests sees a checkout behaving normally. Provenance: Corroborated by external research. Published: 2026-07-28. Updated: 2026-08-24. Most card skimmers exfiltrate over HTTP. The stolen field values go out as a request to a host the attacker controls, and that request is the thing defenders look for: an unfamiliar destination in an egress log, a POST that does not belong to the checkout flow, a beacon fired on form submit. This cluster doesn't. It opens a WebRTC peer connection and pushes the card data down a data channel, so there's no request to find. Anything watching outbound requests sees a checkout page behaving completely normally while the card details leave the browser. ## How the skimmer works The skimmer is injected into the payment page by whatever compromise the operator already has. Once running, it reads the payment fields directly rather than intercepting the form submission, which means it collects the card number as it is typed rather than only when the customer completes the purchase. An abandoned checkout still leaks. One variant in this cluster fakes a payment form outright. On a compromised Vietnamese merchant it rendered a convincing VNPay form over the real checkout, collected the details, and relayed them through a WebRTC channel to a host we now track. ## Why rotation defeats a fixed entry Four of the hosts here were originally matched on a single fronting label — one subdomain each, on apex domains that appear nowhere else. Rotating that one label was enough to escape an entry keyed on the full name, and all four turned up again in a later sighting on the same apexes. They are tracked as subtree entries now, so the whole apex is covered and the next label the operator invents is matched before we have seen it. Every host in this cluster is attacker-registered rather than a compromised legitimate site, so covering the subtree cannot reach an innocent host. That's the call we have to make every time we widen an entry. A legitimate site that's been compromised will get cleaned up, and its subdomains belong to somebody real, so we stay narrow there. Nobody else is ever going to use an attacker's own domain, and matching only the label they're using today means chasing the same operator again next week. ## Why the hosts look legitimate Every host in this cluster is named to read like infrastructure. The labels are `cdn`, `api` and `relay`; the domains they sit on are the kind of two-word compounds that a payments or analytics vendor might plausibly own. None of them are typos of a real vendor, which is the more familiar trick — they are simply unremarkable. That matters because of how a script or connection inventory is usually reviewed. Somebody scans it looking for something that stands out, and nothing here does. A domain that sounds like a metrics vendor sitting alongside real metrics vendors does not draw the eye, and the review passes. You won't fix that by looking harder. You fix it by deciding what's allowed before the review, so the question becomes whether this host is on your list instead of whether it looks plausible. ## What an enforcing policy stops Report-only mode tells you the connection happened. That's worth having, and it's how these hosts came to our attention in the first place, but it doesn't stop the card data leaving. Enforcing it does. If `connect-src` names the origins your checkout is allowed to talk to, the browser refuses the skimmer's connection when it tries, and the card details never leave. The skimmer is still running and the compromise that put it there is still unfixed, but the theft fails and you get a report telling you it happened. That's the argument for getting `connect-src` right on your payment pages even if the rest of your policy is still report-only. Stealing the data needs an outbound connection, and `connect-src` is the directive sitting between a running skimmer and a successful theft. ## What to look for The reporting signal is a `connect-src` violation naming a host you never authorised. WebRTC negotiation is governed by `connect-src`, so the attempt is reported even though the channel that follows carries no HTTP request — which is exactly why policy reporting catches this where request inspection does not. Two things make these easy to wave away. There aren't many of them, because only the visitors who reach a payment form trigger one at all. And the host they name looks like infrastructure, so it reads as something misconfigured rather than an attack. A handful of `connect-src` reports naming an unfamiliar but plausible host is exactly what this looks like from the inside, and the instinct to allowlist it and move on is the wrong one. If one of the hosts below appears in your reports, treat it as a compromise of the page that reported it rather than a policy gap, and work backwards to how the script got there. ## Indicators - *.cdn-statmetrics.com - *.cloudservicecon.com - *.dinkfoundry.com - *.infolservice.com - 172.86.119.16 ## Questions ### What is a WebRTC Magecart skimmer? A card skimmer that sends stolen payment details down a WebRTC data channel instead of making an HTTP request. Your network monitoring never sees the card data in a request, because WebRTC opens a peer connection and carries the payload outside the normal request path. ### Why does WebRTC exfiltration evade monitoring? Most egress controls and client-side monitoring tools look at requests. A WebRTC data channel isn't one, so a tool watching for a suspicious POST to an unfamiliar host sees nothing at all while the card data leaves the page. ### How do I tell whether my site is affected? A Content Security Policy tells you what the browser was actually asked to do, including the connections a skimmer opens. Look for connect-src violations naming hosts you never allowed. WebRTC negotiation is covered by connect-src, so you get the report even though the channel itself makes no HTTP request. ### Does blocking these hosts stop the attack? It stops the data getting out. Whatever compromise injected the skimmer is still there, so enforcing a policy buys you time to find it rather than doing that job for you.