Cloud ASN Risk Watchlist

Most teams that start watching where their traffic comes from build the same rule first, and most of them switch it off within a month. The rule says alert when someone connects from a hosting provider, and it fails for arithmetic reasons, not logical ones. A single large VPS network can carry a corporate VPN concentrator, a vendor’s jump box, a mobile carrier’s NAT egress and an attacker’s rented server on consecutive addresses, and the log shows the same autonomous system number for all four. Alerting on the network alone produces a volume nobody can triage, so the rule gets disabled and the environment ends up with less visibility than before it tried.

This is the catalog I built to make that problem tractable. It separates the networks where a connection genuinely warrants immediate attention from the much larger set where the network is context and nothing more, and it records why each row sits where it does along with what would make that judgement wrong.

An autonomous system number appears in almost every log that records a client address, so nothing here is specific to one vendor or one product. The tiering is the work; where you apply it is your choice.

Downloads

If you came for the files, they are here rather than at the foot of the page. The Excel workbook is the fullest version and the one worth opening if you want to understand the work rather than automate against it. Every sheet is filtered and frozen, and the internal tuning columns are removed. The CSV bundle is the better choice for a SIEM import or any scripted analysis, the JSON carries every sheet in one document, and the text files are a plain ASN list for a quick lookup.

Everything below explains what the tiers mean and how the rows were decided, which is worth reading before the catalog is wired into anything that alerts.

Where this applies

Anything that records the address a request came from can use this catalog, because an autonomous system number is a property of the address rather than of the service being connected to. In practice that covers identity providers and their sign-in logs, VPN concentrators and remote access gateways, firewalls and edge devices, SaaS audit trails, mail gateways, web application firewalls, and the SSH and RDP logs on anything exposed.

The worked examples further down lean on Entra ID and Microsoft 365 because that is where the detection patterns in this release are most developed, and the sign-in telemetry there is rich enough to show what corroboration actually looks like. There are also examples for Splunk against any source-IP index and for Okta, which carries the autonomous system number on every System Log event without any enrichment step. The logic in all of them is the same: find the connection worth looking at, then establish whether anything actually happened.

What the catalog does not do is decide anything on its own, on any platform. That is the next section, and it is the part most watchlists leave out.

An ASN is a risk feature, not attribution

That distinction decides everything else on this page, so it is worth being precise about. When a catalog like this one lists AS62240, it is recording that published reporting and incident evidence placed activity on that network. It is not saying the provider is complicit, that every address there is hostile, or that the operator behind a given sign-in is in the country the number is registered to. Each of those is a separate claim needing separate evidence, and conflating them is how a watchlist turns into an accusation.

What follows from that is a tiering scheme, which is a different artifact from a block list. A tier here answers one question: how much weight can a sign-in from this network carry on its own, before anything else corroborates it. For the top tier the answer is enough to justify looking immediately. For the bottom tier the answer is almost none, which is why those rows ship switched off.

Why a malicious ASN list produces false positives

The false positives are not noise around the edges of a working signal. They are structural. Four distinct causes are worth separating, because each one needs a different response.

Shared infrastructure is the largest. A hosting provider’s business model is renting capacity to anyone who pays, so the same network serves your backup vendor and somebody’s phishing panel simultaneously. The catalog handles this by refusing to promote a commodity hosting network above the context tier without direct evidence tying that specific network to identity attacks, which is why large VPS providers sit at T3 and need a second signal.

Commercial VPN egress is the second, and it is the one that catches organisations out most often. Consumer VPN providers aggregate thousands of unrelated subscribers behind a handful of exit networks. An employee who turns on a personal VPN on a work laptop appears from the same addresses an attacker using the same product would. Whether that is suspicious depends entirely on whether consumer VPN use is expected in your environment, which is a question about your policy, not about the network.

Provider size distorts every count. A network with a million customers generates more abuse reports than one with a thousand, and no feed in this catalog normalises for that. An ASN appearing frequently in indicator lists can simply mean it is large. Nothing here treats volume as evidence of a provider’s character.

Address reassignment breaks the link between history and the present. Prefixes move between holders, registrations get reassigned, and a network that hosted a campaign in 2024 may belong to an unrelated business now. This is why rows get removed on ownership change instead of carrying their old reputation forward, and why every indicator in the download states the window it was observed in. None of them are presented as currently true.

T1 to T4, and what effective enablement means

