Buckets and Public Storage

Object storage (S3 on AWS, Blob on Azure, Cloud Storage on GCP) is one of the most used cloud services and, due to lax configurations, one of the biggest sources of data leaks in recent history. A misconfigured bucket can expose backups, databases, credentials, source code, and personal data to anyone with the URL. Discovering and assessing buckets is almost mandatory in every cloud pentest.

The problem

Buckets can be configured for public access (read, list, and even write). Historically public access has been easy to enable by mistake, and predictable names (company-backups) make them easy to find. Result: countless breaches from open buckets (Verizon, Accenture, Capital One, and a long etcetera).

Discover buckets

# name patterns to try
target, target-backups, target-dev, target-prod, target-assets, target-logs...
# discovery tools
cloud_enum -k target          # S3 + Azure Blob + GCS at once
s3scanner scan -f buckets.txt
# search engines for already-indexed buckets
GrayhatWarfare (buckets.grayhatwarfare.com)
# Google dorking (see recon-dorking)
site:s3.amazonaws.com target

Check access (AWS S3)

# list the contents (if public listing is allowed)
aws s3 ls s3://<bucket> --no-sign-request
curl https://<bucket>.s3.amazonaws.com/            # lists XML if public
# download everything
aws s3 sync s3://<bucket> ./loot --no-sign-request
# write? (very serious: upload files, webshell, defacement)
aws s3 cp test.txt s3://<bucket>/ --no-sign-request
# bucket permissions/ACL
aws s3api get-bucket-acl --bucket <bucket> --no-sign-request

--no-sign-request tests anonymous access. Anonymous write access is critical (content poisoning, malware hosting).

Azure Blob and GCS

# Azure Blob
https://<account>.blob.core.windows.net/<container>?restype=container&comp=list
# GCS
gsutil ls gs://<bucket>              # if public
curl https://storage.googleapis.com/<bucket>

What to look for inside

# the juiciest
backups (.sql, .bak), .env, config, keys (.pem, id_rsa, service-account.json)
source code, DB dumps, personal data, logs with secrets
# after downloading, search for secrets
grep -rniE 'password|secret|api_key|AKIA' ./loot
trufflehog filesystem ./loot

Beyond listing: other vectors

Public snapshots/EBS, public AMIs, shared RDS snapshots → exposed data without being “buckets”.
Subdomain takeover if a CNAME points to a no-longer-existing bucket (see Subdomain takeover).
Overly open bucket policies (not just ACLs): Principal: *.

For the defense

Block Public Access at the account level (AWS) / public access disabled by default (Azure/GCP).
Minimal policies and ACLs: never Principal: * or AllUsers; review with tools (Prowler/ScoutSuite flag public buckets).
Encryption at rest, versioning, and access logging (S3 access logs / CloudTrail data events).
Don’t put secrets in buckets; use secret managers. Unpredictable names are not a defense.
Monitor anonymous access and policy changes; remediate public snapshots/AMIs.

Testing checklist

Discover buckets by patterns and tools (cloud_enum/GrayhatWarfare)
Test anonymous listing (—no-sign-request / curl)
Download content and search for secrets (trufflehog)
Test anonymous write (critical)
Review bucket ACLs and policies
Azure Blob and GCS equivalents
Public snapshots/AMIs/RDS
Subdomain takeover via nonexistent bucket (Subdomain takeover)