CloudGoat walkthrough series: IAM privilege escalation by rollback

December 8, 2020 by Mosimilolu Odusanya

This is the first in the walkthrough series of the CloudGoat scenarios. CloudGoat is a “vulnerable by design” AWS deployment tool designed by Rhino Security Labs. It is used to deploy a vulnerable set of AWS resources and designed to teach and test cloud security penetration testing via issues commonly seen in real-life environments.

This walkthrough assumes you have CloudGoat set up on your Kali Linux. You can use our post, Working with CloudGoat: The “vulnerable by design” AWS environment as a guide in deploying it.

Scenario summary

This scenario starts with an IAM user “Raynor” with limited privileges. The attacker is able to review previous IAM policy versions and restore one which allows full admin privileges, resulting in a privilege escalation exploit.

The goal of the scenario is to acquire full administrative privileges in the AWS account.


To deploy the resources for each scenario on AWS:

./ create iam_privesc_by_rollback

Without Pacu

  1. Enumerate the policies and permissions attached to the user “Raynor” and see what privileges the user has.

Running the below revealed nothing.

aws iam list-user-policies –-user-name <insert username here> –profile <insert profile name here>

list-user-policies: Lists the names of inline policies embedded in the specified IAM user.

aws iam list-attached-user-policies –-user-name <insert username here> –profile <insert profile name here>

list-attached-user-policies: Lists all managed policies that are attached to the specified IAM user.

  1. Get more information on the managed policy attached to the IAM user:

aws iam get-policy -–policy-arn <insert policy arn here> –profile <insert profile name here>

get-policy: Retrieves information about the specified managed policy, including the policy’s default version and the total number of IAM users, groups and roles to which the policy is attached.

We can see that this policy version is v1.

When you make changes to an IAM customer-managed policy and when AWS makes changes to an AWS-managed policy, the changed policy doesn’t overwrite the existing policy. Instead, IAM creates a new version of the managed policy. IAM stores up to five versions of your customer-managed policies.

  1. Review details of the policy attached to this IAM user:

aws iam get-policy-version -–policy-arn <insert policy arn here> –profile <insert profile name here> –version-id <insert version id number here>

We noticed that this policy has iam:SetDefaultPolicyVersion allowed. When modifying a policy, AWS automatically creates a new policy version with the changes. Those changes can then be undone by reverting the policy to a previous version. Users with the iam:SetDefaultPolicyVersion are allowed to set which version of the policy is the default (active) version.

An attacker with the iam:SetDefaultPolicyVersion permission may be able to escalate privileges through existing policy versions not currently in use. If a policy that they have access to has versions that are not the default, they would be able to change the default version to any other existing version.

  1. Check to see if there are other versions of this policy:

aws iam list-policy-versions -–policy-arn <insert policy arn here> –profile <insert profile name here>

We can see that there are five (5) versions of this policy. We check other versions of the IAM policy just in case.

  1. Review other versions of the policy

aws iam get-policy-version -–policy-arn <insert policy arn here> –profile <insert profile name> –version-id <insert version id number here>

Version 2

This policy allows all actions to all resources. This basically grants the user administrative access to the AWS account.

Version 3

This policy allows the only the following actions: “s3:ListBucket”, “s3:GetObject” and “s3:ListAllMyBuckets”.

Version 4

This policy whitelists those two (2) IP subnets.

Version 5

This policy allows this action “iam:Get*” to all AWS resources but only allows for a specified time period which has expired.

  1. Restore the previous version of the policy (v2):

aws iam get-policy-version -–policy-arn <insert policy arn here> –profile <insert profile name> –version-id <insert version id number here>

Confirm the version attached to the IAM user:

  1. Confirm new privileges by creating a new s3 bucket:

aws s3api create-bucket –bucket <insert name of bucket here> –region <insert name of region here> –profile <insert profile name>

With Pacu

  1. Set AWS keys for the users:
  2. Enumerate information about all users, roles, customer-managed policies and groups in the account.

run iam__enum_users_roles_policies_groups

  1. Check the information extracted and stored in the database during the enumeration.


  1. Run the IAM privilege scan module:

run iam__privesc_scan

  1. Switch to version v5, which grants the IAM user administrative access to the AWS environment.
  2. Confirm which version of the policy is attached to the IAM user:
  3. Test the new privileges and create a new bucket:

aws s3api create-bucket –bucket <insert name of bucket here> –region <insert region name here> –profile <insert profile name here>


Versioning IAM Policies, AWS

AWS CLI Command Reference – IAM, AWS

Well, that escalated quickly, Bishop Fox

AWS IAM Privilege Escalation Methods, Rhino Security Labs

Posted: December 8, 2020
Articles Author
Mosimilolu Odusanya
View Profile

Mosimilolu (or ‘Simi’) works as a full-time cybersecurity consultant, specializing in privacy and infrastructure security. Outside of work, her passions includes watching anime and TV shows and travelling.

Notice: Undefined index: visitor_id12882 in /www/resourcesinfosecinstitute_601/public/wp-content/plugins/infosec-user-info/infosec-user-info.php on line 117