The tier sets the posture; the enabled flag decides whether a row is live at all. T1 and T2 are enabled throughout. T3 is enabled with a small number of exceptions where the evidence did not survive review. T4 is disabled throughout, and it is the largest tier in the catalog, which is the most honest thing about the structure. Those rows are broad cloud platforms, consumer access ISPs, allocations that are not currently announcing routes, and candidates whose ownership continuity could not be established. The research examined them, which is why they are in the file at all. They ship switched off because an ASN-only match on any of them is more likely to be an employee on a phone than an intruder.

The research workbook behind this release also carries a local override layer, so a row can be forced on or off for one tenant with the reason recorded next to it. That layer is specific to somebody’s environment and is stripped from every public file. What you are downloading is the researched default. Keep your own override column alongside it rather than editing the defaults in place, because the next refresh will otherwise revert decisions you made deliberately.

There is also a review-only set: candidates examined and left disabled, each with the reason recorded. It ships as its own file. What a catalog considered and rejected tells you more about how it was built than its inclusions do, and it is the part most watchlists never publish.

The high-interest ASNs and provider families

The table below carries every network the research can speak to by name, which means it either has a provider-level evidence record or a named actor or campaign attached. That makes the selection checkable instead of an arbitrary sample. The full catalog is considerably larger and ships in the download, because a table of that length is useful in a spreadsheet and hostile on a web page.

Filter by ASN, provider, country, campaign or category. The tier checkboxes narrow it further.

Clouvider AS62240

Clouvider is a legitimate hosting and transit business, and AS62240 carries the catalog’s top tier. Both of those statements are true at once, which makes it the clearest illustration of what the tiering does and does not claim.

The network appears repeatedly in published reporting across credential replay, phishing authentication, malicious VPN access, ransomware access and command and control, and it also featured in a local compromise reported during 2026. Named activity associated with it in the catalog includes Tycoon 2FA, TAG-53, Akira, Fog and ToolShell. That accumulation of independent sightings is what supports immediate triage of a successful interactive employee sign-in from it.

It does not support a claim about Clouvider’s conduct as a company, and the row says so explicitly in its provider role field. The false-positive risk is recorded as medium, not low, and two related Clouvider networks sit in the review-only set at the context tier precisely because the evidence that justifies AS62240 does not transfer to them by association. A provider’s other networks are a separate question, and treating them as one decision is a common way to generate false positives while feeling thorough.

PacketHub, NordVPN egress and the anonymizer problem

Five active PacketHub networks are classified as commercial VPN and anonymizer infrastructure, and the catalog is deliberate about not calling them bulletproof hosting. These are a consumer VPN product’s exit capacity, which carries a different handling profile entirely.

One of the five carries direct token-replay evidence from device-code phishing activity. The rest are included as provider family rather than on individual evidence, and their confidence field records exactly that weaker basis. All five sit at the high tier with a medium to high false-positive risk, because the thing that makes them worth watching also makes them noisy: a legitimate employee with a NordVPN subscription arrives from the same place.

The operational answer is a policy decision before it is a detection decision. If consumer VPN use on managed devices is not expected in your environment, these networks are worth an alert and the alert will be meaningful. If it is tolerated or common, step-up authentication is the better response, and you will want these rows as context attached to other signals instead of a trigger of their own.

GTHost, and why Spamhaus ASN-DROP delisting is not exoneration

GTHost is a small, useful case study in reading feed membership over time. AS63023 was present in the Spamhaus ASN-DROP snapshot of 15 September 2026 and absent from the snapshot two weeks later. It remains in this catalog at the context tier.

Leaving a feed is a change in that feed. A delisting describes that list’s current contents and says nothing about whether the underlying network changed. Spamhaus reporting in the first half of 2026 separately identified GlobalTeleHost among newly prominent botnet command and control networks, and that observation did not expire when the ASN-DROP entry did. The row is kept at the context tier with a high false-positive risk, which is the honest position: enough to be worth correlating, not enough to alert on alone.

The same reasoning runs in the other direction. Appearing on ASN-DROP is current, high-confidence network risk and it is not proof that every customer of that network is malicious. Membership is a strong input to a tier and it is never the only one.

Bulletproof hosting ASNs and sanctioned networks

