Catch Attacker Infrastructure Before It Goes Live: Feeding Newly Registered Domains into Suricata

Every malicious domain has a first day. Before it hosts a credential-harvesting page, before it becomes a malware command-and-control server, before it ever appears on a single blocklist, it is simply a name someone registered a few hours ago. That window, between registration and reputation, is where attackers do their best work, and it is exactly where most network defenses are blind.

This post is about closing that gap. We will look at why newly registered domains (NRDs) have become one of the most reliable early-warning signals in security operations, and then walk through a concrete, open-source way to act on that signal: piping the WhoisFreaks NRD feed directly into Suricata so your IDS tags any traffic touching a freshly registered domain, in real time, for your SIEM to correlate.

TL;DRMost malicious domains are used within hours or days of registration, well before they reach any blocklist.Domain age is a signal you can act on at registration time, earlier than reputation-based feeds.The open-source wf-suricata-nrd-feed integration loads the WhoisFreaks NRD list into Suricata as a dataset and tags matching DNS, TLS SNI, and HTTP Host traffic.It runs alert-only by default. Treat a match as a lead for SIEM correlation, not an automatic block.

The problem: reputation always arrives late

Traditional domain defenses are reactive by design. A domain has to do something bad, get observed doing it, get reported, get analyzed, and finally get added to a blocklist before it will ever be caught. Each of those steps takes time. Attackers have spent the last few years systematically engineering that time out of the equation.

The numbers are stark. According to Palo Alto Networks Unit 42, more than 70% of newly registered domains are classified as malicious, suspicious, or not safe for work, roughly 10 times the rate seen across Alexa's top 10,000 domains. This isn't a fringe statistic. It reflects a structural shift in how attacks are staged. The majority of phishing domains are maliciously registered, meaning created specifically for the attack rather than hijacked from a legitimate owner. Interisle's Phishing Landscape 2025 study found that 77% of all domain names used in phishing attacks were maliciously registered by cybercriminals, a 36% year-over-year increase in such registrations.

Speed is the whole game now. Generative AI has collapsed the effort required to stand up a convincing campaign. An attacker can register a fresh domain, spin up a credential-harvesting page with generative AI, and launch targeted ads within a few hours, even with minimal technical skill. IBM X-Force research found that generative AI can produce a convincing phishing email in about five minutes, work that takes an experienced human team roughly 16 hours.

The volume is climbing to match. Interisle's Cybercrime Supply Chain 2025 study analyzed more than 26 million unique cybercrime events involving malware, phishing, and spam, a 60% annual increase, and found that malicious domain registrations rose 149% year over year while bulk registration of domains for criminal purposes surged 177%. New generic top-level domains are disproportionately abused: though they hold only about 12% of the market, Interisle found they accounted for nearly half of all cybercrime domains reported and well over half of the maliciously registered cybercrime domains.

Put those trends together and the conclusion is uncomfortable but clear: when attackers can deploy new phishing infrastructure in minutes, traditional blocklist-based approaches simply cannot keep pace. By the time a malicious domain gets reported, analyzed, and added to a blocklist, the campaign may have already captured thousands of credentials and moved on to a fresh domain.

The signal: domain age as a zero-day indicator

If reputation arrives too late, what arrives on time? Registration itself.

The insight behind NRD monitoring is disarmingly simple: every malicious domain starts as a newly registered domain. That is what makes NRDs a powerful early-warning signal. Registration data lets security teams flag attacker infrastructure before it is weaponized in a campaign, and long before it surfaces in curated threat feeds.

Domain age is one of the very few signals available before a domain has any behavioral history at all. A domain registered three days ago has, by definition, no established track record, which is precisely why attackers rely on freshly minted infrastructure and precisely why its newness is worth flagging. Newly registered domains are, in effect, zero-day assets: they carry no historical telemetry and no reputation, which creates an exploitable gap for attackers to deploy phishing, malware delivery, and C2 infrastructure undetected.

Be clear about what this signal is and isn't. Domain age is probabilistic, not deterministic. Plenty of newly registered domains are perfectly legitimate: a startup launching, a marketing campaign spinning up, a company defensively registering brand variants. The newness signal on its own produces false positives, because legitimate new businesses and product launches create fresh domains every day. That is not a reason to discard it. It is a reason to use it correctly, as enrichment that raises the priority of an event and feeds correlation, rather than as a standalone verdict that blocks traffic outright.

