AWS Pentesting: IAM Privilege Escalation via Rollback Policy

When conducting AWS penetration tests, one of the key privilege escalation paths I always check for is the ability to manipulate IAM policy versions through the iam:SetDefaultPolicyVersion permission. Today, I’ll be walking through a lab on Pwnlabs that demonstrates this attack vector. While IAM permissions might initially appear restrictive, the ability to roll back to previous policy versions can sometimes reveal a goldmine of elevated privileges that were previously removed but not properly cleaned up. This lab showcases why security teams should always include policy version management in their AWS security assessments.

Since, I have multiple AWS keys in the attack machine, I used the “ — profile” option.

aws configure --profile <name-of-the-profile>

Running aws sts get-caller-identity — profile <name-of-the-profile> would show the name of our IAM user which is “intern01”.

I then checked for the inline policies for the current user using the command below:

aws iam list-user-policies --user-name intern01 --profile iamprivesc

Inline policies are embedded directly within the specified IAM user; These policies exist only for that specific user and cannot be reused across different users.

The error above showed that the current user doesn't have permission to run list-user-policies.

Next, I then checked for any IAM policies attached to the current user. Based on the result, there is a policy name “intern_policy” that is attached to the current user.

I then ran the command below to get more details of this policy.

aws iam get-policy --policy-arn <POLICY_ARN> --profile <name-of-the-profile>

The image below showed that this policy is the v2. There could be a v1 for this policy.

To enumerate the available policy versions, we’ll use the list-policy-versions command. The output below showed that there are two available versions for this policy.

aws iam list-policy-versions --policy-arn <POLICY_ARN> --profile iamprivesc

Let’s inspect version 2 of the policy document to understand its permission set. The get-policy-version command will reveal the exact permissions defined in this version:

aws iam get-policy-version --policy-arn <POLICY_ARN> --version-id v2 --profile iamprivesc

The presence of iam:SetDefaultPolicyVersion in this policy is a significant security finding. AWS specifically warns against granting this permission as it allows users to switch between different versions of an IAM policy — including rolling back to potentially more permissive versions. Think of it as a time machine for permissions that could enable privilege escalation if any previous policy versions contained broader access rights.

V2 of the policy shows that the current user has permission to check the details of the EC2 instances and has other IAM permission. There is no permission for S3. We can confirm this by running “ aws s3 ls — profile < your profile>.

I then checked the V1 policy and noticed that in this version, the current user has permission to S3.

Let’s set v1 as the default policy version by running the following command.

aws iam set-default-policy-version --policy-arn <POLICY_ARN> --version-id v1 --profile <name-of-the-profile>

I then used the command below to confirm the permission.

aws iam get-policy --policy-arn <POLICY_ARN> --profile <name-of-the-profile>

Because v1 has no permission to run “get-policy”, the command returned an access deny response.

I also confirmed the new permission by checking the S3 bucket.

aws s3 ls --profile <name-of-the-profile>

As an option, I ran Pacu to check if the same misconfiguration can be flagged by the tool. Noticed in the result below that “SetExistingDefaultPolicyVersion” is set to “Confirmed”

Conclusion

Exploiting IAM policy version rollbacks serves as a powerful reminder that AWS privilege escalation isn’t always about direct permission grants. In this lab, we demonstrated how the seemingly innocuous iam:SetDefaultPolicyVersion permission can be leveraged to gain elevated access by reverting to older, more permissive policy versions. For security teams and cloud penetration testers, this highlights the importance of carefully managing policy versions and regularly auditing version history, not just current permissions. Always remember: when testing AWS environments, checking for policy rollback capabilities should be a standard part of your privilege escalation testing methodology.

References:

https://pwnedlabs.io/labs/escalate-privileges-by-iam-policy-rollback
https://docs.aws.amazon.com/wellarchitected/latest/financial-services-industry-lens/aws-identity-and-access-management-iam.html