On a Tuesday morning in early September 2026, a regional hospital SOC blocked an outbound-looking connection attempt against its Citrix NetScaler management path. The source IP sat on a freshly updated exploit-scanner list that had begun circulating after public reporting that a critical NetScaler auth bypass was already being leveraged in the wild. The firewall rule fired. The ticket closed as “blocked, no further action.”
Two days later, incident response found the same /24 had probed the appliance nine times across the prior week, including three successful authentication-adjacent requests that never matched a live blocklist entry at the time. The list catch felt like containment. The useful hunting window had already closed on the earlier, unlabeled traffic.
That pattern is common when teams treat blocklist hits as the start of enforcement and the end of investigation. For threat hunting, the listing date is often a late signal. The practical question is how far back you replay your own telemetry once an address finally appears on a trusted feed.
Why listing lag turns a block into a blind spot
Public IP blocklists aggregate observations from honeypots, sinkholes, shared telemetry, and commercial sensors. Guest diaries and operator write-ups, including recent honeypot batching work discussed in community forums around early September 2026, show how scanner campaigns get packaged into shareable lists only after enough sensors agree the traffic is hostile.
That aggregation delay creates a predictable gap:
- Day 0–2: opportunistic scanners hit newly disclosed or newly weaponized surfaces (NetScaler, VPN portals, exposed admin paths).
- Day 2–5: enough honeypots and shared sensors classify the sources.
- Day 5+: your edge feed updates and your deny rule starts matching.
If your playbook only inspects the moment of the match, you miss the pre-list contacts that already touched the same asset class. Threat hunting with blocklists starts by treating the hit as a pivot key for historical search, not as a one-line deny event.
A concrete replay window that most teams can run
When a newly listed IP (or a small set of related addresses) hits your environment, open three concurrent queries rather than a single “was this blocked?” check.
1. Exact-IP retrospective
Search firewall, WAF, reverse proxy, VPN, and IdP logs for the source IP across a fixed lookback. For exploit-scanner categories tied to active CVE exploitation, start at 14 days. For long-lived malware C2 or spam-abuse categories, start at 7 days and expand only if you find contact.
Capture for each hit: timestamp, destination host, destination port, URI or service name, response code, bytes transferred, and authenticated identity if any. Sort chronologically. The first successful or anomalous response is your candidate “patient zero” contact, not the blocklist match time.
2. Neighborhood and infrastructure pivot
Expand one hop without boiling the ocean. Query the same /24 for identical destination paths and user-agents within the same lookback. Limit to the ports and paths that matter for the campaign you care about (for example, NetScaler management URIs, not every HTTPS GET on the CDN).
This catches rotating sources that share hosting with the listed address. It differs from ASN-wide filtering: you are hunting for behavioral twins of a known bad IP, not applying a permanent network policy based on the ASN.
3. Outbound and lateral follow-through
If the listed IP ever reached an internal system, or if an internal host later connected to that IP or its neighbors, run host-level hunting: process creation around the contact time, new scheduled tasks, unusual DNS, and unusual service account use. Egress matches against scanner or C2 lists deserve the same replay discipline as ingress hits.
How to score a hit before you burn analyst hours
Not every blocklist match deserves a 14-day SIEM marathon. Score quickly, then deepen.
- Asset criticality: management interfaces, identity providers, and remote-access appliances outrank marketing sites.
- List category fidelity: “exploit scanner” or “known C2” justifies deeper replay than generic “suspicious” or bulk spam tags.
- Response shape: 401/403 storms differ from 200s with unusual body sizes or successful auth events.
- Recency of the vulnerability: when vendors and agencies are reporting active exploitation of a specific product, raise priority for any listed IP that touched that product class.
- Feed freshness relative to first contact: if your first log hit predates the list’s “first seen” field by days, treat that as a strong hunt trigger.
A practical triage rule many SOCs can adopt: any listed exploit-scanner IP that contacted a remote-access or edge-management surface gets a mandatory historical replay; generic web scrapers hitting public content get an automated enrichment note and a short retention of context without a full hunt.
Implementation details that keep the hunt honest
Wire the workflow into tools you already run.
- Ingest list metadata: store source feed name, category, confidence, and first-seen/last-seen timestamps beside the IP. Without first-seen, you cannot measure lag against your own logs.
- Preserve pre-block telemetry: ensure deny actions still log the original request line. Silent drops starve retrospective hunting.
- Automate the first pass: on new list membership for IPs that appeared in your logs in the prior 14 days, open a case with the chronological contact table pre-filled.
- Separate enforce from investigate: keep the block in place while the hunt runs. Enforcement and hunting are parallel tracks.
- Document false-positive cost: shared cloud exits and carrier NAT produce noisy lists. Require a second signal (path, payload fingerprint, repeated timing) before you expand from IP hunt to host isolation.
Tradeoffs and caveats
Longer replay windows raise storage and query cost. Fourteen days of full-packet or verbose proxy logs is expensive; many teams keep high-fidelity logs for edge management paths and thinner summaries for bulk web traffic. That asymmetry is acceptable if your highest-value assets keep the deep history.
Blocklists disagree. One feed may tag an address as a scanner while another still shows it clean. Prefer the more specific category from the feed with better historical precision for your sector, and record which feed drove the hunt so you can measure later which sources produce useful cases.
Neighborhood pivots can explode. Cap /24 expansion with destination filters and time boxes. If more than a handful of neighbors show identical probe patterns, escalate to a campaign case instead of opening one ticket per IP.
Timely news cycles, from ISC Stormcast briefings to active exploitation notes on appliances like NetScaler, should shorten your default lookback for the affected product class, not widen every hunt globally. Scope the urgency to the surfaces under active attack.
A short playbook you can run this week
- Pick one high-signal feed category (exploit scanners targeting remote access).
- For every match in the last 30 days against management or VPN paths, replay 14 days of logs for that IP.
- Build a one-page timeline template: first contact, response codes, related /24 twins, host follow-up yes/no.
- Measure how often first contact predates list first-seen. That ratio tells you whether your hunting window is sized correctly.
- Tune lookback down only after you see that ratio stay near zero for several weeks.
Threat hunting with IP blocklists pays off when the list entry becomes a time machine into your own telemetry. The block stops the next packet. The replay tells you whether the campaign already learned something about your perimeter while the address still looked clean.
