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.
Published 28 July 2026
Updated 24 August 2026
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.
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.
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.
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.
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.
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.
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.
*.cdn-statmetrics.com*.cloudservicecon.com*.dinkfoundry.com*.infolservice.com172.86.119.16Corroborated by external research. We classify these on what we saw them doing, not on any claim about who runs them.
We flag these hosts in your own reports automatically, so you hear about it from us instead of from your customers.
← All threat intelligence research · Read this page as Markdown