AWS S3 Bucket ACL Modified to Allow Public Access by New Identity

IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

AWS S3 Bucket ACL Modified to Allow Public Access by New Identity

Detects a principal modifying an S3 bucket ACL to grant public read or write access that has not been observed doing so within the history window, using canned ACLs such as public-read or public-read-write. ACL-based public access is a distinct API path (PutBucketAcl) that can bypass some Block Public Access controls. Monitoring for new identities performing this change helps surface freshly compromised credentials being used to stage data for exfiltration or inadvertently expose sensitive content.

Rule type: new_terms

Rule indices:

logs-aws.cloudtrail-*

Severity: medium

Risk score: 47

Runs every: 5m

Searches indices from: now-6m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

Tags:

Domain: Cloud
Data Source: AWS
Data Source: Amazon Web Services
Data Source: Amazon S3
Use Case: Threat Detection
Tactic: Collection
Resources: Investigation Guide

Version: 1

Rule authors:

Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating AWS S3 Bucket ACL Modified to Allow Public Access by New Identity

This rule fires when a PutBucketAcl call sets a canned ACL that grants public or broad access. Unlike bucket policies, bucket ACLs are a legacy mechanism that bypasses some newer Block Public Access controls and can inadvertently or deliberately expose bucket contents to unauthenticated internet users.

Possible investigation steps

Identify the modifying principal (aws.cloudtrail.user_identity.arn) and determine whether they are authorized to modify S3 bucket ACLs.
Review aws.cloudtrail.request_parameters to confirm the specific canned ACL applied (public-read, public-read-write).
Check whether AWS S3 Block Public Access is enabled at the account or bucket level — if so, it may still be preventing effective public exposure even though this ACL change succeeded.
Enumerate the bucket contents to assess the sensitivity of any exposed data.
Check for recent GetObject or ListObjects calls from unauthenticated sources against the same bucket.

False positive analysis

Static website hosting buckets are commonly configured with public-read ACLs.

Response and remediation

If unauthorized, immediately reset the bucket ACL to private using PutBucketAcl.
Enable S3 Block Public Access at the account level to prevent future ACL-based public exposure across all buckets.
Review the bucket’s object-level access log for any unauthorized reads that occurred after the ACL change.

Setup

edit

The AWS CloudTrail integration must be enabled and configured to collect S3 management events (s3.amazonaws.com).

Rule query

edit

data_stream.dataset: "aws.cloudtrail"
    and event.provider: "s3.amazonaws.com"
    and event.action: "PutBucketAcl"
    and event.outcome: "success"
    and not aws.cloudtrail.user_identity.type: "AWSService"
    and aws.cloudtrail.flattened.request_parameters.x-amz-acl: ("public-read" or "public-read-write")
    and not user_agent.original: (*Terraform* or *terraform* or "cloudformation.amazonaws.com" or *pulumi* or *Pulumi*)

Framework: MITRE ATT&CK^TM

Tactic:
- Name: Collection
- ID: TA0009
- Reference URL: https://attack.mitre.org/tactics/TA0009/
Technique:
- Name: Data from Cloud Storage
- ID: T1530
- Reference URL: https://attack.mitre.org/techniques/T1530/

« Potential Tunneling via Tailscaled AWS EC2 NACL Entry Created or Replaced Allowing All Traffic by New Identity »