A family of unrelated-looking domains, retired and replaced on a schedule, all sitting on one server the whole time.
Published 24 August 2026
The domains in this cluster do not look related. They are registered months apart, through more than one registrar, and their names read like ordinary analytics endpoints — the kind of hostname that survives a review because nothing about it invites a second look.
They are related. Every one of them resolves into the same small block of servers, and has done for as long as we have telemetry covering them.
An operator runs two or three domains at a time. Each carries a share of the traffic for weeks or months, and then, on a single day, they stop and are replaced. Not tapered — stopped. The two we watched most closely were still on sixty-odd sites the day before they went quiet.
The replacements tend to go live the same day they are bought. One was registered just before one in the afternoon and was being blocked on more than a dozen unrelated sites by that evening. Nothing had to be deployed for that to happen. Whatever is running in the visitor's browser already knew where to look, and the only thing that changed was the address it looked at.
Which tells you what the domain actually is. Not the operation — a setting in the operation, and one that costs about as much to replace as a cup of coffee.
A few do sit and wait. One was registered in May, generated nothing at all for twelve weeks, then came up in the August changeover alongside the rest. Those are the ones worth hunting for: a domain resolving into the same block but barely showing up in reports is not a straggler winding down, it is the next rotation waiting to start.
Every defence keyed to the registered domain has the same problem: it can only describe domains that have already been used.
A blocklist entry is a record of the last rotation. A reputation score is a judgement about a domain's history, and the replacement has none — it is a clean name on a dirty server, and the score has no way to express that. So the new domain arrives unflagged, runs for weeks, accumulates enough of a history to be judged, and is retired around the time anything catches up with it.
None of this requires the operator to react to defenders. It is a schedule, and the schedule is shorter than the loop that would catch it.
The server does.
Domains are cheap and disposable. A server is neither: it is rented, it is paid for monthly, and moving means rebuilding. So while the names churn, the address underneath them tends not to, and one address can sit under an entire family across several rotations.
Pivoting on it takes a resolver and nothing else. Resolve the hosts your reports have shown you, group them by address, and look at the groups holding more than one domain. Most will be a CDN and uninteresting. What is left is short.
Two corroborating signals usually sit alongside it. The registration timestamps cluster — domains bought in the same minute, sometimes the same second, are one purchase. And the registrar and nameservers repeat across the family, because whoever is running it has an account somewhere and keeps using it.
You do not have to take our word for any of this. Point a filtering resolver at some of these domains and it will not answer you — no address, nothing. Someone else looked at them and came to the same conclusion we did, without ever seeing our reports.
Which ones, though, is the interesting part. They are the old domains, retired a rotation or two back. The two doing the work today resolve fine everywhere. That is not a dig at the blocklists — it is the same lag as before, seen from the other side.
Grouping by address is only meaningful when the address belongs to one tenant.
A CDN edge fronts thousands of unrelated sites and tells you nothing; so does budget shared hosting. The distinction is a lookup rather than a guess — the allocation's registered holder and its size say plainly whether you are looking at a provider's shared estate or a single small block that one customer rents.
Where it is the second, the network is the durable indicator and the domain list is a description of history. Where it is the first, stay with the hosts.
Where the delivery mechanism is a browser extension, and it often is, none of this indicates that your site has been compromised. The requests come from software the visitor installed, running on whatever page they happen to be on. Your policy reporting them is the system working.
It is still worth knowing. An extension with permission to run on your pages can read what the visitor reads, and that includes everything behind their login. The site is fine; the session may not be.
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.
*.duertry.com*.everydaysi.com*.fivestat.com*.gadstat.com*.gresta.cloud*.hipodi.com*.junklip.com*.luselucky.com*.motramby.com*.nutrifunc.com*.paradosto.com*.singleview.site*.tstats.onlineoverbridgenet.comstatsdata.onlineObserved in Report URI report telemetry. 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