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

Key facts for AWS IAM Privilege Escalation

Detection coverage for AWS IAM Privilege Escalation

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. Every threat comes with one complete detection in Splunk SPL, Microsoft KQL and Sigma, free for everyone; a free account adds daily TL Creds to unlock the rest. Paid plans add a larger daily allowance, correlation and the MCP server. Threadlinqs MCP server · View plans.

Free detection: Privilege-Escalation Primitive Immediately Followed by sts:AssumeRole — Escalation Chain Completion

Detects an IAM principal calling a known privilege-escalation primitive (CreateAccessKey, UpdateLoginProfile, CreateLoginProfile, or UpdateAssumeRolePolicy) and then, within 30 minutes, calling sts:AssumeRole — the final step Horizon3.ai's NodeZero used to complete the chain from a low-privileged IAM identity to full AWS account compromise.

• Languages: Splunk SPL, Microsoft KQL, Sigma
• ATT&CK: T1548.005, T1078.004, T1078
• Data sources: aws_cloudtrail, aws_iam, aws_sts
• Severity: critical
• Confidence: high

Splunk SPL

index=aws sourcetype="aws:cloudtrail" eventSource="iam.amazonaws.com"
  (eventName="CreateAccessKey" OR eventName="UpdateLoginProfile" OR eventName="CreateLoginProfile" OR eventName="UpdateAssumeRolePolicy")
| eval caller=coalesce('userIdentity.arn','userIdentity.userName')
| eval escalation_time=_time
| eval escalation_action=eventName
| join type=inner caller
    [ search index=aws sourcetype="aws:cloudtrail" eventSource="sts.amazonaws.com" eventName="AssumeRole"
      | eval caller=coalesce('userIdentity.arn','userIdentity.userName')
      | eval assume_time=_time
      | eval role_arn='requestParameters.roleArn'
      | fields caller, assume_time, role_arn, sourceIPAddress ]
| eval minutes_to_assume=round((assume_time-escalation_time)/60, 1)
| where minutes_to_assume >= 0 AND minutes_to_assume <= 30
| table escalation_time, caller, escalation_action, assume_time, role_arn, minutes_to_assume, sourceIPAddress
| sort -escalation_time

Microsoft KQL

let escalation = AWSCloudTrail
| where TimeGenerated > ago(24h)
| where EventSource == "iam.amazonaws.com"
| where EventName in ("CreateAccessKey","UpdateLoginProfile","CreateLoginProfile","UpdateAssumeRolePolicy")
| extend Caller = coalesce(UserIdentityArn, UserIdentityUserName)
| project EscalationTime = TimeGenerated, Caller, EscalationAction = EventName;
let assumes = AWSCloudTrail
| where TimeGenerated > ago(24h)
| where EventSource == "sts.amazonaws.com" and EventName == "AssumeRole"
| extend Caller = coalesce(UserIdentityArn, UserIdentityUserName)
| extend RoleArn = tostring(parse_json(RequestParameters).roleArn)
| project AssumeTime = TimeGenerated, Caller, RoleArn, SourceIpAddress;
escalation
| join kind=inner (assumes) on Caller
| where AssumeTime between (EscalationTime .. EscalationTime + 30m)
| project Caller, EscalationAction, EscalationTime, AssumeTime, RoleArn, SourceIpAddress
| order by EscalationTime desc

Sigma

title: AWS STS AssumeRole Following an IAM Privilege-Escalation Primitive
id: 4f1e7a2c-0a1a-4b8e-9c3d-1a2b3c4d5e07
status: experimental
description: Detects sts:AssumeRole calls in AWS CloudTrail. Pair with a temporal correlation (SIEM join) against a preceding CreateAccessKey/UpdateLoginProfile/CreateLoginProfile/UpdateAssumeRolePolicy call by the same principal to isolate the chain-completion step of this attack path.
references:
    - https://attack.mitre.org/techniques/T1548/005/
    - https://horizon3.ai/intelligence/blogs/aws-attack-paths-pentest-wednesday/
author: AII-Detector — ThreadLinqs Intelligence
date: 2026-08-12
tags:
    - attack.privilege-escalation
    - attack.defense-evasion
    - attack.t1548.005
    - attack.t1078.004
logsource:
    product: aws
    service: cloudtrail
detection:
    selection:
        eventSource: sts.amazonaws.com
        eventName: AssumeRole
    condition: selection
falsepositives:
    - Normal cross-account or federated role assumption unrelated to a preceding IAM privilege-escalation primitive
level: medium

Known false positives:

• Legitimate CI/CD or automation workflows that rotate a key/role and immediately assume a role as part of normal operation
• Break-glass emergency-access procedures

