Loot Public EBS Snapshots

What this lab covers

You enumerate what a set of AWS credentials can reach, discover snapshots that were shared more widely than intended, and recover their contents to demonstrate the impact.

The path runs through several ordinary AWS services rather than any single flaw, which is what makes it realistic. Each step is a permitted action performed by an identity that was allowed to perform it.

The lab closes on mitigation, because the interesting question is not how to read a public snapshot but why an organization would ever have one and how to find yours before somebody else does.

How public EBS snapshot exposure works

EBS snapshots are point-in-time copies of block storage volumes. They are created constantly, by backup automation, before maintenance, and as part of building machine images, and they persist independently of the volume they came from.

A snapshot has permissions of its own. It can be private, shared with named AWS accounts, or public. Public means readable by any AWS account, and because snapshots are regional and enumerable, they can be discovered systematically rather than guessed.

The exposure is usually accidental. Building a public machine image can leave the underlying snapshot public, and a snapshot shared temporarily for a migration is rarely unshared afterwards. Because a snapshot is a disk image rather than a file, what leaks is not one document but everything: application configuration, private keys, database contents, credential files and command history.

How to detect this in your own environment

Query for public snapshots directly and repeatedly. Listing snapshots filtered by public permission across every region you operate in takes seconds and should be a scheduled check, not a one-off audit. Regions you do not use are exactly where a forgotten snapshot survives.

Alert on the permission change rather than the state. The API call that modifies snapshot attributes is recorded in CloudTrail, so an alert on any snapshot being made public catches the mistake at the moment it happens rather than at the next audit.

Watch for copy activity by accounts outside your organization. When an external account copies your snapshot, that is visible to you, and it is one of very few signals that an exposure has actually been used.

How to prevent it

Use the account-level block public access setting for EBS snapshots. This is a single control that prevents any snapshot in the account from being made public, and for most organizations there is no legitimate reason not to enable it everywhere.

Treat snapshot sharing as a time-bound action. If a snapshot must be shared with a partner account, record why and set a date to revoke it, because sharing that persists past its purpose is where most exposure comes from.

Encrypt volumes by default. An encrypted snapshot cannot be shared publicly at all, which turns an encryption control into an exposure control, and it removes the possibility of the mistake rather than relying on catching it.

Real-world context

Public snapshot exposure was brought to wide attention by research presented at DEF CON 27 in 2019, More Keys Than A Piano: Finding Secrets In Publicly Exposed EBS Volumes, which showed that a systematic sweep of public EBS snapshots surfaced credentials, private keys and proprietary source code belonging to real organizations.

The pattern has not gone away, because the underlying cause is operational rather than technical. Snapshots are created by automation that outlives the people who configured it, and nothing about a public snapshot degrades or expires on its own.

It maps to MITRE ATT&CK T1580 Cloud Infrastructure Discovery and T1530 Data from Cloud Storage Object. It is best understood as a data exposure problem with an identity component rather than a vulnerability.

Applying this at work

• Enable block public access for EBS snapshots at the account level, in every account and every region.
• Run a cross-region inventory of snapshots with public permissions today, then schedule it monthly.
• Add a CloudTrail alert on snapshot permission modification.
• Enable EBS encryption by default, which prevents public sharing outright.
• Review snapshots shared with external account identifiers and revoke any whose purpose has passed.

Frequently asked questions

Can anyone find a public EBS snapshot?

Yes. Public snapshots can be listed by any AWS account using standard API calls, filtered by region. They do not need to be guessed or brute forced, which is why exposure is discovered systematically rather than by chance.

What actually leaks in a snapshot?

Everything that was on the volume, including files that had been deleted but not overwritten, shell history, configuration files, private keys and any credentials stored on disk. It is a disk image, not a file share.

How do public snapshots happen by accident?

Most commonly by building a public machine image without realising the underlying snapshot inherits public visibility, or by sharing a snapshot for a migration or support case and never revoking it.

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 data exposure and privilege escalation paths in full, and is assessed hands-on in a live AWS account.