Storage & Data Services

After this chapter you will be able to attack a cloud provider's object-storage layer as a system — squat its global namespace, exploit predictable and provider-generated bucket names, and turn cross-tenant storage trust into a confused-deputy or supply-chain compromise.

The problem

A web engineer hears "cloud storage attack" and pictures a public S3 bucket leaking a spreadsheet. That is an in-tenant misconfiguration — one customer's mistake, one customer's blast radius — and this course deliberately demotes it. We are here to attack storage as a provider-side, multi-tenant system: the shared registry, the cross-tenant trust, the auto-fetch-and-execute paths the provider built for everyone at once.

First, vocabulary, because the reader knows HTTP but not necessarily S3. Object storage is a key-value store at planetary scale. A bucket (AWS S3, GCS) or storage account → container (Azure Blob) is a named container; an object / blob is a blob of bytes addressed by a key. Each is reachable over HTTPS at a predictable URL:

The problem is not that someone left a bucket public. The problem is two structural facts about how object storage is built. The first is the global namespace: bucket names are claimed first-come-first-served from one flat registry shared by every tenant on Earth, with nothing in the name that says "this belongs to me." The second is cross-tenant storage trust: services, SDKs, and infrastructure-as-code templates routinely resolve a name to data and then act on that data — often fetching and executing it — without ever checking who owns the bucket the data came from. Put those two facts together and you get the chapter's thesis: in object storage the enforcement plane and the attack surface are the same flat string. Whoever controls the name controls the bytes; and whoever controls the bytes a victim's service auto-fetches controls the victim.

Why it matters / how it differs from a traditional pentest

Pentesting a tenant, you would look for one customer's public bucket and report it. That finding has a blast radius of one. Attacking the provider's storage layer is a different exercise, and three properties make it so.

The namespace is the sixth isolation boundary, and it is global. Chapters 1–6 attacked five boundaries — network, identity, hypervisor, Linux namespace, account/subscription. This chapter introduces naming. A naming bug does not affect one tenant; it affects whoever next claims, or next trusts, a name. When the namesquatting victims turned out to include AWS's own service teams, the blast radius became the entire tenant base.

Recon leaves no trace in the victim's logs. Claiming a bucket happens in the attacker's account, so the victim's CloudTrail records nothing. Enumerating Azure storage accounts happens over public DNS, entirely off-platform. This is the storage-specific instance of the log-invisible reconnaissance from Chapter 2 — the victim's detection surface for the recon phase is precisely nothing.

The payoff runs through the confused deputy. A traditional pentest exploits the attacker's own access. Here the impactful step is performed by the victim's service — CloudFormation, Glue, a build pipeline — running with the victim's privilege on attacker-supplied content. Recall from Chapter 3: a confused deputy is a privileged component tricked into misusing its authority on an attacker's behalf. Storage is where you weaponise it cheaply, silently, and patiently.

The methods at a glance

Four techniques, each a different way the namespace or the trust placed in it breaks. The breakdown sections below take them one at a time.

Technique 1 · Squatting a predictable name

The simplest abuse of a first-come-first-served namespace: claim a name a victim expects to own — before they create it, or after they delete it — so their traffic, uploads, or deployments land in attacker-controlled storage.

The attack works only because bucket names are predictable. Software that deploys across many regions cannot hard-code one bucket name — it needs one per region — so it builds names from a template, typically prefix-{region}. The region is a known, small, public set. The cruel part: future regions are foreseeable. AWS announces regions long before they open, and new region names leak even earlier through Certificate Transparency logs as AWS provisions infrastructure. An attacker who knows a template uses appdevzipfiles-{region} can register appdevzipfiles-<next-region> before AWS launches that region.

That is exactly what Ian McKay demonstrated in 2019, the foundational disclosure of the problem^[1]#211. He found a Sumo Logic CloudFormation quick-start template — the one-click install an ISV ships to thousands of customers — that sourced a Lambda's code like this:

"Code": {
  "S3Bucket": { "Fn::Join": ["", ["appdevzipfiles-", { "Ref": "AWS::Region" }]] },
  "S3Key": "cloudwatchlogs-with-dlq.zip"
}

{ "Ref": "AWS::Region" } resolves at deploy time to whatever region the customer is in. McKay registered appdevzipfiles-eu-north-1 before AWS launched the Stockholm region. Any customer who later deployed that template in Stockholm would pull their Lambda's executable code straight out of his bucket — not their data, their code. He had hijacked a code-delivery path into thousands of accounts for the price of a bucket name and the patience to wait for a region to open.

Notice the shape. The squat is a control-plane race — a single CreateBucket call — whose payoff is a data-plane interception: the victim's GetObject reads attacker bytes. The victim's CloudTrail records nothing, because the attacker's bucket lives in the attacker's account.

