The Cloud Offensive: A Dedicated Front on Google's Network

TI-2026-078A · The Cloud Offensive, Part A Confidence: HIGH on scale and dual-vector shape; MEDIUM on single-campaign unification Classification: TLP:WHITE

The plain version

Every server on the internet gets attacked constantly. That is normal, and most of it is faceless background noise — automated scanners sweeping the whole internet, hitting your address the same way they hit everyone's, with no particular interest in you.

This is not that.

For nearly two months, one network has been attacking this infrastructure with a scale and persistence that is not background noise — 2,105 different attacking machines, thirty-seven distinct campaigns, hitting both the websites and the remote-login service at the same time, every day, still going right now. And the network they are attacking from is not some shady bulletproof host in a permissive jurisdiction. It is Google Cloud — the most reputable, most trusted, most un-blockable network on the internet.

That combination — a sustained, dedicated, dual-front assault, waged from the one address nobody can block — is what this series is about. This first letter maps the front: how big it is, what shape it takes, how long it has run, and why it is being fought from behind Google's good name. The letters that follow trace the parts: the reconnaissance aimed at this estate by name (Part B), the credential army (Part C), and the reason none of it can be made to stop (Part D).

The size of the front

Start with the numbers, because the numbers are the story.

The web-threats layer records 2,105 distinct attacker IPs from AS396982 — Google Cloud — of which 516 are classified aggressive, spread across 37 separate campaigns. Its effective-bad-rate is 0.462: nearly half of everything observed from this network is classifiably hostile. To calibrate that, the commercial-VPN network profiled in the previous series (TI-2026-077) ran a bad-rate around 0.15 — roughly one hostile connection in seven. Google Cloud runs at nearly one in two. No other network attacking this infrastructure comes close in the sheer scale of its hostile presence.

Two thousand attacking machines is not a stray misconfigured VM or a single operator's small fleet. It is a front — a standing body of hostile capacity, continuously replenished, pointed at one target. And the target is this homelab: a personal infrastructure of a few dozen services, being worked over by a slice of the world's largest cloud.

Both doors at once

The offensive is not on one protocol. It runs on two at the same time, continuously, which is what makes it a coordinated front rather than two coincidences.

On the web layer it is a credential-harvest army. Attack-pattern detection flags dozens of Google Cloud VMs each firing roughly 146 credential-harvesting attempts in a tight five-second burst — 34.151.74.196, 34.129.126.223, 34.125.48.170, 136.110.87.228, 34.104.178.132, and many more, all at the same ~146 count, all high-confidence. Around them swirl cms_detect (fingerprinting the content-management systems), vhost_enum (guessing which sites are hosted), auth_probe (testing the login portals), and scanner_fingerprint. This is the machinery of a distributed web intrusion, run from ephemeral cloud VMs by the dozen. (The synchronized 146-round magazines get their own letter — Part C.)

On the SSH layer it is a botnet — specifically the "Cloud Contractor" pentest cluster documented in The Armory (TI-2026-075B). The honeypot records high-threat Google Cloud hitters like 35.188.112.111 (46 honeypot sessions, an AbuseIPDB score of 100, GreyNoise "malicious," tagged actor_cluster_001), alongside dozens of threat-100 GCP IPs, several with recorded honeypot successes.

One network. Both doors. Continuously. This is the cross-vector pattern the Armory named (TI-2026-075X) and the last series caught on a single VPN operator (077C) — but here it is at the scale of an entire hyperscaler. A defence watching only the web sees a credential army; a defence watching only SSH sees a botnet; only correlating the two, on the shared ASN, reveals that they are one offensive.

The timeline: months, not moments

This is not a bad afternoon. It is a campaign measured in months.

Activity runs continuously from 21 May into 10 July 2026 — the day of writing — with no let-up, and it is punctuated by enormous coordinated bursts that reveal the machinery behind it:

• 21 June: 2,011 requests from 799 distinct Google Cloud IPs in a single day.
• 25–26 June: ~1,400–1,500 requests from ~72 IPs each day.
• 4 July: 647 requests.
• 10 July (today): still firing — 188 requests, 17 IPs.

The 799-IP single-day burst is the tell. That is not a handful of persistent machines; it is the signature of a distributed campaign spinning up hundreds of ephemeral cloud VMs at once, pointing them all at one target for a day, and letting them be torn down. This is the cloud's own elasticity — the feature that lets a startup scale to millions of users overnight — turned into a weapon: instant, disposable, hundreds-of-machines attack capacity, rented by the hour and thrown away.

A battle being fought right now

Here is what makes this front different from a historical write-up: it is live, and it is being actively contested. As these words are written, the defence is trading blows with the offensive in real time.

CrowdSec — the behavioural intrusion-prevention engine — has roughly 91 Google Cloud IPs under active ban and is adding more by the hour. The decisions log for 10 July alone shows a continuous stream of autobans: credential_harvest, cms_detect combined with vhost_enum, http:scan, watchdog-http-probing, crowdsecurity/http-sensitive-files, http-generic-403-bf. MikroTik enforces every one of those bans at the router, dropping the traffic at the network edge.

The rhythm is a running battle: the attacker spins up a new batch of Google Cloud VMs; the behavioural engine watches what each one does and bans it by intent; MikroTik drops it; the attacker spins up more. And — this is the point that Part D will develop — the estate is holding, because the defence keys on behaviour, not network. It bans the hostile VM for its hostile act, and never has to (never could) block Google Cloud itself. The offensive has scale; the defence has the one thing scale cannot overwhelm: a per-act response that removes each attacker without touching the platform.

