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

# AWS\_UPDATE\_POLICY\_AND\_ASSUME

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

```bash
# 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

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

## References

* [AWS IAM: PutRolePolicy API](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePolicy.html)
* [AWS IAM: AttachRolePolicy API](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachRolePolicy.html)
* [Rhino Security Labs: AWS IAM Privilege Escalation Methods](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)