The Attack Pattern That Prompted a Second Look at ASN Filtering
In mid-July 2026, security operations teams began documenting a wave of reconnaissance activity tied to exposed Model Context Protocol servers and AI assistant credential endpoints. The ISC Stormcast report from July 14th noted that scanning campaigns targeting these services were originating from a concentrated set of autonomous systems — hosting providers and residential proxy networks with known abuse histories. The attackers were rotating IP addresses rapidly, but the ASN assignments were remarkably consistent. Teams that had ASN-level visibility caught the pattern within hours. Teams relying on individual IP blocklists were still updating rules two days later.
That gap illustrates the core value proposition of ASN-based threat filtering: when attackers rotate addresses but stay within the same infrastructure provider, filtering at the autonomous system level collapses the attack surface in ways that per-IP rules cannot match. It also introduces real operational complexity that security teams need to manage carefully.
This article walks through how ASN filtering actually works, what the telemetry looks like in practice, how to implement it without causing collateral damage, and where it fits alongside other controls in a mature defensive stack.
What an Autonomous System Number Tells You That an IP Address Does Not
Every block of IP addresses on the public internet is assigned to an autonomous system — a collection of IP prefixes under the control of a single administrative entity, typically an internet service provider, cloud provider, enterprise, or hosting company. Each autonomous system carries a unique ASN, registered through regional internet registries like ARIN, RIPE, or APNIC.
When you look up an attacking IP address and see that it belongs to ASN 14061 (DigitalOcean), ASN 16509 (Amazon), or ASN 209 (CenturyLink), you immediately have context that a raw IP address cannot provide. You know the upstream provider responsible for the address space, the general nature of the network (cloud hosting, residential ISP, enterprise, data center), the geographic region of registration, and the abuse contact responsible for reporting.
More importantly, ASN data allows you to reason about entire infrastructure classes rather than individual endpoints. A threat actor deploying OkoBot — the cryptocurrency-targeting malware framework documented in recent threat intelligence reporting — may rotate through hundreds of IPs to deliver payloads and contact command-and-control infrastructure. But if those IPs consistently fall within a handful of autonomous systems known for permissive abuse policies, blocking or rate-limiting at the ASN level catches the infrastructure pattern, not just the individual addresses.
This is a fundamentally different defensive posture. Per-IP blocking is reactive by nature. ASN-level filtering can be both reactive and proactive, because you can act on the infrastructure class before a specific IP from that ASN ever appears in your logs.
Reading the Telemetry: What ASN Data Looks Like in Practice
Before you can filter effectively at the ASN level, you need to be collecting and enriching ASN data as part of your standard log pipeline. This is a step many teams skip, and it shows up as a blind spot during incident analysis.
Every inbound connection carries a source IP. BGP routing tables and WHOIS data map that IP to an ASN in near-real time. Most commercial and open-source threat intelligence platforms perform this enrichment automatically — MaxMind, IPinfo, and Team Cymru all provide ASN-to-IP mapping databases suitable for integration into SIEM pipelines, firewall rule engines, and API gateways.
Once enrichment is running, your logs shift from flat rows of IP addresses to structured records that include the ASN number, the ASN owner name, the IP prefix the address belongs to, and the country of registration for that ASN. In a Splunk or Elastic environment, this allows you to build queries and dashboards that immediately surface which autonomous systems are generating the most inbound requests, which ASNs appear in failed authentication events, which ASNs are hitting your API endpoints with unusual request patterns, and which ASNs overlap with known threat actor infrastructure from current intelligence feeds.
The P2P Botnet monitoring work published in mid-2026 demonstrated a particularly useful telemetry pattern: peer-to-peer botnet nodes tend to cluster in residential ISP ASNs and specific cloud hosting ASNs simultaneously. The residential ASN traffic represents compromised user devices, while the cloud ASN traffic often represents control nodes or relay infrastructure. When you see both clusters hitting the same internal endpoints in short succession, the cross-ASN correlation becomes a high-confidence indicator of botnet activity even when no individual IP is on a blocklist.
Building the ASN Reputation Model
Not all ASNs carry equal risk, and treating them as a binary allow/deny decision misses most of the operational value. A more useful model assigns ASNs to risk tiers based on observed behavior, abuse reporting history, and infrastructure type.
Risk Tier Classification
A practical four-tier model works as follows. Tier one covers known-good enterprise and ISP networks with strong abuse policies and no meaningful threat history — major telcos, large enterprise networks, educational institutions. Tier two covers general cloud and hosting providers where some abuse occurs but the provider actively responds to abuse reports — AWS, Azure, Google Cloud, and similar platforms. Tier three covers hosting providers and networks with high abuse rates, slow or nonexistent abuse response, and regular appearance in threat intelligence feeds. Tier four covers networks specifically associated with bulletproof hosting, proxy services, and infrastructure known to support malicious activity.
The FBI's seizure of the NetNut proxy platform in 2026 illustrated why proxy and residential proxy ASNs deserve their own category in this model. NetNut and similar services aggregate residential IP addresses into proxy pools, meaning traffic from these ASNs looks like legitimate user traffic by IP class but carries entirely different risk characteristics. ASN identification exposes this immediately, where individual IP analysis often does not.
Data Sources for ASN Reputation
Building an ASN reputation model requires pulling from multiple data sources. Spamhaus, Emerging Threats, and AbuseIPDB all publish ASN-level reputation data. CAIDA and Team Cymru maintain routing data that reveals ASN relationships and peering arrangements, which can surface ASNs that exist primarily to route traffic for other suspicious networks. Your own historical log data is one of the most valuable inputs — an ASN that appears repeatedly in authentication failure logs, vulnerability scanning traffic, and credential stuffing attempts has earned a higher risk tier regardless of what external feeds say.
Threat intelligence sharing programs, when they function correctly, accelerate ASN reputation development significantly. Teams that contribute and receive ASN-level indicators can identify emerging hostile infrastructure weeks before it appears in commercial feeds. The ESET Threat Report for H1 2026 noted that several major malware campaigns used infrastructure that was identifiable at the ASN level well before individual C2 IPs were published — teams with ASN-level intelligence sharing in place had a meaningful detection lead.
Implementation Approaches Across the Stack
ASN-based filtering can be implemented at multiple points in your infrastructure, and the right placement depends on what you're protecting and what trade-offs you can accept.
Perimeter Firewall and Router ACLs
At the network perimeter, ASN filtering translates to BGP prefix list management or ACL rules built from the IP prefixes associated with high-risk ASNs. Tools like bgpq4 can automatically generate ACL entries from routing data for specific ASNs. This approach is computationally efficient and handles filtering before traffic reaches application layers, but it requires careful change management because a BGP prefix list for a large ASN can include thousands of CIDR entries.
For organizations running their own BGP peering, route filtering at the BGP level provides the cleanest implementation. You selectively accept or reject route advertisements from specific ASNs at the peering layer, which prevents traffic from those networks from entering your routing table at all. This approach requires BGP expertise and is more appropriate for larger organizations with dedicated network engineering staff.
Web Application Firewalls and API Gateways
For web-facing applications, WAF and API gateway implementations of ASN filtering provide granular control tied to application context. You can apply different policies for different endpoints — blocking tier-four ASNs entirely at the login endpoint while still allowing access to public content pages, or applying aggressive rate limiting to tier-three ASNs while serving normal responses to tier-one traffic.
The scanning activity targeting MCP servers documented in the July 2026 ISC reports would have been effectively contained with ASN-level rate limiting at the API gateway layer. The scanning originated from a concentrated set of hosting ASNs. A rule applying strict rate limits to requests from those ASN classes, combined with behavioral anomaly detection for MCP endpoint patterns, would have reduced the attack surface substantially without requiring per-IP updates.
SIEM Detection Rules and Automated Response
Within the SIEM, ASN data enables detection rules that operate on infrastructure patterns rather than individual indicators. A rule that triggers when more than fifty failed authentication attempts originate from tier-three or tier-four ASNs within a ten-minute window is more durable than a rule that looks for specific IP addresses, because it catches new infrastructure from the same threat actor class without requiring indicator updates.
Automated response workflows can take this further. When an ASN crosses a behavioral threshold — sustained failed authentications, high-volume endpoint scanning, or repeated requests for sensitive paths — an automated firewall rule can elevate the filtering policy for that ASN temporarily, while alerting the SOC team for review. This time-based, threshold-triggered ASN blocking is more defensible than permanent blocks and avoids the collateral damage that comes from blocking an entire cloud provider permanently.
Collateral Damage and the Cases Where ASN Filtering Breaks Down
ASN filtering creates real operational risk when applied without understanding the infrastructure it targets. Cloud provider ASNs present the most significant challenge. When you block or severely restrict traffic from AWS, Azure, or Google Cloud ASNs, you also block legitimate users accessing your application through cloud-hosted VPN services, remote desktop environments, or corporate proxies that route through cloud infrastructure. You block partner systems, automated monitoring services, and your own development pipelines if they run in cloud environments.
The Lessons Learned documentation from the CISA GitHub Leak incident underscored that internal tooling and automation often originates from cloud ASNs that security teams might otherwise want to restrict. ASN filtering policies that do not account for internal automation can create operational outages that look, initially, like attacks.
Watering hole attacks using infrastructure like the ScanBox keylogger campaigns exploit legitimate-looking hosting infrastructure precisely because defenders are reluctant to block major hosting ASNs. Attackers hosting malicious content on compromised legitimate sites or on reputable cloud platforms know that broad ASN blocking is unlikely to catch them without also causing significant disruption. This is why ASN filtering works best as one layer in a defense-in-depth model rather than as a standalone control.
Residential ISP ASNs present a different challenge. Blocking a residential ISP ASN to stop botnet traffic also blocks legitimate residential users who happen to be served by that ISP. This trade-off requires a policy decision based on whether you have a user base in that geography and whether the volume of botnet traffic from that ASN justifies the impact on legitimate users.
Operational Workflow for ASN Filtering Management
Sustainable ASN filtering requires a defined operational workflow rather than ad hoc rule additions that accumulate without review.
Weekly Enrichment Review
Schedule a weekly review of ASN data appearing in authentication failure logs, WAF block logs, and SIEM alerts from the previous seven days. Look for ASNs appearing repeatedly across multiple event types — an ASN that shows up in credential stuffing attempts, port scanning traffic, and web scraping logs simultaneously is a strong candidate for policy escalation. Assign or update risk tier classifications based on the week's observed behavior.
Automated Feed Integration
Integrate ASN reputation feeds into your blocking policy engine with automatic update cycles. Tools like pfBlockerNG, Suricata with BGP enrichment plugins, or commercial SOAR platforms can pull updated ASN reputation data and apply policy changes without manual intervention. Set alert thresholds so that significant changes in ASN reputation scoring trigger human review before automatic policy escalation.
Exception Management
Maintain a documented exception list for ASNs that would otherwise qualify for restrictive policies but serve legitimate business functions. Cloud provider ASNs used by partner systems, CDN ASNs that serve your own application content, and monitoring service ASNs all belong in a managed exception registry with documented justification and review dates. Exceptions should expire and require renewal rather than persisting indefinitely.
Logging the Policy Layer
Ensure that ASN-based filtering decisions are logged with the same fidelity as individual IP decisions. When a request is blocked or rate-limited based on ASN policy, the log entry should capture the ASN number, the policy tier that triggered the action, the specific rule applied, and the endpoint targeted. This data feeds back into your weekly enrichment review and builds the longitudinal record needed to evaluate whether your ASN policies are actually reducing attack surface.
Connecting ASN Data to the Broader Threat Picture
The value of ASN filtering scales with how well it connects to the rest of your threat intelligence operation. Standalone ASN blocking is useful but limited. ASN data enriching every other control in your stack is significantly more powerful.
When credential stuffing attempts arrive, ASN context tells you whether the traffic is coming from a residential proxy network, a datacenter ASN known for abuse, or a legitimate ISP. That context changes the response — a residential proxy ASN warrants different handling than a bulletproof hosting ASN. The Popa Botnet infrastructure that was seized by FBI in 2026 operated through a specific set of ASNs that were identifiable through routing analysis. Organizations that had flagged those ASNs through their threat intelligence pipeline had policy controls in place before the takedown made headlines.
Phishing infrastructure, including campaigns using tools like ScanBox, consistently reuses ASNs across campaigns because threat actors have established relationships with specific hosting providers. Tracking ASN reuse across incident data allows your threat intelligence function to anticipate infrastructure patterns for future campaigns rather than responding to each campaign individually.
Microsoft's record patch release in 2026, covering 570 security flaws, immediately triggered scanning campaigns targeting newly disclosed vulnerabilities. Post-disclosure scanning of this kind originates overwhelmingly from a consistent set of hosting and security research ASNs. Organizations with ASN-aware detection rules identified the scanning activity as expected post-patch behavior and were able to prioritize patching based on which specific ASNs were scanning for which specific vulnerabilities — a level of context that per-IP analysis cannot efficiently provide.
Building Toward Maturity: What a Functioning ASN Filtering Program Looks Like
A mature ASN filtering program has several observable characteristics that distinguish it from ad hoc implementation.
Enrichment runs automatically and consistently. Every log source in the environment enriches IP addresses with ASN data at ingest time, so analysts never have to manually look up ASN context during investigation. ASN data appears in dashboards, alerts, and reports as a standard field alongside IP address and geolocation.
Policy tiers are documented and reviewed quarterly. The risk tier classification system has written criteria, and ASN tier assignments are reviewed against observed behavior data every quarter. Tier assignments change based on evidence, and changes are logged with justification.
Filtering decisions are measurable. The team can report on how many requests were rate-limited or blocked based on ASN policy in any given period, what the false-positive rate was (measured by exceptions processed or business complaints received), and what the detection lead time was compared to per-IP indicator-based detection for the same threat actors.
ASN data feeds forward into threat hunting. Threat hunters use ASN clustering in their hypothesis development, looking for new attack campaigns by identifying unusual ASNs appearing in low-volume but suspicious traffic patterns before those campaigns generate alerts. This proactive use of ASN data is where the investment in enrichment and classification pays off most clearly.
Immediate Steps for Teams Starting From Zero
If ASN enrichment is absent from your current environment, the following sequence moves you toward functional coverage without requiring a major infrastructure project.
- Add ASN enrichment to your SIEM ingest pipeline using a free or commercial IP intelligence database. MaxMind GeoLite2 ASN data is available at no cost and integrates with most major SIEM platforms through existing plugins.
- Build a baseline dashboard showing the top twenty ASNs by volume across authentication logs, WAF logs, and firewall deny logs for the past thirty days. This baseline immediately surfaces which ASNs are already generating the most activity against your infrastructure.
- Apply rate limiting rules at your WAF or API gateway for ASNs that appear in authoritative abuse lists — Spamhaus ASN reputation and AbuseIPDB ASN scores are good starting points.
- Create a SIEM alert for any ASN appearing in more than one event type (authentication failure and port scan, for example) within a twenty-four-hour window. This cross-event-type correlation rule has a low false-positive rate and high detection value for active threat actors.
- Document your first tier classification decisions with justification and schedule a thirty-day review to assess whether the classifications held up against observed traffic.
Starting with detection and classification before moving to active blocking reduces the risk of operational disruption and builds the evidence base you need to make blocking decisions with confidence.
Where ASN Filtering Fits in the Defensive Architecture
ASN-based threat filtering occupies a specific and valuable position in a layered defensive architecture. It provides infrastructure-level context that individual IP analysis cannot efficiently deliver, enables policy decisions that scale across attacker infrastructure rotation, and connects threat intelligence about hosting providers and abuse networks directly to enforcement controls.
The threat landscape of mid-2026 — scanning campaigns targeting AI infrastructure, P2P botnets operating across residential and cloud ASNs simultaneously, proxy platform seizures that expose how attackers route through legitimate-looking infrastructure — consistently rewards defenders who operate at the infrastructure level rather than the individual-indicator level. ASN filtering, implemented deliberately and maintained operationally, is one of the more practical ways to shift the defensive posture in that direction.
