S3 Exposure

What It Is and Why It Matters

S3 exposure is one of the most common and damaging cloud security failures because S3 is widely used to store everything from application assets to customer data to internal documents. The total volume of breached records from exposed S3 buckets across public disclosures exceeds 100 million.

The risk comes from the complex interaction between multiple permission layers — bucket policies, IAM user policies, ACLs, and account-level public access blocks — where a single misconfigured setting can make an entire bucket readable by anyone on the internet.

Even when a bucket itself is private, data can still be exposed if an IAM role with read access is compromised or if pre-signed URLs are generated without expiration.

For analysts, S3 exposure incidents demand rapid assessment of what data was accessible, who may have accessed it, and whether any objects were downloaded.

How Public Access Happens — The Four Permission Layers

S3 has four independent permission layers, and a bucket is publicly accessible if any one of them allows public access:

The most dangerous scenario: an account-level public access block with the setting “Block public and cross-account access if bucket has public policies” set to false. This allows bucket policies to override everything.

Detection — Finding Exposed S3 Buckets

AWS CloudTrail Events

CloudTrail records every S3 API call. The following events are critical for S3 exposure detection:

CloudTrail KQL Query — Detect Buckets Made Public

// Find when a bucket was made publicly accessible
CloudTrail
| where TimeGenerated > ago(7d)
| where EventName in ("PutBucketPolicy", "PutBucketAcl", "PutObjectAcl")
| extend BucketName = parse_json(RequestParameters).bucketName
| extend PolicyStatement = parse_json(RequestParameters).bucketPolicy
| extend Grantee = parse_json(RequestParameters).AccessControlPolicy.AccessControlList.Grant[*].Grantee
| extend Principal = PolicyStatement.Statement[0].Principal
| extend Effect = PolicyStatement.Statement[0].Effect
| extend Action = PolicyStatement.Statement[0].Action
| where Principal == "*" or Grantee.URI contains "global/AllUsers" or Grantee.URI contains "global/AuthenticatedUsers"
| project TimeGenerated, EventName, BucketName, UserIdentity.arn, SourceIPAddress, PolicyStatement

AWS Config Rules

AWS Config provides managed rules specifically for S3 exposure detection:

Enable these rules in AWS Config and configure SNS notifications for NonCompliant evaluations.

S3 Server Access Logs

S3 can log every request to the bucket. Key fields for investigation:

Third-Party Monitoring

• Trusted Advisor (AWS) — S3 Bucket Permissions check in the Security category.
• Security Hub — Aggregates Config findings, GuardDuty, and Inspector into a single dashboard with CIS benchmarks for S3.
• CloudSploit / ScoutSuite — Open-source auditing tools that scan AWS accounts for public S3 buckets.
• GrayHatWarfare — Public bucket search engine (buckets.grayhatwarfare.com). Search your org’s naming patterns to see if your buckets appear.

What To Do When You Find Exposed Data

If you discover a publicly accessible S3 bucket, follow this sequence:

1. Immediately block public access — Set the account-level public access block to block all public policies and ACLs. This is the fastest way to cut access without modifying individual bucket policies.
2. Identify the data — Run aws s3 ls s3://bucket-name --recursive (using an internal role) to enumerate objects. Create a manifest of file types, sizes, and date ranges.
3. Check CloudTrail — Query GetObject events for the bucket. Identify which IPs accessed which objects and when.
4. Notify stakeholders — Legal, compliance, and engineering teams need to know. The bucket owner may need to issue a data breach notification depending on data classification.
5. Rotate credentials — If IAM keys were in the exposed bucket, rotate them immediately. API keys, database passwords, and TLS private keys are high-value targets.
6. Root cause analysis — Why was the bucket exposed? Misconfigured IaC template? Manual override? Missing public access block? Fix the process, not just the bucket.

Real-World Examples

• Dow Jones watchlist exposure (2017) — An exposed S3 bucket contained the names, addresses, and financial account details of over two million high-risk individuals and politically exposed persons from Dow Jones watchlist data.
• Verizon NICE Systems leak (2017) — A third-party vendor misconfigured an S3 bucket containing Verizon customer data including names, phone numbers, and account PINs for over 6 million subscribers.
• Accenture cloud exposure (2017) — Four unsecured S3 buckets exposed internal Accenture data including API access keys, authentication credentials, and customer decryption keys.
• US Army data leak (2023) — An exposed S3 bucket belonging to a contractor contained US Army intelligence data, accessible to anyone with the bucket URL.

Prevention — S3 Security Checklist

Related

• Insider Threat — detection and response for T1078 techniques
• Cloud Incident Response — detection and response for T1525, T1526, T1078, T1530 techniques
• Active Directory Basics — covers the active directory basics concepts
• AWS Misconfigurations — detection and response for T1525, T1613 techniques

Sources

• AWS S3 Security Best Practices
• AWS CloudTrail Documentation
• S3 Server Access Log Format
• MITRE ATT&CK Data from Cloud Storage T1530