The Incident That Started With a Trusted ASN
A mid-sized financial services firm running continuous authentication monitoring noticed an unusual pattern in February: credential stuffing attempts were bypassing their IP-based blocking rules at a rate that suggested something had changed in the attacker's infrastructure. The security team had invested heavily in ASN-based filtering, blocking entire autonomous systems known to host bulletproof hosting providers, datacenter ranges frequently associated with botnets, and residential proxy networks. On paper, the policy was solid.
What the postmortem revealed was more instructive than the attack itself. The attackers had migrated a portion of their operation to ASNs belonging to small regional ISPs in Eastern Europe and Southeast Asia, ASNs that appeared in no threat feed and carried no historical abuse reputation. The credential stuffing traffic arrived looking indistinguishable from legitimate regional user traffic. The ASN-based rules, tuned during a period when attacker infrastructure skewed heavily toward major hosting providers, had not been updated to reflect how the threat landscape had shifted.
This failure pattern shows up repeatedly across sectors. ASN filtering is a powerful and underused layer in network defense, but teams that deploy it as a static control rather than a living policy end up with coverage that erodes silently over time.
What ASN Filtering Actually Does at the Network Layer
Every IP address on the public internet belongs to an autonomous system, a collection of IP prefixes under the administrative control of a single organization. Each autonomous system is identified by an Autonomous System Number, or ASN. ISPs, cloud providers, enterprise networks, hosting companies, and CDN operators all operate their own ASNs. Border Gateway Protocol, BGP, is the mechanism by which these ASNs announce their prefixes and route traffic globally.
ASN-based threat filtering works by evaluating the ASN associated with an incoming IP address and making access decisions based on that ASN's reputation, category, or historical behavior. Rather than blocking individual IPs, which rotate continuously in modern attack infrastructure, filtering at the ASN level targets the infrastructure source. If ASN 12345 is operated by a bulletproof hosting provider that consistently ignores abuse complaints, blocking all traffic originating from that ASN removes thousands of potential attack IPs in a single rule.
The practical implementation typically involves one of three approaches. The first is WHOIS and routing database lookups at request time or during preprocessing, using data from registries like ARIN, RIPE, APNIC, LACNIC, and AFRINIC. The second is enriched threat intelligence feeds that pre-classify ASNs by category and reputation, allowing teams to import structured block or monitor lists directly into firewalls, WAFs, or SIEM platforms. The third is real-time BGP data integration, where infrastructure receives live routing table updates and can react when an IP prefix moves between ASNs, a technique relevant primarily to larger network operators.
Where the Coverage Gaps Form
The credential stuffing postmortem points to a category problem that is easy to miss until it costs you. Attacker infrastructure is not static. Sophisticated operations rotate through ASNs the way they rotate through IP addresses, deliberately targeting ranges that security vendors have not yet flagged. The residential proxy ecosystem, recently highlighted by LG's decision to ban residential proxies from smart TV app traffic, demonstrates how pervasive this infrastructure has become. Residential proxy networks aggregate IP addresses from consumer ISP ranges, which means the ASNs involved look identical to legitimate home user traffic. Blocking those ASNs would mean blocking real customers.
The same problem exists with compromised infrastructure inside legitimate cloud providers. When attackers compromise virtual machines inside AWS, Azure, or Google Cloud, the originating ASN belongs to a highly reputable provider that no reasonable policy would block wholesale. The Chinese financial sector cybersecurity monitoring report published in May 2025 specifically flagged the use of major cloud provider infrastructure as attack relay points, a pattern that ASN-level filtering cannot address without significant collateral impact.
ASN reassignment creates another gap. IP address blocks do get transferred between organizations, and the ASN that was associated with a bulletproof hosting operation six months ago may now be operated by a legitimate ISP following acquisition or reallocation. Filtering rules that are not validated against current routing data will generate false positives against traffic that has no relation to the original threat actor.
Building a Policy That Accounts for Attacker Mobility
Effective ASN filtering starts with segmenting your rule base by confidence level rather than treating all block decisions the same way. High-confidence blocks apply to ASNs with consistent, documented abuse histories and no plausible legitimate user traffic, certain datacenter ranges operated by known bulletproof hosts, ASNs that have never appeared in legitimate traffic to your services, and ASNs that appear exclusively in your threat intelligence feeds. These can be hard blocks with minimal monitoring overhead.
Medium-confidence rules apply to ASNs associated with datacenter and hosting infrastructure that also carry legitimate traffic. These ranges warrant rate limiting, step-up authentication, or enhanced logging rather than outright blocking. A financial institution applying hard blocks to all AWS traffic will lock out legitimate customers running businesses from cloud infrastructure. Rate limiting that traffic while logging the full request chain gives you friction against automated attacks without destroying usability.
Low-confidence or monitoring-only rules apply to ASNs that have appeared in threat feeds but where your own traffic data shows meaningful legitimate usage. These feed into anomaly detection rather than access control directly. If ASN 67890 accounts for 0.3% of your legitimate logins but shows up in a shared threat list, blocking it requires a business impact assessment, not an automatic rule addition.
Integrating ASN Data Into Your Existing Stack
The most common implementation failure is treating ASN filtering as a standalone firewall rule set disconnected from the rest of the detection pipeline. ASN data is most valuable as an enrichment signal that flows into every layer of your security stack.
At the perimeter, your firewall or WAF can enforce hard blocks against known-malicious ASNs while logging the ASN for every request that passes through. That per-request ASN field then becomes available to your SIEM, your authentication monitoring, and your anomaly detection platform. When your SIEM correlates authentication failures across multiple IP addresses and discovers they all share the same ASN, you have identified a campaign operating from coordinated infrastructure even if no individual IP has crossed a threshold that would have triggered an alert.
For teams running behavioral monitoring aligned with frameworks like the recently introduced CUSTODY framework for AI agent network constraints, ASN context helps distinguish expected system-to-system communication from anomalous outbound connections. If an AI agent or automated process inside your network initiates a connection to an IP in a datacenter ASN that has no business relationship with your organization, that ASN signal elevates the alert priority significantly.
Threat intelligence platforms that aggregate feed data from multiple sources allow you to cross-reference ASN reputation across providers. An ASN that appears in one feed may be a false positive; an ASN that appears in feeds from five independent sources warrants much stronger action. The StopAndProtect campaign, which compromised thousands of WordPress sites across a coordinated operation, relied on infrastructure distributed across multiple ASNs specifically to avoid triggering single-feed detection. Cross-source ASN correlation would have identified the pattern earlier than single-feed monitoring did.
Operational Maintenance That Most Teams Skip
The financial services incident mentioned at the outset traced directly to a policy that had not been reviewed in eight months. ASN filtering rules need a maintenance cadence that matches the pace at which attacker infrastructure evolves.
A practical quarterly review process covers four areas. First, validate that blocked ASNs still match your original justification by pulling current WHOIS data and checking whether the operator has changed. Second, review your traffic logs for blocked ASNs that are generating high false positive rates, which indicates either customer infrastructure changes or ASN reassignment. Third, ingest new ASN categorization data from your threat intelligence providers and compare it against your current rule set to identify gaps. Fourth, audit which ASNs appear in your authentication logs, API access logs, and web traffic at meaningful volumes but carry no label in your threat intelligence data, as these unlabeled ASNs warrant manual review.
Automated tooling can handle much of this. Scripts that pull BGP routing data and compare it against your block list on a weekly basis will catch ASN reassignments before they generate customer complaints. Most threat intelligence platforms with ASN feeds support automated sync into firewall vendor APIs, keeping your rule base current without manual import cycles.
The Residential Proxy Problem Deserves Its Own Treatment
Residential proxies represent the scenario where ASN filtering has the least traction. These networks, which LG is now moving to block from smart TV application traffic, route malicious requests through IP addresses assigned to consumer ISPs. The ASNs involved are major domestic carriers, Comcast, Deutsche Telekom, NTT, and similar providers. No policy that blocks these ASNs wholesale is operational.
The detection approach for residential proxy traffic shifts from ASN reputation to behavioral and session analysis. Residential proxies frequently exhibit short session durations, high request rates inconsistent with human browsing, geographic inconsistency between the claimed ASN location and behavioral patterns, and user-agent strings that do not match the device type typically associated with that ISP's customer base. These signals layer on top of ASN data rather than replacing it.
For authentication systems specifically, residential proxy traffic often shows a very high account validity rate, meaning the attackers have pre-validated credentials and are selectively testing them at low volume per IP to avoid lockout thresholds. Detecting this pattern requires cross-ASN correlation: many different IPs across many different residential ASNs, all showing the same successful login rate for a specific set of compromised accounts. ASN data helps cluster those IPs into groups, even if no individual ASN is blockable.
Tradeoffs Security Teams Need to Communicate Upward
ASN filtering decisions carry business impact that requires stakeholder communication. Blocking a major cloud hosting ASN affects customers running their applications in that cloud. Blocking an ASN associated with a country your organization does not serve sounds straightforward until you discover that your third-party vendor's monitoring infrastructure routes through that country's IP space.
The safest framing for ASN filtering policy is risk reduction within defined parameters, not risk elimination. A well-tuned ASN filtering layer will reduce automated attack traffic, lower the volume of requests that reach your authentication and API layers, and create a cleaner signal for the detection systems operating downstream. It will not stop determined attackers who have already mapped your ASN policies and adjusted their infrastructure accordingly.
That limitation is precisely why ASN filtering belongs as one layer in a defense-in-depth architecture rather than as a primary control. Pair it with behavioral rate limiting, session integrity checking, credential breach monitoring, and anomaly detection tuned to your actual traffic baseline. The postmortem from the credential stuffing incident ultimately showed that the ASN filtering had actually blocked the first wave of the attack effectively. The attackers adapted. The security team's policy had not kept pace with that adaptation. Closing that gap is an operational problem, not a technical one.
Practical Starting Points for Teams Without Existing ASN Policies
For organizations building ASN-based filtering from scratch, a phased approach reduces the risk of misconfiguration causing business disruption. Start in monitor-only mode for 30 days, enriching every inbound request log with its ASN, ASN category, and any threat feed matches. This baseline reveals which ASNs generate your legitimate traffic and which generate your attack traffic, providing the data needed for confident rule decisions.
In the second phase, implement hard blocks only for ASNs that appear exclusively in threat traffic with zero representation in legitimate user sessions. These are safe to block without business impact analysis. Simultaneously, implement rate limiting for datacenter and hosting ASNs that appear in both legitimate and attack traffic.
In the third phase, automate ASN feed ingestion and set up alerting for new ASNs that appear in your traffic for the first time at meaningful volume. Novel ASNs generating significant traffic warrant immediate investigation, as attackers provisioning new infrastructure will show up in this signal before they show up in threat feeds.
The process is iterative. The teams that extract the most value from ASN filtering are the ones that treat it as a dynamic intelligence discipline rather than a configuration task that gets completed and filed away.
