WebRTC Skimmers: Magecart Exfiltration With No Request to Find

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 skimmer is there: CSP reports the requests that load it or set up its channel, and Connection Allowlist reports the WebRTC connection itself. That's worth having, but it doesn't stop the card data leaving.

Enforcing it helps, but connect-src alone isn't enough here. It blocks the HTTP and WebSocket requests a skimmer makes to fetch its code or set up its channel, but it doesn't cover WebRTC, so a data channel or TURN connection to the attacker's server goes ahead regardless. The CSP webrtc directive would cover it, but browsers don't support it yet. Connection Allowlist blocks WebRTC by default, so with it enforced the card details never leave. It has only shipped in Chrome so far, so visitors on other browsers are still exposed. Where it applies, 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 locking down outbound connections 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 together with Connection Allowlist is what sits between a running skimmer and a successful theft.

What to look for

The reporting signal is a violation naming a host you never authorised, from the requests that load the skimmer or set up its channel. The WebRTC connection itself isn't governed by connect-src, so CSP won't report it. Connection Allowlist will: a webrtc connection report from a checkout that never uses WebRTC is a strong signal on its own, even though it doesn't name the destination.

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.

The hosts we're tracking for this campaign

These are the entries in our threat intelligence feed for this campaign, shown exactly as we match them. An entry starting *. covers that domain and everything under it, so an attacker cycling through subdomains doesn't get away from it. We only do that when the attacker registered the domain themselves.

The feed changes as we go. We add hosts when they show up and pull them out when the evidence no longer holds, so this is what we're matching today rather than a permanent record.

Frequently asked questions