The Problem No One Talks About Until the Traffic Is Already Inside
Most security teams spend considerable energy analyzing individual IP addresses — investigating reputation scores, checking blocklists, correlating against threat feeds. What gets far less attention is the organizational layer sitting above those IPs: the Autonomous System Number, or ASN. When Head Mare APT was actively exploiting unpatched TrueConf servers to deliver PhantomCore and PhantomGraph malware to video conference participants, analysts who traced the attack infrastructure discovered consistent ASN patterns tied to specific hosting providers known for lax abuse handling. The individual IPs rotated. The ASNs did not.
This is the core operational insight behind ASN-based threat filtering. Threat actors — whether running phishing campaigns, operating botnets, conducting watering hole attacks like those pushing ScanBox keyloggers, or running fraudulent employment operations like PurpleDelta — tend to cluster their infrastructure within a predictable set of autonomous systems. Those systems have consistent, queryable identifiers that change far less frequently than IP addresses do. Building filtering logic around ASNs gives security teams a more durable and scalable signal than per-IP blocklisting alone.
What an ASN Actually Is and Why It Matters for Filtering
An Autonomous System is a collection of IP address ranges managed by a single organization — typically an ISP, hosting provider, cloud platform, or CDN. Each AS is assigned an ASN by a regional internet registry (RIR) such as ARIN, RIPE NCC, APNIC, LACNIC, or AFRINIC. When a packet traverses the internet, BGP routing decisions reference these ASNs constantly. From a security perspective, the ASN tells you who is responsible for the block of addresses that traffic originates from.
ASNs carry operational meaning that individual IPs lack. An IP address from AS14061 (DigitalOcean) carries different risk context than one from AS20473 (Vultr), which differs again from traffic sourcing out of AS396982 (Google Cloud) or AS16509 (Amazon). None of these are inherently malicious — but each has a different abuse profile, a different customer base, and a different rate of appearance in threat intelligence reports. When the financial sector cybersecurity monitoring reports for Q2 and Q3 2026 noted spikes in credential theft and identity abuse through trusted communication channels, infrastructure tracing consistently pointed back to a small set of hosting ASNs used repeatedly across incident clusters.
Where ASN Filtering Fits in Your Defense Architecture
ASN-based filtering operates at a different layer than signature-based detection or behavioral analysis. Think of it as a network-level policy control that reduces the attack surface before traffic reaches your application logic, your WAF rules, or your IDS signatures. The practical placement options include:
- Perimeter firewall rules that drop or flag inbound connections from specific ASNs before packets reach internal systems
- Web application firewall (WAF) policies that apply stricter inspection or rate limiting to traffic from hosting ASNs with elevated risk profiles
- SIEM enrichment pipelines that append ASN context to every log event, enabling ASN-aware correlation rules
- API gateway controls that require additional authentication challenges for requests originating from known VPS or proxy-heavy ASNs
- Outbound filtering policies that flag or block connections to IP ranges within ASNs associated with command-and-control infrastructure
The important distinction here is between blocking and flagging. Wholesale blocking entire ASNs is appropriate in some contexts — an internal HR tool has no legitimate reason to accept connections from a Moldovan VPS hosting provider. A public-facing e-commerce API serving global customers requires a more nuanced approach where ASN risk scores inform inspection intensity rather than outright rejection.
Building Your ASN Risk Classification Framework
Effective ASN-based filtering requires a classification system that reflects actual threat data rather than subjective assumptions. The following categories provide a workable starting structure.
High-Confidence Block Candidates
These are ASNs that appear consistently in threat intelligence feeds with minimal legitimate traffic justification for your specific environment. Bulletproof hosting providers fall into this category — they explicitly market their services based on resistance to abuse complaints and law enforcement requests. If your organization's threat intelligence ingestion is working, these ASNs should already be surfacing in your data. CISA's recent warnings about attackers exploiting critical MLflow vulnerabilities included infrastructure hosted in ASNs that appear on multiple commercial threat feeds as chronic abuse sources.
Elevated-Inspection ASNs
Large cloud providers, residential proxy networks, and major VPN service ASNs generate both legitimate and malicious traffic. These warrant increased scrutiny rather than blanket blocking. For a student loan servicer — relevant given the 2.5 million record breach that exposed sensitive financial data — blocking all AWS or Azure traffic outright makes no sense. Requiring additional verification steps for account actions originating from those ASNs does make sense.
Trusted and Expected ASNs
ASNs used by your own organization's ISPs, your cloud providers' known ranges, your CDN partners, and your SaaS vendors form a baseline of expected traffic. These still require monitoring — supply chain attacks use exactly this trust relationship — but they should not trigger the same friction as unknown hosting ASNs.
Data Sources for ASN Intelligence
Building and maintaining ASN risk classifications requires feeding data from multiple sources. No single feed provides comprehensive coverage, and the landscape shifts as threat actors migrate infrastructure.
WHOIS and RIR data provide authoritative ASN registration information. Tools like whois -h whois.radb.net AS14061 or BGP looking glass queries let you enumerate the IP prefixes announced by any given ASN. This raw data tells you the scope of what you're dealing with when considering a block or inspection policy.
Commercial threat intelligence platforms aggregate abuse reports, malware C2 sightings, and phishing infrastructure data indexed by ASN. Platforms including Recorded Future, Mandiant, and CrowdStrike publish ASN-level risk context that maps observed threat actor infrastructure to specific autonomous systems.
Open-source feeds such as Spamhaus ASN-DROP, the CAIDA AS rank dataset, and abuse.ch's data provide ASN-level threat context at no cost. The Spamhaus ASN-DROP list specifically identifies ASNs that have demonstrated persistent tolerance for spam, botnet activity, and related abuse — making it a practical starting point for initial block list population.
Your own telemetry is often underused for this purpose. If your SIEM is enriching logs with ASN data (which every SOC team should implement regardless of whether they're actively filtering on ASNs), you can query that data to identify which ASNs are generating disproportionate alert volumes, authentication failures, or scanning activity against your infrastructure.
Implementation: What to Do Today, This Week, and This Quarter
Immediate Actions (Today)
Start with ASN enrichment before you touch a single firewall rule. If your SIEM ingestion pipeline does not already append ASN information to log events containing source IP addresses, implement this immediately. Most SIEMs support lookup tables or external enrichment APIs. MaxMind's GeoIP2 database includes ASN data, as does ip-api.com and several other providers. Once enrichment is flowing, build a simple dashboard showing the top ASNs by event volume across authentication logs, web access logs, and firewall deny logs. Within 24 hours you'll have a data-driven picture of which ASNs are actually generating noise in your environment rather than working from assumptions.
Short-Term Implementation (This Week)
Pull the Spamhaus ASN-DROP list and cross-reference it against your ASN enrichment dashboard. Any ASN appearing on that list that is also generating authentication attempts, web requests, or connection attempts to your infrastructure should be immediately flagged for policy action. For most organizations, converting high-confidence block candidates into firewall deny rules at the perimeter is the first concrete filtering step. Implement these as named rule groups with clear documentation so your team understands the rationale when reviewing rules six months from now.
Simultaneously, begin configuring elevated-inspection policies for major VPS and cloud hosting ASNs. In your WAF or API gateway, create rule sets that apply additional verification to requests from these sources. For APIs handling sensitive operations — financial transactions, credential changes, data exports — require step-up authentication for requests originating from known hosting and proxy ASNs.
Quarterly Objectives
ASN filtering requires maintenance infrastructure to remain effective. Threat actors regularly migrate to new hosting providers, and legitimate services sometimes share ASN space with abusive operators. Build a quarterly review cycle that includes:
- Refreshing ASN block lists against current threat intelligence feeds
- Auditing your elevated-inspection categories for false positive rates that may justify reclassification
- Reviewing new ASNs appearing in your alert telemetry that are not yet classified
- Testing whether your filtering policies are catching known-bad traffic by running controlled queries against your logs for ASNs that threat intelligence has flagged after your last review cycle
Also this quarter: build your ASN classification data into your incident response playbooks. When an alert fires, the first enrichment step should include ASN context. An SSH brute force attempt from AS12345 (a legitimate university research network) warrants different handling than the same activity from an ASN that appears in three commercial threat feeds as a known botnet hosting provider.
Real-World Scenario: Applying ASN Filtering During an Active Campaign
Consider how ASN-based filtering would have applied to the PurpleDelta fraudulent employment operations that security researchers documented in mid-2026. PurpleDelta operated a network of fake job postings and recruiter personas, using those personas to push malicious payloads to job seekers — a textbook identity abuse through trusted communication channels scenario. When analysts mapped the infrastructure, the command-and-control servers, payload hosting, and fraudulent domain registration all clustered within a small set of ASNs that had prior associations with cybercriminal activity.
Organizations with ASN-based filtering in place at the email gateway and web proxy layers had a measurable advantage. Outbound connections to payload-hosting domains resolved to IPs within flagged ASNs, triggering elevated inspection that caught the malicious content before it executed. Inbound phishing emails with links to those same domains produced warning signals when the ASN context of the destination matched high-risk classification thresholds.
This scenario illustrates a key operational principle: ASN filtering is effective not just at the network perimeter but throughout the traffic inspection stack. Outbound proxy inspection with ASN awareness catches malware calling home. Email gateway enrichment catches phishing infrastructure. Web application logging with ASN context accelerates post-incident investigation by grouping attacker activity under a common infrastructure attribute even when IP addresses differ.
Limitations and Failure Modes to Plan Around
ASN filtering provides a durable but imperfect signal. Several scenarios reduce its effectiveness, and security teams need explicit strategies for each.
Legitimate cloud platform abuse is the most common limitation. AWS, Azure, Google Cloud, and similar providers appear in both threat intelligence reports and legitimate enterprise traffic. Blanket blocking of major cloud ASNs creates operational disruption that is difficult to justify even when those ASNs carry genuine risk. The answer here is risk-proportionate inspection rather than binary block decisions.
CDN and proxy intermediation obscures the true origin ASN. When an attacker routes traffic through a CDN or anonymizing proxy, the ASN you observe belongs to the intermediary, not the actual source. Layer ASN filtering with other signals — behavioral patterns, TLS fingerprinting, user-agent analysis — to maintain detection capability when origin obfuscation is in play.
ASN reassignment and prefix migration can invalidate historical block decisions. A hosting provider that was repeatedly abused may clean up its operations, or its IP ranges may be transferred to a different operator. Your quarterly review process exists specifically to catch these changes before they generate persistent false positives that erode team confidence in the filtering system.
Attacker adaptation is always a factor. Sophisticated actors like Head Mare APT — capable of chaining multiple zero-day vulnerabilities and operating across diverse infrastructure — deliberately use ASNs that blend with legitimate traffic. ASN filtering catches opportunistic attackers and reduces noise effectively; it provides partial but meaningful coverage against advanced persistent threats that actively manage their infrastructure footprint.
Integrating ASN Filtering with Broader Threat Intelligence Operations
ASN-based filtering reaches its full potential when it feeds into and receives data from your broader threat intelligence program. The enrichment flow should operate in both directions: your ASN classifications should inform alert triage and investigation priority, and your investigation findings should update your ASN classifications.
When your team investigates a phishing campaign, document the ASNs hosting the infrastructure and feed that into your classification system. When a threat intelligence subscription flags a new malware family's C2 infrastructure, extract the ASNs and check whether your current policies already cover them or whether a classification update is warranted. This feedback loop — investigation findings enriching filtering policy, filtering signals surfacing investigation leads — is what separates a static blocklist from an adaptive threat filtering capability.
The financial sector threat monitoring data from mid-2026 consistently highlighted that organizations with integrated threat intelligence pipelines detected and contained incidents faster than those operating feeds and filtering policies as disconnected systems. ASN data was a consistent point of integration — flexible enough to be useful across multiple security controls, stable enough to provide durable signal even as individual indicators rotated.
Getting Started Without Overhauling Your Stack
The most common obstacle to implementing ASN-based filtering is the assumption that it requires significant infrastructure investment. The reality is that the first meaningful steps require only log enrichment and a handful of firewall rules, both of which are available in essentially every enterprise security environment.
Start with enrichment. Get ASN data flowing into your SIEM logs. Use that data for 30 days to understand your actual traffic profile before writing a single block rule. Then make decisions grounded in your specific environment's traffic patterns rather than generic assumptions about what ASNs are risky. The enrichment investment pays dividends immediately in investigation speed, and the filtering decisions built on that foundation will be significantly more accurate than policies written from scratch without supporting telemetry.
The threat landscape documented across Q2 and Q3 2026 — APT exploitation of unpatched software, credential theft at scale, identity abuse through trusted channels, fraudulent infrastructure campaigns — consistently shows that attackers rely on infrastructure they can provision quickly, cheaply, and with minimal accountability. ASN-based filtering applies friction exactly where that model is most vulnerable: at the hosting layer where threat actor infrastructure concentrates before individual IPs are spun up and burned through.