Technique 2 · Shadow resources & Bucket Monopoly

McKay's attack still needed a human to write a predictable template. The 2024 escalation removed the human: the provider itself creates predictably-named buckets, automatically, with names the customer never chose and often never sees.

Aqua's Bucket Monopoly research catalogued six first-party AWS services that auto-create predictably-named S3 buckets^[2]#236:

For four of those six, the entire secret ingredient is the victim's AWS account ID — and an account ID is not a secret. It is printed in every ARN, leaks in S3 "access denied" error messages, and appears in public role trust policies. Recover it once and you can compute every Glue/EMR/SageMaker/CodeStar shadow-bucket name the victim will ever use, in every region.

Now the "Monopoly." An attacker pre-creates the predictably-named bucket in every region the victim has not used yet. The victim cannot enable the service in that region until the bucket exists — and the attacker owns it. The attacker holds a monopoly on that namespace slot, and the victim is forced to interact with attacker-controlled storage the first time they touch that service in that region. There is no "choose a different name" escape hatch; the name is hard-coded into the service.

The CDK case is worth a beat because the SDK hands the attacker the name. CDK bootstraps with a staging bucket called cdk-{Qualifier}-assets-{AccountID}-{Region}. The default qualifier is the fixed string hnb659fds^[3]#230 — it looks random, but it is hard-coded into CDK and used by the overwhelming majority of CDK projects. So the "random-looking" bucket name collapses to account ID + region, both knowable. That is the bucket from the cold open.

How the chain reaches cross-account admin

Squatting a code-delivery path is bad; Aqua turned it into full account takeover, and the route runs through the confused deputy. The escalation works because the squatted bucket is not a passive sink — S3 buckets support event notifications. The attacker pre-creates cf-templates-{hash}-{region} in an unused region and attaches a notification that triggers an attacker-owned Lambda on every PutObject. When the victim later runs a CloudFormation deployment in that region, their template is uploaded into the attacker's bucket. The attacker's Lambda fires, reads the template (data theft) and injects new resources — most usefully a new IAM role with AdministratorAccess and a trust policy that lets the attacker's account assume it. CloudFormation then deploys the tampered template with the victim's privilege, creating an admin role inside the victim's account.

Read through the lens: naming failed first, which then defeated the account boundary; the attacker never used their own privilege for the impactful step — the victim's CloudFormation role did; the detection surface on the victim side is empty until the admin role appears, by which point it is over.

Technique 3 · Enumerating the namespace

A reasonable reader objects: Azure made blobs private by default years ago; surely the namespace is no longer a free recon channel. CyberArk's 2021 blob hunt answers that objection by finding 50 million publicly readable files across roughly 100,000 storage accounts^[4]#192 — PII, health records, around a million invoices, half a million log files, and plaintext credentials and keys.

"Private by default" did not stop this, and the reason is structural: the defense is a per-container toggle; the attack is against the namespace, which no toggle touches. The enumeration pipeline:

The provider-side teaching point is step 1. Because the storage-account name is a DNS name, the entire global namespace is enumerable for free, from outside the cloud, leaving zero entries in any victim's log. The existence and naming of every storage account leak through DNS regardless of any blob ACL — and the victim's detection surface for that recon is precisely nothing. That is a provider architecture decision, not a customer slip. CyberArk packaged the technique as the open-source tool BlobHunter.

Technique 4 · Storage as a confused deputy & a supply chain

The Bucket Monopoly chain and the pickle-model kicker are two instances of one idea: a victim's component trusts the contents of storage and acts on them. Object storage is a trust sink — and a sink is dangerous in both directions. Things downstream trust what they read out of it; and a "private" bucket is not safe if something upstream hands out scoped write credentials and the consumer trusts whatever lands there.

The template-as-supply-chain pattern is not a one-off either. McKay's Sumo Logic finding was an ISV shipping a name-templated CloudFormation quick-start to every customer; the same shape recurred when Microsoft's Defender for Cloud distributed an AWS-onboarding CloudFormation template through public GitHub with an under-scoped IAM trust policy^[7]#238. And the trust web runs all the way up: the BingBang research^[8]#085, whose headline is an Entra multi-tenant auth flaw, also exposed an internal Microsoft application called COSMOS — a file-management front-end over more than four exabytes of Microsoft internal files, with in-app list, read, and edit. Object storage is rarely the end of a chain; it is the medium the chain travels through. Chapter 9 develops CI/CD supply chain in full — here the warm-up lesson is that a squatted bucket or a tampered template feeds a victim's pipeline.

That comparison — across all three majors — is worth holding as one table: