Cloud Logging and Detection: Attacking and Defending CloudTrail and GuardDuty

Cloud Security
2025.09.28
Time it takes to read this article 6 minutes.

Disclaimer: This article is for educational purposes and authorized security testing only. Run these techniques exclusively in accounts you own or where you have explicit written authorization. Tampering with logging in systems you do not control is illegal in most jurisdictions and violates the AWS Acceptable Use Policy.

Introduction / Overview

In AWS, your audit trail is only as trustworthy as the controls protecting it. CloudTrail records management and data-plane API calls, while GuardDuty consumes CloudTrail, VPC Flow Logs, and DNS logs to emit threat findings. Attackers who gain credentials know this, so one of their earliest objectives is defense evasion — blinding CloudTrail or disabling GuardDuty so subsequent actions go unrecorded.

This post walks through the most common log-tampering and detection-evasion techniques (mapped to MITRE ATT&CK), demonstrates them in a lab, and gives the blue team an equal-weight playbook to close the detection gaps.

How it works / Background

CloudTrail has two relevant surfaces:

  • Event history — a free, 90-day, read-only record that exists even with no trail configured. It captures management events only and cannot be deleted by an attacker.
  • Trails — configurable delivery to an S3 bucket (and optionally CloudWatch Logs). Trails can be stopped, deleted, or have their event selectors narrowed. This is the soft target.

GuardDuty is a regional detector. Disabling the detector in a region, or suspending it, stops new findings from that region. Because both services are regional, attackers frequently pivot to a region the defender ignores.

Key ATT&CK techniques in play:

  • T1562.008 – Impair Defenses: Disable or Modify Cloud Logs
  • T1578.005 – Modify Cloud Compute Infrastructure (region pivoting context)
  • T1070 – Indicator Removal

Prerequisites / Lab setup

You need an AWS account you control, the AWS CLI v2, and an IAM principal with administrative rights for setup (we will then simulate an attacker with scoped permissions).

# Confirm identity and region
aws sts get-caller-identity
aws configure get region

# Create a trail that logs all regions to S3
aws cloudtrail create-trail \
  --name lab-org-trail \
  --s3-bucket-name my-lab-cloudtrail-bucket \
  --is-multi-region-trail

aws cloudtrail start-logging --name lab-org-trail

# Enable GuardDuty in the current region
aws guardduty create-detector --enable
Bash

Walkthrough / PoC (Red Team)

Assume the attacker has compromised access keys with broad permissions. The first reconnaissance step is enumerating what visibility the defender has.

1. Enumerate logging posture

# List trails and check whether logging is on
aws cloudtrail describe-trails --query 'trailList[].[Name,IsMultiRegionTrail]'
aws cloudtrail get-trail-status --name lab-org-trail \
  --query '[IsLogging,LatestDeliveryTime]'

# Find GuardDuty detectors per region
aws guardduty list-detectors
Bash

2. Stop the trail (noisy but effective)

aws cloudtrail stop-logging --name lab-org-trail
Bash

This single call emits a StopLogging event before logging halts, so it is detectable — but only if someone is watching. Deleting the trail (delete-trail) is similar.

3. Surgical evasion — narrow event selectors

Rather than stopping the trail outright (loud), a stealthier move is to reconfigure the trail so it stops capturing the events the attacker cares about. For example, disabling management event logging:

aws cloudtrail put-event-selectors \
  --trail-name lab-org-trail \
  --event-selectors '[{"ReadWriteType":"ReadOnly","IncludeManagementEvents":false}]'
Bash

Now write management events (the ones an attacker generates) are no longer delivered, while the trail still appears "enabled" in the console.

4. Disable GuardDuty per region

DET=$(aws guardduty list-detectors --query 'DetectorIds[0]' --output text)
aws guardduty update-detector --detector-id "$DET" --no-enable
# or fully remove it
aws guardduty delete-detector --detector-id "$DET"
Bash

5. Region pivot (the real detection gap)

Most organizations build trails as multi-region but only monitor GuardDuty in a handful of regions. An attacker enumerates all regions and operates where GuardDuty is absent:

