Reveal Hidden Files in Google Storage

What this lab covers

You work with a Google Cloud Storage bucket that will not reveal its contents, discover objects by name anyway, and recover material that was assumed to be hidden.

The lab targets a specific and widespread misunderstanding. Teams disable listing and consider the problem solved, when the meaningful question is whether anonymous or broad read access remains.

It assumes no prior Google Cloud experience and introduces the CLI alongside ordinary web content discovery technique.

How object discovery without listing works

Cloud Storage separates the permission to list a bucket's contents from the permission to read an object. A bucket configured so that listing is denied while reading is allowed will refuse to enumerate and will happily serve any object whose name is supplied.

Names are more guessable than teams expect. Files follow conventions, carry predictable extensions, and are frequently referenced elsewhere: in application source, in HTML, in documentation, in error messages and in search engine results. Wordlist-driven discovery against a known bucket is fast.

Bucket names themselves share a global namespace and follow organizational conventions, so discovering the bucket is often the same exercise one level up. Neither step relies on a vulnerability.

How to detect this in your own environment

Enable data access logging on Cloud Storage, which is not on by default. Without it, reads of objects, including anonymous ones, leave no record you can query afterwards.

Look for large numbers of not-found responses against a bucket, which is the signature of name guessing. This is one of the clearest cases where failures are more informative than successes.

Alert on changes to bucket IAM policy and on public access being granted, since these are the configuration events that create the exposure.

How to prevent it

Use uniform bucket-level access and remove anonymous read entirely. Relying on obscure object names is not access control, and the fix is to require an identity rather than to make names harder to guess.

Apply the public access prevention organization policy so buckets cannot be made public even by mistake. This is the equivalent of block public access elsewhere and is the control that holds when a policy is written carelessly.

Use signed URLs with short expiry where a specific object must be shared externally, so access is scoped to one object for a limited period rather than granted at the bucket level.

Real-world context

Object storage exposure is one of the most consistently reported cloud data incident categories across every provider, and the underlying cause is nearly always a permission granted to solve an immediate delivery problem.

The listing misconception is a recurring aggravating factor. Organizations respond to an exposure by disabling listing, treat the finding as closed, and remain fully readable to anyone with the object names, which are frequently recoverable from their own website.

The pattern maps to MITRE ATT&CK T1530 Data from Cloud Storage Object and T1580 Cloud Infrastructure Discovery.

Applying this at work

• Apply the public access prevention organization policy across your projects.
• Enable uniform bucket-level access and review which buckets permit anonymous read regardless of listing.
• Turn on data access logging for buckets holding anything sensitive.
• Check whether object names are referenced in your public web content, which removes the need for guessing entirely.
• Replace long-lived public objects with signed URLs scoped to a single object and a short expiry.

Frequently asked questions

Does disabling bucket listing protect my data?

No. It prevents enumeration of contents, not retrieval. If read access remains, any object can be fetched by anyone who knows or guesses its name, and names are often recoverable from your own application or documentation.

How are object names discovered?

Through naming conventions, wordlists, references in application source and HTML, documentation, and search engine indexing. Discovery is a content enumeration exercise rather than an exploit.

What is public access prevention?

An organization policy that stops buckets being made publicly accessible regardless of their individual IAM configuration. It is the control that holds when a permission is granted carelessly.

Do I need my own Google Cloud account to practice this?

No. The lab runs in a live Google Cloud environment that Pwned Labs provisions for you, so there is nothing to set up and no risk to your own project.

Which certification covers this in depth?

The Google Cloud Red Team Professional (GCRTP) covers Google Cloud and Google Workspace attack paths in full, including service account abuse and privilege escalation, and is assessed hands-on in a live Google Cloud environment.