This is also where NRD data complements, rather than duplicates, the telemetry you already have. DNS traffic in particular is famously underused. Most organizations collect DNS logs because the network requires them, but few analyze them for threats. A newly registered domain appearing in a DNS query is a natural pairing: the query tells you someone on your network is trying to reach this thing right now, and the NRD feed tells you this thing didn't exist last week. Together, that is a lead worth chasing.

The build: WhoisFreaks NRD feed to Suricata to SIEM

Suricata is a natural place to operationalize this. It already sees your DNS queries, TLS handshakes, and HTTP requests on the wire. What it doesn't have, out of the box, is knowledge of which domains are newly registered. The open-source wf-suricata-nrd-feed integration supplies exactly that missing piece.

The design goal is deliberately conservative: alert and tag, don't block. Given that domain age is a probabilistic signal, the integration ships in alert-only mode by default. Every match becomes a tagged event in Suricata's eve.json output, carrying tag: NRD and feed: whoisfreaks metadata, so your SIEM can correlate it against everything else it knows about that host and session. Nothing is dropped unless you explicitly opt into inline blocking later.

Here's how the pieces fit together.

Suricata datasets, in brief

Suricata supports a feature called datasets: large sets of values (strings, IPs, hashes) that rules can match against efficiently. Instead of writing one rule per domain, you load a single dataset of hundreds of thousands of domains and write three rules that check DNS queries, TLS SNI values, and HTTP Host headers against it. The integration ships exactly those three rules:

alert dns any any -> any any (msg:"NRD DNS QUERY - domain registered in WhoisFreaks NRD feed"; dns.query; dataset:isset,nrd_domains,type string,load /var/lib/suricata/data/nrd_domains.lst; ... sid:9000001;)

The dataset is defined inline in the rule itself using the load keyword, which points Suricata at an externally managed file it reads but doesn't own. That detail matters: it avoids colliding with the datasets: block that most suricata.yaml files already ship with, and it correctly models the fact that an external script, not Suricata, is what keeps the file up to date.

The sync pipeline

A daily scheduled job does the work of keeping that dataset current. Its logic, at a glance:

Check local cache for which day(s) in the retention window are missing
  -> fetch only the missing day(s) from the WhoisFreaks API
  -> save each day to its own cache file (gzip, plain domain list)
  -> expire cache files older than the retention window
  -> merge all cached days, dedup
  -> base64-encode, atomically write the Suricata dataset file
  -> reload Suricata (live socket reload, or service restart fallback)

A few of these choices are worth calling out, because they are what separate a script that works once from one that runs unattended for months:

Per-day caching, not full re-downloads. WhoisFreaks publishes the NRD feed as a daily snapshot per TLD group (gTLD and ccTLD). A naive implementation would re-download the entire rolling window every night: fourteen API calls a day for data that is six-sevenths unchanged. Instead, the integration caches each day's feed to its own file the first time it fetches it. A normal run only pulls the single new day (two calls); the first run backfills the whole window automatically. It is the difference between hammering the API and sipping from it.

A rolling retention window. How new is new enough? The integration defaults to a seven-day window, configurable via NRD_RETENTION_DAYS. This aligns with common practice: treat NRDs as elevated risk for a fixed window, because most legitimate sites are not operational the instant they are registered, and the highest-risk period is the first several days after registration. Cache files older than the window are automatically expired, so the dataset size stays bounded no matter how long the integration has been running.

Atomic writes everywhere. Every file the tool produces, each cache file and the final dataset, is written to a temporary file and then renamed into place. Renames are atomic on both Linux and Windows, which means Suricata (or you, mid-debug) never reads a half-written file during an update.

A hot reload, not a restart. After the dataset is refreshed, the integration tells Suricata to reload via its command socket, so detection picks up the new domains without dropping a single packet. If the socket isn't available, it falls back to a service restart.

Matching on three layers

Why check DNS, TLS SNI, and HTTP Host rather than just one? Because attackers don't always give you a clean DNS query to catch. Encrypted traffic, cached resolutions, and evasion techniques mean the same domain can surface at different layers. Checking all three (the DNS question, the TLS Server Name Indication in the handshake, and the HTTP Host header) gives you overlapping coverage. And because all three rules write the same tag: NRD metadata, your SIEM logic stays simple regardless of which layer caught the match.

