🛡️ Methodology Checklist
- Identify cloud provider (AWS/Azure/GCP) from DNS CNAMEs and HTTP headers
- Enumerate S3/Azure Blob/GCS buckets: GrayhatWarfare, bucket brute-force
- Test bucket for public access:
aws s3 ls s3://[BUCKET] --no-sign-request - Check for misconfigured ACLs (ListBucket, GetObject without auth)
- Enumerate cloud metadata endpoint if instance access:
169.254.169.254 - Search for storage URLs exposed in JS/source code
- Document all cloud assets found for scope clarification
🎯 Operational Context
Think Dumber First: Check for S3 buckets, Azure Blob Storage, and GCP buckets with common naming patterns:
[company]-backup,[company]-dev,[company]-files. Many are world-readable or even world-writable.aws s3 ls s3://[BUCKET] --no-sign-requesttests anonymous access. Cloud misconfigs are often the fastest path to sensitive data.
When you land here: Target uses cloud infrastructure. Check DNS CNAMEs for cloud provider hints. Test unauthenticated access to storage buckets. Check for exposed environment variables, API keys in JavaScript source, and public-facing serverless functions.
⚡ Tactical Cheatsheet
| Command | Tactical Outcome |
|---|---|
host [SUBDOMAIN] | Resolve subdomain — look for CNAME pointing to cloud provider domains |
intext:[Company] inurl:amazonaws.com | Google dork — find exposed S3 buckets |
intext:[Company] inurl:blob.core.windows.net | Google dork — find exposed Azure blobs |
🔬 Deep Dive & Workflow
Core Concept
Cloud providers (AWS, Azure, GCP) are essential for centralized management but introduce new attack surfaces. The infrastructure is secured by the provider — the configuration is the administrator’s responsibility.
Common Vulnerability: Misconfigured storage (S3 Buckets, Azure Blobs) with unauthenticated public access.
Discovery Methods
1. DNS & IP Analysis Cloud storage is often linked to company subdomains. Look for CNAME records or IPs resolving to:
s3-website-us-west-2.amazonaws.comblob.core.windows.net
2. Google Dorking (Passive)
| Provider | Dork | Target |
|---|---|---|
| AWS | intext:[Company] inurl:amazonaws.com | S3 Buckets, public files |
| Azure | intext:[Company] inurl:blob.core.windows.net | Azure Blobs, documents |
3. Source Code Inspection
Developers offload static assets to cloud. View Page Source (Ctrl+U) and search for links to:
blob.core.windows.netin<link>or<script>tags
Specialized Tools
- GrayHatWarfare: Searchable database of public cloud storage. Filter for sensitive file extensions.
- Domain.Glass: “Identity Card” of the domain — identifies Cloudflare protection and other infra details.
High-Value Findings
When exploring buckets, look beyond PDFs:
- SSH Keys:
id_rsa/id_rsa.pub— server access without passwords. - Backups: Database dumps or source code archives.
- Admin Files: Presentations, internal codes, sensitive employee data.
🛠️ Troubleshooting & Edge Cases
| Problem | Cause | Fix |
|---|---|---|
| S3 bucket name unknown | Cannot guess bucket name | Try [company]-[env] patterns; use cloud_enum tool; check HTML source for S3 URLs; check JS files for bucket references |
| aws s3 ls returns ‘Access Denied’ | Bucket exists but private | This is actually correct security — document that bucket is private; still note bucket exists as potential finding |
| GCP/Azure storage enumeration returns no results | Wrong naming convention or tool | For Azure: https://[name].blob.core.windows.net/[container]?comp=list; for GCP: https://storage.googleapis.com/[bucket] |
| API keys found in JavaScript source | Exposed in client-side code | Test key immediately; even if read-only this is a Critical finding; document scope of access the key provides |
| Cloud resource found but no data accessible | Correct ACL configuration | Document discovery of cloud resource; test for metadata service access if EC2 instance is found (169.254.169.254) |
📝 Reporting Trigger
Finding Title: Publicly Accessible Cloud Storage Bucket / Exposed Cloud API Credentials Impact: Unauthenticated read (or write) access to cloud storage — potential data exfiltration of backups, exports, PII, or internal files. Exposed API keys enable programmatic access to cloud resources. Root Cause: S3/Blob/GCP bucket ACL misconfigured to public access. API keys hardcoded in client-side JavaScript or HTML source. Recommendation: Enable S3 Block Public Access at account level. Audit all storage bucket ACLs. Rotate exposed API keys immediately. Implement secrets scanning in CI/CD pipeline. Use IAM roles instead of static API keys.