The Problem Sitting in Your Inbound Traffic Right Now
Security teams spend considerable time chasing individual malicious IP addresses, building blocklists, and tuning signature-based rules. Meanwhile, entire Autonomous System Numbers (ASNs) operated by bulletproof hosting providers, compromised cloud tenants, and state-affiliated infrastructure keep rotating fresh IPs through the same network blocks, bypassing every IP-level control in place. The IP changes. The ASN does not.
ASN-based threat filtering treats the network operator itself as the unit of trust rather than the individual IP address. For cybersecurity professionals and IT administrators managing perimeter defenses, this shift in perspective changes both the scope of what gets blocked and the operational work required to maintain it responsibly.
This article addresses the practical mechanics of ASN filtering: what it catches, where it breaks, how to phase implementation without operational disruption, and what current threat activity makes it increasingly urgent to get right.
Why Individual IP Blocking Has a Structural Ceiling
Consider how modern attack infrastructure actually works. During Q1 2026, mobile threat statistics published by Kaspersky's research team documented continued growth in campaigns using dynamically allocated IPs across commercial cloud and hosting ASNs. The underlying attack tooling stays constant while the originating IP rotates on intervals as short as minutes. Traditional blocklists, even well-maintained ones updated in near real-time, operate in a permanent catch-up mode against this rotation pattern.
The Nimbus Manticore operations documented during the Iranian conflict period illustrated this clearly. Threat actors routed campaign infrastructure through a small set of hosting ASNs that offered minimal abuse response, rotating IP assignments while keeping the same ASN prefix ranges in use for weeks. Defenders who blocked individual IPs addressed symptoms. Defenders who identified and filtered the ASN ranges cut off the rotation mechanism itself.
ASN-based filtering works because network blocks assigned to an ASN represent a persistent organizational identity. A bulletproof hosting provider in Eastern Europe or a cloud tenant running unchecked abuse infrastructure carries its ASN across every IP it controls. When your filtering operates at the ASN level, IP rotation becomes irrelevant.
How ASN Filtering Actually Works in Practice
An ASN is a unique number assigned by a Regional Internet Registry (RIR) to a network operator. Each ASN controls one or more IP prefixes (CIDR blocks) that route through that operator's infrastructure. Border Gateway Protocol (BGP) routing tables map which IP ranges belong to which ASN at any given time.
Operationally, ASN-based filtering means maintaining a list of ASN numbers and dynamically resolving their current IP prefix assignments, then applying firewall or routing rules to those prefix blocks. The key distinction from static CIDR blocking is the dynamic resolution. ASN prefix assignments change as operators acquire, release, or renumber IP space. A static CIDR list of a known-bad ASN from six months ago may miss current assignments or incorrectly block IPs that have since moved to a legitimate operator.
Tools and data sources that support this workflow include:
- BGPView and RIPE NCC: Provide current prefix-to-ASN mappings through queryable APIs. These are the authoritative sources for resolving what IP blocks an ASN currently controls.
- Team Cymru's IP-to-ASN service: Widely used in security tooling for bulk lookups, particularly useful when enriching SIEM data with ASN context during investigations.
- MaxMind GeoIP2 and IPinfo databases: Include ASN fields in their enrichment datasets, enabling integration with log analysis and SIEM platforms for real-time classification.
- Firewall vendor integrations: Palo Alto Networks, Fortinet, and Check Point all support dynamic address lists or feed mechanisms that can ingest ASN-derived prefix lists and apply policy automatically.
Building a Tiered ASN Risk Classification
Applying blanket blocks across entire ASNs without tiering creates operational risk. Some ASNs host a mix of legitimate and malicious traffic because they serve large cloud platforms or shared hosting environments where tenant abuse is common but the provider itself is not adversarial. Amazon AWS, Microsoft Azure, and Google Cloud all carry ASNs from which significant amounts of scanning, credential stuffing, and abuse traffic originate, alongside enormous volumes of legitimate enterprise traffic.
A workable tiered model separates ASNs into three categories:
- Tier 1 - High-confidence block: ASNs operated exclusively or primarily for bulletproof hosting, with documented histories of non-response to abuse complaints and near-zero legitimate traffic from your organization's perspective. These include providers in jurisdictions with minimal cybercrime enforcement cooperation and ASNs that appear repeatedly in threat intelligence feeds with no corresponding legitimate business relationships.
- Tier 2 - Alert and monitor: ASNs associated with commercial VPN providers, shared hosting, and cloud tenants where abuse is common but so is legitimate use. Traffic from these ASNs triggers heightened inspection, additional authentication requirements, or rate limiting rather than outright blocking.
- Tier 3 - Context-dependent: Large cloud ASNs and major CDN providers where the risk profile depends entirely on which specific services your organization uses and whether inbound traffic from those ASNs serves a legitimate business function.
Building this tiering requires correlating threat intelligence feeds with your organization's actual traffic patterns. Start by pulling 30 days of inbound connection logs, enriching each source IP with its ASN, and ranking ASNs by connection volume against known-bad indicators. The ASNs generating high volumes of blocked, rate-limited, or authentication-failed connections with no corresponding successful legitimate sessions are your Tier 1 candidates.
Today: Immediate Actions for Defenders
The fastest operational win available right now is ASN enrichment across existing log and alert data. Before changing a single firewall rule, add ASN context to your current visibility layer. Configure your SIEM to resolve the ASN for every source IP appearing in authentication logs, web application firewall events, and intrusion detection alerts. Most platforms support this through lookup tables or threat intelligence integrations.
Once ASN data is flowing, build a dashboard showing your top 20 source ASNs for failed authentication attempts, blocked connection attempts, and web scanning activity. In most enterprise environments, three to five ASNs account for the majority of hostile inbound traffic. This data provides the evidence base for filtering decisions and prevents the political problem of blocking ASNs on intuition rather than demonstrated traffic analysis.
For immediate blocking, focus on ASNs that meet all three of the following criteria: they appear in at least two independent threat intelligence feeds as associated with malicious infrastructure, they generate zero successful legitimate sessions in your logs over the past 30 days, and your organization has no business relationships with any services hosted on them. Blocking these carries near-zero collateral risk.
This Week: Operationalizing the Feed Pipeline
ASN filtering degrades quickly without a mechanism to keep prefix lists current. An ASN that controlled 50 IP prefixes in January may control 80 in June as it acquires additional space, or 30 in June if blocks were revoked following abuse complaints. Filtering decisions based on stale prefix data either miss current infrastructure or block IPs that have moved to unrelated legitimate operators.
Build an automated pipeline that performs the following on a daily schedule:
- Queries BGP data sources for current prefix assignments for every ASN in your blocklist.
- Diffs the current prefix list against the previous day's list to identify added and removed blocks.
- Updates firewall address objects or dynamic feed endpoints with the current prefix set.
- Logs all changes for audit purposes and triggers alerts when prefix counts change significantly (indicating possible ASN renumbering or hijacking events).
Most enterprise firewalls support external dynamic lists or feed-based address groups that update automatically when the source URL changes. Hosting your ASN-derived prefix lists on an internal feed server allows the firewall to pull updates without manual intervention. For environments using infrastructure-as-code, store the prefix generation scripts in version control alongside firewall policy definitions so changes are reviewable and reversible.
The 0ktapus threat group campaigns that victimized over 130 organizations used infrastructure spread across a small set of hosting ASNs. Organizations that had automated ASN-to-prefix resolution in their filtering stack could apply a single ASN block and cover the entire rotated IP range used across those campaigns. Organizations relying on manually maintained IP blocklists spent the operational cycle chasing individual addresses as they rotated.
Handling Major Cloud ASNs Without Breaking Operations
AWS, Azure, and Google Cloud present the hardest filtering problem in ASN-based threat management. The same ASNs that deliver legitimate SaaS traffic, cloud-hosted business applications, and partner API integrations also originate enormous volumes of scanning, credential stuffing, and exploitation attempts from compromised or abusively-provisioned tenants.
Blanket blocking of major cloud ASNs creates an operational emergency within hours as business-critical services go dark. The practical approach is directional and service-specific filtering rather than blanket blocks.
For inbound web application traffic from major cloud ASNs, apply rate limiting and require completed TLS handshakes with validated certificate chains rather than blocking. Layer in behavioral analysis that triggers step-up authentication for sessions originating from cloud ASN ranges when those sessions request sensitive endpoints. Many web application firewall platforms support ASN-aware rate limiting rules that treat cloud-ASN traffic differently from direct residential or enterprise ASN traffic without blocking it outright.
For authentication endpoints specifically, cloud ASN source IPs attempting authentication where no prior successful session from that ASN exists in the user's history warrant additional verification. This addresses the credential stuffing problem, where attackers specifically use cloud infrastructure to distribute authentication attempts across thousands of IPs, while preserving access for legitimate users who may work from cloud-hosted VDI or remote access environments.
This Quarter: Building ASN Threat Intelligence Into Your Broader Program
The 2026 World Cup creates a predictable surge in infrastructure abuse as threat actors register and provision attack infrastructure using legitimate hosting providers, leveraging major events as social engineering themes and scaling attack capacity ahead of high-value campaigns. Similar patterns emerged ahead of major geopolitical events and large-scale sporting competitions in previous years. Security teams have a defined window before the event-driven campaign surge to audit their ASN filtering coverage and close gaps.
Proactive ASN intelligence work this quarter means building relationships with threat intelligence sources that provide early warning on emerging malicious ASN infrastructure. This includes:
- Monitoring abuse.ch, Spamhaus, and SANS Internet Storm Center feeds for newly identified bulletproof hosting ASNs and comparing them against your current blocklist coverage.
- Participating in ISACs relevant to your sector, which often distribute ASN-level threat indicators ahead of their public availability in commercial feeds.
- Tracking ASN registration activity in RIR databases for newly registered ASNs showing patterns consistent with bulletproof infrastructure (minimal contact information, rapid prefix acquisition, registration in jurisdictions with poor abuse response).
Build a quarterly review process that re-evaluates every ASN in your blocklist against current traffic data. ASNs that have been cleaned up by their operators, changed ownership, or are no longer generating hostile traffic should be reviewed for potential removal. Blocklist accumulation without pruning creates firewall rule bloat, increases packet processing overhead, and eventually degrades performance on high-throughput links.
Integration Points With Your Existing Security Stack
ASN filtering works best when it feeds into the broader detection and response workflow rather than operating as a standalone block-or-allow mechanism. Several integration points deliver outsized value.
SIEM enrichment: Every alert should carry ASN context for the source IP. Analysts investigating an alert from a known-bulletproof-hosting ASN have a different initial hypothesis than analysts investigating traffic from a residential ISP ASN. This context reduces triage time by orienting the investigation before the analyst opens the first log entry.
Threat hunting queries: Build standing queries that identify traffic from ASNs appearing in current threat feeds that is not already covered by your blocklist. This catches cases where a threat actor uses an ASN that hasn't yet reached Tier 1 classification but is generating early-stage reconnaissance traffic against your environment.
Incident response playbooks: When a confirmed intrusion is under investigation, immediately query the attacker's infrastructure IPs for ASN associations and add those ASNs to your monitoring tier. In many campaigns, the same infrastructure ASN serves multiple victims or is used across multiple attack phases. Blocking the ASN during an active incident contains lateral movement and prevents additional command-and-control channels from establishing.
Vulnerability management prioritization: During the April 2026 CVE landscape activity period, exploitation attempts for newly disclosed vulnerabilities concentrated heavily in specific hosting ASNs used by exploitation-as-a-service operations. Organizations with ASN telemetry in their vulnerability management workflow could identify which CVEs were being actively targeted against their exposed services by correlating exploit attempt source ASNs with known exploitation infrastructure.
Measuring Whether Your ASN Filtering Is Actually Working
Metrics for ASN filtering effectiveness need to go beyond raw block counts. High block counts may indicate a well-tuned policy or may indicate that legitimate traffic is being incorrectly classified. The meaningful metrics are:
- False positive rate: Track support tickets and user-reported access failures that trace back to ASN blocking decisions. A well-calibrated policy should generate very few false positives after the initial tuning period.
- Coverage ratio: Measure what percentage of hostile traffic in your IDS and WAF logs originates from ASNs currently in your Tier 1 or Tier 2 classification. This tells you whether your threat intelligence sources are covering the ASNs actually attacking your environment.
- Time-to-block for emerging ASNs: When a new bulletproof hosting ASN is identified in threat intelligence feeds, measure how long before your filtering policy reflects it. Reducing this lag is one of the primary operational goals of ASN filtering automation.
- Prefix list staleness: Track how often your prefix resolution pipeline runs and whether prefix counts for monitored ASNs are changing, indicating your data is current rather than stale.
Where ASN Filtering Reaches Its Limits
ASN filtering handles a specific part of the threat landscape effectively and reaches its limits in equally specific ways. Nation-state actors with access to compromised infrastructure in legitimate residential ISP ASNs, as documented in multiple advanced persistent threat campaigns, operate from ASNs that carry enormous volumes of legitimate traffic. Filtering at the ASN level against residential ISPs causes collateral damage disproportionate to the security benefit.
Residential proxy networks, increasingly used by threat actors to distribute attack traffic across consumer-grade ASNs, present a similar challenge. The ASN belongs to a legitimate ISP. The individual IPs are compromised or voluntarily enrolled residential nodes. ASN filtering provides no leverage here; behavioral analysis and session-level anomaly detection handle this traffic pattern more effectively.
The practical conclusion is that ASN filtering belongs in a layered defense architecture where it handles the high-confidence, bulk-noise end of the threat spectrum, freeing analyst attention and filtering capacity for the harder problems that require behavioral and contextual analysis. Used as the sole filtering mechanism, it leaves gaps. Used as a foundational layer under behavioral analysis, anomaly detection, and threat intelligence correlation, it significantly reduces the noise that degrades everything else.
For organizations still building out their filtering stack, ASN-based filtering delivers the best return on implementation effort in the early phases of program maturity. It is operationally straightforward to implement, directly addresses the IP-rotation tactics most commonly used by high-volume threat actors, and provides enrichment data that makes every other layer of the security stack more effective.
