Last reviewed:
A practical guide to turning AWS CloudTrail records into SOC detections for credential misuse, privilege change and control-plane tampering.
CloudTrail is the AWS audit trail for control-plane activity. A useful detection starts with that limitation. CloudTrail can show that a principal called an API, which service handled it, where the request came from and whether AWS returned an error. It does not prove what happened inside an EC2 instance after that call.
The fields SOC teams should preserve are userIdentity, eventSource, eventName, awsRegion, sourceIPAddress, userAgent, requestParameters, responseElements, errorCode and recipientAccountId. Those names come from the CloudTrail event record, not from a SIEM parser. Your SIEM may rename them, but the review should keep the original AWS field beside the mapped field.
Treat eventName as a starting point, not a detection on its own. CreateAccessKey, AssumeRole and ConsoleLogin tell different stories depending on the userIdentity.type, the sourceIPAddress, the account, the MFA context and whether the principal normally performs that action.
CloudTrail coverage becomes messy when teams start with a long list of API names. Start with detection families instead. Identity access, privilege change, logging tamper and data access each need different context. A single event list cannot carry that difference.
For identity access, ConsoleLogin and AssumeRole are usually the first events to review. The useful context is userIdentity.type, userIdentity.arn, sourceIPAddress, userAgent and additionalEventData.MFAUsed where it appears. For privilege change, the IAM events matter more: CreateAccessKey, AttachUserPolicy, PutUserPolicy, CreatePolicyVersion and UpdateAssumeRolePolicy are common review targets.
For logging tamper, watch the CloudTrail service itself. StopLogging, DeleteTrail, PutEventSelectors and UpdateTrail deserve a separate severity model because they can reduce the evidence available after an intrusion. For data access, CloudTrail management events are not enough. You may need S3 data events or other service-specific data events enabled before the detection is honest.
Many CloudTrail detections support ATT&CK T1078 Valid Accounts, but the evidence is not always equal. A successful ConsoleLogin by an IAM user from a new ASN is different from an AssumeRole call by known deployment automation. Both can use valid credentials. Only one may be suspicious without extra context.
Use evidence labels when mapping CloudTrail to ATT&CK. Direct detection evidence means the event and context show the attacker behaviour clearly enough to alert. Correlation context means the event matters only when paired with another signal. Posture context means the event describes exposure or configuration risk, not active abuse.
That labelling keeps coverage reporting honest. A SOC lead can still see that CloudTrail helps with Valid Accounts, Account Discovery, Cloud Service Dashboard and Impair Defences, but the report does not pretend every mapped event is equally alertable.
def cloudtrail_evidence_kind(event):
if event.eventName in {'ConsoleLogin', 'AssumeRole'} and event.has_unusual_source:
return 'direct-detection'
if event.eventName in {'CreateAccessKey', 'AttachUserPolicy', 'PutUserPolicy'}:
return 'direct-detection'
if event.eventName in {'StopLogging', 'DeleteTrail', 'PutEventSelectors'}:
return 'logging-tamper'
return 'correlation-context'
Most SOC teams do not query raw CloudTrail JSON forever. Splunk, Sentinel, Elastic, OpenSearch and Google SecOps all have their own normalised field names and parser habits. That is fine, as long as the detection review can still point back to the AWS event field.
For every CloudTrail rule, keep a small mapping table in the rule notes or detection repository. It should say which AWS field was used, what the SIEM calls it and whether the field is always present. This avoids a common failure mode: a rule looks right in Sigma, but the production parser never populates the selected field.
CloudSigma can produce Sigma rules from CVE and advisory inputs, but CloudTrail tuning still belongs in the customer SIEM. Operators should test converted queries against their own parser, account list and automation inventory before enabling alerts.
Review CloudTrail detections whenever AWS adds relevant event types, when a new account joins the organisation, or after an incident shows that an API call was visible but unmapped. The review should include both rule logic and collection scope. A perfect query cannot detect S3 object reads if data events are not collected for the bucket.
A useful quarterly review asks four questions: which high-risk API calls have no alert, which alerts depend on optional logging, which detections are noisy because automation is unnamed, and which ATT&CK techniques are covered only by correlation context. The answers give the backlog its shape.
DCV helps by keeping CloudTrail-derived mappings visible in the coverage model. The point is not to colour more cells green. The point is to show which AWS behaviours the SOC can detect today, which ones need better logs, and which ones need SIEM tuning before they are safe to count.