AWS_UPDATE_POLICY_AND_ASSUME

Summary

Forestall ACL Alias	AWS_UPDATE_POLICY_AND_ASSUME
AD Alias	N/A
Affected Object Types	AWSUser|AWSRole → AWSRole
Exploitation Certainty	High
AWS IAM Action	(iam:PutRolePolicy | iam:AttachRolePolicy) + sts:AssumeRole

Description

An attacker who can both change a role's permission policy and assume that role escalates through it. They attach or inline an admin policy on the role, then assume it and inherit the new permissions. This is a self-escalation: the attacker raises their own effective privilege by turning an assumable role into an admin.

This is a consolidated edge — it needs both halves on the same role. iam:PutRolePolicy or iam:AttachRolePolicy alone changes what the role can do but grants the attacker nothing, because a permission policy does not decide who may assume the role. sts:AssumeRole alone only yields the role's current permissions. Together they let the attacker mint admin on a role they can already become.

This differs from the trust-policy vector (AWS_UPDATE_TRUST / AWS_UPDATE_TRUST_AND_ASSUME), which changes who may assume the role. Here the attacker already holds the assume path and upgrades what the role is worth.

Edge semantics: (Attacker:AWSUser|AWSRole) -[AWS_UPDATE_POLICY_AND_ASSUME]-> (TargetRole:AWSRole)

Precondition: the attacker can assume the target role (a resolvable sts:AssumeRole path to it).

Identification

# Does the principal hold both a policy-write action and assume on the same role?
aws iam simulate-principal-policy \
  --policy-source-arn <attacker-arn> \
  --action-names iam:PutRolePolicy iam:AttachRolePolicy sts:AssumeRole \
  --resource-arns "arn:aws:iam::<account-id>:role/<target-role>"

Exploitation

# Step 1: Give the assumable role admin (managed policy shown; inline works too)
aws iam attach-role-policy \
  --role-name <target-role> \
  --policy-arn arn:aws:iam::aws:policy/AdministratorAccess

# Step 2: Assume the now-admin role
aws sts assume-role \
  --role-arn "arn:aws:iam::<account-id>:role/<target-role>" \
  --role-session-name escalate

Mitigation

• Separate the ability to modify a role's policies from the ability to assume it. A principal should rarely hold both on the same role.

• Restrict iam:PutRolePolicy and iam:AttachRolePolicy to IAM administrators.

• Enforce IAM permission boundaries so an attached policy cannot exceed the boundary.

• Constrain which managed policies may be attached with an iam:PolicyARN condition.

Detection

CloudTrail Event	Description	Key Fields
PutRolePolicy / AttachRolePolicy	The role's permissions were changed	requestParameters.roleName, requestParameters.policyName/policyArn, userIdentity.arn
AssumeRole	The role was assumed after the change	requestParameters.roleArn, userIdentity.arn

Alert when a principal changes a role's policy and then assumes that same role. Alert with higher priority when the attached policy grants admin (AdministratorAccess, *:*, or iam:*).

References

• AWS IAM: PutRolePolicy API

• AWS IAM: AttachRolePolicy API

• Rhino Security Labs: AWS IAM Privilege Escalation Methods