AWS GuardDuty Findings: Severity Levels, Finding Types, and Response Playbooks

GuardDuty finding names follow a consistent taxonomy: ThreatPurpose:ResourceType/ThreatFamilyName.DetectionMechanism!Artifact. A finding named UnauthorizedAccess:IAMUser/ConsoleLoginSuccess.B tells you the threat purpose (UnauthorizedAccess), the affected resource type (IAMUser), the threat family (ConsoleLoginSuccess), and a variant indicator (B). This naming convention is not incidental — understanding it lets you assess the severity and likely response before reading the finding details.

This guide covers the most important GuardDuty finding categories, what each indicates in practice, and the specific response actions that contain and remediate the threat. Not all findings require the same urgency. Understanding the difference between a finding that warrants immediate containment and one that warrants investigation-at-next-business-day is the operational skill that makes threat detection useful rather than noisy.

Severity Levels

GuardDuty assigns severity on a numeric scale: LOW (1.0–3.9), MEDIUM (4.0–6.9), HIGH (7.0–8.9), and CRITICAL (9.0–10.0). These map to specific operational expectations. CRITICAL findings indicate active, confirmed threats requiring immediate response. HIGH findings indicate strong indicators of compromise requiring same-day investigation. MEDIUM findings warrant investigation within 24–48 hours. LOW findings are weak indicators that provide useful context for investigations but rarely require standalone action.

The numeric score within each band provides additional granularity. A finding with severity 8.9 vs. 7.1 both fall in HIGH, but the 8.9 reflects stronger confidence or higher potential impact. Sort your active findings by severity score rather than severity label when prioritizing.

Credential Threat Findings

Credential-based findings are the highest-consequence GuardDuty finding category. They indicate that legitimate AWS credentials are being used in ways that suggest compromise.

UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS fires when credentials that originated from an EC2 instance metadata service (IMDS) are used from an IP address outside AWS. Since EC2 instance credentials should only be used by code running on that instance, usage from an external IP means the credentials have been exfiltrated — either via an SSRF vulnerability, a misconfigured application, or direct server compromise. This finding requires immediate response: revoke the instance's current credentials by stopping and restarting the instance (which rotates the temporary credentials), investigate the IMDS exposure vector, and review CloudTrail for actions taken with the exfiltrated credentials.

UnauthorizedAccess:IAMUser/ConsoleLoginSuccess.B indicates a successful console login from an IP address that GuardDuty's threat intelligence identifies as unusual or suspicious. Correlate with your user's known IP ranges. If the login is not from a recognized location for that user, initiate immediate credential rotation and review what actions were taken in the session.

PrivilegeEscalation:IAMUser/AdministrativePermissions indicates that an identity has added permissions to itself — a classic privilege escalation pattern. Any IAM principal that modifies its own permissions (or grants itself access to a role with elevated permissions) should be treated as a high-confidence indicator of either compromise or insider threat.

Cryptocurrency Mining Findings

CryptoCurrency:EC2/BitcoinTool.B and related findings fire when EC2 instances communicate with cryptocurrency mining pools or mining-related domains. These findings have extremely high confidence. Legitimate production workloads do not mine cryptocurrency. When this finding appears, the affected instance is either compromised or was intentionally provisioned for mining — both of which require immediate termination of the instance and credential revocation for the identity that launched it.

The response sequence for crypto mining findings: (1) immediately revoke the IAM credentials that launched the instance; (2) terminate the mining instance; (3) check CloudTrail for all API calls made by the compromised identity in the past 24–72 hours; (4) inventory any other resources created by the same identity; (5) review how the credentials were obtained (leaked access key, compromised role, compromised console access).

Network Threat Findings

Recon:EC2/PortProbeUnprotectedPort fires when a known malicious IP probes unprotected ports on your EC2 instances. This is a medium-severity finding indicating reconnaissance, not active compromise. The appropriate response is to verify the security group rules on the affected instance and ensure that only required ports are open. Do not panic over this finding — every internet-accessible instance receives port probes continuously.

