AWS S3 Enumeration Basics

What this lab covers

You use the AWS command line to discover storage, establish what your access permits against it, and retrieve what is there, including material that should never have been reachable.

This is the foundational S3 lab and most other AWS paths pass through it at some point. Getting comfortable with the difference between listing a bucket, reading an object and having no access at all is what makes later labs legible.

It assumes no prior AWS experience and is a sensible starting point if you are new to cloud security entirely.

How S3 enumeration works

Bucket names are globally unique across all AWS accounts, which has an underappreciated consequence: a name either exists or it does not, and anyone can test that. Because organizations name buckets predictably, from company name, environment, application and function, candidate names can be generated and tested at scale.

Access is layered. A bucket may permit anonymous listing, anonymous reading of specific objects, both, or neither, and these are separate permissions. Listing reveals the inventory, reading retrieves content, and an attacker who can list has a map while one who can only read must already know the object key.

Authenticated access changes the picture again. Credentials that appear low-privilege often permit listing across many buckets, and the value of enumeration is in identifying which of those buckets hold configuration, backups or credentials that lead somewhere else.

How to detect this in your own environment

Anonymous access to a public bucket is not recorded in CloudTrail management events. You need S3 server access logging or data events to see it at all, and neither is enabled by default, which is why organizations discover public bucket exposure from researchers rather than from their own logs.

For authenticated access, watch for principals listing buckets they have never touched. A workload identity typically interacts with a small fixed set of buckets, so breadth is the anomaly rather than volume.

Look for failed access attempts across many bucket names, which indicates enumeration against your account rather than reconnaissance of a name space. This requires failures to be retained in your logging pipeline.

How to prevent it

Enable account-level block public access. It overrides bucket policies and access control lists, and for the large majority of buckets there is no legitimate reason for it to be off.

Do not grant the list permission where read is sufficient. Applications almost always know the object key they need, so listing is granted out of habit and it is what converts a narrow exposure into a complete inventory.

Avoid predictable bucket naming for anything sensitive. Obscurity is not a control on its own, but combined with correct permissions it removes the cheap discovery path that makes bulk enumeration worthwhile.

Real-world context

Publicly readable buckets have been behind a long series of disclosed data exposures, and bucket enumeration remains a standard first step in external cloud assessment. The recurring cause is a permission granted to make something work rather than any subtle flaw.

Automated scanning for readable buckets runs continuously at internet scale, so the practical question is not whether an exposed bucket will be found but how quickly. Obscure names buy very little time.

The activity maps to MITRE ATT&CK T1580 Cloud Infrastructure Discovery and T1530 Data from Cloud Storage Object.

Applying this at work

• Enable account-level block public access everywhere it is not a documented, deliberate exception.
• Review which identities hold the list permission and remove it where only read is required.
• Enable S3 data events or server access logging on buckets holding anything sensitive, so access is visible at all.
• Run a bucket name enumeration against your own naming convention and see what a stranger would find.
• Confirm failed access attempts survive your log pipeline, since they are the signal for enumeration against you.

Frequently asked questions

How are S3 buckets discovered if they are not listed anywhere?

Bucket names are globally unique, so any name can be tested for existence. Organizations name buckets predictably from company, environment and application names, which makes generated wordlists effective.

What is the difference between listing and reading a bucket?

Listing returns the inventory of object keys. Reading retrieves a specific object and requires knowing its key. They are separate permissions, and granting listing turns a narrow exposure into a complete one.

Is anonymous access to a public bucket logged?

Not by default. It does not appear in CloudTrail management events, so you need S3 data events or server access logging enabled. Without them, public bucket access is invisible to you.

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