CloudTrail Investigation: How to Trace Suspicious Activity in AWS

Last verified on Nov 8, 2026.

CloudTrail records API calls and console sign-ins in your AWS account, and it is the first place to look when you ask who did something, from where, and what else they did. An investigation means choosing a pivot such as an access key, a user, or an IP address, pulling every event for it, then widening the search to the actions that attackers tend to take. This guide covers the record structure, where to run queries, and a set of ready queries for Logs Insights and Athena.

Read a CloudTrail Event

Most of an investigation uses the fields below from the event record.

userIdentity.type tells you the kind of principal. AWS documents types including Root, IAMUser, AssumedRole, and FederatedUser. For temporary credentials, the sessionIssuer element shows the role or user that issued the session, which is how you follow an ASIA key back to its source. awsRegion matters too: events are recorded in the Region where they happened.

Two cautions. The sourceIPAddress for actions originating in the console is the address of the underlying customer resource, not the console web server, and for calls from inside AWS it may be a DNS name or AWS Internal/<number>. And errorCode is only sometimes top-level: some services report error information inside responseElements.

Choose Where to Query

Event history is a searchable, downloadable, immutable record of 90 days of management events in a Region, with no charge to view it. lookup-events takes a time range and one lookup attribute: AccessKeyId, EventName, EventSource, and Username, among others.

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=Username,AttributeValue=alice \
  --start-time 2026-11-01T00:00:00Z --end-time 2026-11-08T00:00:00Z \
  --max-results 50 --output json \
| jq -r '.Events[].CloudTrailEvent | fromjson
    | [.eventTime, .eventSource, .eventName, .sourceIPAddress, .userAgent, (.errorCode // "-")] | @tsv'

Run it in every Region you use. Event history shows no data events such as S3 object reads, and lookup-events accepts only one lookup attribute per query, so filter on a second attribute, such as the source address, in jq. For a single leaked key, see leaked AWS access key. To catch privilege-granting calls such as CreateAccessKey as they happen, see the privilege changes detection guide. GuardDuty findings are a good source of pivots, since each names the principal, API, and source address to start from. To send trails into a log platform, the AWS CloudTrail integration covers the setup.

Investigation Queries

These queries are written for CloudWatch Logs Insights, over the log group a trail delivers to. Insights discovers JSON fields automatically, so nested fields such as userIdentity.arn can be addressed directly. Athena equivalents follow where the shape differs.

Failed console sign-ins. A failed IAM user sign-in is a ConsoleLogin event from signin.amazonaws.com with errorMessage of Failed authentication and responseElements.ConsoleLogin set to Failure.

filter eventName = "ConsoleLogin" and responseElements.ConsoleLogin = "Failure"
| stats count(*) as failures by userIdentity.userName, sourceIPAddress
| sort failures desc

Many failures from one address against many names is password spraying. Many failures against one name, then a success from the same address, is the pattern to escalate. Check the successes too: filter responseElements.ConsoleLogin = "Success" and compare additionalEventData.MFAUsed.

Persistence: new identities, keys, and policies. GuardDuty describes persistence APIs as typically create or modify operations, such as CreateAccessKey:

filter eventName in ["CreateUser", "CreateAccessKey", "CreateLoginProfile", "AttachUserPolicy", "PutUserPolicy", "AttachRolePolicy", "UpdateAssumeRolePolicy"]
| fields @timestamp, eventName, userIdentity.arn, sourceIPAddress, requestParameters.userName, errorCode
| sort @timestamp desc

Defense evasion: logging changes. GuardDuty describes defense evasion as delete, disable, or stop operations such as StopLogging:

filter eventName in ["StopLogging", "DeleteTrail", "UpdateTrail", "PutEventSelectors"]
| fields @timestamp, eventName, userIdentity.arn, sourceIPAddress, errorCode
| sort @timestamp desc

Bucket exposure. Changes to bucket policies, ACLs, and public access blocks:

filter eventSource = "s3.amazonaws.com" and eventName in ["PutBucketPolicy", "PutBucketAcl", "DeleteBucketPolicy", "PutBucketPublicAccessBlock", "DeletePublicAccessBlock"]
| fields @timestamp, eventName, userIdentity.arn, sourceIPAddress, requestParameters.bucketName

Secret reads in bursts. One application reading its own secret on startup is normal. A new principal reading many secrets in minutes is not:

filter eventSource = "secretsmanager.amazonaws.com" and eventName = "GetSecretValue"
| stats count(*) as reads by bin(5m), userIdentity.arn, sourceIPAddress
| sort reads desc
| limit 20

Root and failed calls. Root activity should be rare, and a run of different failing calls is often enumeration:

filter userIdentity.type = "Root"
| stats count(*) by eventName, sourceIPAddress

filter ispresent(errorCode)
| stats count(*) as errors by userIdentity.arn, errorCode
| sort errors desc

The Same Questions in Athena

With the partition-projected table from AWS's documentation, cloudtrail_logs_pp, always filter on the timestamp partition (formatted yyyy/MM/dd) to limit the scan. In that table responseelements is a string, so extract the field:

SELECT eventtime, useridentity.username, sourceipaddress, useragent, errormessage
FROM cloudtrail_logs_pp
WHERE "timestamp" >= '2026/11/01'
  AND eventname = 'ConsoleLogin'
  AND json_extract_scalar(responseelements, '$.ConsoleLogin') = 'Failure'
ORDER BY eventtime DESC
LIMIT 100;

SELECT useridentity.arn, sourceipaddress,
       date_trunc('minute', from_iso8601_timestamp(eventtime)) AS minute,
       count(*) AS reads
FROM cloudtrail_logs_pp
WHERE "timestamp" >= '2026/11/01'
  AND eventsource = 'secretsmanager.amazonaws.com'
  AND eventname = 'GetSecretValue'
GROUP BY 1, 2, 3
HAVING count(*) > 20
ORDER BY reads DESC;

Judge What You Find

A single odd event proves little. Look for sequences: a failed login streak, then a success, then CreateAccessKey, then calls from a Region you do not use. Build a timeline by principal and by source address, mark the first event that should not have happened, and work backwards for how access began and forwards for what it reached.

Check the record itself. A stopped trail leaves a gap, which the logging-change query above would show. CloudTrail log file integrity validation delivers digest files so you can detect tampering with delivered logs, and it is enabled by default for new trails.

Searching CloudTrail Events in Sazabi

Sazabi, an AI-native observability and security platform, streams CloudTrail events from your trail's CloudWatch Logs group. Each event keeps CloudTrail's own JSON, so eventName, eventSource, userIdentity, sourceIPAddress, and errorCode remain searchable fields.