The Infrastructure Pattern That Keeps Showing Up
In Q1 2026, threat intelligence teams tracking mobile malware campaigns documented a recurring pattern: attack infrastructure consistently clustered within a small set of autonomous systems. The same ASNs appeared across unrelated campaigns — credential stuffing runs, phishing kit hosting, and command-and-control nodes for mobile implants all shared hosting providers that had earned a reputation for minimal abuse response. This was reinforced by reporting on Nimbus Manticore operations during the Iranian conflict period, where offensive tooling was staged and rotated across a predictable set of ASNs tied to specific bulletproof hosting ecosystems.
This is the core observation that makes ASN-based threat filtering worth taking seriously: attackers pick infrastructure for reasons that are visible to defenders. Low-cost VPS providers with weak abuse desks, residential proxy networks aggregated under a handful of ASNs, and commercial hosting companies that dominate malware delivery infrastructure all leave fingerprints at the network routing layer before a single malicious packet reaches your perimeter.
What an ASN Actually Tells You About Risk
An Autonomous System Number identifies a collection of IP prefixes under common routing policy, typically operated by a single organization. ISPs, cloud providers, enterprise networks, universities, and hosting companies each operate one or more ASNs. When you pull BGP data on a suspicious IP, the ASN tells you who is ultimately responsible for routing that address block.
For defenders, this matters because the abuse history and operational posture of the hosting organization is often more predictive of threat likelihood than any individual IP reputation score. A single IP flagged for scanning today will be rotated tomorrow. The ASN behind it will remain consistent for months or years. Attackers who burned through dozens of IPs across a campaign that targeted 130 firms — a pattern consistent with what was documented in the 0ktapus reporting — still revealed infrastructure patterns that ASN-level analysis could have surfaced earlier than individual IP blacklisting did.
Cloud providers complicate this picture. AWS, Google Cloud, and Azure each announce massive address blocks across multiple ASNs, and legitimate business traffic shares those blocks with attacker-rented instances. Raw ASN blocking on major cloud ASNs generates enormous false positive rates. The filtering logic has to account for this, which is where most implementations either overcorrect or underperform.
Building a Risk Tier Model Around ASN Data
Effective ASN filtering starts with categorization, not binary blocking. The goal is to assign a risk tier to every ASN that generates meaningful inbound traffic, then apply differentiated controls based on that tier.
A practical three-tier model looks like this:
- High-risk ASNs — Bulletproof hosting providers, known residential proxy aggregators, and ASNs that appear repeatedly in threat intelligence feeds with minimal or no legitimate business traffic in your environment. Traffic from these sources warrants aggressive rate limiting, CAPTCHA challenges, or outright blocking depending on the service exposed.
- Medium-risk ASNs — Major cloud providers, VPN service providers, and hosting companies with mixed abuse histories. Traffic warrants enhanced logging, behavioral analysis, and lower authentication failure thresholds before lockout triggers.
- Baseline ASNs — ISPs, enterprise networks, universities, and other organizations with clean or minimal abuse history. Standard controls apply, with alerting on anomalous volumes.
This model requires ongoing maintenance. An ASN that was clean six months ago may acquire a new abuse profile after a change in ownership or acceptable use policy enforcement. Feeding threat intelligence into your tier assignments on a regular schedule is what keeps the model accurate.
Data Sources That Make ASN Filtering Operational
Several data sources are practical to integrate for an operational ASN filtering program:
- BGP routing tables and WHOIS — Tools like Team Cymru's IP-to-ASN mapping, Hurricane Electric's BGP Toolkit, and RIPE's routing information service provide the foundational mapping between IP addresses and their announcing ASNs.
- Commercial threat intelligence feeds — Services from providers like Recorded Future, Mandiant, and CrowdStrike include ASN-level attribution for tracked threat groups and infrastructure clusters. These are worth the investment for environments with a dedicated threat intelligence function.
- Open-source abuse tracking — Spamhaus, AbuseIPDB, and similar public resources aggregate abuse reports and often surface ASN-level abuse scores that complement commercial feeds.
- Your own telemetry — Authentication logs, web application firewall events, and network flow data generate internal ASN profiles based on what you actually observe. An ASN that produces 80% of your credential stuffing attempts is high-risk for your environment regardless of what a feed says.
The most operationally effective programs combine all four. External feeds give you early warning on ASNs that have been abused elsewhere. Internal telemetry tells you which ones are targeting you specifically.
Implementation at the Firewall and WAF Layer
Once your tier model is built and your data sources are feeding it, the controls themselves live at several points in the stack.
At the network perimeter, ASN-based filtering is implemented through BGP communities if your upstream provider supports it, or through firewall rules built from IP prefix lists derived from routing data. The prefix list approach requires automation — manually maintaining IP lists for even a small number of ASNs is operationally unsustainable given how frequently prefix announcements change. Tools like bgpq4 can generate firewall-compatible prefix lists from IRR data, and integrating these into a CI/CD pipeline for firewall rule updates keeps the lists current.
At the web application firewall layer, most enterprise WAF products support ASN-based policy. Cloudflare's WAF, AWS WAF, and F5 Advanced WAF all provide mechanisms to apply different rule sets based on the ASN of the source IP. A common pattern is to apply challenge pages or stricter rate limits to requests originating from high-risk ASNs while allowing normal traffic from baseline ASNs through without additional friction.
For authentication endpoints specifically, ASN risk scoring should feed directly into authentication policy. Login attempts from a bulletproof hosting ASN with no prior legitimate user sessions from that ASN warrant immediate step-up authentication or blocking, independent of whether the credentials are valid. This closes a gap that pure IP reputation blocking leaves open: an attacker rotating across fresh IPs within the same high-risk ASN will evade IP-level controls but remain visible at the ASN level.
Handling Cloud Provider ASNs Without Breaking Legitimate Traffic
The practical challenge most teams run into is that legitimate users increasingly access services from cloud and VPN infrastructure. Remote workers use corporate VPN concentrators, developers test from cloud instances, and SaaS tools make API calls from cloud provider IP ranges. Blocking major cloud ASNs outright creates operational damage.
Several approaches manage this without abandoning the filtering signal:
First, use session context. A first-time authentication from an AWS ASN with no session history for that user account is different from a recurring API call from the same ASN used by a known service integration. Your authentication and API gateway logic should factor in whether the ASN has appeared in prior successful sessions for that account or service credential.
Second, apply tighter behavioral thresholds rather than categorical blocks. Cloud ASN traffic that triggers authentication failure rates above a low threshold — say, five failures per hour per ASN prefix — warrants automatic rate limiting even if the individual IPs look clean. This catches credential stuffing operations that rotate IPs within the same cloud ASN block.
Third, maintain allowlists for specific prefixes within cloud ASNs that correspond to known service integrations. If your payment processor's API calls originate from a specific AWS prefix in us-east-1, that prefix can carry a higher baseline trust than the broader AWS ASN.
Real-World Scenario: Filtering During a Sustained Credential Campaign
Consider a mid-size financial services organization that observed a spike in authentication failures against their customer portal in late 2025. Initial analysis flagged hundreds of individual IPs across multiple countries. IP-level blocking was applied and traffic shifted within hours to fresh IPs. The credential stuffing continued.
When the security team pulled ASN data on the attacking IPs, the pattern became clear: approximately 70% of attack traffic was originating from five ASNs associated with residential proxy networks. These networks aggregate real residential IP addresses, making individual IPs appear legitimate while the controlling infrastructure remains constant at the ASN level.
Applying rate limiting rules scoped to those five ASNs — rather than individual IPs — reduced attack volume by 65% within two hours and held under continued attack rotation. The remaining 30% came from a mix of cloud and VPN ASNs where the organization applied step-up authentication rather than rate limiting to avoid blocking legitimate users.
This pattern, proxied attacks through residential ASNs combined with cloud-hosted attack tooling, maps directly to documented tactics from multiple threat groups tracked in 2025 and 2026 reporting.
Integrating ASN Filtering Into Existing Security Operations
ASN filtering generates data that benefits the broader security operations function beyond its immediate blocking utility.
Enriching alerts with ASN context changes how analysts triage. An authentication alert from a residential proxy ASN with a known abuse history reads differently than one from a major ISP, even if the individual IP is clean in available feeds. Building ASN enrichment into your SIEM or SOAR pipeline using lookup tables derived from BGP data gives analysts this context at alert time rather than requiring manual investigation.
Threat hunting benefits from ASN visibility as well. Querying your network flow and authentication logs for traffic volumes by ASN, then comparing against historical baselines, surfaces shifts in attack infrastructure routing before individual IP reputation catches up. Attackers who move to new infrastructure show ASN patterns in your internal data before external feeds reflect the new addresses.
For incident response, ASN attribution helps scope investigations. When an ASN associated with a known threat group's infrastructure appears in your logs, the scope of the investigation expands to cover the full time window during which that ASN was communicating with your network, not just the window around the specific alert that triggered the investigation.
Monitoring, Tuning, and Keeping the Model Honest
ASN filtering requires ongoing measurement to remain useful. Several metrics are worth tracking on a regular basis:
- False positive rate by ASN tier — How often does traffic from high-risk ASNs correspond to legitimate user sessions? Rising false positive rates indicate either a tier assignment that needs revision or a legitimate use case that needs accommodation through allowlisting.
- Attack volume by ASN over time — Attackers respond to filtering by shifting infrastructure. Tracking which ASNs appear in attack telemetry each week shows you whether your blocking is displacing attacks or absorbing them, and where new attack infrastructure is emerging.
- Coverage gaps — What percentage of attack traffic originates from ASNs not currently in your tier model? Gaps indicate new attack infrastructure that your feeding sources have yet to flag.
Quarterly reviews of ASN tier assignments, cross-referenced against your internal telemetry and updated external feeds, catch drift before it degrades your filtering effectiveness. ASNs do change hands, abuse policies do tighten up, and what was a bulletproof hosting ASN two years ago may be cleaner today — or worse.
Where ASN Filtering Fits in the Defensive Stack
ASN-based filtering addresses the infrastructure layer of the attack chain. It reduces the volume of attack traffic reaching your applications, raises the operational cost for attackers by forcing infrastructure rotation, and surfaces routing-level patterns that individual IP analysis misses. It complements geo-blocking by adding routing context that geography alone lacks, and it provides signal that behavioral detection can use to improve precision.
With attack campaigns in 2026 showing consistent infrastructure reuse patterns across mobile threats, state-sponsored operations, and criminal campaigns targeting everything from healthcare genetics data to major sporting events, the routing layer is where defenders have meaningful, actionable signal. Investing in the data pipelines, tier models, and integration work to operationalize ASN filtering turns that signal into controls that hold when attackers rotate through the IP space beneath them.
