Scope
An authorized Pwned Labs environment. I was given a target IP address and a set of AWS credentials, and nothing else.
Attack path
- Network reconnaissance. An Nmap scan of the target showed the open ports and services. I used the discovered port to reach the web page.
- Web enumeration. The page source showed that some of the site's resources were hosted in an Amazon S3 bucket.
- AWS enumeration. I configured the provided credentials and tested IAM policy listing, bucket listing, object downloads, object ACL checks and unauthenticated access. Most were denied, because the credentials were narrowly scoped.
- Bucket policy enumeration. An unsigned request was denied, so the bucket was not public. The bucket policy itself, however, was readable. It revealed which resources existed and which principals could use them, which let me send a targeted download request for an object I could not list.
- Credential extraction. The downloaded file was password protected. John the Ripper recovered the password, and the contents exposed administrative credentials and other privileged information.
- Web directory enumeration. Gobuster mapped the directories I could reach with those credentials, which led to confidential data inside the lab.
Small AWS permission weaknesses, chained together, became a serious compromise.
What went wrong
- Overly permissive bucket policy
- Policy contents disclosed too much about the bucket
- Weak access controls around S3 objects
- Object names relied on as a security boundary
- Credentials stored in a spreadsheet
How to fix it
- Apply least privilege to IAM and S3 policies
- Limit access to bucket policies and metadata to identities that need it
- Never treat knowing an object name as access control
- Review bucket policies and ACLs regularly for unintended access
- Keep credentials in a managed password manager
