The Credential Army: Elasticity as a Weapon

TI-2026-078C · The Cloud Offensive, Part C Confidence: HIGH Classification: TLP:WHITE

The army behind the scout

Part B was the scout — one machine, mapping the estate by name. This letter is the army it was scouting for: the web arm of the Google Cloud offensive, and the mechanism that makes it dangerous. It is a distributed credential-stuffing campaign, and its weapon is not a clever exploit or a rare tool. Its weapon is the cloud itself — specifically, the one feature every cloud is built to sell: elasticity, the ability to conjure hundreds of machines out of nothing, in seconds, and dispose of them just as fast.

This is the letter where the offensive's scale stops being impressive and starts being instructive — because the way it is built is precisely designed to defeat the standard defence, and understanding how it does that is the same as understanding what actually stops it.

Dozens of machines, the identical magazine

On the 8th and 9th of June, the attack-pattern detector surfaced something that does not happen by accident. Dozens of separate Google Cloud IPs each fired almost exactly 146 credential-harvesting attempts — the same number, from address after address, all high-confidence:

34.151.74.196 (146), 34.129.126.223 (146), 34.125.48.170 (146), 136.110.87.228 (146), 136.109.142.37 (146), 34.104.178.132 (146), 136.110.77.61 (146), 34.125.19.171 (146), 34.118.27.145 (146), 34.64.101.40 (136) — and many more, clustered tightly at 142–146.

Think about what "the same number" means. If these were dozens of unrelated attackers who merely happened to share Google Cloud, their attempt-counts would scatter — some fire 12 credentials, some 400, some 3. They do not scatter. They land, over and over, on 146. That is the fingerprint of one campaign distributing a single, shared credential list — one magazine of exactly 146 rounds — across a rented fleet, and telling every machine to empty the same magazine at the same target. The identical magazine size is a cluster key as strong as any tool fingerprint: sources that fire the identical count of the identical attack are one operation, no matter how disposable and unrelated their addresses look.

A burst, not a trickle

Look at how fast each machine emptied its magazine, and the automation is unmistakable. 34.129.126.223 fired its 146 attempts between 03:35:31 and 03:35:37 on 8 June — six seconds for 146 credential attempts. The others are identical: roughly 25–30 login attempts per second, sustained for about five seconds, and then the machine goes silent forever.

That rate is a machine emptying a clip, not a person guessing passwords. And the shape matters for the defence: it is a burst, not a trickle. Each VM does not settle in and hammer the login slowly over hours; it arrives, dumps its entire magazine in a five-second spray, and vanishes. Now multiply that by dozens of VMs firing in overlapping windows, and the target receives thousands of credential attempts in minutes, from dozens of different addresses, each of which appears exactly once. Hold that image — "each address appears once" — because it is the whole trick.

Then it became hundreds

The June campaign did not stay at dozens. It scaled to a size that only a cloud can produce. On 21 June, the offensive generated 2,011 requests from 799 distinct Google Cloud IPs in a single day. A detected campaign — Burst 2026-06-09 AS396982 (credential_harvest) — groups 83 IPs and 2,765 requests at an effective-bad-rate of 0.97, meaning virtually everything those machines did was hostile.

Seven hundred and ninety-nine attacking addresses in one day is not a botnet. A botnet's size is the number of devices its operator managed to infect — hard-won over months, finite, painful to grow. Seven hundred and ninety-nine fresh cloud IPs in a day is something else entirely: the fingerprint of an operator provisioning hundreds of ephemeral VMs at once, firing them, and tearing them down. The operator did not build this army. They rented it, by the hour, and will return it when they are done.

The weapon is elasticity itself

This is the conceptual heart of the letter, and it is worth stating plainly because it reframes what "a cloud attack" even is.

Every cloud provider sells the same core promise: elasticity. Need one server today and a thousand tomorrow? Provision them in seconds, pay by the hour, tear them down when the traffic subsides. It is the feature that lets a two-person startup survive going viral — the single most valuable capability the cloud offers, and a genuine good.

The credential army is that exact feature, pointed the wrong way. Instant, disposable, massively-parallel compute — provisioned on demand, fired once, discarded — is precisely what you want if your goal is to spray a credential list at a target from hundreds of addresses that each appear only once. The operator did not compromise a single machine. They did not build anything. They rented the cloud's defining virtue and aimed it at a stranger's login page. Elasticity is the weapon — which is why this is not really an attack on Google Cloud or by Google Cloud, but an attack made of Google Cloud, assembled from the same rent-a-server capability that runs the legitimate internet.

And the ammunition, as always, is public. The 146-round magazine is a curated, SecLists-derived credential list — the common-property wordlist every auditor and every attacker draws from, exactly as The Ammunition (075J) documented. Nothing about the list is malicious. What is hostile is loading it into hundreds of rented VMs and firing it, in parallel, at someone else's logins. The parallelism is the crime, and the parallelism is the cloud's contribution to it.