UnauthorizedAccess:EC2/SSHBruteForce indicates brute-force SSH login attempts against your instances. If your instances require SSH access, ensure key-based authentication only and verify that password authentication is disabled. If SSH is not required, remove the inbound security group rule. High-severity variants of this finding indicate successful authentication from unusual IPs, which warrant immediate investigation.

Backdoor:EC2/C&CActivity.B fires when an instance communicates with known command-and-control infrastructure. This is a HIGH or CRITICAL finding indicating active malware or backdoor presence. Isolate the instance immediately by modifying its security group to deny all outbound traffic, capture an EBS snapshot for forensic analysis, then terminate the instance.

S3 Threat Findings

GuardDuty S3 Protection findings detect anomalous access patterns to S3 buckets. Discovery:S3/MaliciousIPCaller fires when S3 API calls (ListBuckets, GetObject, PutObject) originate from a known malicious IP. Exfiltration:S3/ObjectRead.Unusual fires when a previously unseen identity reads an unusually large number of objects — a pattern consistent with data theft.

S3 exfiltration findings warrant immediate response: identify what was accessed using CloudTrail data events, determine whether the accessing identity is legitimate, and if the identity is compromised, revoke its credentials and assess the data exposure scope for any required breach notifications.

Building Response Automation

Manual response to GuardDuty findings is too slow for high-severity threats. Build EventBridge rules that trigger automated responses for the highest-priority finding types. For CryptoCurrency findings, automation can immediately detach the instance's IAM role, preventing further credential use while investigation proceeds. For UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration, automation can deactivate the affected instance's IAM role.

Implement automated response conservatively. Automated containment actions (stopping instances, revoking credentials) can disrupt legitimate operations if triggered on false positives. Start with automated notification to on-call for HIGH and CRITICAL findings, add automated containment for finding types with near-zero false positive rates (CryptoCurrency findings have very high confidence), and expand automation as you develop confidence in your environment's baseline.

Related Reading

• GuardDuty setup guide — configuring GuardDuty across your organization
• AWS incident response plan — building runbooks for cloud security events
• IAM security monitoring — detect root logins, MFA gaps, and policy drift
• Account compromise response — step-by-step recovery procedures

FAQ

How do I reduce GuardDuty false positives without missing real threats?

Use suppression rules to filter known-good patterns rather than adjusting finding thresholds. Write suppression rules that are specific to the resource and finding type — suppress a port probe finding from a specific security scanner IP against a specific instance, not all port probe findings. Review suppression rules quarterly to ensure they remain valid as your environment changes.

What GuardDuty findings should I respond to immediately?

Any finding with CRITICAL severity requires immediate response. Among HIGH findings, credential exfiltration (InstanceCredentialExfiltration), C&C activity (C&CActivity), crypto mining (CryptoCurrency), and unauthorized console logins warrant same-day response. MEDIUM findings should be investigated within 24–48 hours but rarely indicate active compromise requiring immediate containment.

Can GuardDuty findings be wrong?

Yes. GuardDuty uses behavioral anomaly detection, which produces false positives in environments with unusual but legitimate operational patterns. New deployments, security scanning tools, and unusual IAM usage patterns can trigger findings that are not actual threats. This is why context matters — correlate GuardDuty findings with your change management records and operational context before taking containment actions.

How long are GuardDuty findings retained?

GuardDuty retains findings for 90 days from the last update. After 90 days, findings are automatically deleted from the service. Configure finding export to S3 for longer retention — regulatory requirements like PCI DSS require 12 months of security event history, which GuardDuty's native retention does not satisfy.

What is the difference between GuardDuty finding types ending in .B vs. no suffix?

The letter suffix (A, B, C, etc.) indicates a variant within the same finding family. Different variants use different detection mechanisms or data sources to detect the same threat type. A finding ending in .B is not inherently more or less severe than one without a suffix — evaluate severity based on the numeric score, not the variant indicator.