Attackers who generate a new subdomain for every victim, so blocking the host you saw yesterday achieves nothing today.
Published 23 July 2026
Updated 24 August 2026
Some of the hosts we track do not look like anything a person chose. 0a493bc161019.beer.
4f852800cedaf3ec.com. bsvrrkmpnyyyprmsnynnfrstlar.info. They are generated, and the domain is
only half the story: underneath each one sits a stream of subdomains that changes faster than anyone
can write rules for.
The instinct on seeing a hostile host in your reports is to block that host. It is the right instinct and against this pattern it accomplishes almost nothing.
Consider the sequence. The skimmer connects to a generated subdomain. It appears in your reports. A human reads it, decides it is hostile, and adds it to a policy or a blocklist. That change gets reviewed and deployed.
By then the campaign has moved. Not because the attacker noticed you — because it was always going to move, on a schedule that has nothing to do with your response. Every entry added this way is an accurate record of where the attack used to be, and a policy accumulating them looks like diligence while blocking nothing.
The subdomains are free and infinite. The registered domain is neither: somebody paid for it, with a registrar, and replacing it costs time and money and leaves a trail.
So the domain is the durable thing to match, and matching it means covering everything beneath it. We
write those entries with a leading *. — the domain itself and every subdomain under it, however
many there turn out to be, including the ones that do not exist yet.
That last part is the whole point. The next subdomain in the rotation is matched before it has been generated, which is the only way to stop being a step behind.
Covering a whole domain is a decision that can go wrong in a way an exact-host block cannot, so we only make it in one situation: the attacker registered the domain themselves.
Those are recognisable. A generated name on a cheap top-level domain, registered days before it started serving, with nothing else beneath it. There is no innocent host under a domain like that, because there is nobody else using it.
The opposite case is a legitimate site that has been compromised. Its subdomains belong to a real business, that business will clean up, and covering the whole domain would take out services with nothing to do with the attack. We stay narrow there, and accept that we will have to add hosts as we see them.
The signal is the shape of the name and the shape of the traffic together.
A hostname that reads as machine-generated — long hex strings, consonant runs, no pronounceable words — is worth attention on its own. But the stronger signal is a series of them: several different subdomains under one domain, appearing in your reports across days, each seen once or twice. One odd hostname is ambiguous. A rotation is not.
If you are keeping a manual blocklist and find yourself adding a third or fourth host under the same registered domain, that is the moment to stop adding hosts and cover the domain.
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.
*.0a493bc161019.beer*.4f852800cedaf3ec.com*.bsvrrkmpnyyyprmsnynnfrstlar.infoObserved 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