What is purple team security → OWASP Top 10 mapped to cloud infrastructure → Cloud security breaches 2020–2025 → Broken access control in AWS
TL;DR
- Broken access control in AWS is OWASP A01 — the most common cloud security failure, covering IAM wildcards, public S3 buckets, and overly broad trust policies
- A public S3 bucket containing 47 million customer records went undetected for six months in an authorized assessment — no GuardDuty finding, no AWS Config alert, because those controls weren’t enabled
- The red phase: three commands to identify public buckets, enumerate IAM over-permissions, and test trust policy abuse — all with read-only access on your own account
- The blue phase: two AWS Config managed rules and one GuardDuty finding type that cover the majority of A01 findings
- The purple phase: deny-based SCPs, bucket public access blocks, and IAM Access Analyzer — structural controls, not monitoring alerts
- Cross-series: IAM privilege escalation paths (IAM EP08) and AWS least privilege audit (IAM EP09) go deeper on the IAM layer
OWASP Mapping: A01 Broken Access Control — primarily. A09 Logging and Monitoring Failures — the six-month detection gap demonstrates A09 as an amplifier of A01.
The Big Picture
┌─────────────────────────────────────────────────────────────────────┐
│ BROKEN ACCESS CONTROL — ATTACK SURFACE │
│ │
│ INTERNET AWS ACCOUNT │
│ │
│ Attacker ──────────────▶ S3 bucket (public read) │
│ └── 47M customer records │
│ │
│ Attacker ──────────────▶ IAM user with "Action": "*" │
│ (compromised creds) └── escalate → admin access │
│ │
│ Attacker ──────────────▶ Trust policy: "AWS": "*" │
│ (any AWS account) └── assume role from attacker's │
│ account │
│ │
│ ═══════════════════════════════════════════════════════ │
│ │
│ DETECTION GAPS (A09 amplifying A01): │
│ • S3 public access not in AWS Config rules │
│ • GuardDuty not enabled │
│ • No IAM Access Analyzer │
│ • No SCP boundary on public bucket creation │
│ │
└─────────────────────────────────────────────────────────────────────┘
Broken access control in AWS is the infrastructure equivalent of OWASP A01: a principal can reach a resource it should not be able to reach, because the access control decision was either not made or made incorrectly. In the cloud context, this manifests as public S3 buckets, IAM policies with wildcard actions and resources, and trust policies that allow any principal rather than a specific, scoped entity.
The Assessment That Changed My Approach to Access Control Auditing
During an authorized assessment, I found an S3 bucket containing 47 million customer records. The bucket name was generic — no obvious PII signal in the name itself. It was created two years prior by an engineer who was troubleshooting a data pipeline and needed temporary public access to share data with an external partner. The partner relationship ended. The bucket access was never reverted.
The bucket had been public for six months at the time I found it. I checked the AWS Config rules: S3 public access was not in the rule set. GuardDuty was enabled but no finding had fired — GuardDuty generates a Policy:S3/BucketAnonymousAccessGranted finding when public access is enabled, but only if the finding is new during GuardDuty’s monitoring window. The bucket went public before GuardDuty was enabled.
No alert ever fired. Not because the tools couldn’t detect it — because the tools weren’t configured to look.
This is A01 amplified by A09. The broken access control is the public bucket. The six-month window is the logging and monitoring failure.
Red Phase: How Broken Access Control Works in Practice
The red team perspective on broken access control starts with enumeration. What can this principal reach that it shouldn’t be able to reach?
Enumerating Public S3 Buckets
aws s3api list-buckets --query 'Buckets[].Name' --output text | \
tr '\t' '\n' | \
while read bucket; do
# Check account-level block
account_block=$(aws s3control get-public-access-block \
--account-id $(aws sts get-caller-identity --query Account --output text) \
2>/dev/null | jq -r '.PublicAccessBlockConfiguration.BlockPublicAcls')
# Check bucket-level policy
policy=$(aws s3api get-bucket-policy-status --bucket "$bucket" 2>/dev/null | \
jq -r '.PolicyStatus.IsPublic')
# Check bucket ACL
acl=$(aws s3api get-bucket-acl --bucket "$bucket" 2>/dev/null | \
jq -r '.Grants[] | select(.Grantee.URI == "http://acs.amazonaws.com/groups/global/AllUsers") | .Permission')
if [ "$policy" = "true" ] || [ -n "$acl" ]; then
echo "PUBLIC BUCKET: $bucket (policy_public=$policy, acl_grants=$acl)"
fi
done
Enumerating Overly Permissive IAM Policies
# Find all customer-managed policies with wildcard actions
aws iam list-policies --scope Local --query 'Policies[].Arn' --output text | \
tr '\t' '\n' | \
while read arn; do
version=$(aws iam get-policy --policy-arn "$arn" \
--query 'Policy.DefaultVersionId' --output text)
doc=$(aws iam get-policy-version --policy-arn "$arn" --version-id "$version" \
--query 'PolicyVersion.Document' --output json)
if echo "$doc" | jq -e '.Statement[] | select(.Effect == "Allow" and .Action == "*")' > /dev/null 2>&1; then
echo "WILDCARD ACTION POLICY: $arn"
echo "$doc" | jq '.Statement[] | select(.Effect == "Allow" and .Action == "*")'
fi
done
Testing Trust Policy Abuse
# Find IAM roles with overly broad trust policies
# Specifically: trust policies that allow any AWS account or service
aws iam list-roles --query 'Roles[].{Name:RoleName,Arn:Arn}' --output json | \
jq -r '.[].Arn' | \
while read role_arn; do
trust=$(aws iam get-role --role-name "$(basename $role_arn)" \
--query 'Role.AssumeRolePolicyDocument' --output json 2>/dev/null)
# Check for wildcard principals
if echo "$trust" | jq -e '.Statement[] | select(.Principal == "*")' > /dev/null 2>&1; then
echo "WILDCARD TRUST PRINCIPAL: $role_arn"
fi
# Check for cross-account trust without conditions
if echo "$trust" | jq -e '.Statement[] | select(.Principal.AWS | type == "string" and test("arn:aws:iam::[0-9]+:root"))' > /dev/null 2>&1; then
account_in_trust=$(echo "$trust" | jq -r '.Statement[] | .Principal.AWS // empty' | grep -oP '(?<=arn:aws:iam::)[0-9]+')
current_account=$(aws sts get-caller-identity --query Account --output text)
if [ "$account_in_trust" != "$current_account" ]; then
echo "CROSS-ACCOUNT TRUST (verify scope): $role_arn trusts account $account_in_trust"
fi
fi
done
Simulating S3 Exfiltration (on your own bucket — safe test)
# Create a test bucket, make it public, verify it's accessible without credentials
# Do this in a non-production account only
TEST_BUCKET="purple-team-test-$(date +%s)"
aws s3 mb s3://${TEST_BUCKET} --region us-east-1
# Disable the public access block (simulates the misconfiguration)
aws s3api put-public-access-block \
--bucket "${TEST_BUCKET}" \
--public-access-block-configuration \
"BlockPublicAcls=false,IgnorePublicAcls=false,BlockPublicPolicy=false,RestrictPublicBuckets=false"
# Add a public-read bucket policy
aws s3api put-bucket-policy --bucket "${TEST_BUCKET}" --policy '{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::'"${TEST_BUCKET}"'/*"
}]
}'
# Put a test file
echo "PURPLE_TEAM_TEST_DATA" | aws s3 cp - s3://${TEST_BUCKET}/test.txt
# Verify it's accessible without credentials
curl -s "https://${TEST_BUCKET}.s3.amazonaws.com/test.txt"
# Should return: PURPLE_TEAM_TEST_DATA
echo ""
echo "Test complete. Clean up:"
echo "aws s3 rb s3://${TEST_BUCKET} --force"
Blue Phase: What Detection Looks Like
What AWS Config Catches
Two managed rules cover the majority of S3 broken access control findings:
# Enable the S3 public access rules in AWS Config
# (requires Config to already be enabled)
# Rule 1: s3-bucket-public-read-prohibited
aws configservice put-config-rule --config-rule '{
"ConfigRuleName": "s3-bucket-public-read-prohibited",
"Source": {
"Owner": "AWS",
"SourceIdentifier": "S3_BUCKET_PUBLIC_READ_PROHIBITED"
},
"Scope": {
"ComplianceResourceTypes": ["AWS::S3::Bucket"]
}
}'
# Rule 2: s3-account-level-public-access-blocks-periodic
aws configservice put-config-rule --config-rule '{
"ConfigRuleName": "s3-account-level-public-access-blocks-periodic",
"Source": {
"Owner": "AWS",
"SourceIdentifier": "S3_ACCOUNT_LEVEL_PUBLIC_ACCESS_BLOCKS_PERIODIC"
}
}'
# Check current compliance status
aws configservice describe-compliance-by-config-rule \
--config-rule-names s3-bucket-public-read-prohibited \
--query 'ComplianceByConfigRules[].{Rule:ConfigRuleName,Compliance:Compliance.ComplianceType}'
What GuardDuty Catches
GuardDuty generates these findings for S3 broken access control:
| Finding Type | Trigger | Severity |
|---|---|---|
Policy:S3/BucketAnonymousAccessGranted |
Bucket policy or ACL grants public read/write | Medium |
Policy:S3/BucketPublicAccessGranted |
Same as above — alternate finding type | Medium |
Discovery:S3/MaliciousIPCaller |
S3 GetObject from a known malicious IP | High |
# Query GuardDuty findings for S3 public access violations
DETECTOR_ID=$(aws guardduty list-detectors --query 'DetectorIds[0]' --output text)
aws guardduty list-findings \
--detector-id "${DETECTOR_ID}" \
--finding-criteria '{
"Criterion": {
"type": {
"Equals": ["Policy:S3/BucketAnonymousAccessGranted", "Policy:S3/BucketPublicAccessGranted"]
}
}
}' \
--query 'FindingIds' --output text | \
xargs -n 10 aws guardduty get-findings \
--detector-id "${DETECTOR_ID}" \
--finding-ids | \
jq '.Findings[] | {type: .Type, bucket: .Resource.S3BucketDetails[0].Name, severity: .Severity}'
What IAM Access Analyzer Catches
IAM Access Analyzer continuously analyzes resource policies for external access — S3 buckets, IAM roles, KMS keys, SQS queues, Lambda functions. It generates a finding any time a resource policy grants access to a principal outside the AWS account (or AWS Organization boundary).
# Enable IAM Access Analyzer for the account
aws accessanalyzer create-analyzer \
--analyzer-name "account-access-analyzer" \
--type ACCOUNT
# List all active findings (external access granted)
aws accessanalyzer list-findings \
--analyzer-arn $(aws accessanalyzer list-analyzers --query 'analyzers[0].arn' --output text) \
--filter '{"status": {"eq": ["ACTIVE"]}}' \
--query 'findings[].{Resource:resource,Principal:principal,Action:action}' \
--output table
What the CloudTrail Event Looks Like
When an anonymous user accesses a public S3 object:
{
"eventVersion": "1.09",
"userIdentity": {
"type": "AWSAccount",
"accountId": "ANONYMOUS_PRINCIPAL",
"principalId": "ANONYMOUS_PRINCIPAL"
},
"eventTime": "2024-03-15T02:47:00Z",
"eventSource": "s3.amazonaws.com",
"eventName": "GetObject",
"requestParameters": {
"bucketName": "your-bucket-name",
"key": "customer-data/records.csv"
},
"sourceIPAddress": "198.51.100.1",
"userAgent": "python-requests/2.28.0"
}
The signal: userIdentity.type = "AWSAccount" with accountId = "ANONYMOUS_PRINCIPAL" on a GetObject event. This is a read from an anonymous, unauthenticated principal.
# CloudTrail Insights query (Athena) to find anonymous S3 GetObject events
# Assumes CloudTrail S3 data events are enabled for the bucket
SELECT
eventTime,
sourceIPAddress,
requestParameters.bucketName,
requestParameters.key,
userIdentity.type,
userIdentity.accountId
FROM cloudtrail_logs
WHERE
eventName = 'GetObject'
AND userIdentity.type = 'AWSAccount'
AND userIdentity.accountId = 'ANONYMOUS_PRINCIPAL'
AND eventTime > current_timestamp - interval '7' day
ORDER BY eventTime DESC
LIMIT 100;
Purple Phase: The Structural Fix
Detection catches broken access control after the fact. The structural fix prevents it from being possible.
Fix 1: Account-Level S3 Public Access Block
This is a single setting that prevents any bucket in the account from becoming public — regardless of bucket policy or ACL. It overrides bucket-level settings.
# Enable account-level S3 public access block
aws s3control put-public-access-block \
--account-id $(aws sts get-caller-identity --query Account --output text) \
--public-access-block-configuration \
"BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true"
# Verify
aws s3control get-public-access-block \
--account-id $(aws sts get-caller-identity --query Account --output text)
Fix 2: SCP to Prevent Disabling the Public Access Block
An SCP (Service Control Policy) at the AWS Organizations level that prevents any account from disabling the public access block — even an account administrator.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyS3PublicAccessBlockDisable",
"Effect": "Deny",
"Action": [
"s3:PutBucketPublicAccessBlock",
"s3:DeletePublicAccessBlock"
],
"Resource": "*",
"Condition": {
"ArnNotLike": {
"aws:PrincipalArn": "arn:aws:iam::*:role/s3-public-access-exception-role"
}
}
}
]
}
# Apply the SCP to your organizational unit
aws organizations create-policy \
--name "DenyS3PublicAccessBlockDisable" \
--type SERVICE_CONTROL_POLICY \
--content file://scp-deny-s3-public-access.json \
--description "Prevents disabling S3 public access block at account level"
Fix 3: IAM Policy Cleanup — Remove Wildcards
For IAM policies with wildcard actions, the fix is least-privilege replacement. This is not a quick operation — it requires analyzing actual usage and scoping to what is actually needed.
# Use IAM Access Analyzer policy generation to generate a least-privilege policy
# based on actual CloudTrail activity for a role
aws accessanalyzer start-policy-generation \
--policy-generation-details '{
"principalArn": "arn:aws:iam::123456789012:role/your-role-name"
}' \
--cloud-trail-details '{
"accessRole": "arn:aws:iam::123456789012:role/access-analyzer-cloudtrail-role",
"trailProperties": [{
"cloudTrailArn": "arn:aws:cloudtrail:us-east-1:123456789012:trail/your-trail",
"regions": ["us-east-1", "us-west-2"],
"allRegions": false
}],
"startTime": "2024-01-01T00:00:00Z",
"endTime": "2024-03-01T00:00:00Z"
}'
# Retrieve the generated policy
JOB_ID="<returned-job-id>"
aws accessanalyzer get-generated-policy --job-id "${JOB_ID}"
For a systematic audit approach, the AWS least privilege audit process in IAM EP09 covers how to move from wildcard policies to scoped permissions methodically across a multi-account environment.
Fix 4: IAM Access Analyzer with Automated Archiving
# Create an archive rule for known-good cross-account access
# (prevents alert fatigue from legitimate cross-account patterns)
aws accessanalyzer create-archive-rule \
--analyzer-name "account-access-analyzer" \
--rule-name "archive-legitimate-cross-account" \
--filter '{
"principal.AWS": {
"contains": ["arn:aws:iam::111122223333:role/legitimate-cross-account-role"]
}
}'
Run This in Your Own Environment: A01 Audit
Run this in any AWS account you own or have read-only access to audit:
#!/bin/bash
# Purple Team EP04 — Broken Access Control (A01) Audit
# Safe to run with read-only IAM permissions
ACCOUNT=$(aws sts get-caller-identity --query Account --output text)
echo "Auditing account: ${ACCOUNT}"
echo "==============================="
echo ""
echo "[A01-1] S3 Account-Level Public Access Block"
aws s3control get-public-access-block --account-id "${ACCOUNT}" 2>/dev/null || \
echo " FINDING: Account-level public access block not configured"
echo ""
echo "[A01-2] S3 Buckets with Public Access"
aws s3api list-buckets --query 'Buckets[].Name' --output text | tr '\t' '\n' | \
while read bucket; do
status=$(aws s3api get-bucket-policy-status --bucket "$bucket" 2>/dev/null | \
jq -r '.PolicyStatus.IsPublic // "false"')
if [ "$status" = "true" ]; then
echo " FINDING: Public bucket: $bucket"
fi
done
echo ""
echo "[A01-3] IAM Roles with Wildcard Trust Policies"
aws iam list-roles --query 'Roles[].RoleName' --output text | tr '\t' '\n' | head -50 | \
while read role; do
trust=$(aws iam get-role --role-name "$role" \
--query 'Role.AssumeRolePolicyDocument.Statement' 2>/dev/null)
if echo "$trust" | jq -e '.[] | select(.Principal == "*")' > /dev/null 2>&1; then
echo " FINDING: Wildcard trust principal in role: $role"
fi
done
echo ""
echo "[A01-4] IAM Access Analyzer — Active External Access Findings"
ANALYZER=$(aws accessanalyzer list-analyzers --query 'analyzers[0].arn' --output text 2>/dev/null)
if [ -z "$ANALYZER" ]; then
echo " FINDING: IAM Access Analyzer not enabled"
else
aws accessanalyzer list-findings \
--analyzer-arn "${ANALYZER}" \
--filter '{"status": {"eq": ["ACTIVE"]}}' \
--query 'findings[].{Resource:resource,Type:resourceType}' \
--output table
fi
⚠ Common Mistakes When Fixing Broken Access Control in AWS
Fixing the symptom at the bucket level without the account-level block. If you set RestrictPublicBuckets=true on individual buckets but leave the account-level block unset, the next bucket created by another engineer starts with public access possible again. The account-level block is the structural control; the bucket-level setting is defense-in-depth.
Not enabling CloudTrail S3 data events. CloudTrail management events capture bucket creation and policy changes. They do not capture GetObject and PutObject by default — that requires enabling S3 data events, which adds cost. Without data events, you cannot see who accessed what in a public bucket. If you can’t afford data events on all buckets, enable them on buckets containing sensitive data.
Treating IAM Access Analyzer findings as one-time. Access Analyzer runs continuously. A new resource policy that grants external access generates a new finding. If you archive findings without fixing the underlying policy, you lose visibility. Archive only findings that represent intentional, documented cross-account access.
Confusing “no GuardDuty findings” with “no problem.” GuardDuty’s Policy:S3/BucketAnonymousAccessGranted only fires when access is newly granted during GuardDuty’s monitoring window. A bucket that was made public before GuardDuty was enabled will not generate a finding — GuardDuty does not retroactively scan all bucket policies. Use AWS Config for retroactive compliance checks; use GuardDuty for real-time detection of new violations.
For the full IAM attack chain that broken access control enables — including IAM privilege escalation paths via iam:PassRole — see IAM series EP08. The privilege escalation analysis belongs alongside the access control audit.
Quick Reference
| Control | What It Does | AWS Service |
|---|---|---|
| Account-level S3 public access block | Prevents any bucket from becoming public | S3 Control |
| SCP: deny public access block disable | Prevents disabling the account-level block | Organizations |
AWS Config: S3_BUCKET_PUBLIC_READ_PROHIBITED |
Flags buckets that are or become public | AWS Config |
GuardDuty: Policy:S3/BucketAnonymousAccessGranted |
Detects new public access grants | GuardDuty |
| IAM Access Analyzer | Finds all resources with external access grants | Access Analyzer |
| CloudTrail S3 data events | Captures GetObject/PutObject for audit | CloudTrail |
| IAM policy generation | Generates least-privilege policy from actual usage | Access Analyzer |
Key Takeaways
- Broken access control in AWS (OWASP A01) is the most common cloud security failure — IAM wildcards, public S3, and broad trust policies are the three primary manifestations
- A public S3 bucket with 47 million records was active for six months without a single alert — because the detection controls (AWS Config rules, GuardDuty) weren’t enabled to look for it
- The structural fix is the account-level S3 public access block enforced by SCP — detection tools catch violations; the SCP prevents the violation from being possible
- IAM Access Analyzer provides continuous visibility into every resource that grants external access — enable it in every account
- The red phase can be run with read-only permissions against your own account — the audit script above reveals your current A01 exposure in under five minutes
- Fixing A01 without enabling the A09 controls (CloudTrail data events, GuardDuty, AWS Config) leaves you blind to whether the fix is working
- Use Access Analyzer’s policy generation feature to move from wildcard policies to least-privilege without guessing
What’s Next
EP05 covers MFA fatigue attacks — how the Uber and Okta breaches worked at the authentication layer, how to simulate push-notification fatigue in a test environment, and the structural fix: phishing-resistant MFA using FIDO2 hardware keys. The identity layer is where most cloud compromises start — understanding how push MFA fails is the prerequisite for knowing why hardware keys are the only structural answer.
Get EP05 in your inbox when it publishes → subscribe at linuxcent.com
