Detecting CloudTrail Tampering and Logging Anomalies

Defense evasion in AWS usually starts with the audit trail: stopping or deleting a trail, narrowing its event selectors, or damaging the bucket and key that protect the logs. Each of these is itself an API call, usually recorded by another trail, so it can be alerted on. The harder case is silence, which needs a heartbeat rather than a signature.

Signals at a Glance

The Tampering API Calls

Cover the trail, its coverage and the services that watch alongside it. This Sigma rule collects the core calls; split it by severity once you know which are routine in your change process:

title: AWS Logging And Detection Service Tampering
logsource:
  product: aws
  service: cloudtrail
detection:
  trail:
    eventSource: 'cloudtrail.amazonaws.com'
    eventName:
      - 'StopLogging'
      - 'DeleteTrail'
      - 'UpdateTrail'
      - 'PutEventSelectors'
      - 'PutInsightSelectors'
  config:
    eventSource: 'config.amazonaws.com'
    eventName:
      - 'StopConfigurationRecorder'
      - 'DeleteConfigurationRecorder'
      - 'DeleteDeliveryChannel'
  guardduty:
    eventSource: 'guardduty.amazonaws.com'
    eventName:
      - 'DeleteDetector'
      - 'UpdateDetector'
  condition: trail or config or guardduty
level: high
# tune/validate: UpdateTrail and UpdateDetector occur in legitimate changes; allowlist your IaC roles

• Send a copy of audit logs to a separate log-archive account with a bucket policy that denies deletion, so tampering in the workload account cannot erase the record.
• Use an organisation trail and service control policies that deny StopLogging and DeleteTrail to all but a break-glass role.
• Enable CloudTrail log file validation so edits to delivered files are provable.

Detecting Silence

If tampering succeeds before an alert runs, the signal is absence. A CloudWatch Logs metric filter on the trail’s log group is a fast, native tripwire, and an Athena heartbeat finds regions or accounts that have gone quiet:

# CloudWatch Logs metric filter pattern (CIS-style) on the CloudTrail log group
{ ($.eventName = CreateTrail) || ($.eventName = UpdateTrail) || ($.eventName = DeleteTrail) || ($.eventName = StartLogging) || ($.eventName = StopLogging) }

-- Athena SQL - hours with no events for an account and region that normally has steady traffic
SELECT recipientaccountid, awsregion, date_trunc('hour', from_iso8601_timestamp(eventtime)) AS hr, count(*) AS events
FROM cloudtrail_logs
WHERE from_iso8601_timestamp(eventtime) > current_timestamp - interval '7' day
GROUP BY 1, 2, 3
ORDER BY recipientaccountid, awsregion, hr;
-- tune/validate: compare against each region's own hourly baseline; quiet regions need a longer window, and gaps should alert in your scheduler, not by eye

• Alert on any gap longer than your delivery-latency tolerance for an account that normally emits continuous management events.
• After a confirmed event, rebuild the timeline from the log-archive copy, VPC flow logs and service-native logs such as S3 server access logs.