for r in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text); do
  echo "== $r =="
  aws guardduty list-detectors --region "$r" --query 'DetectorIds' --output text
done
Bash

Any region returning an empty list is a blind spot for behavioral detection, even though management events may still reach the multi-region trail.

6. Test GuardDuty without real malice

You can validate detection plumbing safely using GuardDuty's built-in sample finding generator:

aws guardduty create-sample-findings --detector-id "$DET" \
  --finding-types "UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.InsideAWS"
Bash

This produces a finding that should flow through EventBridge to your SIEM — a great way to prove the pipeline works (or doesn't) before an incident.

Attack and detection flow

Cloud Logging and Detection: Attacking and Defending CloudTrail and GuardDuty diagram 1

The diagram shows the attacker's evasion decision tree on the left and the two blue-team tripwires (right) that fire when logging or the detector is tampered with.

Detection & Defense (Blue Team)

Evasion only works when nobody is watching the watchers. Build these controls with equal priority to the offensive concerns above.

1. Protect the trail at the org level

Use AWS Organizations to deploy an organization trail and a Service Control Policy (SCP) that denies tampering even for account admins:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyCloudTrailTampering",
    "Effect": "Deny",
    "Action": [
      "cloudtrail:StopLogging",
      "cloudtrail:DeleteTrail",
      "cloudtrail:UpdateTrail",
      "cloudtrail:PutEventSelectors"
    ],
    "Resource": "*"
  }]
}
JSON

Attach this SCP to member OUs; only the management account (out of attacker reach) can change logging.

2. Detect tampering in near real-time

GuardDuty natively raises Stealth:IAMUser/CloudTrailLoggingDisabled and Stealth:IAMUser/LoggingConfigurationModified findings. Ensure these route to action. As a backstop, alarm directly on the CloudTrail API call via CloudWatch Logs metric filters:

aws logs put-metric-filter \
  --log-group-name CloudTrail/Logs \
  --filter-name StopLoggingFilter \
  --filter-pattern '{ ($.eventName = "StopLogging") || ($.eventName = "DeleteTrail") || ($.eventName = "PutEventSelectors") }' \
  --metric-transformations metricName=CloudTrailTampering,metricNamespace=Security,metricValue=1

aws cloudwatch put-metric-alarm \
  --alarm-name CloudTrailTampering \
  --metric-name CloudTrailTampering --namespace Security \
  --statistic Sum --period 300 --threshold 1 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --evaluation-periods 1 \
  --alarm-actions arn:aws:sns:us-east-1:111122223333:sec-alerts
Bash

3. Close the region gap

Enable GuardDuty in every region — including ones you don't use — and centralize findings via a delegated administrator account. An idle region with a detector is your canary for region-pivot attacks. Also enable S3, DNS, and Malware Protection data sources.

4. Make logs immutable

Enable S3 Object Lock in compliance mode and MFA Delete on the CloudTrail bucket, and turn on CloudTrail log file validation (--enable-log-file-validation) so any post-hoc deletion or modification of delivered log files is provably detectable:

aws cloudtrail update-trail --name lab-org-trail --enable-log-file-validation
aws cloudtrail validate-logs --trail-arn <arn> --start-time 2025-09-01T00:00:00Z
Bash

5. Centralize and decouple

Ship logs to a dedicated, hardened security/log-archive account that workload principals cannot touch. This is the single most impactful control: even full compromise of a workload account does not grant the attacker the ability to delete the canonical copy of the logs.

For deeper IAM-side hardening, see my notes on IAM privilege escalation paths and the broader cloud attack lifecycle.

Conclusion

CloudTrail and GuardDuty are powerful, but their default, single-account, single-region posture leaves exploitable gaps: trails can be stopped or narrowed, detectors can be disabled, and unmonitored regions invite pivots. The fix is structural — org trails behind SCPs, immutable logs in an isolated archive account, GuardDuty everywhere with centralized findings, and alarms on the tamper events themselves. Treat your logging pipeline as a primary target, because attackers already do. For hands-on enumeration tooling, pair this with Pacu and cloud recon.

References

You Might Also Like

If you found this useful, these related deep-dives cover adjacent techniques and their defenses:

Comments

Copied title and URL