The Wardrobe Rack: Seven Crawler Masks in One Cloud Tenant

TI-2026-086A · Series: The Wardrobe · Case 1 · Classification: HIGH · Confidence: HIGH

The anchor case of a new series. Where The Unmasking (TI-2026-085) built the method for judging a single visitor's claimed identity — VERIFIED, CLAIMED, SPOOFED, UNVERIFIABLE — this series starts from what that method found once it was pointed at the whole edge at once: not one impostor, but a rack of them, hanging in a single cloud tenant's closet, worn in rotation. This case establishes the finding, the method, and why it matters now. Every case that follows pulls one costume off the rack and turns out its pockets.

Executive Summary

Between 2026-06-08 and 2026-07-13, our public web edge recorded a single autonomous system — AS396982, Google LLC / Google Cloud Platform — carrying nineteen distinct named crawler identities. Seven of them are not merely suspicious. They are proven impostors: coordinated fleets of five or more IP addresses, each fleet impersonating one trusted crawler, each failing the provenance check that the real crawler would pass.

The roster, as the pipeline clusters it:

This is the finding: the trusted-name identity space is being consumed as a fungible resource out of one address block. A defender who allowlisted crawler traffic by User-Agent name — which is to say, nearly every WAF and bot-management product on the market — would, inside this one window, have waved through seven separate attack fleets, each wearing a name that appears on somebody's do-not-block list.

The second half of the finding is newer, and it is the reason this series exists now rather than a month ago. On 2026-07-13 at 06:45 UTC, our web-threats/autoban job did not ban these IPs one at a time as anonymous scanners. It banned them by fleet, under the fleet's own name. The CrowdSec decision scenario reads, verbatim:

web-threats/autoban (spoofed fleet): Fake-Googlebot Fleet AS396982 (77 IPs)

The unit of detection is no longer the IP. It is the costume. The mask stopped being a shield and became a handle — the very thing that lets us grab all 77 of them at once.

Why This Is Not TI-2026-085 Again

Forensic honesty first, because this ASN is one of the most-written-about objects in our corpus. AS396982 is referenced in 34 published dossiers. Before claiming novelty, we have to say precisely what is new, because a reader who has followed the work will recognise the raw materials.

• TI-2026-085B, The Impostor Economy — took a single fake Googlebot on GCP (35.247.135.112) and used it to fix the verdict method: SPOOFED means checked-and-contradicted, categorically different from CLAIMED (no-check-possible). That case was about one visitor and one rule.
• TI-2026-066B, The Browser Costume — censused impostor crawlers across small budget hosts (INFRALY AS400529, NextGenWebs AS41608, BreezeHost, ColoCrossing). It found 57 of 333 "crawlers" were lying. That case was about many small hosts, one impostor each.
• TI-2026-046A, The .env Harvesters — GCP credential scanning that used Googlebot and ChatGPT-User strings. That case was about one intent (.env theft) across mixed identities.
• TI-2026-059D, Scanners in the Mirror — a single IP trying on Baiduspider and Applebot and GoogleOther and YandexBot in sequence. That case was about one IP wearing the whole wardrobe.

086A is none of these. It is the fleet-level concentration finding: seven simultaneous, independently-clustered impostor fleets sharing one cloud tenant space, plus the operational fact that each is now detected as its own spoofed_impostor_cluster campaign and enforced against as a named unit. 066B found the wardrobe scattered across a slum of cheap hosts; 086A finds it hanging on one rack in the most reputable building on the internet. 059D found one actor flipping through masks; 086A finds a whole population doing it, industrialised, and shows the countermeasure that finally treats the population as the object. The prior cases are the raw thread. This is the garment.

The Rack: One ASN, Nineteen Names

Start with the host, because everything about this case turns on where the rack is standing.

AS396982 is Google Cloud Platform. Registered through ARIN, allocated 2018-08-15, PeeringDB organisation google-cloud, policy Selective, roughly 15,000 announced IPv4 prefixes. Our own risk scoring puts it at 19.8 / 100. It is not flagged bulletproof. It is not Spamhaus-listed. By every institutional measure this is a clean, legitimate hyperscaler — the opposite of the NOVACONN, Hostigger, and CDS Global Cloud networks that top our dangerous-ASN list at risk 100.