A smaller group of networks is in a genuinely different category, where the evidence speaks to the provider’s business and not merely to activity that happened to occur there. Spamhaus described Netiface in provider-level bulletproof-hosting terms directly. Media Land and Aeza are source-confirmed bulletproof hosting under sanctions. UFO Hosting is assessed by Recorded Future with high confidence as a successor to Stark infrastructure, and WorkTitans appears as another sanctioned successor entity. Others in the set are source-confirmed active bulletproof hosting, one is tracked as a current malicious prefix-hopping network, and one is recorded as a facilitator carrying upstream risk rather than hosting the activity itself.

These rows carry the top tier with a low to medium false-positive risk, which is unusually low for this catalog and reflects that very little legitimate enterprise traffic originates there. The confidence field on each one records whether the basis is a direct provider-level assessment or a successor and control relationship. Those are different strengths of claim, and collapsing them would overstate the weaker ones.

Joint guidance from CISA, NSA, FBI and international partners on mitigating bulletproof hosting risk is one of the sources behind this section, and it is also the source of a caution worth repeating: whole-ASN blocking affects legitimate services, so baselining, allowlisting and logging come before any deny decision.

Current credential campaigns and edge device infrastructure

Infrastructure rotates faster than tiers do, so the catalog separates ASN-level risk from exact indicators, each carrying its own observation window. Several campaign families drive the current indicator set.

Adversary-in-the-middle phishing kits remain the dominant credential theft route into Microsoft 365, and the catalog tracks both reverse-proxy infrastructure and the phishing-panel backends behind it. Device-code phishing and token replay are represented by their own detection patterns, because the sequence they produce in the logs is distinctive: the same identity and token appearing across different networks, addresses and user agents within minutes.

Anomalous application identifiers are a particularly clean signal when you have them. The catalog carries specific client and resource identifiers observed in campaign activity, including the broker application identifier abused by Tycoon 2FA. Alerting when an unexpected application identifier appears in your tenant’s authentication logs costs very little and does not depend on any network judgement at all.

Edge devices produce the fastest chains in the whole dataset. SonicWall SSL VPN access associated with Akira ransomware activity, and FortiGate management access followed by account creation, VPN configuration changes and credential access, both move from initial access to impact within hours. The detection patterns for those sequences correlate a hosting or VPN origin login with what happens immediately afterwards, which is the only part of the chain fast enough to matter.

Provider families, because a provider is one decision

A hosting business announcing thirty autonomous systems is one handling decision, not thirty. Working ASN by ASN through a family produces inconsistent coverage, where some of a provider’s networks are monitored and others are not for no reason anyone recorded. The family view is how to avoid that.

It also shows where concentration genuinely sits. The largest single family in the enabled set is a Moldovan hosting operation whose networks are almost entirely top tier, which is a more useful thing to know than any individual row within it.

Holder country against event-time IP geolocation

The country field in this catalog records where an autonomous system’s holder is registered with its regional internet registry. That is useful for understanding provider ownership context. For deciding where a sign-in came from it is close to useless, and treating it as a location is the single most common way to misread data of this kind.

The catalog’s own numbers make the point better than an argument does. The United States holds more top-tier networks in this catalog than any other country, by a clear margin. Brazil has a large number of catalog entries and very few enabled ones, because almost all of them are broad access networks that sit in the disabled review tier. A country-based filter built on holder registration would miss most of the first case and generate noise on the second.

For geography-based rules, use event-time IP geolocation and apply the event-country policy column to that, marking each country as expected, no employees, or prohibited according to where your people actually are. Then correlate a match with user history, managed device state, anonymizer classification, travel feasibility and authentication method. A United States exit address can carry a foreign operator’s traffic, and a foreign-registered server can be a compromised host belonging to anyone.

Detection patterns, including Entra ID risky sign-in monitoring

The patterns below are the logic, recorded with the event sources each one needs, what has to corroborate it, and the ATT&CK techniques involved. Most are written against identity telemetry because that is where the evidence in this release is deepest, and the shape of each one carries over to any system that logs an address alongside an account. They are stated as logic and not as finished rules, deliberately. Thresholds that work in one tenant are wrong in another, and a rule presented as universal invites being deployed without tuning.

The ones marked critical share a shape worth noticing. Almost none of them fire on a sign-in. They fire on what happens after it: an authentication method being registered, a token appearing from a second network, a scripted client reading files in bulk, a device registration following suspected session theft. Sign-in infrastructure is how you find the session worth looking at, and post-authentication behaviour is how you establish that something actually happened.

Worked examples for Sentinel, Defender XDR, Splunk and Okta