What a detection actually looks like

When a monitored host queries a domain that's in the feed, Suricata emits a JSON event to eve.json. Stripped to the essentials, it looks like this:

{
  "event_type": "alert",
  "src_ip": "192.168.1.75",
  "dest_ip": "1.1.1.1",
  "proto": "UDP",
  "alert": {
    "signature": "NRD DNS QUERY - domain registered in WhoisFreaks NRD feed",
    "signature_id": 9000001,
    "metadata": {
      "feed": ["whoisfreaks"],
      "tag": ["NRD"]
    }
  },
  "dns": {
    "queries": [
      { "rrname": "0-ojnp3.garden", "rrtype": "A" }
    ]
  }
}

Everything a SOC needs is right there: the internal host that made the request, the domain it asked for, and the NRD tag that lets a SIEM rule pluck this event out of the millions of others and route it to an analyst, or better, correlate it automatically. Note the domain doesn't even need to resolve for this to fire; the outbound query is what the rule matches, which means you catch attempts to reach dead or parked infrastructure too.

Using it well: enrichment, not autopilot

The single most important thing to understand about NRD detection is that it is a lead, not a conviction. A match tells you someone on your network just talked to a domain that didn't exist a few days ago. That is genuinely valuable, but on its own it is not proof of compromise.

The mature way to use this signal is to fuse it with others. Security engineering guidance consistently recommends multi-signal scoring over any single indicator: combining domain age with WHOIS privacy status, DNS configuration, the reputation of the resolved IP, and TLD-specific abuse rates produces far fewer false alarms than domain age alone. In practice, that means using the NRD tag as a priority multiplier in your SIEM. An NRD hit on its own might be an informational event. An NRD hit from a host that also just triggered an EDR alert, or that is beaconing at regular intervals, or that resolved to a suspicious hosting range, that is an incident.

A few practical recommendations:

• Start in alert-only mode. Watch what fires for a week or two before you even think about blocking. You'll learn your own environment's baseline, which legitimate new domains your users touch, and can build allowlists accordingly.
• Tune the retention window to your risk tolerance. Seven days is a sensible default. A tighter window means fewer alerts and fewer false positives but a shorter catch radius; a wider one is the reverse.
• Correlate before you escalate. Route NRD-tagged events into a correlation rule rather than straight to a pager. The value compounds when combined with the rest of your telemetry.
• Consider blocking only for the highest-confidence cases. If you do move to inline blocking, scope it narrowly, for example to NRDs that also resolve to known-bad infrastructure, rather than blocking every newly registered domain wholesale, which risks collateral damage to legitimate new services.

Why this approach holds up

There's a reason to prefer a registration-based feed over trying to infer newness from your own traffic. Passive DNS, which watches for domains to start resolving, has an inherent lag: a domain can be registered and sit dormant for days before it provisions any DNS records, and passive observation misses domains that never resolve publicly at all. A dedicated NRD feed catches the domain at registration, the earliest possible moment. For continuous monitoring across an entire namespace, that is the right tool for the job.

The integration is intentionally boring in all the ways that matter for production: it is cross-platform (Linux and Windows), dependency-light (one Python package), idempotent, and honest about its own limitations in the documentation. It doesn't try to be a detection decision engine. It is a clean pipe that gets a high-quality signal to the place where you already make those decisions.

Getting started

The full integration is open source and MIT-licensed at github.com/WhoisFreaks/wf-suricata-nrd-feed. You'll need a WhoisFreaks account with NRD feed access for the API key, and a Suricata deployment (the repo includes a helper to install one on Linux). From there it is clone, drop in your API key, wire the rule into suricata.yaml, run the fetch script once, and schedule it. The README walks through each step, including the platform-specific gotchas.

Attackers have optimized for the gap between registration and reputation. This is a clear, transparent way to start watching that gap, so the next time a device on your network reaches for a domain that was registered this week, you hear about it.

Newly registered domain intelligence, WHOIS, DNS, and IP data are available through the WhoisFreaks API and downloadable feeds. Domain age is a probabilistic signal; treat NRD matches as enrichment for triage and validate false-positive rates against your own traffic before enabling any automated blocking.