CloudTrail and Auditability

What we're doing: See why a security investigation into an S3 object deleted 4 months ago finds nothing without a trail.

Account has never created a trail.
An object in a sensitive S3 bucket is deleted.
Investigator opens Event history 4 months later, searches "DeleteObject":
→ No results — Event history only holds 90 days, AND it never held this
  event in the first place: DeleteObject is a data event, off by default

1

Nothing about a fresh AWS account logs S3 object-level activity automatically — that requires a trail with data events explicitly enabled.

4

Two separate gaps stack here: the 90-day window (even if it were a management event) and data events being opt-in and billed separately from management events.

Why this works: Event history's 90-day window and management-events-only scope make it useful for a quick "what changed this week" check, but it is not a substitute for a trail — an investigation that needs S3 object-level history or anything older than 90 days finds nothing without one.

What we're doing: See what happens when a workload IAM role that can delete objects also happens to have access to the trail's own log bucket.

Trail's S3 bucket lives in the same account as the application it audits.
The application's IAM role has a broad s3:* policy (common over-grant).
Attacker compromises the application via a dependency vulnerability.
Attacker uses the app's own role to call s3:DeleteObject on the trail's
bucket, removing the log files that would show the compromise.

1

Nothing about CloudTrail itself requires this — it is a configuration choice to put the log bucket where the workload can reach it.

2

A broad s3:* grant is common when a team scopes IAM by "the app needs S3 access" rather than by bucket — and it silently includes the log bucket too.

5

The attacker never needed CloudTrail-specific permissions — ordinary S3 delete permission on the wrong bucket was enough to destroy the evidence.

Why this works: This is exactly the failure a dedicated log archive account with a least-privilege bucket policy prevents — the application's role, however broad its S3 permissions, simply has no network or IAM path to a bucket that lives in a different account it was never granted access to.

What we're doing: Read a real CloudTrail event structure and pull out the five audit answers.

{
  "eventVersion": "1.08",
  "userIdentity": {
    "type": "AssumedRole",
    "arn": "arn:aws:sts::123456789012:assumed-role/DevRole/jordan.reyes",
    "accountId": "123456789012",
    "sessionContext": {
      "sessionIssuer": {
        "type": "Role",
        "arn": "arn:aws:iam::123456789012:role/DevRole"
      }
    }
  },
  "eventTime": "2026-08-24T14:02:11Z",
  "eventSource": "s3.amazonaws.com",
  "eventName": "DeleteBucket",
  "sourceIPAddress": "203.0.113.42",
  "requestParameters": { "bucketName": "quarterly-reports-archive" }
}

3

who: an AssumedRole session named "jordan.reyes" — the ARN alone tells you the role, and the session name (set by the caller) usually maps to a specific person or automation job.

9

under which identity: sessionIssuer shows this session came from assuming the DevRole IAM role — the identity that was actually granted the DeleteBucket permission in the first place.

15

when: 2026-08-24 at 14:02:11 UTC, to the second.

16

what: eventSource + eventName together say precisely which API call happened — s3.amazonaws.com's DeleteBucket, not just "something in S3."

17

from where: sourceIPAddress narrows the search to a specific network origin, which is often the fastest way to tell a legitimate CI job from an unexpected human login.

Why this works: None of these five answers require correlating multiple systems — a single CloudTrail event record already carries all of them, which is exactly why CloudTrail (not application logs, not S3 access logs alone) is the first place an incident investigation starts.