Within hours of CISA publishing its warning on a critical pre-auth remote code execution flaw in MikroTik RouterOS, a mid-size MSP watched Winbox and API probes climb from background noise to sustained bursts against customer edge routers. Patch tickets were already open. Per-IP blocklists still showed yesterday's scanners. The sources that mattered clustered inside a small set of bulletproof and low-cost VPS autonomous systems that specialized in short-lived tenants and rapid renumbering.
One branch router remained unpatched through a change freeze. Operators later tied the compromise to a source ASN that had never appeared on their deny list as a single bad address, yet had driven the majority of RouterOS management scans that week. ASN-based threat filtering would have narrowed who could speak to management ports while signatures and vendor firmware still lagged.
Why ASN context beats waiting for the next IP listing
Mass exploit waves against edge appliances follow a predictable logistics pattern. Operators rent capacity in ASNs that tolerate aggressive scanning, recycle prefixes quickly, and answer abuse tickets slowly. Individual source IPs rotate faster than most reputation feeds refresh. The ASN, and often a /24 or peer group under it, stays stable across the campaign.
That pattern showed up again when public GitHub dumps exposed hundreds of thousands of valid credentials and stuffing traffic shifted across fresh VPS ranges in the same hosting networks. Extortion crews linked to investigations such as ShinyHunters have reused similar hosting footprints when rotating infrastructure. For IT administrators, the durable control surface is the network origin class, not the ephemeral host.
What ASN filtering actually means in production
ASN-based threat filtering maps source or destination traffic to an autonomous system number, then applies policy by risk tier, role, or temporary quarantine. Practical deployments combine:
- Enrichment at the edge or SIEM that tags flows, VPN sessions, and auth events with ASN and organization name
- Class scoring that separates residential ISPs, enterprise networks, major cloud providers, CDNs, and low-reputation hosting or bulletproof space
- Path-scoped rules that apply the strictest ASN policy to management planes, admin portals, and VPN concentrators first
- Time-boxed escalations tied to advisories, exploit proof-of-concept release, and observed probe velocity
Blanket ASN denies across all inbound HTTPS create outages when customers and partners sit behind large cloud or carrier ASNs. Scoped filtering on high-value paths delivers most of the defensive value with less collateral damage.
A failure case that keeps repeating on RouterOS edges
Consider a retailer with two dozen MikroTik devices terminating site VPNs and guest Wi-Fi. Winbox (TCP 8291), the API port, and the web UI were reachable from the public internet "for remote support." Country geo filters were in place. ASN policy was not.
After the CISA advisory, scanners from three hosting ASNs accounted for more than 90 percent of management-port hits across those sites. Geo rules still allowed the traffic because the rented VPS regions sat in permitted countries. Per-IP automation added dozens of addresses per hour and still trailed the campaign. The unpatched branch router accepted a pre-auth exploit chain, dropped a persistence implant, and later opened outbound callbacks into neighboring address space under the same ASN family.
Incident response spent the first day chasing single IPs. The useful containment step was closing management exposure to the internet and allowing only a short list of corporate and jump-host ASNs to reach Winbox and API listeners.
Build an ASN risk ladder before the next advisory lands
Start with inventory, not with a giant deny list. Export every path that accepts administrative authentication or appliance control: Winbox, router HTTP(S), SSH on network gear, hypervisor consoles, VPN admin UIs, cloud control-plane break-glass routes, and identity provider emergency access.
Then classify ASNs you already observe in 30 to 90 days of edge logs:
- Trusted operational ASNs for NOC jump hosts, managed service providers, and primary ISP handoffs you intentionally use for admin work
- Broad user ASNs such as major consumer ISPs and mobile carriers that should reach customer apps but almost never need router management ports
- Shared cloud and CDN ASNs that require careful exceptions for APIs and partner integrations, yet deserve default deny on appliance admin listeners
- Elevated-risk hosting ASNs repeatedly tied to scanning, exploit kits, bulletproof hosting, or rapid prefix churn
Feed classification from multiple signals: historical hit counts on management ports, abuse desk response quality, RIR and peering notes, commercial threat intel ASN scores, and whether the ASN appears in your own honeypot or decoy admin path telemetry.
Policy that fits a patch window
When an edge RCE advisory hits, raise the ladder without waiting for firmware everywhere:
- Default-deny public internet to management ports; allow only trusted operational ASNs plus a break-glass source
- Quarantine elevated-risk hosting ASNs at the perimeter for those ports, and optionally for VPN authentication when probe volume spikes
- Rate-limit or tarpit remaining unknown ASNs hitting admin paths rather than treating them like ordinary web clients
- Mirror the same ASN tags into SIEM correlation so auth failures from elevated-risk ASNs page faster than failures from residential broadband
Keep user-facing application ports on a separate policy track. Mixing "block noisy hosting ASN" into checkout or content delivery paths is how teams freeze shared cloud customers and create executive exceptions that never expire.
Implementation details that survive contact with operations
On firewalls and routers, prefer vendor features that match by ASN or by regularly refreshed prefix sets derived from ASN origin. Many teams export ASN prefixes via BGP or periodic IRR/RPKI-informed pulls into object groups. Refresh cadence matters: a weekly prefix sync lags campaigns that renumber daily inside the same ASN, while sub-hourly syncs need automation and change review.
For cloud WAFs and zero-trust brokers, push ASN enrichment into access policies on admin applications first. Example rule logic: allow app = router-admin only when source ASN ∈ trusted_ops and device posture passes. Send everything else to deny and retain full request metadata for hunt work.
In the SIEM, store ASN and AS organization as first-class fields on firewall, VPN, and identity events. Build a dashboard that ranks management-port volume by ASN during advisory weeks. When Microsoft-scale patch cycles and other high-profile disclosure periods drive opportunistic scanning, that dashboard shows whether your elevated-risk tier still matches reality or needs retuning.
Tradeoffs and caveats
ASN filters inherit the messiness of internet routing. Anycast, CGNAT, and cloud multi-tenant prefixes mean one ASN can host both hostile scanners and legitimate SaaS. A deny aimed at exploit infrastructure can clip a partner's automation if that partner egresses from the same cloud ASN. Document exceptions with owners and expiry dates.
Prefix hijacks and stale IRR data can mis-map traffic. Prefer RPKI-validated origin information where your tooling supports it, and keep a manual override path for false positives during incidents.
Temporary ASN quarantine is powerful during ransomware callback hunts and exploit waves, yet it ages poorly if nobody revisits the list after tenants churn. Schedule a review whenever an elevated-risk ASN stays quiet for a defined window, and when a trusted ASN suddenly originates management scans it never sent before.
Legal and upstream constraints also apply. Some carriers and cloud providers limit how aggressively you can blackhole their space on shared segments. Prefer dropping at your edge on specific destinations and ports over advertising indiscriminate ASN blocks upstream.
A workable playbook for the next edge RCE cycle
- Within one hour of a critical appliance advisory, confirm which management ports are internet-reachable and which ASNs currently hit them.
- Apply trusted-ASN allowlists on those ports immediately; move elevated-risk hosting ASNs to deny or quarantine for the same listeners.
- Open patch and compensating-control tickets in parallel, including network ACLs for devices that cannot patch during a freeze.
- Hunt auth and session logs for successful management access from non-trusted ASNs in the pre-advisory window.
- After patches complete, keep ASN enrichment on and lower quarantine tiers deliberately rather than deleting the policy stack.
Takeaways for SOC and network teams
ASN-based threat filtering earns its keep when attackers rotate addresses inside stable hosting networks and your per-IP lists trail the campaign. Scope it first to management planes and other high-impact paths, classify ASNs by operational role, and escalate tiers when advisories like the MikroTik RouterOS RCE warning turn routine scanners into exploit hunters. Pair the controls with enrichment in your logs so analysts investigate by campaign footprint instead of isolated addresses. Revisit elevated-risk ASN membership on a fixed cadence so yesterday's bulletproof neighbor does not become tomorrow's silent hole in the policy.
