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