AWS GuardDuty Finding Triage and False Positive Reduction: A Practitioner's Workflow
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
AWS GuardDuty is a powerful threat detection service that becomes overwhelming without tuning. It analyzes CloudTrail management events, VPC flow logs, DNS query logs, and (optionally) S3 data events, EKS audit logs, and Lambda logs to detect threats against your AWS environment. Out of the box, it fires on any behavior that matches its threat model, which includes a significant number of patterns that are routine in typical AWS environments: vulnerability scanner activity, CI/CD automation, NAT gateway traffic, and legitimate but unusual API usage.
Teams that enable GuardDuty without a triage plan typically experience one of two failure modes: alert fatigue (ignoring all findings because false positives overwhelm the queue) or missed detections (dismissing real threats as false positives without investigation). This guide gives you the systematic approach to avoid both: a triage workflow for the most common finding types, a suppression rule strategy for high-confidence false positives, and EventBridge automation to route confirmed threats to the right responders.
Step 1: Baseline your finding volume and identify false positive sources
Before building suppression rules, you need a clear picture of what GuardDuty is actually seeing across your accounts and regions. This means exporting current findings, grouping them by finding type, and sampling enough individual findings per type to determine whether they represent real threats or recurring false positives from your environment's known-good behavior. The baseline work identifies which finding types have the highest volume and the lowest true-positive rate, so you know where to focus suppression rule development first. It also separates the handful of finding types that have very high true-positive rates and should never be suppressed, such as CloudTrail logging disable and EC2 instance credential exfiltration, from the noisy but low-fidelity types that are almost always false positives in your specific environment.
Export finding data and group by type
Use the AWS CLI to export your current findings and group by type: aws guardduty list-findings --detector-id DETECTOR_ID --finding-criteria '{"Criterion":{"updatedAt":{"GreaterThan":1700000000}}}' --output json. Pipe to jq to count by type: jq '.FindingIds' | xargs -I{} aws guardduty get-findings --detector-id DETECTOR_ID --finding-ids {} | jq '.Findings[].Type' | sort | uniq -c | sort -rn. Alternatively, use GuardDuty's built-in filtering and sorting in the console. Identify the 5-10 finding types with the highest volume. These are your suppression rule candidates.
Classify high-volume findings as false positives or worth investigating
For each high-volume finding type, sample 10-20 findings and determine the source: Is the source IP a known scanner (check Shodan's IP list, GreyNoise), internal vulnerability assessment tool, or NAT gateway? Is the IAM principal a CI/CD service account or automation role with a documented purpose? Is the EC2 instance running a workload that legitimately produces this behavior (blockchain node, security tool, network scanner)? For each finding type where the answer is consistently 'yes, this is legitimate behavior,' build a suppression rule. For findings where even a fraction are suspicious, do not suppress the type globally, build narrowly-scoped rules targeting the specific legitimate source.
Identify the highest-fidelity finding types
Some GuardDuty finding types have very high true-positive rates and should never be suppressed globally. Treat these as mandatory investigations: DefenseEvasion:IAMUser/CloudTrailLoggingDisabled (CloudTrail disabling is almost always an attack step), Persistence:IAMUser/UserPermissions (IAM privilege escalation is high-fidelity), UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration (EC2 instance credentials used from non-EC2 IPs strongly indicates credential theft), and Impact:S3/AnomalousBehavior (unusual S3 data access patterns with AI-detected anomaly). These types should route to immediate incident response, not a triage queue.
Step 2: Build suppression rules for known-good behavior
Suppression rules archive matching findings automatically, which keeps your active findings queue focused on genuine threats while preserving all findings in the archive for audit and compliance purposes. The key discipline is building suppression rules narrowly: target the specific IP, IAM principal, or instance that generates false positives rather than suppressing an entire finding type globally. A broad suppression on a finding type like Recon:EC2/PortProbeUnprotectedPort would hide real reconnaissance activity from an attacker who happens to use the same finding type as your vulnerability scanner. Each rule should target the smallest set of criteria that eliminates the specific false positive source, while leaving the detection active for all other sources. Test each rule after deployment by verifying that new false-positive findings are archived immediately and that unrelated findings of the same type continue appearing in the active queue.
Suppression rule for vulnerability scanner activity
If you run Nessus, Qualys, Rapid7, or an internal scanner, GuardDuty will generate Recon:EC2/PortProbe findings for every scan. Scope the suppression rule to the scanner's IP address(es) or your scanner's EC2 instance ID, not to the entire finding type. Example criteria: type equals Recon:EC2/PortProbeUnprotectedPort AND remoteIpDetails.ipAddressV4 equals [scanner IP]. For an EC2-based scanner: type equals Recon:EC2/PortProbeUnprotectedPort AND service.action.networkConnectionAction.remoteIpDetails.ipAddressV4 is your scanner's EIP. Test the rule by verifying new scan findings are archived and non-scanner port probe findings still appear in the active list.
Suppression rule for CI/CD automation roles
CI/CD pipelines often trigger CredentialAccess or UnauthorizedAccess findings because they make API calls from IPs that GuardDuty does not recognize as internal (GitHub Actions IP ranges, GitLab runner IPs, Bitbucket IPs). Build a suppression rule for the specific IAM role your CI/CD uses: type contains 'IAMUser' AND resource.accessKeyDetails.userName equals 'ci-cd-deploy-role'. This suppresses findings for the specific role without suppressing the finding type for all IAM principals. Verify that the CI/CD role's permissions follow least-privilege so a compromised token has limited blast radius even if its findings are suppressed.
Suppression rule for Trusted Advisor and AWS-internal service activity
AWS services like Trusted Advisor, AWS Config, Security Hub, and Cost Explorer make API calls that can trigger Behavior or Discovery findings. Suppress findings where the principal is an AWS service: resource.accessKeyDetails.userType equals AWSService. Alternatively, suppress by the specific AWS service principal names documented in the AWS GuardDuty console for these false positive types. Do not use this suppression for IAM user or assumed-role principals, only for AWS service principals.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Step 3: Automate threat routing with EventBridge
Once suppression rules reduce false positive volume, the remaining active findings need to reach the right responders at the right speed without manual triage bottlenecks. EventBridge is the primary mechanism for routing GuardDuty findings to downstream systems such as PagerDuty, Slack, Jira, or Security Hub, and it supports filtering rules that can route findings based on severity, finding type, and resource tags. The tiered routing model ensures that the handful of highest-fidelity findings that indicate active compromise generate immediate pages, while lower-severity informational findings create tickets for next-business-hour review without waking anyone up at 2 AM. Adding a Lambda enrichment step before routing adds business context (team ownership, application name, environment) that dramatically reduces the time responders spend asking who owns the affected resource before they can begin investigation.
Create tiered EventBridge rules by severity and finding type
Tier 1 (page on-call immediately): severity >= 7.0 AND type matches 'DefenseEvasion:IAMUser/CloudTrailLoggingDisabled', 'UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration', 'Impact:S3/AnomalousBehavior'. Route to PagerDuty or OpsGenie with P1 priority. Tier 2 (create ticket for next-business-hour review): severity >= 4.0 AND type matches 'Recon:IAMUser/NetworkPermissions', 'Persistence:IAMUser/UserPermissions', 'CredentialAccess:IAMUser/Anomalousbehavior'. Route to Jira/ServiceNow via Lambda. Tier 3 (log for weekly review): severity < 4.0, archive automatically in Security Hub with a note for periodic review. This tiering ensures high-fidelity findings get immediate attention while low-confidence findings do not interrupt the team.
Enrich findings with context before routing
Raw GuardDuty finding payloads lack business context: they identify an IAM principal but not which team owns it, or an EC2 instance but not which application runs on it. Add a Lambda enrichment step between GuardDuty EventBridge events and your routing target. The Lambda function: looks up the IAM principal in your identity management system to determine team and owner, checks EC2 instance tags for application and environment (production vs. test), queries your CMDB or CloudMap for service ownership, and adds these fields to the finding before forwarding. This eliminates the 'who owns this resource' back-and-forth that delays incident response.
The bottom line
GuardDuty's value is directly proportional to the quality of your triage and suppression configuration. The workflow: export and group findings by type to identify false positive sources, build narrowly-scoped suppression rules targeting specific legitimate behaviors (not entire finding types), treat the 5-6 highest-fidelity finding types as mandatory immediate investigations, and automate finding routing with EventBridge so severity determines response speed rather than analyst availability. After initial tuning, revisit suppression rules quarterly: new finding types are added regularly, and legitimate behavior patterns in your environment change as applications evolve.
Frequently asked questions
Why is AWS GuardDuty generating so many false positives?
GuardDuty uses threat intelligence, machine learning, and behavioral baselines to detect threats, but its out-of-box configuration does not know which of your account's activities are intentional. Common false positive sources: security scanners and vulnerability assessment tools triggering Recon findings, CI/CD pipelines making unusual API calls triggering CredentialAccess findings, NAT gateways appearing as suspicious IP communicators, legitimate use of infrastructure automation triggering Stealth or DefenseEvasion findings, and crypto mining services running legitimately (like Ethereum nodes) triggering CryptoCurrency findings. Without suppression rules tuned to your environment, all of these fire as findings.
What are GuardDuty suppression rules and how do I create them?
Suppression rules are filter criteria that automatically archive findings matching specific conditions, preventing them from appearing in the active findings list while still recording them in GuardDuty's archive for audit purposes. Create suppression rules in the GuardDuty console under Findings > Suppression Rules, or via AWS CLI: aws guardduty create-filter --detector-id DETECTOR_ID --name 'KnownScanner' --action ARCHIVE --finding-criteria file://criteria.json. Criteria JSON example to suppress Recon:EC2/PortProbe findings from a specific IP: {"FindingCriteria":{"Criterion":{"type":{"Eq":["Recon:EC2/PortProbe"]},"service.action.networkConnectionAction.remoteIpDetails.ipAddressV4":{"Eq":["203.0.113.10"]}}}}. Apply suppression rules incrementally: start with high-volume, high-confidence false positive sources.
What are the most common GuardDuty finding types and how do I triage them?
The five highest-volume findings in most environments: UnauthorizedAccess:IAMUser/ConsoleLoginSuccess.B (investigate whether the login was from an expected location and device, check CloudTrail for subsequent API calls), Recon:EC2/PortProbeUnprotectedPort (determine whether the source IP is a known scanner like Shodan or your internal vulnerability scanner), CryptoCurrency:EC2/BitcoinTool.B (verify whether the instance legitimately runs blockchain workloads), Behavior:EC2/NetworkPortUnusual (check whether a new process is listening on the reported port), and DefenseEvasion:IAMUser/CloudTrailLoggingDisabled (always investigate immediately, CloudTrail disabling is a high-fidelity indicator of attacker activity).
How do I route GuardDuty high-severity findings to PagerDuty or Slack automatically?
GuardDuty publishes all new and updated findings to Amazon EventBridge in near-real time. Create an EventBridge rule that filters for GuardDuty finding events with severity >= 7.0: {"source":["aws.guardduty"],"detail-type":["GuardDuty Finding"],"detail":{"severity":[{"numeric":[">=",7]}]}}. Route matched events to an SNS topic, which can deliver to PagerDuty (via email/webhook integration), Slack (via Lambda function that calls the Slack API), or a ticketing system. For Slack, use a Lambda function as the EventBridge target that formats the finding fields (type, severity, resource, account) into a Slack message block.
Should I enable GuardDuty in all AWS regions, even ones I don't actively use?
Yes. Attackers who compromise IAM credentials frequently pivot to less-monitored regions to launch resources (EC2 instances for crypto mining, Lambda functions for C2) precisely because those regions have fewer controls. GuardDuty must be enabled in every region to detect inter-region lateral movement. Use AWS Organizations and GuardDuty delegated administrator to enable GuardDuty in all member accounts and all regions from a central management account with a single Terraform or CloudFormation deployment. Cost is proportional to event volume, which is minimal in unused regions.
How do I measure GuardDuty coverage and validate it's detecting threats?
Use the GuardDuty Tester tool (available on GitHub at awslabs/amazon-guardduty-tester) to simulate GuardDuty-detectable behaviors in a test environment: DNS lookups to known-malicious domains, port probes against your instances, and simulated credential compromise patterns. Verify that corresponding findings appear within the expected detection window (typically 5-15 minutes). Also review GuardDuty's coverage statistics: check the Coverage section in the GuardDuty console to identify accounts or regions with disabled detectors, and ensure all EC2 instances and EKS clusters are within GuardDuty's monitoring scope.
What is the difference between GuardDuty and AWS Security Hub?
GuardDuty is a threat detection service: it analyzes CloudTrail logs, VPC flow logs, and DNS logs to detect threats and generates findings when threats are identified. Security Hub is a findings aggregation and security posture management service: it collects findings from GuardDuty, Inspector, Macie, IAM Access Analyzer, and third-party security tools, correlates them, and provides a normalized view across your AWS accounts and regions. Enable both: GuardDuty detects threats, Security Hub aggregates and correlates findings from all AWS security services into a unified console. Security Hub also runs its own AWS Foundational Security Best Practices compliance checks independently of GuardDuty.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.