Tuning notes: Tune the 30-minute correlation window to your environment's typical automation cadence, and allowlist known CI/CD service-role ARNs that legitimately rotate credentials and assume roles in immediate succession.

• 🔒 IAM Enumeration Followed by Cross-Principal Console Takeover (KQL Correlation) · unlock with TL Creds
• 🔒 Trust Policy Rewrite Immediately Followed by AssumeRole (Same Actor) — Self-Granted Role Assumption · unlock with TL Creds
• 🔒 Newly-Minted Access Key or Console Login First Used From an Unseen Source (Anomalous Valid-Accounts Use) · unlock with TL Creds
• 🔒 Cross-Principal IAM Privilege-Escalation Primitive Invoked (Sigma Baseline) · unlock with TL Creds
• 🔒 AWS IAM UpdateAssumeRolePolicy — Trust Policy Rewrite (Sigma Baseline) · unlock with TL Creds
• 🔒 GuardDuty IAM Privilege-Escalation Finding Correlated to Recent Trust-Policy or Credential Change · unlock with TL Creds
• 🔒 IAM Enumeration Followed by Cross-Principal CreateAccessKey (SPL Correlation) · unlock with TL Creds
• 🔒 IAM Role Trust Policy Rewritten (UpdateAssumeRolePolicy) — Additional Cloud Roles Persistence · unlock with TL Creds

Indicators of compromise for AWS IAM Privilege Escalation

As of 2026-08-12, Threadlinqs Intelligence tracks 3 indicators of compromise for TL-2026-2000.

How AWS IAM Privilege Escalation works

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.

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 by tactic:

Discovery

T1069.003 Cloud Groups; T1087.004 Cloud Account

Initial Access

T1078.004 Cloud Accounts

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

T1078.004 Cloud Accounts

Remediation for AWS IAM Privilege Escalation

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

Affected and fixed versions

• 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

Timeline of AWS IAM Privilege Escalation

• 2026-08-12 locked-ioc-2 publishes the case study 'AWS Attack Paths | Pentest Wednesday' (author Stephen Gates) documenting the validated attack path and engagement statistics.
• 2026-08-12 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.
• 2026-08-12 locked-ioc-2 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.
• 2026-08-12 locked-ioc-2 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.
• 2026-08-12 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.
• 2026-08-12 locked-ioc-3 calls sts:AssumeRole against the modified role, completing the chain from the low-privileged IAM identity toward full AWS account compromise.
• 2026-08-12 locked-ioc-3 abuses iam:UpdateAssumeRolePolicy to rewrite the trust ('assume role') policy of a connected role so the compromised principal is permitted to assume it.
• 2026-08-12 Using iam:CreateAccessKey, locked-ioc-3 mints a new access key for a discovered higher-privileged IAM user, inheriting that user's permissions.
• 2026-08-12 locked-ioc-3 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).
• 2026-08-12 locked-ioc-3 begins autonomous discovery, enumerating AWS IAM users, policies, and connected roles across the client's AWS environment.

Sources cited for AWS IAM Privilege Escalation

• CIS Amazon Web Services Foundations Benchmark d1.awsstatic.com · Advisory
• Account Manipulation: Additional Cloud Credentials, Sub-technique T1098.001 - Enterprise | MITRE ATT&CK MITRE · Research
• Account Manipulation: Additional Cloud Roles, Sub-technique T1098.003 - Enterprise | MITRE ATT&CK MITRE · Research
• Abuse Elevation Control Mechanism: Temporary Elevated Cloud Access, Sub-technique T1548.005 - Enterprise | MITRE ATT&CK MITRE · Research
• Valid Accounts: Cloud Accounts, Sub-technique T1078.004 - Enterprise | MITRE ATT&CK MITRE · Research
• Account Discovery: Cloud Account, Sub-technique T1087.004 - Enterprise | MITRE ATT&CK MITRE · Research
• Permission Groups Discovery: Cloud Groups, Sub-technique T1069.003 - Enterprise | MITRE ATT&CK MITRE · Research
• AWS IAM Privilege Escalation Techniques - Hacking The Cloud hackingthe.cloud · Research
• AWS IAM Assume Role Policy Update | Prebuilt detection rules reference (Elastic Security) elastic.co · Vendor report
• AWS-IAM-Privilege-Escalation: A centralized source of all AWS IAM privilege escalation methods (Rhino Security Labs) GitHub · Code repository
• AWS Attack Paths | Pentest Wednesday (Horizon3.ai) horizon3.ai · Blog · 2026-08-12

Threats related to AWS IAM Privilege Escalation

• 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

Related coverage of this activity

• CVE-2026-69836 Entra ID RCE