Skip to content

Beginner-friendly red team icon   aws

Identify the AWS Account ID from a Public S3 Bucket

We created this beginner-friendly lab to teach a technique that can find an AWS account ID given a public S3 bucket, and how this can be leveraged.

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
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.

Attackers leverage SNS's deep integration into automated workflows and its broad permissions to silently deliver confidential information outside the organization. The service's legitimate business purpose provides perfect cover for malicious activity, as data exfiltration disguised as routine notifications rarely raises suspicions among security teams focused on traditional attack vectors like direct database access or file transfers. This technique has proven particularly effective because most organizations implement robust monitoring for their databases and storage systems while neglecting to scrutinize the content and recipients of their notification streams, creating a blind spot that experienced adversaries are quick to exploit.

KEY TAKEAWAY

An AWS account ID is not a secret, but it is the key that makes further reconnaissance possible. Given an account ID, an attacker can test whether specific role and user names exist without ever authenticating, turning a guess about your naming convention into a confirmed list.

What this lab covers

You take a publicly readable S3 bucket and determine which AWS account owns it, then examine how the technique works by reading the source of the tooling that performs it rather than simply running it.

Understanding the mechanism matters more than the result here. The technique relies on how AWS evaluates policy conditions, and once you have seen it, the same reasoning applies to a family of enumeration methods across other services.

It suits anyone doing cloud reconnaissance or defending against it, and assumes no prior AWS experience. The takeaway for defenders is what an externally visible bucket discloses beyond its contents.

How AWS account ID disclosure works

AWS resource policies can include conditions that compare the resource owner against a supplied value. That comparison supports wildcards, and the request either succeeds or fails depending on whether the condition matches, which turns a policy evaluation into a yes or no oracle.

By testing one character position at a time, an account identifier can be recovered digit by digit without any credentials for the target account and without triggering an authentication failure in it. The work is done by the requesting side, using the target's own policy evaluation as the response channel.

The account ID by itself does nothing. Its value is that it enables role and user enumeration: an attacker can attempt to reference a principal in a trust policy and learn from the resulting error whether that principal exists. Names are guessable because organizations use consistent conventions, so a confirmed account ID converts naming convention into a validated target list.

How to detect this in your own environment

This is genuinely difficult to detect from the target side, and it is important to say so rather than pretend otherwise. The probing happens against a public endpoint, and principal existence checks occur in the attacker's account, not yours.

What you can detect is the follow-on activity. Enumeration of this kind is preparation for credential attacks against named principals, so the observable phase is usually attempted role assumption or console sign-in against identities that were just confirmed to exist.

The practical position is to assume your account ID is discoverable if you host anything publicly, and to design so that knowing it is not useful. Detection effort is better spent on authentication anomalies than on the discovery itself.

How to prevent it

Do not rely on the account ID being secret. Treat it as public information, because for any organization with a public bucket, a public image or a partner integration, it effectively is.

Break the naming convention advantage. Predictable role and user names are what make a confirmed account ID valuable, so including a non-guessable component in identity names materially raises the cost of enumeration.

Reduce public surface. Enable block public access at the account level and use presigned URLs or a content delivery layer where public distribution is genuinely needed, so buckets are not directly addressable in the first place.

Real-world context

This class of technique is well documented in cloud security research and is a standard early step in external cloud assessments. It is a reconnaissance capability rather than a vulnerability, and AWS treats the account ID as non-sensitive by design.

The reason it matters operationally is chaining. Reconnaissance that costs the attacker nothing and produces no signal on the target side is the ideal starting point, and every subsequent technique benefits from knowing which identities exist.

It maps to MITRE ATT&CK T1580 Cloud Infrastructure Discovery and T1087 Account Discovery.

Applying this at work

  • Audit which of your buckets are publicly readable, and enable account-level block public access wherever public access is not a deliberate requirement.
  • Review your IAM naming conventions and consider whether role and user names are guessable from your company name and environment names alone.
  • Assume your account IDs are known when threat modeling, and check that no control in your environment depends on them being secret.
  • Monitor for failed role assumption attempts referencing principals in your accounts.
  • Where public distribution is required, serve content through a distribution layer rather than exposing the bucket directly.

Frequently asked questions

Is an AWS account ID considered sensitive?

AWS does not treat it as a secret, and it appears in many resource identifiers. It is best regarded as public information. The risk is not disclosure itself but what it enables, which is validating whether specific roles and users exist.

What can someone do with my AWS account ID?

Primarily principal enumeration. They can test whether particular role or user names exist in your account without authenticating, which converts guessed naming conventions into a confirmed target list for credential and trust policy attacks.

Can I stop my account ID being discovered?

Not reliably, if you host anything publicly. The better approach is to design so that knowing it provides no advantage, principally by avoiding predictable identity names and reducing public bucket exposure.

Do I need my own AWS account to practice this?

No. The lab runs in a live AWS environment that Pwned Labs provisions for you, so there is nothing to set up and no risk to your own infrastructure.

Which certification covers this in depth?

The Amazon Cloud Red Team Professional (ACRTP) covers AWS reconnaissance, IAM abuse and privilege escalation in full, and is assessed hands-on in a live AWS account.