From S3 Misconfiguration to Full AWS Account Compromise
A walkthrough of a real attack chain: public S3 bucket → embedded credentials → IAM privilege escalation → full AWS admin access.
The Initial Discovery
During an external attack surface scan for a telehealth client, our ASM platform flagged a publicly accessible S3 bucket named company-terraform-configs-dev. This is an extremely common finding — engineers create buckets during development and forget to restrict access before or after going to production.
What Was Inside
The bucket contained Terraform state files, configuration templates, and — critically — a .env file with hardcoded AWS access keys. This is the digital equivalent of leaving your house keys under the doormat with a note saying "these are keys to the house."
Privilege Escalation
Using the exposed AWS access keys, we enumerated the IAM permissions attached to that credential. The key belonged to a CI/CD service account with an overly broad IAM policy that included iam:AttachRolePolicy and iam:CreatePolicy. Using Pacu (the AWS exploitation framework), we escalated to full administrative access by attaching AdministratorAccess to a role we controlled.
Impact
With full admin access, we could read the production RDS database containing 500,000 patient health records, modify EC2 instances, access all S3 buckets including those with patient intake forms, and pivot to any service in the account.
Remediation
1. Immediately rotate all exposed credentials. 2. Enable S3 Block Public Access at the account level. 3. Implement least-privilege IAM policies — no service account should ever have iam:* permissions. 4. Use AWS Secrets Manager for all credentials. 5. Enable AWS Config and GuardDuty.