Detecting S3 Bucket Policy Misconfiguration: CloudTrail, GuardDuty and Athena Queries

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

Overly broad bucket policies are a frequent root cause of S3 exposures. Detecting policy changes that widen access — and catching risky policies already in place — keeps small mistakes from becoming headlines.

Signals worth watching

• New bucket policies with "Principal": "*" without restrictive conditions.
• Grants to unfamiliar external AWS account IDs.
• Removal of deny statements such as TLS enforcement or organization restrictions.
• Policies granting s3:* or write and delete actions broadly.

Where the data lives

• IAM Access Analyzer: generates findings whenever a bucket is shared outside your zone of trust, including the exact principal.
• AWS Config: rules such as s3-bucket-public-read-prohibited and s3-bucket-ssl-requests-only.
• CloudTrail: PutBucketPolicy events include the full new policy in the request parameters.
• Security Hub: aggregates S3 control findings from the AWS Foundational Security Best Practices standard.

A detection approach

Alert on every PutBucketPolicy event for buckets tagged as sensitive, and parse the policy for wildcard principals or foreign account IDs. In Microsoft Sentinel:

AWSCloudTrail
| where EventName == "PutBucketPolicy"
| extend Policy = tostring(parse_json(RequestParameters).bucketPolicy)
| where Policy has "\"Principal\":\"*\"" or Policy has "\"AWS\":\"*\""
| project TimeGenerated, UserIdentityArn, SourceIpAddress, RequestParameters

Response

1. Compare the new policy with the previous version and revert if unintended.
2. Check object access logs for the period the policy was in effect.
3. Contact the change author to understand the business need and offer a safer pattern, such as an access point or presigned URLs.