report.json contains the same findings in machine-readable form for export / SIEM pipelines.
S3 Corroboration
s3scanner independently scans the same candidate list for open S3 buckets — a second detector for the AWS branch.
The report flags which public S3 buckets both tools agree on, increasing confidence in the finding.
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
Read the keyword and the target domain.
Candidate bucket names are generated by permuting the keyword with common
environment, function and date affixes.
Each candidate is checked anonymously across S3, Google Cloud Storage, Azure
Blob and DigitalOcean Spaces, distributed across the fleet.
s3scanner corroborates the S3 results and adds permission
detail.
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.