How to investigate AWS CloudTrail anomalies without a SIEM

1. Know what CloudTrail Event history can show you

AWS CloudTrail Event history is enabled by default and provides the previous 90 days of management events for one AWS account and one Region. It is useful for focused investigation, but it is not a complete or organization-wide log search.

Event history excludes data events, Insights events, and network activity events. Its filters accept one lookup attribute plus a time range. AWS also documents Event history as separate from trails and CloudTrail Lake event data stores. Start by acknowledging those boundaries so a missing event is not mistaken for proof that an action never occurred.

AWS reference: Working with CloudTrail Event history

2. Bound the search by time, account, and Region

Translate the alert or report into UTC, add a small buffer before and after it, and list every Region that could be relevant. The CloudTrail console and lookup-events operate on the selected or configured Region; repeat the search deliberately for each Region in scope.

Begin with the strongest known value—such as an event name, resource name, username, access key, or event ID. If you only know a time window, inspect the surrounding sequence and narrow from there.

aws cloudtrail lookup-events \
  --region us-east-1 \
  --start-time 2026-08-09T12:00:00Z \
  --end-time 2026-08-09T14:00:00Z \
  --lookup-attributes \
    AttributeKey=EventName,AttributeValue=AssumeRole

CloudTrail accepts one lookup attribute per command, returns at most 50 results per page, and limits lookup requests to two per second per account per Region. Follow the returned pagination token rather than assuming the first page is complete.

AWS references: Viewing events with the AWS CLI and Viewing events with the CloudTrail console

3. Reconstruct who did what—and how

Open the original event JSON and answer these questions before assigning severity:

Who?

Inspect userIdentity.type, ARN, account, principal ID, access key, session issuer, and sourceIdentity when present.

What?

Use eventSource and eventName to identify the service and API call. Check readOnly, affected resources, and request parameters.

Where?

Compare awsRegion and sourceIPAddress with known workloads, offices, VPNs, and AWS service behavior.

How?

Review userAgent, credential context, MFA indicators when available, and any role-session chain.

Result?

Check errorCode, errorMessage, response elements, and related events. A failed call can still reveal intent.

Target?

Identify the resource and compare its account, name, policy, tags, and lifecycle with the expected change.

Treat source IP as context, not identity. AWS notes that it can represent a console connection, an AWS service, a DNS name, or other intermediary—not necessarily the operator's physical device.

AWS references: CloudTrail record contents and CloudTrail userIdentity element

4. Prioritize high-signal behavior

One unfamiliar field rarely proves compromise. Combinations of identity, action, timing, and novelty are more useful. Investigate these patterns first:

• Identity and policy changes: new users, access keys, trust relationships, inline policies, or permissions attached outside a change window.
• Unexpected role assumptions: a new principal, unusual session name, missing expected source identity, or a role used from a new account.
• First-seen services or Regions: especially when paired with resource discovery or privilege changes.
• Failure bursts: repeated AccessDenied calls across services can indicate broken automation or reconnaissance. Resolve which with identity and user-agent evidence.
• Destructive or evasive changes: resource deletion, logging changes, key disabling, public-access changes, or security-control modification.
• Unfamiliar source and tooling: an unusual IP plus a new user agent is stronger evidence than either signal alone.

5. Validate the surrounding context

Compare the event with deployment logs, infrastructure-as-code changes, tickets, on-call activity, and the principal's normal schedule. Search immediately before and after the event for credential creation, discovery calls, role assumption, policy changes, and cleanup activity.

Preserve the original JSON, event ID, UTC timestamps, account, Region, and the query you used. If the action remains unexplained, rotate or disable exposed credentials according to your incident process, preserve wider evidence, and involve the resource owner. Do not let the initial Event history window become the only retained evidence.

6. Know when Event history is not enough

Use a trail or CloudTrail Lake when the investigation needs more than 90 days, data events, longer retention, multi-Region collection, organization-wide visibility, or richer querying. AWS recommends a multi-Region trail as a security best practice; trails can deliver records to Amazon S3 and optionally CloudWatch Logs.

AWS reference: Creating a trail for your AWS account