The Detection Layer That Was Quietly Off: GuardDuty Disabled on an AWS Account
✓ Human-authored analysis; AI used for formatting and proofreading. A researcher looked at an AWS account and asked a question most don't run as part of a configuration audit: is the threat-detection layer actually on? CloudTrail was logging. CloudWatch metric filters were watching for unauthorised API calls. The SNS topic was wired up. But GuardDuty was disabled. This layer correlates those logs…
An AWS account was found to have GuardDuty disabled, despite having CloudTrail logging, CloudWatch metric filters and alarms configured for unauthorized API calls. GuardDuty correlates those logs into an alert indicating a potential account compromise. This layer is critical as it checks if the recorded data looks like reconnaissance, instance compromise, or credential abuse.
The configuration showed CloudTrail with multi-region enabled, monitoring with metric filters and alarms set up, but threat detection (GuardDuty) was turned off. The misconfiguration is not a resource issue but the absence of a required resource (aws_guardduty_detector). Scan tools typically don't detect this issue as it is not a resource setting.
The system invariant states that an AWS account must have GuardDuty enabled with at least one detector. Enforcing this control costs only one boolean check per account per snapshot, while the cost of not enforcing it is significant until an attack goes unnoticed.
Written by urgent.news from Dev.to's reporting — not their text. Machine-written — may contain errors; check the original before relying on it.
