When 73,932 Devices Leak Credentials, the Question Becomes Infrastructure
The FortiBleed campaign, which exposed credentials for 73,932 FortiGate systems, was not primarily a vulnerability story. It was an infrastructure story. Attackers harvested credentials at scale by targeting systems reachable from hosting providers and autonomous systems (ASNs) that security teams had decided to trust, or more accurately, had never decided anything about at all. The scanning and exploitation traffic flowed through ASNs that any competent filtering policy should have flagged weeks or months earlier.
That pattern appears repeatedly across recent campaigns. The VBScript campaign distributing RMM software through WhatsApp used infrastructure routed through commodity hosting ASNs that appear consistently on abuse feeds. The ScanBox keylogger deployments tied to watering hole attacks relied on ASNs associated with bulletproof hosting that have been flagged in threat intelligence for years. In each case, defenders who had implemented ASN-based filtering as a genuine policy layer had a meaningful advantage. Defenders who treated ASN filtering as an edge case or an afterthought did not.
This article covers how to build ASN-based threat filtering that actually changes your risk posture, what the policy decisions look like in practice, and where teams consistently create gaps that undermine the work they have already done.
What ASN Filtering Actually Means at the Network Layer
An Autonomous System Number is a globally unique identifier assigned to a collection of IP prefixes under common routing policy control. Every IP address on the internet is announced by an ASN, and that ASN tells you something meaningful about the administrative and operational context of the traffic.
When a request hits your login page, your API gateway, or your VPN endpoint, it originates from an IP that belongs to a prefix announced by a specific ASN. That ASN might be a major cloud provider, a residential ISP, a university, a content delivery network, or a hosting company known primarily for providing infrastructure to threat actors with minimal abuse response. The ASN is a layer of context that IP reputation data alone cannot fully substitute for.
ASN-based filtering means using that ASN context to make policy decisions. Those decisions can be hard blocks, soft friction increases, enhanced logging triggers, or routing changes depending on your environment and risk tolerance. The ASN is not a substitute for IP-level analysis, but it provides a signal at a different resolution that is often more stable and operationally useful than individual IP reputation scores.
Why ASN-Level Signals Are More Stable Than Individual IP Reputation
IP reputation feeds track individual addresses. Attackers know this and rotate IPs constantly. A hosting provider ASN that serves as infrastructure for credential stuffing operations, ransomware C2, or vulnerability scanning does not change its ASN assignment when it rotates addresses. The underlying organizational relationship between the provider and the threat actor persists even as individual IPs cycle.
This is exactly why the ransomware groups behind the campaigns driving current attack statistics are able to evade IP reputation filters while remaining detectable at the ASN layer. The Gentlemen's EDR killer framework, which uses living-off-the-land techniques to disable endpoint detection before executing payloads, still needs to stage infrastructure somewhere. That somewhere is consistently a small set of ASNs with documented abuse histories. The IP changes. The ASN does not.
Building an ASN Classification Framework
Before you can filter by ASN, you need a system for classifying ASNs by risk profile. Most teams skip this step and end up with a blocklist of individual ASNs that grows organically without a coherent policy behind it. That approach creates gaps, generates unnecessary friction for legitimate users, and produces a list that becomes stale within weeks.
A functional classification framework groups ASNs into tiers based on operational characteristics and threat relevance to your environment.
Tier One: High-Confidence Block Candidates
These are ASNs with no legitimate business justification for reaching your services, combined with documented and current abuse activity. Bulletproof hosting providers that explicitly market resistance to abuse takedowns belong here. ASNs that appear consistently across multiple independent threat intelligence sources as infrastructure for botnets, ransomware C2, or credential harvesting operations belong here. ASNs where the entire announced prefix space has appeared in recent attack telemetry belong here.
Blocking these ASNs at the perimeter or at the application layer for your public-facing services is a defensible, low-friction decision. The probability of a legitimate user reaching your services from an ASN in this tier is low enough that the operational cost of false positives is acceptable.
Tier Two: Elevated Scrutiny Without Hard Block
This tier includes ASNs associated with hosting environments that serve a mix of legitimate and malicious clients, large VPN and proxy provider ASNs, Tor exit infrastructure, and cloud providers known to be heavily abused for attack automation even though they also serve legitimate workloads. Major hyperscalers fall here for most organizations because blocking them entirely would create significant false positive rates, but traffic from these ASNs warrants more aggressive rate limiting, additional authentication friction, and enhanced logging.
The OpenClaw AI supply chain threat is a useful reference point here. Malicious actors using AI-assisted attack tooling are staging operations through legitimate cloud ASNs specifically because organizations have learned to block obvious hosting providers while exempting major cloud providers. Policy decisions about tier two ASNs need to account for this deliberate infrastructure choice.
Tier Three: Monitor and Baseline
Residential ISPs, enterprise network ASNs, and university ASNs that represent your legitimate user base belong here. The goal for tier three is accurate baselining so that anomalies become visible. If your application normally sees zero traffic from a specific regional ISP and suddenly receives a credential stuffing burst from that ASN, the baseline makes that anomaly actionable.
Practical ASN Filtering Checklist
The following checklist covers the implementation steps that separate functional ASN filtering programs from ones that look good in documentation but fail under real attack conditions.
- Map your legitimate traffic to ASNs before writing any blocking rules. Pull 30 to 90 days of access logs, extract source IPs, resolve them to ASNs, and build a frequency distribution. This baseline tells you which ASNs your actual users come from and prevents you from blocking your own customers.
- Integrate at least three independent ASN reputation and abuse data sources. No single feed has complete coverage. Cross-referencing Spamhaus ASN data, RIPE NCC abuse contact records, and commercial threat intelligence feeds gives you a more complete and defensible classification basis than any single source.
- Implement ASN-aware rate limiting before hard blocks. For tier two ASNs, apply stricter rate limits on authentication endpoints, API routes, and any endpoint that returns sensitive data. This reduces attack velocity without the false positive risk of a full block.
- Create separate policies for different service exposure profiles. Your public-facing authentication endpoint, your partner API with known client ASNs, and your internal administrative interface each warrant different ASN filtering postures. A blanket policy applied to all services creates either unnecessary friction on some surfaces or inadequate protection on others.
- Log ASN context alongside every access event. If your logging pipeline captures IP addresses but not ASN resolution, you are missing the layer of context that makes post-incident analysis useful. ASN data should be enriched at log ingestion time.
- Build an ASN review cadence into your threat intelligence workflow. ASN classifications change. A hosting provider that was clean six months ago may now serve as infrastructure for ransomware operations. Schedule a monthly review of your tier one and tier two classifications against current threat intelligence.
- Test your filtering rules against your own traffic before production deployment. Run new ASN block rules in logging-only mode for at least 72 hours and compare the flagged traffic against your legitimate user baseline. This catches false positives before they affect users.
- Create an expedited exception process for legitimate use cases. Your ASN blocking policy will occasionally catch legitimate traffic from business partners, contractors using VPNs, or users in unusual network contexts. Having a documented, fast-path exception process prevents the policy from being bypassed informally.
- Correlate ASN filtering events with your SIEM. ASN-based blocks and rate limit triggers should feed into your detection stack as signals, not just network events. An attacker who rotates through multiple ASNs attempting to reach your login endpoint is detectable at the behavioral layer even when individual ASN blocks stop individual attempts.
- Document your classification rationale for each blocked ASN. When an ASN block causes a business impact or gets challenged internally, you need documented justification. Record the specific threat intelligence sources, timestamps, and abuse evidence that supported each classification decision.
Where ASN Filtering Fits in a Layered Defense Architecture
ASN filtering is not a replacement for any other control layer. It is a coarse-grained filter that reduces attack surface and attack volume so that finer-grained controls operate more effectively.
Consider the current ransomware attack surface. Groups gaining initial access through VPN credential compromise, which remains one of the most common initial access vectors, conduct their credential harvesting from scanning and stuffing infrastructure. That infrastructure lives in predictable ASNs. ASN filtering at the authentication layer reduces the volume of credential stuffing attempts that reach your actual authentication logic, which in turn reduces the noise that authentication-layer controls like MFA, anomaly detection, and rate limiting have to process.
The same logic applies to the ScanBox watering hole campaign. The keylogger payload needed to phone home to attacker infrastructure. Organizations with outbound ASN filtering policies that blocked known bulletproof hosting ASNs at the egress layer interrupted that callback even when the initial compromise occurred on an endpoint that visited the watering hole.
ASN filtering also integrates naturally with geo-blocking, though the two controls operate differently. Geo-blocking uses IP-to-country mapping to restrict traffic by perceived geography. ASN filtering uses routing context to restrict traffic by operational origin. An attacker using a VPN hosted in the same country as your user base bypasses geo-blocking but may still route through an ASN that your filtering policy covers. Layering both controls increases the probability of catching evasion attempts that defeat either control individually.
Data Sources That Actually Support Operational ASN Filtering
The quality of your ASN classifications depends entirely on the quality of your data sources. The following sources provide actionable data for building and maintaining an ASN filtering program.
The RIPE NCC, ARIN, APNIC, LACNIC, and AFRINIC regional internet registries maintain authoritative ASN assignment data. Registry data tells you who the ASN is registered to, what contact information is on record, and when the registration was last updated. ASNs registered to entities with no verifiable business presence, generic registrant names, or contact information that bounces abuse reports warrant elevated scrutiny by default.
Spamhaus publishes ASN-level threat intelligence through its DROP and EDROP lists, which cover ASNs allocated to spammers, bulletproof hosting providers, and criminal infrastructure. These lists are updated frequently and are directly consumable by most firewall and router platforms.
BGPView, Hurricane Electric BGP Toolkit, and similar BGP analysis tools let you examine routing relationships between ASNs, which is useful for identifying cases where a hosting provider routes traffic through a cleaner upstream ASN to avoid reputation-based filtering. This technique is common enough that any ASN filtering program that only looks at the immediately announcing ASN is incomplete.
Commercial threat intelligence platforms that aggregate abuse reports, botnet sinkhole data, and malware infrastructure tracking provide ASN-level reputation scoring that goes beyond what public sources cover. The Insikt Group intelligence model, which combines human analyst expertise with algorithmic processing of threat data, is one example of how professional threat intelligence products surface ASN-level patterns that would take individual security teams significant time to develop independently.
Implementation Pitfalls That Undermine ASN Filtering Programs
Most ASN filtering failures are not technical failures. They are process and policy failures that create gaps the technology cannot compensate for.
Static Lists That Never Get Updated
An ASN blocklist that was accurate when it was created becomes progressively less accurate over time. Threat actors migrate infrastructure. Hosting providers change their abuse policies. ASNs get reallocated. A list that has not been reviewed against current threat intelligence in more than 60 days is providing diminishing protection while the maintenance overhead remains constant. If your team cannot commit to a review cadence, implement automated feeds rather than manually maintained lists.
Applying the Same Policy to All Traffic Types
Authentication endpoints, content delivery paths, API routes, and administrative interfaces each have different legitimate traffic profiles and different risk exposures. A hard block policy appropriate for your login endpoint may be unnecessarily restrictive for a content endpoint that serves public users. Segmenting your filtering policy by endpoint type and service exposure profile produces better outcomes than a single policy applied uniformly.
Ignoring IPv6 ASN Routing
Most ASN filtering implementations focus exclusively on IPv4 prefixes. IPv6 addressing is increasingly present in attack telemetry, and the same ASNs that route malicious IPv4 traffic also announce IPv6 prefixes. If your filtering rules do not cover both address families, attackers can route around IPv4-based ASN blocks by connecting over IPv6. This is a documented evasion technique that has been observed in banking phishing campaigns delivered over IPv6 specifically to bypass IPv4-centric blocklists.
No Feedback Loop Between Filtering Events and Threat Intelligence
ASN filtering events are threat intelligence data. When your filter blocks a credential stuffing burst from a specific ASN, that event should feed back into your threat intelligence workflow to confirm current classifications, identify new ASNs associated with the same campaign infrastructure, and update your monitoring for related activity. Teams that treat filtering events as network noise rather than intelligence miss the opportunity to improve their classifications continuously.
Trusting ASN Reputation Without Verifying Current Routing Context
ASN reputation data reflects historical behavior. An ASN with a clean historical record can become malicious infrastructure quickly if a hosting provider changes ownership, modifies its abuse response policies, or starts accepting clients it previously rejected. Reputation data should be one input into your classification decision, not the sole basis for it. Combining reputation data with current BGP routing analysis and fresh abuse telemetry produces more reliable classifications than reputation alone.
No Exception Handling for Legitimate Edge Cases
Security contractors, penetration testers, threat intelligence researchers, and remote employees using enterprise VPNs all generate traffic that may originate from ASNs your filtering policy targets. Without a documented exception process, these cases get resolved through informal workarounds that create undocumented policy gaps. Building a formal, fast-path exception handling process into your ASN filtering program prevents policy erosion over time.
Connecting ASN Filtering to Incident Response
The operational value of ASN filtering extends beyond prevention. During an active incident, ASN context accelerates triage significantly. When the FortiBleed campaign was active, organizations with ASN-enriched logging could immediately identify which login attempts and credential use events originated from known malicious ASNs and prioritize those events for investigation. Organizations without ASN enrichment in their logs had to resolve individual IPs manually, which added hours to their triage process during a period when speed determined whether credentials were used before defensive action was taken.
Integrating ASN context into your incident response playbooks means training responders to use ASN data as a triage filter, building ASN-aware queries into your SIEM detection rules, and ensuring that your threat intelligence platform can provide current ASN context on demand during an active investigation. The clean GitHub repository technique being used to trick AI coding agents into executing malware also relies on infrastructure that has ASN fingerprints. Response teams with ASN context in their toolchain can pivot from a malicious callback IP to the full ASN infrastructure context faster than teams working only with individual IP data.
ASN-based threat filtering works best as a living program with data, policy, and process components that evolve together. The technical implementation is the easiest part. The harder work is building the operational discipline to keep classifications current, integrate ASN signals into the broader detection stack, and treat every filtering event as an input to the next iteration of your policy.
