Detecting StopLogging and GuardDuty disabled in CloudTrail

TL;DR. Blinding the defenders is itself logged. StopLogging and DeleteTrail are recorded by the trail they stop; DeleteDetector shows up in CloudTrail even though GuardDuty is gone; PutEventSelectors and UpdateTrail quietly narrow what gets logged. Treat any of these from an unexpected principal as critical, restore logging at once, then fill the gap: event history is independent of trails and keeps 90 days of management events per region, so a stopped trail rarely means zero evidence.

Attackers who have spent a few minutes in an AWS account know what watches them. Once they hold admin rights, turning off CloudTrail, GuardDuty, AWS Config or VPC Flow Logs is cheap and often scripted. MITRE ATT&CK tracks this as T1562.008 Impair Defenses: Disable or Modify Cloud Logs and T1562.001 Disable or Modify Tools.

CloudTrail: stop, delete, or narrow

Things practitioners get wrong:

• StopLogging is logged. The call is recorded before logging stops, so the attacker's identity and IP are in your last delivered file.
• Narrowing is quieter than stopping. A PutEventSelectors that sets ReadWriteType to WriteOnly, or removes the S3 data-event selector, keeps the trail "on" in every dashboard while dropping exactly the events you need to prove data access.
• Bucket-side sabotage. Deleting log objects, changing the bucket policy, or adding a lifecycle rule does not touch the trail at all. Look for PutBucketPolicy, PutBucketLifecycleConfiguration and DeleteObjects on the trail bucket (the last only if data events cover it).
• Organization trails cannot be stopped from a member account; an attacker in a member account may instead target account-level trails or the services below.

GuardDuty itself raises Stealth:IAMUser/CloudTrailLoggingDisabled when a trail is disabled or deleted (finding types) — as long as GuardDuty is still running.

GuardDuty: delete, suspend, or silence

The trusted IP list and the auto-archive filter are the subtle ones: GuardDuty keeps running and the console looks healthy, but the attacker's address produces nothing, or its findings are archived before anyone reads them.

Because deleting a detector removes its findings, export GuardDuty findings as soon as an incident is suspected (export guide).

Everything else that watches

Remember the region dimension: GuardDuty, Config and Security Hub are regional. An attacker who deletes the detector in eu-west-1 and then works in ap-southeast-1, where GuardDuty was never enabled, is using two evasion techniques at once — the second one is T1535 Unused/Unsupported Cloud Regions.

Reading the gap

When logging was stopped, your job is to bound the blind spot and fill it from other sources:

1. Bound it. The StopLogging event gives the start; the next delivered file (or the StartLogging event when you re-enable it) gives the end.
2. Event history. It is not affected by trail configuration (documentation): download it for every region and the window of the gap. You will not get data events, but you get the management events.
3. Other trails. An organization trail or a second account-level trail may have kept running.
4. Service-side state. Resources that exist now but were created during the gap (users, instances, keys) can be dated with their creation time: user_creation_time in the credential report, LaunchTime on instances, CreateDate on keys.
5. Network evidence. VPC Flow Logs, if they survived, cover the gap on the network side.

Write the gap into the report explicitly. "No malicious activity found" and "no logs for 02:10–03:40" are different statements.

Response steps

1. Restart logging (StartLogging) or recreate the trail with its previous settings; re-enable GuardDuty, Config and the security services in every region they were running.
2. Remove attacker-added trusted IP lists and archive filters; restore publishing destinations.
3. Alarm on these events — AWS describes CloudWatch alarms on CloudTrail events.
4. With AWS Organizations, deny these actions to everyone but a break-glass role with a service control policy.

In the analyzer

AWS Forensics rates CloudTrail stopped or deleted as critical — alone enough for a "Compromised" verdict — and flags trail configuration changes, GuardDuty weakened (including IP sets and archive filters), Config stopped, security services disabled, S3 logging off, Flow Logs deleted and log groups deleted. See the CloudTrail events reference for the full list, and the limits of log-only investigation for what no tool can recover once logs are gone.