Enumerate AWS Account IDs

To maintain security, AWS Account IDs should be handled carefully, even though they are not deemed confidential. While they are not secrets, they can lead to exposure of sensitive resources or data.

Are AWS Account IDs considered to be a secret?

• AWS has long said that AWS Account IDs are not secret

While account IDs, like any identifying information, should be used and shared carefully, they are not considered secret, sensitive, or confidential information.

What is the risk of exposed AWS Account IDs?

• Knowing an AWS Account ID can lead to discovering information that could be used to compromise an account. For example, knowing the AWS Account ID lets us find public resources (e.g., EBS or RDS snapshots, AMIs, etc.) that could contain credentials or other sensitive information.

---

Methods to Enumerate AWS Account IDs

Using valid AWS Access Keys

• With valid AWS Access Keys, we can use an AWS CLI command

aws --profile dev sts get-caller-identity 
                                                                                 
{
    "UserId": "AIDAxxxxxxx",
    "Account": "111111111111",
    "Arn": "arn:aws:iam::111111111111:user/dev_user"
}

---

Using AWS Access Key ID

• With just a valid AWS Access Key ID, we can use an AWS CLI command

• You must have valid access keys configured for this to work but these can be from your own account i.e., it doesn't need to be credentials from the same account as the access key id found

aws sts get-access-key-info --access-key-id AKIAxxxxxxxxxx
{
    "Account": "111111111111"
}

---

Using an S3 Bucket Name

• Knowing the name of an AWS S3 bucket, we can use s3-account-search to identify the account ID

• The bucket must be public or otherwise accessible by the IAM Role used

s3-account-search --profile dev arn:aws:iam::111111111111:role/s3-enumerator s3bucketnamehere
 
Starting search (this can take a while)
found: 1
found: 11
found: 112
found: 1123
found: 11234
found: 112345
found: 1123456
found: 11234567
found: 112345678
found: 1123456789
found: 11234567890
found: 112345678901

---

Using EC2 metadata

• The EC2 metadata service (IMDS) provides the AWS Account ID in the instance identity document

• This method requires code execution on the target EC2 as IMDS is a local service

IMDSv1

curl http://169.254.169.254/latest/dynamic/instance-identity/document

{
  "accountId" : "111111111111",
  "architecture" : "x86_64",
  "availabilityZone" : "us-west-2b",
  "billingProducts" : null,
  "devpayProductCodes" : null,
  "marketplaceProductCodes" : null,
  "imageId" : "ami-xxxxxxxxxx",
  "instanceId" : "i-xxxxxxxxxx",
  "instanceType" : "t2.micro",
  "kernelId" : null,
  "pendingTime" : "2024-12-08T03:46:08Z",
  "privateIp" : "172.31.30.110",
  "ramdiskId" : null,
  "region" : "us-west-2",
  "version" : "2017-09-30"

IMDSv2

---

Using Amazon Bedrock API Keys

Short-Term API Keys

Option 1

• You must have valid access keys configured for this to work but these can be from your own account i.e., it doesn't need to be credentials from the same account as the access key id found

aws --profile attacker sts get-access-key-info --access-key-id ASIA[REDACTED]
{
    "Account": "111111111111"
}

Option 2

• Otherwise, we can discover the account id without any credentials

echo $AWS_BEARER_TOKEN_BEDROCK | base64 -d | LC_ALL=C sed -n 's/.*X-Amz-Security-Token=\([^&]*\).*/\1/p' | python3 -c "import sys, urllib.parse; print(urllib.parse.unquote(sys.stdin.read().strip()))" | base64 -d

Long-term API Keys

echo $AWS_BEARER_TOKEN_BEDROCK | base64 -d