GuardDuty Evasion Hunt: 9 Techniques Adversaries Use to Stay Silent on AWS

GuardDuty is the safety net most cloud SOCs assume will catch the obvious attacks. Sophisticated adversaries treat it as a known opponent — one whose detection logic is public and whose blind spots are enumerable. This article reverse-engineers nine evasion techniques and ships the meta-hunt that detects the silence itself.

The reasoning many AWS environments rely on is: GuardDuty is enabled, GuardDuty will fire on anything interesting, no GuardDuty findings means no incidents. This reasoning is structurally false. GuardDuty’s detection logic is well-documented, its sensitivity is bounded by false-positive budgets, and its coverage has known gaps that adversaries exploit deliberately.

Part 3 of the AWS Threat Hunting series catalogues nine specific evasion techniques in active use, the operational reason adversaries prefer each one, and the hunt patterns that surface activity GuardDuty did not catch. The meta-pattern across all nine: silence on a GuardDuty rule is itself a signal when correlated with other telemetry.

01 · Why this hunt matters

Two structural forces make GuardDuty evasion increasingly attractive to adversaries. First, the public documentation of GuardDuty’s detection logic means every operator who reads the docs can engineer their tradecraft to avoid known triggers. Second, the production-grade false-positive constraints that GuardDuty operates under necessarily leave detection gaps — a rule that fires on 0.01% of normal activity simply cannot also catch every variant of the targeted behaviour.

The hunt-team implication is direct: you cannot rely on GuardDuty findings as the sole indicator of cloud intrusion. The compensating hunt patterns below detect the behaviours that GuardDuty was designed to catch but did not.

02 · Adversary tradecraft

The 9 evasion techniques

1. Slow-rate credential brute force. GuardDuty’s brute-force detector requires rate above a threshold. Spread attempts over hours instead of seconds.
2. Private subnet pivoting. Many GuardDuty rules look at internet-bound traffic. Pure inside-VPC lateral movement evades them.
3. VPC endpoint use. Routing API calls through interface endpoints can change the source attribution that GuardDuty observes.
4. Service-linked role abuse. Activity by service-linked roles is sometimes filtered. Adversaries hijack those roles when possible.
5. Region selection. GuardDuty must be enabled per region. Operating in an unmonitored region produces no findings.
6. Runtime-monitoring evasion. GuardDuty Runtime Monitoring is opt-in; many environments have it off. Container payloads execute invisibly.
7. Subtle privilege escalation. Adding a single permissive statement to an existing policy is below the detection threshold; replacing an entire policy is above it.
8. Log alteration evasion. GuardDuty depends on CloudTrail. Tampering with trail event selectors disables the input feed silently.
9. Legitimate-tooling reuse. GuardDuty’s malware-detection logic depends on signatures. Adversaries who use legitimate cloud-management tooling for malicious purposes generate no signatures.

03 · Telemetry needed

The detection-via-silence approach requires composite telemetry. The minimum stack:

• CloudTrail across all regions. The base layer that GuardDuty itself depends on.
• VPC Flow Logs. Closes the private-subnet pivoting evasion.
• DNS query logs from Route 53 Resolver. Closes the DNS-based evasion.
• EC2 instance-level endpoint telemetry. Closes the runtime-monitoring evasion.
• Per-region GuardDuty finding stream. Lets you detect regions where findings have unexpectedly dropped to zero.

04 · Hunt queries

Hunt query 01 — Slow-rate credential brute force

SELECT userIdentity.userName AS user, COUNT(*) AS attempts,
       MIN(eventTime) AS first_attempt, MAX(eventTime) AS last_attempt
FROM cloudtrail_logs
WHERE eventName = 'ConsoleLogin' AND errorMessage = 'Failed authentication'
  AND eventTime BETWEEN '2026-06-08' AND '2026-06-14'
GROUP BY userIdentity.userName
HAVING COUNT(*) BETWEEN 5 AND 30
   AND (CAST(MAX(eventTime) AS TIMESTAMP) - CAST(MIN(eventTime) AS TIMESTAMP)) > INTERVAL '6 hours';

Hunt query 02 — Regions with zero GuardDuty findings

WITH ct_active AS (
  SELECT awsRegion, COUNT(*) AS events
  FROM cloudtrail_logs
  WHERE eventTime BETWEEN '2026-06-08' AND '2026-06-14'
  GROUP BY awsRegion
  HAVING COUNT(*) > 1000
),
gd_findings AS (
  SELECT region, COUNT(*) AS findings
  FROM guardduty_findings
  WHERE created BETWEEN '2026-06-08' AND '2026-06-14'
  GROUP BY region
)
SELECT c.awsRegion, c.events, COALESCE(g.findings, 0) AS findings
FROM ct_active c
LEFT JOIN gd_findings g ON c.awsRegion = g.region
WHERE COALESCE(g.findings, 0) = 0
ORDER BY c.events DESC;

Hunt query 03 — Single-statement policy additions

SELECT eventTime, userIdentity.arn AS principal, sourceIPAddress,
       requestParameters.policyName AS policy,
       requestParameters.policyDocument AS new_document
FROM cloudtrail_logs
WHERE eventName IN ('PutUserPolicy', 'PutRolePolicy', 'AttachUserPolicy',
                    'AttachRolePolicy', 'PutGroupPolicy')
  AND eventTime BETWEEN '2026-06-08' AND '2026-06-14'
  AND LENGTH(requestParameters.policyDocument) < 500;

05 · Sigma rule

title: AWS Region Active in CloudTrail with Zero GuardDuty Findings
id: 7c4d5e66-8f9a-4b12-9c0d-1e2f3a4b5c6d
status: experimental
description: |
  Detects AWS regions producing significant CloudTrail event volume
  with zero GuardDuty findings in the same window — suggests either
  GuardDuty is disabled in the region or evasion-grade tradecraft.
author: HackForLab
date: 2026/06/16
references:
  - https://hackforlab.com/aws-guardduty-evasion-hunt-2026/
tags:
  - attack.defense_evasion
  - attack.t1562.008
logsource:
  product: aws
  service: cross-source
detection:
  selection:
    cloudtrail_events_in_region|gt: 1000
    guardduty_findings_in_region: 0
  timeframe: 7d
  condition: selection
fields:
  - region
  - cloudtrail_events_in_region
  - guardduty_findings_in_region
falsepositives:
  - GuardDuty intentionally disabled in dev/test regions
level: high

06 · Ship as a production detection

The production deployment of these rules is the meta-detection of evasion. Engineer the GuardDuty-finding-stream join carefully — the GuardDuty findings API has rate limits and pagination considerations. Land findings in your SIEM through the EventBridge event bus rather than polling. Map detections to T1562.008 (Impair Defenses: Disable or Modify Cloud Logs). — or pull pre-mapped clusters from HuntIntel

07 · False-positive considerations

Dev / test regions with intentionally disabled GuardDuty are the dominant FP source. Maintain an allowlist of regions where the absence of findings is expected. Operations roles with low-volume legitimate brute-force test traffic are a secondary source — coordinate detection tuning with the red team.

08 · Response actions

Response: confirm GuardDuty status in the surfaced region; if disabled, escalate to cloud security. If enabled but quiet, audit the principal whose activity is dominant in the region’s CloudTrail events. Investigate single-statement policy additions for privilege expansion. Validate that the corresponding identity has not used the new permissions for sensitive operations. — Sign in to huntintel.hackforlab.com to pull the live catalogue and pivot on the cluster directly.

09 · FAQ