Hijack Orphaned S3 Buckets for Data Access

What this lab covers

You work through an environment establishing what your access permits, follow references in code to storage that no longer exists, and demonstrate what happens when someone else claims the name first.

This is a vector Pwned Labs encountered on a real engagement, which is why it is here. It is under-discussed relative to how often it appears, because it lives in the gap between infrastructure and code where neither team is auditing.

It is rated intermediate and assumes some AWS familiarity. The reasoning transfers directly to other services with global namespaces.

How orphaned bucket hijacking works

S3 bucket names occupy a single global namespace. A name is unique across all AWS accounts worldwide while it exists, and it becomes immediately available to anyone once the bucket is deleted. There is no reservation period and no ownership memory.

References outlive infrastructure. Deployment scripts, container images, application configuration, documentation and infrastructure code all embed bucket names, and deleting a bucket does not update any of them. Typos create the same condition without anything ever being deleted.

The consequence depends on the direction of the reference. Where systems write to the bucket, an attacker who claims the name receives that data, which may include logs, backups or uploads. Where systems read from it, the attacker controls what is served, which can mean supplying scripts, packages or configuration to a trusting client. The second case is a supply chain problem rather than a data exposure one.

How to detect this in your own environment

Look for the failures. Applications referencing a bucket that no longer exists generate errors, and those errors are usually treated as noise and suppressed. A recurring no-such-bucket error is a dangling reference and should be treated as a finding, because it is a window during which someone else can claim the name.

Inventory references rather than resources. Scan source repositories, container images and infrastructure code for bucket names and reconcile them against buckets you actually own. The gap between those two lists is your exposure.

Once a name has been claimed by someone else, the errors stop, which is the difficult part. Silence after a period of failures is not resolution and is worth investigating specifically.

How to prevent it

Do not delete buckets that anything has ever referenced. Empty them and keep the name. Retaining an empty bucket costs effectively nothing and permanently denies the name to anyone else, which is the only complete mitigation.

Remove the reference before removing the resource, and treat decommissioning as a code change rather than a console action. Most hijacking opportunities are created by doing these in the wrong order.

Where clients read code or configuration from object storage, verify integrity rather than trusting the source. Signature or hash verification means claiming the name does not automatically mean controlling the client.

Real-world context

Dangling resource takeover is a well-established class covering DNS records, cloud storage names and package registry names, and it recurs because the underlying cause is organizational rather than technical. Resources are deleted by one team while references live in artifacts owned by another.

The supply chain variant is the more serious one. If build systems or applications fetch scripts or packages from a bucket, whoever controls the name controls what runs, and that trust is usually implicit with no verification step.

The pattern maps to MITRE ATT&CK T1584 Compromise Infrastructure and T1195 Supply Chain Compromise.

Applying this at work

• Scan your repositories and infrastructure code for bucket names and reconcile them against the buckets you own. Include archived repositories and container images.
• Stop deleting buckets as a decommissioning step. Empty and retain the name instead.
• Search your logs for no-such-bucket errors and treat each as a dangling reference to close.
• Where anything fetches executable content or configuration from object storage, add integrity verification.
• Apply the same reasoning to DNS records pointing at decommissioned cloud resources, which is the same problem in a different namespace.

Frequently asked questions

Can anyone claim a deleted S3 bucket name?

Yes. Bucket names are globally unique while in use and become immediately available once deleted. There is no reservation period and no record of prior ownership, so the name is first come, first served.

What is the risk if my code still points at a deleted bucket?

It depends on direction. If your systems write to it, an attacker who claims the name receives that data. If your systems read from it, they control what is served to you, which can mean supplying code or configuration that you execute.

How do I prevent bucket hijacking entirely?

Keep the name. Empty the bucket rather than deleting it, so the name can never be claimed by anyone else. Retaining an empty bucket costs almost nothing and is the only complete mitigation.

Do I need my own AWS account to practice this?

No. The lab runs in a live AWS environment that Pwned Labs provisions for you, so there is nothing to set up and no risk to your own infrastructure.

Which certification covers this in depth?

The Amazon Cloud Red Team Professional (ACRTP) covers AWS attack paths including resource takeover and privilege escalation, and is assessed hands-on in a live AWS account.