Identifying the AWS account ID from a public S3 bucket

Identifying the AWS account ID from a public S3 bucket | by Ronaldsecurit - Freedium Milestone: 20GB Reached We’ve reached 20GB of stored data — thank you for helping us grow! Patreon Ko-fi Liberapay Close < Go to the original Identifying the AWS account ID from a public S3 bucket The art of cloud reconnaissance: How to transform a simple exposed bucket into the key piece for mapping and enumerating critical AWS… Ronaldsecurit Follow ~5 min read · March 30, 2026 (Updated: March 30, 2026) · Free: Yes The art of cloud reconnaissance: How to transform a simple exposed bucket into the key piece for mapping and enumerating critical AWS resources. Context for the real world: If malicious actors obtain an AWS account ID, they can attempt to identify the IAM users and roles associated with that account. This can be done by exploiting the detailed error messages that AWS services return when entering an incorrect username or role. These messages may verify whether an IAM user or role exists, which can help malicious actors compile a list of potential targets within the AWS account. It is also possible to filter public EBS and RDS snapshots by the owning AWS account ID. 1- The first step in recognizing this S3 bucket was to first identify the open ports on the destination IP address. 2- Identify the website on the open door, its functionalities, and source code. This reveals the website of the company Mega Big Tech. There doesn't seem to be any interesting functionality; let's check the source code. By analyzing the source code, we can see that the website's images are being stored in an AWS S3 bucket. 3 — Obter o AWS ID da conta aws na qual este bucket esta armazenado Using the S3 bucket name, we can try to obtain the AWS account ID where it's hosted. Research by Ben Bridts revealed that it's possible to quickly discover, through brute force, the AWS account ID to which an S3 bucket belongs. Reading this research article and reviewing the code here is recommended, but in short, this script creates a policy that uses the new S3:ResourceAccountA policy condition key to evaluate whether we should have access to an S3 bucket based on the AWS account the bucket belongs to. Fortunately, the script doesn't need to guess a trillion different account IDs to find the correct one; the available search space is drastically reduced thanks to the use of string matching and wildcards. Each correctly found digit is added to a variable, and the request is repeated until the account ID is found. After configuring our AWS tool in the terminal, we also installed a Python module that helps us with information recognition. python3 -m pip install s3-account-search s3-account-search arn:aws:iam::427648302155:role/LeakyBucket mega-big-tech After obtaining the AWS ID of the account associated with the site, we can begin our reconnaissance to uncover incorrect configurations and obtain things like the account owner's name, as well as public snapshots from EBS and RDS. 4- Get the AWS region from the website headers using the curl tool with the command. curl -I https://mega-big-tech.s3.amazonaws.com In the response headers, we see that the x-amz-bucket-region header is set to us-east-1, which is Northern Virginia. 5- After that, create your AWS account, go to the AWS console, then to EC2 services, and then to snapshots. Then search for the EC2 service. Click the service and in the EC2 dashboard, in the left-hand menu, select Snapshots under the Elastic Block Store menu item. In the dropdown list, select Public snapshots , paste the discovered AWS account ID into the field and hit enter/return. After waiting a minute we get a hit and see that the company has a publicly exposed EBS snapshot! PWNED! After a minute, we get a match and see that the company has a publicly exposed EBS snapshot! We did it! Although AWS account IDs are not considered particularly sensitive and are often available in public documentation or code, knowing the account ID of an organization whose security you are evaluating can be useful. In terms of detection, STS actions occur in the account of the person attempting to find the account ID, which will not be visible to the bucket owner's account. However, it is possible to enable S3 data events for an additional cost. and through the terminal using the command: aws ec2 describe-snapshots — owner-ids 107513503799 — restorable-by-user-ids all — region us-east-1 Exploring AWS infrastructure via CLI is a fundamental skill for any security or cloud professional. As we've seen, identifying exposed resources — whether through S3 bucket metadata or by searching public snapshots — requires not only the right tools but also an understanding of how Amazon APIs and regions communicate. Reconnaissance is only the first step. The real challenge lies in configuring IAM and Bucket Policies that follow the principle of least privilege, ensuring that sensitive data is not at the mercy of public queries. Acknowledgements Thank you for following this AWS reconnaissance guide! I hope the commands and environment error corrections (such as adjusting the PATH in Zsh) have been helpful to your learning journey. If you have any questions about the ec2 describe-snapshots filters or would like to share any other useful enumeration commands, feel free to get in touch or leave a comment. My linkedin: https://www.linkedin.com/in/ronald-santos-/ #cloud-penetration-testing #aws-s3-bucket #red-team #bug-bounty Reporting a Problem Sometimes we have problems displaying some Medium posts. If you have a problem that some images aren't loading - try using VPN. Probably you have problem with access to Medium CDN (or fucking Cloudflare's bot detection algorithms are blocking you).