AWS_UPDATE_POLICY_AND_ASSUME

Copy page

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:*).

Ask AI