AWS: IAM AssumeRole Privilege Escalation

by

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

Summary

This Hacking Articles tutorial demonstrates an AWS IAM privilege-escalation technique driven by misconfiguration rather than a software flaw: a low-privileged IAM user can assume a highly privileged IAM role when that role’s trust policy is written too permissively. By calling sts:AssumeRole against a role that trusts the low-privileged user’s ARN, the attacker receives temporary credentials carrying the role’s (here, administrator) permissions. It is a hands-on lab walkthrough and general technique explainer, not a specific vulnerability disclosure — there is no CVE. It is a companion to the same author’s iam:CreateAccessKey write-up and reinforces the same least-privilege lesson, this time on role trust relationships.

Technical Details

AWS Security Token Service (STS) issues short-lived credentials (an access key ID, secret access key, and session token) when a principal successfully calls AssumeRole. Whether a principal may assume a role is governed by that role’s trust policy (the AssumeRolePolicyDocument). If the trust policy names a low-privileged user (or an overly broad principal) as trusted, that user can assume the role regardless of how limited their own attached policies are. The article’s lab sets up a low-privileged user (with EC2 full access, S3 read-only, and IAM read-only) and a separate admin_role carrying AdministratorAccess whose trust policy permits the low-privileged user to assume it. The escalation uses only documented tooling and API calls:

  • Enumerate IAM (the article uses the enumerate-iam recon tool and IAM read access) to discover the role and confirm the trust policy allows the current user’s ARN.
  • Call aws sts assume-role --role-arn arn:aws:iam::<ACCOUNT>:role/admin_role --role-session-name "<session>".
  • Export the returned temporary access key, secret, and session token as environment variables and operate with the role’s administrator permissions.

No exploit or vulnerability is involved — the abuse is a legitimate STS call permitted by a misconfigured trust relationship.

Impact

The technique converts a limited foothold into full administrative control of the AWS account. Even though the starting user held only read-only S3 access, assuming the admin role grants the ability to read, modify, delete, or exfiltrate data across services and to move laterally. Because AssumeRole yields temporary credentials, the activity can also be less conspicuous than creating a long-lived key, and the session inherits whatever the role allows. This is one of a family of IAM permissions and relationships (alongside iam:CreateAccessKey, iam:UpdateLoginProfile, policy-attachment permissions, and lax role trust policies) that become escalation primitives when granted or configured too broadly.

Mitigation

Because the issue is configuration, the defenses focus on tightening role trust and monitoring, several of which the article recommends:

  • Scope role trust policies tightly — trust only the specific principals that genuinely need to assume a role, and never let low-privileged or broad principals assume highly privileged roles.
  • Add conditions to trust policies, such as requiring MFA ("aws:MultiFactorAuthPresent": "true") and restricting source IP ranges, and consider external-ID requirements for cross-account roles.
  • Audit AssumeRole events in AWS CloudTrail and alert on assumptions of sensitive roles or unexpected principal/role pairings.
  • Apply Service Control Policies (SCPs) to constrain who can assume privileged roles organization-wide.
  • Follow least privilege and role separation, and regularly review trust relationships on administrative roles.

For detection, every AssumeRole call is recorded by CloudTrail; a low-privileged user assuming an administrative role is a high-signal indicator worth flagging.

References

Leave a Comment