The Gap Between Having a Blocklist and Actually Hunting With One
Most security teams treat IP blocklists as a passive control. They load a feed into their firewall or SIEM, set it to block or alert, and move on. The list updates automatically, alerts fire occasionally, and the team considers the job done. That approach leaves an enormous amount of threat intelligence sitting unused.
Blocklists, when used actively, tell you far more than whether a connection should be dropped. They reveal attacker infrastructure patterns, campaign timing, targeting priorities, and in many cases, early indicators of breaches that your endpoint tools have not yet detected. The difference between passive and active use is essentially the difference between a speed bump and a reconnaissance asset.
Recent incidents reinforce this point directly. The 0ktapus campaign, which compromised over 130 organizations through phishing and credential harvesting, relied on attacker-controlled infrastructure that appeared in threat feeds well before many targeted organizations noticed outbound connections to those endpoints. Teams that hunted their historical logs against updated blocklists after the campaign became public found evidence of staging activity they had missed entirely. Teams that only used blocklists as real-time filters found nothing retroactively, because the traffic had already happened and was already gone from active view.
What Blocklists Actually Contain and Why the Distinction Matters
Not all blocklists are equivalent. Understanding what a list actually contains changes how you use it operationally. The major categories break down as follows.
- Known malicious IPs: Addresses confirmed as command-and-control nodes, drop servers, or active attack sources. These are high-confidence but often short-lived, because adversaries rotate infrastructure quickly.
- Scanners and mass-exploit sources: IPs observed conducting automated vulnerability scanning, credential stuffing, or exploit delivery at scale. The WSzero DDoS family, now in its fourth version and using 21 known vulnerabilities for propagation, generates scanner traffic from a rotating pool of compromised hosts that appears consistently across these feeds.
- Abuse-reported IPs: Addresses flagged by network operators, honeypot operators, or automated abuse reporting systems. Quality varies significantly depending on the reporting source.
- Anonymization infrastructure: Tor exit nodes, known VPN egress points, and commercial proxy endpoints. These are not inherently malicious but indicate deliberate obfuscation.
- Phishing and malware hosting: IPs associated with hosting fake sites, malware payloads, or phishing landing pages. Recent campaigns targeting soccer fans with fake FIFA World Cup ticket and merchandise sites generated blocklist entries within hours of domain registration, giving defenders a narrow but real detection window.
Each category has different operational shelf life. C2 IPs might be valid for 24 to 72 hours. Scanner IPs tend to persist longer because the infrastructure behind them is often botnet-based and harder for operators to fully rotate. Phishing IPs can be active for days or weeks depending on how quickly hosting providers respond to abuse reports.
Building a Tiered Feed Architecture
Running a single blocklist and applying uniform action to everything on it creates both false positives and missed detections. A tiered approach gives you meaningful differentiation.
Tier 1: High-confidence, auto-block candidates. These feeds should have extremely low false positive rates, confirmed malicious attribution, and regular validation. Examples include Spamhaus DROP/EDROP, abuse.ch Feodo Tracker C2 endpoints, and threat intelligence feeds from your existing security vendor that carry confidence scores above a defined threshold. Traffic to or from Tier 1 addresses should be blocked automatically and generate high-priority alerts.
Tier 2: Alert and investigate. These feeds carry higher false positive potential but are operationally valuable. Commercial threat intelligence aggregators, OSINT feeds from reputable research sources, and honeypot-derived lists fall here. Instead of blocking, generate alerts that feed directly into your threat hunting queue. Analysts review these within a defined SLA, typically four to eight hours for business-critical assets.
Tier 3: Historical enrichment only. Some feeds are too noisy or too slow to be useful in real time but are valuable for retrospective analysis. You ingest these into your SIEM or data lake, use them to enrich log data after the fact, and query against them during active investigations. This is where a lot of the retroactive 0ktapus-style hunting happens.
Threat Hunting Workflows That Actually Use Blocklists Actively
The core shift from passive to active use comes down to running queries rather than waiting for alerts. The following workflows are concrete starting points.
Retroactive Log Enrichment
Pull your DNS query logs, proxy logs, and firewall connection logs for the past 30 to 90 days. Cross-reference the destination IPs against your current blocklist feeds. Any matches represent traffic that occurred before the IP was flagged or before you had the relevant feed loaded. This process surfaces historical compromises, staging activity, and early reconnaissance that passed through your environment undetected.
When the Akira ransomware kill chain is reconstructed from perimeter and endpoint logs, analysts consistently find that early external communication with infrastructure that later appeared on threat feeds was visible in firewall logs days before the encryption event. The data existed. The correlation just never happened in real time.
Frequency and Volume Analysis
A single connection to a blocklisted IP might be noise. Repeated connections, connections from multiple internal hosts, or high-volume data transfers to a flagged endpoint represent a different risk profile entirely. Pull connection data and group by destination IP, source host, byte counts, and connection frequency. Outliers in this analysis are high-value hunting leads.
Lateral Movement Correlation
Inbound connections from blocklisted IPs followed by rapid internal connection activity from the receiving host indicate potential compromise and lateral movement. Build a query that identifies hosts that received external connections from blocklisted sources and then initiated new connections to other internal systems within a defined time window, typically 15 to 60 minutes. This pattern appeared clearly in Webworm intrusion activity, where initial access from flagged infrastructure was followed by immediate internal reconnaissance using built-in Windows tooling.
Beaconing Detection Against Known C2 Ranges
Many C2 frameworks produce regular outbound connections at consistent intervals. When those destination IPs appear in threat feeds, the beaconing pattern becomes a high-confidence indicator. Query your proxy or firewall logs for connections to blocklisted IPs that occur at regular intervals across multiple hours or days. Intervals between 30 seconds and 10 minutes are common for commodity malware C2 communication.
Threat Hunting Checklist for IP Blocklist Operations
Use this checklist when establishing or auditing your blocklist-based threat hunting program.
- Inventory all current blocklist feeds, their update frequency, source reliability ratings, and where they are applied in your stack.
- Confirm that blocklist data is being ingested into your SIEM or data lake, not only into firewall or proxy controls, so retroactive queries are possible.
- Define confidence tiers for each feed and document what automated action, if any, applies to each tier.
- Schedule a recurring retroactive enrichment query against all connection and DNS logs using current blocklist data. Weekly at minimum, daily for high-risk environments.
- Build detection rules that fire on high-frequency or high-volume connections to Tier 1 and Tier 2 IPs, not only on single connection events.
- Create a process for analysts to submit newly identified IPs to internal blocklists during active investigations, so emerging threat infrastructure gets tracked immediately.
- Document feed overlap. Many commercial and open-source feeds share sources. Knowing which feeds are largely duplicates prevents false confidence in coverage breadth.
- Establish a deduplication and normalization pipeline so the same IP appearing across multiple feeds is treated as a single enriched indicator rather than multiple separate alerts.
- Test your hunting queries on known historical incidents in your environment to confirm that the logic would have caught them. If it would not, revise the query before relying on it operationally.
- Set expiration policies for blocklist entries. An IP flagged 18 months ago with no recent activity is not the same risk as one added last week. Treat age as a confidence modifier.
- Verify that blocklist feeds cover both IPv4 and IPv6 address space. IPv6 threat infrastructure is underrepresented in many feeds, and adversaries are beginning to exploit that gap.
Integrating Blocklists With Your Existing Stack
The practical integration points vary depending on your architecture, but the common insertion points each serve different purposes.
Firewall and NGFWs: Best suited for Tier 1 high-confidence blocking. Keep the block list small, validated, and current. Firewall performance degrades with very large IP sets depending on vendor and hardware, so resist the temptation to load every available feed directly into firewall policy.
DNS sinkholes: Particularly effective for catching malware that uses domain names to reach C2 infrastructure, since many blocklist feeds include associated hostnames. A sinkhole that logs attempted resolutions of malicious domains and then resolves to a controlled internal IP gives you both a blocking control and a detection mechanism. Hosts attempting to reach known C2 domains become visible immediately.
SIEM enrichment: This is where the full operational value of blocklists is realized. Ingest feed data as lookup tables or reference sets. Every log event that includes an IP field gets enriched at query time or ingestion time with blocklist status, feed source, and confidence tier. Analysts see context directly in alerts rather than needing to manually check each IP.
SOAR playbooks: Automate the initial enrichment steps for alerts generated by blocklist matches. When an alert fires on a Tier 2 IP, a playbook can automatically query additional OSINT sources, pull related connection history for the affected internal host, check whether the IP appears in multiple feeds, and generate a structured investigation package before a human analyst ever touches the case. This reduces mean time to investigate significantly.
The BTMOB Android malware service, which generates custom phishing payloads on demand, relies on hosting infrastructure that cycles through IP ranges frequently. Teams that integrate blocklist feeds directly into mobile device management and email gateway enrichment pipelines catch the outbound connections these payloads attempt before device-level indicators are available.
Common Implementation Pitfalls
Several failure patterns appear consistently across organizations that deploy blocklist-based hunting programs.
Feed staleness without operational awareness: A blocklist feed that stopped updating three weeks ago because the source API changed an authentication requirement looks identical to an active feed in most dashboards. Build monitoring that alerts when a feed has not received new entries within its expected update window. Stale feeds create false confidence.
Treating all blocklist hits as equal severity: A connection from an IP that appeared on a single low-confidence abuse report feed three months ago does not carry the same weight as a connection to an active Feodo Tracker C2 endpoint. Without tiering and confidence scoring, analysts either overreact to low-confidence hits or begin ignoring alerts entirely because too many turn out to be false positives. Both outcomes degrade the program.
Blocking without logging: When traffic to a blocklisted IP is silently dropped without generating a log entry that feeds into your SIEM, you lose the detection and hunting value entirely. The block happens, but no one ever reviews the pattern or investigates the internal host that attempted the connection. Always log blocked traffic from high-confidence feeds, with enough detail to support investigation.
Ignoring internal-to-blocklisted-IP traffic in favor of inbound-only focus: Most teams focus on blocking inbound connections from bad IPs. The higher-value detection signal is often outbound connections from internal hosts to blocklisted destinations, because those connections frequently indicate already-compromised systems attempting to reach attacker infrastructure. Reorient hunting queries to prioritize outbound connection matching.
Feed source monoculture: Relying on a single commercial feed or a single open-source aggregator creates coverage gaps. Adversaries developing infrastructure for targeted campaigns often avoid IPs that appear on the most commonly used feeds. Diversifying sources across commercial, community, government-shared, and honeypot-derived feeds improves coverage without proportionally increasing operational burden.
No feedback loop into feed quality assessment: When a blocklist-generated alert turns out to be a false positive or a true positive, that outcome should feed back into how you weight that feed. Feeds that consistently produce actionable detections deserve higher confidence ratings. Feeds with high false positive rates get demoted or scoped more narrowly. Without this feedback loop, feed quality degrades silently over time.
Operationalizing the Intelligence Over Time
The organizations that extract the most value from IP blocklists treat them as living intelligence assets rather than static configuration. That means analysts are contributing new indicators based on their investigations, feeds are being evaluated quarterly, hunting queries are being refined based on real detections, and the blocklist program is connected to incident response so that IPs identified during investigations are immediately looped back into detection.
As threat actors become more sophisticated about rotating infrastructure, avoiding commonly blocked IP ranges, and using residential proxy networks to blend traffic, the raw blocking value of IP blocklists decreases. But the hunting and enrichment value remains high, because even infrastructure designed to avoid detection leaves traces when you look back across large volumes of historical log data with current intelligence applied.
The goal is to move from a posture where blocklists catch threats in real time to one where they anchor a continuous retroactive hunting cycle that surfaces what real-time detection missed. That shift turns a passive control into one of the more productive components of a mature threat detection program.
