Post cover image

July 15, 2026

How a Simple S3 Bucket Misconfiguration Turned into a Security Assessment

“Every bug hunter dreams of finding that one small clue that leads to something much bigger.”

By sunny561

2 min read

"Every bug hunter dreams of finding that one small clue that leads to something much bigger."

Every potential security finding story starts with the Reconnaissance.

Whenever someone asks me:

"What do you do if you find an S3 bucket during reconnaissance?"

Most people reply:

"If it's private, move on."

I don't. I keep digging.

Because in bug bounty hunting, gold is rarely sitting on the surface.

And this story starts exactly there

Recon

Finding S3 buckets isn't difficult. Finding interesting S3 buckets is.

There are dozens of reconnaissance techniques, but these are the ones I use most frequently.

Google Dorking for AWS S3 Buckets

Let's start with the google , basic and simple

you can use the following dork to find open s3 buckets:

site:s3.amazonaws.com "target.com"
site:*.s3.amazonaws.com "target.com"
site:s3-external-1.amazonaws.com "target.com"

Search for S3 URLs in JavaScript Files

This is probably my favorite technique.

Modern web applications constantly interact with cloud storage.

Developers often hardcode S3 URLs inside JavaScript bundles.

Search through:

  • main.js
  • bundle.js
  • app.js
  • vendor.js

You'll frequently find references like:

https://company-assets.s3.amazonaws.com/

or

const bucket = "company-backups";

Tip: S3 URLs hidden in JavaScript are one of the easiest ways to expand your attack surface.

S3 Buckets from GitHub Repositories

Public repositories can accidentally expose S3 bucket names, AWS configurations, or even credentials.

Useful GitHub dorks include:

org:target "amazonaws"
org:target "bucket_name"
org:target "aws_access_key"
org:target "aws_access_key_id"
org:target "aws_key"
org:target "aws_secret"
org:target "aws_secret_key"
org:target "S3_BUCKET"

Time to Test the Bucket

ow comes the interesting part.

Finding a bucket means nothing.

Testing it properly is where the real assessment begins.

list the contents of an Amazon S3 bucket

The very first test is checking whether anonymous users can list its contents.

aws s3 ls s3://bucket_name --no-sign-request

Expected output if it is publicly accessible

2026-06-15 09:10:32       1024 index.html
2026-06-15 09:11:01      45231 backup.zip
PRE images/

If the bucket is private, The expected output as AccessDenied

An error occurred (AccessDenied) when calling the ListObjectsV2 operation: Access Denied

Why — no-sign-request ?

Without :

--no-sign-request

Normally, the AWS CLI:

  • looks for AWS credentials,
  • signs every request using AWS Signature Version 4,
  • sends the authenticated request.

With:

--no-sign-request

the CLI:

  • does not use any credentials,
  • does not sign the request,
  • sends it as an anonymous (public) request.

Can Anyone Upload Files?

Test for missing write permissions, we can use the following command

aws s3 cp file.txt s3://[bucketname] --no-sign-request

If this succeeds, the bucket is publicly writable.

Can Anyone Download Everything?

We can also the all the objects in the s3 bucket using following command

aws s3 cp s3://[bucketname]/ ./ --recursive --no-sign-request

This recursively downloads every accessible object.

Can Anyone Delete Files?

We can remove the objects from the S3 Bucket

aws s3 rm s3://[bucketname]/file.txt --no-sign-request

If deletion succeeds, attackers could remove production assets or destroy valuable data

Review the Bucket Policy If you possess valid AWS credentials with sufficient permissions, you can inspect additional bucket settings.

aws s3api get-bucket-policy --bucket bucket-name --no-sign-request

This reveals who can access the bucket and under what conditions.

Check bucket encryption

we can review whether server-side encryption is configured.

aws s3api get-bucket-encryption --bucket bucket-name --no-sign-request

Check bucket versioning

We can review whether versioning is enabled or suspended.

aws s3api get-bucket-versioning --bucket bucket-name --no-sign-request

read permissions on Access Control Lists (ACLs)

These ACLs can also have misconfigured access controls and allow malicious actors to request them, essentially allowing them to take a shortcut and easily enumerate any storage buckets or objects with misconfigured access controls

aws s3api get-bucket-acl --bucket bucket-name --no-sign-request

Final Thoughts

S3 bucket testing isn't about running a single AWS CLI command.

It's about understanding how the bucket is configured, what data it contains, and how an attacker might abuse overly permissive access.

Many critical findings begin with a simple question:

"What happens if I don't stop at AccessDenied?"

The best security researchers don't just look for open buckets — they assess the entire storage configuration, validate permissions, and think like an attacker.

In many bug bounty programs, that extra curiosity is what separates an informational finding from a high-impact vulnerability.

Happy Hacking