The Incident That Started a Conversation
A mid-sized financial services firm running a customer-facing loan portal began noticing a pattern of credential stuffing traffic in early 2024. The attacks were distributed, low-and-slow, and originating from dozens of IP addresses. The security team applied geo-blocking rules, then added IP reputation feeds, then tightened rate limits. None of it solved the problem. The traffic kept coming, and it kept rotating through addresses that had no prior reputation history.
When the team finally pulled the upstream data, they found something interesting: roughly 70% of the malicious traffic was traceable to fewer than a dozen Autonomous System Numbers. The IPs changed constantly. The ASNs did not. Blocking at the ASN level cut the attack volume by over 60% within hours. The fix that should have been applied first came last, and it only arrived because someone thought to look at the network layer above the IP address.
This scenario illustrates a gap that affects many security teams: ASN-based filtering exists as a capability in most enterprise firewalls and WAFs, but it gets underused, misunderstood, or applied so carelessly that it causes operational problems. This article explains what ASN filtering is, how to implement it without breaking legitimate traffic, and how it fits into a layered threat response strategy informed by recent real-world attack campaigns.
What an ASN Actually Is and Why It Matters for Security
An Autonomous System Number is a globally unique identifier assigned to a collection of IP address blocks managed by a single administrative entity under a common routing policy. ASNs are assigned by Regional Internet Registries such as ARIN, RIPE NCC, APNIC, LACNIC, and AFRINIC. When traffic enters your network, every packet carries metadata that traces back to a source ASN, even if the specific IP address has never been seen before.
From a threat-filtering perspective, ASNs matter because attackers operate within infrastructure constraints. A threat actor running a large botnet, a bulletproof hosting operation, or a residential proxy service needs IP address space, and that space is anchored to ASNs. The 911 S5 botnet, one of the largest residential proxy networks ever dismantled, operated through a sprawling infrastructure that, when analyzed post-takedown, showed heavy concentration in specific ASNs tied to residential ISPs in Southeast Asia and compromised endpoint pools in North America. When law enforcement eventually seized and dismantled 911 S5, researchers found the ASN-level fingerprint had been visible for years before the takedown.
The 0ktapus campaign, which victimized over 130 organizations through phishing infrastructure and credential harvesting, relied on hosting providers and VPS services tied to a small set of ASNs. Security researchers at Group-IB and others identified that the command-and-control infrastructure was concentrated in specific hosting ASNs that could have been flagged proactively. Individual IPs rotated frequently; the ASNs were consistent.
How ASN Filtering Differs from IP Blocklisting
IP-based blocklisting targets specific addresses. ASN filtering targets the organizational or network entity responsible for a range of addresses. The two approaches are complementary but serve different purposes.
IP blocklisting is reactive and precise. You add a specific offending address and block it. The problem is that IP addresses are cheap and easily rotated. Botnets, proxy networks, and cloud-hosted attack infrastructure cycle through addresses fast enough to make IP blocklists feel like playing whack-a-mole.
ASN filtering is broader and more proactive. When you block ASN 12345, you block every IP address currently or subsequently allocated under that ASN. This is both its strength and its primary risk. A single ASN may contain millions of IP addresses, including legitimate users, business partners, and cloud services running alongside malicious actors on shared infrastructure.
The practical distinction matters most when dealing with large cloud providers. AWS, Google Cloud, Microsoft Azure, and similar platforms each operate under their own ASNs. Blocking the entire ASN of a major cloud provider because a few VMs on that infrastructure sent attack traffic would be an operationally disastrous overreaction. ASN filtering requires context and granularity, not a blunt on/off switch.
Attack Categories Where ASN Filtering Provides Real Value
Bulletproof Hosting Operators
Bulletproof hosting providers deliberately ignore abuse complaints and cater to criminal operations. These providers typically operate under small, obscure ASNs with minimal legitimate traffic. JanelaRAT, the financial RAT targeting users in Latin America, used infrastructure tied to bulletproof hosting ASNs to host its command-and-control servers. Blocking those ASNs at the network perimeter would have severed the C2 communication channel for infected hosts trying to beacon out, even if the individual C2 IP addresses were unknown at the time of infection.
Threat intelligence vendors maintain lists of ASNs associated with bulletproof hosting. Providers like Spamhaus maintain the Don't Route Or Peer (DROP) list, which contains ASNs that should have no legitimate routing relationships with normal networks. Applying DROP list ASNs as egress filtering rules prevents compromised internal hosts from reaching infrastructure hosted in these networks.
Residential Proxy Networks
Residential proxy services route attack traffic through IP addresses assigned to real consumer ISPs, making the traffic appear to come from legitimate home users. The 911 S5 network was a prime example, routing fraudulent traffic through millions of compromised residential endpoints. These proxies make IP reputation scoring ineffective because the exit IPs belong to regular consumer ASNs.
ASN filtering does not stop residential proxy traffic directly since the exit nodes belong to legitimate ISPs. However, analyzing inbound traffic by ASN distribution can reveal statistical anomalies. If your application normally sees 5% of traffic from a specific residential ISP's ASN and suddenly sees 40%, that ASN-level spike signals proxy abuse even when individual IPs appear clean.
Ransomware Initial Access Brokers
The rise of ransomware-as-a-service has created an ecosystem of initial access brokers who scan, compromise, and sell access to corporate networks. These brokers operate scanning infrastructure that often lives in specific hosting ASNs known for tolerating abuse. The VECT ransomware and wiper cases analyzed recently involved initial reconnaissance traffic that, in retrospect, traced back to ASNs with established abuse histories. Security teams that had ingested ASN threat intelligence as part of their detection stack flagged the reconnaissance earlier than those relying solely on IP reputation.
Industrial Control System Threats
The threat landscape for industrial automation systems in Q4 2025 highlighted continued targeting of operational technology networks through internet-exposed interfaces. Attackers scanning for Modbus, DNP3, and other OT protocol ports routinely use scanning infrastructure concentrated in specific ASNs. For organizations operating industrial environments with external-facing components, pre-emptively restricting inbound traffic to only known-good ASNs, including those of legitimate vendors, partners, and monitoring services, reduces the attack surface significantly without requiring individual IP management.
Implementation Approaches
Firewall and ACL-Based Blocking
Most enterprise firewalls support object-based IP range blocking. ASN ranges can be converted to CIDR blocks using tools like bgpview.io, whois queries, or the RIPE/ARIN APIs. The process involves querying the ASN for all announced prefixes, converting those to CIDR notation, and importing them into your firewall policy as a named object group.
The challenge is maintaining freshness. ASNs reassign, acquire, and announce new prefixes regularly. A blocklist based on ASN prefix data that is six months old may miss newly announced ranges or incorrectly block ranges that have been transferred. Automation is essential. Build a pipeline that queries prefix data on a regular cadence, weekly at minimum, and pushes updates to your firewall objects automatically.
For teams running Palo Alto Networks firewalls, the External Dynamic Lists (EDL) feature supports IP-based lists that can be auto-refreshed from a hosted URL. Maintaining an EDL endpoint that serves up-to-date ASN prefix CIDRs enables near-real-time blocking with minimal manual overhead. Fortinet, Check Point, and Cisco equivalents offer similar dynamic feed mechanisms.
WAF-Level ASN Filtering
Web application firewalls from vendors including Cloudflare, AWS WAF, Akamai, and Imperva support ASN-based rules natively. Cloudflare's Firewall Rules allow direct filtering on ip.gre.src.asnum and similar fields. This makes it straightforward to build rules like: challenge traffic from ASN 12345, or block traffic from ASNs flagged in a threat intelligence feed.
WAF-level filtering is preferable for web-facing applications because it allows graduated responses. Rather than hard-blocking all traffic from a suspicious ASN, you can apply CAPTCHA challenges, JavaScript challenges, or rate limiting specifically to flagged ASNs. This reduces false positive impact while still degrading the attacker's ability to operate at scale.
SIEM and Analytics Integration
Beyond active blocking, enriching your SIEM logs with ASN data transforms your detection capability. When every log entry for inbound connections includes the source ASN and the ASN's reputation score, analysts can pivot on ASN during investigations rather than chasing individual IPs.
This approach paid dividends during the LAPSUS$ investigation involving Checkmarx. Retrospective analysis showed that the threat group's infrastructure touched specific ASNs that other organizations had flagged in threat intelligence sharing communities. Teams that had ASN enrichment in their logs could identify early-stage activity that was invisible at the IP level because the IPs themselves had no reputation history.
Popular SIEM platforms support ASN enrichment through lookup tables or threat intelligence integrations. Splunk supports lookup commands that join log data with ASN tables. Elastic has GeoIP and ASN processors in its ingest pipeline. Microsoft Sentinel supports enrichment through watchlists and threat intelligence connectors.
Building an ASN Risk Scoring Model
Not all ASNs warrant binary allow/block treatment. A tiered risk model gives security teams flexibility to respond proportionally.
- Tier 1 (Block): ASNs appearing on Spamhaus DROP/EDROP, ASNs with documented bulletproof hosting history, ASNs with zero legitimate business use relative to your organization's profile.
- Tier 2 (Challenge/Scrutinize): ASNs with elevated abuse scores from threat intelligence providers, ASNs associated with residential proxy services, ASNs from high-risk hosting regions with limited business justification.
- Tier 3 (Monitor): Large cloud provider ASNs, major ISP ASNs with occasional abuse reports, ASNs that appear in threat data but also serve legitimate traffic to your platform.
- Tier 4 (Allow): Known partner ASNs, corporate network ASNs of key customers, internal infrastructure ASNs.
Maintaining this tiering requires input from multiple data sources: abuse complaint databases, threat intelligence feeds, your own historical traffic analysis, and business context from account management or customer success teams who know which ASNs correspond to key customers.
Data Sources for ASN Intelligence
Several public and commercial sources provide ASN threat intelligence:
- Spamhaus DROP and EDROP: Free lists of ASNs with no legitimate use, widely considered essential baseline.
- Team Cymru IP-to-ASN Mapping: Provides accurate ASN attribution for IP addresses, useful for enrichment pipelines.
- GreyNoise: Distinguishes between internet background noise scanners and targeted attack traffic, with ASN-level attribution.
- Shodan and Censys: Useful for understanding the service profile of an ASN before blocking it.
- BGPView and Hurricane Electric BGP Toolkit: Free tools for querying current ASN prefix announcements.
- Commercial threat intelligence platforms: Providers like Recorded Future, Mandiant, and CrowdStrike maintain curated ASN reputation data as part of broader IP intelligence offerings.
Operational Risks and How to Manage Them
ASN filtering carries real operational risks that security teams need to account for before deployment.
False Positives on Shared Infrastructure
The student loan data breach exposing 2.5 million records is a reminder that sensitive consumer data flows through cloud and hosting infrastructure shared with malicious actors. A financial institution blocking an entire hosting provider ASN because it was used in an attack campaign risks cutting off legitimate customers who use that same provider's services, including cloud-hosted banking applications, legitimate SaaS tools, or remote workers connecting through cloud desktops.
Mitigation involves scoping blocks carefully. Where possible, block specific ASN prefix subsets rather than entire ASNs. Use challenge-based responses before hard blocks. Maintain a process for exceptions that allows business owners to request whitelisting with documented justification.
ASN Reassignment and Collateral Changes
IP address blocks get transferred between ASNs through legitimate business transactions. A block you blocked because it was under a malicious ASN may later transfer to a legitimate operator. Without regular refresh of your ASN prefix data, you create stale blocks that affect innocent parties.
Automated refresh pipelines with regular auditing cycles address this. Set a review cadence for your highest-impact blocks, particularly those affecting large IP ranges, and validate that the business justification still holds.
Attacker Adaptation
Sophisticated threat actors can move their infrastructure to different ASNs. The 0ktapus group demonstrated operational agility in shifting infrastructure when specific hosting providers responded to abuse complaints. ASN filtering slows attackers down and increases their costs, but it does not permanently stop them. Treat it as one layer in a defense-in-depth strategy, not a terminal solution.
Integrating ASN Filtering into Incident Response
During an active incident, ASN data should be one of the first enrichments applied to attacker IP addresses. The workflow looks like this:
- Identify attacker IP addresses from logs, alerts, or threat intelligence.
- Query ASN attribution for each IP using Team Cymru, bgpview, or your SIEM enrichment pipeline.
- Cross-reference identified ASNs against threat intelligence feeds and abuse databases.
- If the ASN shows consistent malicious use with low legitimate traffic relevance, escalate to a temporary block at the firewall or WAF level.
- Document the block with the justification, ASN, affected prefix ranges, and expected review date.
- Monitor for attacker pivoting to new ASNs and repeat the process.
This workflow formalizes what the financial firm in the opening scenario eventually discovered through trial and error. Making it a documented procedure means the first instinct during a credential stuffing or scanning campaign is to look at the ASN layer, not just the IP layer.
Thinking About Egress, Not Just Ingress
Most teams apply ASN filtering to inbound traffic, but egress filtering on ASNs provides significant defensive value for detecting compromised internal hosts. Ransomware operators and RAT implants like JanelaRAT establish outbound connections to command-and-control infrastructure. That infrastructure lives in ASNs. Blocking egress to high-risk ASNs at the network perimeter prevents beaconing, data exfiltration, and command receipt even when the specific C2 IP is unknown.
Implementing egress ASN filtering requires knowing your expected outbound traffic patterns. Build a baseline of which ASNs your internal systems legitimately communicate with, including SaaS providers, update services, cloud resources, and business partner networks. Anything outside that baseline warrants scrutiny. Applying egress filtering to Spamhaus DROP list ASNs is a low-risk starting point since those ASNs have no legitimate reason to receive traffic from your environment.
What Good Looks Like in Practice
A mature ASN filtering program has several characteristics. The ASN intelligence data refreshes automatically on a regular schedule. Firewall and WAF rules are structured around named ASN objects rather than raw CIDR lists, making them readable and auditable. The SIEM enriches every inbound connection log with source ASN and ASN reputation data. There is a documented tiering model that specifies what action to take for each risk tier. Incident response procedures explicitly include ASN analysis as an early step. And there is a business exception process that allows legitimate traffic from flagged ASNs to be accommodated without dismantling the entire control.
Getting there does not require a large budget. The public data sources are free. The automation can be built with scripting skills most network security teams already have. The WAF and firewall capabilities already exist in tools most organizations run. The gap is usually awareness and process, not technology.
Final Thoughts
ASN-based threat filtering occupies a valuable middle ground between per-IP blocklisting and broad geographic blocking. It targets the infrastructure layer where attackers have real operational constraints while preserving more granularity than country-level controls. The threat campaigns making headlines, from the persistence of botnets like 911 S5 to the infrastructure patterns behind groups like 0ktapus, all share a characteristic: their attack infrastructure is more stable at the ASN level than at the IP level.
Security teams that build ASN awareness into their monitoring, filtering, and incident response workflows gain a durable advantage. Individual IPs will always change. The organizations operating malicious infrastructure change far more slowly. Filtering at the level where your adversary has the least flexibility is simply more efficient than filtering at the level they optimize for evading.
