When the Blocklist Was Right but the Hunt Came Too Late
A mid-sized financial services firm running a standard perimeter stack had blocklists deployed across their firewall, their SIEM, and their email gateway. The lists were updated weekly through a commercial threat intelligence subscription. On a Tuesday afternoon, a server in their environment started making outbound connections to an IP that had been flagged as a known command-and-control node three days earlier. The blocklist on the firewall blocked egress traffic. The SIEM generated an alert. The alert sat in a queue for six hours.
By the time an analyst reviewed it, the infected endpoint had already exfiltrated staged data through a secondary channel using a different IP that was not yet listed anywhere. The blocklist did exactly what it was configured to do. The problem was that nobody had built a process around what a blocked connection actually means as an intelligence artifact. The block was the beginning of an investigation, and the team treated it as the end of one.
This scenario plays out across organizations of every size. Blocklists are commonly deployed as passive filters, and the rich behavioral signal they generate goes largely unexamined. Shifting that mental model, from blocklist-as-barrier to blocklist-as-tripwire, is where threat hunting with IP data becomes genuinely useful.
What Blocked Traffic Is Actually Telling You
Every time your infrastructure blocks a connection attempt to or from a listed IP, that event carries contextual information that most teams discard. The source or destination IP, the internal host involved, the protocol, the port, the time, and the frequency of attempts all contribute to a picture of what is happening inside your environment.
A single block event is low value. A pattern of block events is a different matter entirely. Consider these scenarios:
- An internal workstation generates five blocked outbound connections to known malware distribution IPs over a 48-hour window. Each block is treated as a resolved event. Nobody correlates them. The workstation is likely compromised and beaconing.
- Twelve different internal hosts all generate blocked connections to the same external IP within a six-hour window. This is a lateral movement or worm propagation pattern. The external IP may be irrelevant; the internal spread is what matters.
- A server that should have no external communication generates repeated blocked connection attempts to IPs associated with a specific threat actor's infrastructure. This indicates something running on that server is attempting to phone home.
None of these patterns are visible if you treat blocked events as closed tickets. They become visible the moment you start aggregating and correlating blocklist hit data the same way you would analyze any other behavioral log.
Building the Data Pipeline That Makes Hunting Possible
The infrastructure requirement for blocklist-driven threat hunting is relatively straightforward, but the implementation details matter significantly. Your goal is to get blocklist hit events into a queryable data store where you can run time-series analysis and cross-reference with other log sources.
Start with log completeness. Firewalls, proxies, and endpoint security tools all generate block events, but they often log different fields. Establish a normalized schema that captures at minimum: timestamp, source IP, destination IP, source port, destination port, protocol, the specific blocklist that matched, the internal hostname or asset identifier, and the direction of the connection attempt. Without the internal asset identifier, you cannot connect blocked events to your asset inventory, which is where the hunting value lives.
Route these events to your SIEM with a separate index or data stream if your platform supports it. Blocklist events tend to be high volume and can pollute general log analysis if not separated. Many teams route them to cold storage and only pull them on demand, which defeats the purpose entirely. Keep at minimum 90 days of blocklist hit data in a hot or warm tier where it can be queried in real time during an investigation.
Once the data is flowing correctly, build a baseline. How many blocklist hits does your environment generate per day? Which internal hosts generate the most? What is the distribution across blocklist categories such as malware C2, botnet, phishing infrastructure, or scanning nodes? Anomalies become detectable only after you have a baseline against which to measure them.
Structuring Hunts Around Blocklist Categories
Different blocklist categories warrant different hunting approaches. Treating all blocked IPs as equivalent noise misses the signal that category-specific analysis provides.
Command-and-Control Infrastructure Hits
Any internal host generating blocked connections to known C2 infrastructure is your highest priority signal. The host is exhibiting post-compromise behavior. Your hunt should pivot immediately to that host: pull process network activity logs, look for unusual parent-child process relationships, examine scheduled tasks and persistence mechanisms, and check for any successful outbound connections in the hours before the blocks started. The blocked connections may represent a fallback channel; the primary channel may have already been successful through an IP not yet listed.
The CL-STA-1062 campaign targeting Southeast Asian governments and critical infrastructure demonstrated this pattern clearly. Threat actors operating at that level maintain large pools of C2 infrastructure, rotating through IPs faster than most blocklists update. Blocked connections to listed C2 IPs indicate the early or fallback stages of communication. The hunt value is in finding what succeeded before the blocks started, not in celebrating that the blocks are working.
Ransomware Pre-Deployment Infrastructure
Ransomware operators conduct significant reconnaissance and staging activity before deploying encryption. Groups have demonstrated consistent use of legitimate remote access tools such as ScreenConnect, as documented in recent reporting on large-scale campaigns where the software was masqueraded as freeware to establish persistent access. When your blocklists are enriched with ransomware group infrastructure indicators, hits against those IPs from internal hosts should trigger an immediate hunt for remote access tooling, credential harvesting activity, and lateral movement artifacts.
The masquerade-as-legitimate-software technique means the initial access vector often does not generate blocklist hits at all. The blocklist hit may come during the staging phase when the actor is moving data to exfiltration infrastructure or reaching back to download additional tooling. At that point, you have a narrow window to interrupt the operation before payload deployment.
Scanning and Reconnaissance Sources
Inbound connection attempts from IPs listed as scanners or reconnaissance sources are lower individual priority but high analytical value in aggregate. Track which of your external-facing assets attract the most scanner activity. Sudden increases in scanner hits against a specific asset often precede targeted exploitation attempts. The Watering Hole attacks that pushed the ScanBox keylogger demonstrated that reconnaissance infrastructure and payload delivery infrastructure frequently overlap; an IP flagged for scanning today may be serving exploits tomorrow.
Integrating Threat Intelligence Feeds With Hunting Workflows
The quality and recency of your blocklist data directly determines what you can hunt on. Most organizations use a combination of commercial threat intelligence feeds, open-source lists such as those maintained by Abuse.ch, Emerging Threats, and the Spamhaus Project, and government-published indicators from sources like CISA and similar bodies.
Each feed has different update frequencies, different false positive rates, and different coverage areas. A feed that excels at tracking botnet infrastructure may have minimal coverage of nation-state C2 nodes. A feed with excellent ransomware infrastructure coverage may be slow to add newly registered phishing domains. Understanding the coverage profile of each feed you consume is a prerequisite for knowing what your blocklists can and cannot tell you.
For hunting purposes, feeds with high confidence ratings and low false positive rates are more valuable than high-volume feeds with mixed confidence. A blocklist hit on a high-confidence C2 indicator warrants immediate escalation. A hit on a low-confidence indicator warrants investigation but not necessarily incident response mobilization. Tag your feed sources with confidence tiers and reflect those tiers in your alerting logic.
Operationally, consider maintaining a private blocklist fed by your own historical observation data. IPs that have directly targeted your environment, scanned your assets, or appeared in previous incidents carry a different weight than generic threat intelligence. They represent adversaries who have specifically expressed interest in your organization. Hits against that private list should generate higher-priority alerts than hits against generic commercial feeds.
Cross-Referencing Blocklist Data With Other Telemetry
Blocklist hits in isolation are interesting. Blocklist hits correlated with other security telemetry are actionable. The most productive threat hunting workflows treat blocklist hit data as a starting point for cross-source correlation, not a standalone detection mechanism.
When an internal host generates a blocklist hit, pull the following data for that host covering the same time window and the 24 hours preceding the event:
- DNS query logs: look for queries to domains associated with the same threat actor infrastructure, algorithmically generated domain names, or domains with very recent registration dates
- Authentication logs: look for successful logins from unusual sources, failed authentication spikes, or new credential use patterns
- Endpoint detection logs: look for new processes, unsigned binaries, unusual parent-child relationships, or LOLBin abuse
- Network flow data: look for connections to IPs in the same ASN or geographic region as the blocked IP, particularly if those connections were not blocked
- Email gateway logs: look for recent phishing delivery attempts targeting users on that host or in the same department
This cross-reference approach frequently reveals that the blocklist hit represents a late indicator of a compromise that began elsewhere. The goal of the hunt is to walk that compromise back to its origin point and identify the full scope of affected assets.
Automating Correlation Without Automating Judgment
Automation has a clear role in blocklist-driven threat hunting, but it requires careful scoping. Automated correlation of blocklist hits with asset inventory, automatic enrichment of hit events with threat intelligence context, and automatic grouping of related events by internal host or time window are all legitimate automation targets. These tasks are deterministic and do not require analyst judgment.
Automated response based on blocklist hits carries significant risk. Automated blocking of internal hosts based on a single blocklist hit will generate false-positive-driven disruption, particularly in environments with shared infrastructure or dynamic IP assignment. Automated network isolation based on outbound C2 hits is more defensible but still warrants a verification step before execution. Build automation that accelerates analyst investigation rather than automation that substitutes for it.
A practical implementation is a playbook that triggers on blocklist hits meeting a defined threshold: for example, three or more hits from the same internal host within a two-hour window, or any hit against a high-confidence C2 indicator. The playbook automatically pulls enrichment data, correlates with the asset inventory, retrieves recent related telemetry from other sources, and presents the analyst with a consolidated case view. The analyst makes the response decision. The automation compresses investigation time from hours to minutes.
Handling the Evasion Reality
Threat actors conducting campaigns at scale are aware that their infrastructure gets listed. The Armored Likho group's BusySnake Stealer campaign illustrated the operational security measures sophisticated actors now routinely employ, including rapid infrastructure rotation, use of compromised legitimate infrastructure, and multi-stage delivery chains designed to limit exposure of high-value C2 infrastructure.
Blocklist-based hunting under these conditions requires accepting that you will frequently be hunting on stale indicators. The response is to hunt for behavioral patterns rather than specific indicators. An internal host exhibiting consistent outbound connection attempts to diverse IPs across multiple threat actor infrastructure ranges, even if each individual IP is new, represents a pattern that is detectable through behavioral analysis even when the specific IPs are not yet listed.
Infrastructure rotation also creates hunting opportunities. When a threat actor rotates C2 IPs, the new IP often appears in the same ASN, the same geographic region, or resolves through the same hosting provider as the previous IP. Hunting for connection attempts to infrastructure sharing these characteristics with known-bad IPs can surface new activity before the new IP makes it onto a blocklist.
Additionally, credential attack campaigns, which continue to scale in sophistication and volume as recent reporting on large-scale credential attacks confirms, frequently use proxy and VPN infrastructure that cycles through blocklisted and unlisted IPs. Hunting on the behavioral pattern of authentication attempts rather than relying solely on blocklist matching catches more of this activity.
Measuring Whether the Hunt Program Is Working
Threat hunting programs fail quietly when they lack outcome metrics. For blocklist-driven hunting specifically, track the following over time:
- Mean time from blocklist hit to investigation initiation: this measures whether your alerting and triage process is functioning
- Percentage of blocklist hits that result in a confirmed finding: this measures hunt effectiveness and blocklist quality
- Number of compromises identified through blocklist correlation where no prior alert existed: this measures the incremental value of the hunting program over passive detection
- Mean time from first blocklist hit to full incident scope determination: this measures investigation efficiency
If the percentage of blocklist hits resulting in confirmed findings is very low, either your blocklist data quality is poor, your correlation process is not surfacing real patterns, or both. If it is very high, your detection baseline may be set too aggressively or you may be dealing with a persistent threat that warrants deeper investigation.
Practical Starting Points for Teams Building This Capability
For teams moving from passive blocklist deployment toward active blocklist-driven hunting, the sequence that produces the fastest demonstrable value typically runs as follows.
First, establish log completeness for blocklist hit events across all enforcement points, normalize the schema, and confirm that internal asset identifiers are present in every event. This alone eliminates a significant amount of investigation friction.
Second, build a 30-day historical baseline of blocklist hit frequency by internal host and by blocklist category. Identify the top five internal hosts by hit volume and investigate each manually. In most environments, this first manual pass surfaces at least one genuine finding.
Third, implement a correlation rule that groups blocklist hits by internal host over a rolling 24-hour window and alerts when any host exceeds its baseline by a defined threshold. Start with a threshold high enough to avoid alert fatigue and tune downward as your baseline data matures.
Fourth, build the cross-source correlation playbook so that when a blocklist hit alert fires, the analyst immediately has access to correlated DNS, authentication, endpoint, and network flow data for that host. This is where the hunt becomes productive rather than merely reactive.
Finally, conduct a monthly review of all blocklist hits that did not generate alerts and sample a percentage for manual review. This is where you find the slow, low-volume activity that threshold-based alerting misses, which is frequently the most sophisticated threat activity in your environment.
IP blocklists deployed as passive filters are a commodity security control. IP blocklists treated as a structured source of hunting signal are a materially different capability. The difference is not in the technology but in the operational model built around the data those blocks generate.
