The Operator Pain Point No One Wants to Admit
Your IP blocklists are running. Feeds are updating. Alerts are firing on the obvious stuff. And yet something slips through every week that should have been caught at the perimeter. The gap is rarely the blocklist itself. It is the assumptions baked into how the blocklist gets consumed, checked, and acted on.
A concrete illustration arrived in mid-June when SANS Internet Storm Center documented an eBanking phishing campaign delivered through IPv4-mapped IPv6 addresses. The attacker used addresses in the ::ffff:0:0/96 range, which maps IPv4 space into IPv6 notation. Most blocklist implementations check IPv4 and IPv6 separately, using different lookup tables and sometimes different pipeline stages entirely. An address like ::ffff:192.0.2.1 often bypasses a blocklist that would have flagged 192.0.2.1 without a second thought. This is a structural gap, and it is representative of a much larger class of blocklist failures that security teams carry silently for months.
This article is for the analyst who already has blocklists deployed and wants to understand where they break down, how to test them honestly, and what changes produce measurable improvement over a realistic timeframe.
What Blocklists Actually Are (and What They Are Not)
An IP blocklist is a dataset of addresses or ranges associated with observed malicious behavior, abuse reports, scanner activity, botnet infrastructure, or policy violations. Commercial feeds, open-source projects like Spamhaus, Emerging Threats, and Feodo Tracker, and community-maintained sources like AbuseIPDB all produce blocklists with different methodologies, refresh rates, and focus areas.
The critical thing to understand is that every blocklist is a historical artifact. An entry exists because something bad happened from that address in the past. The address may have been cleaned up, reassigned, or handed to a completely different actor since the record was written. Equally, an address causing active harm today may not appear on any list for hours, days, or longer depending on how the source feed collects and distributes data.
This does not make blocklists useless. It means they need to be positioned correctly in your detection architecture: as one signal layer among several, not as a firewall substitute or a complete answer to inbound threat filtering.
Where the IPv6 Mapping Problem Fits Into a Broader Pattern
The eBanking phishing campaign using IPv4-mapped IPv6 addresses is a precise example of what happens when a threat actor understands the tooling better than the defender does. The attacker was not using some exotic technique. IPv4-mapped IPv6 is a standard mechanism defined in RFC 4291. Any developer or operator who has worked with dual-stack implementations has encountered it. Yet blocklist lookup implementations frequently handle the two namespaces as isolated domains.
This class of evasion shares structural similarities with other active threat patterns. The FishMonger group's deployment of SprySOCKS malware on Windows endpoints relies partly on the assumption that detection tools are tuned for known signatures rather than behavioral markers. SprySOCKS communicates over standard-looking protocols precisely because protocol-level blocklisting is predictable and therefore avoidable. The same logic applies to IP address evasion: threat actors probe for where the detection boundary sits and route around it.
Scattered Spider, whose members entered guilty pleas in June, built an operational model around social engineering and SIM swapping that rendered traditional network blocklists irrelevant because initial access came through authenticated sessions, not blocked IP ranges. Blocklists would have contributed nothing to stopping that campaign. Understanding where your tools apply and where they do not is as important as tuning the tools themselves.
Auditing Your Blocklist Coverage: What to Do Today
Before investing time in new feeds or integrations, run an honest audit of what your current implementation actually checks. Most teams are surprised by what this reveals.
Test IPv4-to-IPv6 Mapping Coverage
Take ten addresses from your active blocklist. Convert them to IPv4-mapped IPv6 format manually. Submit those converted addresses to your SIEM, firewall, and any inline inspection tools to see whether they register as blocked or unknown. If your tooling treats ::ffff:203.0.113.42 differently from 203.0.113.42, you have a gap that active threat actors are already aware of and some are already using.
The fix varies by platform. In Python-based lookup scripts, use the ipaddress module's ipv4_mapped property to normalize addresses before comparison. In SIEM platforms, add a field extraction rule that identifies IPv4-mapped addresses and resolves them before blocklist lookup occurs. In firewall ACLs, ensure your IPv6 rule sets include the ::ffff:0:0/96 range mapped to your IPv4 blocklist entries.
Measure Feed Freshness Honestly
Pull your current blocklist feed timestamps. Calculate the average age of entries at the time they are consumed by your enforcement point. A feed that updates every 24 hours and takes six hours to propagate through your SIEM pipeline and another four hours before a firewall rule is pushed means any address that appears on the feed today will not be blocked for up to 34 hours in the worst case. For fast-moving phishing infrastructure, that window is the entire campaign lifecycle.
Document the actual end-to-end latency for each blocklist source you rely on. This is a number worth knowing precisely because it determines how you communicate the value and limitations of this layer to your incident response team and to management.
Identify Overlaps and Gaps Across Feed Sources
Run a coverage comparison across your active feeds. Take a sample of recently investigated malicious IPs from your own incident logs and check how many appeared on each feed, how quickly, and whether any appeared on zero feeds during the window of the attack. This exercise consistently reveals that single-source deployments have substantial blind spots, and that adding a second or third feed with different collection methodology catches a meaningful percentage of addresses the primary feed missed.
Feodo Tracker focuses on banking trojan command-and-control infrastructure. Spamhaus provides broad abuse coverage. Emerging Threats focuses on network attack signatures. AbuseIPDB aggregates community reports with confidence scores. Each source reflects what its collection mechanism can see. A mix of automated honeypot-derived data, community reporting, and commercial telemetry will cover more of the attack surface than any single source.
Operationalizing Blocklists as Hunting Tools, Not Just Blocking Rules
The biggest shift in how mature security teams use blocklists is the move from passive enforcement to active hunting. The enforcement use case blocks a known-bad address from reaching a resource. The hunting use case asks: have any of these known-bad addresses touched our environment in the past 90 days, including in traffic that was not blocked?
Retroactive Log Matching
Export your current blocklist and run it against 90 days of firewall and proxy logs, including traffic that was allowed. This frequently surfaces connections that occurred before an address was added to a feed, or connections that bypassed the enforcement point through a split-tunnel VPN, a misconfigured proxy exception, or a cloud workload that routes directly to the internet.
The practical implementation depends on your log volume and storage platform. In Splunk, a lookup table populated from your blocklist feed can be joined against historical netflow or proxy logs in a scheduled search. In Elastic, enrich your documents with a threat feed using the Elastic threat intelligence module or a custom ingest pipeline that tags matching source or destination IPs. In Microsoft Sentinel, the ThreatIntelligenceIndicator table can be cross-referenced against CommonSecurityLog or AzureNetworkAnalytics_CL using joins in KQL.
Prioritize results where the matched connection was allowed, where data was transferred outbound, or where the connection occurred from a privileged endpoint or server. These are the cases most likely to represent active compromise rather than reconnaissance noise.
Threat Actor Infrastructure Pivoting
When you identify a blocklisted address in your logs, the investigation should not stop at confirming the hit. Use the address as a starting pivot point for broader infrastructure analysis. Query passive DNS data for the address to identify what domains resolved to it over time. Check WHOIS records for registration patterns. Look for other addresses registered to the same ASN with similar abuse histories. This approach frequently reveals additional infrastructure that has not yet been added to any feed.
The Cybercriminals selling access to Chinese surveillance cameras, documented in recent reporting, represents exactly this kind of infrastructure: large pools of IP addresses associated with compromised devices that appear on some feeds but not others, often categorized inconsistently as proxy infrastructure, scanner nodes, or botnet endpoints depending on the source. Treating a single matched address as the entry point to a cluster of related infrastructure multiplies the value of each blocklist hit.
Context Scoring for Prioritization
Raw blocklist matches produce too many results for manual review in any environment above a few dozen endpoints. Build a scoring layer that weights matches based on factors beyond presence on a list. Relevant signals include the confidence score or age of the blocklist entry, whether the matched address appears on multiple independent feeds, the sensitivity classification of the asset that made or received the connection, the direction and volume of data transfer, and whether the connection time correlates with off-hours activity.
A match where a high-sensitivity server connected outbound to an address that appeared on three independent feeds with high confidence scores during a weekend night is a very different priority level from a match where a developer workstation loaded a web resource from an address that appeared once on a low-confidence community feed during business hours.
What to Implement This Week
With the audit complete and the hunting approach defined, there are several concrete changes that pay off within a week of implementation.
Normalize Address Formats in Your Pipeline
Add address normalization at ingestion. Every IP address entering your SIEM or log aggregation platform should be resolved to its canonical form before any blocklist comparison occurs. This means expanding IPv4-mapped IPv6 to standard IPv4 where applicable, stripping port numbers appended to addresses in some log formats, and handling CIDR notation consistently. This single change closes the phishing campaign evasion technique documented in the eBanking incident.
Add a Second Feed With a Different Collection Method
If your current blocklist comes from a single commercial provider, add one open-source feed with a different methodology. If your primary feed is honeypot-derived, add a community abuse report feed. If your primary feed focuses on malware C2, add a phishing-focused feed. The marginal cost of ingesting a second feed into an existing SIEM integration is low, and the coverage improvement is consistent.
Set Up Automated Retroactive Matching on a Defined Window
Schedule a daily or weekly job that runs current blocklist contents against the past 30 days of allowed traffic logs. This does not require real-time processing and can run as a batch job during off-peak hours. The output should feed directly into your ticketing or case management system with the context scoring applied so analysts receive pre-prioritized findings rather than raw match lists.
Quarterly Planning: Where to Invest for Sustained Improvement
Over a quarter, the most valuable investments move from reactive detection to predictive positioning.
Build Feed Performance Metrics
Establish a baseline for how often each feed you consume produces a true positive match versus a false positive or an unresolvable hit. Track this over time. Feeds that produce high false positive rates consume analyst time without value. Feeds that consistently catch real activity should receive higher weight in your scoring model. This is the same principle behind how platforms like Recorded Future build confidence scoring into their proprietary collection engine: source reliability is not assumed, it is measured continuously.
Integrate Blocklist Data With Asset Context
Blocklist matches become significantly more useful when they are automatically enriched with asset context from your CMDB, EDR, or cloud inventory. A connection from a blocklisted address to an unmanaged device in a guest network is a different risk profile from the same connection reaching a database server in your production environment. Enriching blocklist alerts with asset classification at the time of alert generation cuts the triage time for each case and reduces the risk of high-severity events being deprioritized due to alert volume.
Develop Custom Indicator Lists From Your Own Investigations
Every incident your team investigates produces infrastructure data that is specific to your environment and threat profile. Addresses used in phishing campaigns targeting your sector, domains associated with credential stuffing attacks against your authentication endpoints, and ASNs repeatedly appearing in your logs all represent custom intelligence that generic feeds will never carry. Maintain an internal blocklist derived from your own investigations and treat it as your highest-confidence feed. The AI supply chain threat model emerging around tools like those discussed in the OpenClaw Skill Marketplace reporting suggests that custom intelligence derived from your specific technology stack and vendor relationships will become increasingly important as generic feed coverage struggles to keep pace with new attack surfaces.
Test Your Blocklist Under Adversarial Conditions
Once per quarter, run a tabletop or technical exercise that asks your red team or a trusted third party to simulate traffic from addresses that are on your blocklist through techniques that might evade detection: IPv4-mapped IPv6, traffic routed through an unlisted proxy chain, requests using address ranges adjacent to blocked CIDR blocks. Document what was caught and what passed through. Use the results to drive specific configuration changes rather than general improvement goals.
The Structural Limit You Need to Accept
Blocklists catch what has been seen before. They provide coverage against known infrastructure, and when used as hunting tools against historical logs, they surface past exposure that would otherwise go undetected. They contribute meaningfully to a layered defense. They are not a substitute for behavioral detection, network anomaly analysis, or endpoint monitoring.
The Healthtech firm Xolis breach affecting 1.4 million records and the student loan breach exposing 2.5 million records both represent cases where the initial intrusion path and subsequent data exfiltration may or may not have touched blocklisted infrastructure, but in either scenario, blocklist coverage alone would have been insufficient to prevent the outcome. These incidents required detection capabilities operating across authentication logs, data access patterns, and lateral movement behaviors that IP reputation data does not address.
Position your blocklist investment accordingly. Keep it well-maintained, well-integrated, and honestly audited. Use it as the hunting and correlation layer it is built to be. Build the behavioral and anomaly detection layers alongside it rather than treating either as a replacement for the other.
Actionable Takeaways
- Test your blocklist implementation against IPv4-mapped IPv6 addresses today. Normalize address formats before lookup to close the gap demonstrated in the eBanking phishing campaign.
- Measure feed latency end to end from source update to enforcement point. Know the exact window during which a newly listed address can reach your environment.
- Run retroactive blocklist matching against 90 days of allowed traffic. Schedule this as a recurring process, not a one-time exercise.
- Add a second blocklist feed with a different collection methodology to improve coverage across attack types and actor categories.
- Build context scoring that weights blocklist matches by asset sensitivity, connection direction, data volume, and multi-feed confirmation.
- Maintain an internal indicator list derived from your own incident investigations. This feed will outperform generic sources for threats targeting your specific environment.
- Conduct quarterly adversarial testing of your blocklist implementation using evasion techniques that active threat actors already employ.
