GuardDuty silently disabled on AWS account despite CloudTrail logging, HackerOne report shows

What happened

A researcher auditing an AWS account found that its security telemetry looked healthy while its actual detection capability was zero. According to a post on dev.to, CloudTrail was recording API activity across all regions, a CloudWatch metric filter was watching for unauthorised API calls, and an alarm was wired to an SNS topic for security alerts. The one layer missing was Amazon GuardDuty, AWS's managed threat detection service — it was disabled, and nothing in the account's tooling signalled that fact.

The case was filed as HackerOne report #3022516. What makes it instructive is not exotic exploitation but the shape of the gap: every existing resource was configured correctly, and the failure was a service that had never been switched on. Restoring it takes a single CLI call.

Three layers, three jobs

The dev.to post walks through why these components complement rather than duplicate each other:

• CloudTrail captures every API call but performs no analysis. On its own it is a complete record, not a warning system.
• CloudWatch metric filters catch exactly the patterns their authors wrote. An attack technique that exercises different API calls simply does not match.
• GuardDuty is the behavioural layer. It correlates CloudTrail management events, VPC Flow Logs and DNS query logs against threat intelligence and statistical baselines to flag signals such as reconnaissance, instance compromise or credential abuse.

With GuardDuty off, the post argues, the other two layers keep working while nobody watches. The audit trail becomes mainly useful for a post-incident review long after the fact, rather than for catching an intrusion while it is happening.

Why scanners miss it

The central lesson of the write-up concerns how configuration scanners operate. Typical checklist and CSPM tools iterate over the resources an account already has — S3 buckets, IAM roles, security groups, trails — and evaluate their settings. A disabled GuardDuty is not a misconfigured resource; it is the complete absence of a detector resource. There is nothing to iterate over, so the scan completes cleanly and the dashboard stays green.

The author frames this as the same failure pattern as missing logging or missing backups: a scanner that only inspects what exists cannot tell you what should exist but does not. Some CSPM tools eventually added detector-presence rules, but the post notes these are special-case logic rather than the default scanner design. The correct question is a presence check — does this account have a detector? — rather than an attribute check.

Fixing it and keeping it fixed

The remediation is one command: aws guardduty create-detector --enable. Presence can then be verified with aws guardduty list-detectors, which returns the detector ID as proof. For organisation-wide coverage, the post recommends delegating GuardDuty administration once and enabling it for every member account through the delegated administrator.

The running cost, per the post's estimate, is typically tens of dollars per account per month — effectively the price of visibility into account compromise. For prevention, it suggests a Config rule, a service control policy or an AWS Organizations policy asserting that every member account maintains at least one active detector. The author also demonstrates encoding the check as a single control in a tool called Stave, mapping it to SOC 2 CC7.1, PCI DSS 4.0 requirement 5.2, NIST 800-53 SI-3 and ISO 27001 A.8.16, and grouping it in the same "detection evasion" lane as disabled CloudTrail or missing monitoring — so that multiple blind spots firing together produce a compound finding.

Why it matters

This is a practical warning for anyone auditing cloud security posture. Detection failures are silent by definition: you learn about them at the worst possible moment, when an alert that should have arrived never does. Audits and scanners that only validate configured resources will keep reporting green on accounts that are effectively blind to behavioural threats. The cheap, immediate action is to run aws guardduty list-detectors in every account today and add detector-presence checks to audits permanently.