AWS CloudTrail Log Format: Field Reference and Example Records

    {
      "eventVersion": "1.08",
      "userIdentity": {
        "type": "IAMUser",
        "arn": "arn:aws:iam::123456789012:user/alice",
        "userName": "alice",
        "accountId": "123456789012"
      },
      "eventTime": "2024-01-15T09:05:12Z",
      "eventSource": "s3.amazonaws.com",
      "eventName": "ListBuckets",
      "awsRegion": "us-east-1",
      "sourceIPAddress": "203.0.113.10",
      "userAgent": "aws-cli/2.13.0 Python/3.11.4 Darwin/22.6.0",

What it records

A CloudTrail record describes one API call in an AWS account: the time, the service (eventSource) and operation (eventName), the calling identity and the credentials it used (userIdentity), the source address and client (sourceIPAddress, userAgent), the parameters sent and values returned (requestParameters, responseElements), and, when the call failed, errorCode and errorMessage.

Management events — control-plane operations such as creating a policy, attaching it to a user or assuming a role — are the default content. Data events, such as individual S3 object reads or Lambda invocations, are recorded only when a trail is configured to capture them.

In log files written to S3 the records are gzipped JSON with a top-level Records array, exactly as in the samples on this page.

Where to get it

• Event history in the CloudTrail console: the last 90 days of management events for the current region, searchable and downloadable, with no setup required.
• A trail delivering log files to an S3 bucket, optionally multi-region and optionally organization-wide. This is what gives you retention beyond 90 days and the only place data events appear.
• CloudWatch Logs, if the trail is configured to send events there as well, for near-term queries and metric filters.
• CloudTrail Lake, which stores events as a queryable event data store.

Trails can also write digest files so the delivered log files can be checked for tampering with log file integrity validation.

Parsing pitfalls

• requestParameters and responseElements are shaped per API. There is no fixed schema; the same key can be a string in one operation and an object in another. Flatten them lazily, or store them as raw JSON and extract per eventName.
• Nulls everywhere. Both fields are frequently null, as is userIdentity.accessKeyId on some records. A parser that assumes objects will drop events.
• sourceIPAddress is not always an IP. When an AWS service calls on your behalf, the field carries the service’s DNS name, which breaks IP-typed columns and geolocation.
• Delivery lag and ordering. eventTime is set by the service, files arrive in batches, and records within a file are not in time order. Sort before building a timeline, and do not read a gap at the end of the data as silence.
• Duplicates happen. Deduplicate on eventID rather than assuming one delivery per call.
• Read-only calls look harmless. ListBuckets, DescribeInstances and GetBucketPolicy are routine for administrators and also exactly what reconnaissance looks like; context, not the operation name, separates them.

Detection ideas

• Privilege escalation: CreatePolicy with a wildcard action followed by AttachUserPolicy on the caller’s own user, then AssumeRole — the sequence in the malicious sample and the basis of the CloudTrail IAM privilege-escalation rule.
• Logging tampering: StopLogging, DeleteTrail, PutEventSelectors or deletion of the log bucket, especially from an identity that has never touched CloudTrail before.
• Permission probing: many AccessDenied results for one userIdentity.arn across different eventSource values in a short window.
• Stolen key use: an accessKeyId appearing from a new sourceIPAddress, a new awsRegion or a scripted userAgent such as python-requests when the owner normally uses the CLI.
• Data staging: GetBucketPolicy and ListObjects against production data buckets by an identity whose job is development.

The free browser analyzer runs these checks on a CloudTrail JSON export without uploading it.