Exposed object storage: establish possible access and observed reads
Investigate object storage flagged as public: effective permissions, presigned URLs, logging coverage and evidenced reads before verifying containment.
Integration scope: Seculogik uses a source-agnostic architecture to ingest security alerts and events through its own data map. Wazuh and OpenSearch are the first integrations. Other named sources describe planned connector targets; their availability must be confirmed for each evaluation.
An alert reports that object storage is public. Does that establish a leak of every file? No: a potential permission, an authorised request and content actually served are different findings. Conversely, an empty log search does not establish that no access occurred.
This guide proposes an investigation method independent of SIEM and provider, illustrated by public Amazon S3 documentation. AWS-specific behaviour is identified as such. It describes neither a customer incident nor an available Seculogik integration capability.
1. Scope the alert and preserve the observed state
Identify the storage, owner, relevant objects or versions, access endpoint and period under review. Also record what produced the alert: policy analysis, a configuration change or a successful request. Those signals supply different evidence.
AWS documents several S3 public-access blocking levels, including account, bucket and access point. The service combines applicable restrictions; one setting inspected at bucket level therefore does not describe every relevant control. Source: AWS, S3 Block Public Access
Our recommendation is to preserve relevant settings and policies before changing them, with their origin and collection time. A current configuration copy does not automatically reconstruct past configuration. Seek available history to bound the possible exposure period.
Define scope before counting affected files. Permission covering some objects or actions does not establish that the entire storage was readable. Where scope remains unknown, retain that uncertainty rather than inventing a total.
2. Separate anonymous access, authorised identity and shared link
AWS evaluates applicable policies in the request context. Its documentation distinguishes identity policies, resource policies and other limits; an explicit denial can override permission. An isolated permissive statement does not necessarily describe the final outcome. Source: AWS, policy evaluation
Presigned URLs provide another path: AWS describes time-limited access using the permissions of the identity that created the URL. Possession allows the intended use when access conditions are satisfied. A read through this mechanism should not automatically be classified as anonymous public access. Source: AWS, S3 presigned URLs
We recommend classifying each path separately: anonymous request, authenticated application, presigned link or intermediary service. Record the permitted action, resource and relevant conditions. Listing objects and reading their contents are different access checks.
Treat signed links as sensitive evidence. In a shared comment, prefer a protected reference and a description of the mechanism to the full URL. Do not submit a real access link to a public analysis service to check its reputation.
3. Check whether evidence covers the operations being investigated
AWS distinguishes CloudTrail management events from data events, which include S3 object operations such as GetObject. Trails do not log data events by default, and these events do not appear in standard CloudTrail event history. Searching that history alone can therefore miss the reads under investigation. Source: AWS, CloudTrail logging for S3
Server access logs provide another source. AWS states that delivery is best effort, with no completeness or timeliness guarantee; records can arrive late, be missing or duplicated. Source: AWS, S3 server access logs
Our recommendation is to map coverage by source, period, operation and resource. Check selectors, exclusions, retention and known configuration changes. A logging arrangement present today does not establish that it covered the relevant objects at the time of interest.
Separate collection for the rest of the investigation from historical evidence already available. Enabling additional logging does not recreate events that were never recorded. Any change needs authorisation, with its volume and cost implications understood by the owner.
4. Classify what was actually served
S3's text access-log format distinguishes operation, object, HTTP status, bytes sent and object size. It also provides authentication type and, depending on the request, a version reference. A dash can represent an unavailable field. Source: AWS, S3 access-log format
We recommend building a timeline of relevant requests, distinguishing content reads, metadata inspection, object listing and denied attempts. Technical success for one operation should not become, through simplification, download of a complete file.
Connect the operation to its result, object or version and documented volume where available. Address repeated requests and copied log records before counting: adding multiple traces of the same request can inflate the finding. Do not substitute the total size of all accessible objects for bytes served.
A served response does not establish that a human read or retained its contents. A technical identity or address does not itself identify the person controlling the request either. Present established effects separately from attribution limitations.
5. Verify containment with a proportionate test
Preserve useful evidence in an authorised location without delaying urgent action for a perfect case record. Have the change approved according to the affected path: resource policy, identity, presigned sharing or intermediary service. Blocking one path does not demonstrate that the others disappeared.
Our recommendation is to define a test using a synthetic object and controlled identities within an authorised scope. The object must be subject to controls relevant to the problem. A control object governed by another policy does not validate containment of the flagged objects.
Verify rejection of the unwanted path and preservation of expected legitimate access. Universal failure could simply indicate an outage or service unavailability. Record time, request context and outcome, then inspect the resulting evidence where logging coverage permits.
Do not download actual sensitive files to prove exposure. Do not re-enable public access to reproduce an incident. If realistic testing requires additional privileges or a particular environment, have authorised owners define that setting rather than expanding the exercise along the way.
6. Conclude without equating exposure with complete exfiltration
Entirely fictional example: an old policy allowed unwanted reads within a limited scope. Recovered records establish read responses for some objects, while part of the period lacks coverage. The conclusion should distinguish the established access path, documented objects and unresolved interval.
We recommend making four elements visible in the completed case:
- The confirmed access mechanism and period, with remaining hypotheses.
- Observed operations and affected data within the evidence's limits.
- Source coverage, duplicates addressed and blind spots.
- The measure taken, its owner and the check verifying its effect.
Avoid both “everything was exfiltrated” without evidence and “no leak” across an uncovered period. Assessing consequences for the data belongs with authorised owners, using the technical evidence and its limitations; the SOC should not replace that decision with a configuration status.
Our free investigation resources can help organise these findings. The objective is a case another responder can use to distinguish possible access, content served and containment outcome without relying on a public-or-private indicator.