AWS IAM misconfigurations are among the most reliably exploited attack vectors in cloud environments. Unlike a software vulnerability, these flaws require no sophisticated exploit. An attacker who gets hold of even limited credentials can, through a handful of well-chosen API calls, work their way up to full account control. The privilege escalation path is documented, repeatable, and yet consistently underestimated until it shows up in a real incident.
The three most dangerous IAM mistakes in AWS
Wildcard policies on iam:*
Granting iam:* to any user or role hands over the keys to the entire IAM plane. With that permission, the entity can create a new user, attach an AdministratorAccess policy to it, and operate freely under that new identity. The escalation takes exactly two API calls: iam:CreateUser followed by iam:AttachUserPolicy. These policies tend to appear in development environments that get cloned into production, or in permissions written quickly under deadline pressure and never revisited.
Assumable roles without restrictive conditions
An IAM role with an overly permissive trust policy — typically "Principal": {"AWS": "*"}, or no condition restricting the source IP, MFA status, or AWS Organization — can be assumed by any authenticated entity, sometimes even from an external account. In a typical scenario, an attacker compromises a Lambda function with narrow permissions, discovers that a highly privileged role is assumable without any condition from any resource in the same account, and calls sts:AssumeRole immediately. The privilege jump is instant.
Unrotated (or simply existing) root access keys
AWS strongly advises against creating programmatic access keys for the root account, but those keys exist in many environments — often created during initial setup and never removed. An active root key is not subject to any IAM policy restriction: it carries every right in the account by definition, including disabling MFA and removing Organizations guardrails. If that key leaks — through a public Git repository, a poorly versioned config file, or a third-party vendor incident — the compromise is total and immediate.
A realistic privilege escalation path to full account control
A real escalation rarely starts with elevated rights. The attacker begins with weak credentials: a developer user with ReadOnly access to S3 and a few EC2 actions. The first phase is enumeration — which policies are attached, which roles exist in the account, which ones are assumable. This is where PMapper becomes essential.
PMapper (Principal Mapper) builds a directed graph of all IAM entities in the account and the transition paths between them. It automatically detects where entity A can reach the privileges of entity B, directly or through several intermediaries. An entity with iam:PassRole and ec2:RunInstances can, for instance, launch an instance with an admin role attached and execute commands via SSM. PMapper calculates that path without requiring any manual graph construction from the operator.
Once the path is identified, the exploitation itself is handled by Pacu, the open-source AWS offensive framework. Pacu includes modules specifically designed for IAM privilege escalation: iam__privesc_scan enumerates applicable techniques for the current identity, iam__backdoor_users_keys creates persistent backdoors, and several modules cover vectors like inline policy creation or IAM group manipulation. Together they form a coherent attack chain from reconnaissance through persistence.
Why these misconfigurations persist despite being well-known
Most cloud teams know these risks in theory. The problem is operational. Permissive policies are usually born from urgency: a service was broken, permissions got broadened to unblock it, and no one came back to tighten them afterward. Unconstrained assumable roles often come from Infrastructure-as-Code templates copied from public examples without carefully reading the Trust Policy section. Root keys are sometimes unknown to current teams, inherited from an initial configuration done by an external contractor.
Visibility is the other obstacle. Without a mapping tool, identifying that an escalation path exists between two IAM entities in an account with hundreds of roles is an exhausting manual exercise. Hands-on practice environments close that gap effectively — browsing AWS cloud security labs gives teams a structured way to practice detecting and remediating these paths before an attacker finds them first.
Concrete remediation steps
Audit and restrict existing IAM policies
Start with a full policy export via aws iam get-account-authorization-details and scan for wildcard occurrences on sensitive actions (iam:*, sts:*, s3:*). AWS Access Analyzer surfaces unintended external access. Running PMapper regularly catches new escalation paths introduced by each policy change.
Harden role trust policies
Every role needs an explicit condition in its trust policy: restriction to a specific source ARN, an aws:PrincipalOrgID condition for Organizations environments, or an MFA requirement for critical roles. A role that has no legitimate reason to be assumed from an external account should never allow it.
Delete root keys and activate organizational guardrails
Root access keys must be deleted, not just deactivated. AWS CloudTrail should be enabled across all regions with an alert on any root usage. In multi-account setups, Service Control Policies (SCPs) can explicitly deny any action performed with root credentials on member accounts.
Making IAM security a continuous practice
A one-time IAM audit has limited shelf life. Configurations drift with every deployment, every new service integration, every team change. IAM posture should be treated like code — versioned, tested, reviewed. Static analysis pipelines for CloudFormation or Terraform templates, regular escalation simulation exercises, and tools like automated policy diff reviews keep the risk picture accurate over time. Teams looking to assess their current cloud IAM exposure will find that a structured review of existing permissions is the most actionable starting point.
Frequently asked questions
What exactly is IAM privilege escalation in AWS?
It is the process by which an attacker starts from limited access and obtains progressively higher privileges — up to full account control in the worst cases — by chaining API calls that are individually permitted by misconfigured IAM policies. No system exploit is required: only the IAM logic itself is leveraged.
Are PMapper and Pacu only used for Red Team exercises?
No. PMapper is widely used defensively by security teams and Cloud Security Architects to map existing IAM risks without exploiting anything. Pacu is typically used in lab environments or during authorized penetration tests to validate paths that PMapper identifies. The two tools are complementary in any structured audit workflow.
How can I tell if my AWS account has active root access keys?
AWS provides a credential report (aws iam generate-credential-report) that lists all IAM entities, including the root account, along with their access key status and last-used date. An active root key with a recent usage date is an immediate red flag that warrants urgent action.
Are IAM wildcards always dangerous?
A wildcard covering read-only actions on services with no lateral movement potential carries limited risk. The danger lies in wildcards on IAM, STS, Organizations, or code execution services like Lambda, EC2, and ECS — those open concrete escalation paths. The principle of least privilege remains the only reliably safe baseline.