AWS CloudTrail Log Integrity: Detecting Tampering and Ensuring Your Audit Trail Is Valid

A compromised AWS account where the attacker deleted CloudTrail logs is worse than an account with no CloudTrail at all — because you believe you have a complete audit trail when you don't. Log tampering is a standard post-compromise step: stop logging to prevent detection, delete existing logs to eliminate evidence, or modify logs to replace attacker activity with benign entries. Each scenario requires a different technical countermeasure.

CloudTrail provides a log file validation mechanism that makes tampering detectable — but only if you actually validate the logs. This guide covers how log file validation works, how to verify it, how to detect and alert on log-tampering attempts in real time, and how to protect logs from deletion using S3 Object Lock.

How CloudTrail Log File Validation Works

When log file validation is enabled on a trail, CloudTrail creates a digest file every hour. The digest file contains the S3 keys and SHA-256 hashes of every log file delivered during that hour, and is itself signed using CloudTrail's RSA private key. Each digest file also includes the hash of the previous digest file, forming a cryptographic hash chain.

To verify integrity, you reconstruct the hash chain from a starting digest file forward to the present. Any log file that was modified after delivery has a different hash than the digest file records. Any log file that was deleted is missing from the chain. Any tampered digest file breaks the chain at that point. The AWS CLI's aws cloudtrail validate-logs command performs this verification automatically.

The validation result identifies exactly which log files were tampered with or deleted, when the tampering occurred, and the gap in coverage caused by the attack. This evidence is admissible in legal proceedings as proof of tampering and is sufficient to demonstrate to auditors that the remaining log files are authentic.

Running Log Validation

Validate logs using: aws cloudtrail validate-logs --trail-arn arn:aws:cloudtrail:{region}:{account-id}:trail/{trail-name} --start-time {iso-datetime} --end-time {iso-datetime} --region {region}. The command outputs validation results for each digest and log file in the specified time range.

For multi-region trails, run validation separately in each region or use the --s3-bucket flag to validate across all regions simultaneously. The output categorizes files as VALID, INVALID, or MISSING — any result other than VALID requires investigation.

Automate validation with a scheduled Lambda function that runs weekly, validates the past week's logs, and publishes results to CloudWatch Metrics or an SNS topic. Alert on any INVALID or MISSING result. Regular automated validation catches tampering quickly and demonstrates continuous log integrity monitoring to auditors.

Real-Time Alerting for Log-Tampering Attempts

Log file validation is retroactive — it detects tampering after the fact. Real-time alerting on log-tampering API calls catches attempts as they happen.

Configure EventBridge rules for the following CloudTrail API calls: DeleteTrail (deletes the trail entirely), StopLogging (disables event capture without deleting the trail), UpdateTrail (changes trail configuration, potentially removing regions or event types), and PutEventSelectors (narrows event selection, potentially excluding security-relevant events).

Each of these events warrants immediate response — route them to your highest-priority alert channel and initiate your incident response process. In particular, DeleteTrail and StopLogging executed outside of a documented change window should be treated as active intrusion indicators regardless of who executed them.

Add an automated response for StopLogging and DeleteTrail that immediately re-enables logging via a Lambda function. The Lambda should: call StartLogging to re-enable a disabled trail, notify the security team with the caller's identity and IP, and initiate your credential review process for the principal that disabled logging. This response cannot restore deleted log files, but it limits the gap in coverage created by the attack.

Protecting Logs from Deletion

Log file validation detects tampering; S3 Object Lock prevents it. Enabling Object Lock in Compliance mode on your CloudTrail bucket makes log files immutable for the configured retention period — no principal, including root, can delete or overwrite them. This eliminates the ability to destroy evidence even for attackers with full account compromise.

Enable S3 Versioning before enabling Object Lock (Object Lock requires versioning). Set the Object Lock retention period to your compliance requirement: 12 months minimum for most security frameworks, 7 years for financial regulatory requirements. Note that Object Lock in Compliance mode cannot be disabled for the duration of the retention period — configure the retention period thoughtfully before enabling.

The AWS Config rule cloudtrail-enabled checks whether CloudTrail is enabled and delivers to an S3 bucket with log file validation enabled. Deploy this rule with auto-remediation to automatically re-enable and reconfigure CloudTrail if it is disabled. The remediation uses an SSM Automation document to restore the trail configuration.

Related Reading

• CloudTrail best practices — complete audit logging configuration
• CloudTrail alerting — real-time detection of critical API events
• AWS incident response plan — responding to log tampering as a security event
• S3 security best practices — securing the bucket that holds your logs

FAQ

Does CloudTrail log file validation protect against logs being read by unauthorized parties?

No. Log file validation addresses integrity (have logs been modified or deleted?) not confidentiality (who has access to read them?). Protect log confidentiality through S3 bucket policies that restrict access to authorized auditors and security tools, S3 encryption at rest using KMS with restricted key policies, and access logging on the CloudTrail bucket to record who reads the logs.

If an attacker deletes CloudTrail logs, can I still detect what they did?

Partially. CloudTrail log file validation will identify which files were deleted and the time window they covered. For that window, you have no CloudTrail evidence of what actions were taken. However, other evidence sources may partially reconstruct the timeline: VPC Flow Logs (if stored separately from CloudTrail), CloudWatch Logs (if CloudWatch Logs delivery was configured), application-level logs, and AWS Config configuration snapshots. Keeping evidence sources in separate accounts and storage locations limits the damage an attacker can do by compromising a single account.

Is CloudTrail log file validation compliant with PCI DSS requirements for audit log integrity?

Yes. PCI DSS Requirement 10.5 requires that audit trails be secured to prevent modification. CloudTrail log file validation, combined with S3 Object Lock and restricted S3 bucket policies, satisfies this requirement. Auditors typically require evidence that validation is performed regularly, not just that the capability exists — automated weekly validation with results reviewed and retained provides that evidence.