That cleanliness is not incidental to the abuse. It is the point of the abuse. A fake Googlebot is at its most believable when it egresses from Google's own network. The entity graph makes the irony exact: AS396982 shares a PeeringDB organisation with AS15169 (GOOGLE), AS19527 (GOOGLE-2), and AS43515 (YOUTUBE) — sibling ASNs under one corporate roof. The real Googlebot lives on AS15169. The fake Googlebot lives one ASN over, on AS396982, under the same organisation banner. To a defender doing the naive check — "is this IP announced by something called Google?" — the impostor and the genuine article are indistinguishable. The mask is credible precisely because the wardrobe closet is inside the house whose livery it forges.

Across the observation window, the web-threats ASN dossier for AS396982 records:

• effective bad-rate: 0.469 — nearly half of all classified traffic from this ASN to our edge is hostile.
• avg 404 rate: 0.221, 531 of 2,147 IPs "aggressive."
• top intents: auth_probe, cms_detect, credential_harvest, scanner_fingerprint, vhost_enum.

Nineteen agent identities appear in that stream. Twelve are the honest noise of a hyperscaler — unnamed browsers, python-requests, Wget, HeadlessChrome, libwww-perl, Discordbot — tools and scripts making no notable claim, correctly filed UNVERIFIABLE. The other seven make a claim worth checking, and every one of those checks comes back the same way: the provenance fails. That is the rack.

Costume One, Examined: How the Mask Actually Behaves

Pull one member off the Fake-Googlebot fleet and watch it work. IP 34.87.136.84, geolocated Singapore, AbuseIPDB 24, announced by AS396982.

In its short life on our edge it made six GET requests. Every one is instructive:

• It hit exactly one path: /components/com_sppagebuilder/assets/css/sppagebuilder.css — the asset tree of Joomla's SP Page Builder, a component with a documented history of arbitrary-file and RCE issues. This is not a crawler indexing content. It is a scanner fingerprinting a CMS.
• Two of its six requests targeted nonexistent virtual hosts — vhost_enum, guessing hostnames that were never published, hoping to find a forgotten staging site behind the same IP. It touched lsn-ai-k3s, lsn-ai, lsn-amp, lsn-grafs, lsn-images, and web-offline under shuffle-on.com.
• Its agent identity is filed google / Googlebot [search/indexing] — SPOOFED.

And here is the detail that names the whole series. Across those six requests, the User-Agent field did not stay Googlebot. It rotated through four different strings:

Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
Mozilla/5.0 (Linux; Android 12) Chrome/111.0 Mobile
Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/1..
Mozilla/5.0 (X11; Linux x86_64) Firefox/117.0

One IP. Six requests. Four identities. The fleet is "Fake-Googlebot" because Googlebot is its dominant mask — but every node on the rack carries the whole rack, and flips through it mid-session, testing which costume gets past the door. This is why per-request User-Agent logging cannot cluster these actors: if you file by the name in the header, this single IP fragments into four "different" visitors, three of which look like ordinary human browsers. The only stable identity is the fleet — the ASN, plus the provenance failure, plus the behaviour — and the behaviour is the same no matter which mask is up: probe a CMS, enumerate vhosts, harvest what answers. You cannot spoof your way out of what you did.

34.87.136.84 is now banned on both CrowdSec and the MikroTik crowdsec-blacklist, under the fleet scenario, since 06:45 UTC on 2026-07-13.

The Costume Fits the Crime

Look back at the intent column of the roster and a structure appears that is not random. The high-volume, high-bad-rate fleets — Baiduspider (ebr 1.000), YandexBot (1.000), Twitterbot (1.000), ia_archiver (0.958), Googlebot (0.905) — all carry the credential_harvest intent. The low-volume fleets — SemrushBot (5 requests, ebr 0.000) — carry scanner_fingerprint.

That split is the operator telling us what each mask is for.

• A search-engine or archive identity (Googlebot, Baiduspider, YandexBot, ia_archiver) is expected to crawl deeply and repeatedly. It is the perfect cover for high-volume credential-harvesting against login endpoints, because "why is Googlebot hitting /wp-login.php two thousand times" is a question most WAFs are configured not to ask. Volume is camouflaged as thoroughness.
• An SEO-audit identity (SemrushBot) is expected to make a handful of structural requests and leave. It is the perfect cover for quiet fingerprinting — five requests, learn the stack, move on — because volume would break the disguise.

