Switch Policy to Broader Version
highPrivilege Escalation
An attacker with iam:SetDefaultPolicyVersion can switch a managed policy back to an older, more permissive version — escalating every principal that uses it.
Required Permissions
Description
This technique exploits a common gap in policy lifecycle management. When an administrator tightens a managed policy by creating a new, narrower version as the default, the old broader version often stays behind. An attacker with iam:SetDefaultPolicyVersion can switch the default pointer back to the old version.
The blast radius is every principal (user, role, or group) that has the policy attached. All of them immediately gain the broader permissions from the restored version. No new resources are created — only the active version pointer changes.
The attack flow: 1. Enumerate managed policies attached to the current identity and find those with multiple versions 2. Read each non-default version's document to score its permission breadth 3. Verify the candidate is a strict superset of the current permissions — it must include everything the current version allows, plus more 4. Switch the default to the most permissive superset version 5. All principals using this policy now have the broader permissions
The technique only switches to a version that is a strict superset — it never removes existing permissions. This prevents service disruption and ensures the caller retains the ability to revert. Unlike creating a new policy version (critical severity), this technique only works when a broader version already exists — the attacker cannot author arbitrary permissions, only restore what was previously in place.
This technique is fully reversible — the original default version ID is recorded and the cleanup command switches back. However, the broader permissions persist until cleanup runs.
Impact
Every principal attached to the targeted policy gains the broader permissions from the restored version. If the old version included sts:AssumeRole or admin-level access, the attacker can reach previously inaccessible roles and accounts.
Detection
Monitor CloudTrail for SetDefaultPolicyVersion calls, especially where the new default version has broader permissions than the previous one. Alert on ListPolicyVersions and GetPolicyVersion calls in rapid succession — this pattern indicates version comparison.
Mitigation
Delete old policy versions after tightening permissions — do not leave broader versions behind. Use SCPs to deny iam:SetDefaultPolicyVersion from non-admin principals. Audit managed policies for multiple versions regularly. Apply permission boundaries to limit the maximum effective permissions regardless of the active policy version.