# AWS IAM Privilege Escalation Attack Path via iam:CreateAccessKey, iam:UpdateLoginProfile, and iam:UpdateAssumeRolePolicy (Horizon3.ai NodeZero Case Study)

> 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.

- **Published:** 2026-08-12T00:00:00Z
- **Last reviewed:** 2026-08-12T00:00:00Z
- **Canonical:** https://intel.threadlinqs.com/threat/TL-2026-2000
- **ID:** TL-2026-2000
- **Severity:** MEDIUM
- **Category:** CLOUD
- **Status:** ACTIVE
- **Detections:** 9 · **IOCs:** 3 (full data via the Threadlinqs MCP server — Purple tier)

## Description

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

- T1087.004 Cloud Account
- T1069.003 Cloud Groups
- T1078.004 Cloud Accounts
- T1098.001 Additional Cloud Credentials
- T1098.001 Additional Cloud Credentials
- T1098.003 Additional Cloud Roles
- T1098.003 Additional Cloud Roles
- T1548.005 Temporary Elevated Cloud Access
- T1078.004 Cloud Accounts
- T1078.004 Cloud Accounts
- T1078.004 Cloud Accounts

## Sources

- [AWS Attack Paths | Pentest Wednesday (Horizon3.ai)](https://horizon3.ai/intelligence/blogs/aws-attack-paths-pentest-wednesday/)
- [Account Manipulation: Additional Cloud Credentials, Sub-technique T1098.001 - Enterprise | MITRE ATT&CK](https://attack.mitre.org/techniques/T1098/001/)
- [Account Manipulation: Additional Cloud Roles, Sub-technique T1098.003 - Enterprise | MITRE ATT&CK](https://attack.mitre.org/techniques/T1098/003/)
- [Abuse Elevation Control Mechanism: Temporary Elevated Cloud Access, Sub-technique T1548.005 - Enterprise | MITRE ATT&CK](https://attack.mitre.org/techniques/T1548/005/)
- [Valid Accounts: Cloud Accounts, Sub-technique T1078.004 - Enterprise | MITRE ATT&CK](https://attack.mitre.org/techniques/T1078/004/)
- [Account Discovery: Cloud Account, Sub-technique T1087.004 - Enterprise | MITRE ATT&CK](https://attack.mitre.org/techniques/T1087/004/)
- [Permission Groups Discovery: Cloud Groups, Sub-technique T1069.003 - Enterprise | MITRE ATT&CK](https://attack.mitre.org/techniques/T1069/003/)
- [AWS-IAM-Privilege-Escalation: A centralized source of all AWS IAM privilege escalation methods (Rhino Security Labs)](https://github.com/RhinoSecurityLabs/AWS-IAM-Privilege-Escalation/blob/master/README.md)
- [AWS IAM Privilege Escalation Techniques - Hacking The Cloud](https://hackingthe.cloud/aws/exploitation/iam_privilege_escalation/)
- [AWS IAM Assume Role Policy Update | Prebuilt detection rules reference (Elastic Security)](https://www.elastic.co/docs/reference/security/prebuilt-rules/rules/integrations/aws/privilege_escalation_iam_update_assume_role_policy)
- [CIS Amazon Web Services Foundations Benchmark](https://d1.awsstatic.com/whitepapers/compliance/AWS_CIS_Foundations_Benchmark.pdf)

## Full data

Detection queries (Splunk SPL / Microsoft KQL / Sigma) and IOC values require the Threadlinqs MCP server (Purple tier): https://intel.threadlinqs.com/mcp

Canonical: https://intel.threadlinqs.com/threat/TL-2026-2000