Object Storage Enumeration Detection: A Review Method

The cheapest early-warning system for exposed object storage is a request log you already have. Before an attacker can read a bucket, they have to find it, and finding it leaves traces: bursts of anonymous requests, sequences of HEAD and GET calls against guessed names, and clusters of 403 and 404 responses from addresses that match no known client. A review built around object storage enumeration detection catches exposure while it is still being probed instead of after the data is gone.

The method works on two planes at once. First, verify that the platform-wide controls against public access are actually enforced at the highest scope you manage. Second, read the request plane for evidence that strangers are already testing your storage names. The enforcement side is well documented: when block public access configurations differ across scopes, Amazon S3 enforces the most restrictive combination of the access point, bucket, account, and organization settings, so an organization-level policy keeps protecting a bucket even after someone disables the bucket-level switch. The request side is where most teams still fly blind, and it is the half this method is designed to fix.

Why logs catch scans early

Attackers do not need a zero-day to reach your data; they need a name and a permissive policy. Discovery tooling sweeps storage endpoints at scale, which means your first realistic notice of exposure is often a pattern in failed requests, not a breach alarm. Providers implicitly acknowledge this window: Google recommends taking an inventory of public resources and setting up usage logs before enforcing public access prevention, precisely because workloads and strangers may already depend on resources you did not know were public.

There is also a hard limit that makes early detection matter. Google documents that Cloud Audit Logs does not track access to objects that are public, so once a bucket truly serves anonymous readers, the audit trail of who read what largely dries up. The log-rich period is the window when requests are still failing authorization, which is exactly the enumeration phase this review targets. Treat failed anonymous traffic as signal, not noise.

Verify the enforcement plane

Start the review by confirming the kill switch on every account, subscription, and project, because per-resource settings drift. The three major providers each expose a control that survives local misconfiguration:

Two properties make these controls worth verifying on a schedule rather than once. On AWS, the restrictive combination rule means organization policy protects every member bucket even if a bucket owner flips their local settings off. On Azure, disallowing anonymous access at the Azure storage account level overrides the anonymous access setting of any container in that account, so a single account-level flag neutralizes hundreds of container-level mistakes at once. On Google Cloud, requests authorized through allUsers or allAuthenticatedUsers fail with HTTP 401 or 403 while prevention is enforced, and requests to add those principals fail outright.

For discovering what is already exposed on AWS, use the analyzer rather than ad hoc scripts: IAM Access Analyzer for S3 reports buckets whose ACLs, bucket policies, or access point policies grant public or shared access, with findings that can be acknowledged and archived when publicity is genuinely intended. That exception mechanism matters, because static website hosting is a legitimate reason a bucket stays public on both AWS and Google Cloud, and a review that treats every exception as a violation will eventually be ignored by the team.

Read the request plane

Enforcement settings tell you what should be closed; logs tell you what is being tested. Build the review around three signals that survive across providers:

• Anonymous request volume by resource. Azure exposes this directly: in Metrics Explorer, filter Blob transactions on Authentication equal to Anonymous, then drill into which containers receive the traffic.
• Authorization type in raw logs. A log query such as StorageBlobLogs | where TimeGenerated > ago(7d) and AuthenticationType == "Anonymous" returns the timestamps and URIs of anonymous attempts, which is your enumeration candidate list.
• Failure clusters on guessed names. Repeated 403 and 404 responses against common prefixes like backup, exports, or uploads from unfamiliar networks indicate name guessing rather than broken applications.

On Google Cloud, usage logs and bucket IAM policy reviews are the documented path to identifying which resources strangers might already depend on. Where signed URLs are in play, remember they are narrow, time-limited, and unaffected by public access prevention, so they belong on a separate review track rather than in the exposure sweep.

Time expectations also belong in the runbook. Google documents that public access prevention enforcement can take up to 10 minutes to take effect, and that objects can remain reachable through internet caches according to their Cache-Control metadata, with the default max-age at 3600 seconds. A remediation is not verified until a fresh request from an unauthenticated client fails after that window.

Run the review on cadence

Execute the whole loop as one procedure so results are comparable between runs:

1. Reconcile the inventory. List every bucket, container, and project storage resource across all accounts, subscriptions, and projects, then diff against your asset register; anything unexplained becomes the first review item.
2. Confirm the kill switches. Verify organization- or account-level block settings in each provider, not only bucket-level ones, and record any deliberate exceptions with an owner and expiry.
3. Export analyzer findings. Pull current public and shared access findings, and treat newly archived findings as changes requiring justification.
4. Pull seven days of anonymous traffic. Use the metrics filter and log query pattern above per account, and normalize results into requests per resource per day.
5. Triage the spikes. Prioritize anonymous traffic from unknown networks hitting high-value prefixes, and separate legitimate public workloads before escalating.
6. Remediate and re-verify. Close the exposure at the highest scope, then confirm with an unauthenticated request after the propagation and cache windows have passed.

Cadence depends on change rate. A monthly permission sweep such as the one described in our guide on auditing cloud object storage exposure pairs well with a lighter weekly pass over anonymous-request logs. If you are formalizing the workflow for the first time, the structure in our five-step early review for exposed object storage is a good baseline; add the request-plane half described here and you stop relying on luck for the window between misconfiguration and discovery.

Sources

• AWS – Blocking public access to your Amazon S3 storage
• Microsoft – Remediate anonymous read access to blob data
• Google Cloud – Public access prevention