Identity and Access Management is the perimeter of the cloud. Misconfigured IAM policies — not software vulnerabilities — are behind a large share of AWS breaches. The dangerous part: a policy can look harmless while silently allowing an attacker (or a compromised workload) to escalate to full administrative access.
Below are seven escalation patterns that appear constantly in real environments, why they are dangerous, and how to detect them before they ship.
1. iam:PassRole with a Wildcard Resource
iam:PassRole lets a principal hand an IAM role to a service (e.g., launch an EC2 instance or Lambda function with that role). If the Resource is * and the principal can also create the service resource, it can pass a highly privileged role and execute code as that role — instant escalation. Always scope PassRole to specific role ARNs and add iam:PassedToService conditions.
2. iam:CreatePolicyVersion on Own Policy
A user who can create a new version of a policy attached to themselves can simply author a version granting *:* and set it as default. This is one of the oldest escalation paths and still appears in permission-boundary misconfigurations.
3. lambda:CreateFunction + lambda:InvokeFunction
Creating a Lambda function with an arbitrary role (via PassRole) and invoking it executes arbitrary code under that role's permissions. The same pattern applies to glue:CreateDevEndpoint, cloudformation:CreateStack, and ec2:RunInstances with a role-bearing instance profile.
4. iam:AttachUserPolicy / AttachRolePolicy
If a principal can attach managed policies to itself or its role, it can attach AdministratorAccess. Restrict attachment permissions with conditions on iam:PolicyARN.
5. iam:CreateAccessKey on Other Users
Creating an access key for another user — especially an admin — yields persistent credentials that bypass MFA assumptions in many setups. Scope CreateAccessKey to the caller's own user only.
6. NotAction / NotResource Traps
NotAction in an Allow statement grants everything except the listed actions — an inverted allowlist that is easy to get wrong. "Action": "NotAction": "iam:*"-style mistakes silently grant broad access. Prefer explicit Action lists; reserve NotAction for tightly-scoped exceptions.
7. Public Principals in Resource Policies
"Principal": "*" or "AWS": "*" in S3 bucket, KMS key, SNS, SQS, or Lambda resource policies can expose data or invoke paths to the entire internet. Combined with missing conditions, this is the classic public-bucket failure mode — but it applies to far more than S3.
How to Catch Them Automatically
Manual review does not scale — AWS has over 18,000 actions and policies combine in non-obvious ways. Paste any policy JSON into our free IAM Policy Validator to instantly flag wildcards, privilege escalation actions, NotAction traps, public principals, and size-limit violations. Everything runs client-side — policies never leave your browser.
Need to verify which account or service an ARN refers to while reviewing policies? Use the AWS ARN Parser to break ARNs into partition, service, region, account ID, and resource components.
Frequently Asked Questions
What is the principle of least privilege?
Grant only the specific actions on the specific resources a workload needs — nothing more. In practice: replace Action: "*" with explicit actions, scope Resource to concrete ARNs, and add conditions (MFA, source IP, PassedToService) where possible.
Are wildcards ever acceptable?
Prefix wildcards like s3:Get* or resource wildcards like arn:aws:s3:::my-bucket/* are reasonable when scoped deliberately. Full *:* or service-level s3:* on Resource: "*" should trigger review.
How often should policies be audited?
Continuously. Validate policies in CI before deployment, enable AWS IAM Access Analyzer for external-access findings, and re-review after any incident or architecture change.
