When the Attack Surface Starts at the Network Boundary
In mid-2026, the Cavern Manticore campaign gave threat intelligence teams something unusual: a modular command-and-control framework that rotated across a specific cluster of Iranian hosting providers, each operating under a small set of autonomous system numbers. Analysts tracking the campaign noticed that the C2 infrastructure, despite frequent IP rotation, kept re-emerging from the same ASNs. The IPs changed. The ASNs did not. Teams that had built ASN-level awareness into their filtering stack caught re-emerging nodes before they could re-establish persistence. Teams operating purely on IP reputation feeds watched the same threat actors cycle back in under new addresses.
This distinction, between filtering at the IP layer and filtering at the autonomous system layer, defines one of the most underutilized defensive controls available to security operations today. ASN-based threat filtering treats the network provider, not the individual address, as the unit of analysis. That shift in perspective changes what defenders can see, what they can block, and how quickly they can respond when an attacker pivots infrastructure.
What an ASN Actually Represents and Why It Matters for Defense
An Autonomous System Number is a globally unique identifier assigned to a collection of IP prefixes under the control of a single administrative entity. That entity might be an internet service provider, a cloud hosting company, a university, a content delivery network, or a dedicated hosting provider that rents infrastructure to customers. The Border Gateway Protocol uses ASNs to route traffic across the global internet.
From a defensive standpoint, ASNs carry context that individual IP addresses cannot. A single ASN may control thousands or hundreds of thousands of IP addresses. When a threat actor rents a virtual private server, compromises a cloud instance, or cycles through residential proxy pools, they operate within an ASN. The IP address rotates. The ASN often persists across campaigns, across threat actors sharing infrastructure, and across time.
Recorded Future's tracking of advanced persistent threat groups has consistently shown that nation-state actors and organized cybercriminal groups demonstrate preference for specific hosting environments. Some prefer bullet-proof hosting providers in particular jurisdictions. Others use legitimate cloud providers but cluster within specific ASNs tied to reseller accounts. Tracking these patterns at the ASN level gives defenders a coarser but more durable signal than IP-level reputation alone.
Telemetry Patterns That Surface ASN-Level Threat Concentration
Before implementing ASN filtering, teams need a clear picture of what their own logs reveal. Most organizations already collect the data necessary to build this picture. The analysis requires joining it correctly.
Start with authentication logs and web access logs. Extract source IP addresses for all failed authentication attempts, high-rate scanning events, and known-malicious requests over a rolling 30-day window. Resolve each IP to its originating ASN using a reliable database such as MaxMind, IPinfo, or the Team Cymru IP-to-ASN mapping service. Then aggregate by ASN and count event volume.
What defenders typically find is concentration. The majority of hostile traffic comes from a small number of ASNs. In practice, security teams reviewing this aggregation frequently discover that 10 to 20 ASNs account for 60 to 80 percent of all observed hostile activity. Some of those ASNs are well-known bullet-proof hosting providers. Others are legitimate cloud providers that threat actors abuse because the onboarding friction is low and attribution is difficult.
The WSzero DDoS family, which reached its fourth version in 2026 exploiting 21 distinct vulnerabilities, demonstrated this concentration clearly. Infrastructure analysis of WSzero campaign traffic showed consistent origination from a handful of hosting ASNs used to stage the initial exploit distribution. Defenders with ASN-level telemetry could identify the staging infrastructure faster than those waiting for individual IP reputation updates to propagate.
Once you have your concentration map, cross-reference it against three additional data sets. First, compare your high-volume hostile ASNs against publicly available abuse databases such as AbuseIPDB and the Spamhaus Don't Route Or Peer list, which operates at the ASN and prefix level. Second, check whether any of those ASNs appear in threat intelligence feeds related to active campaigns. Third, review whether any high-volume ASNs are also sources of legitimate business traffic for your organization, which is the factor that determines whether hard blocking is appropriate or whether rate-limiting and enhanced inspection make more sense.
Building the Filtering Architecture
ASN-based filtering can be implemented at several layers of your stack, and the right placement depends on your infrastructure and your risk tolerance.
Edge Firewalls and Border Routers
The most direct implementation is at the network perimeter. When you have identified ASNs that generate exclusively hostile traffic with zero legitimate business use, prefix-level blocking at the border router or edge firewall is appropriate. BGP blackhole routing and firewall prefix lists both accomplish this. Maintain these lists in a version-controlled configuration file so changes are auditable and reversible.
The operational challenge at this layer is scale. An ASN might announce dozens or hundreds of prefixes. Manual maintenance of prefix lists becomes error-prone at volume. Automate the enrichment pipeline: when an ASN is approved for blocking, a script should pull the current prefix list from a routing database such as the RIPE NCC or ARIN, validate it, and push the updated block list to your perimeter controls. Schedule daily re-validation because prefix announcements change.
Web Application Firewalls and API Gateways
For organizations running public-facing web applications and APIs, the WAF or API gateway layer offers more granular control than pure network blocking. Rather than dropping traffic entirely, you can apply differentiated treatment based on ASN classification.
Traffic from ASNs associated with cloud hosting providers, for example, warrants heightened inspection even when it does not justify outright blocking. A significant portion of credential stuffing traffic originates from cloud ASNs because attackers buy compute to run their tools. The Scattered Spider operators, who pleaded guilty in 2026, demonstrated sophisticated use of cloud and VPN infrastructure to obscure their origins. A WAF rule that applies stricter rate limits and additional challenge requirements to requests from cloud hosting ASNs, while allowing legitimate users through with normal friction, meaningfully degrades attacker economics without blocking legitimate cloud-origin traffic wholesale.
Implement ASN-based rate limiting tiers at the API gateway level. Traffic from residential ISP ASNs gets a standard rate limit. Traffic from known data-center and hosting ASNs gets a tighter limit. Traffic from ASNs that appear on your hostile concentration list gets the tightest limit or a CAPTCHA challenge. This tiered approach preserves access for legitimate users while making automation expensive for attackers.
SIEM Enrichment and Detection Rules
ASN data belongs in your SIEM alongside every log event that carries a source IP address. Most modern SIEM platforms support lookup tables or enrichment pipelines. Build an enrichment stage that appends ASN number, ASN name, and an internal classification tag to every ingested event. Classification tags might include categories such as residential-ISP, cloud-provider, hosting-provider, known-hostile, and tor-exit-adjacent.
With enrichment in place, detection rules become significantly more precise. Instead of alerting on any authentication failure above a threshold, alert on authentication failures from cloud-provider ASNs above a lower threshold, or on any authentication success preceded by failures from a known-hostile ASN. The student loan breach that exposed 2.5 million records in 2026 followed a pattern where credential stuffing preceded account takeover. ASN-enriched authentication logs would have surfaced the hosting-provider concentration of the stuffing traffic as an early indicator.
Operationalizing ASN Intelligence for Ongoing Campaigns
Static ASN block lists decay quickly. Threat actors migrate infrastructure, legitimate providers clean up abuse, and new hostile hosting providers emerge. The operational model needs to treat ASN filtering as a living control rather than a configuration artifact.
Establish a weekly review cycle for your ASN concentration data. Pull fresh telemetry, re-run the aggregation, and compare the current top-hostile-ASN list against last week's. ASNs entering the top tier for the first time warrant immediate investigation. ASNs dropping off the list may indicate that the threat actor moved infrastructure, which is itself an intelligence signal worth tracking.
Integrate ASN tracking into your incident response workflow. When an active intrusion or campaign is detected, one of the first enrichment steps should be resolving the attacker's observed IP addresses to ASNs and checking whether those ASNs appear in your existing hostile concentration data. If they do, the ASN block or enhanced-inspection rule should already be active. If they do not, the new ASN should be flagged for immediate review and potentially added to the enhanced-inspection tier while the investigation proceeds.
The npm threat landscape, which received an updated analysis in July 2026, highlighted how supply chain attacks often use staging infrastructure hosted in a small number of ASNs to exfiltrate data or deliver payloads. Teams with ASN-level monitoring on outbound connections from their build pipelines could detect anomalous connections to unusual hosting ASNs as an early warning of compromise.
Handling Legitimate Traffic From High-Risk ASNs
The most common objection to ASN filtering is the false-positive risk. Legitimate users connect through cloud providers. Remote workers use VPN services that route through data-center ASNs. Business partners may operate from hosting environments that share ASN space with threat actors. A blocking-only approach to ASN filtering creates operational friction that damages the control's sustainability.
The practical solution is a risk-tiered response model rather than a binary allow-or-block decision. For ASNs that generate hostile traffic but also serve legitimate users, apply progressive friction rather than hard blocks. Require multi-factor authentication from these ASNs. Apply tighter session controls. Log all successful authentications from these ASNs at a higher verbosity level and route those logs to a dedicated detection rule that looks for post-authentication abuse patterns.
For your most sensitive administrative interfaces and APIs, consider whether cloud-provider and hosting-provider ASNs should be permitted at all outside of explicitly allow-listed specific prefixes. Administrative consoles, privileged API endpoints, and internal tooling rarely have legitimate use cases that require access from anonymous hosting infrastructure. Restricting these high-value targets to residential ISP ASNs and explicitly approved corporate network ranges reduces the attack surface substantially without affecting most legitimate users.
Correlating ASN Data With Threat Actor Infrastructure Tracking
ASN filtering becomes significantly more powerful when combined with structured threat actor infrastructure tracking. Groups like those behind the Cavern Manticore framework demonstrate infrastructure preferences that persist across campaigns. When threat intelligence identifies the ASNs favored by a tracked threat actor, defenders can pre-position controls before the next campaign begins.
Recorded Future's APT tracking work, along with open-source infrastructure analysis from groups like Shadowserver and Team Cymru, regularly produces ASN-level indicators tied to specific threat actors. Incorporate these into your ASN classification system as a distinct category. When an ASN is associated with a tracked threat actor's infrastructure, it warrants more aggressive treatment than an ASN that simply hosts high volumes of generic scanning traffic.
For security operations teams supporting organizations in sectors targeted by nation-state actors, this correlation work is particularly valuable. The AI Security Report for 2026 noted that AI-assisted infrastructure generation is accelerating the speed at which threat actors can spin up new campaign infrastructure. The ASN layer remains one of the controls where this acceleration has limited effect, because acquiring new ASN registrations requires interaction with regional internet registries and takes time that IP address acquisition does not.
Metrics That Tell You Whether the Control Is Working
Like any security control, ASN filtering needs measurement to remain credible and to justify the operational investment in maintaining it.
Track the following metrics on a weekly basis. First, the volume of requests blocked or challenged at each ASN filtering tier, segmented by ASN and by application. Rising block volume from a specific ASN may indicate an active campaign targeting your environment. Second, the false-positive rate, measured as the ratio of successfully challenged or blocked requests that subsequently passed manual review and were determined to be legitimate. A rising false-positive rate indicates that your classification data is stale or that a legitimate service has moved into a previously hostile ASN space. Third, the time from ASN first observed in hostile telemetry to ASN classification update in your filtering stack. This measures the operational latency of your ASN intelligence pipeline and highlights where automation improvements would have the most impact.
Review your ASN block list quarterly against current routing data. ASNs are occasionally reassigned or split. A block entry that once applied to a hostile hosting provider may, after a routing change, apply to a completely different organization. Automated prefix validation against current routing databases catches these drift scenarios before they cause unintended blocking.
Practical Starting Point for Teams Without Existing ASN Filtering
If your organization has no current ASN filtering capability, the fastest path to value follows a specific sequence.
First, enable ASN enrichment in your SIEM or log aggregation platform this week. This requires no blocking decisions and carries no operational risk. It simply adds context to existing log data. Run the enrichment for two weeks and generate your hostile-ASN concentration report.
Second, identify the three to five ASNs with the highest hostile event volume and zero confirmed legitimate traffic. Submit a change request to apply enhanced rate limiting to these ASNs at your WAF or API gateway. This is a low-risk first implementation that reduces attacker throughput without creating hard blocks.
Third, identify any ASNs on the Spamhaus DROP or EDROP list that are currently sending traffic to your environment. These lists represent ASNs with no legitimate routing purpose that have been designated for blocking by community consensus. Hard-blocking these at the perimeter is a low-risk, high-confidence action.
Fourth, integrate ASN resolution into your incident response runbooks so that every investigation involving external IP addresses automatically produces ASN context as part of the initial triage.
This four-step sequence builds the operational habit and the data foundation before making aggressive blocking decisions. The data you collect in the first 30 days will make every subsequent filtering decision more precise and more defensible.
Where ASN Filtering Fits in the Broader Defensive Stack
ASN filtering addresses a specific problem: reducing the attack surface presented to threat actors who operate from identifiable network infrastructure. It does not replace IP reputation systems, which provide finer-grained historical signal about specific addresses. It does not replace behavioral analytics, which detect threats that originate from otherwise unremarkable infrastructure. It does not replace endpoint detection, which catches threats that have already passed the network perimeter.
What ASN filtering provides is a durable, infrastructure-level signal that degrades attacker effectiveness across campaigns rather than just in response to individual incidents. When a threat actor moves from one compromised IP to another within the same ASN, the filtering control remains effective. When a new campaign emerges from infrastructure in a pre-classified hostile ASN, the control activates without requiring a new signature or rule update.
CISOs managing AI risk exposure in 2026 face a threat environment where the speed of attacker infrastructure generation is accelerating. Controls that operate above the IP level, targeting the networks and providers that host attacker infrastructure, provide a meaningful counterweight to that acceleration. ASN-based filtering, implemented as a living operational program rather than a static configuration, represents one of the more cost-effective controls available at this layer of the stack.
