Post cover image

July 15, 2026

Common ASN Patterns Seen in Phishing Infrastructure

Domain blocklists react after the fact. By the time a phishing domain gets reported, added to Safe Browsing, and pushed out to filtering…

By Paritosh

5 min read

Domain blocklists react after the fact. By the time a phishing domain gets reported, added to Safe Browsing, and pushed out to filtering products, the kit has usually already harvested a batch of credentials and moved on. Autonomous System data gives defenders a signal that shows up earlier and survives domain rotation, because standing up new IP space costs more time and money than registering a new domain.

This writeup breaks down the technical patterns analysts look for when correlating phishing infrastructure to its hosting networks, with the queries and data sources used to surface them.

Why look at the ASN layer at all

Every IP address on the public internet sits inside a block announced by an Autonomous System. That announcement is public routing data, visible in BGP tables and archived by projects like RIPEstat, RouteViews, and Team Cymru. A phishing operator can burn through hundreds of throwaway domains in a week, but the IP space behind them, and the ASN announcing that space, changes far less often. Pivoting from domain to IP to ASN is one of the highest value moves in triage.

A basic pivot chain looks like this:

dig +short phish-lure.example.com
# 185.220.xx.xx
whois -h whois.cymru.com " -v 185.220.xx.xx"
# AS      | IP               | AS Name
# 44477   | 185.220.xx.xx    | STARK-INDUSTRIES-SOLUTIONS-LTD

Once you have the ASN, the next step is pulling its announced prefixes and history:

curl -s "https://stat.ripe.net/data/announced-prefixes/data.json?resource=AS44477"

Pattern 1: Traffic concentration in a small set of networks

Across large phishing datasets (APWG, PhishStats exports, urlscan.io corpora), a disproportionate share of malicious hosts trace back to a repeating shortlist of ASNs rather than being evenly spread across the roughly 75,000 active networks on the internet. A quick way to check this on your own data:

import pandas as pd
df = pd.read_csv("phishing_iocs.csv")  # columns: url, ip, asn, asn_name
top = df.groupby(["asn", "asn_name"]).size().sort_values(ascending=False).head(20)
print(top)

Running this against any reasonably sized phishing feed tends to surface the same handful of networks at the top, month after month, even as the underlying kits and lure brands change completely.

Pattern 2: Bulletproof and semi bulletproof hosting

"Bulletproof hosting" describes providers that market themselves, directly or through reseller channels, on lax abuse handling and slow response to takedown requests. The names rotate as providers get deregistered or rebrand, but the operating model is consistent: minimal KYC, cryptocurrency payment options, and abuse tickets that go unanswered for weeks.

Some networks repeatedly named in public threat intel writeups (Spamhaus, Krebs on Security, multiple vendor blogs) over the last several years include:

| ASN      | ASN Name (Historical)                  | Commonly Flagged For                             |
| -------- | -------------------------------------- | ------------------------------------------------ |
| AS44477  | Stark Industries Solutions             | Malware C2, phishing, DDoS infrastructure        |
| AS197540 | Netskin / Former Ecatel Descendants    | Long-running abuse complaints                    |
| AS49505  | Selectel (mixed legitimate and abused) | Compromised customer accounts, some direct abuse |
| AS29073  | Quasi Networks / Ecatel Lineage        | Historic bulletproof hosting reputation          |

Table entries like this should be treated as reputational snapshots, not permanent verdicts. Ownership, abuse handling, and even ASN numbers themselves change over time as companies restructure.

None

Pattern 3: Freshly allocated ASNs with short lifespans

RIRs (ARIN, RIPE NCC, APNIC, LACNIC, AFRINIC) publish allocation timestamps. Cross referencing an ASN's registration date against when it started appearing in abuse feeds is a strong early indicator:

curl -s "https://stat.ripe.net/data/rir.json?resource=AS213xxx"

An ASN allocated four to six weeks before it shows up hosting a wave of freshly registered phishing domains, then goes dark shortly after, is a much stronger signal than an old, established ASN with a single flagged IP. Analysts often track this as asn_age_days at time of first abuse sighting, and set alerting thresholds around anything under 90 days.

