AWS: IAM CreateAccessKey Privilege Escalation

by

Author: Fatima Aziz (published on Hacking Articles)
Published: July 16, 2025
Source: https://www.hackingarticles.in/aws-iam-createaccesskey-privilege-escalation/

Summary

This Hacking Articles tutorial demonstrates a well-known AWS IAM privilege-escalation technique that stems from misconfiguration rather than any software flaw: a low-privileged IAM user who has been granted the iam:CreateAccessKey permission on other users can mint a fresh access key for a higher-privileged user and assume that user’s privileges. It is a hands-on lab walkthrough and general technique explainer, not a specific vulnerability disclosure — there is no CVE. The takeaway is a least-privilege lesson: iam:CreateAccessKey scoped too broadly (for example on Resource: "*") is effectively an administrative escalation path.

Technical Details

The AWS API action CreateAccessKey generates a new access key ID and secret access key for a specified IAM user. Programmatic access keys are long-lived credentials that are not tied to the requester, so if an IAM policy allows a user to call CreateAccessKey against other users (rather than only themselves), that user can generate valid credentials for any account in scope — including an administrator. The article’s lab grants the low-privileged user a set of read/enumeration permissions (iam:ListUsers, iam:ListAttachedUserPolicies, iam:GetUser, iam:GetPolicy, iam:GetPolicyVersion) plus iam:CreateAccessKey. The escalation path is straightforward and uses only documented AWS CLI calls:

  • Enumerate IAM users and their attached policies to find a high-privileged target (in the lab, an account carrying AdministratorAccess).
  • Call aws iam create-access-key --user-name <target-admin> to obtain a new access key ID and secret for that admin user.
  • Configure the AWS CLI with those credentials and operate as the administrator, with full access to account resources (S3, etc.).

No exploit code or vulnerability is involved — the abuse is entirely a legitimate API call enabled by an over-permissive policy. AWS allows up to two access keys per user, so in most cases the call succeeds without disturbing the target’s existing key.

Impact

Successful abuse turns a low-privileged foothold into full administrative control of the AWS account. Because the newly created access key is independent and long-lived, it also provides durable persistence: the attacker retains access even if the original foothold is revoked, until the rogue key is discovered and deleted. From administrator context an attacker can reach sensitive resources (S3 buckets, databases), exfiltrate or destroy data, and move laterally across the account. This is one of a family of IAM permissions (alongside things like iam:AssumeRole, iam:UpdateLoginProfile, and policy-attachment permissions) that are individually innocuous-looking but become escalation primitives when granted too broadly.

Mitigation

The technique is a configuration problem, so the defenses are policy-hygiene measures, several of which the article recommends:

  • Do not grant iam:CreateAccessKey on other users unless strictly required; where users need to manage their own keys, scope the permission to the caller’s own user (for example via the ${aws:username} resource condition) rather than Resource: "*".
  • Prefer short-lived, role-based credentials via sts:AssumeRole over long-lived access keys wherever possible.
  • Monitor CreateAccessKey API calls in AWS CloudTrail and alert on access-key creation, especially where the caller and the target user differ.
  • Use Service Control Policies (SCPs) to constrain sensitive IAM actions organization-wide.
  • Avoid wildcard resources in sensitive IAM policies and apply least privilege and proper role separation throughout.

For detection, note that every CreateAccessKey call is logged by CloudTrail; a key created for a user by a different principal is a high-signal indicator worth flagging.

References

Leave a Comment