The Gap Between Having a Blocklist and Actually Using One
Most security teams have IP blocklists deployed somewhere in their stack. They're fed into firewalls, loaded into SIEMs, and referenced by threat intelligence platforms. The problem is that the majority of these lists are used passively: traffic gets dropped at the perimeter, a counter increments, and nobody looks twice. That passive posture is exactly where threat actors have learned to exploit the seams.
Threat hunting with IP blocklists is a fundamentally different discipline. Instead of treating a blocklist as a final verdict, you treat it as a starting point for investigation. A matched IP is a signal, not a closed case. The distinction matters enormously when you consider that sophisticated threat groups like the 0ktapus actors, who compromised more than 130 organizations through targeted phishing and credential harvesting campaigns, routinely rotate infrastructure fast enough to stay ahead of any static list. Passive blocking catches the slow movers. Active hunting catches the ones operating at scale.
Understanding What Blocklists Actually Contain
Before you can hunt with blocklists, you need a clear picture of what you're actually working with. IP blocklists vary enormously in composition, freshness, and signal quality. Treating them as interchangeable is one of the most common mistakes operators make.
Feed Categories and Their Operational Value
Commercial threat intelligence feeds typically aggregate data from sinkholes, honeypots, passive DNS, and sandboxes. They tend to have broader coverage and faster refresh cycles, but they also carry more noise, particularly around shared hosting and cloud provider ranges that serve both legitimate and malicious traffic.
Open-source feeds like Emerging Threats, Spamhaus DROP, and the Abuse.ch Feodo Tracker are narrower in scope but often highly accurate within their domain. The Feodo Tracker, for example, focuses specifically on botnet C2 infrastructure. When the WSzero DDoS family recently reached its fourth version and expanded its propagation across 21 different vulnerabilities, the associated C2 infrastructure showed up in Feodo and similar feeds within hours of analysis. Teams that were actively hunting against those feeds detected lateral movement indicators before automated blocking rules had fully propagated.
Government and sector-specific feeds, such as those distributed through ISACs, carry high-confidence indicators tied to specific campaigns. These are often lower volume but extremely high value, particularly for critical infrastructure operators.
Reputation databases aggregated from SMTP abuse reports, web crawlers, and ad fraud systems contain huge volumes of IPs, but the signal relevance for network intrusion hunting is mixed. An IP that spammed 10,000 inboxes may or may not be the same one probing your VPN concentrator.
Freshness and Decay
IP indicators have a half-life. Residential proxies and VPN exit nodes rotate constantly. Cloud infrastructure gets provisioned, used for a campaign, and released back into the pool within hours. The Akira ransomware kill chain reconstructed from perimeter and endpoint logs in recent forensic reporting showed initial access originating from IPs that had appeared in threat feeds 14 days earlier and had since been recycled to a legitimate cloud tenant. Teams relying on static snapshots of blocklists missed the context entirely.
Understanding decay means tagging your blocklist indicators with first-seen and last-seen timestamps and factoring that into your hunting logic. An IP seen in a feed 90 days ago and never since deserves different treatment than one that appeared yesterday and is still active.
Building the Hunting Workflow: What to Do Today
If you're starting from a posture where blocklists are purely passive enforcement mechanisms, the first step is making your existing data queryable in the context of your internal telemetry. This doesn't require new tools. It requires data normalization and a clear process.
Enrich Your Firewall Deny Logs
Pull the last 30 days of firewall deny logs for traffic matching your current blocklist feeds. Segment them by source IP and count unique destination ports, destination hosts, and time-of-day patterns. IPs that generate dense, varied deny events across multiple internal destinations are worth examining as potential persistence or reconnaissance activity that partially succeeded before being caught.
Focus on IPs that appear in your deny logs and also appear in your allow logs, even briefly. Cloud environments with dynamic routing, split-tunnel VPNs, and load balancers regularly create windows where the same IP hits a denied path and an allowed path within the same session window. That's where the Akira-style initial access patterns hide.
Cross-Reference Authentication Logs
The 0ktapus campaign succeeded in part because authentication events originating from known-bad infrastructure were not being correlated with the IP intelligence available at the time. Operators who ingested threat feed data into their SIEM but didn't build correlation rules between successful authentications and blocklist hits missed the breach entirely until after the fact.
Build a query that surfaces any successful authentication event in the past 30 days where the source IP appears in any of your current threat feeds, even feeds focused on categories that seem unrelated, such as spam or ad fraud. Attackers reuse infrastructure across campaigns. An IP that appears in an ad fraud database today may have been used for credential stuffing last month.
Tag, Don't Just Block
For a subset of your lower-confidence blocklist feeds, switch from a drop policy to a tag-and-log policy. This gives you visibility into traffic that would otherwise vanish from your logs. Dropped packets generate a deny event. Tagged-and-logged packets generate a full session record. That record tells you where the traffic was going, what it looked like, and whether there's a pattern worth investigating.
Implement this selectively. High-confidence feeds covering active C2 infrastructure and known malware distribution should remain hard blocks. Lower-confidence reputation feeds and geographic enrichment feeds are better candidates for tagging.
Structuring Your Hunt: What to Build This Week
With queryable data and enriched logs in place, the next phase is constructing structured hunts that move beyond simple IOC matching.
Cluster by Infrastructure, Not Individual IPs
Sophisticated threat actors don't operate from single IPs. They operate from infrastructure clusters: ASNs, hosting providers, geographic regions, or specific netblocks that appear across multiple campaigns. The Webworm group, observed using new burrowing techniques to maintain persistence in compromised environments, rotated through a relatively small set of hosting providers even as individual IPs changed. Teams that pivoted from individual IP matches to ASN-level and netblock-level analysis identified the pattern days faster.
When a blocklist hit surfaces an IP, immediately pull the /24 or /16 containing that IP and query your logs for any traffic to or from that range over the past 90 days. Look for low-and-slow patterns, repeated connection attempts, or beaconing behavior that wouldn't trigger a blocklist match on its own but becomes visible in the context of the broader range.
Build Temporal Correlation Rules
Threat actors who are aware of blocklist feeds often time their activity to exploit the delay between indicator publication and defender ingestion. The typical lag between a new C2 IP appearing in open-source feeds and that IP being blocked at enterprise firewalls ranges from 12 to 48 hours, depending on feed subscription tier and update frequency.
Build SIEM rules that look backward when a new blocklist indicator is ingested. When a fresh IOC hits your platform, automatically query the previous 72 hours of logs for any traffic involving that IP. This retroactive sweep catches the initial access or reconnaissance phase that occurred before the indicator was available.
Prioritize by Behavioral Context
A blocklist hit in isolation tells you very little. A blocklist hit combined with specific behavioral signals tells you a great deal. Develop a prioritization matrix that scores blocklist hits based on accompanying context.
- High priority: Blocklist hit on a successful authentication event, followed by outbound data transfer within 60 minutes.
- High priority: Blocklist hit on a source IP that also appears in DNS queries for internal hostnames not exposed externally.
- Medium priority: Blocklist hit on an IP scanning multiple internal hosts across different subnets within a 10-minute window.
- Medium priority: Blocklist hit on a known Tor exit node or commercial VPN range making API calls to sensitive internal services.
- Low priority: Blocklist hit on a single denied connection with no correlated internal activity.
This prioritization keeps your hunting team focused on signals that require investigation rather than noise that can be handled by automated blocking.
Operationalizing at Scale: This Quarter's Roadmap
Short-term hunting produces immediate value. Long-term operationalization is what sustains that value when team capacity is constrained and threat volume increases.
Feed Hygiene and Consolidation
Many organizations accumulate blocklist feeds over time without ever retiring outdated or low-value sources. The result is a bloated feed inventory that generates false positives, consumes analyst bandwidth, and creates latency in blocking updates. Conduct a feed audit that measures each source against hit rate on confirmed malicious activity, false positive rate against baseline internal traffic, average indicator age at time of ingestion, and overlap with higher-quality feeds you're already running.
Cut feeds that score poorly across these dimensions. Fewer, higher-quality feeds with faster refresh cycles outperform large aggregated lists in both blocking effectiveness and hunting signal quality.
Automate Indicator Lifecycle Management
Manual feed management doesn't scale. Build automated processes that ingest new indicators with timestamps, apply confidence scoring based on feed source and corroborating evidence, age out indicators past a defined decay threshold unless corroborated by internal activity, and escalate aged indicators that still appear in internal logs.
Platforms like MISP, OpenCTI, and commercial TIP solutions handle most of this workflow natively. The key is configuring decay rules that match your threat model rather than accepting vendor defaults.
Integrate with Endpoint Telemetry
Network-layer blocklist hunting is limited by what network sensors can see. When attackers use encrypted channels, residential proxies, or compromised internal hosts as pivot points, network-level IP matching becomes unreliable. Endpoint telemetry closes this gap.
When the BTMOB Android malware service generates custom phishing payloads targeting users in an organization, the initial contact often happens on personal devices outside network visibility. But when those credentials get used against corporate systems, the authentication event and subsequent internal pivoting appear in endpoint logs. Correlating blocklist hits against EDR process network connection logs, rather than just firewall logs, surfaces attack chains that remain invisible at the perimeter.
Configure your EDR platform to alert when any process establishes a network connection to an IP appearing in high-confidence threat feeds. This catches post-exploitation C2 beaconing even when the initial entry point was a clean IP that bypassed perimeter controls.
Create Hunting Runbooks for Common Patterns
Documented runbooks reduce the time from alert to investigation and ensure consistency across analysts with different experience levels. Build runbooks for the patterns your environment sees most frequently.
A basic blocklist hunting runbook should cover: initial triage steps to assess whether a hit represents active intrusion or reconnaissance, pivot queries to run against adjacent log sources, escalation criteria for moving from analyst investigation to incident response, and documentation requirements for capturing hunting findings regardless of outcome.
The findings from negative hunts, where investigation reveals no compromise, are just as operationally valuable as confirmed incidents. They tell you which blocklist feeds are generating noise for your environment and which behavioral context combinations are reliable indicators of actual activity.
When Blocklists Are Being Used Against You
A threat hunting program focused entirely on defending against blocklisted IPs will miss actors who have learned to exploit blocklist gaps as an evasion technique. This is a real and growing operational challenge.
Attackers who are aware of major open-source threat feeds will test their infrastructure against those feeds before launching campaigns. If their IPs don't appear in common blocklists, they have reasonable confidence that perimeter controls won't stop them. The fake FIFA ticket websites targeting World Cup fans this year consistently used freshly registered domains and clean IPs specifically because the operators knew that reputation-based filtering relies on historical data.
Counter this by hunting on behavioral signals independent of IP reputation. New IPs making their first appearance in your environment deserve scrutiny regardless of whether they appear in any feed. A source IP with no history in your environment that immediately begins scanning internal ranges, making authentication attempts across multiple accounts, or generating unusual volumes of API calls is worth investigating whether or not a threat feed has flagged it.
Combine blocklist-based hunting with first-seen IP analysis, user-agent anomaly detection, and behavioral baselining to build a detection layer that doesn't rely entirely on indicator databases that attackers can preemptively test against.
Measuring Whether Any of This Is Working
Threat hunting programs without measurement frameworks tend to drift toward reactive postures over time. Define metrics that reflect actual hunting effectiveness rather than just activity volume.
Track mean time from indicator ingestion to retroactive log sweep completion, the ratio of blocklist hits that escalate to confirmed investigations versus those resolved as noise, the percentage of confirmed intrusions where a blocklist indicator was available in the feed environment before detection, and the number of new infrastructure clusters identified through pivot analysis on individual blocklist hits.
The third metric is the most critical. If blocklist indicators were present and available before detection in a significant percentage of confirmed incidents, your correlation and triage processes need work. If that number is low, your hunting program is operating effectively and your gaps lie elsewhere.
Threat hunting with IP blocklists is neither glamorous nor technically complex in its fundamentals. What makes it effective is the discipline of treating every blocklist hit as a question rather than an answer, building the data infrastructure to investigate that question quickly, and maintaining the operational rigor to do it consistently at scale.
