Why blocklists are always one step behind

Malicious domain detection and investigation before blocklist enforcement
Photo of Kaveh Azarhoosh

Kaveh Azarhoosh

Community & Research Lead

March 2026

Why blocklists are always one step behind

You detect a malicious domain. You add it to your blocklist. Your threat intel feed picks it up, distributes it, and within hours thousands of firewalls are blocking it. That domain is done.

The attacker doesn't care. That domain was disposable. By the time it hit the feed, two more were already live and a third was warming up. Same registrar, same hosting, nearly identical DNS setup. The campaign didn't stop. It rotated.

This is how blocklist-based defence actually plays out. It works, but after the fact. Every indicator on every feed got there because someone was already a victim. The domain had to be used in an attack, reported, verified, and published before it could protect anyone else. That cycle takes hours at best. Often days.

Attackers provision infrastructure faster than that.

Twenty domains, one pattern

Think about how a phishing operation actually runs. The attacker registers a batch of lookalike domains. Twenty, thirty, sometimes more. They're not using them all at once. A few go live, they run until they get flagged, then the next batch activates.

But those twenty domains were registered through the same registrar, within the same 48-hour window, pointed at the same hosting, with DNS configurations that are nearly identical. They look obviously related if you can see the infrastructure underneath. Blocklists can't. They evaluate each domain on its own, as it gets reported. Domain one enters the feed on Monday. Domain seven might not show up until Thursday. Domains twelve through twenty may never get flagged at all.

The shared registrar, the timing, the overlapping infrastructure, none of that exists in blocklist data. Feeds carry labels, not context.

The wrong question

A blocklist answers one question: is this indicator known-bad? That's useful for enforcement. But if you're trying to get ahead of a campaign rather than chase it, you need a different question.

What does the domain's infrastructure neighbourhood look like? Who registered it, when, and what else did they register at the same time? Where is it hosted? What other domains share its IP, its nameserver, its certificate?

You can't answer any of that with a feed. Two domains can sit on the same server, registered by the same entity minutes apart, configured identically, and a blocklist will treat them as completely unrelated until both have been independently caught in the wild.

Structure over indicators

None of this means blocklists are broken. They're essential for real-time enforcement. But they work best as a starting point.

One confirmed malicious domain is a data point. Connect it to its registrar, its hosting, its DNS, the ASN it routes through, and it becomes the start of a map. Follow the connections and you find the other nineteen domains the attacker registered alongside it. Most of them won't be on any feed yet. Some may never be.

This is what Whisper does, it maps the structural relationships between domains, IPs, ASNs, DNS records, and hosting in a single queryable graph. Start from one confirmed domain, traverse the graph, find everything connected to it. Instead of waiting for each indicator to be independently flagged, you pull on one thread and the rest comes with it.

You can start with a free Whisper API key.

Gain the Whisper Advantage Today

Empower your security team with the predictive insights they need to stay ahead of threats.