Which IAM API calls are the most dangerous in a privilege escalation chain?

AttachUserPolicy and PutUserPolicy (grant arbitrary permissions directly), CreateAccessKey (create long-lived credentials), AddUserToGroup (inherit group permissions), and UpdateAssumeRolePolicy (add the attacker's identity as trusted principal for an existing privileged role). Any one of these called by an identity that doesn't normally manage IAM is a high-priority signal.

Does LogTriage require CloudTrail to be enabled for all regions?

LogTriage analyzes whatever CloudTrail export you provide. For complete IAM escalation detection, AWS recommends enabling CloudTrail in all regions or using an organization-level trail, since IAM API calls are global but logged in the region the request was made to.

How does LogTriage handle assumed-role chains in CloudTrail?

The CloudTrail parser extracts userIdentity.arn and session context, normalizing them into a user_principal_name field. AssumeRole chains — where an identity assumes a role and then makes API calls under that role — are attributed to the originating principal, making the full escalation chain visible rather than just the individual calls.

What's the difference between an IAM escalation alert and a routine admin task?

Context: who made the call, from which IP, and what they normally do. An IAM admin making AttachUserPolicy calls during business hours from their normal workstation is routine. The same call made by a developer's access key, from a commercial hosting IP range, after a burst of AccessDenied errors, is the escalation pattern.

Detecting IAM Privilege Escalation in AWS CloudTrail

Why this matters

Privilege escalation is the pivot point in nearly every serious AWS account compromise. An attacker rarely starts with admin access — they start with one over-permissioned credential and chain a handful of IAM API calls (AttachUserPolicy, CreateAccessKey, PutUserPolicy, AssumeRole) into full account control. Every one of those calls is logged in CloudTrail by default, which makes this one of the most detectable attack chains available — if you’re actually looking for the chain, not just the individual calls.

Indicators to look for in CloudTrail logs

eventName values like AttachUserPolicy, PutUserPolicy, CreateAccessKey, UpdateAssumeRolePolicy, or AddUserToGroup performed by an identity that doesn’t normally manage IAM
errorCode of AccessDenied on a sensitive IAM call, immediately followed by a successful related call — this is an attacker probing for the exact permission boundary
API calls originating from a sourceIPAddress that’s never been associated with that userIdentity.arn before
A new access key (CreateAccessKey) created and used within minutes, from a different IP than the one that created it
userIdentity.principalId showing a role assumed via AssumeRole shortly after suspicious IAM modification calls

How LogTriage detects this

The CloudTrail parser maps errorCode directly to HTTP-style status codes and extracts userIdentity.arn/userName/principalId into a normalized user_principal_name field, so the same session-grouping and risk-scoring logic that works across every other format applies here too. The MITRE mapper specifically recognizes IAM-modifying eventName values and tags them with the matching privilege escalation technique, so the connection between “this API call” and “this is a known attack technique” doesn’t depend on the analyst already knowing the MITRE matrix by heart.

Detection / evidence checklist

Reconstruct the full chain of IAM API calls by the same identity, in order, not just the one that triggered the alert
Identify every credential (access key, role, federated session) created or modified during the window
Check CloudTrail for any resource enumeration calls (ListUsers, ListRoles, GetAccountAuthorizationDetails) that preceded the escalation — that’s the reconnaissance phase
Revoke and rotate every credential touched in the chain, not just the one that was originally compromised
Review IAM policies for any role/user that grants iam:* or wildcard resource permissions broader than the role actually needs

Frequently Asked Questions

Which IAM API calls are the most dangerous in a privilege escalation chain?: AttachUserPolicy and PutUserPolicy (grant arbitrary permissions directly), CreateAccessKey (create long-lived credentials), AddUserToGroup (inherit group permissions), and UpdateAssumeRolePolicy (add the attacker's identity as trusted principal for an existing privileged role). Any one of these called by an identity that doesn't normally manage IAM is a high-priority signal.
Does LogTriage require CloudTrail to be enabled for all regions?: LogTriage analyzes whatever CloudTrail export you provide. For complete IAM escalation detection, AWS recommends enabling CloudTrail in all regions or using an organization-level trail, since IAM API calls are global but logged in the region the request was made to.
How does LogTriage handle assumed-role chains in CloudTrail?: The CloudTrail parser extracts userIdentity.arn and session context, normalizing them into a user_principal_name field. AssumeRole chains — where an identity assumes a role and then makes API calls under that role — are attributed to the originating principal, making the full escalation chain visible rather than just the individual calls.
What's the difference between an IAM escalation alert and a routine admin task?: Context: who made the call, from which IP, and what they normally do. An IAM admin making AttachUserPolicy calls during business hours from their normal workstation is routine. The same call made by a developer's access key, from a commercial hosting IP range, after a burst of AccessDenied errors, is the escalation pattern.

See this detection run on a real report

Try the live demo with a pre-loaded malicious log set — no signup required — or upload your own log file and get a full AI-reviewed threat report in minutes.

Try Live Demo → Analyze Your Own Logs