The Accountability Gap: Why the Cloud Offensive Never Ends

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

The question the whole series has been circling

Three letters have described a sustained, dual-vector, months-long offensive from Google Cloud: its scale (Part A), its reconnaissance aimed at this estate by name (Part B), its credential army built from rented elasticity (Part C). Every one of them ended on the same quiet, unsettling note — it is still going. Two months in, banned by the dozen, and still firing.

Which forces the question this finale exists to answer: why can no one make it stop?

Not "why is the defence failing" — the defence is holding. The question is deeper and stranger. A crime is being committed continuously, from a known network, against a known target, with the evidence sitting in plain view. In any normal setting, that is a solvable problem: you report it, or you block it, or you identify who did it. And against a cloud offensive, all three of those fail — not because the attacker is a genius, but because of how the cloud is built. This letter is about that triple failure, the gap it opens, and the one thing that falls through the gap intact.

The report is aimed at a ghost

The first and most natural response to abuse is to report it. Every provider has an abuse desk; Google's is google-cloud-compliance@google.com. Send the evidence, and they act — suspend the account, pull the VM. That is how accountability is supposed to work.

Against ephemeral cloud VMs, it fails at the level of time. Recall the credential army of Part C: each VM fired its 146-round magazine in five seconds and was then destroyed. Now imagine filing the report. You gather the logs, write the complaint, send it. Even if Google's abuse desk triages it in hours — which for a hyperscaler receiving millions of such reports would be fast — the machine you are reporting ceased to exist long before the email was opened. You are reporting a VM that lived for five seconds against a process that operates in hours or days.

Disposability outruns due process. The unit of attack is a machine with a lifespan of seconds; no abuse process on earth operates at that timescale. The report is not ignored — it is simply aimed at a ghost, a machine that was gone before the complaint was written. This is the core of what The Google Cloud Anomaly (TI-2026-032G) called the accountability gap: the attacker's atomic unit is briefer than the shortest possible response, so the response can never land.

The block would sever the world

The second response is to block it. If you cannot get Google to pull the VM, pull it yourself — drop AS396982 at your router and be done.

This fails at the level of dependency. Google Cloud is not a peripheral network you can afford to lose. It runs a vast fraction of the legitimate internet — the applications, the businesses, the services that you and everyone you deal with rely on every day. The corpus even records it holding government workloads, up to a US Department of Defense IL5 authorization (TI-2026-019M). A network that critical cannot be severed by any defender without severing themselves from the functioning internet. Block Google Cloud and you do not stop the attacker; you break your own access to half the services you depend on, while the attacker — who can exit from any of a thousand other places — barely notices.

This is The Cloud Complicity (TI-2026-041D): the hyperscaler's centrality to legitimate infrastructure is precisely what makes it un-blockable, and un-blockability is exactly what the attacker rented. It is the reputable-midtier thesis of the previous series (077D) at its absolute maximum — not merely a clean network rarely blocked, but the single most essential, most un-blockable network on the planet. The more the world depends on the platform, the safer the attack that hides inside it. Criticality is not a barrier the attacker overcame; it is the shield they leased.

The owner is not the attacker

The third response is to attribute it — find who is responsible and hold them accountable. And here the failure is the subtlest and the most complete, because it fails at the level of who exists to be blamed.

The attacking IP belongs to Google. The attacker is a momentary tenant who rented it for an hour. So who is accountable? Not the owner: Google did not commit the act, and you cannot hold a landlord criminally responsible for what a one-hour tenant did with a rented room, especially when millions of other tenants use the same rooms lawfully. Not the tenant: they committed the act, but they are gone — the VM destroyed, the account possibly a stolen or throwaway one, the human behind it anonymous behind the platform. There is an owner who did not do it and an actor who cannot be found, and accountability reaches neither.

This is the gap The Deed and the Tenant (TI-2026-068B) named exactly: responsibility falls into the space between the deed (the IP, owned by Google) and the tenant (the attacker, transient and anonymous). Every other kind of attack has someone at the end of the thread. This one has a landlord and a ghost, and the thread simply ends in the space between them.

Everything a defender can pull is defeated by structure

Stack the three failures and the picture is total:

• Report it → the VM is destroyed before the complaint is read. Disposability defeats the report.
• Block it → the platform is too essential to sever. Criticality defeats the block.
• Blame the owner → the owner is not the actor, and the actor is gone. Tenancy defeats the attribution.

Notice what these three have in common. None of them is a failure of the defender. None is the attacker being clever. Each is defeated by a structural property of the cloud itself — the very features that make cloud computing valuable. Disposability is a feature (spin up, tear down, pay only for what you use). Criticality is a feature (the platform is reliable enough to run the world on). Tenancy is a feature (anyone can rent compute without owning a datacenter). The offensive persists because the internet's accountability mechanisms were never designed for infrastructure that is instant, essential, and rented — and the cloud is all three, by design. The gap is not a bug in Google Cloud. It is the shape of cloud computing, seen from the receiving end of an attack.

The one thing that falls through the gap intact

When the report fails, the block fails, and the attribution fails, it would be easy to conclude that nothing can be done. That conclusion is wrong, and the reason it is wrong is the whole point of the arc.

One thing survives every structural failure: the act.

A defender cannot make Google act. Cannot block Google. Cannot identify the tenant. But a defender can, unilaterally and immediately, refuse the hostile act at their own door. When CrowdSec bans a VM on the pattern of its first credential-harvest burst and MikroTik drops it at the router, that is accountability relocated — moved from the places where it fails (the abuse desk, the network block, the attribution graph) to the one place a defender fully controls: the boundary of their own estate, judged on behaviour.

