TI-2026-066A — Trusted by Default

Series: The Allowlist · Part A · Classification: HIGH · Confidence: HIGH

Somewhere in almost every firewall on earth is a rule that says, in effect: allow Microsoft, allow Google, allow Cloudflare, allow AWS. It is written to stop false positives — you cannot block the clouds your own services depend on. This series is about what walks through that rule. The short version: most of the attackers do.

Executive Summary

We took every web IP our platform assigned a genuine attack intent — credential harvesting, shell upload, CMS probing, admin hunting — and asked one question: where do they live? The answer inverts the reputation model the whole industry runs on.

• 2,137 IPs earned a real attack-intent label (out of 10,114 observed — we count only the labelled ones, not the crawler-and-404 noise).
• 1,346 of them — 63.0% — ride the major hyperscalers: Microsoft (508), Google Cloud (490), DigitalOcean (152), Cloudflare (76), Amazon (63), Alibaba (22), Oracle (17).
• Their intents are unambiguous: credential_harvest 987, cms_detect 514, shell_upload 377.
• And they arrive in costume — Google Cloud IPs running credential harvest behind a browser user-agent, Microsoft IPs running shell upload behind an empty one.

The clouds you allowlist by reputation are the single largest origin of the attacks that reach you. The allowlist is not a shield. It is the door.

I. The Number That Breaks the Model

Reputation-based defense rests on an assumption: bad traffic comes from bad neighborhoods — bulletproof hosts, sketchy ASNs, countries on a list. Block the bad neighborhoods, trust the good ones, done. The data does not cooperate.

The top of the attacker leaderboard is not a rogues' gallery. It is the reference architecture of the modern internet. Sixty-three percent of everything we could positively call an attacker was launched from an address a default firewall waves through.

(Methodology, stated up front: we count only IPs with a classified attack intent, and we score with effective_bad_rate — the login-page 200 mask pierced to its real 401/404 — so a benign crawler generating 404s is not miscounted as an attacker. The 63% is a floor, not an inflation.)

II. The Costume — Why It Works Silently

A reputation allowlist fails safe only if attackers announce themselves. They do the opposite. Laid against user-agent, the trusted-cloud attacks are wearing disguises:

A residential browser hitting a login form is normal. A datacenter IP presenting a residential-browser user-agent while sweeping for credentials is a costume — the request claims to be something the network it came from could never be. Reputation defense reads the costume (trusted ASN + browser UA) and waves it through. Behaviour defense reads the conduct (credential_harvest, effective_bad_rate near 1.0) and stops it. This series is the argument for the second kind. (Part B, The Browser Costume, takes the disguise apart on its own.)

III. Four IPs You Would Have Allowed

Abstractions are easy to wave off, so here are four addresses, each eligible for a default allowlist, each behaving purely maliciously:

20.104.203.253 sent 1,479 requests, every one hostile, from Microsoft's address space, wearing no identity at all. If your rule is "trust Azure," you trusted it 1,479 times.

IV. The Seven Questions

Who is this? 1,346 attacker IPs renting reputable clouds. Why did they attack? The usual: credentials, shells, footholds. Who do they claim to be? A trusted cloud, often plus a browser — two borrowed identities stacked. Who are they really? Disposable tenants; the cloud is a costume rack, not an owner. Whom are they related to? Each other only loosely — what unites them is the choice of launch point, not a common operator. Where is the money? In the allowlist bypass itself: a pre-trusted IP is worth paying cloud rent for. What is the official anchor? The providers' own abuse desks — which exist, and which the volume outruns.

V. Steelman — "Of Course the Big Clouds Have the Most IPs"

The strongest objection: hyperscalers host most of the internet's compute, so of course they host most of everything, including attackers. This is a denominator artifact, not a finding. And your classifier probably over-labels benign cloud services as attackers.

Both halves deserve an answer, and the first is partly right: the clouds are big, so raw counts will lean their way. But the finding is not "big clouds are big." It is that the reputation model treats size as safety — it grants the largest networks the most trust precisely where they host the most abuse, and it does so by default, without inspecting behaviour. The denominator is the point, not a confound: the bigger and more trusted the network, the more attackers it launders, and the more a reputation allowlist rewards them for choosing it.

On over-labelling: we guard against it in three ways stated plainly. We count only IPs with a positive attack intent, discarding the 8,000 with none. We score with effective_bad_rate, so a service returning honest 404s is not flagged. And the exemplars are checkable — 20.104.203.253 is not a mislabelled CDN edge; it is 1,479 requests at a 1.00 hostile rate behind an empty UA. The narrow claim survives its own counter-argument: held to behaviour, not reputation, the trusted clouds are the majority origin of web attacks against this estate.

VI. Read Between the Lines

• Reputation is a lagging, borrowable signal. An ASN earns trust over years; an attacker rents it by the hour. The trust accrues to the address, not the conduct — and the address is for sale.
• The allowlist was built to reduce false positives, and it does. It also silently maximises false negatives on exactly the networks it exempts from inspection. Every allowlist is a blindfold with a brand name on it.
• Country and ASN are the same mistake at different resolution. Both ask where is this from? when the only answer that matters is what is it doing?

VII. The Human Layer

Picture the analyst who wrote the rule. A quarter's worth of pages, half of them false positives from an Azure health-check or a Google uptime probe, until someone finally types allow AS8075, allow AS396982 and the noise stops. It is a reasonable, defensible, deeply human decision — and it is the exact decision the 1,346 attackers in this dossier are counting on. The person who allowlists a cloud to get some sleep is not careless. They are responding rationally to a trust model that was broken before they arrived. This series is not aimed at them. It is aimed at the model.

VIII. Verdict

Held to behaviour rather than reputation, 63% of the web attackers reaching this estate originate on the major hyperscalers and CDNs that defenders allowlist by default — running credential harvest, shell upload and CMS probing, frequently behind browser or empty user-agent costumes. Confidence: HIGH (intent-labelled subset, mask-pierced scoring, checkable exemplars). The trusted clouds are not incidentally present in the attack data; they are the majority of it. Reputation-based allowlisting does not reduce this risk — it selects for it.

IX. Defensive Response

The platform keys on conduct, not origin: effective_bad_rate and probe_intent drive CrowdSec bans regardless of ASN reputation or UA string, propagating to the MikroTik crowdsec-blacklist at L3. An Azure IP at a 1.00 hostile rate is banned exactly like a bulletproof one — which is the whole point.

Crosslinks

• TI-2026-032H — The Double Standard — the principle beneath this series: name the behaviour regardless of the brand.
• TI-2026-065 (The Return) — Tencent as a single, fully-worked instance of the pattern this series generalises.
• → TI-2026-066B — The Browser Costume — how datacenter IPs forge consumer and crawler identities, and how the mask is torn off.
• → TI-2026-066C — Behind the Orange Cloud — attacks arriving through Cloudflare, and the source-IP trust problem.

Sources: LSN web-threats ip_intel — intent-labelled subset (2,137 of 10,114), effective_bad_rate scoring, ASN/UA/geo distributions, checkable exemplars. Method: count only classified attack intents; score mask-pierced; name behaviour, not brand. TLP:WHITE.