CloudTrail investigation: event coverage, identity evidence and missing records
Distinguish CloudTrail management and data events, Event history and durable trail delivery. Investigate missing records through collection scope, identity context, retention and log integrity.
TL;DR: A missing CloudTrail search result is meaningful only after you establish that the operation was collected, delivered and retained in the place you searched. Event history covers recent management events; object-level activity needs the relevant data-event collection.
Start with the operation you need to prove
Creating an S3 bucket and reading an object from it are different audit questions. Bucket configuration changes are management activity; supported object operations are data activity. A trail that collects management events can be healthy while omitting the object reads an investigator needs.
CloudTrail Event history provides the past ninety days of management events for an account and Region. It is separate from trails and event data stores, does not aggregate an organization, and does not show data events. Check the time range and filters too. AWS documents these boundaries in Event history.
For supported data events, configure selectors covering the relevant resource types and operations. Defaults and selectors matter more than the phrase “CloudTrail enabled.” See data-event logging and S3 event coverage.
This is an evidence decision tree. Enabling additional collection now cannot recreate unrecorded requests from yesterday.
Distinguish the stores before searching them
| Evidence location | Useful scope | Boundary to check |
|---|---|---|
| Event history | Recent management activity | Account, Region and ninety-day window |
| Trail delivered to S3 | Selected events retained as log files | Selectors, delivery, bucket access and lifecycle |
| Organization trail | Collection for covered organization accounts | Actual account/Region coverage and central access |
| Application or access logs | Service-specific actions and outcomes | Different identifiers, retention and collection gaps |
An organization trail centralizes selected activity; it does not turn every possible data event on. A configured destination also does not establish successful delivery. Review the trail's logging state and delivery errors, destination permissions, encryption-key access and object arrival times. Investigators need permission to retrieve the evidence without granting workload operators the power to erase its only copy.
Reconstruct a suspicious role session
Use a fictional report: an object under exports/ was downloaded at about 14:20 UTC. The responder searches Event history for GetObject, finds nothing and declares that no download occurred. The conclusion fails at the collection boundary: the chosen view excludes data events.
Inspect whether the object's bucket and operation were selected for data-event logging at the relevant time. If they were, query the retained trail files or configured event store. If they were not, record the gap and look for independent evidence such as application access records. Do not relabel absence as a confirmed negative.
When a record exists, preserve its event ID, event time, source, action, account/Region, resource details and error fields. An assumed-role session should be interpreted with its session issuer and credential context. A source IP might be a proxy or service path; a role name alone does not identify a particular human. The event record reference defines which fields are available and their limitations.
Correlate the event with the workload's request identifiers and identity-federation records where available. A successful API call is evidence about that API operation. It does not by itself prove the downstream business process completed or that a named employee personally initiated it.
Preserve integrity without overstating completeness
CloudTrail log-file validation uses digest files and signatures to detect changes to delivered log files. Enabling validation does not automatically run a verification of the files, and it does not prove that your selectors collected every operation of interest. Follow the integrity validation documentation when preserving an investigation set.
An interview answer should name the evidence gap before proposing a retention or collection change. That produces a useful follow-up: how will the team test that the new control actually records the intended operation?
Self-check: management events arrive in the central bucket, but a deliberately performed S3 object read produces no data record. What do you inspect first? Check the data-event selector and covered bucket/operation, then delivery and query scope. Healthy management delivery proves only part of the collection path.