Research
The campaigns
Every campaign documented here began the same way: an unexpected request, blocked by a customer's security policy and captured in real browser telemetry. On its own, a strange hostname might be nothing more than noise. But when the same host starts appearing across unrelated sites, it becomes a pattern worth investigating. We follow those signals, connect the dots, and document what we find here — with the latest campaigns first.
Aug 2026
A family of unrelated-looking domains, retired and replaced on a schedule, all sitting on one server the whole time.
15 indicators
· c2 · extensions · infrastructure · detection
Aug 2026
Attacks that remove a hosted payment element and render a convincing copy in its place, so card details are typed into attacker-controlled markup on a page that still looks entirely correct.
2 indicators
· magecart · skimmer · pci-dss · tag-manager
Jul 2026
Skimmers that read their next-stage host out of a blockchain contract, so the operator can move infrastructure without ever going back into the sites they compromised.
5 indicators
· magecart · skimmer · clickfix · web3 · c2
Jul 2026
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.
5 indicators
· magecart · skimmer · webrtc · exfiltration
Jul 2026
Attackers who generate a new subdomain for every victim, so blocking the host you saw yesterday achieves nothing today.
3 indicators
· magecart · skimmer · dga · detection
Jul 2026
Injected scam and scareware content that steals attention and trust rather than card numbers, which is exactly why it survives on a page longer than a skimmer would.
3 indicators
· scareware · scam · injection · monetisation
Jul 2026
An overlay that tells the visitor to fix a problem by pasting a command, turning the person into the delivery mechanism and leaving no malicious download to catch.
5 indicators
· clickfix · social-engineering · websocket · c2
Jun 2026
Skimmers served from domains registered one character away from a CDN you already trust, so the host survives the glance that a review gives it.
8 indicators
· magecart · skimmer · typosquat · supply-chain
Apr 2026
Extensions your visitors installed, running on your pages, reporting to a shared C2 cluster and taking session data with them.
16 indicators
· extensions · c2 · session-theft · exfiltration
Mar 2026
Packages you legitimately depend on, compromised upstream, arriving in your bundle through the same pipeline everything else uses.
7 indicators
· supply-chain · npm · exfiltration · sri
The Tiers
Indicator of Compromise, or Suspicious
We assess hosts continuously as they appear in browser telemetry, so classifications can change as new evidence emerges. We use two distinct tiers — Indicator of Compromise and Suspicious — to show how confident we are that a host represents a genuine threat. The telemetry behind that runs at thousands of data points a second, and you can watch it live on our public dashboard.
Confirmed
Indicator of Compromise
We have evidence the host is doing something hostile: serving skimmer code, collecting stolen card data, or staging a payload. If one shows up in your reports, it needs looking at.
Unconfirmed
Suspicious
Something about the host looks wrong but we can't confirm it's hostile yet. We flag it so you can see it, without calling it a confirmed finding. Some of these become Indicators of Compromise later and some turn out to be fine.
Both surface in the product: badges on your report rows, filters, and Watch alerts. Where a flagged host belongs to a campaign we have written up, its badge links straight through to the research — so the evidence behind a classification is one click from the report that raised it, and you can judge for yourself what it means for your site. See how threat intelligence works →
Methodology
How a host enters the feed
It starts with our own data. Hosts show up in the reports our customers already send us, the ones that look wrong get triaged and classified, and where somebody else has covered the same infrastructure we check our findings against theirs. Every write-up says which of those applies.
This runs all the time, so the feed is never finished. We add hosts as they appear, widen an entry when an attacker starts rotating subdomains, and pull a host back out when the evidence no longer holds up.
Behaviour, not intent
What we will say
We describe what a host was seen doing: serving skimmer JavaScript, receiving card data. We don't make claims about who's running it or why.
Subtree entries
When we cover a whole domain
An entry starting *. covers a domain and everything under it, so an attacker cycling through subdomains doesn't get away from it. We only do this when the attacker registered the domain themselves. If it's a real site that's been compromised, we stick to the exact host.
Scope
Why the feed outruns the write-ups
There are thousands of hosts in the feed and a few dozen write-ups here. That gap isn't a backlog we're working through.
Most of these domains don't last long. One gets registered, serves a skimmer for a week or two, then goes quiet. The attacker moves to a new subdomain, we widen our entry to cover the whole domain, and the original host stops mattering. If we wrote a page for every one of them, most would be about domains that were already dead.
The campaign is the part worth writing about. Attackers swap domains constantly, but they reuse the same techniques and delivery routes for months, sometimes years. That's what these pages cover, so they're still useful after every host in them has gone.
Corrections
Disputing a classification
If a host named here is yours and we've got it wrong, email support@report-uri.com and tell us what it actually does.
If we're wrong, we take the host out of the feed and off this page. We don't just add a note saying it's disputed. The pages and the feed come from the same place, so the fix lands in both at once.
FAQ
Frequently asked questions
A host we have evidence is doing something hostile: serving skimmer code, collecting stolen card data, or staging a payload. If one shows up in your reports it is worth looking at rather than tuning out.
Suspicious is the tier below. Something about the host looks wrong but we cannot confirm it is hostile, so we flag it for you to see without calling it a confirmed finding. Some become Indicators of Compromise later and some turn out to be fine.
Hosts that show up in the browser telemetry our customers already send us. We triage and classify them, and where somebody else has covered the same infrastructure we check our findings against theirs. Each write-up says which of those applies.
No, every page here is public. What a paid plan gets you is the answer to whether any of these hosts are showing up in your own reports.
There are thousands of hosts in the feed and most of them do not last long. A domain serves a skimmer for a week or two, the attacker moves on, and a page written about that one host would already be out of date. Campaigns last much longer than the domains they run on, so that is what we write about.
Email support@report-uri.com with the host and tell us what it actually does. If we have got it wrong we take it out of the feed and off these pages, rather than leaving it up with a note attached.
See which of these are on your site.
We check your reports against the feed as they arrive, so if one of these hosts turns up on your site you'll know about it straight away. It's one HTTP header, and nothing of ours runs on your pages.
