How to Analyze AWS CloudTrail Logs

What’s in a CloudTrail event

Every CloudTrail record captures eventSource, eventName, sourceIPAddress, userAgent, errorCode, and a userIdentity block that can be an IAM user, a role, a federated identity, or an AWS service itself. The userIdentity.arn is usually the most important field for security analysis — but eventName is what tells you whether a given call even matters.

What to look at first

1. IAM-modifying eventName values. AttachUserPolicy, PutUserPolicy, CreateAccessKey, UpdateAssumeRolePolicy, AddUserToGroup — these are the building blocks of privilege escalation, and they’re rare enough in normal operations to deserve scrutiny every time.
2. errorCode: AccessDenied followed by a related successful call. This is the signature of permission probing — an attacker testing boundaries before finding the gap.
3. sourceIPAddress consistency for a given identity. A role or user calling from an IP/ASN it’s never used before is worth a second look, independent of which API it called.
4. AssumeRole chains. Following userIdentity.principalId across a session can reveal an attacker pivoting from a low-privilege credential into a series of assumed roles.
5. Resource enumeration calls (ListUsers, ListRoles, GetAccountAuthorizationDetails) preceding a privilege change — this is the reconnaissance phase, and it’s loggable.

Common patterns and what they mean

Pattern	Likely meaning
CreateAccessKey then immediate use from a different IP	Credential exfiltration and reuse
AccessDenied then a related success	Active permission-boundary probing
New role created, then assumed within minutes	Privilege escalation via role creation
Resource enumeration, then targeted IAM change	Reconnaissance followed by exploitation
API calls from a region your organization doesn’t operate in	Possible compromised credential use

Where manual log review breaks down

CloudTrail logs are voluminous by design — that’s the point, it’s meant to capture everything. The privilege-escalation chains that matter are rarely a single suspicious call; they’re three or four individually-plausible calls strung together over a few minutes, which is exactly the kind of pattern that’s invisible scrolling through a console one event at a time.

LogTriage normalizes CloudTrail’s userIdentity and errorCode fields into the same model used across every other log source, maps IAM-modifying events directly to MITRE ATT&CK techniques, and groups related calls into sessions so the escalation chain — not just the individual API call — is what gets surfaced.