Prevent Privilege Escalation via Customer-Managed IAM Policies
Why this matters
Customer-managed IAM policies that allow users to attach or modify permissions (e.g., iam:AttachUserPolicy
, iam:PutRolePolicy
, or iam:CreatePolicy
) can be exploited to gain unauthorized privileges. This creates a high risk of:
Privilege escalation, where a user or compromised identity elevates their access level
Unauthorized changes to security boundaries
Circumvention of approval or break-glass procedures
To maintain a secure permission model, ensure that only tightly controlled identities have rights to modify IAM policies.
What this check does
This Auto Check analyzes all customer-managed IAM policies and identifies:
Policies that grant permissions to IAM write-level APIs such as iam:Put*
, iam:Attach*
, iam:Create*
, or iam:Update*
Policies attached to users, groups, or roles without clear constraints (conditions or resource scoping)
Any wildcard permissions ("Action": "*"
) that may lead to unchecked privilege escalation
The check fails if such permissions are found in any user-defined policy.
How to fix it
You should revise or remove policies that enable users to grant themselves or others new permissions.
From the AWS Console
Go to the IAM Console.
Click on Policies and filter for customer-managed policies.
Look for usage of IAM privilege-modifying actions like:
iam:AttachUserPolicy
iam:PutRolePolicy
iam:CreatePolicy
Detach these policies from all attached entities (users, groups, roles).
If not essential, delete the policy.
If needed, restrict these permissions to trusted break-glass roles or add conditions (e.g., aws:RequestTag
, aws:PrincipalArn
).
Using AWS CLI
# List all identities attached to a policy
aws iam list-entities-for-policy --policy-arn <policy_arn>
# Detach from a user
aws iam detach-user-policy --user-name <user_name> --policy-arn <policy_arn>
# Detach from a group
aws iam detach-group-policy --group-name <group_name> --policy-arn <policy_arn>
# Detach from a role
aws iam detach-role-policy --role-name <role_name> --policy-arn <policy_arn>
Exceptions
If break-glass access is required:
Define these permissions in dedicated roles that are not used in day-to-day operations
Require MFA or approval workflows for role assumption
Monitor with CloudTrail for policy and role modification events