Before running a single scanner, a researcher opens bucket-stream, connects to certstream, and within minutes has a list of S3 buckets derived from the target company's subdomains. No packet was sent to the target. No log was written to the SIEM.
Most security teams treat bucket exposure as a configuration problem fixed with a click on "Block Public Access". That assumption misses the point: even with Block Public Access enabled, the discovery phase through CT logs is unaffected -- it runs before any permission check. Attackers treat it as a passive discovery problem, and have already mapped your assets through CT logs and GrayhatWarfare before making the first API call. That difference in perspective is why S3 incidents keep happening even at companies with formal cloud security policies.
Prerequisites: Python 3 + pip (bucket-stream), AWS CLI, gsutil (GCS), az CLI (Azure). Basic knowledge of DNS and cloud storage naming conventions.
CT Logs Are Your Company's Public Bucket Directory
Any TLS certificate issued for company domains -- such as backup.acme.com or cdn.acme.com -- appears in CT logs through certstream. bucket-stream extracts naming components from those domains and generates bucket name permutations to test: acme-backup, backup-acme, cdn-acme. The bucket itself never needs its own certificate; it's the company's operational domains that expose the naming convention.
