Most teams treat an ASN block as a binary perimeter decision: if the number looks dirty, every packet from that network gets the same fate. That habit fails the moment your customer portal, partner VPN, and remote support brokers share the same hosting or carrier neighbors. ASN-based threat filtering only works when you score the Autonomous System by path criticality, not by a single reputation label.
Storm-0940's link to ConnectWise-style supply chain activity, MATCHBOIL's quieter proxy and DNS timing tricks, and mass PHP exploit scouting all show the same pattern. Abuse concentrates inside a handful of ASNs long before individual source IPs stabilize on your blocklists. Sanction actions such as the U.K. move against Cryptomus push the same lesson into policy: infrastructure numbers become actionable faster than tidy attribution. The mistake is applying one ASN verdict to every service that happens to face the internet.
Why a single ASN verdict breaks operations
Security stacks often ingest ASN enrichment as a column on an alert and then promote that column into a firewall object. The object lands at the top of the inbound rulebase. Analysts feel progress because hit counts climb. Operators feel pain because legitimate tenants behind the same ASN lose login, webhook delivery, or RMM reachability in the same change window.
Three failure modes show up repeatedly:
- Shared cloud density. A noisy scanner prefix and a clean SaaS tenant share an ASN. A blanket deny freezes partner automation that your SOC still needs during containment.
- Path blindness. Customer auth, OAuth token exchange, and remote support consoles sit behind different risk tolerances. One ASN cap on "any inbound TCP" collapses those distinctions.
- Stale ownership. Bulletproof or repeatedly abused ASNs churn tenants. Yesterday's deny still matches the number while today's prefixes serve different customers with different risk.
Texas laptop-farm enforcement and residential proxy abuse add another wrinkle. Carrier ASNs that look "normal" in GeoIP still deliver high volumes of credential stuffing and MFA fatigue. Country filters and IP reputation scores lag that reality. ASN context helps, but only when you apply it where identity decisions happen.
Score the ASN by what it touches
Build a short decision matrix before you create any new ASN object. For each candidate ASN, answer four questions with evidence from the last 24 to 72 hours:
- Which internal services saw the traffic: public web, customer auth, OAuth/token endpoints, mail, VPN, or RMM/remote support?
- Is the signal inbound scouting, outbound callback, or both?
- Do you still depend on other tenants in that ASN for patches, payment webhooks, or partner APIs?
- Is the ASN itself the risk (repeat bulletproof or sanctioned infrastructure), or is one prefix acting as a temporary staging pad?
If the answers diverge by service, your policy must diverge by service. That is the core of usable ASN filtering.
A practical split: portal auth versus remote support
Use two ASN control planes with different timers and owners.
Customer auth and public APIs
Here volume and spray matter most. When exploit notices for PHP, edge appliances, or portal frameworks drive overnight scout spikes from a hosting ASN, prefer a time-boxed rate cap or challenge on the auth VIP before a hard deny. Keep the window short, for example 6 to 24 hours, and bind it to an advisory ticket so the object expires when the scout wave ends.
Implementation details that hold up under pressure:
- Match on source ASN plus destination service object, never source ASN alone.
- Log allow-with-challenge outcomes into the same SIEM join you use for MFA failures and password spray.
- Promote to deny only after you confirm the ASN still concentrates probes after the rate cap, and after you check that no named partner tenant lives behind it.
Remote support and management consoles
RMM and remote support paths deserve a stricter default and a slower promote-to-deny path. Storm-0940-style activity shows attackers prize these planes because one compromised broker reaches many endpoints. Cap anonymous internet ingress to the support portal aggressively by ASN watchlists derived from known abuse hosting. Keep a separate allow corridor for named vendor and MSP prefixes, reviewed weekly, with ticketed exceptions.
Do not reuse the customer-auth ASN object on the RMM VIP. Shared objects make rollback unsafe when one plane needs relief and the other still needs pressure.
Egress holds when inbound IPs keep rotating
Per-IP inbound lists lag during scout waves. Hosting ASNs rotate prefixes while callback destinations stay sticky. Put ASN context on egress early:
- Hold or sinkhole outbound connections to ASNs repeatedly tied to C2, ransomware staging, or sanctioned payment rails.
- Join those holds to process and parent process fields so you catch RMM agents and living-off-the-land tools that phone home through "business" ports.
- Keep an explicit exception process for payment and logistics partners so sanctioned-infrastructure denies do not silently break merchant webhooks.
OAuth attack campaigns often stage token theft relays on cheap cloud ASNs that also host clean apps. Treat ASN hits on token endpoints as hunt seeds: pull user-agent, redirect URI, and ASN together before you widen to a network-wide deny.
Evidence pack before you widen scope
Before an ASN moves from watch to cap to deny, require a one-page packet:
- Earliest internal sighting and earliest public malware or abuse sighting for related IPs.
- Prefix list actually observed, with tenure notes if new space appeared this week.
- Services hit and whether any legitimate tenant shares the ASN.
- Proposed control (watch, rate cap, challenge, deny) and expiry.
- Owner and rollback contact for the change window.
This keeps ASN policy from becoming folklore after the next advisory crowd arrives.
Runbook you can rehearse
Walk this sequence during your next exploit week tabletop:
- Ingest overnight ASN-enriched edge and auth logs; rank ASNs by distinct destinations hit, not raw packet count.
- Open two draft objects: Auth-ASN-Cap and RMM-ASN-Cap, both empty.
- Fill Auth-ASN-Cap with high-scout hosting ASNs at challenge or connection rate limits on portal VIPs only.
- Fill RMM-ASN-Cap with anonymous-internet denies toward support consoles, excluding named MSP allows.
- Add egress holds for callback ASNs tied to the same campaign notes.
- Set 12-hour review alarms; retire or renew with written evidence, not vibes.
- Feed partial campaign notes upstream the same day so peer defenders see the ASN fingerprint before perfect attribution lands.
Takeaways worth keeping on the wall
- ASN filtering is a service-scoped control, not a global reputation switch.
- Split customer auth from remote support so supply-chain and spray risks get different timers.
- Prefer short ASN caps and challenges on portals; reserve hard denies for management planes and sticky callback ASNs.
- Always check shared tenants and sanctioned-payment exceptions before a number enters production.
- Expire ASN objects on a calendar. Numbers outlive the campaigns that made them famous.
Teams that treat ASN context as path-aware policy convert scout noise and supply-chain chatter into same-day containment. Teams that paste one ASN deny across every VIP trade a quiet firewall for a noisy outage during the week they can least afford it.
