Unauthenticated AWS IAM Principals Enumeration

What this lab covers

You confirm whether specific IAM users and roles exist in a target account using nothing but policies in an account you control, working through several services that expose the same behavior.

The technique is entirely unauthenticated against the target. Nothing is logged there, no credential is used, and the target has essentially no visibility into it, which is what makes it a first step rather than an attack in itself.

It assumes no prior AWS experience and pairs with the account ID lab, since knowing the account identifier is what makes this possible.

How principal enumeration oracles work

When you write a policy naming a principal in another account, AWS validates that the principal exists before accepting the policy. A valid reference is accepted and an invalid one is rejected, and the difference in response is the information leak.

Several services expose this. Role trust policies, bucket policies and other resource policies all perform the same validation, which means an attacker has multiple interfaces to test against and can pick whichever is most convenient.

The reason it matters is that names are guessable. Organizations name identities from company, environment, team and function, so a confirmed account identifier plus a wordlist yields a validated list of real principals. That list is the input to credential attacks, trust policy abuse and social engineering, all of which work better against confirmed targets.

How to detect this in your own environment

You cannot detect this from the target side, and it is important to state that plainly. The validation occurs in the attacker's account, so there is no event in your logs at all.

What you can detect is what follows. Confirmed principals become targets for authentication attempts, so failed console sign-ins and failed role assumption attempts against real identities are the first observable stage.

Given the absence of upstream visibility, the practical posture is to assume your identity names are known and to invest detection effort in authentication anomalies rather than in the enumeration.

How to prevent it

Make names unpredictable. Including a random component in role and user names defeats wordlist enumeration, because the oracle can only confirm names an attacker thinks to test.

Reduce the value of a confirmed name. Federated access with no long-lived credentials means knowing a role exists provides much less than it would if that role were assumable with a password or a static key.

Assume the account identifier is public and check that no control in your environment depends on it or on identity names being secret.

Real-world context

Cross-account enumeration techniques are standard early steps in external AWS assessments and are implemented in widely used offensive tooling. They are documented behavior rather than a vulnerability, which is why the defensive answer is naming and credential design.

The absence of any signal on the target side is the significant operational point. Most reconnaissance leaves something in a log somewhere, and this leaves nothing, so it is genuinely free for an attacker.

The pattern maps to MITRE ATT&CK T1087 Account Discovery and T1589 Gather Victim Identity Information.

Applying this at work

• Review your IAM naming conventions and consider whether role and user names are derivable from your company and environment names.
• Add a non-guessable component to the names of privileged roles.
• Move human access to federation so that a confirmed identity name yields no directly assumable credential.
• Alert on failed role assumption and console sign-in attempts, which is the first stage you can actually see.
• Confirm nothing in your environment treats account identifiers or identity names as secrets.

Frequently asked questions

Can this enumeration be detected by the target?

No. The policy validation happens in the attacker's own account, so nothing is recorded in the target's logs. The first observable stage is whatever follows, typically authentication attempts against confirmed identities.

What does an attacker gain from knowing a role exists?

A validated target list for credential attacks, trust policy abuse and social engineering. Confirmed names remove the guesswork from every subsequent step and make attempts against real identities rather than noise.

How do I defend against it?

Make identity names unpredictable so wordlists fail, and reduce what a confirmed name is worth by removing long-lived credentials in favour of federated access.

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 attack and detection paths in full, including IAM abuse and privilege escalation, and is assessed hands-on in a live AWS account.