Well, it's just an AWS Account ID!

Let’s dive into a highly debated topic common in the AWS Security Community: AWS Account IDs.

You might think, "It's just a number, right?" Well, let’s see if you hold on to the same opinion by the end of this post.

What's the Big Deal with AWS Account IDs?

First things first, let's get our basics straight.

Every AWS account has a unique 12-digit identifier.

1. These IDs are part of most AWS resource's Amazon Resource Name (ARN).

2. They're crucial for sharing resources between accounts (using resource policies or Resource Access Manager)

3. They're used in sharing resources outside your AWS accounts, especially with external vendors.

In simple terms, your AWS Account ID is your identity in the AWS cloud. If someone needs to access your resources or if you need to intentionally share your resources with others, you need to provide them with your AWS Account ID.

The Power of Knowing an Account ID

Imagine you're a red teamer or black box pentester (or worse, an attacker). With just an Account ID, you can:

Bruteforce IAM Entities: You can bruteforce for the existence of common IAM users and roles. This information is gold for phishing attacks, social engineering, or password spraying. You can also see the user name patterns for IAM users (especially those of the target’s infra or DevOps team). An attacker with this information could craft convincing phishing emails or vishing scripts targeting the company's cloud team.

Discover Services in Use: By checking for specific AWS Service Linked Roles, you can deduce which AWS services or third-party security tools a company uses.

Example: If you find a role named AWSServiceRoleForAmazonGuardDuty, the account might use GuardDuty for threat detection. I say “might” here because enabling an AWS service like GuardDuty will create the service-linked role. But if you turn it off, AWS will not delete the role. If the role doesn’t exist, it's 100% certain that GuardDuty is not enabled in the target account.

Note: You can use the same technique to determine whether the target AWS account uses services like EKS or ECS, allowing you to fine-tune your attacks and web app payloads.

Find Public Resources: You can search for the target company's unintentional public resources, from public EBS snapshots to AMIs.

• EBS Snapshots: https://us-east-1.console.aws.amazon.com/ec2/home?region=us-east-1#Snapshots:visibility=public;sort=snapshotId

• RDS Snapshots: https://us-east-1.console.aws.amazon.com/rds/home?region=us-east-1#snapshots-list:tab=public

• DocumentDB Snapshots: https://us-east-1.console.aws.amazon.com/docdb/home?region=us-east-1#snapshots

• Neptune Snapshots: https://us-east-1.console.aws.amazon.com/neptune/home?region=us-east-1#snapshots:type=public

• Public AMIs: https://us-east-1.console.aws.amazon.com/ec2/home?region=us-east-1#Images:visibility=public-images

Correlate Resources (Niche): You can confirm if a leaked resource belongs to a specific company.

Account IDs can be crucial in HackerOne or other bug bounty reports where you can correlate a misconfigured S3 bucket leaking PII belonging to the target company by matching Account IDs.

Evade Detection (Niche): Some security tools, like CanaryTokens.org, create credentials from known AWS accounts. Identifying the account ID of these intentionally leaked credentials before checking out their permissions will avoid triggering alarms.

Real-world example

Imagine you found a public object hosted on your target’s S3 bucket. It could be anything - a PDF, an image file, or just some javascript and CSS files:

https://cloudsecclub-bucket.s3.amazonaws.com/some.jpg

You can extract the Account ID from this URL with s3-account-search tool. Now what?

1. You can look for public EBS snapshots, RDS backups, or AMIs.

2. You can even try to guess IAM user names (just search for the target’s employees on LinkedIn).

3. You can enumerate IAM service-linked roles to check out the AWS services in use (probably). Or even stumble upon any security tools they use in the company (Wiz, Datadog, etc.)

Each piece of information you gather paints a clearer picture of the company's AWS footprint. And remember, we started with just a bucket URL!

The Recon Goldmine

In my cloud security research, I've seen Account IDs pop up in multiple places:

• GitHub repositories (especially in IaC code)

• Error logs on Stack Overflow

• Public Docker images (including public ECR images)

• Even in the documentation of security vendors!

The Bigger Picture

So, Is the AWS Account ID a Security Risk?

Here's my take: The Account ID is useless and not a direct weakness. It's more like a key that helps with other cloud attacks.

Knowing someone's home address isn't a security breach. But if that address helps a burglar plan their approach, it becomes part of the security equation.

The sensitivity of AWS Account IDs arises from their ability to fetch and correlate resources and gather information for other attacks.

What I do know is it’s a powerful technique in your recon or red team process.

Worried about your AWS Account exposing public resources?

What if you could ensure you have no unintended public assets to begin with?

My upcoming course, "Secure AWS: Strategies for Lean Teams," teaches you to lock down your entire AWS environment, not just manage Account IDs. Learn to prevent resource exposure, implement robust controls, and avoid costly mistakes - all tailored for lean teams. 🔥 

Early Bird Alert: Enroll now for a 60% discount and transform your AWS security posture from reactive to proactive!