Detecting S3 Misconfiguration: CloudTrail, GuardDuty and Athena Queries

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

Most S3 misconfigurations begin with a configuration change. Monitoring those changes in near real time catches exposures within minutes rather than months.

Signals worth watching

• Bucket ACL changes granting AllUsers or AuthenticatedUsers.
• Bucket policy changes adding wildcard principals or external accounts.
• Account-level Block Public Access being turned off.
• Encryption, versioning or logging being disabled on sensitive buckets.
• AWS Config rules switching from compliant to non-compliant.

Where the data lives

• AWS Config compliance change notifications.
• CloudTrail management events for S3 configuration APIs.
• Security Hub findings from the AWS Foundational Security Best Practices standard.
• GuardDuty S3 Protection for suspicious access after the change.

A starting approach

Create an Amazon EventBridge rule that matches Config compliance changes for your S3 rules and sends them to an SNS topic or ticketing system. For Microsoft Sentinel users, query CloudTrail:

AWSCloudTrail
| where EventSource == "s3.amazonaws.com"
| where EventName in ("PutBucketAcl", "PutBucketPolicy", "DeleteBucketPolicy",
    "DeleteBucketEncryption", "PutBucketVersioning", "DeletePublicAccessBlock")
| project TimeGenerated, EventName, UserIdentityArn, SourceIpAddress, RequestParameters

Response

1. Confirm whether the change was intended and approved.
2. Revert if not, and check access logs for the exposure window.
3. Add the pattern to preventive controls so it cannot recur.