The Operator Problem Nobody Wants to Admit
Most security teams have some version of ASN-based filtering in place. A list of known-bad autonomous systems, a few firewall rules blocking traffic from hosting providers with poor abuse histories, maybe a SIEM correlation rule that flags connections from cloud ranges that have no business touching your environment. It feels like coverage. Then you watch the logs from last week and realize that three of the campaign IPs that burned through your web application firewall belonged to ASNs you had never reviewed, registered with registrars you had never audited, and carrying traffic patterns that looked indistinguishable from legitimate SaaS egress.
That gap is not a configuration failure. It is a structural one. ASN-based filtering is a genuinely powerful defensive layer when it is built and maintained correctly, but most deployments treat it as a set-and-forget blocklist rather than a living intelligence operation. The threat landscape in mid-2026 makes that approach increasingly dangerous.
China's TA4922 campaign, which has expanded its global targeting footprint significantly over the past two quarters according to recent threat intelligence reporting, has made aggressive use of infrastructure diversification. The group routes operations through a rotating mix of legitimate cloud providers, bulletproof hosting ASNs, and residential ISP ranges, specifically to defeat static filtering rules. Meanwhile, the malware distribution ecosystems detailed in recent reporting on click hijacking and traffic distribution systems show similar patterns: attackers are not just picking one hosting provider and staying there. They are treating ASN selection as an operational security decision and rotating accordingly.
What ASN Filtering Actually Does and Where It Lives in Your Stack
An Autonomous System Number is a globally unique identifier assigned to a collection of IP prefixes under a single routing policy, typically operated by an ISP, hosting provider, enterprise, or content delivery network. When you filter by ASN, you are making a policy decision about an entire organization's IP space rather than about individual addresses.
This is both the strength and the limitation of the approach. Blocking ASN 396982 (Google Cloud) will stop a meaningful volume of cloud-hosted attack infrastructure, but it will also block legitimate Google Cloud customers. Blocking a known bulletproof hosting ASN like those associated with AS49870 or similar abuse-heavy registrants in Eastern Europe is a much cleaner decision because legitimate use cases from those ranges hitting your production environment are rare to nonexistent.
ASN filtering typically lives at several points in a network architecture:
- Upstream border routers using BGP blackholing or route policy to drop traffic from specific AS paths before it reaches your infrastructure
- Firewalls and NGFWs where IP ranges associated with an ASN are loaded as address groups and applied to access control lists
- Web application firewalls that can perform ASN lookups at request time using enriched threat intelligence feeds
- SIEM and SOAR platforms that tag incoming connection metadata with ASN context for correlation and alerting
- API gateways where ASN reputation can be a factor in rate limiting decisions or request routing
Each of these integration points has different latency tolerances, different update frequencies, and different operational overhead. Understanding which layer you are optimizing matters before you start writing rules.
Building a Tiered ASN Risk Model
Effective ASN filtering starts with categorization. Not all ASNs are equivalent threats, and treating them as a binary block-or-allow decision throws away actionable intelligence.
A practical tiered model looks like this:
Tier 1: Block Outright
These are ASNs with documented abuse histories, no legitimate user base that would contact your systems, and consistent presence in threat intelligence feeds. Bulletproof hosting providers, known botnet C2 infrastructure operators, and ASNs that appear repeatedly in blocklists like Spamhaus ASN-DROP or FireHOL's level3 lists fall here. Peer-to-peer botnet monitoring data, such as what has been published through ongoing P2P botnet research, often surfaces ASNs that concentrate C2 relay nodes. These are candidates for hard blocks at your border.
Tier 2: Scrutinize and Rate-Limit
Large cloud providers, VPN services, and residential proxy networks sit in this tier. You cannot block AWS, Azure, or Google Cloud wholesale without operational consequences, but you can apply stricter authentication requirements, lower rate limits, and more aggressive anomaly thresholds to traffic originating from these ranges. The FIFA World Cup 2026 threat landscape analysis, for instance, highlights how ticket fraud operations and credential stuffing campaigns targeting sports and entertainment platforms almost exclusively route through cloud and VPN ASNs to appear geographically distributed.
Tier 3: Monitor and Baseline
Unknown or newly registered ASNs, small regional ISPs with no prior threat history, and enterprise ASNs that occasionally appear in your logs for legitimate reasons. These warrant logging, baselining, and alerting on anomalous volume or behavior rather than blocking.
Building this model requires pulling data from multiple sources: RIPE, ARIN, and APNIC WHOIS records for registration history; routing security databases for BGP announcement history; commercial and open threat feeds for abuse reputation; and your own historical traffic logs to understand which ASNs have appeared in prior incidents.
Practical Implementation: The First 24 Hours
If you are starting from scratch or rebuilding a poorly maintained implementation, the fastest high-value action is to pull your existing firewall and WAF logs for the past 30 days and extract every source ASN. Cross-reference that list against Spamhaus ASN-DROP and BGPRanking. Any ASN that appears in both your logs and those blocklists that is not associated with a recognized business partner represents an immediate gap. These are your Tier 1 candidates for the first block rules.
Use a tool like Team Cymru's IP-to-ASN mapping service or IPinfo's ASN database to do the enrichment at scale. Most SIEMs can ingest this enrichment as a lookup table. A Python script hitting the Cymru whois service or the ipinfo.io API can process tens of thousands of IPs in minutes and return ASN, organization name, country of registration, and prefix size.
Write your first block rules conservatively. Start with ASNs where the entire registered prefix space is small (under a /20) and the organization name matches known bulletproof hosting entities. Larger ASNs need more surgical handling to avoid collateral damage.
This Week: Feed Integration and Automation
Manual ASN list maintenance fails within weeks. Attackers register new ASNs, migrate infrastructure, and exploit legitimate provider ASNs faster than any team can keep up without automation.
The following feed sources should be integrated into your filtering pipeline on a minimum 24-hour update cycle, ideally every 6 hours for high-risk environments:
- Spamhaus ASN-DROP: Maintained list of ASNs used for outright criminal hosting. Available as a zone file compatible with most firewalls and route policy systems.
- BGPRanking (CIRCL): Ranks ASNs by malicious activity concentration. Useful for Tier 2 threshold decisions.
- GreyNoise ASN tags: Shows which ASNs are currently generating mass scanning activity, relevant for the continued swagger.json scanning campaigns documented in recent SANS ISC reporting. Those scans are not coming from random IPs — they cluster into specific cloud and hosting ASNs.
- ESET APT Activity Reports: The Q4 2025 to Q1 2026 report documents infrastructure ASNs used by tracked APT groups. Cross-referencing your traffic logs against ASNs named in these reports is a high-fidelity hunting activity.
- Internal incident history: Every incident your team has investigated in the past 18 months contains ASN data. Extract it, tag it with incident severity, and build an internal reputation score.
Automation architecture for feed integration typically follows this pattern: a scheduled job pulls updated feed data, normalizes it into a common format (ASN number, risk tier, feed sources, last seen), writes it to a Redis or PostgreSQL store, and triggers a webhook that pushes updated IP prefix lists to your firewall API or WAF management plane. Most enterprise firewalls and cloud security groups support API-driven rule updates. If yours do not, that is a procurement consideration worth raising.
Handling the Residential Proxy and ISP Complication
The most operationally difficult ASN filtering problem is residential proxy networks. Services like 911.re successors, IPRoyal, and similar providers route attack traffic through IPs registered to consumer ISPs — Comcast, Deutsche Telekom, Reliance Jio — making the source ASN look completely legitimate.
This is where pure ASN filtering reaches its limits. A connection sourcing from AS7922 (Comcast) carrying credential stuffing payloads against your authentication endpoint is indistinguishable at the ASN layer from a legitimate Comcast subscriber trying to log in. The filtering logic has to move down to behavioral signals: request rate, session entropy, user-agent consistency, and cookie handling patterns.
The practical response is to use ASN context as a weighting factor in a composite risk score rather than a binary control. Traffic from a Tier 1 ASN gets blocked. Traffic from a residential ISP ASN with anomalous behavioral signals gets challenged or rate-limited. Traffic from a known corporate ASN that is a registered business partner gets expedited. This scoring approach is what modern WAF and SASE platforms implement under the hood, and it is worth understanding the logic even if your tooling abstracts it.
This Quarter: Operational Maturity and Edge Cases
Over a 90-day horizon, the focus shifts from rule coverage to operational discipline. Several activities define mature ASN filtering programs:
ASN Allowlisting for Partners and Vendors
Identify every third-party service that legitimately communicates with your environment: payment processors, identity providers, monitoring vendors, SaaS integrations. Map each one to its operating ASN. Build explicit allowlist entries for these ranges that are evaluated before any block or scrutiny rules. This prevents legitimate business traffic from being caught in broad Tier 2 rules and gives you a documented inventory of trusted network relationships.
Reviewing BGP Hijack and Route Leak History
An ASN that has been the victim or perpetrator of BGP hijacking events in the past carries elevated risk even if its current abuse score looks clean. BGPmon and RIPE's routing security dashboards track these events historically. An ASN with two or more routing incidents in the past 24 months warrants Tier 2 treatment at minimum, even if it does not appear on active abuse feeds.
Logging ASN Context in Every Alert
Every security alert your team investigates should carry ASN metadata: the originating AS number, organization name, country of registration, and current tier classification. This context dramatically accelerates triage. When analysts can see at a glance that an alert is sourcing from a Tier 1 ASN, the response priority escalates immediately without requiring a manual lookup cycle. Enrich your SIEM schema to include these fields and build alert templates that surface them prominently.
Tracking New ASN Registrations in Your Relevant Threat Geography
New ASN registrations in high-risk jurisdictions or from registrars with poor abuse histories are a leading indicator of infrastructure buildup. RIPE and ARIN publish new registration feeds. Monitoring for new ASNs registered in regions associated with active threat groups — and flagging any traffic from those new registrations immediately — gives you a short window of advantage before those ASNs appear in mainstream threat feeds.
When the Filtering Holds and When It Gets Bypassed
ASN filtering is highly effective against opportunistic attackers, commodity malware distribution campaigns, and scanning operations. The swagger.json scanning campaigns tracked through June 2026 are a good example: the scanning infrastructure concentrates in a handful of cloud and VPN ASNs, and organizations that maintain current Tier 2 rules see meaningful noise reduction from those scans even without fully blocking the traffic.
Against sophisticated threat actors, the picture is different. The malware distribution ecosystems using traffic distribution systems and click hijacking infrastructure documented in recent reporting deliberately diversify across dozens of ASNs, mixing bulletproof hosting with compromised legitimate hosts on clean ASNs. TA4922's global expansion campaign shows similar infrastructure discipline. Against these actors, ASN filtering is a friction layer rather than a decisive control. It raises their operational cost and forces more frequent infrastructure rotation, but it does not stop them alone.
The correct frame is that ASN filtering is one component in a layered defense, not a perimeter in itself. Teams that understand this use ASN data to enrich every other detection capability they operate: it weights SIEM alerts, informs WAF challenge thresholds, guides threat hunting queries, and accelerates incident triage. Teams that treat it as a standalone blocklist find themselves either blocking too aggressively and creating operational friction or not blocking enough and wondering why the same attack infrastructure keeps appearing in their logs.
Measuring Whether Your ASN Filtering Is Actually Working
Operational measurement matters. The following metrics give you a practical view of program effectiveness:
- Block rate by tier: What percentage of inbound connection attempts are hitting Tier 1 block rules? A very low percentage might indicate that your Tier 1 list is not current. A very high percentage might indicate overly broad rules creating false positive risk.
- Feed lag: How many hours between a new ASN appearing in an external threat feed and that ASN being reflected in your active block rules? Target under 24 hours for Tier 1 additions.
- Incident ASN coverage: For each security incident investigated in the past quarter, was the source ASN in your Tier 1 or Tier 2 list at the time of the attack? If not, why not, and which feed would have caught it?
- Partner ASN coverage: Is every known legitimate partner and vendor ASN on your allowlist? Run a monthly check against your vendor inventory to catch gaps from new SaaS adoptions or vendor infrastructure changes.
- New ASN alert volume: How many alerts per week are generated for traffic from ASNs registered in the past 90 days? This is a useful early warning metric for infrastructure buildup targeting your environment.
Connecting ASN Filtering to Broader Threat Intelligence Operations
The most mature implementations connect ASN filtering to a broader threat intelligence program rather than running it as an isolated network control. When a new campaign report drops — the ESET APT activity report for Q4 2025 through Q1 2026 names specific infrastructure providers, for example — the first workflow action should be extracting every named ASN or hosting provider and pushing it into your classification pipeline within hours.
Similarly, when your team investigates a phishing campaign or malware distribution incident internally, the ASN data from that investigation feeds back into your block rules and internal reputation scores. Every incident becomes an intelligence collection event that sharpens your filtering posture.
The teams that do this well treat ASN data as a shared intelligence artifact. It lives in a documented, version-controlled format. Changes are logged with justification. Feed sources are audited quarterly. And the filtering rules that result from it are tested in a staging environment before hitting production, because an incorrect rule that blocks a payment processor's outbound callbacks is a revenue event, not just a security misconfiguration.
Where to Start if You Are Inheriting a Messy Implementation
If you have taken over an environment where ASN filtering exists but is undocumented and unmaintained, the audit sequence is straightforward. Pull the current block rules and extract every IP prefix. Map each prefix to its current ASN using a bulk lookup tool. Check each ASN against current threat feeds to see which blocks are still valid. Check your traffic logs to see which allowed ASNs appear frequently and require tier classification. Document what you find, prioritize the gaps, and build a roadmap that addresses Tier 1 coverage first, feed automation second, and allowlist hygiene third.
The goal at the end of that process is a filtering program that a new analyst can understand from documentation alone, that updates itself from authoritative feeds without manual intervention, and that produces measurement data your team can use to argue for resources and demonstrate operational value. That is not an ambitious standard. It is the baseline that ASN filtering needs to meet to be worth the operational overhead it carries.
