The Landlords: The Per-Cloud Geography of the Wardrobe

TI-2026-086H · Series: The Wardrobe · Case 8 · Classification: HIGH · Confidence: HIGH

Seven cases described the costumes and the two ways they are worn. This one steps back to ask a question the costume cases kept brushing past: why are the masks hosted where they are? The wardrobe is not scattered randomly across the internet. It clusters — heavily on Google Cloud, with satellites on AWS, Cloudflare, DigitalOcean, and a fringe of budget hosts. That map is not an accident of pricing. Each landlord contributes a specific property to the disguise, and the set of landlords an operation uses is a readout of what kind of operation it is.

Executive Summary

Read off the router's ban list and the geography is immediate. The top autonomous systems by MikroTik ban count are, almost entirely, mainstream clouds:

Not a bulletproof host in sight. And that absence is the finding, because it is the exact opposite of what the other observation point sees. On the honeypot's SSH side, the most dangerous autonomous systems are dedicated bulletproof operations — NOVACONN, Grand Tel, CMTECH, CDS Global Cloud, Hostigger, CYBERCON, Digit One — all scored 99–100 and flagged bulletproof. Two observation points, two completely different top-ASN lists. The crawler-mask wardrobe lives among the reputable; the loud SSH brute-force lives among the bulletproof. The landlord you rent is a statement of what you are selling.

Two Real-Estate Markets

The cleanest way to see the geography is to notice that these are not two ends of one spectrum but two separate markets, serving two incompatible needs.

The loud-attack economy — SSH credential floods, botnet C2, malware hosting — needs one thing above all: takedown resistance. When you are running hadoop:123123 against ten thousand hosts, your infrastructure will be reported, and you need a host that ignores the abuse complaints. That is what a bulletproof provider sells, and it is why the honeypot's danger list is full of them. Reputation is irrelevant to a brute-force flood; nobody allowlists your SSH scanner because of where it comes from.

The mask economy — the wardrobe — needs the exact opposite: a clean, trusted name. The entire value of a forged Googlebot is that it egresses somewhere a defender trusts. A bulletproof host would destroy the disguise: a "Googlebot" arriving from NOVACONN or Hostigger is instantly suspect, because no real crawler lives there and the host's own reputation screams scanner. The mask only works from a landlord whose name lends it credibility — which means a reputable cloud. So the mask economy cannot use the bulletproof market at all; it is structurally pushed onto Google, Amazon, Cloudflare, DigitalOcean.

This is why the two ban lists barely overlap. It is not that mask operators happen to prefer nicer hosts; it is that the mask and the bulletproof host are mutually exclusive — the property one sells (anonymity through non-cooperation) is useless to the disguise, and the property the disguise needs (borrowed reputation) is exactly what a bulletproof host lacks. Read a cluster's landlord and you have read its business model.

What Each Landlord Contributes

Within the reputable market, the landlords are not interchangeable either. Each adds a different property to the mask, and the wardrobe is distributed across them accordingly.

Google Cloud (AS396982) — credibility. This is the reputation landlord, and it hosts the series' whole static concentration: the 77-IP Fake-Googlebot fleet and its six neighbours (086A–F). Its gift to the disguise is believability by adjacency. The real Googlebot egresses Google's AS15169; the fake one egresses Google's AS396982, a sibling ASN under the same PeeringDB organisation. To a defender doing the naive check — "is this Google?" — the impostor and the genuine article share a corporate banner. No other landlord makes a forged Googlebot this convincing, which is why the biggest fleets are here.

