Start with the finding type
Every Amazon GuardDuty finding has a type, and the type is built to be read. AWS documents the format as:
ThreatPurpose:ResourceTypeAffected/ThreatFamilyName.DetectionMechanism!ArtifactEach part answers a question:
- ThreatPurpose: what the activity is trying to do, or the stage of an attack. Values include
Backdoor,Behavior,CredentialAccess,CryptoCurrency,DefenseEvasion,Discovery,Execution,Exfiltration,Impact,InitialAccess,PenTest,Persistence,Policy,PrivilegeEscalation,Recon,Stealth,TrojanandUnauthorizedAccess. Many of these line up with MITRE ATT&CK tactics. - ResourceTypeAffected: what is potentially targeted, such as
EC2,IAMUser,S3,Kubernetes,Runtime,RDSorLambda. - ThreatFamilyName: the specific behavior, such as
PortProbeUnprotectedPortorBitcoinTool. - DetectionMechanism (optional): how it was detected.
.Tcpand.Udpare protocol variants,.Custommeans it matched one of your own threat lists, and.Reputationmeans a domain reputation model. - Artifact (optional): the kind of resource the malicious tool uses.
!DNSmeans the activity was seen in DNS queries.
Some real types and how to read them:
Recon:EC2/PortProbeUnprotectedPort: someone is probing an EC2 instance on a port that is open to them. Reconnaissance, not compromise.CryptoCurrency:EC2/BitcoinTool.B!DNS: an EC2 instance is querying a domain associated with cryptocurrency activity. If you do not mine, treat the instance as compromised.Backdoor:EC2/C&CActivity.B: an instance is talking to a known command and control server.UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS: credentials that belong to an EC2 instance role are being used from an IP address outside AWS. This is one of the most important findings to act on quickly.Policy:IAMUser/RootCredentialUsage: the root user was used. Low severity, but always worth confirming who did it and why.Exfiltration:S3/AnomalousBehavior: an IAM entity is reading S3 data in a pattern that differs from its baseline (requires S3 Protection).AttackSequence:IAM/CompromisedCredentials: an Extended Threat Detection finding that ties several signals into one multi-stage attack.
Understand the four severity levels
GuardDuty scores each finding from 1.0 to 10.0 and groups the score into four levels:
| Level | Score | What it means |
|---|---|---|
| Critical | 9.0 to 10.0 | An attack sequence may be in progress or recently happened |
| High | 7.0 to 8.9 | A resource is compromised and being actively misused |
| Medium | 4.0 to 6.9 | Activity that deviates from normal and may indicate compromise |
| Low | 1.0 to 3.9 | Suspicious activity that was attempted but did not compromise anything |
AWS recommends triaging Critical and High findings immediately and investigating Medium findings at your earliest convenience. Low findings, such as a port scan or a failed intrusion attempt, need no immediate action, but they are not noise. They show someone looking for weak points, and they are inputs to Extended Threat Detection.
The same finding type can have different severities depending on context. In the finding types table, these are marked as variable. UnauthorizedAccess:EC2/SSHBruteForce, for example, is Low when your instance is the target, and High when your instance is the one doing the brute forcing.
Read these fields first
When you open a finding, check these in order:
- Account and Region. Is this production, a sandbox, or an account you did not know about?
- Resource. The instance ID, IAM principal, bucket, cluster or database involved, with its tags. Tags usually tell you the owner and how critical it is.
- Action. What happened: an API call, a network connection, a DNS request or a port probe, with the API name, port and protocol.
- Actor or remote details. The remote IP address, its geolocation and organization, and whether it matched a threat list.
- Count and first and last seen. GuardDuty aggregates repeat occurrences into one finding, so a high count over weeks is a different story from a burst in the last hour.
For findings that need deeper context, open the finding in Amazon Detective (if enabled) to see related activity across accounts and time.
Cut noise with suppression rules
Some findings are expected in your environment: a vulnerability scanner causes Recon:EC2/Portscan, a bastion host attracts UnauthorizedAccess:EC2/SSHBruteForce, and traffic routed through an on-premises gateway can trigger the InstanceCredentialExfiltration.OutsideAWS finding.
Suppression rules handle these. A rule is a saved filter: a finding type plus one or more attributes, such as an instance tag, AMI ID or API caller IP address. Matching findings are still generated, but they are archived automatically and are not sent to AWS Security Hub CSPM, Amazon S3 exports, Amazon Detective or Amazon EventBridge. You can still view them under archived findings for 90 days.
A few rules of thumb from the AWS guidance:
- Create suppression rules reactively, for findings you have confirmed as false positives more than once.
- Keep them narrow. Suppressing a whole finding type or resource class also hides those signals from Extended Threat Detection, which can stop it from spotting a multi-stage attack.
- In a multi-account setup, only the GuardDuty administrator account can create suppression rules, which keeps tuning in one place.
For addresses and domains you trust, such as your own egress IPs, a trusted list is often cleaner than a suppression rule: GuardDuty does not generate findings for them at all. The reverse also works. Add indicators from your own threat intelligence to a threat list, and matches appear as findings with the .Custom mechanism. AWS now recommends entity lists, which can hold IP addresses, domains and (for threat lists) file hashes, over the older IP address lists.
A practical triage routine
- Route by severity. Send Critical and High findings to on-call through EventBridge, and review Medium and Low findings daily or weekly.
- Look for clusters. Several findings on the same resource or principal in a short window matter more than any single one. Attack sequence findings do this correlation for you.
- Confirm with the owner. Many Medium findings turn out to be a new deployment or a changed security group. Check with the resource owner before you escalate, and if you cannot confirm the activity was authorized, treat the resource as compromised.
- Follow the remediation guide. AWS publishes remediation steps by resource type: rotate exposed credentials, isolate the instance, review bucket policies.
- Practice. Generate sample findings (marked
[SAMPLE]) to test your rules and runbooks before you need them.
Getting help
9Acts is an AWS Advanced Tier Services Partner with the AWS Level 1 MSSP Competency. If your team is drowning in findings or wants a second opinion on triage, see our security and compliance services.