vulns.co
/
mcp by GKData.io

Back to Playbooks

Cloud storage and public object hunting

Public buckets still pay, but only after you prove ownership. DNS, TLS SAN, response body, or a billing alias. Guessing a brand name is recon, not a report.

Tags: cloud, s3, secrets, ssrf

Level: intermediate

Method

  1. Name the org

    Company legal name, product codes, TLS SANs, JS config buckets, mobile APK endpoints, terraform leftovers in GitHub.

    Tools: httpx, trufflehog

  2. Enumerate candidates

    cloud_enum / s3scanner / gcp/azure equivalents from keywords you already attributed. Do not spray the whole internet.

    python3 cloud_enum.py -k {keyword} -t 10 -l cloud.txt

    Tools: cloud_enum, s3scanner

  3. Prove it is theirs

    CNAME to the bucket, object that contains their JS/CSS, policy doc, or an error that names the account. No ownership, no report.

    Tools: httpx, tlsx

  4. Read vs list vs write

    GET a non-secret object you can justify. LIST if the program allows. PUT only an inert canary object you will delete, and only if write is in scope.

    Tools: httpx

  5. Secrets in objects

    Config JSON, .env, heap dumps, terraform state. Download only what you need to prove, redact, delete local copies.

    Tools: trufflehog, gitleaks

Field notes

  • A public marketing PDF in an S3 bucket is not a finding. A customer export or AKIA key is.
  • IMDS via SSRF is a different playbook (ssrf-hunting). Do not mix them unless you chained them.

References

Back to Playbooks