Cloudflare (AS13335) — egress-laundering. Cloudflare is the odd landlord, because it is not a VM host at all. It is a CDN and edge network, and the spoofers observed on it (Fake-ChatGPT-User 104.23.245.63 and 172.71.126.234, Fake-Googlebot 172.71.30.41) are not tenants running instances — they are traffic egressing through WARP (Cloudflare's VPN) or Workers (its serverless edge). The consequence is severe for attribution: the source IP of the forged crawler is genuinely Cloudflare's, not the operator's. So on Cloudflare the operator borrows two things at once — the crawler's identity and a trusted CDN's address. The mask hides who they claim to be; the egress hides where they actually are. Attribution stops at the proxy.

AWS (AS16509) — ambiguity. Amazon's contribution is verification friction. AWS is a vast shared space, and its address blocks carry noisy attribution: 086E's 216.73.216.0/22 is RIR-registered to Amazon yet ISP-tagged "Anthropic, PBC," so a naive verifier could be fooled in either direction. The AWS landlord does not make the mask more credible so much as it makes the check harder — the false-verify and false-spoof hazards both live in shared hyperscaler space. It is where the Fake-ClaudeBot cluster and the vhost sweeps (Vhost Sweep AS16509, sibling AS14618) sit.

DigitalOcean (AS14061) and the budget fringe (Hostodo AS399804, ColoCrossing AS36352) — disposability and rotation. DigitalOcean sells cheap, quickly-spun disposable VMs. The budget hosts sell cheap IPs with no borrowable reputation — which is exactly why, as 086G showed, operators there abandon the static fleet for mask rotation: with no clean name to lean on, they compensate by cycling disguises. The budget landlord's contribution is not credibility but volume-of-identity-per-dollar.

Put together, the landlords form a menu of disguise properties: rent Google for credibility, Cloudflare to disappear, AWS to muddy the check, DigitalOcean to be disposable, Hostodo to rotate cheaply. An operation's landlord set is a specification of the disguise it wants.

The Accountability Gap Is Load-Bearing Here

Why do the reputable clouds allow this? The prior corpus established the general answer — hyperscalers can monitor tenant egress but do not police it (TI-2026-032G The Google Cloud Anomaly, 041D Cloud Complicity, 046E Cloud Mercenaries). This case adds the identity-layer reason the gap matters so much for the wardrobe specifically.

For most abuse, the reputable cloud is a convenience — cheap, reliable, elastic. For the mask economy it is the product itself. The operator is not merely hosting on Google Cloud; they are spending Google's reputation. The clean name that makes a forged Googlebot credible is manufactured by Google's own good conduct everywhere else, and it is being drawn down, a fraction of a cent per request, by tenants presenting Google's own crawler's name from Google's own sibling network. The provider is both the victim (its reputation is the thing being stolen) and the unwitting enabler (its non-policing is what makes the theft possible).

That framing points at a defence the provider alone can deploy: a hyperscaler that flagged its own tenants presenting major-crawler User-Agents — a GCP VM claiming to be Googlebot is a near-certain impostor, since the real Googlebot is not a GCP tenant — would drain the credibility the mask economy rents, at the source. It is the one countermeasure in this entire series that lives not with the target but with the landlord, and it is currently unexercised.

A Nuance: Not Every Banned ASN Is an Impostor Host

Forensic honesty requires flagging the one landlord on the list that complicates the clean story: Semrush (AS209366), 25 bans. That is an operator-own ASN — Semrush's real crawler infrastructure. Its presence on the ban list does not mean Semrush is spoofing itself; far more likely, a genuine SemrushBot crawled aggressively enough to trip a rate rule and got banned as behaviour, not as a forgery.

This matters for reading the whole map. A ban is a rate-and-behaviour decision, not a spoofing verdict. An IP lands on the list because it probed too much or hit a bad path, regardless of whether its identity was forged. The mask claim requires the provenance failure (086E's SPOOFED, checked-and-contradicted) — not merely a ban. So the landlord geography is real, but one must not over-read it: reputable-operator ASNs can appear on the ban list as genuine crawlers caught by rate limits, and separating those from true impostor hosts is part of the discipline the classifier exists to enforce.

Steelmanning: "The bans just reflect where the internet's servers are"

The strongest objection: of course the top ASNs are Google, Amazon, Microsoft, Cloudflare — those are simply the biggest clouds, hosting the most of everything, so they would top any traffic list, benign or malicious. Is the geography a finding or just a census of cloud market share?

It is a finding, and the control is the contrast list. If the ban geography merely reflected raw cloud size, the honeypot's SSH danger list would look the same — dominated by the same big clouds. It does not: it is dominated by tiny bulletproof providers most people have never heard of (NOVACONN, Grand Tel, Digit One). The two lists diverge precisely because the two activities select their hosts differently. The mask economy is over-represented on reputable clouds relative to the brute-force economy, and the brute-force economy is over-represented on bulletproof hosts relative to the mask economy. That divergence cannot be explained by market share — market share would push both toward the same big providers. It is explained by the two different things being sold. The geography survives its own strongest objection.

(The one caveat the objection correctly forces: Microsoft topping the web ban list at 326 is mostly the empty-UA Azure botnet from 059, not crawler masks — so Azure's rank reflects a different abuse than the wardrobe. The mask concentration is specifically Google Cloud; the broader reputable-cloud dominance is the frame, not every entry in it.)

What Holds, and What Is Bounded

Documented, HIGH confidence: the ban-list landlord distribution (reputable clouds dominant); the contrast with the honeypot's bulletproof SSH ASNs; the per-landlord disguise properties (GCP credibility, Cloudflare egress-laundering, AWS ambiguity, budget rotation) as observed across cases A–G; the Semrush operator-own nuance.

Inferred, MEDIUM confidence: the causal reading that operators choose landlords for these properties. The correlations are strong and the incentive logic is tight (a mask needs a clean name; a brute-force needs takedown-resistance), but "the operator selected Cloudflare in order to launder egress" is an inference from the pattern, not an observed decision. Held as the leading explanation. The Cloudflare-egress attribution loss is documented in mechanism; its prevalence relative to VM-hosted masks is not quantified here.

Why It Matters

The landlords case turns the wardrobe from a catalogue of costumes into a map of infrastructure with meaning. It shows that where a mask is hosted is not incidental to the disguise — it is part of it. Google Cloud is rented for credibility, Cloudflare for disappearance, AWS for ambiguity, budget hosts for cheap rotation, and the whole reputable market is chosen over the bulletproof one because the mask's currency is a clean name that only a reputable provider can supply.

For defenders that yields two durable readings. First, hosting choice is an intelligence signal: reputable-cloud egress under a crawler mask is the disguise economy; bulletproof-host egress under an SSH flood is the volume economy — the landlord tells you the game before you read the payload. Second, and more provocatively, the most effective countermeasure lives with the landlord, not the target. Every target can only check the masks that reach it; a reputable cloud could deny the mask its credibility at the source by refusing to let its own tenants wear its own crawler's name. Until it does, the wardrobe will keep renting the one thing a target cannot revoke — the good name of the house it operates from.

Cross-references

• TI-2026-086A — The Wardrobe Rack — the Google Cloud concentration this case explains the why of.
• TI-2026-086E — The Newest Trust — the AWS ambiguity landlord (Anthropic-on-AWS) in detail.
• TI-2026-086G — The Wardrobe in Motion — the budget landlords and the rotation their cheapness forces.
• TI-2026-032G / 041D / 046E — The Google Cloud Anomaly / Cloud Complicity / Cloud Mercenaries — the accountability gap that lets the reputation landlord persist.

Next in the series — TI-2026-086I, The Costume Fits the Crime: the intent-to-mask correlation drawn across the whole rack — which disguises cover harvest, which cover recon, and why the mask predicts the payload.

TLP:WHITE. Attacker infrastructure and impersonated brands only; providers named as unwitting hosts, not accused of complicity. No internal addresses, credentials, or PII disclosed. One causal claim explicitly held as inference.