The Cloud Contractor: A Pentest Arsenal on Google's Network

TI-2026-075B · Series: The Armory (Part B) · TLP:WHITE · 2026-07-10

Assessment (HIGH confidence). The single most dangerous scanner network hitting the honeypot is not a bulletproof host in a permissive jurisdiction. It is Google Cloud. AS396982 carries a CRITICAL threat classification — fifty honeypot IPs averaging a threat score of 77 out of 100, with a maximum of 100 — and yet the platform's own bulletproof assessment for it reads false, because it is Google LLC, arguably the most identity-verified, most abuse-responsive network operator alive. Both facts are true, and the gap between them is the whole story. The Armory's opening claim was that the attacker's tools are the defender's tools. Here is where those tools run from — and it is the most reputable address on the internet.

1. Two numbers that should not coexist

Threat intelligence is trained on a comfortable correlation: dangerous traffic comes from dangerous networks. Bulletproof hosts in jurisdictions that ignore abuse reports, offshore shells holding provider-independent address space, ASNs that Spamhaus has given up on. You learn to read a high threat score and a bulletproof flag as two halves of the same sentence.

AS396982 refuses to cooperate with that reading. The honeypot's enrichment gives it:

• Threat classification: CRITICAL. Fifty observed IPs, average threat 77.4, maximum 100.0.
• Bulletproof: false. Local risk score ~20. RDAP org: Google LLC. ARIN-registered, PeeringDB-listed, with a published, functioning abuse process.

A CRITICAL rating on a network that is the opposite of bulletproof. The instinct is to call one of the numbers wrong. Neither is. The danger is entirely real — this network delivers top-tier offensive tooling to the honeypot every week — but it flows from Google's tenants, not Google's policies. Accountability of the operator does nothing to constrain the anonymity of the renter. The most accountable network on earth is also a leading source of attack traffic, and there is no contradiction in that sentence once you stop conflating the landlord with the guest.

2. The loadout

To see why the score is CRITICAL, look at what runs from these addresses. In the previous letter we built a census of offensive tooling by HASSH fingerprint across the whole honeypot. Filter that census to a single ASN — 396982 — and the concentration is startling. The named cracker-and-enumerator tools do not merely appear here; they live here:

This is the entire brute-force-and-scan arsenal, concentrated on one hyperscaler. It is a different shape from the botnets of Letter A. There, a single tool build (libssh_0.11.x) was smeared across 1,313 IPs in 84 countries — dispersion across dirty infrastructure, the fleet hiding in geography. Here it is the inverse: consolidation on clean infrastructure, the fleet hiding in reputability. Same weapons; opposite strategy. And the reputable-address version is the one defenders are most reluctant to touch, which is precisely the point of choosing it.

3. What the cloud actually sells the attacker

The reflexive assumption is that criminals want bulletproof hosting. Sometimes. But bulletproof hosting sells a very specific product — persistence against takedown, the promise that your abuse reports will be filed in the void. That product is expensive, slow to provision, and reputationally radioactive (every serious blocklist knows the bulletproof ranges).

A hyperscaler sells the exact opposite product, and for a large class of attacks the opposite product is better:

• A fresh IP with clean reputation, provisioned in seconds from a pool of millions, so no blocklist has ever heard of it.
• Disposability. Billed by the minute. Spin it up, point Hydra at a /16, tear it down. The instance's job is to finish, not to survive.
• Unblockability by association. Defenders hesitate to null-route Google's ranges because real, wanted traffic lives there too. The attacker inherits that hesitation as free cover.
• Cost near zero. Free trials, promotional credits, stolen cards, and hijacked billing accounts drop the marginal cost of a fresh scanning identity to approximately nothing.

Read the top nodes through that lens and they snap into focus. 34.14.110.148 — threat 100, RDAP org Google LLC, a single honeypot appearance on 2026-06-27, then gone. 35.205.166.70 — threat 100, three hits, one successful login, then gone. These are not persistent adversary infrastructure you can profile over months. They are matches: struck once, burned, discarded. For a task that lasts an hour, the attacker never needs to outlast the abuse process. They need only to finish before it arrives — and against a hyperscaler's provisioning speed and a defender's reluctance to block the brand, they always do.

