The Flagship Mask: Turning Out the 77-IP Fake-Googlebot Fleet
TI-2026-086B ยท Series: The Wardrobe ยท Case 2 ยท Classification: HIGH ยท Confidence: HIGH
Case 1 hung the rack in the light: seven crawler masks in one Google Cloud tenant space, now detected and banned by fleet. This case takes down the largest costume and turns out its pockets. The Fake-Googlebot fleet is 77 IPs โ the biggest single impostor cluster in our corpus โ and the question it answers is the one that decides whether the whole series holds: are these 77 separate opportunists who each happened to pick the same famous name, or one operation wearing one costume seventy-seven times? The evidence says the latter, and it says so in a way that also proves the costume is cosmetic.
Executive Summary
The Fake-Googlebot Fleet AS396982 (web-threats campaign #148056) is 77 IP addresses, 4,597 requests, an effective bad-rate of 0.905, and a dominant intent of credential_harvest. It is the flagship of The Wardrobe for one reason: Googlebot is the single most universally allowlisted identity on the internet. No operator wants to be the one who accidentally blocked Google's crawler and fell out of the index, so the name Googlebot buys passage past nearly every WAF, bot-manager, and rate-limiter on the market. That is exactly why it is the costume worth forging most.
Turned out node by node, the fleet does not resolve into 77 strangers. It resolves into one behavioural grammar โ enumerate the target's internal service subdomains, fingerprint its CMS, then burst-harvest its .env secrets โ executed from disposable Google Cloud instances, under a Googlebot label that is swapped for other crawler names without changing a single thing about what the nodes do. We can prove that last claim directly: the identical toolkit runs from the same address space under a YandexBot mask, inside the same cross-mask campaigns. The name is paint. The sweep is the machine underneath.
Every member identified here is active-banned under the fleet-keyed CrowdSec/MikroTik scenario as of 2026-07-13 06:45 UTC.
Why Googlebot Is the Flagship
Start with the economics of the disguise, because they explain the fleet's size. A costume's value is the product of two things: how much trust the name carries and how rarely anyone checks it. Googlebot maximises both.
- Trust: Googlebot is on the shortest allowlist every operator keeps. Blocking it has an immediate, visible business cost โ deindexing โ so defenders configure their stacks to never challenge it. A request that says Googlebot is a request most systems have decided in advance not to interrogate.
- Uncheckability, in practice: Google does publish the method to verify Googlebot (reverse-then-forward DNS against
googlebot.com, plus published egress ranges), but almost nobody runs it at request time. The verification is available and neglected โ the perfect gap for an impostor. The name is trusted precisely where it is least tested.
So the flagship costume is not the most exotic one. It is the most boring one โ the name so trusted that checking it feels unnecessary. The fleet is 77 IPs because Googlebot is the identity with the highest passage-value per stolen instance, and the operator scaled to match.
Turning Out Pocket One: Reconnaissance Under the Costume
Member 35.240.197.184 (geolocated Singapore, AS396982) shows the fleet's first job. In twelve requests it did something a real Googlebot never does: it guessed hostnames.
Its target_host_type is nonexistent_guessed. It enumerated nine internal service subdomains that were never published anywhere โ names you would only try if you were mapping a homelab's service topology by convention:
lsn-auth lsn-pgadmin lsn-redis lsn-qdrant
lsn-jupyter lsn-netdata lsn-llm-factory lsn-mail
lsn-docling
That is a target-specific reconnaissance list โ an SSO gateway, a Postgres admin panel, a Redis instance, a vector database, a Jupyter server, a monitoring console, an LLM pipeline, a mailserver. Real Googlebot follows links it finds; it does not sit outside your estate reciting the service names it hopes you run. And under the same twelve requests, 35.240.197.184 also fetched /components/com_sppagebuilder/assets/css/sppagebuilder.css โ the asset tree of Joomla's SP Page Builder, a component with a history of arbitrary-file and RCE flaws. Reconnaissance and CMS-fingerprinting in one short visit, both wearing the crawler's coat.
It belongs to two campaigns at once: Fake-Googlebot Fleet AS396982 (77 IPs) and Vhost Sweep AS396982 (16 IPs). The second is the important one โ a cross-mask sub-campaign of sixteen GCP IPs all running the same subdomain-guessing sweep. The reconnaissance arm of the fleet has its own name in our data because it is a coordinated unit, not a solo scanner. And like every node on this rack, 35.240.197.184 rotated four browser User-Agents (Windows Chrome, Linux Firefox, Android Chrome, Googlebot) across its handful of requests โ the per-member mask-stacking that Case 1 first flagged, here in the reconnaissance role.
Turning Out Pocket Two: The Harvest
Reconnaissance finds the doors. The second job tries the locks. Member 34.125.48.170 shows the harvest โ and it is the single most important node in this dossier, because of the label it wears while doing it.
34.125.48.170 made 151 requests in six seconds โ a cadence of 98,953 paths per hour, which is not a human, not a browser, and not a crawler indexing content. It is a script emptying a wordlist. The wordlist is a .env dictionary:
/.env /.env.backup /.env.backup.txt /.env.bak
/.env.copy /.env.default /.env.demo /.env.dev
/.env.dev.local /.env.development ... (151 distinct variants)
.env files hold application secrets โ database passwords, API keys, mail credentials, signing secrets. A single hit is a credential windfall. The target was lsn-webmail.sonatural.life, the webmail host โ a high-value box to hold the keys to. This is the credential_harvest intent in its purest form: brute the secret-file namespace and grab whatever answers.
Here is the finding. 34.125.48.170 does not wear a Googlebot mask. It wears a YandexBot mask. Its agent identity is filed yandex / YandexBot [search/indexing] โ SPOOFED. And yet it is running the exact same toolkit as the Googlebot-masked nodes, from the same ASN, inside the same cross-mask campaigns: it is a member of Burst 2026-06-08 AS396982 (credential_harvest) and Shared-Exploit Cluster (5 IPs, 10 paths) โ clusters it shares with Googlebot-masked peers.
Strip the two nodes of their names and they are indistinguishable: same address space, same burst cadence, same .env/vhost target grammar, same shared campaigns. Dress them, and one is "Googlebot," the other "YandexBot." The crawler identity is a coat of paint applied over a shared machine. That is not an interpretation; it is what the campaign membership records say. The operator keeps one toolkit and a wardrobe of names, and reaches for whichever name the target's allowlist is most likely to honour.
The Costume Is Cosmetic โ Why That Changes the Defence
This is the load-bearing conclusion of the case, so state it plainly. If the Googlebot mask were the identity of this operation, then detecting and banning "Fake-Googlebot" would end it. It would not. The 34.125.48.170 evidence shows the operator already runs the same sweep under YandexBot, and the 086A rack shows five more masks (Baiduspider, ia_archiver, Twitterbot, SemrushBot, Bingbot) available on the same rail. Ban the Googlebot costume and the next request simply arrives dressed as Yandex.
The only defence that survives an interchangeable costume is one that never looked at the costume in the first place. Three signals do that here, and all three are mask-invariant:
- Cadence. 151 paths in six seconds is a script no matter what name it claims. Real crawlers pace themselves; harvesters do not.
- Target grammar. Guessing unpublished internal subdomains and brute-forcing the
.envnamespace is disqualifying conduct on its own. Googlebot does neither; neither does YandexBot. - Fleet membership. The
Vhost SweepandShared-Exploit Clustercampaigns bind the nodes together by behaviour, across masks. The fleet is a coordinated shape the individual costume cannot hide.
The pipeline detects on these and then labels the result with the dominant mask for human readability โ "Fake-Googlebot Fleet (77 IPs)" โ but the detection never trusted the label. That is the inversion the series is built on: the mask is not what we judge; it is what we hand back to the reader after we have already judged the behaviour.
The Wall It Hit: Authelia Turns the Harvest Into Telemetry
The .env sweep from 34.125.48.170 found nothing, and how it found nothing is worth a paragraph, because it is where the homelab's architecture and its intelligence collection turn out to be the same thing.
All 151 of those .env probes returned 401, not 404 and not 200. They did not reach a filesystem. They hit Authelia, the forward-auth proxy in front of the protected hosts, and were intercepted at the door. On an unprotected server, a .env probe leaks its answer in the status code โ 404 (not here) versus 200 (jackpot). Behind Authelia every probe gets the same 401 regardless of whether the file exists, so the harvest learns nothing from the response. The secret namespace is not just empty to the attacker; it is uniform, which means unreadable.
And the same 401 wall that denies the harvest also sharpens the detection: 151 identical-status requests in six seconds is a spotless fleet signature, trivially clustered. The defence (auth-gating) and the telemetry (uniform 401 burst) reinforce each other โ a property first documented in The Front Door (059) and here operating against the flagship fleet. The attacker paid for 151 requests and bought us one clean fingerprint.
Steelmanning: "Seventy-seven GCP tenants, seventy-seven coincidences"
The honest counter-argument: Google Cloud has millions of tenants; a fake Googlebot on GCP is common; maybe these are 77 unrelated small operators who each independently spun up an instance, grabbed the obvious famous name, and ran an off-the-shelf scanner. Correlation by shared cloud is weak โ we say so ourselves in 086A. So what makes this one operation rather than 77 coincidences?
Three things that coincidence does not produce:
- Shared cross-mask campaigns.
Vhost Sweep AS396982 (16 IPs)andShared-Exploit Cluster (5 IPs, 10 paths)are memberships computed from identical path sets and timing, not from shared hosting. Independent operators running different scanners do not converge on the same ten-path exploit set and the same subdomain wordlist by chance. - A shared, specific target list. The nine guessed subdomains are this estate's private service names. Seventy-seven unrelated actors would guess seventy-seven different generic lists; a single operator working one target reuses one list โ which is what the data shows.
- The cross-mask identity. The clincher against "each grabbed the obvious name" is that they did not all grab the same name. The same toolkit appears under YandexBot too, inside the same clusters. Coincidence explains a shared name; it does not explain a shared toolkit under different names. That requires one hand.
The counter-argument correctly warns against over-reading shared tenancy, and we keep its discipline: our attribution stops at "one operation," not at a named actor โ that is the work of a later case (086M). But "77 coincidences" cannot survive the shared-campaign and cross-mask evidence. This is a fleet.
What Holds, and What Is Bounded
Documented, HIGH confidence: the fleet's size, volume, bad-rate and intent; the vhost_enum reconnaissance sub-mode and its nine guessed subdomains; the 151-path .env burst and its uniform 401 outcome; the cross-mask toolkit sharing (Googlebot and YandexBot nodes in one campaign set); the fleet-keyed enforcement. All are direct observations from the web edge, the auth proxy, and the enforcement logs.
Inferred, MEDIUM confidence: that the Googlebot-masked and YandexBot-masked members are the same operator rather than two operators sharing a rented toolkit. The shared campaigns make same-operator the leading hypothesis, but a "scanner-as-a-service" model โ one toolkit vendor, several customers picking different masks โ would produce a similar signature. Distinguishing them needs the operator-resolution pass (086M). We flag the fork rather than assert past it.
Why It Matters
The flagship mask teaches the defensive lesson of the whole series in one node. 34.125.48.170 is the proof, and it is a proof by contradiction of its own label: a thing that calls itself YandexBot, does exactly what the Fake-Googlebot fleet does, and belongs to the Fake-Googlebot fleet's campaigns. If you believed the label, you saw two different crawlers. If you watched the behaviour, you saw one machine in two coats.
Defenders spend enormous effort on better allowlists โ more crawler names, tighter verification of each. This case says the allowlist is the wrong object entirely, because the operator's costume is cheaper to change than your allowlist is to maintain. The durable move is to stop asking who do you claim to be and start asking what are you doing, how fast, against what, and with whom โ questions no costume can answer falsely. Ask those, and the flagship fleet undresses itself: 77 IPs, one toolkit, one target, a rack of names, and a 401 wall that kept every secret.
Cross-references
- TI-2026-086A โ The Wardrobe Rack โ the seven-mask concentration this fleet flies the flag of.
- TI-2026-046A โ The .env Harvesters โ the GCP
.envscanning economy this fleet continues, now attributed to a specific cluster. - TI-2026-085B โ The Impostor Economy โ the single-IP verdict method scaled here to the 77-IP unit.
- TI-2026-059D โ Scanners in the Mirror / The Front Door โ the Authelia 401-wall mechanics that both deny the harvest and fingerprint the fleet.
Next in the series โ TI-2026-086C, The Archivist's Coat: the 22-IP Fake-ia_archiver fleet, and why impersonating the Internet Archive is a costume 085 never caught.
TLP:WHITE. Attacker infrastructure only; no internal addresses, credentials, or PII disclosed. Confidence calibrated per claim above.