And this relocation is not a consolation prize. It is structurally superior to everything that failed, because of what it does not require. It does not require Google to cooperate. It does not require the attacker's identity. It does not require leverage over the platform, or a fast abuse desk, or the VM to still exist. It requires only that the defender watch what crosses their own door and refuse what is hostile. It is the one form of accountability that is unilateral — that depends on no one else acting — and unilateral is exactly what a small estate facing a hyperscaler needs, because every other option depends on some larger party that will not, or cannot, move.

The act is the only thing the gap does not swallow. So the act is where the defence lives.

The arc converges on one sentence

This finale closes more than an epic. It closes a three-series arc, and the three series arrive — from three different layers of the same problem — at a single conclusion.

• The Armory (075) spent twenty-six letters proving: judge the act, not the tool — because the tool is shared, common property, owned by defenders and attackers alike.
• The Laundered Vector (077) proved: judge the act, not the pipe — because the pipe is a shared VPN carrying the innocent alongside the guilty, un-blockable without collateral harm.
• The Cloud Offensive (078) proves: judge the act, not the platform — because the platform is un-reportable, un-blockable, and owned by someone other than the attacker.

Tool, pipe, platform. Three layers of concealment, and the same answer at every one. Look at what these three things — the tool, the pipe, the platform — have in common: each is either common property or structurally un-actionable. The tool is shared. The pipe is shared. The platform is essential and rented. Everything an attacker can hide behind turns out to be, on inspection, either something everyone owns or something no one can act against. And the one thing that is neither — not shared, not structural, not un-reachable — is what the attacker actually does. The behaviour. The act.

That is the load-bearing sentence of the entire body of work, proven now at three layers: at every level of laundering, the act is the sole accountable unit. You cannot hold the tool accountable; it is yours too. You cannot hold the pipe accountable; the innocent are inside it. You cannot hold the platform accountable; the world runs on it. You can only ever hold accountable what was done — and, precisely because everything else is un-actionable, that turns out to be enough.

You do not win. You hold.

A last, honest word about what "enough" means, because the finale should not pretend to a victory it has not won.

The offensive is still firing as this publishes. It has run for two months and it will not stop — because, as this letter has shown, nothing can make it stop. There is no version of this story where the estate reports the right address, blocks the right network, identifies the right person, and the attacks end. That ending does not exist. The front is permanent.

That is not defeat. The estate is holding: ninety-one Google Cloud IPs under live ban, each hostile VM removed on its first act, the crown jewels named in Part B intact, no compromise observed anywhere in two months of assault. The correct objective was never victory — victory is unavailable — it is endurance. Accept the front as permanent. Maintain per-act behavioural defence indefinitely. Harden the named targets. Share the indicators. And understand why this is sustainable for a small estate against a hyperscaler: because the defence is per-act and unilateral, it does not tire faster than the attacker can rent VMs. Each ban is cheap, automatic, and final for that VM; the attacker's each new VM is cheap too, but it gains them nothing, because it is caught on its first act. The two sides are both inexhaustible — but only one of them is making progress, and it is not the attacker.

You do not win the cloud war. There is no winning a war that cannot end. You hold the line — per-act, at your own door, forever — and holding the line, it turns out, is a thing a small estate can actually do, indefinitely, against the largest cloud on earth. That is the epic's ending, and it is not a grim one. The offensive is endless; so is the defence; and the defence is the one that keeps the doors shut.

The translation, for everybody

In plain words: someone keeps trying to break into your house, from an address you cannot get them evicted from (the landlord is the most powerful company in the world and the burglar rents by the hour and is gone before you can point), on a property you cannot wall off (you would cut yourself off from half the town), by a person you cannot name (the landlord did not do it and the renter vanished). Every normal way of making it stop — call the landlord, block the road, name the culprit — hits a wall.

So you stop trying to make it stop. You accept that people will keep coming, forever, and you simply get very good at one thing: the instant a hand touches your lock, you catch that hand, and shut the door, and you do it again for the next one, and the next, tirelessly, automatically, at your own threshold — where you, and only you, are fully in charge. You will never clear the street of burglars. You do not need to. You need only keep your own door shut, one caught hand at a time, and that is a thing you can do forever. The attacks never end. Neither does the catching. And the door stays shut.

That is the whole of it. Not victory — vigilance, made permanent and cheap. The doors are still shut. They have been the whole time.

The Cloud Offensive — complete

Four letters, one front, still live. It is the largest and most persistent attacker of this infrastructure, waged from the world's most reputable and un-blockable network, aimed at this estate by name, built from rented elasticity, and immune to every accountability mechanism the internet has. And it is being held — not by making it stop, which is impossible, but by refusing each act at the door, one banned VM at a time, indefinitely.

The Cloud Offensive — complete. The line holds.

The series

Cross-references

• TI-2026-032G — The Google Cloud Anomaly · 041D — Cloud Complicity · 068B — The Deed and the Tenant — the three structural failures of accountability.
• TI-2026-075I — The Weapon Is Never the Point / 077D — The Midtier — the arc convergence: judge the act, not the tool / pipe / platform.
• TI-2026-078A–C — The Cloud Offensive — the front, the recon, the credential army this finale explains.

This dossier documents why cloud-hosted attacks resist accountability and why behavioural, boundary-level defence is the only enforceable response, for defensive purposes. Google Cloud is a lawful, essential platform whose structural properties are abused by transient tenants; nothing here attributes the attack to Google, and the finding is that accountability must therefore rest on the act, at the defender's own boundary. TLP:WHITE.