AWS IAM Privilege Escalation: Common Paths and How to Catch Them

Privilege escalation is the moment a limited AWS identity gains permissions it was never meant to have. It rarely comes from a single "admin" policy. Far more often it hides in an innocent-looking combination of permissions that, chained together, let a low-privileged user, role, or compromised credential promote itself to full account control.

Because each individual permission looks reasonable on its own, these paths slip past human review and rule-based scanners alike. Below are the escalation patterns we see most often, why they work, and how to find them in your own policies.

What Makes Privilege Escalation Possible

Every escalation path exploits the same idea: some IAM actions let you change who can do what, or let you run code as a more privileged identity. If a principal can modify policies, attach permissions, pass roles, or create compute that assumes a role, it can usually reach administrator access in one or two steps.

The danger is contextual. iam:PassRole is harmless until it is paired with a service that runs code. iam:CreatePolicyVersion is fine until the principal can point it at a policy attached to itself. Risk lives in the combination, not the line.

The Most Common Escalation Paths

These are the high-frequency patterns documented in IAM privilege escalation research (including the well-known Rhino Security Labs catalog). If a non-admin identity holds any of them, treat it as effectively admin.

• PassRole + RunInstances. iam:PassRole plus ec2:RunInstanceslets a principal launch an EC2 instance with an administrator instance profile, then use that instance's credentials.
• PassRole + Lambda. iam:PassRole with lambda:CreateFunction and lambda:InvokeFunction lets an attacker create a function that runs as a privileged role and execute arbitrary AWS API calls.
• CreatePolicyVersion. iam:CreatePolicyVersion on a managed policy the principal is attached to lets it write a brand-new default version granting "Action": "*".
• AttachUserPolicy / AttachRolePolicy. The ability to attach AdministratorAccess to yourself is a one-call path to full control.
• PutUserPolicy / PutRolePolicy. Inline-policy write permission lets a principal grant itself any permission directly.
• UpdateAssumeRolePolicy.Rewriting a privileged role's trust policy to trust the attacker, then assuming it.
• CreateAccessKey. Minting access keys for a more privileged user.

What an Escalation Policy Looks Like

The policy below grants only two actions. Neither is *, and a quick glance might wave it through a code review. Together they are a direct path to administrator.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "iam:PassRole",
        "ec2:RunInstances"
      ],
      "Resource": "*"
    }
  ]
}

The fix is to scope iam:PassRole to the specific, least-privileged roles the workload actually needs, and constrain it with a iam:PassedToService condition so the role can only be handed to the intended service.

Why Static Tools Miss These

Rule-based linters evaluate permissions in isolation: they flag a wildcard, an iam:*, or a known-bad action. But an escalation path is an interaction between permissions that are individually benign. Detecting it requires reasoning about the attack chain — what each permission unlocks when combined with the others in the same policy and the surrounding account.

How to Find Privilege Escalation in Your Policies

• Inventory the dangerous actions. Search every policy for iam:PassRole, iam:Create*, iam:Attach*, iam:Put*, and iam:UpdateAssumeRolePolicy.
• Scope and condition them. Replace Resource: * with explicit ARNs and add conditions that limit which roles and services are in play.
• Analyze the whole policy, not the line.Shieldly's AI-Powered analysis reads the full policy in context, detects multi-step escalation chains, and returns a risk score plus concrete remediation for each finding — the kind of reasoning rule engines can't do.

Amazon Web Services (AWS) is a trademark of Amazon.com, Inc. Shieldly is not affiliated with, endorsed by, or sponsored by Amazon Web Services.