Why Google Cloud — the armour of reputation

Which raises the question the whole series turns on: why here? Why would an attacker wage a sustained offensive from Google Cloud rather than a cheap bulletproof host?

Because Google Cloud is un-blockable, and un-blockable is the most valuable property attack infrastructure can have.

AS396982 is impeccable by every reputation measure: ARIN-allocated in 2018, 15,000 IPv4 prefixes, PeeringDB-listed, not on Spamhaus, not bulletproof, ASN risk score 20. It is the backbone of a large fraction of the legitimate internet — the cloud that runs countless businesses, services, and applications the world depends on. And that dependency is the armour. A defender cannot block Google Cloud without severing legitimate service to a huge slice of the internet; nobody can afford to, so nobody does.

The attacker knows this. They fire from behind Google's reputation knowing the single response a defender is structurally unable to take is the obvious one — a network block. This is the reputable-midtier thesis of the previous series (077D) and The Bulletproof Shelf (075V) at hyperscaler scale: not merely a clean network that is rarely blocked, but the single most un-blockable address on the internet, weaponised. The offensive is waged from Google Cloud because it is Google Cloud. The reputation is not a place the attack happens to be; it is the shield the attack hides behind.

And yet — the corpus has been documenting exactly this for a long time. AS396982 is the most-named attacker ASN in the entire library: 33 published dossiers, from the SSH pentest arsenal (The Cloud Contractor, 075B) to the global botnet censuses (026M, 047C, 025G) to the pointed accountability studies (The Google Cloud Anomaly: Hyperscaler Accountability Gap, 032G; The Cloud Complicity, 041D; The Cloud Mercenaries, 046E). This series is the synthesis those dossiers were building toward: the sustained, dual-vector offensive, seen whole, and turned on this estate specifically.

One soldier, named

The scale can feel abstract — 2,105 machines, 37 campaigns — so it helps to name one, because one of them shows the offensive's intent with unusual clarity.

34.122.16.212 is a single Google Cloud VM, active from 5 June and MikroTik-banned since 30 June. It does not spray blindly. It enumerates this estate by name — probing lsn-nas1 (the network-attached storage, via its actual Synology QuickConnect ID, 19 times), lsn-wifi, lsn-wireguard (the VPN), lsn-registry, lsn-storage, lsn-webtop, lsn-pihole, lsn-ai, and sixteen more of the lsn-* namespace, and auth-probing the Authelia login portal with redirect parameters pointed at the protected services behind it. It is the reconnaissance spearpoint of the front — the machine sent to map the target before the army works it — and it is disturbing enough, in how specifically it knows this estate, to warrant its own letter.

That is Part B. It is the letter where the offensive stops being a statistic and becomes personal.

The translation, for everybody

In plain words: imagine your house is being cased and rattled — every door, every window, day after day, for two months — by hundreds of different people. Now imagine they are all doing it while standing on the property of the most respected company in town, a company whose address is so reputable that you cannot complain your way to getting them removed and cannot wall off the property without cutting yourself off from half the neighbourhood. That is what attacking from Google Cloud is: hundreds of disposable hands, rattling your doors, from behind a name too big and too trusted to block.

You cannot make them leave the property. What you can do — and what is working — is watch each pair of hands, and the moment one of them actually tries a lock, stop that pair, specifically, while everyone else on the property goes about their legitimate business. You will never block the company. You do not need to. You only need to catch the hands in the act, one at a time, forever if necessary. That is the war this series documents — and, so far, the estate is winning it, one banned VM at a time.

Where the epic goes

Four letters, one front:

• Part A — The Cloud Offensive (this letter): the map — scale, dual-vector shape, timeline, and the armour of reputation.
• Part B — The Estate Sweep: 34.122.16.212 and the reconnaissance aimed at this infrastructure by name — the NAS, the VPN, the registry, the whole lsn-* estate.
• Part C — The Credential Army: the synchronized 146-round magazines and the 799-IP burst — the cloud's elasticity turned into distributed credential-stuffing.
• Part D — The Accountability Gap: why the world's most reputable cloud cannot be made to stop, and why behaviour — not network, not reputation, not the abuse report — is the only thing that ever catches it. The finale.

The offensive is still firing as this publishes. It has been for two months. It is waged from the most trusted address on the internet, by hundreds of disposable machines, against a personal infrastructure it knows by name. And it is being held — not by blocking the cloud, which is impossible, but by reading the one thing the cloud cannot launder: what each machine actually does.

Indicators (TLP:WHITE)

Cross-references

• TI-2026-075B — The Cloud Contractor — the SSH pentest-arsenal cluster on this ASN.
• TI-2026-032G — The Google Cloud Anomaly · 041D — Cloud Complicity · 046E — Cloud Mercenaries — the accountability gap that lets it persist (Part D).
• TI-2026-075X — The Cross-Vector / 077 — The Laundered Vector — the dual-vector and reputable-cloud patterns, here at hyperscaler scale.
• TI-2026-073C — The Namespace Sweep — the namespace-native recon examined in Part B.

This dossier documents a sustained, dual-vector offensive waged from Google Cloud infrastructure against this homelab, for defensive purposes. AS396982 (Google Cloud) is a lawful platform whose ephemeral compute and un-blockable reputation are abused by third parties; nothing here attributes the attack to Google. Attribution rests on behaviour, not the platform. TLP:WHITE.