4. The attribution ceiling

On a bulletproof network, the operator frequently is the abuser, or is one handshake away — so RDAP, corporate filings, and shared contacts lead somewhere. The forensic thread has an end you can pull. That is why so much of this program's work anchors in registry records: on those networks, the paperwork is the perpetrator.

On a hyperscaler, the thread ends at the provider. RDAP resolves every one of these IPs to the same three words — Google LLC — and stops. The actual operator is a billing account behind the shared-responsibility model, invisible to any external observer. This is a structural attribution ceiling, and it is worth naming plainly because it inverts the usual dynamic: a bulletproof host grants anonymity through non-cooperation; a hyperscaler grants it through scale and abstraction. The mechanism is opposite; the outcome for an outside analyst is identical. The network is named. The actor is not. You can say "a Google Cloud tenant ran Hydra against us" and you cannot, from the outside, say one word more.

There is a real difference under the surface, and it matters for defenders: the hyperscaler's abuse channel actually works — Google will act on a well-formed report, which a bulletproof host will not. But it works on the provider's timescale, measured in hours to days, while the offending instance's lifespan is measured in minutes. By the time cooperation is possible, there is nothing left to cooperate about. The ceiling is not that no one will help; it is that help arrives after the match has already burned out.

5. Steelman: some of this traffic is legitimate

Honesty requires the counter-narrative, stated at full strength, because it is genuinely strong.

Not every Nmap sweep from Google Cloud is criminal. A great deal of the world's authorized security work runs from exactly this infrastructure. Internet-measurement projects map the IPv4 space from cloud. Academic researchers enumerate services from cloud. Commercial scanning services — the Shodan- and Censys-class platforms whose data this very program consumes — run their probes from cloud. Bug-bounty hunters and contracted red teams spin up cloud instances to test clients who asked to be tested. All of them use the same tools: Nmap, libssh2, sometimes Hydra. All of them present the same HASSH fingerprints as the abusers. At the tool layer they are indistinguishable, because they are running the same code for a different reason.

Where does the steelman fail? Only on the specific, and only because of what a honeypot is. A honeypot is a decoy that hosts nothing real and has authorized no test of itself. It cannot be the legitimate target of anyone's contracted engagement, because there is no owner who commissioned an assessment of a system that exists only to be attacked. So every hit against it is unauthorized by construction — not because the tool is malicious, but because consent is the one thing that separates research from attack, and a honeypot, by design, gives none.

But notice what survives the rebuttal. The rebuttal only holds for the honeypot. Across the broader population of cloud-hosted scanners — the ones hitting real assets — the mixture of research and attack is genuine, and no signal at the tool layer resolves it. That unresolvable mixture is not noise in the data. It is the dual-use thesis of this series, observed at the network layer: the tool is silent about intent, and on infrastructure this legitimate, the network is silent too. Consent is carried in neither, and consent is the only thing that was ever the difference.

6. The seven questions

Who? Unattributable tenants of Google Cloud, invisible behind the provider — plus an honest, unquantifiable fraction of legitimate researchers sharing the same fingerprints.

What? The concentrated brute-force-and-scan arsenal — Hydra, Ncrack, Medusa, Nmap enumeration, libssh2 scanners — run from disposable instances.

When? Continuously; the top nodes are single-appearance bursts (e.g. 2026-06-27), consistent with spin-up/run/tear-down.

Where? AS396982, Google Cloud Platform (US registration; instances globally distributed but the ASN is one).

Why? Because the cloud sells the attacker a fresh, clean, instantly-provisioned, effectively-unblockable identity for the duration of a short, loud task — a product bulletproof hosting cannot match for that use case.

How? Provision an instance (trial, promo credit, stolen card, or hijacked account), install a published tool, point it at a target range, finish before the abuse report lands, destroy the instance.

So what? The honeypot's most CRITICAL-rated tooling source is also one of the internet's most legitimate networks — proof that operator reputation is worthless as a packet-level trust signal.

7. Read between the lines

The uncomfortable inference sits in the collision of the two numbers, and it generalizes far past this one ASN.

