The Wardrobe in Motion: Identity-Rotation Subnets
TI-2026-086G ยท Series: The Wardrobe ยท Case 7 ยท Classification: HIGH ยท Confidence: HIGH
Cases B through F undressed one costume at a time from a rack that stood still: on Google Cloud, each mask was worn by its own fleet โ a Fake-Googlebot fleet, a Fake-ia_archiver fleet, one identity per crowd. This case leaves the reputable cloud and finds the wardrobe doing something different. On a cheap host in a small subnet, the costumes are not distributed across many bodies; they are cycled through a few. The rack is moving. And catching a moving rack takes a different eye than catching a still one.
Executive Summary
Two /24 subnets exhibit a spoofing pattern the Google Cloud fleets do not:
- Identity-Rotation
66.187.5.0/24โ ~5 IPs, 68 requests, effective bad-rate 0.868, cycling three stolen crawler masks (baidu-flavoured). - Identity-Rotation
38.43.93.0/24โ ~5 IPs, 11 requests, effective bad-rate 1.0, cycling three masks (amazon-flavoured).
Both belong to Hostodo (AS399804), a US budget VPS provider โ not a hyperscaler. And the defining difference from every prior case is how the wardrobe is worn. The GCP operators field one mask across many IPs: seventy-seven bodies, all called Googlebot. These Hostodo subnets do the inverse โ many masks across a few IPs: a handful of bodies, each changing costume. Node 66.187.5.19 alone ran credential-harvesting, admin-panel hunting, vhost enumeration and eighteen-path probing, under rotating identities. One body, the whole wardrobe.
This mobile pattern is invisible to the detector that caught the GCP fleets, because each individual mask in a rotation appears only once or twice โ far below the "five-plus IPs on one name" threshold. Catching it needed a second detector, identity_rotation, keyed not on the IP or the mask but on the subnet cycling two or more stolen names. Both /24s were auto-banned on 2026-07-13 under that detector, mirrored to the router. The lesson of the case is a methodological one: mask-spoofing has two kinematics, and each needs its own eye.
Two Ways to Wear a Wardrobe
Put the static and mobile patterns side by side, because the contrast is the whole case.
The static fleet (Google Cloud, cases BโF). One costume, many bodies. The operator spins up dozens of GCP instances and dresses them all as Googlebot, or all as ia_archiver. Detection sees โฅ5 IPs sharing one forged name and one behaviour, and clusters them as a spoofed_impostor_cluster. The unit is the fleet.
The mobile subnet (Hostodo, this case). Many costumes, few bodies. The operator has a small block of cheap IPs and cycles each one through several crawler names โ Baiduspider now, something else next, Amazonbot after that. Detection sees a /24 in which two or more stolen names appear, and clusters the subnet as an identity_rotation. The unit is the subnet.
Same wardrobe โ the same catalogue of trusted crawler names, the same behavioural toolkit underneath โ worn with opposite motion. And the choice between them is not stylistic. It is dictated by the host.
Why the Host Chooses the Kinematics
The GCP operators and the Hostodo operators are solving the same problem โ get past the allowlist while running a scanner โ under different constraints, and the constraints explain the two shapes.
A reputable cloud gives the static operator two gifts. First, cheap breadth: you can spin up as many instances as you want, so scaling bodies is easy. Second, and more subtly, the provider's name lends the mask credibility โ a fake Googlebot is most believable when it egresses Google's own network (086A's central irony). With breadth cheap and the host name doing half the disguise's work, the rational move is to buy many bodies and put one convincing mask on each.
A budget host like Hostodo gives neither gift. You get a small handful of IPs in a /24, not an elastic fleet โ so scaling bodies is not cheap. And "Hostodo" lends the mask nothing; no allowlist trusts a crawler because it comes from a discount VPS. So the disguise gets no help from the host, and the operator has few bodies to work with. The rational move inverts: with bodies scarce and reputation absent, scale the disguises per body instead. Rotate masks on each IP to defeat per-name rate limits, to blend three trickles into background noise, and to keep any single forged identity below the threshold that would cluster it. The mobile wardrobe is the budget operator's answer to not being able to afford the fleet.
This is a satisfying structural result: the shape of a spoofing operation is a readout of the economics of its host. Show me whether the masks are spread across bodies or cycled through them, and I can tell you whether the operator is renting a hyperscaler or a discount VPS.
One Body, the Whole Wardrobe: 66.187.5.19
The mobile pattern is clearest in a single node. 66.187.5.19 (Hostodo, AS399804) made forty-six requests, and its CrowdSec history reads like a one-person crime spree rather than a specialised bot:
web-threats/autoban: credential_harvest:25, admin_hunt:2, vhost_enum:1
watchdog-http-probing (18 paths)
crowdsecurity/http-probing
Compare that to a GCP fleet member, which typically does one thing โ a .env sweep, or vhost enumeration, single-purpose, under a single name. 66.187.5.19 does everything: it harvests credentials, hunts admin panels, enumerates vhosts, and probes eighteen distinct paths, and it does so while rotating the crawler identity it presents. This is the signature of the mobile model. When bodies are scarce, each body is a generalist that works the whole target and changes its name as it goes, rather than a specialist that does one job under one mask.
That generalism is also why the per-mask counts are so low. Spread forty-six requests across three rotating identities and several behaviours, and no single (name) pairing accumulates enough volume to look like a fleet. The operator is not being quiet by accident; the rotation is the quiet.
Why the Static Detector Goes Blind โ and the Second Detector Sees
Here is the methodological heart of the case. Run these two subnets past the detector that caught the Google Cloud fleets โ spoofed_impostor_cluster, defined as five or more IPs all wearing one crawler name whose provenance failed โ and it finds nothing. Each stolen name in a rotation appears once or twice; there is no crowd of five IPs sharing a single mask. The static detector looks for a costume worn by many and sees, instead, three costumes worn by a few, and clusters none of them. The mobile wardrobe hides in exactly the low-per-mask counts the fleet detector is built to ignore.
The identity_rotation detector inverts the question. It does not ask "how many IPs wear this one name?" It asks "how many stolen names does this one subnet wear?" A /24 cycling two or more forged crawler identities is the signal, regardless of how few requests each identity carries. Point that eye at 66.187.5.0/24 and the three baidu-flavoured masks light up as one coordinated rotation; at 38.43.93.0/24, three amazon-flavoured masks do the same.
The takeaway generalises the series' method. In 086A the lesson was "the fleet, not the IP, is the unit." Here it becomes: the coordination structure is the unit, and it is not always the fleet โ for the mobile case it is the subnet. A defender who only ever clusters by "shared mask" has a blind spot precisely where the shared thing is the address block and the masks are what move. Two kinematics, two units, two detectors โ and the enforcement loop handles both.
The Rotation Hedges Its Bets
One detail rewards a closer look, because it ties this case back to the verifiability frontier of 086E and 086F. The 66.187.5.0/24 subnet cycles Baiduspider-flavoured masks; the 38.43.93.0/24 subnet cycles Amazonbot-flavoured ones. Those two names sit on opposite sides of the verifiability line:
- Baiduspider is verifiable โ Baidu publishes crawler ASNs, so a Baiduspider on Hostodo is convictable by the ASN check (086D).
- Amazonbot is claimed-only in the practical sense โ the taxonomy can only verify it by a reverse-DNS suffix (
crawl.amazonbot.amazon), and a budget-VPS IP with no such rDNS record simply fails to confirm rather than being cleanly contradicted.
Cycling a convictable name alongside a hard-to-convict one is a hedge. Some of the operator's disguises will fail the ASN check and get caught; others lean on a name whose verification is weaker, buying a little more life. It is the opacity-gravitation of 086E and 086F โ the pull toward names that publish nothing โ operating not across a population of operators but within a single rotating body. The same argument applies, and lands harder for being so concrete: every operator that leaves its crawler's provenance weakly specified hands the rotator a mask worth keeping in the cycle.
Steelmanning: "A few IPs on a cheap host โ is this worth a case?"
The honest objection is scale again, sharper here: eleven requests on one subnet, sixty-eight on the other. Why does this rate a dossier next to a 77-IP fleet?
Because the case is not about these two subnets' volume; it is about a kinematic class and a detection gap. Three points hold it up:
- It documents a second attack shape. If the series only ever described the static fleet, a defender would build one detector and believe the problem solved โ while the mobile subnet walked through the blind spot. Naming the mobile kinematics is the deliverable, and two live examples suffice to establish it exists and is caught.
- Low volume is the design, not a weakness. As with the social unfurlers (086F), the small footprint is the point of the mobile model: rotation exists precisely to keep every forged identity below the fleet threshold. Judging it by request count is judging it by the metric it was built to minimise.
- The host economics are a general readout. The finding that operation shape reveals host class is reusable well beyond these two subnets โ it is a lens for reading any spoofing cluster.
The objection correctly notes these are small; it does not touch the claim, which is about kinematics and coverage, not counts.
What Holds, and What Is Bounded
Documented, HIGH confidence: both subnets' Hostodo (AS399804) membership; the identity_rotation detection (โฅ2 stolen names per /24) versus spoofed_impostor_cluster; the one-body-many-jobs behaviour of 66.187.5.19; the fleet-keyed enforcement of both /24s on 2026-07-13; the static detector's structural blindness to the mobile pattern.
Inferred, MEDIUM confidence: the host-economics explanation for the two kinematics (reputable-cloud โ scale bodies; budget-host โ scale masks). The correlation is clean in the data โ the static fleets are on GCP, the rotations on Hostodo โ but two rotation subnets is a small sample for a causal claim, and the reasoning (few IPs + no borrowable reputation โ rotate) is an inference about operator incentives, not an observed decision. Held as the leading explanation, revisited when more rotation subnets accumulate.
Why It Matters
The wardrobe in motion completes the picture of how the costumes are worn, after six cases on which costumes and why. It shows that spoofing is not a single behaviour to be caught by a single rule but a family of at least two โ the fleet and the rotation โ whose shapes are set by the economics of the infrastructure underneath. And it drives home the series' deepest methodological claim: the object of detection is never the mask and never even, always, the IP or the fleet โ it is whatever structure the operator uses to coordinate, which on a hyperscaler is a fleet and on a budget host is a subnet. Find the coordination unit, judge it by behaviour and provenance, and the mask โ still, moving, or mid-change โ is just the label you write on the ban.
The defensive corollary is that coverage means owning both eyes. A pipeline with only the fleet detector is not wrong, merely incomplete, and incomplete in a way an adversary can read off and exploit: rent a cheap /24, rotate three masks, stay under the fleet threshold, and walk. The answer is not a bigger allowlist or a stricter fleet rule; it is the second detector that asks the inverse question โ not how many wear this name, but how many names does this block wear โ and treats the moving rack as the single thing it is.
Cross-references
- TI-2026-086A โ The Wardrobe Rack โ the static fleet whose kinematics this case inverts; "the fleet is the unit" becomes "the subnet is the unit."
- TI-2026-086D โ The Eastern Crawlers โ Baiduspider verifiability, one of the rotated masks here.
- TI-2026-086E / 086F โ The Newest Trust / The Social Unfurlers โ the claimed-only opacity-pull, here operating inside a single rotating body via the Amazonbot mask.
- TI-2026-066B โ The Browser Costume โ the budget-host impostor class (Hostodo among them) this case's operators belong to.
Next in the series โ TI-2026-086H, The Landlords: the per-cloud geography of the wardrobe โ why the masks cluster on Google Cloud, AWS, DigitalOcean and Cloudflare, and what each landlord's tenancy contributes.
TLP:WHITE. Attacker infrastructure only; Baidu and Amazon are named as impersonation victims. No internal addresses, credentials, or PII disclosed. One explanatory claim explicitly held as inference.