Why the standard defence fails

Here is where the design reveals its purpose, because the elasticity attack is engineered — whether by intent or by convergent evolution — to defeat the single most common web defence: per-IP rate limiting.

Rate limiting works by counting requests per address and blocking the ones that get too noisy. Fire 500 logins from one IP in a minute and you get blocked. It is simple, standard, and effective against a persistent attacker — one that has to keep hammering from the same address because that address is all it has.

The elasticity attack has no such constraint. Each VM fires its magazine once, in five seconds, and dies. No single address ever stays noisy long enough to trip a rate limit — and even if the threshold were low enough to catch a five-second burst, by the time it fired, that VM would already be gone and a fresh one would have taken its place. The attack removes per-address volume as a signal entirely, by making every address single-use. A defence that counts requests per IP is looking for a sustained noise that, by design, never exists. It is structurally blind.

Recall the image from earlier: each address appears once. That is not incidental. That is the whole point. It is what makes the throwaway-VM model work, and what makes rate limiting useless against it.

What actually held the line

So why did the estate not drown in credential attempts? Because the defence that met this army does not count per-IP volume at all. It reads per-request intent, and it fires on the first burst.

CrowdSec's credential_harvest autoban does not wait for an address to become sustainedly noisy. It recognises the pattern of a credential-stuffing burst — the shape of that five-second, 146-round spray — and bans the VM on the strength of its very first magazine, before the disposable machine has a chance to disappear. MikroTik enforces the ban at the router. And because the detection fires on the first hostile act rather than on accumulated volume, the throwaway-VM model gains the attacker nothing: a VM that appears once and dies is caught on that single appearance, so being single-use stops being an advantage and becomes irrelevant.

This is the precise counter to elasticity, and it is worth stating as a rule: against disposable-VM attacks, speed of detection beats volume threshold. You cannot out-count an attacker who never lets any address accumulate a count. You can out-read them, by acting on what the first burst is rather than on how much it does. Behaviour, evaluated per-request, is faster than the VM is disposable. That is the whole game, and the estate is winning it.

One arsenal, two protocols

A closing connection, because it ties the offensive together. This web credential army is not a separate thing from the SSH side of the front. It is the same arsenal on a different protocol. The Cloud Contractor (075B) documented Google Cloud VMs firing Hydra and Ncrack — credential-auditing tools — at the SSH service on port 22. This is the identical doctrine on the web: the same class of credential attack, the same public ammunition, parallelised across throwaway VMs, aimed at the login portals on port 443. Credential-auditing on SSH, credential-stuffing on web, both from Google Cloud, both from public wordlists, both firing in disposable bursts. One arsenal, expressed twice. Which is exactly why the whole offensive has to be read across both protocols at once — and why Part D, the finale, turns to the question that has hung over the entire series: if the weapon is the cloud's own elasticity and the ammunition is public and the addresses are disposable and the platform is un-blockable, then why can no one make it stop?

The translation, for everybody

In plain words: imagine a burglar who does not have one lockpick set but can, for a few dollars an hour, rent a thousand identical robots, hand each one the same ring of 146 keys, send them all to try your door at the same second, and then throw them all away. Your usual alarm — "call the police if the same person rattles the door too many times" — never goes off, because no single robot rattles it more than once. Each shows up, tries all 146 keys in five seconds, and is gone before the alarm could count to ten.

The way you catch that is not by counting how many times each robot knocks. It is by recognising, the instant a robot pulls out a ring of 146 keys and starts trying them, that this is a break-in — and stopping that one robot on the spot, before it vanishes, then doing the same to the next, and the next. You never run out of robots to ban, but it does not matter: each one is useless the moment it acts, because you are reading what it is doing, not counting how long it does it. The keys are ordinary keys anyone can buy. The robots are ordinary rentals anyone can hire. The only thing that gives the burglar away — every single time — is the ring of 146 keys coming out. So you watch for the keys, not the knocking.

Indicators (TLP:WHITE)

Cross-references

• TI-2026-078A — The Cloud Offensive — the front this credential army belongs to.
• TI-2026-075B — The Cloud Contractor — the SSH-side twin; one arsenal, two protocols.
• TI-2026-075J — The Ammunition — the public credential magazine, here fired in parallel.
• TI-2026-078D — The Accountability Gap — why the elasticity that makes this possible cannot be made to stop (the finale).

This dossier documents distributed credential-stuffing waged from Google Cloud elasticity, for defensive purposes. The credential lists are public, dual-use resources and the compute is lawful rented infrastructure; the hostility is in the parallel firing at a stranger's logins, which behavioural detection catches on the first burst. TLP:WHITE.