We have spent two decades teaching defenders to build reputation systems: score the sender, score the ASN, score the network, and let the score gate the traffic. AS396982 is where that entire paradigm quietly breaks. Its reputation as an operator is impeccable and its contribution to attacks against you is CRITICAL, at the same time, from the same addresses, and there is no reputation number you can assign the network that is simultaneously true for the wanted traffic and the unwanted traffic sharing it. The hyperscaler did not defeat reputation scoring by being bad. It defeated it by being shared — by hosting, on one indivisible address block, both the traffic you must allow and the traffic you must stop.

Which means the attacker's cleverest move here is not technical at all. It is to hide inside your own trust. They chose Google not despite its legitimacy but because of it — because your blocklist flinches at the brand, because your reputation feed rates the ASN benignly, because a Hydra run wearing a Google return address gets a benefit of the doubt a Hydra run from a Seychelles shell never would. The reputability is not incidental cover. It is the exploit.

8. Detection and defence

1. Separate the operator from the tenant in every score. A CRITICAL rating on a hyperscaler is a statement about who rents it, never who runs it. Do not let a benign operator reputation launder a malicious packet, and do not blocklist the operator to punish the tenant — both are errors of the same conflation.
2. Score behaviour, not the hosting brand. A Hydra brute-force is a Hydra brute-force whatever the return address. Hyperscaler space at your perimeter deserves the same behavioural scrutiny as any bulletproof range — arguably more, because it is the space attackers deliberately choose for its unblockability.
3. Detect at connect time; the IP will be gone by blocklist time. Ephemeral, single-appearance, high-threat cloud IPs will always evade reputation lists. Match the tool (HASSH), the burst, the credential pattern — signals available in the handshake — because the address itself is a fifteen-minute artifact.
4. Use the abuse channel, but do not wait on it. Unlike a bulletproof host, a hyperscaler will act on a well-formed report. File it — it raises the tenant's cost over time. But treat it as attrition, not defence: the offending instance is already destroyed, and your protection has to have worked without it.
5. Do not allowlist a cloud because it is reputable. This is the load-bearing rule. The instinct to trust Google's ranges is exactly the instinct the attacker rented the ranges to exploit.

9. The Armory, placed

Letter A mapped the armory and named its two tracing primitives — HASSH for the tool, key-reuse for the hand. Letter B is the first weapon opened, and the choice was deliberate: before profiling any single tool or operator, profile the ground they stand on, because the most important fact about the honeypot's cracker arsenal is not which tool it is but where it runs from — and where it runs from is the most legitimate address on the internet.

That reframes everything that follows. The series will walk from here to the dual-arm botnet operator, and onward to the heavy end — Sliver, Havoc, AdaptixC2. Every one of them will be, in its own way, the same lesson this letter draws in the sharpest possible form: the tools are dual-use, the infrastructure is dual-use, and the only thing that was ever single-use — the only thing that carries intent — is consent, which lives in neither the weapon nor the network, and which a honeypot, uniquely, can prove was never given.

10. Sources

• LSN honeypot ASN dossier (AS396982) — CRITICAL classification (50 IPs, avg threat 77, max 100), bulletproof=false, RDAP org Google LLC; top nodes 34.14.110.148 and 35.205.166.70 at threat 100.
• LSN honeypot HASSH campaigns — pentest-tool cluster concentration on AS396982 (Hydra 29, Ncrack 29/34, Nmap-enum 23/23, libssh2_scanner 21/21, openssh_legacy 22/25).
• TI-2026-075A (The Armory) — the dual-use census this letter grounds on one ASN.
• ICANN RDAP / cloud shared-responsibility model — the structural attribution ceiling.

Confidence: HIGH on the CRITICAL rating, the non-bulletproof status, the tool concentration, and the disposable-node behaviour — all direct from honeypot telemetry. The economics and attribution-ceiling analysis is interpretive but standard and well-supported. The legitimate-scanner confound is explicitly retained, not resolved: a fraction of this traffic is authorized research indistinguishable at the tool layer, and the letter treats that indistinguishability as the finding rather than pretending to pierce it. TLP:WHITE — attacker infrastructure and tooling only; no operator secrets disclosed, and no claim is made that Google LLC is complicit — the opposite is the point.