S3 Bucket Sniffing — awsomecloud.io

When performing cloud security assessments or bug bounties, discovering an S3 bucket is often just the beginning. What many researchers don't realise is that a publicly accessible S3 bucket can be a stepping stone to uncovering the AWS Account ID behind it and from there, potentially exposed snapshots, misconfigurations, and more.

In this post, we'll walk through how to enumerate an AWS Account ID from an S3 bucket name, find the bucket's region, and discover publicly exposed EBS snapshots.

Step 1: Finding the S3 Bucket Name

The first step is simply identifying the target S3 bucket. This can happen in a number of ways source code leaks, exposed environment variables, JavaScript files, or even DNS enumeration. Once you have a bucket name (for example, bank-of-mumdad), you can browse it directly in your browser:

https://bank-of-mumdad.s3.amazonaws.com

Inspecting the bucket may reveal directories and files. Even if nothing immediately sensitive is found, the bucket name itself is a valuable foothold.

Step 2: Enumerating the AWS Account ID

Research by Ben Bridts revealed a clever technique to brute-force the AWS Account ID that an S3 bucket belongs to. The method leverages the S3:ResourceAccount Policy Condition Key, which allows a policy to grant or deny access to an S3 bucket based on the AWS account it belongs to.

The tool s3-account-search automates this process. Rather than guessing all possible account IDs, it uses string matching and wildcards to progressively narrow down the correct digits drastically reducing the search space.

Setting Up Your Infrastructure

You'll need an IAM user and role in your own AWS account.

1. Create an IAM User with permission to assume a role:

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

2. Create a Role with S3 permissions:

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

Trust Policy:

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

Running the Tool

Configure your AWS credentials:

aws configure

Install the tool:

python3 -m pip install s3-account-search

Add it to your PATH if needed:

echo 'export PATH=$PATH:~/.local/bin' >> ~/.bashrc
source ~/.bashrc

Then run the enumeration:

s3-account-search arn:aws:iam::000000000:role/LeakyBucket bank-of-mumdad

This will return the AWS Account ID — in this example, 0000222211111.

Step 3: Finding the Bucket's Region

Knowing the region the bucket was created in helps you narrow down where other resources (like EBS snapshots) might live. Use curl to inspect response headers:

curl -I https://bank-of-mumdad.s3.amazonaws.com

Look for the x-amz-bucket-region header in the response. In this case, it reveals us-east-1 (North Virginia).

Step 4: Discovering Public EBS Snapshots

With the AWS Account ID and region in hand, you can search for publicly exposed EBS snapshots. Log into your AWS Console, navigate to EC2 → Elastic Block Store → Snapshots, and select Public Snapshots. Paste in the discovered Account ID and search.

A hit here means the target organisation has accidentally exposed an EBS snapshot to the public — a significant security finding.

Detection & Defensive Considerations

It's worth noting that the STS actions used in this technique occur within the attacker's own AWS account, meaning they won't appear in the target account's CloudTrail logs by default. However, bucket owners can enable S3 data events (at additional cost) to gain visibility into access patterns.

While AWS Account IDs aren't considered highly sensitive secrets on their own, they can appear in public documentation and code — knowing one during a security assessment can meaningfully accelerate the attack path.