These queries implement some of the patterns above. Each one states what it needs and what it will wrongly catch, because a detection shipped without its false-positive mode is a detection somebody disables in week two, and the reason they disable it is that nobody told them what to allowlist first.

The Splunk example is the generic one worth reading even if you do not run Splunk, because it shows the whole pattern in four lines: enrich an address with its autonomous system number, join the catalog, filter on tier. Every other query here is a variation on that with a vendor’s field names.

They are correct against the documented schemas as far as review establishes, and they have not been executed against a live tenant as part of this release. Check the Entra audit operation names in the enrollment query against your own environment before trusting it: those operations have been renamed before, and a stale string matches nothing while looking perfectly healthy.

// Needs a Watchlist named CloudASNRiskWatchlist, built from
// utilities/sentinel-watchlist.csv. _GetWatchlist returns every column as a
// string, which is why ASNumber is cast before the join.
let watch =
    _GetWatchlist('CloudASNRiskWatchlist')
    | where Enabled == "Yes" and Tier in ("T1 Critical", "T2 High")
    | project ASNumber = toint(ASNumber), Tier, ProviderFamily, Category, FPRisk;
SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType == 0
| where IsInteractive == true
| join kind=inner watch on $left.AutonomousSystemNumber == $right.ASNumber
| project
    TimeGenerated,
    UserPrincipalName,
    IPAddress,
    AutonomousSystemNumber,
    Tier,
    ProviderFamily,
    Category,
    FPRisk,
    EventCountry = tostring(LocationDetails.countryOrRegion),
    AppDisplayName,
    ClientAppUsed,
    UserAgent,
    Device = tostring(DeviceDetail.displayName),
    Compliant = tostring(DeviceDetail.isCompliant)
| order by TimeGenerated desc

let lookback = 14d;
let watch =
    _GetWatchlist('CloudASNRiskWatchlist')
    | where Enabled == "Yes"
    | project ASNumber = toint(ASNumber), Tier, ProviderFamily;
// The baseline deliberately stops at ago(1d) so today's activity cannot
// baseline itself and disappear.
let baseline =
    SigninLogs
    | where TimeGenerated between (ago(lookback) .. ago(1d))
    | where ResultType == 0
    | summarize KnownAsns = make_set(AutonomousSystemNumber, 1000)
        by UserPrincipalName;
SigninLogs
| where TimeGenerated > ago(1d)
| where ResultType == 0
| where IsInteractive == true
| join kind=inner watch on $left.AutonomousSystemNumber == $right.ASNumber
| join kind=leftouter baseline on UserPrincipalName
| where isnull(KnownAsns) or not(set_has_element(KnownAsns, AutonomousSystemNumber))
| project
    TimeGenerated,
    UserPrincipalName,
    IPAddress,
    AutonomousSystemNumber,
    Tier,
    ProviderFamily,
    NoBaseline = isnull(KnownAsns),
    Device = tostring(DeviceDetail.displayName),
    Compliant = tostring(DeviceDetail.isCompliant),
    EventCountry = tostring(LocationDetails.countryOrRegion)
| order by TimeGenerated desc

let watch =
    _GetWatchlist('CloudASNRiskWatchlist')
    | where Enabled == "Yes"
    | project ASNumber = toint(ASNumber), Tier, ProviderFamily;
SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType == 0
| where AuthenticationProtocol =~ "deviceCode"
    or OriginalTransferMethod =~ "deviceCodeFlow"
// leftouter: an unlisted ASN is still worth seeing here.
| join kind=leftouter watch on $left.AutonomousSystemNumber == $right.ASNumber
| project
    TimeGenerated,
    UserPrincipalName,
    IPAddress,
    AutonomousSystemNumber,
    Tier = coalesce(Tier, "not in catalog"),
    ProviderFamily,
    AppDisplayName,
    ResourceDisplayName,
    UserAgent,
    CorrelationId
| order by TimeGenerated desc

let window = 15m;
let watch =
    _GetWatchlist('CloudASNRiskWatchlist')
    | where Enabled == "Yes" and Tier in ("T1 Critical", "T2 High")
    | project ASNumber = toint(ASNumber), Tier, ProviderFamily;
let risky =
    union SigninLogs, AADNonInteractiveUserSignInLogs
    | where TimeGenerated > ago(7d)
    | where ResultType == 0
    | join kind=inner watch on $left.AutonomousSystemNumber == $right.ASNumber
    | project
        SignInTime = TimeGenerated,
        UserPrincipalName,
        IPAddress,
        AutonomousSystemNumber,
        Tier,
        ProviderFamily;
