Privilege Escalation
iam:CreatePolicyVersion
An attacker with iam:CreatePolicyVersion uploads a new admin version of a customer-managed policy they already use and promotes it to default in a single API call, escalating every attached principal.
Required Permissions
Description
The attacker holds iam:CreatePolicyVersion on a customer-managed policy that is attached to their identity or group. The IAM API lets a single CreatePolicyVersion call carry SetAsDefault:true, so the attacker uploads a new version that allows Action:* on Resource:* and promotes it to the default version in the same request. The identity is now an administrator. No other IAM permission is required; iam:SetDefaultPolicyVersion is not needed.
The hackaws agent reads the policy's current document, appends an Allow Action:* Resource:* statement, and submits the new version with SetAsDefault:true. The previous default version id is captured first so the cleanup can restore it; delete-policy-version refuses the current default, so cleanup is a two-step chain of set-default-policy-version back to the original and then delete-policy-version on the attacker version.
Impact
Full administrator access across the account from one IAM call. Every user, role, and group that the affected policy is attached to inherits the new permissions as soon as the version is default, so a widely reused policy escalates many identities at once. The attacker can then read any data, modify any resource, and persist by creating new identities, access keys, or login profiles.
Detection
Alert on CloudTrail CreatePolicyVersion events against customer-managed policies, especially when the request parameter setAsDefault is true. Compare the submitted policy document against the current default and flag any version that adds Action:* with Resource:*, adds a wildcard service such as iam:*, or removes a Deny statement. Correlate the caller identity with the principals the policy is attached to; a self-targeted change is a strong signal. Watch SetDefaultPolicyVersion against the same policies as well, because an attacker can split the two calls to evade a setAsDefault-only rule.
Mitigation
Do not grant iam:CreatePolicyVersion through wildcards such as iam:* or Action:*. Scope the permission to a short list of specific policy ARNs that genuinely need it. Add a service control policy or permission boundary that denies iam:CreatePolicyVersion and iam:SetDefaultPolicyVersion on any policy the identity can reach through its own attachments or group memberships. Prefer AWS-managed policies where the capability allows, because their versions cannot be written. Audit customer-managed policies for unused version slots and prune old versions, so there is no pre-staged broader version left for a later SetDefaultPolicyVersion attack.