Security teams buy IP blocklists to stop traffic. The higher-value use is quieter: treating every high-confidence match as a hunt seed that explains why that address showed up, what it touched before the deny fired, and whether siblings of that infrastructure are already inside your estate.
That shift matters more in September 2026 than it did a year ago. Critical Citrix NetScaler authentication bypasses are already being leveraged in live attacks, honeypot operators continue to publish dense login and scanner telemetry (including recent guest diaries covering Honeypot-Omaha and batch-driven probing), and credential and identity abuse campaigns keep rotating through fresh cloud exits. A blocklist hit under those conditions is rarely a closed ticket. It is the first breadcrumb.
Where the deny-first habit comes from
Blocklists entered most stacks as firewall objects, WAF IP sets, and email gateway deny tables. Ops measured success as packets dropped and tickets closed. Hunting teams inherited the same artifact and kept the same mental model: match equals malicious, action equals block, done.
That model fails for three operational reasons.
- Coverage lag. Extortion and scanning crews often appear first on someone else's honeynet or shared feed hours after they probed you. Your deny rule arrives late; your logs already hold the earlier contacts.
- Shared infrastructure. Cloud, CDN, and residential-proxy ranges recycle. A blocklist label on an address describes prior abuse somewhere else. Your question is whether that same exit touched admin paths, VPN portals, or Citrix gateways in your window.
- List hygiene noise. Aggressive feeds flag scanners, researchers, and misclassified NAT. Blind blocking creates outages; blind ignore creates misses. Hunting sits between those failure modes.
Teams that only automate deny miss the correlated activity that never matched a list: the same user-agent family from adjacent /24s, the same URI sequence against NetScaler or Teams edge services, or the same failed-auth cadence that appeared one hop before the listed IP.
Reframe the blocklist as a hunt trigger
Operationally, a blocklist is a prioritized query index over your telemetry, not a verdict. When an address lands on a trusted feed, ask three questions in order:
- Did this IP (or its immediate neighbors) already appear in our authentication, VPN, WAF, or honeypot logs in the last 7–30 days?
- What exact services, paths, and identities did those sessions touch?
- Which related indicators (adjacent IPs, JA3/JA4, user-agents, URI patterns, ASN + path combo) should we hunt even if they are not listed yet?
Those questions turn a static deny into a short investigation that either confirms a clean drop or expands into lateral scoping.
A pragmatic playbook your SOC can run this week
1. Tier the lists before you tier the response
Not every feed deserves the same hunt urgency. Split sources into three operational tiers and bind playbooks to the tier, not to a single reputation score.
- Tier A — high trust, low volume: curated CISA/sector ISAC indicators, vendor lists tied to named campaigns (for example, exploitation of a disclosed NetScaler auth bypass), and IPs your own honeypots observed attacking production-like decoys.
- Tier B — medium trust, high volume: community scanner and abuse lists. Useful for enrichment and clustering, weaker as sole deny authority.
- Tier C — noisy / research: broad "suspicious" ranges. Enrich only; do not auto-page.
Tier A matches get a 30–60 minute hunt window even when the packet was already dropped. Tier B matches batch into daily cluster reviews. Tier C feeds dashboards, not pages.
2. Pivot from IP to session story
For each Tier A hit, pull a fixed evidence pack from the SIEM before anyone debates block duration:
- First-seen and last-seen across firewall, reverse proxy, IdP, VPN, and mail edge
- HTTP methods and paths (especially management and auth endpoints)
- Auth outcomes: success, MFA fail, password spray cadence, impossible travel flags
- TLS fingerprint and user-agent consistency across related IPs
- Whether the same source hit decoy/honeypot listeners you control
Recent honeypot write-ups that walk batch-driven probing illustrate why that last bullet matters: decoy telemetry often shows the pre-blocklist phase of a campaign. If your production logs and honeypot logs share URI and timing patterns with a newly listed IP, treat the campaign as active against you even when only one address is listed.
3. Expand one hop, then stop
Unbounded pivots burn analyst time. Cap expansion:
- Same /24 or cloud project only when path and fingerprint align
- Same ASN only when combined with a rare URI or exploit path (NetScaler management paths, VPN web portals, IdP authorize endpoints)
- Same credential or username across rotating source IPs when auth logs show spray behavior
Document the stop condition in the ticket. Hunting with blocklists fails when every match becomes an open-ended OSINT rabbit hole.
4. Separate containment from intelligence actions
Run two tracks in parallel so neither starves the other.
Containment track: temporary deny or challenge at the edge for the matched IP; tighten controls on the touched service (Citrix/NetScaler, VPN, Teams edge exposure); reset or step-up auth for any accounts that saw successful logons from related infrastructure.
Intelligence track: tag the campaign cluster, push sibling indicators into detection content (not only into deny lists), and share a short internal note: services touched, time window, confidence, and what would falsify the hypothesis.
Voice-phishing activity against Microsoft Teams and similar collaboration surfaces is a reminder that the follow-on stage may be identity abuse rather than more scanning. An IP blocklist match on a gateway can be the network foreshadow of a social-engineering wave aimed at the same tenant.
5. Measure hunt yield, not only block volume
Track metrics that prove the hunting use case:
- Percent of Tier A matches with prior unseen log presence ("list lagged our exposure")
- Number of sibling IPs or patterns promoted to detection rules per week
- False-positive rate by feed tier after analyst review
- Mean time from match to evidence pack completion
If block volume rises while hunt yield stays flat, you are still using lists as switches.
A concrete scenario
Tuesday morning, your edge firewall logs a deny for 203.0.113.44 against the corporate NetScaler gateway. The address landed on a Tier A vendor list tied to active exploitation of a critical auth bypass.
The deny-first team closes the alert. The hunt-first team pulls seven days of gateway, WAF, and IdP logs and finds that 203.0.113.44 probed /logon/LogonPoint/ twice on Sunday with a distinctive TLS fingerprint, then stopped. Three other addresses in a neighboring cloud subnet used the same fingerprint and path on Monday. One of those produced a successful authentication for a service account that rarely signs in from that region.
Actions follow the evidence: contain the four addresses, force step-up and credential rotation for the service account, add a detection for the fingerprint plus NetScaler logon path regardless of list membership, and schedule a configuration review for the gateway patch and auth posture. The original blocklist match was useful because it started that chain, not because the packet drop was the whole story.
Implementation details that keep this sustainable
Wire blocklist matches into the SIEM as enrichments with feed name, tier, first-seen on feed, and confidence. Create a single saved hunt named for the tier (for example, "TierA-IP-Hunt-Pack") that analysts clone rather than reinvent. Keep allowlists for critical SaaS and partner egress explicit and reviewed monthly so hunting does not collide with business traffic. Expire automated denials on a timer unless a hunt promotes them to longer containment.
Where you operate honeypots, feed their attacker IPs into Tier A only after a minimum interaction threshold (authenticated attempt, exploit payload, or repeated admin-path hits). That keeps your highest-urgency list tied to behavior you observed, which is the strongest bridge between open abuse news and your own perimeter.
Takeaways you can hand to the on-call lead
- Treat trusted blocklist matches as hunt seeds with a fixed evidence pack, especially during active exploitation waves such as NetScaler auth bypass abuse.
- Tier feeds so urgency matches trust; stop paging on noisy lists.
- Pivot one hop using path, fingerprint, and identity context, then stop.
- Run containment and intelligence as parallel tracks with different outputs.
- Score success by prior-log discoveries and detections promoted, not by denies alone.
IP blocklists still belong in enforcement. The teams that get ahead of rotating abuse infrastructure are the ones that also let every serious match open a short, disciplined hunt before the ticket dies in the deny log.