let enrolment =
    AuditLogs
    | where TimeGenerated > ago(7d)
    // Verify these against your tenant. Entra has renamed them before.
    | where OperationName has_any (
        "User registered security info",
        "User registered all required security info",
        "Admin registered security info",
        "User changed default security info",
        "Add strong authentication method",
        "Add registered device",
        "Register device")
    | extend Actor = tostring(InitiatedBy.user.userPrincipalName)
    | where isnotempty(Actor)
    | project
        EnrolTime = TimeGenerated,
        UserPrincipalName = Actor,
        OperationName,
        AuditResult = tostring(Result);
risky
| join kind=inner enrolment on UserPrincipalName
| where EnrolTime between (SignInTime .. (SignInTime + window))
| project
    SignInTime,
    EnrolTime,
    Gap = EnrolTime - SignInTime,
    UserPrincipalName,
    IPAddress,
    AutonomousSystemNumber,
    Tier,
    ProviderFamily,
    OperationName,
    AuditResult
| order by SignInTime desc

let window = 30m;
union SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(1d)
| where ResultType == 0
| where isnotempty(UserPrincipalName) and AutonomousSystemNumber > 0
// bin() is a fixed bucket, not a sliding window: a sequence that straddles a
// boundary is split in two and will not be caught here.
| summarize
    Asns = make_set(AutonomousSystemNumber, 100),
    Ips = make_set(IPAddress, 100),
    Agents = make_set(UserAgent, 50),
    Events = count()
    by UserPrincipalName, Window = bin(TimeGenerated, window)
| where array_length(Asns) > 1
| extend AsnCount = array_length(Asns), IpCount = array_length(Ips)
| order by AsnCount desc, Events desc

// Replace this sample with the full AsnT1T2 block from
// utilities/asn-sets.kql in the download bundle. Three entries shown so the
// query is runnable as pasted.
let AsnT1T2 = dynamic([62240, 136787, 206728]);
AADSignInEventsBeta
| where Timestamp > ago(7d)
| where ErrorCode == 0
| where set_has_element(AsnT1T2, AutonomousSystemNumber)
| project
    Timestamp,
    AccountUpn,
    IPAddress,
    AutonomousSystemNumber,
    Country,
    Application,
    ClientAppUsed,
    UserAgent,
    DeviceName,
    IsManaged,
    IsCompliant
| order by Timestamp desc

let agents = dynamic(["python-requests", "python-httpx", "aiohttp", "curl",
                      "Go-http-client", "PowerShell", "WinHttp"]);
CloudAppEvents
| where Timestamp > ago(7d)
| where ActionType == "FileAccessed"
| extend Ua = tostring(RawEventData.UserAgent)
| where isnotempty(Ua) and Ua has_any (agents)
| summarize
    Files = dcount(tostring(RawEventData.ObjectId)),
    Events = count(),
    Ips = make_set(IPAddress, 20)
    by AccountDisplayName, Ua, Window = bin(Timestamp, 2h)
| where Files >= 100
| order by Files desc

``` Generic shape. Replace the index and the field names with your own. ```

``` src_asn has to come from the event or from a lookup. Splunk's iplocation
    command does NOT provide an ASN, only geo fields, so if your source does
    not carry the number already, uncomment the GeoLite2-ASN line below. ```

index=auth action=success
``` | lookup geolite2_asn ip AS src_ip OUTPUT autonomous_system_number AS src_asn ```
| lookup asn_watchlist ASNumber AS src_asn
    OUTPUT Tier, ProviderFamily, Category, FPRisk, Enabled
| where Enabled="Yes" AND Tier IN ("T1 Critical", "T2 High")
| stats count,
        values(Tier) AS tier,
        values(ProviderFamily) AS provider,
        values(FPRisk) AS fp_risk,
        dc(src_ip) AS distinct_ips
        BY user, src_asn
| sort - count

eventType eq "user.session.start" and outcome.result eq "SUCCESS" and (securityContext.asNumber eq 62240 or securityContext.asNumber eq 136787 or securityContext.asNumber eq 206728)

Loading the list into the platform you already run

