The Gap Between Knowing About ASNs and Actually Using Them Defensively
Most security teams have heard of Autonomous System Numbers. Fewer have built operational filtering logic around them. The ones who have often discover a frustrating truth: ASN-based filtering is powerful when tuned correctly, and nearly useless when implemented as a one-time configuration task. Understanding where that gap lives — and how to close it — is one of the more underappreciated advantages available to network defenders right now.
An Autonomous System Number (ASN) is a globally unique identifier assigned to a collection of IP prefixes under the control of a single administrative entity. Internet service providers, cloud platforms, hosting companies, content delivery networks, and yes, known threat infrastructure all operate under ASNs. When your firewall or edge layer evaluates an inbound connection, it sees an IP address. What that IP address belongs to — which ASN, which organization, which network category — is where the filtering decision actually starts to mean something.
Current threat reporting reinforces why this matters. The Q2 2026 IT threat evolution statistics show a continued rise in attacks originating from commercial hosting infrastructure, where threat actors abuse cloud ASNs to blend malicious traffic alongside legitimate workloads. The Head Mare APT group's exploitation of unpatched TrueConf servers demonstrates how targeted campaigns increasingly route through infrastructure that standard IP reputation feeds evaluate slowly, if at all. ASN-level visibility catches organizational network blocks that individual IP lookups miss.
What ASN Filtering Actually Gives You That IP Blocking Doesn't
IP-based blocking operates on individual addresses or narrow CIDR ranges. When an attacker rotates IPs within the same hosting provider, IP blocking chases individual addresses while the same underlying infrastructure continues delivering payloads. ASN filtering addresses the organizational layer above the IP. When you block or rate-limit an entire ASN, you affect every IP prefix that organization announces — thousands or millions of addresses simultaneously.
This has obvious tradeoffs, and those tradeoffs are exactly what makes implementation decisions consequential. Blocking a major cloud provider's ASN will stop attacker traffic riding that provider's infrastructure, and will also stop legitimate users, API consumers, monitoring tools, and business partners running workloads on the same provider. The goal is not blanket blocking of large ASNs. The goal is building filtering logic that treats different ASN categories differently based on the risk profile of your environment and the behavior patterns you observe.
ASN categories worth treating as distinct policy tiers include:
- Residential ISPs: Traffic from consumer internet providers generally carries lower baseline risk for enterprise inbound connections, though it becomes relevant when analyzing outbound exfiltration patterns.
- Commercial hosting and VPS providers: This category deserves careful scrutiny. Most modern attack infrastructure — botnet C2, phishing delivery, credential stuffing platforms, vulnerability scanners — lives here. PurpleDelta's fraudulent employment operations identified in recent threat reporting relied heavily on hosted infrastructure that an ASN-aware filter would have flagged as a high-risk category for first-contact traffic.
- Tor-adjacent and anonymization services: Several ASNs specialize in providing infrastructure to privacy tools. These carry a distinct behavioral signature beyond what individual IP exit node lists capture.
- Academic and research networks: Often a source of legitimate scanning traffic from security researchers, but also a category worth monitoring for misuse.
- Known malicious or sanctioned ASNs: A small number of ASNs have such a consistent history of abuse that categorical filtering carries minimal legitimate traffic collateral.
Building the Filtering Logic: Where to Start This Week
The practical entry point for ASN-based filtering is enriching your existing logging and detection stack with ASN metadata before you make any blocking decisions. Blocking before you understand your traffic composition will create blind spots and operational incidents. Enrichment first gives you the visibility to make defensible policy decisions.
Most SIEM platforms and next-generation firewalls support custom field enrichment. If yours does not natively resolve ASN data, the integration path typically runs through a threat intelligence enrichment layer or a middleware log processor that appends ASN and organization name fields to each connection log entry. MaxMind's GeoLite2 ASN database is a free starting point. Commercial feeds from providers like IPinfo, Cloudflare's ASN data, or threat intelligence platform integrations give you higher accuracy and more timely updates.
Once you have ASN fields in your logs, the first analytical task is establishing a baseline. Run a two-week query across your inbound connection logs and produce a frequency table of ASNs. You will likely find that 80 to 90 percent of legitimate traffic comes from a relatively small set of ASNs corresponding to your users' ISPs, your partners' corporate networks, and major cloud platforms your business depends on. The long tail of ASNs contributing small numbers of connections warrants closer examination.
Look specifically for:
- High-volume scanning activity from hosting ASNs that have no business relationship with your organization
- Authentication attempts from ASNs categorized as VPS or bulletproof hosting providers
- API traffic arriving from ASNs that serve anonymization infrastructure
- First-seen ASNs that appear in your logs immediately following a public disclosure of a vulnerability in software you run
That last pattern is particularly relevant given CISA's recent warning about hackers exploiting a critical MLflow vulnerability. When a high-profile vulnerability advisory drops, security teams should immediately query whether inbound scanning traffic from new ASNs spikes in the 24 to 72 hours following the disclosure. ASN-level trending catches this faster than individual IP reputation feeds, which require abuse reports to accumulate before flagging individual addresses.
Watering Hole Attacks and the ASN Fingerprint They Leave Behind
The ScanBox keylogger campaigns distributed through watering hole attacks illustrate a specific detection use case for ASN analysis. In a watering hole attack, the initial delivery often comes through a compromised legitimate site. But the payload retrieval, the C2 beacon, and the exfiltration channel frequently touch infrastructure the attacker controls — infrastructure with a distinct ASN profile.
If your endpoint or proxy logging captures outbound connection destinations, enriching those logs with ASN data lets you build detection rules around destination ASN categories. A workstation connecting to your internal wiki and then suddenly reaching out to an IP inside a known bulletproof hosting ASN is a different signal than the same workstation connecting to a known CDN. The IP reputation feed might not have flagged the specific address yet. The ASN context tells you something is worth investigating right now.
This is the operational advantage that makes ASN filtering worth the implementation effort. Threat actors rotate individual IPs constantly. They do not rotate hosting providers with the same frequency because operational continuity on their infrastructure has costs too. The ASN is a more stable attribute of attack infrastructure than the individual IP, and filtering at that layer extends the useful life of your detection rules.
Implementing Graduated Response Rather Than Binary Blocking
The operational pattern that survives production pressure is graduated response, not binary allow/block decisions at the ASN level. For most organizations, three response tiers applied to ASN categories produce better outcomes than blanket policies.
Tier one — monitor and enrich: ASNs associated with major cloud providers, academic networks, and large residential ISPs fall here. Traffic from these sources gets logged with full ASN metadata, correlated against behavioral baselines, and fed into your anomaly detection layer. No automatic blocking, but every authentication failure, scanning probe, or unusual access pattern gets the ASN context attached to the alert.
Tier two — rate limit and challenge: ASNs categorized as commercial hosting, VPS providers, or datacenter networks that have no established relationship with your environment get aggressive rate limiting on authentication endpoints, CAPTCHA challenges on web application entry points, and elevated logging fidelity. This tier handles the bulk of opportunistic attack traffic without blocking legitimate cloud-based services your business depends on.
Tier three — block or require explicit allowlisting: A limited set of ASNs with documented histories of hosting attack infrastructure, ASNs in jurisdictions under regulatory sanction, and ASNs that appear exclusively in threat intelligence feeds with no plausible legitimate use for your environment get categorical blocks at the network edge. This list should be small, reviewed quarterly, and documented with the business justification for each entry.
The financial sector's network security monitoring reports for June and July 2026 both highlighted credential stuffing and identity abuse through trusted communication channels as top concerns. Financial organizations implementing this tiered ASN model consistently report that moving commercial hosting ASNs into tier two — specifically for authentication endpoints — reduces credential stuffing attempt volume reaching application logic by 60 to 80 percent, without affecting legitimate users who access from residential or corporate network ASNs.
The Student Loan Breach Context: How ASN Filtering Fits Post-Breach
The 2.5 million record exposure from the student loan breach serves as a reminder that compromised credential data moves quickly into automated abuse campaigns. Within days of a major breach reaching criminal forums, credential stuffing infrastructure spins up and begins testing the leaked pairs against high-value targets. That infrastructure overwhelmingly runs on commercial hosting ASNs — the same category that tier two filtering addresses.
Organizations in financial services, education, and healthcare should treat major breach announcements as a trigger to review their ASN filtering policies on authentication endpoints. When breach data is circulating, the window between credential testing and successful account compromise narrows significantly. Tightening rate limits on high-risk ASN categories for the two to four weeks following a major breach announcement is a low-cost, high-impact defensive adjustment.
Identity abuse through trusted communication channels — another theme in current threat reporting — adds a second dimension to the post-breach ASN filtering question. When attackers successfully compromise accounts from high-risk ASN traffic that slipped through unfiltered, they then leverage those accounts to send phishing and social engineering content through channels that appear trusted. ASN filtering at the authentication layer is part of breaking this chain before account compromise enables the next phase.
Operationalizing ASN Data in Your Security Stack This Quarter
For teams ready to move beyond analysis into operationalization, the quarterly implementation roadmap looks like this:
Weeks one and two: Deploy ASN enrichment on all inbound connection logs, authentication logs, and proxy/DNS logs. Validate that ASN fields are populating correctly and that your SIEM can query and alert on them. Build dashboards showing ASN distribution for authentication traffic specifically, since this is where the highest-value filtering decisions happen.
Weeks three and four: Run the baseline analysis. Identify your top 20 ASNs by authentication attempt volume. Categorize each as residential, corporate, cloud/CDN, commercial hosting, or other. Flag any ASNs in the commercial hosting or VPS category that account for more than one percent of authentication attempts but zero percent of successful authentications. These are candidates for immediate tier two handling.
Month two: Implement rate limiting by ASN category on authentication and API endpoints. Test in logging-only mode for one week, review the false positive rate, then activate enforcement. Set up automated alerting for ASNs that appear in your logs for the first time, particularly if they appear in high volume within 48 hours of each other, which often indicates coordinated scanning from newly provisioned attack infrastructure.
Month three: Establish the tier three block list with formal review criteria. Integrate ASN data into your incident response runbooks so that when an alert fires, the ASN context is already part of the investigator's first view of the data. Schedule a quarterly ASN policy review that coincides with major threat intelligence reporting cycles.
Where ASN Filtering Reaches Its Limits
ASN filtering is a network intelligence layer, not a complete defense strategy. Sophisticated threat actors operating long-term campaigns — the APT profile exemplified by groups like Head Mare — do not rely exclusively on commercial hosting infrastructure. They compromise legitimate hosts, use residential proxies, and route through ISP ASNs that tier one filtering passes without friction. Against that operational profile, ASN filtering catches opportunistic infrastructure and adds context to investigations, but does not stop the campaign by itself.
The filtering layer also requires maintenance discipline that teams underestimate. ASN ownership changes when companies acquire infrastructure or when hosting providers get acquired. An ASN that was associated with legitimate CDN traffic 18 months ago may have changed hands and now hosts a different type of customer. Quarterly policy reviews need to re-validate ASN categorizations against current ownership data, not cached assumptions from initial implementation.
Cloud infrastructure complicates the picture further. Major cloud providers like AWS, Azure, and Google Cloud publish their IP ranges and associated ASNs, but those same ASNs host both attacker infrastructure and legitimate enterprise workloads. Filtering decisions on these ASNs need behavioral context — what is the traffic doing, not just where is it coming from — before moving from tier one monitoring into tier two restriction.
Making ASN Filtering Part of Your Network Defense Architecture
The teams getting the most value from ASN-based filtering treat it as a persistent intelligence layer rather than a configuration checkbox. They enrich every relevant log source with ASN metadata, build detection rules that reference ASN categories alongside behavioral signals, and update their tier three block lists based on threat intelligence reporting rather than waiting for attacks to succeed before responding.
The threat landscape in the second half of 2026 — characterized by APT groups exploiting unpatched conference software, large-scale credential theft feeding automated abuse campaigns, and fraudulent operations running through commercial hosting infrastructure — creates exactly the conditions where ASN-level filtering delivers measurable risk reduction. The intelligence required to implement it is available, the integration paths into modern security stacks are well-documented, and the operational overhead is manageable with proper tooling.
Start with enrichment, build your baseline, implement graduated response on authentication endpoints, and review quarterly. That sequence turns ASN data from a network curiosity into an active component of your threat reduction architecture.
