Cloud Storage Enumeration

Why Cloud Enumeration Matters

Cloud platforms such as AWS, Azure, and Google Cloud are core parts of modern infrastructure. While providers secure the underlying platform, customer misconfigurations still create real exposure paths.

One of the most common issues is publicly accessible object storage:

• AWS S3 buckets
• Azure Blob containers
• Google Cloud Storage buckets

If access policies are too permissive, sensitive files can be discovered and downloaded without authentication.

Initial Discovery Through DNS

A fast first step is to resolve known subdomains and look for cloud-hosted endpoints.

for i in $(cat subdomainlist); do
	host "$i" | grep "has address" | cut -d" " -f1,4
done

When storage endpoints appear in DNS records (for example, s3-website-*.amazonaws.com or blob.core.windows.net), they often indicate externally reachable cloud assets tied to the target.

Google Dorking for Public Cloud Files

Search engines frequently index publicly accessible files hosted in cloud storage. A few focused queries can surface PDFs, backups, and mispublished documents.

Platform	Example Query
AWS S3	intext:"company" inurl:amazonaws.com
Azure Blob	intext:"company" inurl:blob.core.windows.net
GCP Storage	intext:"company" inurl:storage.googleapis.com

Use organization name variants and abbreviations to improve results. In real environments, teams often use short internal naming schemes rather than full company names.

Source Code and Third-Party Intelligence

Public web apps often reference cloud assets directly in HTML, JavaScript, or CSS. Reviewing page source and frontend bundles can reveal storage hostnames and bucket paths.

Additional passive intelligence can be gathered from:

• Domain.glass for DNS, certificate, and infrastructure context
• GrayHatWarfare for indexed public bucket/object discovery

These sources help map cloud exposure without active interaction against target infrastructure.

High-Risk Findings to Prioritize

When public storage is discovered, prioritize high-impact data types:

• Private keys (id_rsa, *.pem, *.pfx)
• Environment files (.env)
• Backups (.zip, .sql, .bak)
• Internal documents and architecture diagrams
• Credential exports and access tokens

Exposed SSH private keys are especially critical because they may allow direct infrastructure access if still valid.

Practical Workflow

1. Collect target domains and subdomains.
2. Resolve DNS and identify cloud-related hostnames.
3. Run targeted search engine dorks for known naming patterns.
4. Inspect site source code and static assets for cloud references.
5. Correlate findings in passive intelligence platforms.
6. Validate exposure scope and report impact with evidence.

Key Takeaways

1. Cloud provider security does not prevent customer-side misconfiguration.
2. Public object storage is a frequent source of data leakage.
3. Passive discovery methods can reveal significant exposure quickly.
4. File-type prioritization helps focus on business-critical risk.
5. Testing should always be authorized and documented.