The Problem Sitting Inside Most Firewall Configs Right Now
Most security teams have spent years building IP-based blocklists, refining geo-blocking rules, and tuning signature-based detection. What many of those same teams have not done is look at the Autonomous System Numbers behind the traffic hitting their perimeter. ASN-based threat filtering occupies an underutilized middle ground between blocking individual IPs, which attackers rotate through constantly, and coarse country-level blocks, which catch too much legitimate traffic while missing infrastructure parked in permissive or poorly monitored networks.
The Nimbus Manticore operations observed during the Iranian conflict in early 2026 illustrated this gap clearly. Attribution analysis showed sustained use of hosting infrastructure across a small set of ASNs associated with bulletproof and semi-bulletproof hosting providers. Individual IP blocks were rotated frequently enough to outpace manual blocklist updates, but the underlying ASN fabric remained consistent across the campaign's lifetime. Teams that had ASN-level visibility caught the pattern within the first wave. Teams relying solely on IP reputation feeds were still updating lists as the third wave landed.
This article is for the network defender or IT administrator who has IP blocking in place but wants to add a higher-order filtering layer that degrades attacker infrastructure more durably than per-IP blocking alone.
What an ASN Actually Represents in a Threat Context
An Autonomous System is a collection of IP prefixes under the control of a single administrative entity, governed by a common routing policy, and identified globally by its ASN. When a hosting provider, ISP, cloud platform, or bulletproof operator registers a block of addresses, those addresses fall under one or more ASNs. That ASN becomes a durable identifier even as individual IPs within it are reassigned, rotated, or abandoned.
From a defender's perspective, an ASN represents a policy fingerprint. A cloud provider's ASN hosts both legitimate customers and abusers. A residential ISP's ASN hosts real end users mixed with botnet-infected devices. A bulletproof hosting ASN exists primarily to provide abuse-resistant infrastructure to threat actors willing to pay for it. The proportion of malicious to legitimate traffic flowing from a given ASN is measurable, and that measurement forms the basis of risk-tiered filtering.
Kaspersky's Q1 2026 mobile threat statistics noted a continuing shift toward attack infrastructure hosted on small regional ISPs and reseller networks. These networks often have minimal abuse response capabilities, slow CERT escalation paths, and IP space that does not appear in major commercial threat intelligence feeds quickly enough to matter. Their ASNs, however, are identifiable well before individual IPs within them develop reputation scores.
Building an ASN Risk Taxonomy Before You Filter Anything
Jumping straight to blocking entire ASNs without a classification framework creates operational problems fast. You will block legitimate cloud egress, break partner integrations, and generate helpdesk tickets that undermine the program. The operational discipline that makes ASN filtering effective is a tiered risk taxonomy built before any rules go live.
Tier 1: High-Confidence Malicious ASNs
These are ASNs where the operator's primary business model is abuse-resistant hosting. They appear persistently in threat intelligence feeds, have no meaningful abuse response, and carry negligible legitimate traffic for most enterprise environments. Blocking outbound and inbound connections to and from these ASNs carries low operational risk for most organizations. Examples include certain offshore hosting operators that have appeared repeatedly in campaign infrastructure associated with ransomware staging, phishing kit hosting, and command-and-control.
Tier 2: High-Risk Mixed ASNs
These ASNs host a meaningful mix of legitimate services and known abuse infrastructure. Large cloud platforms like AWS, Azure, GCP, and DigitalOcean fall into this category. Blocking them entirely is operationally impractical for most organizations, but applying enhanced inspection, rate limiting, and anomaly scoring to traffic from these ASNs is both practical and valuable. The 0ktapus campaign, which victimized over 130 firms, relied heavily on infrastructure spun up across commodity cloud ASNs specifically because defenders treated those ASNs as implicitly trusted.
Tier 3: Low-Risk ASNs Requiring Monitoring
Residential ISPs, regional carriers, and legitimate enterprise network blocks fall here. The threat signal from these ASNs is typically low-volume, often botnet-sourced, and requires behavioral analysis rather than blanket filtering. The ISC Stormcast reporting for late May 2026 highlighted scanning campaigns originating from residential broadband ASNs across Southeast Asia and Eastern Europe, pointing to ongoing botnet activity that ASN-level monitoring helps contextualize even when per-IP blocking is the response mechanism.
Data Sources for ASN Intelligence
Effective ASN filtering requires combining multiple intelligence sources because no single feed covers the full threat landscape reliably.
- WHOIS and RDAP data: Provides ownership, registration country, and contact information for each ASN. Useful for identifying newly registered ASNs with thin registration histories, a reliable indicator of abuse infrastructure.
- BGP routing data: Sources like RouteViews, RIPE RIS, and BGPStream provide real-time and historical prefix announcements, allowing defenders to track when new IP space is announced under a known-bad ASN or when ASN hijacking occurs.
- Threat intelligence feeds: Commercial feeds from providers like Recorded Future, Mandiant, and Crowdstrike include ASN-level annotations alongside IP indicators. Open-source alternatives like Spamhaus ASN DROP list and CIDR Report's bogon data provide baseline coverage.
- Internal telemetry: Your own firewall logs, proxy logs, and DNS query logs contain ASN metadata if you enrich them at ingestion. This internal data often reveals ASN patterns specific to your industry that commercial feeds lag on.
- Abuse contact response rates: Tracking how frequently abuse reports to specific ASN operators result in action creates an operational abuse-responsiveness score. ASNs with zero response to repeated reports are strong candidates for elevated risk tiers.
Implementation Phases: From Today to This Quarter
Today: Enrich Your Existing Log Data With ASN Metadata
The first step requires no firewall changes. Take your existing firewall and proxy logs and run them through an ASN enrichment pipeline. MaxMind GeoLite2 ASN, the ip-api.com commercial tier, or Team Cymru's IP-to-ASN mapping service all provide fast, bulk enrichment. Feed the enriched data into your SIEM and build a simple dashboard showing connection volume, unique IP count, and blocked event count grouped by ASN.
Within hours, this view will surface ASNs generating disproportionate noise relative to their legitimate utility. You will typically find three to five ASNs responsible for thirty to fifty percent of blocked or suspicious events in most mid-sized enterprise environments. Those are your starting candidates for Tier 1 classification review.
Add ASN as a field to your existing alert triage workflow. When an analyst investigates a suspicious IP, the ASN context, specifically the ASN's abuse history, registration age, and peer relationships, provides immediate pivot points that accelerate triage. This change costs nothing in infrastructure and pays dividends in analyst efficiency starting on day one.
This Week: Build Your ASN Allowlist Before Touching the Blocklist
Before you block a single ASN, build the allowlist. Catalog every external service your organization depends on and resolve it to its ASN. Payment processors, SaaS platforms, CI/CD infrastructure, partner API endpoints, cloud provider control planes, and CDN networks all have identifiable ASNs. Document them, assign them to your Tier 3 or a protected exemption tier, and store this as a structured dataset your firewall automation can consume.
This step prevents the most common operational failure in ASN filtering programs: blocking a business-critical ASN because it also hosts known-bad actors. AWS (AS16509), Cloudflare (AS13335), and Google (AS15169) all appear in threat actor infrastructure constantly. They also underpin enormous amounts of enterprise operations. Your allowlist ensures that blocking decisions on these ASNs happen deliberately, with scoped rules rather than blanket blocks.
Build the allowlist in a version-controlled repository. ASN-to-service mappings change as vendors migrate infrastructure, and you need an audit trail showing why specific ASNs were protected when a future incident reviewer asks.
This Week: Configure Passive ASN-Based Scoring in Your WAF or NGFW
Most modern next-generation firewalls and web application firewalls support custom reputation scoring based on source attributes. Before applying hard blocks, configure ASN-based scoring rules that increase the risk weight assigned to connections from Tier 1 and Tier 2 ASNs. Set thresholds so that traffic from high-risk ASNs triggers additional inspection, challenge pages, or elevated logging verbosity rather than outright drops.
This passive scoring phase accomplishes two things. It gives you operational data on false positive rates before any traffic is actually dropped, and it provides a test harness for validating your ASN risk taxonomy against real traffic patterns. Run this configuration for five to seven business days before advancing to active blocking rules.
This Quarter: Implement Tiered Enforcement With Automated Feed Updates
By the time you reach active enforcement, your taxonomy should be validated by several weeks of real traffic data and your allowlist should be confirmed as complete. The enforcement architecture for ASN-based filtering at scale requires three components working together.
First, an automated ASN feed ingestion pipeline that pulls updated ASN risk data on a scheduled basis, reconciles it against your internal taxonomy, and pushes updated rule sets to your enforcement points. Threat actor ASN usage shifts fast enough that a feed updated weekly is the minimum viable refresh rate for Tier 1 classifications. Daily is better for active campaigns.
Second, a firewall rule structure that enforces actions by tier. Tier 1 ASNs receive hard blocks on inbound connection attempts and triggered alerts on any outbound connections to their IP ranges. Tier 2 ASNs receive rate limiting, mandatory TLS inspection where applicable, and elevated log verbosity. Tier 3 ASNs receive normal processing with anomaly scoring active.
Third, a human review process for ASN classification changes. Automated feeds should be able to propose reclassifications, but a human analyst should confirm Tier 1 block additions before they go live. Misclassifying a CDN or cloud provider ASN as Tier 1 will create an outage, and automated systems are not yet reliable enough to prevent that entirely without human validation.
Integrating ASN Filtering With Broader Campaign Detection
The most operationally mature use of ASN intelligence is campaign detection rather than point-in-time blocking. When your enriched log data shows that a cluster of IPs hitting your perimeter over a forty-eight hour window all resolve to the same ASN, and that ASN shares registration patterns with infrastructure used in a known campaign, you have attribution context that per-IP analysis cannot provide.
The 2026 World Cup attack surface analysis published by several threat intelligence teams highlighted this dynamic explicitly. Phishing infrastructure, fake ticketing platforms, and credential harvesting pages were being spun up across a rotating set of hosting ASNs in Eastern Europe and Central Asia. Organizations that had those ASNs in their Tier 1 or Tier 2 enforcement tiers blocked or flagged the phishing domains before they received any malicious traffic. Organizations relying on URL reputation feeds caught the same domains hours to days later, after the campaigns had already completed initial credential collection cycles.
Campaign-level ASN correlation also supports threat hunting. When a threat intelligence report identifies ASN infrastructure used by a group, you can immediately query your historical logs for any connections to IP ranges within that ASN, regardless of whether those individual IPs appeared in any blocklist at the time of the connection. This retroactive analysis has caught staged compromises that looked clean during the initial infection phase.
Handling the Residential Proxy and VPN Problem
ASN filtering's most visible limitation is traffic that originates from high-reputation ASNs via residential proxies, VPN exit nodes, and compromised endpoint infrastructure. The 0ktapus campaign used SIM swapping and smishing to compromise credentials, with subsequent account access often occurring through residential ISP connections to avoid triggering ASN-based controls. Attackers with access to residential proxy networks can source traffic from hundreds of different ASNs simultaneously, defeating ASN-based filtering as a standalone control.
This limitation does not invalidate ASN filtering. It means ASN filtering needs to be layered with behavioral controls. An authentication attempt from a residential ISP ASN in a geography inconsistent with the user's baseline is suspicious on its own. That same authentication attempt accompanied by a fresh session, no cookie history, and a user agent string that does not match the user's historical pattern is a much stronger signal. ASN-based context feeds into this multi-factor behavioral scoring without being the sole determinant of trust.
For network perimeter controls specifically, ASN filtering degrades attack economics even when attackers can route around it. Maintaining bulletproof hosting infrastructure costs money. Routing all campaign traffic through residential proxies adds latency, reduces bandwidth, and increases operational complexity for the attacker. ASN controls that force adversaries to use more expensive infrastructure impose real costs on campaigns even when they do not stop them entirely.
Operationalizing ASN Data in SOC Workflows
The SOC integration layer is where ASN filtering programs either compound their value or stall out. Analysts need ASN data surfaced in context during investigation, not buried in raw log fields that require manual lookup.
Build enrichment automations that append the following data points to every IP-based alert: ASN number, ASN name, ASN registration country, ASN registration date, abuse contact response score, and current tier classification. Feed this enriched context directly into your ticketing and case management system so it appears in the alert summary without requiring analyst pivot steps.
For high-volume environments, build playbooks that auto-close or auto-escalate alerts based on ASN tier. A port scan from a Tier 1 ASN escalates immediately to analyst review. A port scan from a known cloud provider scanning service ASN can be auto-classified as low-priority noise and reviewed in batch. This triage automation preserves analyst time for the events that require human judgment.
Document your ASN taxonomy decisions and their rationale. When the California AG's 23andMe breach investigation and similar regulatory actions put security programs under scrutiny, documented, reasoned filtering decisions are substantially better than ad hoc blocklist additions with no recorded justification.
Metrics That Tell You Whether the Program Is Working
ASN filtering programs need outcome metrics to justify the operational overhead and to identify when the threat landscape has shifted enough to require taxonomy review.
- Blocked event volume by ASN tier: Track weekly blocked connection attempts attributable to Tier 1 ASN rules. Sustained high volume indicates active campaigns using that infrastructure. Sudden drops may indicate attacker pivot to new ASNs and warrant a taxonomy review.
- False positive rate by tier: Count legitimate business traffic inadvertently blocked by ASN rules weekly. A false positive rate above two percent on Tier 1 rules suggests a miscategorization that needs correction.
- Mean time to ASN reclassification: Measure how long it takes from the first threat intelligence report linking an ASN to a campaign until that ASN appears in your Tier 1 enforcement rules. Reducing this lag is the core operational goal of the automation pipeline.
- Incident correlation rate: Track how many confirmed security incidents involved source IP addresses that fell within a Tier 1 or Tier 2 ASN that was already in your taxonomy at the time of the incident. A high correlation rate validates the taxonomy. A low rate suggests you are blocking the wrong ASNs or that attackers have adapted their infrastructure selection.
Where to Start If Your Organization Has Not Touched This Yet
Start with enrichment, not enforcement. Spend the first two weeks adding ASN metadata to your existing log pipeline and building the visibility layer. The data you generate in that period will be more valuable to your initial taxonomy than any third-party ASN reputation list you can buy, because it will reflect your specific traffic mix and your specific threat exposure.
The Q1 2026 threat evolution data is consistent across multiple intelligence sources in showing that attack infrastructure is diversifying across ASNs faster than per-IP reputation feeds can track. Organizations that have built the ASN-level visibility layer will absorb that diversification as a manageable operational signal. Organizations that have not built it will continue experiencing the per-IP whack-a-mole dynamic that has characterized blocklist management for the past decade.
ASN-based filtering is not a replacement for other controls. It is an additional layer that raises the cost and complexity of attack infrastructure for adversaries while giving defenders a more durable intelligence handle on campaign activity than rotating IPs alone provide. The technical overhead to implement it is modest. The operational discipline to maintain it is the harder problem, and that discipline starts with classification before enforcement.