The mask is chosen to match the tempo the crime requires. This is the seed of a later case (086I), but it belongs here as proof that the rack is curated, not thrown together: each costume is selected for the job it will do while wearing it.

The Same Hand on Two Vectors

The wardrobe is a web-layer phenomenon, but the operators behind it are not confined to the web layer. Our honeypot — the SSH observation point — reaches into the same address space and finds the same population.

Node 35.188.112.111 sits in AS396982. On the web side it is unremarkable. On the SSH side it is tagged actor_cluster_001, with 46 honeypot hits, AbuseIPDB 100, and a GreyNoise malicious classification. When we pivot it through the 223,000-edge entity graph, it does not stand alone. It shares an SSH credential — hadoop:123123 — with a five-node cluster whose other members are in Hong Kong (42.200.78.166) and the United Arab Emirates (83.111.76.195), plus 103.146.23.195 and 81.30.212.94. Seventeen further IPs correlate with it temporally, attacking within the same ten-minute windows at lift values up to 305.

So the GCP address space that hangs the crawler-mask wardrobe is the same address space from which multi-vector operators brute-force SSH using shared wordlists that reach across three continents. The fake Googlebot at the front door and the hadoop:123123 guesser at the side door are drawn from one pool. This case only marks the overlap; case 086J turns it out in full. But it forecloses a comfortable reading — that the wardrobe is a self-contained, low-stakes web nuisance. It is one face of actors who are also doing the loud, old-fashioned work of credential brute-forcing, from the same cloud, at the same time.

The Loop Closes: Detection by Costume

Everything above could have been written, in weaker form, a month ago. What could not have been written is the enforcement.

The web-threats pipeline now runs an identity-aware campaign detector. It defines a spoofed_impostor_cluster as five or more IPs all impersonating one crawler whose provenance check failed. When that pattern trips, the cluster becomes a first-class campaign object with its own identity profile — spoofed: 77 (google/search/indexing) — and the web-threats/autoban job acts on the campaign, not the member.

The consequence is visible in the CrowdSec decision log for 2026-07-13:

34.87.136.84   → ban: "Fake-Googlebot Fleet AS396982 (77 IPs)"
34.88.60.114   → ban: "Fake-Googlebot Fleet AS396982 (77 IPs)"
35.240.197.184 → ban: "Fake-Googlebot Fleet AS396982 (77 IPs)"
34.95.201.0    → ban: "Fake-ia_archiver Fleet AS396982 (22 IPs)"
34.77.83.98    → ban: "Fake-ia_archiver Fleet AS396982 (22 IPs)"
136.107.160.133→ ban: "Fake-Baiduspider Fleet AS396982 (10 IPs)"

Every one of these bans is mirrored to the MikroTik router's crowdsec-blacklist, so the block lands at both L7 (CrowdSec, at the reverse proxy) and L3 (MikroTik, at the router). The costume that was supposed to grant passage is now the exact string that triggers the ban. The Impostor Economy argued, philosophically, that a spoofed identity is "the mask that convicts the wearer." 086A is that sentence turned into a cron job.

This matters beyond satisfaction. Fleet-level enforcement changes the economics for the operator. Banning IPs one at a time is a war of attrition the attacker wins with a large enough address pool — and a cloud tenant has an effectively unlimited pool. Banning by fleet identity means the moment the seventy-eighth Fake-Googlebot IP raises its mask, it is classified into an already-condemned cluster and blocked on arrival. The mask that made the fleet efficient is what makes the whole fleet catchable. This is the central lever of the series, and case 086K takes it apart in detail.

Steelmanning the Counter-Narrative

The strongest objection to this dossier is a real one, and it has to be answered rather than waved away: "Some of those are real crawlers, and you are banning Google."

It is true that Google, Baidu, Yandex, Semrush, and Twitter do operate real crawlers, and it is true that verifying a crawler by ASN alone is a trap — a trap we have documented ourselves (the shared-hyperscaler false-verify hazard, developed in 086L). If the method here were "block anything on AS396982 claiming to be Googlebot," it would be wrong, because the genuine Googlebot's own infrastructure and GCP-hosted legitimate tools would be caught in it.

That is not the method. Three things separate this from a false positive:

1. The provenance check is positive-and-failed, not absent. Google publishes the CIDR ranges its crawler egresses from. The real Googlebot lives on AS15169 within those ranges. Every IP in the Fake-Googlebot fleet is a GCP tenant address on AS396982, provably outside the published Googlebot ranges. This is not "we couldn't verify it" (CLAIMED). It is "we checked, and Google says this is not us" (SPOOFED). The distinction is the entire spine of the 085 method.
2. The behaviour is disqualifying on its own. Real Googlebot does not enumerate nonexistent virtual hosts, fetch Joomla exploit-component asset trees, rotate through four browser User-Agents in six requests, or carry a 0.905 effective bad-rate. Strip the name off entirely and the conduct classifies as a scanner.
3. The fleet geometry is not how real crawlers deploy. Genuine crawler fleets are stable IP ranges that forward-and-reverse-confirm. A spoofed_impostor_cluster is five-plus tenant IPs, spun up and torn down, sharing one forged name and one behavioural signature. The shape itself is the tell.

The objection fails not because we ignore it but because the method was built to survive it. When a genuine crawler does appear on this ASN — and OAI-SearchBot on Azure in 085C is the canonical example of a real crawler on a stranger's cloud — the same machinery files it VERIFIED, because verification is about forward-confirmed provenance, not about which building the visitor is standing in. Identity is not where you are. It is what you can prove.

What Holds, and What Is Bounded

Documented, HIGH confidence: the seven-fleet composition on AS396982; the per-fleet sizes, request volumes, bad-rates and intents; the four-mask rotation on 34.87.136.84; the fleet-keyed CrowdSec/MikroTik enforcement of 2026-07-13; the clean institutional anchor of the host ASN. These are direct observations from our own edge and enforcement logs, corroborated across the web-threats DB, the honeypot DB, and the entity graph.

Inferred, MEDIUM confidence: that the seven fleets are operated by a small number of coordinated actors rather than seven unrelated ones. The concentration in one ASN, the shared behavioural grammar (vhost_enum + CMS fingerprint + credential harvest), and the cross-vector overlap with actor_cluster_001 all point that way — but shared cloud tenancy is weak attribution on its own, exactly because millions of innocent tenants share it too. Whether the rack belongs to one operator, a service that rents masks, or a loose crowd converging on the same tactic is the open question that cases 086M (the operators) and 086J (the cross-vector hand) exist to resolve. We state the seam rather than paper over it.

Why It Matters

Three observation points — the honeypot at the SSH layer, the web edge at L7, and the router at L3 — now agree on a single sentence: on the modern internet, the name a visitor gives you is inventory, not identity. It is drawn from a finite catalogue of trusted brands, staged in bulk out of reputable cloud tenancy, worn in rotation, and matched to the tempo of the crime it fronts. The reputational value that Google, the Internet Archive, Baidu, Yandex, and Twitter spent decades building is being spent — a fraction of a cent at a time — by operators who pay only for a GCP instance and a wordlist.

What defends against it is not a longer allowlist. It is refusing to treat the name as the unit at all. The fleet is the unit. The behaviour is the unit. The provenance check — run, and allowed to fail — is the unit. When those become the objects of detection, the mask inverts: the costume that bought passage becomes the handle that condemns the wearer, and it condemns all seventy-seven of him at once.

That inversion is the thesis of The Wardrobe. This case hangs the rack in the light. The rest take the costumes down one at a time.

Cross-references

• TI-2026-085B — The Impostor Economy — the single-IP verdict method (SPOOFED = checked-and-contradicted) that this case scales to fleets.
• TI-2026-085C — Verified, and Still Where It Shouldn't Be — the mirror case (a real crawler on a stranger's cloud) that proves the method is not "ban the ASN."
• TI-2026-066B — The Browser Costume — the impostor-crawler census on budget hosts; 086A is its hyperscaler-concentration counterpart.
• TI-2026-046A — The .env Harvesters — GCP credential scanning under crawler names, by intent.
• TI-2026-059D — Scanners in the Mirror — one IP wearing the whole wardrobe; 086A is that pattern at fleet scale.

Next in the series — TI-2026-086B, The Flagship Mask: the 77-IP Fake-Googlebot fleet, turned out node by node.

TLP:WHITE. Attacker infrastructure only; no internal addresses, credentials, or PII disclosed. Confidence calibrated per claim above.