Pattern 4: Leased or brokered IPv4 space

A large amount of legacy IPv4 space, originally allocated decades ago to universities, defence contractors, or early ISPs that no longer use it, now moves through IP leasing brokers. Phishing infrastructure frequently rides on this leased space rather than address blocks the hosting ASN originally received.

The tell is a mismatch between the announcing ASN and the WHOIS registrant of the underlying block:

whois 185.xx.xx.0/24
# NetName: LEGACY-BLOCK-1998
# OrgName: Some Defunct Research Institute

whois -h whois.cymru.com " -v 185.xx.xx.10"
# AS Name: Totally unrelated hosting company, registered 2023

That gap between a decades old registrant and a newly formed announcing network is worth flagging on its own.

Pattern 5: Geographic and routing anomalies

Legitimate regional ISPs peer in ways that make physical and business sense. Phishing focused infrastructure sometimes doesn't need to, since there's no real customer base to serve. Checking an ASN's upstream transit providers against its registered country using tools like bgp.he.net or RIPEstat's asn-neighbours endpoint can reveal setups where all traffic is routed through transit in a completely different region than the RIR registration would suggest.

curl -s "https://stat.ripe.net/data/asn-neighbours/data.json?resource=AS213xxx"

Pattern 6: The same ASN reused across unrelated campaigns

Clustering unrelated phishing kits (different target brands, different templates, different registrars) and finding they all resolve back to the same ASN usually indicates the network is being rented out as shared infrastructure to multiple independent actors, rather than run by a single group. This is one of the more reliable pivots in a graph based threat intel platform (Maltego, internal Neo4j graphs, or even a simple pandas group by like the one above) because it survives changes in kit tooling and target selection.

Pattern 7: Rapid IP churn inside one ASN

Passive DNS history frequently shows domains rotating across new IPs within the same /24 or the same ASN every few days, as prior addresses get block listed. This is different from CDN style load balancing because the churn correlates with blocklist events rather than traffic load. A simple heuristic:

# flag ASNs where >80% of their IPs seen in the feed
# were only active for less than 72 hours
df["active_hours"] = (df.last_seen - df.first_seen).dt.total_seconds() / 3600
short_lived = df[df.active_hours < 72]
churn_rate = short_lived.groupby("asn").size() / df.groupby("asn").size()

Pattern 8: Abuse riding inside legitimate cloud and CDN ASNs

Not every pattern points to an obscure network. A meaningful share of phishing pages now sit behind major cloud and CDN ASNs (large, well known hosting and content delivery providers), using free tiers, compromised customer accounts, or object storage buckets. In these cases the ASN itself carries no negative reputation, so detection has to shift down a layer, to the certificate, the storage bucket path, or the specific account rather than the network.

Pattern 9: Registries with historically lighter verification

Certain regional registries have, at various points, processed new ASN and IP block requests with less scrutiny than others. This isn't a fixed geographic rule and shifts whenever a registry tightens its process, but abuse researchers do track which registries are currently seeing a spike in newly formed, thinly documented ASNs.

Building a simple scoring model

A practical way to combine these signals without relying on any single one is a weighted score:

def asn_risk_score(row):
    score = 0
    if row["asn_age_days"] < 90: score += 3
    if row["registrant_mismatch"]: score += 2
    if row["seen_in_unrelated_clusters"] >= 3: score += 3
    if row["churn_rate"] > 0.8: score += 2
    if row["known_bulletproof_list"]: score += 4
    return score

None of these signals is conclusive by itself. New ASNs get allocated legitimately every day, and small providers can have thin abuse teams without being complicit in anything. The value is in correlation: a young ASN, hosting a burst of newly registered domains, with a registrant mismatch, appearing across multiple unrelated campaigns, is a very different signal than any single fact taken alone.

Takeaway

Feeding ASN level data (allocation age, routing behaviour, registrant mismatches, historical abuse reports) into detection pipelines gives defenders a signal that shows up well before a domain gets reported and block listed. Domains are the cheapest thing an operator controls. The network underneath them is the part that's actually expensive to replace, which is exactly why it's worth watching.