Intro to AWS IAM Enumeration

What this lab covers

You start with a set of AWS credentials and work out exactly what they can do, using the AWS CLI and nothing else. That means identifying the principal, listing the policies attached to it, and reading those policies to understand the permissions they grant.

The lab deliberately avoids automation at first. Tools that summarise permissions are useful later, but they hide the structure, and the structure is the thing worth learning. Once you can read a policy document, every AWS privilege escalation path becomes legible.

It is aimed at anyone new to AWS security, from either direction. Defenders get the skill needed to audit their own accounts, and attackers get the skill that precedes every other technique.

How AWS IAM enumeration works

IAM has a small number of components that combine in a large number of ways. Users and roles are principals, groups collect users, and policies are JSON documents that allow or deny actions against resources. Policies attach to principals directly, through groups, or through the resource itself.

Effective permissions are the result of evaluating all applicable policies together. An explicit deny always wins, permission boundaries cap what identity-based policies can grant, and service control policies constrain entire accounts. This is why reading one attached policy is rarely the full answer.

Enumeration follows a predictable order. Establish which principal your credentials belong to, list attached and inline policies, retrieve the policy documents, then read them for actions that permit further discovery or escalation. Access denied responses are informative too, because they tell you a boundary exists.

How to detect this in your own environment

Enumeration is noisy in the logs even though it is quiet on the network. IAM read calls are recorded as management events in CloudTrail by default, so a principal that suddenly begins listing users, roles and policies is visible without any additional configuration.

The signal is the pattern, not the individual call. Reading one policy is routine. Reading many policies in sequence, especially by an identity that has never done so, is reconnaissance. Baseline which principals legitimately perform IAM reads, and treat the rest as exceptions.

Keep access denied events. An identity probing the edges of its own permissions produces a distinctive burst of failures, and that pattern is often the earliest evidence of a compromised credential. Many log pipelines discard these events to save cost, removing the clearest signal available.

How to prevent it

You cannot prevent an identity from reading its own permissions, and you should not try. What you can control is how much reading is useful, which comes down to whether the identity holds broad discovery permissions it does not need.

Trim IAM read permissions from workload identities. An application that writes to a queue has no reason to list account users or read policy documents, yet broad read access is frequently granted because it is assumed harmless. It is what turns a foothold into a map.

Use permission boundaries and service control policies so that even a well-informed attacker finds the ceiling low. Enumeration is only valuable if it reveals a path, and a properly bounded identity has fewer paths to reveal.

Real-world context

Enumeration precedes essentially every documented cloud intrusion, because an attacker arriving with valid credentials does not know what those credentials are for. Public incident reporting consistently shows a discovery phase between initial access and impact, and that phase is where defenders have the most time to act.

It maps to MITRE ATT&CK T1087 Account Discovery and T1069 Permission Groups Discovery. Both describe activity composed entirely of legitimate API calls, which is why detection depends on behavioral baselines rather than blocking specific actions.

For defenders the same skill has a second use. The fastest way to find over-permissioned identities in your own account is to enumerate them the way an attacker would, which turns an offensive technique into a routine audit.

Applying this at work

• Enumerate your own most privileged roles and read their policy documents end to end. Most teams find at least one wildcard they did not expect.
• List which non-human identities hold IAM read permissions and remove them where they are not required.
• Confirm access denied events are retained in your logging pipeline rather than filtered out.
• Baseline which principals legitimately perform IAM discovery, then alert on the rest.
• Check whether permission boundaries are in use on identities that can create or modify roles.

Frequently asked questions

What is the difference between an IAM user and an IAM role?

A user is a long-lived identity that usually holds static credentials. A role is assumed temporarily and issues short-lived credentials to whoever assumes it. Roles are preferred because the credentials expire, which limits the value of theft.

Is IAM enumeration logged in AWS?

Yes. IAM read operations are management events and appear in CloudTrail without additional configuration. The individual calls are legitimate, so detection relies on recognizing an unusual pattern from a principal with no history of it.

How do I find out what my own credentials can do?

Identify the principal, list its attached and inline policies including those inherited through groups, then read the policy documents. Remember that permission boundaries, resource policies and service control policies can all further constrain the result.

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