AWS IAM Privilege Escalation Attack Path via iam:CreateAccessKey, iam:UpdateLoginProfile, and iam:UpdateAssumeRolePolicy (Horizon3.ai NodeZero Case Study)
AWS IAM Privilege Escalation Attack Path via (TL-2026-2000) is a medium-severity cloud security threat, first published 2026-08-12. It has no confirmed attribution, affects Amazon Web Services AWS Identity and Access Management (IAM), maps to 6 MITRE ATT&CK techniques (T1069.003, T1078.004, T1087.004), and is covered by 9 detection rules and 3 indicators of compromise.
Key facts for TL-2026-2000
- Threat ID
- TL-2026-2000
- Severity
- MEDIUM
- Status
- ACTIVE
- Category
- CLOUD
- First published
- 2026-08-12
- Last reviewed
- 2026-08-12
- Motivation
- UNKNOWN
- Target sectors
- transport, logistics
- Target regions
- North America
- Detection rules
- 9
- Indicators of compromise
- 3
Malware and tooling in AWS IAM Privilege Escalation Attack Path via
Malware and tooling: NodeZero
Horizon3.ai's NodeZero autonomous pentesting platform validated a real AWS attack path at a U.S. transportation and logistics company in which an over-permissioned IAM user's policies (iam:CreateAccessKey, iam:UpdateLoginProfile, iam:UpdateAssumeRolePolicy) were chained through AWS STS role assumption to reach full AWS account compromise in just over 42 minutes. The broader continuous-validation program ran at least 25 AWS pentests across thousands of assets, connected 4 AWS weaknesses to 25 potential impacts (22 paths to full account compromise, 3 paths exposing sensitive data), and by a later testing cycle only 1 of the 102 identified weaknesses remained open.
How AWS IAM Privilege Escalation Attack Path via works
On 2026-08-12, Horizon3.ai published a case study describing an AWS Identity and Access Management (IAM) privilege-escalation attack path validated end-to-end by its NodeZero autonomous penetration-testing platform against a major U.S. transportation and logistics company whose 'geographically distributed technology environment spans internal infrastructure, customer-facing systems, cloud services, and operationally sensitive environments, creating a significant visibility challenge' (Horizon3.ai's own framing). NodeZero began by discovering AWS identities and IAM policies in the client's environment, and identified an over-permissioned IAM user whose attached policies granted three high-risk IAM actions against other principals: iam:CreateAccessKey, iam:UpdateLoginProfile, and iam:UpdateAssumeRolePolicy — the article does not specify whether the holder was a human user or a service/automation identity.
Each of these actions is a documented AWS IAM privilege-escalation primitive: iam:CreateAccessKey lets a holder mint a new access key/secret pair for any other IAM user who lacks two existing keys, instantly inheriting that user's effective permissions; iam:UpdateLoginProfile lets a holder change the AWS Management Console password of any IAM user that already has a login profile, granting console access under that identity; and iam:UpdateAssumeRolePolicy lets a holder rewrite the trust ('assume role') policy document of any existing IAM role, adding their own principal as a permitted assumer, after which sts:AssumeRole (MITRE ATT&CK T1548.005, Temporary Elevated Cloud Access) is used to actually take on that role's permissions. Combined with the user's ability to discover other users and 'connected roles' via standard IAM enumeration, NodeZero chained these primitives from the low-privileged IAM identity to full AWS account compromise in just over 42 minutes. Because the compromised principal's newly-minted credentials (or console password) let NodeZero operate as the target's existing, higher-privileged identity rather than a distinct attacker-created one, the chain also constitutes Valid Accounts abuse (MITRE T1078.004) — a technique MITRE documents as spanning Initial Access, Persistence, Privilege Escalation, and Defense Evasion, since operating under a legitimate account both grants elevated access and blends in with normal activity in AWS CloudTrail.
The underlying techniques are not novel research from this case study — iam:CreateAccessKey, iam:CreateLoginProfile/iam:UpdateLoginProfile, and iam:UpdateAssumeRolePolicy have been catalogued as AWS IAM privilege-escalation methods since Rhino Security Labs' widely-cited AWS-IAM-Privilege-Escalation research, and are reflected in MITRE ATT&CK sub-techniques for Account Manipulation (T1098.001 Additional Cloud Credentials; T1098.003 Additional Cloud Roles) and Abuse Elevation Control Mechanism (T1548.005 Temporary Elevated Cloud Access). What this case study adds is a concrete, timed, real-world validation of the chain against a live production AWS account, plus program-level statistics from the client's broader continuous-testing engagement: at least 25 AWS pentests conducted across internal, external, cloud, and web-application environments and 'extending validation across thousands of assets'; 4 AWS weaknesses connected to 25 potential impacts, including 22 distinct paths to full account compromise and 3 paths exposing sensitive data; and, in a later testing cycle, 102 weaknesses had been mitigated with only one remaining open. The article separately lists several threat-actor names (Scattered Spider, BlackByte, Lazarus Group, HAFNIUM, FIN13, LAPSUS$, Volt Typhoon) purely as context for why IAM privilege escalation matters to defenders generally — it does not attribute this specific attack path or engagement to any of them.
This is a misconfiguration/attack-pattern threat rather than a software vulnerability: there is no CVE, no vendor patch, and no malware or C2 infrastructure involved. Remediation centers on least-privilege IAM policy design (scoping iam:CreateAccessKey/iam:UpdateLoginProfile/iam:UpdateAssumeRolePolicy away from developer/service roles, or constraining them to the calling principal's own ARN), CloudTrail/GuardDuty monitoring for these specific API calls against non-self principals, and continuous attack-path validation to catch escalation chains proactively.
MITRE ATT&CK techniques used in TL-2026-2000
Discovery
T1069.003 Cloud Groups; T1087.004 Cloud Account
Initial Access
Persistence
T1078.004 Cloud Accounts; T1098.001 Additional Cloud Credentials; T1098.003 Additional Cloud Roles
Privilege Escalation
T1078.004 Cloud Accounts; T1098.001 Additional Cloud Credentials; T1098.003 Additional Cloud Roles; T1548.005 Temporary Elevated Cloud Access
Defense Evasion
Affected products and versions in AWS IAM Privilege Escalation Attack Path via
- Amazon Web Services — AWS Identity and Access Management (IAM)
Vulnerable versions: N/A - misconfiguration/permissions issue, not a version-specific vulnerability
Fixed in: N/A - remediated via least-privilege IAM policy configuration, not a vendor patch
Remediation for AWS IAM Privilege Escalation Attack Path via
Immediate actions
- Audit all IAM principals for iam:CreateAccessKey, iam:UpdateLoginProfile, and iam:UpdateAssumeRolePolicy permissions scoped broadly (wildcard resource or any principal other than self), and scope them down to the minimum resource ARNs required
- Enable AWS CloudTrail logging for IAM and STS events and alert on CreateAccessKey, UpdateLoginProfile, and UpdateAssumeRolePolicy calls where the target principal differs from the calling principal
- Enable Amazon GuardDuty's PrivilegeEscalation:IAMUser/AnomalousBehavior and PrivilegeEscalation:IAMUser/AdministrativePermissions finding types and tune EventBridge rules on these three IAM actions plus sts:AssumeRole
Workarounds
- Add an aws:PrincipalArn (or ResourceTag) IAM policy condition restricting iam:CreateAccessKey and iam:UpdateLoginProfile to the calling principal's own ARN, so self-service key/password rotation still works but cross-user escalation does not
- Add explicit Deny statements or permissions boundaries preventing developer/service IAM roles from calling iam:UpdateAssumeRolePolicy against roles more privileged than themselves
Longer-term hardening
- Apply IAM least privilege per CIS AWS Foundations Benchmark: attach policies to groups/roles rather than individual users, and eliminate wildcard ('*') administrative permissions
- Adopt continuous, automated AWS attack-path validation (autonomous or manual pentesting) to surface privilege-escalation chains proactively, as this engagement's discovery of 22 distinct paths to full account compromise demonstrates such chains are common and easy to miss with static configuration review alone
- Use AWS IAM Access Analyzer to continuously identify unused and overly broad permissions and right-size developer/service IAM policies over time
Weaknesses (CWE) in AWS IAM Privilege Escalation Attack Path via
CWE-269, CWE-732
Timeline of AWS IAM Privilege Escalation Attack Path via
- Horizon3.ai publishes the case study 'AWS Attack Paths | Pentest Wednesday' (author Stephen Gates) documenting the validated attack path and engagement statistics.
- In a later AWS testing cycle, 102 of the identified weaknesses had been mitigated with only one remaining open, reflecting the client's continuous security-validation program.
- Horizon3.ai reports the client's broader AWS testing program findings: 4 AWS weaknesses connected to 25 potential impacts, 22 distinct paths to full account compromise, and 3 paths exposing sensitive data.
- Horizon3.ai reports the client ran at least 25 AWS pentests as part of a broader security-validation program spanning internal, external, cloud, and web-application environments, extending validation across thousands of assets.
- End-to-end validation of the attack path, from the initial over-permissioned IAM user to full AWS account compromise, completes in just over 42 minutes.
- NodeZero calls sts:AssumeRole against the modified role, completing the chain from the low-privileged IAM identity toward full AWS account compromise.
- NodeZero abuses iam:UpdateAssumeRolePolicy to rewrite the trust ('assume role') policy of a connected role so the compromised principal is permitted to assume it.
- Using iam:CreateAccessKey, NodeZero mints a new access key for a discovered higher-privileged IAM user, inheriting that user's permissions.
- NodeZero identifies an over-permissioned IAM user whose attached policies grant iam:CreateAccessKey, iam:UpdateLoginProfile, and iam:UpdateAssumeRolePolicy against other IAM principals (the article does not specify whether the identity is a human user or a service/automation account).
- NodeZero begins autonomous discovery, enumerating AWS IAM users, policies, and connected roles across the client's AWS environment.
Sources cited for AWS IAM Privilege Escalation Attack Path via
- AWS Attack Paths | Pentest Wednesday (Horizon3.ai)
- Account Manipulation: Additional Cloud Credentials, Sub-technique T1098.001 - Enterprise | MITRE ATT&CK
- Account Manipulation: Additional Cloud Roles, Sub-technique T1098.003 - Enterprise | MITRE ATT&CK
- Abuse Elevation Control Mechanism: Temporary Elevated Cloud Access, Sub-technique T1548.005 - Enterprise | MITRE ATT&CK
- Valid Accounts: Cloud Accounts, Sub-technique T1078.004 - Enterprise | MITRE ATT&CK
- Account Discovery: Cloud Account, Sub-technique T1087.004 - Enterprise | MITRE ATT&CK
- Permission Groups Discovery: Cloud Groups, Sub-technique T1069.003 - Enterprise | MITRE ATT&CK
- AWS-IAM-Privilege-Escalation: A centralized source of all AWS IAM privilege escalation methods (Rhino Security Labs)
- AWS IAM Privilege Escalation Techniques - Hacking The Cloud
- AWS IAM Assume Role Policy Update | Prebuilt detection rules reference (Elastic Security)
- CIS Amazon Web Services Foundations Benchmark
Threats related to AWS IAM Privilege Escalation Attack Path via
- Unit 42: Identity Compromise Is the Primary Attack Vector in Nearly 90% of Incidents
- Metabase Zero-Day (GHSA-vwf4-m7j8-wcjf) Exploited in the Wild for Unauthenticated Admin Access
- OAuth-Token Supply-Chain Compromise Enables Attacker Access to Google Workspace: The Vercel and Composio Breaches
- GCP Cross-Project Compute Image Exfiltration via Compromised Developer Credentials
Detection coverage for TL-2026-2000
As of 2026-08-12, Threadlinqs Intelligence publishes 9 detection rule(s) for TL-2026-2000 across Splunk SPL, Microsoft KQL and Sigma, covering 3 indicator(s) of compromise. The whole corpus is readable without an account; a free account unlocks full detection query text in Splunk SPL, Microsoft KQL and Sigma; paid tiers add raw indicator values, correlation and the MCP server. Threadlinqs MCP server · View plans.