Identify the AWS Account ID from a Public S3 Bucket

Picture By Leonardo AI | AWS

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.

Enumeration

The scan shows that port 53 (TCP) is open and running ISC BIND 9.16.23 on RedHat Linux. Port 80 (TCP) is also open, hosting an Apache HTTP server (version 2.4.52) on Ubuntu. The server’s title is ‘Mega Big Tech,’ and the HTTP response headers confirm its running Apache 2.4.52 on Ubuntu.

┌──(root㉿kali)-[/home/kali/AWS]
└─# nmap -sC -sV -A 54.204.171.32 -T4       
Starting Nmap 7.95 ( https://nmap.org ) at 2025-02-17 17:47 EST
Nmap scan report for ec2-54-204-171-32.compute-1.amazonaws.com (54.204.171.32)
Host is up (0.13s latency).
Not shown: 998 filtered tcp ports (no-response)
PORT   STATE SERVICE VERSION
53/tcp open  domain  ISC BIND 9.16.23 (RedHat Linux)
| dns-nsid: 
|_  bind.version: 9.16.23-RH
80/tcp open  http    Apache httpd 2.4.52 ((Ubuntu))
|_http-server-header: Apache/2.4.52 (Ubuntu)
|_http-title: Mega Big Tech
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: general purpose|router|storage-misc
Running (JUST GUESSING): Linux 2.6.X|3.X|4.X|5.X (87%), MikroTik RouterOS 7.X (87%), Synology DiskStation Manager 5.X (85%)
OS CPE: cpe:/o:linux:linux_kernel:2.6.32 cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel:5 cpe:/o:mikrotik:routeros:7 cpe:/o:linux:linux_kernel:5.6.3 cpe:/o:linux:linux_kernel:6.0 cpe:/a:synology:diskstation_manager:5.2
Aggressive OS guesses: Linux 2.6.32 (87%), Linux 2.6.32 - 3.13 (87%), Linux 3.10 (87%), Linux 3.10 - 4.11 (87%), Linux 3.2 - 4.14 (87%), Linux 3.4 - 3.10 (87%), Linux 4.15 (87%), Linux 4.15 - 5.19 (87%), Linux 4.19 (87%), Linux 5.0 - 5.14 (87%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 25 hops
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

TRACEROUTE (using port 80/tcp)
HOP RTT       ADDRESS
1   13.63 ms  192.168.0.1
2   15.48 ms  10.14.161.1
3   ... 4
5   19.71 ms  10.240.254.53
6   ... 8
9   18.36 ms  10.200.22.1
10  17.00 ms  static-65.115.194.14-tataidc.co.in (14.194.115.65)
11  9.34 ms   10.124.248.81
12  11.21 ms  115.113.172.125.static-kolkata.vsnl.net.in (115.113.172.125)
13  82.12 ms  172.28.176.253
14  188.48 ms ix-ae-0-100.tcore1.mlv-mumbai.as6453.net (180.87.38.5)
15  246.71 ms if-be-13-2.ecore1.mlv-mumbai.as6453.net (180.87.38.29)
16  322.19 ms if-be-47-2.ecore1.emrs2-marseille.as6453.net (80.231.217.52)
17  326.42 ms if-bundle-15-2.qcore1.pye-paris.as6453.net (80.231.154.32)
18  ...
19  340.08 ms 63.243.137.148
20  ... 24
25  279.83 ms ec2-54-204-171-32.compute-1.amazonaws.com (54.204.171.32)

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 49.86 seconds

Web Page

This brings us to the website for Mega Big Tech. There doesn’t appear to be any noteworthy functionality, so let’s take a look at the source code.

 <section class="product-mac">
    <div class="container">
      <h2>WorkPro</h2>
      <div class="grid">
        <div class="grid-product">
          <img src="https://mega-big-tech.s3.amazonaws.com/images/workpro1.jpg">
          <div class="grid-detail">
            <p>WorkPro</p>
            <p>From $5,000</p>
          </div>
        </div>

This shows that the images are hosted on an Amazon S3 bucket named ‘mega-big-tech’.

<?xml version="1.0" encoding="UTF-8"?>
<ListBucketResult xmlns="http://s3.amazonaws.com/doc/2006-03-01/"><Name>mega-big-tech</Name><Prefix></Prefix><Marker></Marker><MaxKeys>1000</MaxKeys><IsTruncated>false</IsTruncated><Contents><Key>images/</Key><LastModified>2023-06-25T22:40:57.000Z</LastModified><ETag>&quot;d41d8cd98f00b204e9800998ecf8427e&quot;</ETag><Size>0</Size><StorageClass>STANDARD</StorageClass></Contents><Contents><Key>images/banner.jpg</Key><LastModified>2023-06-25T22:42:34.000Z</LastModified><ETag>&quot;3ad5c014c01ffeb0743182379d2cd80d&quot;</ETag><Size>3184176</Size><StorageClass>STANDARD</StorageClass></Contents><Contents><Key>images/notepro1.jpg</Key><LastModified>2023-06-25T22:42:35.000Z</LastModified><ETag>&quot;f5435f26a11fac38006d8fe32ed75045&quot;</ETag><Size>941294</Size><StorageClass>STANDARD</StorageClass></Contents><Contents><Key>images/notepro2.jpg</Key><LastModified>2023-06-25T22:42:36.000Z</LastModified><ETag>&quot;c7b217afa365714334597643889c5daa&quot;</ETag><Size>1660205</Size><StorageClass>STANDARD</StorageClass></Contents><Contents><Key>images/notepro3.jpg</Key><LastModified>2023-06-25T22:42:37.000Z</LastModified><ETag>&quot;11acc403ec7efabdf2743404e1fc6be7&quot;</ETag><Size>490794</Size><StorageClass>STANDARD</StorageClass></Contents><Contents><Key>images/notepro4.jpg</Key><LastModified>2023-06-25T22:42:38.000Z</LastModified><ETag>&quot;2ba1a84a0908e91bec8d05981c28fc40&quot;</ETag><Size>2415092</Size><StorageClass>STANDARD</StorageClass></Contents><Contents><Key>images/phonepro1.jpg</Key><LastModified>2023-06-25T22:42:39.000Z</LastModified><ETag>&quot;8b2541f6138dd34e392f45fc6ab8ba6f&quot;</ETag><Size>1003564</Size><StorageClass>STANDARD</StorageClass></Contents><Contents><Key>images/phonepro2.jpg</Key><LastModified>2023-06-25T22:42:40.000Z</LastModified><ETag>&quot;f9bf19e16a9a31a6754d7c55d0576ec4&quot;</ETag><Size>1277058</Size><StorageClass>STANDARD</StorageClass></Contents><Contents><Key>images/phonepro3.jpg</Key><LastModified>2023-06-25T22:42:41.000Z</LastModified><ETag>&quot;c5e3b974eb2a8cc3cb6cd7f14a358419&quot;</ETag><Size>2322525</Size><StorageClass>STANDARD</StorageClass></Contents><Contents><Key>images/phonepro4.jpg</Key><LastModified>2023-06-25T22:42:42.000Z</LastModified><ETag>&quot;e77b77f088be31b907562c1c08d3c1ea&quot;</ETag><Size>4080373</Size><StorageClass>STANDARD</StorageClass></Contents><Contents><Key>images/watchpro1.jpg</Key><LastModified>2023-06-25T22:42:43.000Z</LastModified><ETag>&quot;8c6b69baa95f5a7ed0f9d2e1dae73160&quot;</ETag><Size>1160096</Size><StorageClass>STANDARD</StorageClass></Contents><Contents><Key>images/watchpro2.jpg</Key><LastModified>2023-06-25T22:42:44.000Z</LastModified><ETag>&quot;ab66d316fbdfa90eea53e89855dc243f&quot;</ETag><Size>2877784</Size><StorageClass>STANDARD</StorageClass></Contents><Contents><Key>images/watchpro3.jpg</Key><LastModified>2023-06-25T22:42:46.000Z</LastModified><ETag>&quot;a105349b350b257b05438dbc1c8fbe4d&quot;</ETag><Size>3232387</Size><StorageClass>STANDARD</StorageClass></Contents><Contents><Key>images/watchpro4.jpg</Key><LastModified>2023-06-25T22:42:47.000Z</LastModified><ETag>&quot;f5315cb77b5de5a74c13417e185d3953&quot;</ETag><Size>3041540</Size><StorageClass>STANDARD</StorageClass></Contents><Contents><Key>images/watchpro5.jpg</Key><LastModified>2023-06-25T22:42:49.000Z</LastModified><ETag>&quot;f137be90eec86dd71da37f25bdc5452e&quot;</ETag><Size>3400957</Size><StorageClass>STANDARD</StorageClass></Contents><Contents><Key>images/workpro1.jpg</Key><LastModified>2023-06-25T22:42:50.000Z</LastModified><ETag>&quot;ee9140f394608d8ed638c9b39b9c1c4f&quot;</ETag><Size>1632585</Size><StorageClass>STANDARD</StorageClass></Contents><Contents><Key>images/workpro2.jpg</Key><LastModified>2023-06-25T22:42:51.000Z</LastModified><ETag>&quot;fd33607a6406f4a6cb1550cba96ea200&quot;</ETag><Size>1081259</Size><StorageClass>STANDARD</StorageClass></Contents><Contents><Key>images/workpro3.jpg</Key><LastModified>2023-06-25T22:42:54.000Z</LastModified><ETag>&quot;78fec3d6d2c81294346fa618ba0caf00&quot;</ETag><Size>1599810</Size><StorageClass>STANDARD</StorageClass></Contents><Contents><Key>images/workpro4.jpg</Key><LastModified>2023-06-25T22:42:56.000Z</LastModified><ETag>&quot;9a70d62b2f2bd2bf6604943bde09f6bd&quot;</ETag><Size>1144134</Size><StorageClass>STANDARD</StorageClass></Contents></ListBucketResult>

Checking the bucket in the browser reveals an ‘images’ directory containing more images, but nothing particularly interesting.

Once we have the S3 bucket name, we can try to determine the AWS Account ID that owns it. Security researcher Ben Bridts has shown that brute-forcing an AWS Account ID for an S3 bucket is possible. You can read his research post and review the code here for more details.

The core idea is that the script creates a policy leveraging the S3:ResourceAccount Policy Condition Key, which evaluates whether access should be granted based on the AWS account tied to the S3 bucket. Instead of randomly guessing billions of account IDs, the script intelligently reduces the possible search space by using string matching and wildcards. Each correctly identified digit is stored, and the process continues until the full account ID is discovered.

For this task, we have provided a user with a role that can be assumed to perform the attack. However, if you prefer to set up the user and role yourself, the necessary policies are listed below.

The IAM user taking on the role must have the following policy attached.

{
    "Version": "2012-10-17",
    "Statement": {
        "Effect": "Allow",
        "Action": "sts:AssumeRole",
        "Resource": "arn:aws:iam::<your aws account id>:role/<your role name>"
    }
}

The role your user can assume has a policy that grants s3:GetObject and s3:ListBucket permissions for the mega-big-tech bucket.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Enum",
            "Effect": "Allow",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::mega-big-tech/*"
        },
        {
            "Sid": "Enum1",
            "Effect": "Allow",
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::mega-big-tech"
        }
    ]
}

The role would also include the following trust policy, which permits the user to take on the role.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::<your aws account id>:user/s3enum"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

We’ll use our existing user moving forward. Start by setting the provided credentials with aws configure. This allows us to execute commands as the user who can assume the role with the s3:GetObject and s3:ListBucket permissions. Assuming a role with one of these permissions is necessary for the script to work.

┌──(root㉿kali)-[/home/kali/AWS]
└─# aws configure                                         
AWS Access Key ID [****************FGCD]: AKIAWHEOTHRFW4CEP7HK
AWS Secret Access Key [****************Y6jP]: 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
Default region name [us-east-1]: 
Default output format [None]: 
                                                                                                                    
┌──(root㉿kali)-[/home/kali/AWS]
└─# aws sts get-caller-identity                           
{
    "UserId": "AIDAWHEOTHRF62U7I6AWZ",
    "Account": "427648302155",
    "Arn": "arn:aws:iam::427648302155:user/s3user"
}

1. sudo apt install python3-venv
2. python3 -m venv venv
3. source venv/bin/activate
4. pip install s3-account-search

First, create a virtual environment to install the s3-account-search tool. Follow these steps:

1. Install the Python virtual environment package.
2. Create a new virtual environment.
3. Activate the virtual environment.
4. Install the s3-account-search tool.

Once that’s done, you can proceed to provide the Amazon Resource Name (ARN) of the role under your control (in your AWS account) and specify the target S3 bucket in the AWS account whose ID you want to enumerate. The command will look like this:

s3-account-search arn:aws:iam::427648302155:role/LeakyBucket mega-big-tech

┌──(venv)─(root㉿kali)-[/home/kali]
└─# s3-account-search arn:aws:iam::427648302155:role/LeakyBucket mega-big-tech
Starting search (this can take a while)
found: 1
found: 10
found: 107
found: 1075
found: 10751
found: 107513
found: 1075135
found: 10751350
found: 107513503
found: 1075135037
found: 10751350379
found: 107513503799

This reveals the AWS account ID 107513503799. We can use this information to search for publicly exposed resources, such as public EBS or RDS snapshots, that might have been unintentionally shared by the account owner.

To proceed, it’s essential to identify the AWS region where the S3 bucket resides, as public snapshots are available in the same region. If the S3 bucket is in a particular region, other resources could also be exposed there.

To find the region of the S3 bucket, we can use a simple cURL trick.

┌──(kali㉿kali)-[~]
└─$ curl -I https://mega-big-tech.s3.amazonaws.com
HTTP/1.1 200 OK
x-amz-id-2: wvNpGkjc19GcRdsMvlsrHvB5H9Z+LY1ZTAYT0ce2mAsEd1HjBDCD+jBPFe+kBlImpJme2BamURM=
x-amz-request-id: WZPV5AW4P7XFRQN8
Date: Mon, 17 Feb 2025 23:52:47 GMT
x-amz-bucket-region: us-east-1
x-amz-access-point-alias: false
Content-Type: application/xml
Transfer-Encoding: chunked
Server: AmazonS3

In the response headers, we can see that the x-amz-bucket-region is set to us-east-1, which corresponds to North Virginia. Now, log into the AWS Management Console using your personal AWS account and ensure that the us-east-1 region is selected.

Console Home

Next, search for the EC2 service in the AWS Management Console. Click on the service, and in the EC2 dashboard, navigate to the left-hand menu. Under the Elastic Block Store section, select Snapshots. In the dropdown list, choose Public snapshots, then paste the discovered AWS account ID into the field and hit Enter/Return. After a brief wait, you’ll get a result showing that the company has a publicly exposed EBS snapshot! PWNED!

Snapshots

The objective of this lab is to identify the AWS account ID associated with the S3 bucket, which will serve as the flag.

Additionally, you can use the following CLI command to list public EBS snapshots created in the AWS account:

aws ec2 describe-snapshots --owner-ids 107513503799 --query 'Snapshots[]' --region=us-east-1

Snapshots in CLI

Although AWS account IDs are not inherently sensitive — often appearing in public documentation or source code — they can still be useful in a security assessment. Identifying an organization’s AWS account ID can help pinpoint public resources or uncover potential misconfigurations tied to that account.

From a detection standpoint, the STS actions used in this method are executed within the enumerator’s AWS account. As a result, these actions do not generate logs that the S3 bucket owner can view. However, for improved monitoring, the bucket owner can enable S3 data events, albeit at an additional cost, to log access attempts and other relevant activities.

I hope you enjoyed this writeup! Happy Hacking :)

Subscribe to me on Medium and be sure to turn on email notifications so you never miss out on my latest walkthroughs, write-ups, and other informative posts.

Follow me on below Social Media:

1. LinkedIn: Reju Kole

2. Instagram: reju.kole.9

3. Respect me On HackTheBox! : Hack The Box :: User Profile

4. Check My TryHackMe Profile : TryHackMe | W40X

5. Twitter | X : @Mr_W40X

6. GitHub : W40X | Reju Kole | Security Researcher

incase you need any help feel free to message me on my social media handles.