Cloud Bucket Finder (S3, GCS, Azure)

Overview

Cloud storage leaks are almost never a breach. Somebody made a bucket for one migration, loosened the policy to unblock a deploy, and moved on. The data sits there indefinitely, and the only thing standing between it and the internet is that nobody has guessed the name. Names are guessable, because they are made of your company name and words like backup, assets and staging.

This guesses them the way an attacker would and tells you which ones exist and which are readable without credentials. You get the provider, the bucket, and its access state, which is the whole finding. Running it on a schedule catches the bucket created next quarter, which is the point: this is exposure management, not a one-time audit.

Every check is anonymous. Nothing here needs cloud credentials, in your account or anyone else's.

Pipeline

1. Read the keyword and the target domain.
2. Candidate bucket names are generated by permuting the keyword with common environment, function and date affixes.
3. Each candidate is checked anonymously across S3, Google Cloud Storage, Azure Blob and DigitalOcean Spaces, distributed across the fleet.
4. s3scanner corroborates the S3 results and adds permission detail.
5. Buckets that exist are reported with their access state in a PDF.

Inputs

• Keyword. The brand or company token that gets permuted into candidate bucket names. The safe default is example, the reserved documentation name, so an unedited run probes nothing that belongs to you or anyone else. Put your own company token here.
• Domain. Optional. Its label seeds extra candidates alongside the keyword. The safe default is example.com, matching the keyword default.
• Candidate cap. A guard rather than a dial. Generation stops at 800 names per run, which keeps a public workflow from turning into an unbounded sweep. The mutation wordlist is fetched at run time, so it is not frozen into the graph.

Outputs

• A PDF report with publicly readable buckets ranked first, then the full inventory grouped by provider, then the methodology.
• A per-candidate record carrying the bucket name, the provider, the access state, and the HTTP status behind it, so public, exists but private and does not exist stay distinguishable.
• The s3scanner pass over the same candidate list, flagging which public S3 buckets both detectors agree on.

Sample output

From a completed run against the keyword example.

Each candidate is checked per provider and the result records the access state, not just existence:

bucket	provider	access	severity	http_status
example-com	aws-s3	exists (private)	info	403
example-com	gcs	public	high	200
example-com-backups	aws-s3	public	high	200
trickest-com	aws-s3	exists (private)	info	403
trickest-com	azure	not found	info	404
example-media	gcs	exists (private)	info	403

The same name can exist on more than one provider with different permissions, which is exactly the case worth catching. Here the S3 bucket denies anonymous access and the Google Cloud bucket of the same name does not, so a team that verified their S3 configuration and stopped there would have missed it.

FAQ

Do I need cloud credentials to run this?

No. Every probe is an unauthenticated request, the same one any stranger on the internet can make. That is the point: the result tells you what the internet sees without your account in the way.

How does it decide a bucket is public?

By the provider's own answer to an anonymous list request. A 200 with a listing is public, a 403 means the bucket exists and denies you, and a 404 or a DNS failure means the name is unused. The access state is recorded per provider.

Does it download anything out of a public bucket?

No. The run records that a bucket exists and whether it lists anonymously, and stops there. It never reads object contents and never writes. Exposure, not exfiltration.

How many names does it try per run?

Up to 800. Candidates come from permuting your keyword and domain against a mutation wordlist fetched at run time, and the cap is fixed so the workflow cannot become an internet-wide sweep.

Can I point it at a company I do not own?

Enumerating a third party's storage can breach a provider's terms. Run it against your own assets, or under a scope that explicitly covers the target.

Related workflows

• Scan GitHub for Leaked Secrets. Reach for this instead when the leak you expect is a credential committed into code rather than an object sitting in open storage.
• Find Secrets in Wayback Responses. Reach for this instead when the bucket URLs are probably already recorded in archived pages, which makes mining the archive cheaper than guessing names.
• Find Exposed Databases. Reach for this instead when the unauthenticated store you are hunting is a running service on a port rather than a bucket behind a provider API.