In Microsoft Sentinel, import the Sentinel Watchlist CSV from the download bundle and key it on the ASNumber column. That file exists because the obvious mistake is to ship only the AS-prefixed form, which then fails to join against the integer autonomous system number in the sign-in tables and matches nothing. Keeping the list in a watchlist, instead of inline in each analytics rule, means a weekly refresh costs one import and not an edit to every rule.

Defender XDR advanced hunting has no watchlist feature, so the set has to travel inside the query. The bundle includes paste-ready set literals for that, one for the alerting tiers and one for everything enabled. The cost of this approach is that a literal pasted into a custom detection goes stale the moment the catalog updates, so either refresh it on the same cadence or keep the authoritative copy in Sentinel and treat the XDR rules as hunting.

I have used this catalog in Microsoft Defender for Cloud, where what it mostly buys you is enrichment. A flagged connection reads differently once you know the network on the other end has documented identity-attack history, and that changes how quickly somebody picks it up. The alerting value there is secondary to having the context attached when a human finally looks.

Outside the Microsoft estate the mechanics change and the judgement does not. Splunk and most SIEMs want the Sentinel Watchlist CSV as an ordinary lookup table keyed on the ASN number, which is why that file ships with a bare numeric column alongside the AS-prefixed one. Okta needs no enrichment at all, since every System Log event already carries the autonomous system number. Firewalls and edge devices generally want the plain text file, though feeding an enforcement device directly from any of this is the one use I would argue against without a dependency review first.

For Entra ID Conditional Access, the honest guidance is to be conservative. Named locations and risk policies built from this list can work, and the tier structure matters more here than anywhere else: the alerting tiers are defensible inputs to a step-up requirement, and the review tier should never drive a policy because it contains broad cloud and consumer access networks. Validate against your own sign-in history before enforcing anything, and keep allowlists for your workloads, vendors, SASE egress, VPN concentrators and admin jump hosts. A Conditional Access policy that locks out an administrator is a worse outcome than the sign-in it was meant to stop.

Community feeds, and why four lists are not four witnesses

Public indicator feeds are used here for exact-address enrichment and short-lived hunting. They do not drive tiering, and the overlap figures explain why. Tens of thousands of addresses appear on more than one of these lists, and the reason is shared source lineage between the lists themselves. Those are not separate parties confirming each other. Cross-list presence is frequently one observation reported several times.

One feed in this set is recorded as rejected rather than used, because its contents were byte-identical for over a month across more than a hundred consecutive failed updates. A stale list that looks live is worse than no list, and publishing that rejection is more useful than quietly omitting the feed.

What changed in this refresh

The page states both the evidence snapshot date and the build date, and they are different on purpose. A rebuild is not new evidence, and presenting the two as one number is how a stale catalog looks current.

Methodology and limitations

The catalog is assembled from current machine-readable feeds, published vendor and government reporting, registry and routing data, and incident evidence, with every tiering decision resolving to a numbered source record. The full methodology ships in the bundle. The limitations deserve stating here rather than only in a download, because they are the conditions under which this data will be wrong.

Bring-your-own-IP addressing, suballocation, address reassignment, residential and mobile proxy egress, anycast addressing, compromised legitimate hosts and provider size can each break the link between a network and the activity attributed to it. Routing data shows which network announces a prefix, which is not always the party controlling the addresses inside it. Feed membership changes for reasons that have nothing to do with a network’s behaviour. None of this makes the data unusable, and all of it means the data is an input to a judgement and never a substitute for one.

On provider complicity, the position is the same throughout and it is not a disclaimer added at the end. Several networks here belong to legitimate hosting, transit and commercial VPN businesses. They are listed because reporting or incident evidence placed activity on their infrastructure. Where the research has a view on a provider’s role it is recorded in the provider role field, and for most rows that view is that infrastructure use was observed and no complicity claim is made. A tier is a monitoring priority and reading it as an allegation misreads the file.

The catalog is free to use with attribution under CC BY 4.0. Corrections are welcome and useful, particularly from providers who can show that a row is out of date.

Who built this

I have spent about twenty years building and operating security systems, and I spent a long time before that learning how systems fail instead of how they are documented to work. That is roughly the skill this catalog needs, because the gap between what an autonomous system number is supposed to tell you and what it actually tells you is where all the false positives live. There is more about me on the about page.

This research exists because the generic version of it did not work in environments I was responsible for. The tiering, the review-only set, the separation of holder country from event geolocation and the insistence on recording what would make each row wrong are all consequences of watching the simpler approach fail. It is refreshed weekly, and the page is updated when the data changes, not when the date does.