Where the Attack Pattern Starts: Recent Incidents That Blocklists Should Have Flagged
Ransomware groups have grown more deliberate about their pre-attack reconnaissance. Across incidents tracked in recent months, defenders have found that attackers spent days or weeks probing perimeter systems from IP ranges already documented in commercial and open-source threat feeds. The gap was not in the blocklist data itself. The gap was in how teams used it after ingestion.
Consider the resurgence of large-scale credential attacks flagged in recent threat intelligence reports. Attackers behind these campaigns rotated through IP ranges associated with residential proxies, bulletproof hosting, and compromised infrastructure in regions known for hosting abuse-tolerant providers. Many of those IPs appeared in threat feeds days before authentication logs showed the surge. Security teams that treated their blocklists as static firewall inputs missed the forward signal. Teams that fed that data into hunting workflows caught the pattern early.
The same dynamic appeared in campaigns distributing VBScript payloads through WhatsApp, where command-and-control infrastructure landed on IP ranges with documented abuse histories. The infrastructure was flagged. The hunting process to act on that flag was absent.
What an IP Blocklist Actually Contains and Why That Matters for Hunting
Most security teams treat blocklists as binary: an IP is on the list, or it is not. That framing discards most of the signal those lists carry.
A well-structured threat intelligence feed carries more than IP addresses. It carries timestamps, confidence scores, category tags, associated malware families, and historical behavior annotations. A single IP flagged as a Mirai botnet node three weeks ago tells a different story than one flagged as a credential-stuffing source yesterday. Both belong on a blocklist, but they demand different hunting responses.
Categories matter operationally. Common categories in major feeds include:
- Command-and-control infrastructure tied to specific malware families like HIVE variants or commodity RATs
- Scanning and reconnaissance sources that probe for open ports and exposed services
- Credential attack infrastructure including credential stuffing and brute force sources
- Phishing and malware distribution hosts
- Bulletproof hosting ranges used across multiple campaigns
- Compromised devices including the kind of IoT and surveillance camera infrastructure that has appeared in recent access broker markets
When defenders pull a blocklist without preserving category metadata, they collapse all of those into a single undifferentiated block. That collapses the hunting value along with it.
Ingestion Architecture That Preserves Signal
Passive blocking is the floor, not the ceiling. The ingestion pipeline matters for everything that comes after.
The first design decision is where the blocklist data lands. Many teams route it directly into firewall deny rules or SIEM watchlists, which handles the blocking function but produces no structured data for analysis. A more useful pattern routes the same feed into a threat intelligence platform or a structured database that preserves all available metadata fields.
A minimal schema for stored blocklist data should include:
- IP address or CIDR range
- First seen and last seen timestamps from the feed
- Category and subcategory tags
- Confidence score or severity rating
- Associated malware family or campaign identifier where available
- Feed source name and feed retrieval timestamp
- ASN and hosting provider details at ingestion time
Storing ASN and hosting provider data at ingestion time is worth emphasis. IP-to-ASN mappings change. If you investigate a blocklisted IP six weeks after ingestion and the ASN has shifted, you lose the original attribution context. Snapshot it when you pull the feed.
The second design decision is feed aggregation. No single blocklist covers the threat landscape completely. Running multiple feeds and deduplicating with metadata merging produces a richer dataset than any single source. IPs that appear across multiple independent feeds warrant higher confidence scores in your internal scoring model, even if the feeds themselves do not assign scores.
Correlating Blocklist Data Against Internal Telemetry
The hunting workflow starts when you run blocklist data against internal logs rather than waiting for a blocklist hit to trigger an alert.
The query pattern is straightforward: pull all connection records from firewall logs, proxy logs, DNS query logs, and endpoint telemetry for a defined time window, then join against your stored blocklist data on IP address. The output is a set of internal hosts that communicated with known-bad infrastructure, with full metadata context for each match.
This approach reveals activity that passive blocking misses. Passive blocking stops future connections from a listed IP. It does not expose connections that happened before a feed was ingested, connections that bypassed the enforcement point, or internal hosts that are already compromised and communicating outbound. The correlation query catches all three.
Prioritize results using the metadata you preserved at ingestion. A match against a C2 IP associated with a current ransomware campaign like those driving the recent surge in ransomware incidents carries more urgency than a match against a low-confidence scanning source. Your hunting queue should reflect that distinction rather than treating all matches identically.
Practical Query Structure
In a SIEM environment like Splunk or Elastic, the core correlation query structure follows this logic:
- Load the current blocklist as a lookup table with all metadata fields
- Search firewall or proxy logs for outbound connections in a rolling 30-day window
- Join on destination IP address against the lookup table
- Return matches with source host, destination IP, connection timestamp, bytes transferred, and all associated blocklist metadata
- Sort by severity score descending, then by most recent activity
Schedule this query to run daily at minimum. For high-value environments or during active incident response, run it continuously as a streaming alert with a rolling window.
Pivoting From a Blocklist Hit to an Investigation
A blocklist match is a starting point. The investigation determines whether the match represents a real compromise, a false positive, or infrastructure that warrants broader hunting.
When a blocklist match surfaces, the first question is whether the internal host has done anything else worth examining. Pull all activity from that host across the same time window: DNS queries, other external connections, authentication events, process execution where endpoint telemetry exists, and lateral movement indicators. Blocklist matches associated with credential attack infrastructure should immediately trigger a review of authentication logs from that host for unusual login patterns.
The second pivot is outward from the flagged IP itself. What else is hosted on the same subnet? Does the ASN have other IPs in your blocklist data? Have other organizations reported activity from the same infrastructure in public threat sharing channels? Campaigns like the ScanBox watering hole attacks and the HIVE kit variant activity documented in recent reporting tend to share infrastructure across targets. An IP flagged in your environment may connect to broader campaign infrastructure that can inform hunting across your entire environment.
Passive DNS data is useful here. Historical DNS resolutions tied to a flagged IP often reveal domain names associated with the same campaign. Those domains can become additional hunting indicators even if the domains themselves have not appeared in any blocklist. The blocklist IP becomes the entry point for a richer indicator graph.
Tuning False Positive Rates Without Discarding Good Signal
IP blocklists produce false positives. Shared hosting environments, cloud provider IP ranges, and content delivery networks all appear in threat feeds when individual customers on those platforms conduct abuse. Blocking or alarming on the entire range creates noise that degrades analyst trust in the feed.
The solution is not to drop those IPs from consideration. The solution is to apply context before escalating a match.
Build an internal allowlist of known-good infrastructure that overlaps with threat feed data. Large cloud provider ranges where your business has documented legitimate usage, CDN ranges used by vendors, and SaaS platforms used by your organization should be catalogued. When a blocklist match falls within one of those ranges, lower the alert priority and require additional corroborating indicators before escalation.
Corroborating indicators worth checking before escalation include:
- Large data transfers to the flagged IP
- Connections at unusual hours relative to the internal host's baseline
- The internal host recently received a phishing email or downloaded an executable
- Multiple internal hosts connecting to the same flagged external IP
- DNS queries to newly registered or low-reputation domains preceding the connection
Any single one of these raises confidence. Two or more together push the match into high-priority investigation territory regardless of the shared-hosting ambiguity.
Feeding Hunting Results Back Into the Feed
The highest-value use of internal blocklist correlation is the internal indicator that results from it. When a hunt confirms that an internal host communicated with a C2 IP and subsequent investigation identifies additional infrastructure, those new IPs, domains, and hashes become internal intelligence that no commercial feed carries yet.
Document confirmed campaign infrastructure in your internal threat intelligence platform with full provenance: what hunt surfaced it, what investigation steps confirmed it, what external feed first flagged the entry point, and what the associated campaign appears to be. This internal dataset compounds over time. Campaigns rarely abandon infrastructure entirely. Infrastructure documented from a confirmed incident three months ago may appear again in new campaign activity, and your internal dataset will catch the connection before any external feed does.
This is the feedback loop that separates teams doing threat intelligence from teams doing IP blocking. The blocklist is the input. The investigation is the process. The internally generated intelligence is the output that makes the next hunt faster and more accurate.
Operationalizing Feed Freshness and Decay
IP threat data has a shelf life. An IP flagged as active C2 infrastructure six months ago may now be running a legitimate business. Treating stale data with the same weight as fresh data produces alert fatigue and erodes analyst confidence.
Apply a decay model to your stored blocklist data. Common approaches include:
- Hard expiry: Remove IPs from active hunting queries after a defined period unless the feed re-confirms them. Sixty to ninety days is a reasonable default for most categories, shorter for high-volatility categories like scanning sources.
- Score decay: Reduce the internal confidence score of an entry linearly over time from the last confirmed date. An IP still in the feed but not re-confirmed degrades in priority until it falls below the hunting threshold.
- Category-specific decay rates: Bulletproof hosting ranges decay slowly because the infrastructure tends to be persistent. Residential proxy IPs decay quickly because the underlying devices cycle frequently.
Feed freshness also matters at the ingestion side. Pull feeds frequently enough that newly added IPs enter your hunting workflow within hours, not days. For critical environments, automated feed pulls every four to six hours and near-real-time correlation against live firewall and proxy logs reduce the window between an IP appearing in threat intelligence and your team knowing whether any internal host has reached it.
Integrating Blocklist Workflows With Incident Response
When an active incident is underway, blocklist data shifts from a proactive hunting tool to a rapid triage resource. During credential attack campaigns, ransomware pre-deployment activity, or confirmed C2 communications, security teams need to answer two questions immediately: which internal hosts have touched known-bad infrastructure, and what other infrastructure associated with this campaign might still be reachable?
Pre-build the queries for both questions before an incident occurs. Having a saved search that accepts a campaign IP as a parameter and returns all internal hosts that have communicated with it, along with all other IPs from the same ASN and subnet that appear in your blocklist data, saves critical time when the pressure is on.
Integrate blocklist correlation into your incident response playbooks as a standard step. When a host is identified as compromised, run the correlation query against all traffic from that host for the past thirty days. When a phishing campaign delivers a payload, run the C2 IPs extracted from that payload against internal telemetry immediately. Both of these steps surface scope information that would otherwise take hours of manual log review to develop.
What Mature Blocklist Operations Actually Look Like
Mature threat hunting programs using IP blocklists share a few consistent characteristics that separate them from teams still treating blocklists as firewall inputs.
They run multiple feeds and score them based on historical accuracy in their specific environment. A feed that produces frequent false positives in their industry vertical gets lower weight. A feed that has historically predicted campaign infrastructure they later confirmed through incident response gets higher weight.
They maintain an internal indicator database that outlasts any individual feed subscription. When a feed is discontinued or a vendor changes, the internally generated intelligence persists and continues to contribute to hunting.
They treat every confirmed blocklist match as a hunting prompt, not a closed case. The match starts an investigation. The investigation either clears the host or generates new indicators. New indicators feed back into the platform. The loop runs continuously.
They build relationships between blocklist data and other intelligence sources: passive DNS, WHOIS history, BGP routing data, and certificate transparency logs. A single flagged IP connected to those sources produces an intelligence picture that no blocklist alone can generate.
The teams getting the most value from IP threat data are not the teams with the most feeds. They are the teams that built the workflows to turn each feed entry into a question worth answering.
