How attackers discover cloud storage bucket names

The mental model that keeps teams from fixing open buckets is the idea that a name is a secret. "Our bucket isn't guessable. Nobody knows it's called acme-prod-media-2019." That's not how it plays out. Bucket names are leaked constantly through entirely ordinary software development activity, and the attackers who find them aren't guessing blind. They're looking in the same places your name ended up.

Naming patterns and why they're predictable

S3 bucket names must be globally unique across every AWS account. That constraint, plus the need for names to be memorable and self-documenting, pushes teams toward the same vocabulary: company name, environment, and purpose. The resulting names follow a short list of templates:

• <company>-<env>-<purpose> → acme-prod-assets, acme-staging-uploads
• <company>-<purpose>-<year> → acme-backups-2022, acme-terraform-state
• <env>-<company>-<purpose> → prod-acme-media, dev-acme-static
• Abbreviated forms → acme-prd-tls, acme-dr-bak

Permutation-based discovery tools work by generating combinations of a target company name with common environment prefixes, purpose suffixes, and separators, then probing the provider's API for each. Against a target with a common name (or one that follows predictable conventions), the yield is real.

No custom tooling is required. Wordlists for cloud storage enumeration are maintained as open-source projects and work against S3, GCS, and Azure Blob endpoints. An attacker searching for acme-backups will also try acme-bkp, acmebackups, backup-acme, and a few dozen variations.

Public indexes already catalogued the names

The more efficient path isn't wordlist brute-force: check whether someone has already found the bucket. GrayhatWarfare is the most widely used public index of open cloud storage buckets, with millions of entries spanning S3, Azure Blob, and GCS. The search interface lets an attacker query by keyword, company name fragment, or content type. If your bucket was ever open and indexed, it appears here alongside its object count and content summary.

GrayhatWarfare indexes content discovered from open listings, so a bucket that was publicly listable for even a short window can end up in the index long after the listing was closed. The record of its existence and some of its contents persists in the index even after the misconfiguration is fixed.

That's the asymmetry worth internalizing: opening a bucket for a day can produce a permanent discovery artifact. The fix closes the bucket, not the record of what was in it.

Leaked references in application artifacts

Bucket names appear in a surprising number of places outside infrastructure tooling:

Client-side JavaScript. Modern front-end applications make authenticated or signed requests directly to object storage for uploads and downloads. The bucket endpoint (https://<name>.s3.amazonaws.com or the equivalent) appears as a string literal or a configuration value in the compiled JavaScript bundle. Bundles are public by definition if they're served from a web application, and static analysis tools that extract URLs from JavaScript are standard attacker kit.

Source code repositories. Configuration files committed to version control carry bucket names. Even after the file is removed from the current branch, it persists in git history. A git log -p --all or the GitHub code search surface will surface it. Public forks compound the exposure: if a repository was public at any point before an organization moved it private, forks made during that window retain the history.

The Wayback Machine and crawl archives. Archived versions of web applications often contain inline script references, configuration endpoints, or error messages that expose storage bucket names. The Internet Archive's Wayback Machine is commonly queried during reconnaissance; other crawl archives serve similar roles. An infrastructure rename does not scrub what crawlers already have.

Infrastructure-as-code in public repos. Terraform, CloudFormation, and Kubernetes manifests stored in public repositories are a direct leak source. The variable values and resource names that configure object storage buckets are often committed alongside the code, not stored in a secrets manager. A targeted search on GitHub for aws_s3_bucket paired with a company domain or product name regularly returns live configuration.

DNS CNAME records. When a bucket backs a custom domain (media.acme.com is a CNAME to acme-prod-media.s3.amazonaws.com), the bucket name is publicly discoverable via a DNS lookup. Certificate transparency logs surface the custom hostname itself (media.acme.com), not the bucket. A DNS resolution of that hostname then exposes the s3.amazonaws.com CNAME target: the bucket name. This is a reliable discovery path for buckets behind CDNs that preserve the S3 origin hostname as the CNAME value.

The practical implication: names are not access control

Enumeration is worth understanding, but not because it should drive a paranoid naming strategy. Obscure bucket names don't solve the problem. They slow down a scanner by a few minutes at best.

The access control is the fix. A correctly configured bucket rejects unauthenticated listing and download requests regardless of whether the requester knew the name through a wordlist hit, a GrayhatWarfare search, a JavaScript bundle, or a git history scan. A publicly listable bucket is fully accessible regardless of how unmemorable its name is.

The diagnostic question isn't "is our bucket name guessable?" It's "does our bucket reject unauthenticated requests?" Enumeration resistance is a secondary control at best. Public-access settings and IAM policy are what protect the data.

For both AWS S3 and S3-compatible stores: enable Block Public Access at the account level, audit bucket policies for "Principal": "*" without a Condition clause, and confirm no ACL grant to AllUsers or AuthenticatedUsers exists. See the remediation checklist for the full procedure. If you've found a bucket name via any of the vectors above and want to verify whether it's actually open, use the open-bucket viewer: it runs the unauthenticated listing probe without requiring credentials.

For an index of exposed S3 buckets found and tracked by this service, see the AWS S3 exposure index. To probe a specific bucket URL right now, use the open-bucket viewer.