Detecting Public S3 Bucket Access: CloudTrail, GuardDuty and Athena Queries

Retrospective: this article looks back at events from June 2017, written in 2026 with the benefit of hindsight.

The best time to catch a public S3 bucket is the moment it becomes public. Detection rules on configuration changes close the window between a mistake and an exposure.

Signals worth watching

• Changes to bucket policies or ACLs that grant access to everyone or to all authenticated AWS users.
• Block Public Access settings being disabled at bucket or account level.
• Spikes in anonymous GetObject requests on a bucket.
• Large data downloads from unfamiliar IP addresses.

Where the data lives

• CloudTrail management events: PutBucketPolicy, PutBucketAcl, DeletePublicAccessBlock, PutPublicAccessBlock.
• GuardDuty S3 Protection: findings for anomalous access and policy changes that make buckets public.
• IAM Access Analyzer: findings when a bucket becomes shared externally.
• S3 server access logs or CloudTrail data events for object-level reads.

A starting query

In Athena over CloudTrail logs, list recent changes that can open a bucket:

SELECT eventtime, useridentity.arn, eventname, requestparameters
FROM cloudtrail_logs
WHERE eventname IN ('PutBucketPolicy','PutBucketAcl','DeletePublicAccessBlock','PutPublicAccessBlock')
  AND eventtime > to_iso8601(current_timestamp - interval '7' day)
ORDER BY eventtime DESC;

In Microsoft Sentinel with the AWS connector, the same events appear in the AWSCloudTrail table.

Response

1. Re-enable Block Public Access on the affected bucket.
2. Check access logs to see whether anything was downloaded while it was open.
3. Find who made the change and why — it is usually a process gap, not malice.
4. Add a preventive control (SCP or Config auto-remediation) so it cannot happen the same way again.