# Understanding and generating Amazon GuardDuty findings
A GuardDuty finding represents a potential security issue detected within AWS accounts, workloads, and data. GuardDuty generates a finding whenever it detects unexpected and potentially malicious activity in your AWS environment.
You can view and manage your GuardDuty findings on the **Findings** page in the GuardDuty console, or by using the AWS CLI or API operations. For information on how you can manage GuardDuty findings, see [Managing Amazon GuardDuty findings](findings_management.md).
**Topics:**
[GuardDuty finding format](guardduty_finding-format.md)
Understand the format of GuardDuty finding types and different threat purposes that GuardDuty tracks.
[Sample findings](sample_findings.md)
Generate sample findings in the GuardDuty console, or by using GuardDuty API or AWS CLI commands. The generated sample findings include fictitious details to help you understand the finding details associated with each GuardDuty finding. These findings are marked with a prefix **[SAMPLE]**.
[Test GuardDuty findings in dedicated accounts](guardduty_findings-scripts.md)
You can test specific GuardDuty findings in your environment. Run `guardduty-tester` script in a dedicated non-production AWS account. For GuardDuty to detect and simulate findings, it will deploy certain resources in your environment. This experience is different than generating sample findings.
[Viewing generated findings in GuardDuty console](guardduty_working-with-findings.md)
Learn how to review the generated findings in the GuardDuty console.
[Severity levels of GuardDuty findings](guardduty_findings-severity.md)
Each GuardDuty finding has an associated severity level that reflects the potential risk in your AWS environment. This section explains what each severity level signify.
[Finding details](guardduty_findings-summary.md)
Learn about the details associated with GuardDuty findings that get generated in your account. This topic includes the details associated with foundational threat detection, Extended Threat Detection, and dedicated protection plans in GuardDuty.
[GuardDuty finding aggregation](finding-aggregation.md)
Learn how GuardDuty handles multiple occurrences of the same finding type. By aggregating detected same finding types, GuardDuty updates the original finding type with the latest details.
[GuardDuty finding types](guardduty_finding-types-active.md)
This section enlists GuardDuty finding types by the associated [Foundational data sources](guardduty_data-sources.md) or [Mapped GuardDuty feature](guardduty-feature-object-api-changes-march2023.md#guardduty-feature-enablement-datasource-relation). To learn about each finding type, select that finding for further details, such as its description and potential steps to remediate the finding.
# GuardDuty finding format
When GuardDuty detects suspicious or unexpected behavior in your AWS environment, it generates a finding. A finding is a notification that contains the details about a potential security issue that GuardDuty discovers. The [Viewing generated findings in GuardDuty console](guardduty_working-with-findings.md) include information about what happened, which AWS resources were involved in the suspicious activity, when this activity took place, and related information that may help you understand the root cause.
One of the most useful pieces of information in the finding details is a **finding type**. The purpose of the finding type is to provide a concise yet readable description of the potential security issue. For example, the GuardDuty *Recon:EC2/PortProbeUnprotectedPort* finding type quickly informs you that somewhere in your AWS environment, an EC2 instance has an unprotected port that a potential attacker is probing.
GuardDuty uses the following format for naming the various types of findings that it generates:
**ThreatPurpose:ResourceTypeAffected/ThreatFamilyName.DetectionMechanism\$1Artifact**
Each part of this format represents an aspect of a finding type. These aspects have the following explanations:
+ **ThreatPurpose** - describes the primary purpose of a threat, an attack type or a stage of a potential attack. See the following section for a complete list of GuardDuty threat purposes.
+ **ResourceTypeAffected** - describes which AWS resource type is identified in this finding as the potential target of an adversary. Currently, GuardDuty can generate findings for the resource types that are listed in the [GuardDuty active finding types](guardduty_finding-types-active.md#findings-table).
+ **ThreatFamilyName** - describes the overall threat or potential malicious activity that GuardDuty is detecting. For example, a value of **NetworkPortUnusual** indicates that an EC2 instance identified in the GuardDuty finding has no prior history of communications on a particular remote port that also is identified in the finding.
+ **DetectionMechanism** - describes the method in which GuardDuty detected the finding. This can be used to indicate a variation on a common finding type or a finding that GuardDuty used a specific mechanism to detect. For example, **Backdoor:EC2/DenialOfService.Tcp** indicates denial of service (DoS) was detected over TCP. The UDP variant is **Backdoor:EC2/DenialOfService.Udp**.
A value of **.Custom** indicates that GuardDuty detected the finding based on your custom threat lists. For more information, see [Entity lists and IP address lists](guardduty_upload-lists.md).
A value of **.Reputation** indicates that GuardDuty detected the finding using a domain reputation score model. For more information, see [How AWS tracks the cloud's biggest security threats and helps shut them down](https://aws.amazon.com/blogs/security/how-aws-tracks-the-clouds-biggest-security-threats-and-helps-shut-them-down/).
+ **Artifact** - describes a specific resource that is owned by a tool that is used in the malicious activity. For example, **DNS** in the finding type [CryptoCurrency:EC2/BitcoinTool.B\$1DNS](guardduty_finding-types-ec2.md#cryptocurrency-ec2-bitcointoolbdns) indicates that an Amazon EC2 instance is communicating with a known Bitcoin-related domain.
**Note**
Artifact is optional and may not be available for all GuardDuty finding types.
## Threat Purposes
In GuardDuty a *threat purpose* describes the primary purpose of a threat, an attack type, or a stage of a potential attack. For example, some threat purposes, such as **Backdoor**, indicate a type of attack. However some threat purposes, such as **Impact** align with [MITRE ATT&CK tactics](https://attack.mitre.org/tactics/TA0010/). The MITRE ATT&CK tactics indicate different phases in an adversary's attack cycle. In the current release of GuardDuty, ThreatPurpose can have the following values:
**Backdoor**
This value indicates that an adversary has compromised an AWS resource and altered the resource so that it is capable of contacting its home command and control (C&C) server to receive further instructions for malicious activity.
**Behavior**
This value indicates that GuardDuty has detected activity or activity patterns that are different from the established baseline for the AWS resources involved.
**CredentialAccess**
This value indicates that GuardDuty has detected activity patterns that an adversary may use to steal credentials, such as passwords, usernames, and access keys, from your environment. This threat purpose is based on [MITRE ATT&CK tactics](https://attack.mitre.org/matrices/enterprise/cloud/aws/).
**Cryptocurrency**
This value indicates that GuardDuty has detected that an AWS resource in your environment is hosting software that is associated with cryptocurrencies (for example, Bitcoin).
**DefenseEvasion**
This value indicates that GuardDuty has detected activity or activity patterns that an adversary may use to avoid detection while infiltrating your environment. This threat purpose is based on [MITRE ATT&CK tactics](https://attack.mitre.org/matrices/enterprise/cloud/aws/)
**Discovery**
This value indicates that GuardDuty has detected activity or activity patterns that an adversary may use to expand their knowledge of your systems and internal networks. This threat purpose is based on [MITRE ATT&CK tactics](https://attack.mitre.org/matrices/enterprise/cloud/aws/).
**Execution**
This value indicates that GuardDuty has detected that an adversary may try to run or has already run malicious code to explore the AWS environment, or steal data. This threat purpose is based on [MITRE ATT&CK tactics ](https://attack.mitre.org/tactics/TA0002/).
**Exfiltration**
This value indicates that GuardDuty has detected activity or activity patterns that an adversary may use when attempting to steal data from your environment. This threat purpose is based on [MITRE ATT&CK tactics](https://attack.mitre.org/tactics/TA0010/).
**Impact**
This value indicates that GuardDuty has detected activity or activity patterns that suggest that an adversary is attempting to manipulate, interrupt, or destroy your systems and data. This threat purpose is based on [MITRE ATT&CK tactics](https://attack.mitre.org/matrices/enterprise/cloud/aws/).
**InitialAccess**
This value is commonly associated with the initial access stage of an attack when an adversary is attempting to establish access to your environment. This threat purpose is based on [MITRE ATT&CK tactics](https://attack.mitre.org/matrices/enterprise/cloud/aws/).
**Pentest**
Sometimes owners of AWS resources or their authorized representatives intentionally run tests against AWS applications to find vulnerabilities, such as open security groups or access keys that are overly-permissive. These pen tests are done in an attempt to identify and lock down vulnerable resources before they are discovered by adversaries. However, some of the tools used by authorized pen testers are freely available and therefore can be used by unauthorized users or adversaries to run probing tests. Although GuardDuty can't identify the true purpose behind such activity, the **Pentest** value indicates that GuardDuty is detecting such activity, that it is similar to the activity generated by known pen testing tools, and that it could indicate malicious probing of your network.
**Persistence**
This value indicates that GuardDuty has detected activity or activity patterns that an adversary may use to try and maintain access to your systems even if their initial access route is cut off. For example, this could include creating a new IAM user after gaining access through an existing user's compromised credentials. When the existing user's credentials are deleted, the adversary will retain access on the new user that was not detected as part of the original event. This threat purpose is based on [MITRE ATT&CK tactics](https://attack.mitre.org/matrices/enterprise/cloud/aws/).
**Policy**
This value indicates that your AWS account is exhibiting behavior that goes against the recommended security best practices. For example, unintended modification of permission policies associated with your AWS resources or environment, and use of privileged accounts that should have little to no usage.
**PrivilegeEscalation**
This value informs you that the involved principal within your AWS environment is exhibiting behavior that an adversary may use to gain higher-level permissions to your network. This threat purpose is based on [MITRE ATT&CK tactics](https://attack.mitre.org/matrices/enterprise/cloud/aws/).
**Recon**
This value indicates that GuardDuty has detected activity or activity patterns that an adversary may use when preforming reconnaissance of your environment to determine how they can broaden their access or utilize your resources. For example, this activity can include scoping out vulnerabilities in your AWS environment by probing ports, making API calls, listing users, and listing database tables among others.
**Stealth**
This value indicates that an adversary is actively trying to hide their actions. For example, they might use an anonymizing proxy server, making it extremely difficult to gauge the true nature of the activity.
**Trojan**
This value indicates that an attack is using Trojan programs that silently carry out malicious activity. Sometimes this software takes on an appearance of a legitimate program. Sometimes users accidentally run this software. Other times this software might run automatically by exploiting a vulnerability.
**UnauthorizedAccess**
This value indicates that GuardDuty is detecting suspicious activity or a suspicious activity pattern by an unauthorized individual.
# GuardDuty malware detection scan engine
Amazon GuardDuty has an internally built and managed scan engine and a [third-party vendor](https://www.bitdefender.com/blog/businessinsights/bitdefender-and-amazon-web-services-strengthen-cloud-security/). Both use indicators of compromise (IoCs) sourced from various internal feeds that have visibility across different kinds of malware that may target AWS. GuardDuty also has detection definitions that are based on YARA rules added by our security engineers, and detections based on heuristic and machine learning (ML) models. When scanning Amazon S3 objects, GuardDuty Malware Protection produces consistent results when scanning the same object multiple times with the same scan definitions and engines. Signature-based detection not only includes matching of bytes but also a snippet of code that is potentially complex, and the scanner can parse content and make decisions.
The malware scan engine doesn't perform live behavioral analysis, where malware detonation monitors the sample as it executes in a real system. The GuardDuty solution is primarily a file-based detection. For detecting file-less malware, GuardDuty provides an agent-based solution, such as [Runtime Monitoring](runtime-monitoring.md) for Amazon EKS, Amazon EC2, and Amazon ECS (including AWS Fargate).
With no restriction on the file formats that GuardDuty scans for malware, the scan engines that it uses can detect different types of malware, such as cryptominers, ransomware, and webshells. The fully managed GuardDuty scan engine continuously updates the list of malware signatures every 15 minutes.
The scan engine is a part of GuardDuty threat intelligence system that uses an internal malware detonation component. This generates new threat intelligence by independently collecting malware and benign samples from multiple sources. The file hash IoC type from the threat intelligence system further feeds into malware scan engine to detect malware based on known bad file hashes.
# Generating sample findings in GuardDuty
Amazon GuardDuty helps you generate sample findings to visualize and understand the various finding types that it can generate. When you generate sample findings, GuardDuty populates your current findings list with one sample for each supported finding type, including attack sequence finding types.
The generated samples are approximations populated with placeholder values. These samples may look different from real findings for your environment, but you can use them to test various configurations for GuardDuty, such as your EventBridge events or filters. For a list of available values for finding types, see [GuardDuty finding types](guardduty_finding-types-active.md) table.
## Generating sample findings through the GuardDuty console or API
Choose your preferred access method to generate sample findings.
**Note**
The GuardDuty console helps you generate one of each finding type. To generate one or more specific finding types, perform the associated API/CLI steps.
------
#### [ Console ]
Use the following procedure to generate sample findings. This process generates one sample finding for each GuardDuty finding type.
****
1. Open the GuardDuty console at [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/).
1. In the navigation pane, choose **Settings**.
1. On the **Settings** page, under **Sample findings**, choose **Generate sample findings**.
1. In the navigation pane, choose **Findings**. The sample findings are displayed on the **Current findings** page with the prefix **[SAMPLE]**.
------
#### [ API/CLI ]
You can generate a single sample finding matching any of the GuardDuty finding types through the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_CreateSampleFindings.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_CreateSampleFindings.html) API, the available values for finding types are listed in [GuardDuty finding types](guardduty_finding-types-active.md) table.
This is useful for the testing of CloudWatch Events rules or automation based on findings. The following example shows how to generate a single sample finding of the `Backdoor:EC2/DenialOfService.Tcp` type using the AWS CLI.
To find the `detectorId` for your account and current Region, see the **Settings** page in the [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) console, or run the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html) API.
```
aws guardduty create-sample-findings --detector-id 12abc34d567e8fa901bc2d34e56789f0 --finding-types Backdoor:EC2/DenialOfService.Tcp
```
------
The title of sample findings generated through these methods always begins with **[SAMPLE]** in the console. Sample findings have a value of `"sample": true` in the **additionalInfo** section of the finding JSON details.
To understand the finding details, such as finding severity and potentially compromised resource, associated with the generated findings, see [Severity levels of GuardDuty findings](guardduty_findings-severity.md) and [Finding details](guardduty_findings-summary.md).
To generate some common findings based on a simulated activity in a dedicated and isolated AWS account within your environment, see [Test GuardDuty findings in dedicated accounts](guardduty_findings-scripts.md).
# Test GuardDuty findings in dedicated accounts
Use this document to run a tester script that generates GuardDuty findings against test resources that will be deployed in your AWS account. You can perform these steps when you want to understand and learn about certain GuardDuty finding types and how the finding details look for actual resources in your account. This experience is different from generating [Sample findings](sample_findings.md). For more information about the experience of testing GuardDuty findings, see [Considerations](#considerations-generate-gdu-findings-tester).
**Topics**
+ [
## Considerations
](#considerations-generate-gdu-findings-tester)
+ [
## GuardDuty findings tester script can generate
](#gdu-findings-tester-generates)
+ [
## Step 1 - Prerequisites
](#prerequisites-gdu-tester-script)
+ [
## Step 2 - Deploy AWS resources
](#deploy-gdu-tester-script)
+ [
## Step 3 - Run tester scripts
](#run-gdu-tester-script)
+ [
## Step 4 - Clean up AWS test resources
](#clean-gdu-tester-script-resources)
+ [
## Troubleshooting common issues
](#troubleshooting-gdu-tester-script-issues)
## Considerations
Before you proceed, take the following considerations into account:
+ GuardDuty recommends deploying the tester in a dedicated non-production AWS account. This approach will ensure that you are able to properly identify GuardDuty findings generated by the tester. Additionally, the GuardDuty tester deploys a variety of resources which may require IAM permissions beyond what is allowed in other accounts. Using a dedicated account ensures that permissions can be properly scoped with a clear account boundary.
+ The tester script generates over 100 GuardDuty findings with different AWS resource combinations. Presently, this does't include all the [GuardDuty finding types](guardduty_finding-types-active.md). For a list of finding types that you can generate with this tester script, see [GuardDuty findings tester script can generate](#gdu-findings-tester-generates).
**Note**
To visualize *Attack sequence finding types*, the tester script generates only [AttackSequence:EKS/CompromisedCluster](guardduty-attack-sequence-finding-types.md#attack-sequence-eks-compromised-cluster) and [AttackSequence:S3/CompromisedData](guardduty-attack-sequence-finding-types.md#attack-sequence-s3-compromised-data). To visualize and understand [AttackSequence:IAM/CompromisedCredentials](guardduty-attack-sequence-finding-types.md#attack-sequence-iam-compromised-credentials), you can generate [Sample findings](sample_findings.md) in your account.
+ For the GuardDuty tester to work as expected, GuardDuty needs to be enabled in the account where the tester resources are deployed. Depending on the tests that will run, the tester evaluates whether or not the appropriate GuardDuty protection plans are enabled. For any protection plan that is not enabled, GuardDuty will request permission to enable the necessary protection plans long enough for GuardDuty to perform the tests that will generate findings. Later, GuardDuty will disable the protection plan once the testing is complete.
**Enabling GuardDuty for the first time**
When GuardDuty gets enabled in your dedicated account for the first time in a specific Region, your account will be automatically enrolled in a 30-day free trial.
GuardDuty offers optional protection plans. At the time of enabling GuardDuty, certain protection plans also get enabled and are included in the GuardDuty 30-day free trial. For more information, see [Using GuardDuty 30-day free trial](guardduty-pricing.md#using-guardduty-30-day-free-trial).
**GuardDuty is already enabled in your account prior to running the tester script**
When GuardDuty is already enabled, then based on the parameters, the tester script will check the configuration status of certain protection plans and other account level settings that are required to generate the findings.
By running this tester script, certain protection plans may get enabled for the first time in your dedicated account in a Region. This will start the 30-day free trial for that protection plan. For information about free trial associated with each protection plan, see [Using GuardDuty 30-day free trial](guardduty-pricing.md#using-guardduty-30-day-free-trial).
+ As long as the GuardDuty tester infrastructure is deployed, you may occasionally receive [UnauthorizedAccess:EC2/TorClient](guardduty_finding-types-ec2.md#unauthorizedaccess-ec2-torclient) findings from the PenTest instance.
## GuardDuty findings tester script can generate
Presently, the tester script generates following finding types that are related to Amazon EC2, Amazon EKS, Amazon S3, IAM, and EKS audit logs:
+ [AttackSequence:EKS/CompromisedCluster](guardduty-attack-sequence-finding-types.md#attack-sequence-eks-compromised-cluster)
+ [AttackSequence:S3/CompromisedData](guardduty-attack-sequence-finding-types.md#attack-sequence-s3-compromised-data)
+ [Backdoor:EC2/C&CActivity.B\$1DNS](guardduty_finding-types-ec2.md#backdoor-ec2-ccactivitybdns)
+ [Backdoor:EC2/DenialOfService.Dns](guardduty_finding-types-ec2.md#backdoor-ec2-denialofservicedns)
+ [Backdoor:EC2/DenialOfService.Udp](guardduty_finding-types-ec2.md#backdoor-ec2-denialofserviceudp)
+ [CryptoCurrency:EC2/BitcoinTool.B\$1DNS](guardduty_finding-types-ec2.md#cryptocurrency-ec2-bitcointoolbdns)
+ [Impact:EC2/AbusedDomainRequest.Reputation](guardduty_finding-types-ec2.md#impact-ec2-abuseddomainrequestreputation)
+ [Impact:EC2/BitcoinDomainRequest.Reputation](guardduty_finding-types-ec2.md#impact-ec2-bitcoindomainrequestreputation)
+ [Impact:EC2/MaliciousDomainRequest.Reputation](guardduty_finding-types-ec2.md#impact-ec2-maliciousdomainrequestreputation)
+ [Impact:EC2/SuspiciousDomainRequest.Reputation](guardduty_finding-types-ec2.md#impact-ec2-suspiciousdomainrequestreputation)
+ [Recon:EC2/Portscan](guardduty_finding-types-ec2.md#recon-ec2-portscan)
+ [Trojan:EC2/BlackholeTraffic\$1DNS](guardduty_finding-types-ec2.md#trojan-ec2-blackholetrafficdns)
+ [Trojan:EC2/DGADomainRequest.C\$1DNS](guardduty_finding-types-ec2.md#trojan-ec2-dgadomainrequestcdns)
+ [Trojan:EC2/DNSDataExfiltration](guardduty_finding-types-ec2.md#trojan-ec2-dnsdataexfiltration)
+ [Trojan:EC2/DriveBySourceTraffic\$1DNS](guardduty_finding-types-ec2.md#trojan-ec2-drivebysourcetrafficdns)
+ [Trojan:EC2/DropPoint\$1DNS](guardduty_finding-types-ec2.md#trojan-ec2-droppointdns)
+ [Trojan:EC2/PhishingDomainRequest\$1DNS](guardduty_finding-types-ec2.md#trojan-ec2-phishingdomainrequestdns)
+ [UnauthorizedAccess:EC2/MaliciousIPCaller.Custom](guardduty_finding-types-ec2.md#unauthorizedaccess-ec2-maliciousipcallercustom)
+ [UnauthorizedAccess:EC2/RDPBruteForce](guardduty_finding-types-ec2.md#unauthorizedaccess-ec2-rdpbruteforce)
+ [UnauthorizedAccess:EC2/SSHBruteForce](guardduty_finding-types-ec2.md#unauthorizedaccess-ec2-sshbruteforce)
+ [PenTest:IAMUser/KaliLinux](guardduty_finding-types-iam.md#pentest-iam-kalilinux)
+ [Recon:IAMUser/MaliciousIPCaller.Custom](guardduty_finding-types-iam.md#recon-iam-maliciousipcallercustom)
+ [Recon:IAMUser/TorIPCaller](guardduty_finding-types-iam.md#recon-iam-toripcaller)
+ [Stealth:IAMUser/CloudTrailLoggingDisabled](guardduty_finding-types-iam.md#stealth-iam-cloudtrailloggingdisabled)
+ [Stealth:IAMUser/PasswordPolicyChange](guardduty_finding-types-iam.md#stealth-iam-passwordpolicychange)
+ [UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS](guardduty_finding-types-iam.md#unauthorizedaccess-iam-instancecredentialexfiltrationoutsideaws)
+ [UnauthorizedAccess:IAMUser/MaliciousIPCaller.Custom](guardduty_finding-types-iam.md#unauthorizedaccess-iam-maliciousipcallercustom)
+ [UnauthorizedAccess:IAMUser/TorIPCaller](guardduty_finding-types-iam.md#unauthorizedaccess-iam-toripcaller)
+ [Discovery:Kubernetes/MaliciousIPCaller.Custom](guardduty-finding-types-eks-audit-logs.md#discovery-kubernetes-maliciousipcallercustom)
+ [Discovery:Kubernetes/SuccessfulAnonymousAccess](guardduty-finding-types-eks-audit-logs.md#discovery-kubernetes-successfulanonymousaccess)
+ [Discovery:Kubernetes/TorIPCaller](guardduty-finding-types-eks-audit-logs.md#discovery-kubernetes-toripcaller)
+ [Execution:Kubernetes/ExecInKubeSystemPod](guardduty-finding-types-eks-audit-logs.md#execution-kubernetes-execinkubesystempod)
+ [Impact:Kubernetes/MaliciousIPCaller.Custom](guardduty-finding-types-eks-audit-logs.md#impact-kubernetes-maliciousipcallercustom)
+ [Persistence:Kubernetes/ContainerWithSensitiveMount](guardduty-finding-types-eks-audit-logs.md#persistence-kubernetes-containerwithsensitivemount)
+ [Policy:Kubernetes/AdminAccessToDefaultServiceAccount](guardduty-finding-types-eks-audit-logs.md#policy-kubernetes-adminaccesstodefaultserviceaccount)
+ [Policy:Kubernetes/AnonymousAccessGranted](guardduty-finding-types-eks-audit-logs.md#policy-kubernetes-anonymousaccessgranted)
+ [PrivilegeEscalation:Kubernetes/PrivilegedContainer](guardduty-finding-types-eks-audit-logs.md#privilegeescalation-kubernetes-privilegedcontainer)
+ [UnauthorizedAccess:Lambda/MaliciousIPCaller.Custom](lambda-protection-finding-types.md#unauthorized-access-lambda-maliciousIPcaller-custom)
+ [Discovery:S3/MaliciousIPCaller.Custom](guardduty_finding-types-s3.md#discovery-s3-maliciousipcallercustom)
+ [Discovery:S3/TorIPCaller](guardduty_finding-types-s3.md#discovery-s3-toripcaller)
+ [PenTest:S3/KaliLinux](guardduty_finding-types-s3.md#pentest-s3-kalilinux)
+ [Policy:S3/AccountBlockPublicAccessDisabled](guardduty_finding-types-s3.md#policy-s3-accountblockpublicaccessdisabled)
+ [Policy:S3/BucketAnonymousAccessGranted](guardduty_finding-types-s3.md#policy-s3-bucketanonymousaccessgranted)
+ [Policy:S3/BucketBlockPublicAccessDisabled](guardduty_finding-types-s3.md#policy-s3-bucketblockpublicaccessdisabled)
+ [Policy:S3/BucketPublicAccessGranted](guardduty_finding-types-s3.md#policy-s3-bucketpublicaccessgranted)
+ [Stealth:S3/ServerAccessLoggingDisabled](guardduty_finding-types-s3.md#stealth-s3-serveraccessloggingdisabled)
+ [UnauthorizedAccess:S3/MaliciousIPCaller.Custom](guardduty_finding-types-s3.md#unauthorizedaccess-s3-maliciousipcallercustom)
+ [UnauthorizedAccess:S3/TorIPCaller](guardduty_finding-types-s3.md#unauthorizedaccess-s3-toripcaller)
+ [Backdoor:Runtime/C&CActivity.B\$1DNS](findings-runtime-monitoring.md#backdoor-runtime-ccactivitybdns)
+ [CryptoCurrency:Runtime/BitcoinTool.B\$1DNS](findings-runtime-monitoring.md#cryptocurrency-runtime-bitcointoolbdns)
+ [DefenseEvasion:Runtime/ProcessInjection.Ptrace](findings-runtime-monitoring.md#defenseeva-runtime-processinjectionptrace)
+ [DefenseEvasion:Runtime/ProcessInjection.VirtualMemoryWrite](findings-runtime-monitoring.md#defenseeva-runtime-processinjectionvirtualmemw)
+ [Execution:Runtime/ReverseShell](findings-runtime-monitoring.md#execution-runtime-reverseshell)
+ [Impact:Runtime/AbusedDomainRequest.Reputation](findings-runtime-monitoring.md#impact-runtime-abuseddomainrequestreputation)
+ [Impact:Runtime/BitcoinDomainRequest.Reputation](findings-runtime-monitoring.md#impact-runtime-bitcoindomainrequestreputation)
+ [Impact:Runtime/MaliciousDomainRequest.Reputation](findings-runtime-monitoring.md#impact-runtime-maliciousdomainrequestreputation)
+ [Impact:Runtime/SuspiciousDomainRequest.Reputation](findings-runtime-monitoring.md#impact-runtime-suspiciousdomainrequestreputation)
+ [PrivilegeEscalation:Runtime/ContainerMountsHostDirectory](findings-runtime-monitoring.md#privilegeescalation-runtime-containermountshostdirectory)
+ [PrivilegeEscalation:Runtime/DockerSocketAccessed](findings-runtime-monitoring.md#privilegeesc-runtime-dockersocketaccessed)
+ [Trojan:Runtime/BlackholeTraffic\$1DNS](findings-runtime-monitoring.md#trojan-runtime-blackholetrafficdns)
+ [Trojan:Runtime/DGADomainRequest.C\$1DNS](findings-runtime-monitoring.md#trojan-runtime-dgadomainrequestcdns)
+ [Trojan:Runtime/DriveBySourceTraffic\$1DNS](findings-runtime-monitoring.md#trojan-runtime-drivebysourcetrafficdns)
+ [Trojan:Runtime/DropPoint\$1DNS](findings-runtime-monitoring.md#trojan-runtime-droppointdns)
+ [Trojan:Runtime/PhishingDomainRequest\$1DNS](findings-runtime-monitoring.md#trojan-runtime-phishingdomainrequestdns)
## Step 1 - Prerequisites
To prepare your test environment, you will need the following items:
+ **Git** – Install git command line tool based on the operating system that you use.
This is required to clone the [`amazon-guardduty-tester` repository](https://github.com/awslabs/amazon-guardduty-tester).
+ **AWS Command Line Interface** – An open source tool that enables you to interact with AWS services by using commands in your command-line shell. For more information, see [Get started with AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html) in the *AWS Command Line Interface User Guide*.
+ **AWS Systems Manager** – To initiate Session Manager sessions with your managed nodes by using AWS CLI you must install the Session Manager plugin on your local machine. For more information, see [Install Session Manager plugin for AWS CLI](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-working-with-install-plugin.html) in the *AWS Systems Manager User Guide*.
+ **Node Package Manager (NPM)** – Install NPM to install all the dependencies.
+ **Docker** – You must have Docker installed. For installation instructions, see the [Docker website](https://docs.docker.com/get-docker/).
To verify that Docker has been installed, run the following command and confirm there is an output similar to the following output:
```
$ docker --version
Docker version 19.03.1
```
+ Subscribe to [Kali Linux](https://aws.amazon.com/marketplace/pp/prodview-fznsw3f7mq7to) image in the *AWS Marketplace*.
## Step 2 - Deploy AWS resources
This section provides a list of key concepts and the steps to deploy certain AWS resources in your dedicated account.
### Concepts
The following list provides key concepts related to the commands that help you deploy the resources:
+ **AWS Cloud Development Kit (AWS CDK)** – CDK is an open-source software development framework for defining cloud infrastructure in code and provisioning it through CloudFormation. CDK supports a couple of programming languages to define reusable cloud components known as constructs. You can compose these together into stacks and apps. Then, you can deploy your CDK applications to CloudFormation to provision or update your resources. For more information, see [What is the AWS CDK?](https://docs.aws.amazon.com/cdk/v2/guide/home.html) in the *AWS Cloud Development Kit (AWS CDK) Developer Guide*.
+ **Bootstrapping** – It is the process of preparing your AWS environment for usage with AWS CDK. Before you deploy a CDK stack into an AWS environment, the environment must first be bootstrapped. This process of provisioning specific AWS resources in your environment that are used by AWS CDK is part of the steps that you will perform in the next section - [Steps to deploy AWS resources](#steps-deploy-resource-test-guardduty-findings).
For more information about how bootstrapping works, see [Bootstrapping](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html) in the *AWS Cloud Development Kit (AWS CDK) Developer Guide*.
### Steps to deploy AWS resources
Perform the following steps to start deploying the resources:
1. Set up your AWS CLI default account and Region unless the dedicated account Region variables are manually set in the `bin/cdk-gd-tester.ts` file. For more information, see [Environments](https://docs.aws.amazon.com/cdk/v2/guide/environments.html) in the *AWS Cloud Development Kit (AWS CDK) Developer Guide*.
1. Run the following commands to deploy the resources:
```
git clone https://github.com/awslabs/amazon-guardduty-tester && cd amazon-guardduty-tester
npm install
cdk bootstrap
cdk deploy
```
The last command (`cdk deploy`) creates a CloudFormation stack on your behalf. The name of this stack is **GuardDutyTesterStack**.
As a part of this script, GuardDuty creates new resources to generate GuardDuty findings in your account. It also adds the following tag key:value pair to the Amazon EC2 instances:
`CreatedBy`:`GuardDuty Test Script`
The Amazon EC2 instances also include the EC2 instances that host EKS nodes and ECS clusters.
**Instance types**
GuardDuty is designed to use cost-effective instance types that provide the minimum performance necessary to successfully carry out tests. Because of vCPU requirements, the Amazon EKS node group requires `t3.medium`, and because of increased network capacity required for DenialOfService finding tests, the driver node requires `m6i.large`. For all other tests, GuardDuty uses `t3.micro` instance type. For more information about instance types, see [Available sizes](https://docs.aws.amazon.com/ec2/latest/instancetypes/gp.html#gp_sizes) in the *Amazon EC2 Instances Types Guide*.
## Step 3 - Run tester scripts
This is a two-step process where you first need to start a session with test driver and then, run scripts to generate GuardDuty findings with specific resource combinations.
### Part A - Start session with test driver
1. After your resources are deployed, save the Region code to a variable in your current terminal session. Use the following command and replace *us-east-1* with the Region code where you deployed the resources:
```
$ REGION=us-east-1
```
1. The tester script is available only through AWS Systems Manager (SSM). To start an interactive shell on the tester host instance, query the host **InstanceId**.
1. Use the following command to begin your session for the tester script:
```
aws ssm start-session
--region $REGION
--document-name AWS-StartInteractiveCommand
--parameters command="cd /home/ssm-user/py_tester && bash -l"
--target $(aws ec2 describe-instances
--region $REGION
--filters "Name=tag:Name,Values=Driver-GuardDutyTester"
--query "Reservations[].Instances[?State.Name=='running'].InstanceId"
--output text)
```
### Part B - Generate findings
The tester script is a Python-based program that dynamically builds a bash script to generate findings based on your input. You have flexibility to generate findings based on one or more AWS resource types, GuardDuty protection plans, [Threat Purposes](guardduty_finding-format.md#guardduty_threat_purposes) (tactics), [Foundational data sources](guardduty_data-sources.md), or [GuardDuty findings tester script can generate](#gdu-findings-tester-generates).
Use the following command examples as reference, and run one or more commands to generate findings that you want to explore:
```
python3 guardduty_tester.py
python3 guardduty_tester.py --all
python3 guardduty_tester.py --s3
python3 guardduty_tester.py --tactics discovery
python3 guardduty_tester.py --ec2 --eks --tactics backdoor policy execution
python3 guardduty_tester.py --eks --runtime only
python3 guardduty_tester.py --ec2 --runtime only --tactics impact
python3 guardduty_tester.py --log-source dns vpc-flowlogs
python3 guardduty_tester.py --finding 'CryptoCurrency:EC2/BitcoinTool.B!DNS'
```
For more information about valid parameters, you can run the following help command:
```
python3 guardduty_tester.py --help
```
### Part C - Review generated findings
Choose a preferred method to view the generated findings in your account.
------
#### [ GuardDuty console ]
1. Sign in to the AWS Management Console and open the GuardDuty console at [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/).
1. In the navigation pane, choose **Findings**.
1. From the findings table, select a finding for which you want to view the details. This will open up the finding details panel. For information, see [Understanding and generating Amazon GuardDuty findings](guardduty_findings.md).
1. If you want to filter these findings, use the resource tag key and value. For example, to filter the findings generated for the Amazon EC2 instances, use `CreatedBy`:`GuardDuty Test Script` tag key:value pair for **Instance tag key** and **Instance tag key**.
------
#### [ API ]
+ Run [ListFindings](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListFindings.html) to view the findings for a specific detector ID. You can specific parameters to filter findings.
To find the `detectorId` for your account and current Region, see the **Settings** page in the [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) console, or run the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html) API.
------
#### [ AWS CLI ]
+ Run the following AWS CLI command to view the generated findings and replace *us-east-1* and *12abc34d567e8fa901bc2d34EXAMPLE* with suitable values:
```
aws guardduty list-findings --region us-east-1 --detector-id 12abc34d567e8fa901bc2d34EXAMPLE
```
To find the `detectorId` for your account and current Region, see the **Settings** page in the [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) console, or run the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html) API.
For more information about the parameters that you can use to filter findings, see [list-findings](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/guardduty/list-findings.html) in the *AWS CLI Command Reference*.
------
## Step 4 - Clean up AWS test resources
The account-level settings and other configuration status updates made during [Step 3 - Run tester scripts](#run-gdu-tester-script) return to the original state when the tester script concludes.
After you have run the tester script, you can choose to clean up the AWS test resources. You can choose to do this by using one of the following methods:
+ Run the following command:
```
cdk destroy
```
+ Delete the CloudFormation stack with the name **GuardDutyTesterStack**. For information about steps, see [Deleting a stack on the CloudFormation console](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-delete-stack.html).
## Troubleshooting common issues
GuardDuty has identified common issues and recommends troubleshooting steps:
+ `Cloud assembly schema version mismatch` – Update AWS CDK CLI to a version compatible with the required cloud assembly version, or to the latest available version. For more information, see [AWS CDK CLI compatibility](https://docs.aws.amazon.com/cdk/v2/guide/versioning.html#cdk_toolkit_versioning).
+ `Docker permission denied` – Add the dedicated account user to the **docker** or **docker-users** so that the dedicated account can run the commands. For more information about steps, see [Daemon socket option](https://docs.docker.com/reference/cli/dockerd/#daemon-socket-option).
+ `Your requested instance type is not supported in your requested Availability Zone` – Some Availability zones don't support particular instance types. To identify which availability zones support your preferred instance type and reattempt to deploy AWS resources, perform the following steps:
1. Choose a preferred method to determine which Availability zones support your instance type:
------
#### [ Console ]
**To identify Availability zones that support preferred instance type**
1. Sign in to the AWS Management Console and open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. By using the AWS Region selector in the upper-right corner of the page, choose the Region where you want to launch the instance.
1. In the navigation pane, under **Instances**, choose **Instance Types**.
1. From the **Instance types** table, choose a preferred instance type.
1. Under **Networking**, view the Regions listed under **Availability zones**.
Based on this information, you might need to choose a new Region where you can deploy the resources.
------
#### [ AWS CLI ]
Run the following command to view a list of Availability zones. Make sure to specify your preferred instance type and the Region (*us-east-1*).
```
aws ec2 describe-instance-type-offerings --location-type availability-zone --filters Name=instance-type,Values=Preferred instance type --region us-east-1 --output table
```
For more information about this command, see [describe-instance-type-offerings](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/describe-instance-type-offerings.html) in the *AWS CLI Command Reference*.
When running this command, if you receive an error, make sure you are using the latest version of AWS CLI. For more information, see [Troubleshooting](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-troubleshooting.html) in the *AWS Command Line Interface User Guide*.
------
1. Attempt deploying the AWS resources again and specify an Availability zone that supports your preferred instance type.
**To re-attempt deploying AWS resources**
1. Set up the default Region in the `bin/cdk-gd-tester.ts` file.
1. To specify the Availability zone, open the `amazon-guardduty-tester/lib/common/network/vpc.ts` file.
1. In this file, replace `maxAzs: 2,` with `availabilityZones: ['us-east-1a', 'us-east-1c'],` where you must specify the Availability zones for your instance type.
1. Continue with the remaining steps under [Steps to deploy AWS resources](#steps-deploy-resource-test-guardduty-findings).
# Viewing generated findings in GuardDuty console
When GuardDuty detects an activity that matches the pattern of a security issue, GuardDuty generates a finding. This finding is associated with a resource type that may have been compromised during this activity. You can view the details associated with each finding that GuardDuty generates.
If you are using a GuardDuty administrator account, you can view the generated findings on behalf of the member accounts. However, a member account can view the findings generated in their own account. A member account can't view the findings generated for other member accounts.
**Steps to view findings in GuardDuty console**
1. Open the GuardDuty console at [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/).
1. In the left navigation pane, choose **Findings**.
GuardDuty displays the findings in a tabular format. By default, this table is sorted in decreasing order based on the **Last seen** column value, displaying the most recent findings at the top.
Findings with a sword icon (![\[Sword icon that represents attack sequence finding in GuardDuty console.\]](http://docs.aws.amazon.com/guardduty/latest/ug/images/attack-sequences-icon.PNG)) represent an attack sequence finding.
1. To view details associated with a finding, select its **Title**. This will open the finding details side panel. For an attack sequence finding, this side panel includes a *summarized version* of the attack sequence, and to expand this view, choose **View details**.
For information about the fields listed in this side panel, see [Finding details](guardduty_findings-summary.md).
1.
**(Optional) to download finding JSON**
1. Select the finding, and then choose the **Actions** menu.
1. On the **Actions** menu, choose **View and export JSON**.
1. On the **Findings JSON** window, choose **Download**.
**Note**
In some cases, GuardDuty becomes aware that certain findings are false positives after they have been generated. GuardDuty provides a **Confidence** field in the finding's JSON, and sets its value to zero. This way GuardDuty lets you know that you can safely ignore such findings.
Findings without the **Confidence** field are not considered false positives.
## Navigating Findings page
This section provides key information about various elements on the **Findings** page. This will help you analyze the generated findings for threat analysis and response.
The following list explains **Findings** page elements that will help you better understand the generated findings:
+ **Threat type**:
Threat type includes individual GuardDuty findings and attack sequence findings. By default, the page displays **All findings**.
To filter the findings table view, on the **Threat type** menu, choose one of the options – **Attack sequence findings only** or **Individual findings only**.
+ **Resource and Count columns**:
The **Resource** column in the findings table shows the name of the potentially compromised AWS resource. For an attack sequence finding, this column shows the number of potentially compromised AWS resources. To view the resource names, select the *number* under the **Resource** column.
The **Count** column indicates the number of times GuardDuty observes a specific finding. When GuardDuty detects that an activity that matches a previously identified security issue, it increments the count for that specific finding. For an attack sequence finding, this column value indicates the total number of signals and findings involved in the generation of the finding.
+ **Sorting findings by table columns**:
If there is an *arrow* next to a column header, then you can sort the findings table based on the column. Select the column header to sort the findings in either increasing or decreasing order of the value in that column.
+ **Filtering findings**:
Based on specific property attributes, such as `Account ID` and `Resource type`, you can further filter the findings table. For information about types of filters you can use, see [Filtering GuardDuty findings](guardduty_filter-findings.md).
+ **Status and Saved rules**:
The **Status** menu includes two values – **Current** and **Archived**. The default view is **Current** findings in the table.
When you no longer want GuardDuty to generate a finding that matches a specific criteria, you can suppress that finding. GuardDuty archives that finding. When GuardDuty detects this finding again, you will not be notified of this observation. To specifically view archived findings, on the **Status** menu, choose **Archived**.
**Saved rules** is a feature that helps you automatically filter and take actions on findings that match a specified criteria. Actions may include archiving findings or suppressing them from future notifications.
For more information, see [Suppression rules](findings_suppression-rule.md).
# Severity levels of GuardDuty findings
Each GuardDuty finding has an assigned severity level and value that reflects the potential risk the finding could have to your environment, as determined by our security engineers. The value of the severity can fall anywhere within the 1.0 to 10.0 range, with higher values indicating greater security risk. To help you determine a response to a potential security issue that is highlighted by a finding, GuardDuty breaks down this range into *Critical*, *High*, *Medium*, and *Low* severity levels.
A finding of a particular type may have a different severity depending on the context specific to the finding. To view a consolidated list of default severity levels for all GuardDuty finding types, see [GuardDuty active finding types](guardduty_finding-types-active.md#findings-table).
The following sections explain defined severity levels for the GuardDuty findings.
**Topics**
+ [
## Critical severity
](#guardduty-finding-severity-level-critical)
+ [
## High severity
](#guardduty-finding-severity-level-high)
+ [
## Medium severity
](#guardduty-finding-severity-level-medium)
+ [
## Low severity
](#guardduty-finding-severity-level-low)
## Critical severity
**Value range**: 9.0 - 10.0
**Description**: A critical severity level indicates that an attack sequence may be in progress or had recently happened. One or more AWS resources, such as IAM user sign-in credentials and Amazon S3 bucket, are potentially being compromised or may have already been compromised.
**Recommendation**: GuardDuty recommends that you prioritize triaging and remediating all critical severity findings because these issues can be a part of a ransomware attack and can escalate at any time. View details about the involved resources and start addressing the security issues. For more information, see [Remediating findings](guardduty_remediate.md).
## High severity
**Value range**: 7.0 - 8.9
**Description**: A High severity level indicates that the resource in question (an Amazon EC2 instance or a set of IAM user sign-in credentials) is compromised and is actively being used for unauthorized purposes.
**Recommendation**: GuardDuty recommends that you treat any high severity finding security issue as a priority and take immediate remediation steps to prevent further unauthorized use of your resources. For example, clean up your Amazon EC2 instance or terminate it, or rotate the IAM credentials. Follow the steps in [Remediating findings](guardduty_remediate.md) to remediate the finding.
## Medium severity
**Value range**: 4.0 - 6.9
**Description**: A medium severity level indicates suspicious activity that deviates from normally observed behavior and, depending on your use case, may be indicative of a resource compromise.
**Recommendation**: GuardDuty recommends investigating the potentially impacted resource at your earliest convenience. Remediation steps will vary by resource and finding family. An establish approach is for you to confirm that the activity is authorized and consistent with your use case. If you cannot identify the cause, or confirm the activity was authorized, you should consider the resource compromised. Follow the steps in [Remediating findings](guardduty_remediate.md) to remediate the finding.
Here are some things to consider when reviewing a medium level finding:
+ Check if an authorized user has installed new software that changed the behavior of a resource (for example, allowed higher than normal traffic, or enabled communication on a new port).
+ Check if an authorized user changed the control plane settings, for example, modified a security group setting.
+ Run an anti-virus scan on the implicated resource to detect unauthorized software.
+ Verify the permissions that are attached to the implicated IAM role, user, group, or set of credentials. These might have to be changed or rotated.
## Low severity
**Value range**: 1.0 - 3.9
**Description**: A low severity level indicates attempted suspicious activity that did not compromise your environment, for example, a port scan or a failed intrusion attempt.
**Recommendation**: There is no immediate recommended action, but it is worth taking a note of this information as it may indicate someone is looking for weak points in your environment.
# Finding details
In the Amazon GuardDuty console, you can view finding details in the finding summary section. Finding details vary based on the finding type.
There are two primary details that determine what kind of information is available for any finding. The first is the resource type, which can be `Instance`, `AccessKey`, `S3Bucket`, `S3Object`, `Kubernetes cluster`, `ECS cluster`, `Container`, `RDSDBInstance`, `RDSLimitlessDB`, or `Lambda`. The second detail that determines finding information is **Resource Role**. Resource role can be `Target`, meaning the resource was the target of suspicious activity. For instance type findings, resource role can also be `Actor`, which means that your resource was the actor carrying out suspicious activity. This topic describes some of the commonly available details for findings. For [GuardDuty Runtime Monitoring finding types](findings-runtime-monitoring.md) and [Malware Protection for S3 finding type](gdu-malware-protection-s3-finding-types.md), the resource role is not populated.
**Topics**
+ [
## Finding overview
](#findings-summary-section)
+ [
## Resource
](#findings-resource-affected)
+ [
## Attack sequence finding details
](#guardduty-extended-threat-detection-attack-sequence-finding-details)
+ [
## RDS database (DB) user details
](#rds-pro-db-user-details)
+ [
## Runtime Monitoring finding details
](#runtime-monitoring-runtime-details)
+ [
## EBS volumes scan details
](#mp-ebs-volumes-scan-details)
+ [
## Malware Protection for EC2 finding details
](#malware-protection-scan-details)
+ [
## Malware Protection for S3 finding details
](#gdu-malware-protection-for-s3-finding-details)
+ [
## Action
](#finding-action-section)
+ [
## Actor or Target
](#finding-actor-target)
+ [
## Geolocation details
](#guardduty-finding-details-geolocation)
+ [
## Additional information
](#finding-additional-info)
+ [
## Evidence
](#finding-evidence)
+ [
## Anomalous behavior
](#finding-anomalous)
## Finding overview
A finding's **Overview** section contains the most basic identifying features of the finding, including the following information:
+ **Account ID** – The ID of the AWS account in which the activity took place that prompted GuardDuty to generate this finding.
+ **Count** – The number of times GuardDuty has aggregated an activity matching this pattern to this finding ID.
+ **Created at** – The time and date when this finding was first created. If this value differs from **Updated at**, it indicates that the activity has occurred multiple times and is an ongoing issue.
**Note**
Timestamps for findings in the GuardDuty console appear in your local time zone, while JSON exports and CLI outputs display timestamps in UTC.
+ **Finding ID** – A unique identifier for this finding type and set of parameters. New occurrences of activity matching this pattern will be aggregated to the same ID.
+ **Finding type** – A formatted string representing the type of activity that triggered the finding. For more information, see [GuardDuty finding format](guardduty_finding-format.md).
+ **Region** – The AWS Region in which the finding was generated. For more information about supported Regions, see [Regions and endpoints](guardduty_regions.md)
+ **Resource ID** – The ID of the AWS resource against which the activity took place that prompted GuardDuty to generate this finding.
+ **Scan ID** – Applicable to findings when GuardDuty Malware Protection for EC2 is enabled, this is an identifier of the malware scan that runs on the EBS volumes attached to the potentially compromised EC2 instance or container workload. For more information, see [Malware Protection for EC2 finding details](#malware-protection-scan-details).
+ **Severity** – A finding's assigned severity level of either Critical, High, Medium, or Low. For more information, see [Findings severity levels](guardduty_findings-severity.md).
+ **Updated at** – The last time this finding was updated with new activity matching the pattern that prompted GuardDuty to generate this finding.
## Resource
The **Resource affected** gives details about the AWS resource that was targeted by the initiating activity. The information available varies based on resource type and action type.
**Resource role** – The role of the AWS resource that initiated the finding. This value can be **TARGET** or **ACTOR**, and represents whether your resource was the target of the suspicious activity or the actor that performed the suspicious activity.
**Resource type** – The type of the affected resource. If multiple resources were involved, a finding can include multiple resources types. The resource types are **Instance**, **AccessKey**, **S3Bucket**, **S3Object**, **KubernetesCluster**, **ECSCluster**, **Container**, **RDSDBInstance**, **RDSLimitlessDB**, and **Lambda**. Depending on the resource type, different finding details are available. Select a resource option tab to learn about the details available for that resource.
------
#### [ Instance ]
**Instance details:**
**Note**
Some instance details may be missing if the instance has already been stopped or if the underlying API invocation originated from an EC2 instance in a different Region when making a cross-Region API call.
+ **Instance ID** – The ID of the EC2 instance involved in the activity that prompted GuardDuty to generate the finding.
+ **Instance Type** – The type of the EC2 instance involved in the finding.
+ **Launch Time** – The time and date that the instance was launched.
+ **Outpost ARN** – The Amazon Resource Name (ARN) of AWS Outposts. Only applicable to AWS Outposts instances. For more information, see [What is AWS Outposts?](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html) in the *User Guide for Outposts racks*.
+ **Security Group Name** – The name of the Security Group attached to the involved instance.
+ **Security Group ID** – The ID of the Security Group attached to the involved instance.
+ **Instance state** – The current state of the targeted instance.
+ **Availability Zone** – The AWS Region Availability Zone in which the involved instance is located.
+ **Image ID** – The ID of the Amazon Machine Image used to build the instance involved in the activity.
+ **Image Description** – A description of the ID of the Amazon Machine Image used to build the instance involved in the activity.
+ **Tags** – A list of tags attached to this resource, listed in the format of `key`:`value`.
------
#### [ AccessKey ]
**Access Key details:**
+ **Access key ID** – The Access key ID of the user engaged in the activity that prompted GuardDuty to generate the finding.
+ **Principal ID** – The principal ID of the user engaged in the activity that prompted GuardDuty to generate the finding.
+ **User type** – The type of user engaged in the activity that prompted GuardDuty to generate the finding. For more information, see [CloudTrail userIdentity element](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-user-identity.html#cloudtrail-event-reference-user-identity-fields).
+ **User name** – The name of the user engaged in the activity that prompted GuardDuty to generate the finding.
------
#### [ S3Bucket ]
**Amazon S3 bucket details:**
+ **Name** – The name of the bucket involved in the finding.
+ **ARN** – The ARN of the bucket involved in the finding.
+ **Owner** – The canonical user ID of the user that owns the bucket involved in the finding. For more information on canonical user IDs see [AWS account identifiers](https://docs.aws.amazon.com/general/latest/gr/acct-identifiers.html).
+ **Type** – The type of bucket finding, can be either **Destination** or **Source**.
+ ** Default server side encryption** – The encryption details for the bucket.
+ **Bucket Tags** – A list of tags attached to this resource, listed in the format of `key`:`value`.
+ **Effective Permissions** – An evaluation of all effective permissions and policies on the bucket that indicates whether the involved bucket is publicly exposed. Values can be **Public** or **Not public**.
------
#### [ S3Object ]
+ **S3 object details** – Includes the following information about the scanned S3 object:
+ **ARN** – Amazon Resource Name (ARN) of the scanned S3 object.
+ **Key** – The name assigned to the file when it was created in S3 bucket.
+ **Version Id** – When you have enabled bucket versioning, this field indicates the version Id associated with the latest version of the scanned S3 object. For more information, see [Using versioning in S3 buckets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Versioning.html) in the *Amazon S3 User Guide*.
+ **eTag** – Represents the specific version of the scanned S3 object.
+ **Hash** – Hash of the threat detected in this finding.
+ **S3 bucket details** – Includes the following information about the Amazon S3 bucket associated with the scanned S3 object:
+ **Name** – Indicates the name of the S3 bucket that contains the object.
+ **ARN** – Amazon Resource Name (ARN) of the S3 bucket.
+ **Owner** – Canonical Id of the owner of the S3 bucket.
------
#### [ EKSCluster ]
**Kubernetes cluster details:**
+ **Name** – The name of the Kubernetes cluster.
+ **ARN** – The ARN that identifies the cluster.
+ **Created At** – The time and date when this cluster was created.
**Note**
Timestamps for findings in the GuardDuty console appear in your local time zone, while JSON exports and CLI outputs display timestamps in UTC.
+ **VPC ID** – The ID of the VPC that is associated to your cluster.
+ **Status** – The current status of the cluster.
+ **Tags** – The metadata that you apply to the cluster to help you to categorize and organize them. Each tag consists of a key and an optional value, listed in the format `key`:`value`. You get to define both key and value.
Cluster tags do not propagate to any other resource associated with the cluster.
**Kubernetes workload details:**
+ **Type** – The type of Kubernetes workload, such as pod, deployment, and job.
+ **Name** – The name of the Kubernetes workload.
+ **Uid** – The unique ID of the Kubernetes workload.
+ **Created at** – The time and date when this workload was created.
+ **Labels** – The key-value pairs attached to the Kubernetes workload.
+ **Containers** – The details of the container running as a part of Kubernetes workload.
+ **Namespace** – The workload belongs to this Kubernetes namespace.
+ **Volumes** – The volumes used by the Kubernetes workload.
+ **Host path** – Represents a preexisting file or directory on the host machine that the volume maps to.
+ **Name** – The name of the volume.
+ **pod security context** – Defines the privilege and acess control settings for all containers in a pod.
+ **Host network** – Set to `true` if the pods are included in the Kubernetes workload.
**Kubernetes user details:**
+ **Groups** – Kubernetes RBAC (role-access based control) groups of the user involved in the activity that generated the finding.
+ **ID** – Unique ID of the Kubernetes user.
+ **Username** – Name of the Kubernetes user involved in the activity that generated the finding.
+ **Session name** – Entity that assumed the IAM role with Kubernetes RBAC permissions.
------
#### [ ECSCluster ]
**ECS cluster details:**
+ **ARN** – The ARN that identifies the cluster.
+ **Name** – The name of the cluster.
+ **Status** – The current status of the cluster.
+ **Active services count** – The number of services that are running on the cluster in an `ACTIVE` state. You can view these services with [ListServices](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ListServices.html)
+ **Registered container instances count** – The number of container instances registered into the cluster. This includes container instances in both `ACTIVE` and `DRAINING` status.
+ **Running tasks count** – The number of tasks in the cluster that are in the `RUNNING` state.
+ **Tags** – The metadata that you apply to the cluster to help you to categorize and organize them. Each tag consists of a key and an optional value, listed in the format `key`:`value`. You get to define both key and value.
+ **Containers** – The details about the container that's associated with the task:
+ **Container name** – The name of the container.
+ **Container image** – The image of the container.
+ **Task details** – The details of a task in a cluster.
+ **ARN** – The Amazon Resource Name (ARN) of the task.
+ **Definition ARN** – The Amazon Resource Name (ARN) of the task definition that creates the task.
+ **Version** – The version counter for the task.
+ **Task created at** – The Unix timestamp when the task was created.
+ **Task started at** – The Unix timestamp when the task started.
+ **Task started by** – The tag specified when a task is started.
------
#### [ Container ]
**Container details:**
+ **Container runtime** – The container runtime (such as `docker` or `containerd`) used to run the container.
+ **ID** – The container instance ID or full ARN entries for the container instance.
+ **Name** – The name of the container.
+ **Image** – The image of the container instance.
+ **Volume mounts** – List of container volume mounts. A container can mount a volume under its file system.
+ **Security context** – The container security context defines privilege and access control settings for a container.
+ **Process details** – Describes the details of the process that is associated to the finding.
------
#### [ RDSDBInstance ]
**RDSDBInstance details:**
**Note**
This resource is available in RDS Protection findings related to the database instance.
+ **Database Instance ID** – The identifier associated to the database instance that was involved in the GuardDuty finding.
+ **Engine** – The database engine name of the database instance involved in the finding. Possible values are Aurora MySQL-Compatible or Aurora PostgreSQL-Compatible.
+ **Engine version** – The version of the database engine that was involved in the GuardDuty finding.
+ **Database cluster ID** – The identifier of the database cluster that contains the database instance ID involved in the GuardDuty finding.
+ **Database instance ARN** – The ARN that identifies the database instance involved in the GuardDuty finding.
------
#### [ RDSLimitlessDB ]
**RDSLimitlessDB details:**
This resource is available in RDS Protection findings related to the supported engine version of Limitless Database.
+ **DB shard group identifier** – The name associated with the Limitless DB shard group.
+ **DB shard group resource ID** – The resource identifier of the DB shard group within the Limitless DB.
+ **DB shard group ARN** – The Amazon Resource Name (ARN) that identifies the DB shard group.
+ **Engine** – The identifier of the Limitless DB involved in the finding.
+ **Engine version** – The version of the Limitless DB engine.
+ **DB cluster identifier** – The name of the database cluster that is part of the Limitless DB.
For information about user and authentication details of the potentially impacted database, see [RDS database (DB) user details](#rds-pro-db-user-details).
------
#### [ Lambda ]
**Lambda function details**
+ **Function name** – The name of the Lambda function involved in the finding.
+ **Function version** – The version of the Lambda function involved in the finding.
+ **Function description** – A description of the Lambda function involved in the finding.
+ **Function ARN** – The Amazon Resource Name (ARN) of the Lambda function involved in the finding.
+ **Revision ID** – The revision ID of the Lambda function version.
+ **Role** – The execution role of the Lambda function involved in the finding.
+ **VPC configuration** – The Amazon VPC configuration, including the VPC ID, security group, and subnet IDs associated with your Lambda function.
+ **VPC ID** – The ID of the Amazon VPC that is associated with the Lambda function involved in the finding.
+ **Subnet IDs** – The ID of the subnets that are associated with your Lambda function.
+ **Security Group** – The security group attached to the involved Lambda function. This includes the security group name and group ID.
+ **Tags** – A list of tags attached to this resource, listed in the format of `key`:`value` pair.
------
## Attack sequence finding details
GuardDuty provides details for each finding it generates in your account. These details help you understand the reasons behind the finding. This section focuses on details associated with [Attack sequence finding types](guardduty-attack-sequence-finding-types.md). This includes insights such as potentially impacted resources, timeline of events, indicators, signals, and endpoints involved in the finding.
To view details associated with signals that are GuardDuty findings, see the associated sections on this page.
In the GuardDuty console, when you select an attack sequence finding, the details side panel is divided into the following tabs:
+ **Overview** – Provides a compact view of the attack sequence details, including signals, MITRE tactics, and potentially impacted resources.
+ **Signals** – Displays a timeline of events that are involved in an attack sequence.
+ **Resources** – Provides information about the potentially impacted resources, or the resources that are potentially at risk.
The following list provides descriptions associated with the attack sequence finding details.
**Signals**
A signal could be an API activity or a finding that GuardDuty uses to detect an attack sequence finding. GuardDuty considers the weak signals that don't present themselves as clear threat, piece them together, and correlate with individually generated findings. For more context, the **Signals** tab provides a timeline of the signals, as observed by GuardDuty.
Each signal, that is a GuardDuty finding, has it's own severity level and value assigned to it. In the GuardDuty console, you can select each signal to view the associated details.
**Actors**
Provides details about the threat actors in an attack sequence. For more information, see [Actor](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_Actor.html) in *Amazon GuardDuty API Reference*.
**Endpoints**
Provides details about the network endpoints that were used in this attack sequence. For more information, see [NetworkEndpoint](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_NetworkEndpoint.html) in *Amazon GuardDuty API Reference*. For information about how GuardDuty determines location, see [Geolocation details](#guardduty-finding-details-geolocation).
**Indicators**
Includes observed data that matches the pattern of a security issue. This data specifies as to why GuardDuty there is an indication of a potentially suspicious activity. For example, when the indicator name is `HIGH_RISK_API`, this indicates an action commonly used by threat actors, or a sensitive action that may cause potential impact to an AWS account, such as accessing credentials or modifying a resource.
The following table includes a list of potential indicators and their descriptions:
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/guardduty/latest/ug/guardduty_findings-summary.html)
**MITRE tactics**
This field specifies the MITRE ATT&CK tactics that the threat actor attempts through an attack sequence. GuardDuty uses the [MITRE ATT&ACK](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-format.html#guardduty_threat_purposes) framework that adds context to the entire attack sequence. The colors that the GuardDuty console uses to specify the threat purposes that have been used by the threat actor, align with the colors that indicate the critical, high, medium, and low [Findings severity levels](guardduty_findings-severity.md).
**Network indicators**
Indicators include a combination of network indicator values that explain why a network is indicative of a suspicious behavior. This section is applicable only when the **Indicator** includes `SUSPICIOUS_NETWORK` or `MALICIOUS_IP`. The following example shows how network indicators might be associated with an indicator, where:
+ *AnyCompany* is an Autonomous System (AS).
+ `TUNNEL_VPN`, `IS_ANONYMOUS`, and `ALLOWS_FREE_ACCESS` are the network indicators.
```
...{
"key": "SUSPICIOUS_NETWORK",
"values": [{
"AnyCompany": [
"TUNNEL_VPN",
"IS_ANONYMOUS",
"ALLOWS_FREE_ACCESS"
]
}]
}
...
```
The following table includes the network indicator values and their description. These tags are added based on the threat intelligence GuardDuty collects from sources such as Spur
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/guardduty/latest/ug/guardduty_findings-summary.html)
## RDS database (DB) user details
**Note**
This section is applicable to findings when you enable the RDS Protection feature in GuardDuty. For more information, see [GuardDuty RDS Protection](rds-protection.md).
The GuardDuty finding provides the following user and authentication details of the potentially compromised database:
+ **User** – The user name used to make the anomalous login attempt.
+ **Application** – The application name used to make the anomalous login attempt.
+ **Database** – The name of the database instance involved in the anomalous login attempt.
+ **SSL** – The version of the Secure Socket Layer (SSL) used for the network.
+ **Auth method** – The authentication method used by the user involved in the finding.
For information about the potentially compromised resource, see [Resource](#findings-resource-affected).
## Runtime Monitoring finding details
**Note**
These details may be available only if GuardDuty generates one of the [GuardDuty Runtime Monitoring finding types](findings-runtime-monitoring.md).
This section contains the runtime details such as process details and any required context. Process details describe information about the observed process, and runtime context describes any additional information about the potentially suspicious activity.
**Process details**
+ **Name** – The name of the process.
+ **Executable path** – The absolute path of the process executable file.
+ **Executable SHA-256** – The `SHA256` hash of the process executable.
+ **Namespace PID** – The process ID of the process in a secondary PID namespace other than the host level PID namespace. For processes inside a container, it is the process ID observed inside the container.
+ **Present working directory** – The present working directory of the process.
+ **Process ID** – The ID assigned to the process by operating system.
+ **startTime** – The time when the process started. This is in UTC date string format (`2023-03-22T19:37:20.168Z`).
+ **UUID** – The unique ID assigned to the process by GuardDuty.
+ **Parent UUID** – The unique ID of the parent process. This ID is assigned to the parent process by GuardDuty.
+ **User** – The user that executed the process.
+ **User ID** – The ID of the user that executed the process.
+ **Effective user ID** – The effective user ID of the process at the time of the event.
+ **Lineage** – Information about the ancestors of the process.
+ **Process ID** – The ID assigned to the process by operating system.
+ **UUID** – The unique ID assigned to the process by GuardDuty.
+ **Executable path** – The absolute path of the process executable file.
+ **Effective user ID** – The effective user ID of the process at the time of the event.
+ **Parent UUID** – The unique ID of the parent process. This ID is assigned to the parent process by GuardDuty.
+ **Start Time** – The time when the process started.
+ **Namespace PID** – The process ID of the process in a secondary PID namespace other than the host level PID namespace. For processes inside a container, it is the process ID observed inside the container.
+ **User ID** – The user ID of the user that executed the process.
+ **Name** – Name of the process.
**Runtime context**
From the following fields, a generated finding may include only those fields that are relevant to the finding type.
+ **Mount Source** – The path on the host that is mounted by the container.
+ **Mount Target** – The path in the container that is mapped to the host directory.
+ **Filesystem Type** – Represents the type of the mounted filesystem.
+ **Flags** – Represents options that control the behavior of the event involved in this finding.
+ **Modifying Process** – Information about the process that created or modified a binary, script, or a library, inside a container at runtime.
+ **Modified At** – The timestamp at which the process created or modified a binary, script, or library inside a container at runtime. This field is in the UTC date string format (`2023-03-22T19:37:20.168Z`).
+ **Library Path** – The path to the new library that was loaded.
+ **LD Preload Value** – The value of the `LD_PRELOAD` environment variable.
+ **Socket Path** – The path to the Docker socket that was accessed.
+ **Runc Binary Path** – The path to the `runc` binary.
+ **Release Agent Path** – The path to the `cgroup` release agent file.
+ **Command Line Example** – The example of the command line involved in the potentially suspicious activity.
+ **Tool Category** – Category that the tool belongs to. Some of the examples are Backdoor Tool, Pentest Tool, Network Scanner, and Network Sniffer.
+ **Tool Name** – The name of the potentially suspicous tool.
+ **Script Path** – The path to the executed script that generated the finding.
+ **Threat File Path** – The suspicious path for which the threat intelligence details were found.
+ **Service Name** – The name of the security service that has been disabled.
+ **Module Name** – The name of the module that is loaded into the kernel.
+ **Module SHA256** – The SHA256 hash of the module.
+ **Module File Path** – The path to the module loaded into the kernel.
## EBS volumes scan details
**Note**
This section is applicable to findings when you turn on the GuardDuty-initiated malware scan in [Malware Protection for EC2](malware-protection.md).
The EBS volumes scan provides details about the EBS volume attached to the potentially compromised EC2 instance or container workload.
+ **Scan ID** – The identifier of the malware scan.
+ **Scan started at** – The date and time when the malware scan started.
+ **Scan completed at** – The date and time when the malware scan completed.
+ **Trigger Finding ID** – The finding ID of the GuardDuty finding that initiated this malware scan.
+ **Sources** – The potential values are `Bitdefender` and `Amazon`.
For more information about the scan engine used to detect malware, see [GuardDuty malware detection scan engine](guardduty-malware-detection-scan-engine.md).
+ **Scan detections** – The complete view of details and results for each malware scan.
+ **Scanned item count** – The total number of scanned files. It provides details such as `totalGb`, `files`, and `volumes`.
+ **Threats detected item count** – The total number of malicious `files` detected during the scan.
+ **Highest severity threat details** – The details of the highest severity threat detected during the scan and the number of malicious files. It provides details such as `severity`, `threatName`, and `count`.
+ **Threats detected by Name** – The container element grouping threats of all severity levels. It provides details such as `itemCount`, `uniqueThreatNameCount`, `shortened`, and `threatNames`.
## Malware Protection for EC2 finding details
**Note**
This section is applicable to findings when you turn on the GuardDuty-initiated malware scan in [Malware Protection for EC2](malware-protection.md).
When the Malware Protection for EC2 scan detects malware, you can view the scan details by selecting the corresponding finding on the **Findings** page in the [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) console. The severity of your Malware Protection for EC2 finding depends on the severity of the GuardDuty finding.
The following information is available under the **Threats detected** section in the details panel.
+ **Name** – The name of the threat, obtained by grouping the files by detection.
+ **Severity** – The severity of the threat detected.
+ **Hash** – The SHA-256 of the file.
+ **File path** – The location of the malicious file in the EBS volume.
+ **File name** – The name of the file in which the threat was detected.
+ **Volume ARN** – The ARN of the scanned EBS volumes.
The following information is available under the **Malware scan details** section in the details panel.
+ **Scan ID** – The scan ID of the malware scan.
+ **Scan started at** – The date and time when the scan started.
+ **Scan completed at** – The date and time when the scan completed.
+ **Files scanned** – The total number of scanned files and directories.
+ **Total GB scanned** – The amount of storage scanned during the process.
+ **Trigger finding ID** – The finding ID of the GuardDuty finding that initiated this malware scan.
+ The following information is available under the **Volume details** section in the details panel.
+ **Volume ARN** – The Amazon Resource Name (ARN) of the volume.
+ **SnapshotARN** – The ARN of the snapshot of the EBS volume.
+ **Status** – The scan status of the volume, such as `Running`, `Skipped`, and `Completed`.
+ **Encryption type** – The type of encryption used to encrypt the volume. For example, `CMCMK`.
+ **Device name** – The name of the device. For example, `/dev/xvda`.
## Malware Protection for S3 finding details
The following malware scan details are available when you enable both GuardDuty and Malware Protection for S3 in your AWS account:
+ **Threats** – A list of threats detected during the malware scan.
**Multiple potential threats in archive files**
If you have an archive file with potentially multiple threats in it, Malware Protection for S3 reports only the first detected threat. After this, the scan status is marked as complete. GuardDuty generates the associated finding type and also sends EventBridge events that it generates. For more information about monitoring the Amazon S3 object scans using the EventBridge events, see the sample notification schema for **THREATS\$1FOUND** in [S3 object scan result](monitor-with-eventbridge-s3-malware-protection.md#s3-object-scan-status-malware-protection-s3-ev).
+ **Item path** – A list of nested item path and hash details of the scanned S3 object.
+ **Nested item path** – Item path of the scanned S3 object where the threat was detected.
The value of this field is available only if the top-level object is an archive and if threat is detected inside an archive.
+ **Hash** – Hash of the threat detected in this finding.
+ **Sources** – The potential values are `Bitdefender` and `Amazon`.
For more information about the scan engine used to detect malware, see [GuardDuty malware detection scan engine](guardduty-malware-detection-scan-engine.md).
## Action
A finding's **Action** gives details about the type of activity that triggered the finding. The information available varies based on action type.
**Action type** – The finding activity type. This value can be **NETWORK\$1CONNECTION**, **PORT\$1PROBE**, **DNS\$1REQUEST**, **AWS\$1API\$1CALL**, or **RDS\$1LOGIN\$1ATTEMPT**. The information available varies based on action type:
+ **NETWORK\$1CONNECTION** – Indicates that network traffic was exchanged between the identified EC2 instance and the remote host. This action type has the following additional information:
+ **Connection direction** – The network connection direction observed in the activity that prompted GuardDuty to generate the finding. The values can be one of the following:
+ **INBOUND** – Indicates that a remote host initiated a connection to a local port on the identified EC2 instance in your account.
+ **OUTBOUND** – Indicates that the identified EC2 instance initiated a connection to a remote host.
+ **UNKNOWN** – Indicates that GuardDuty could not determine the direction of the connection.
+ **Protocol** – The network connection protocol observed in the activity that prompted GuardDuty to generate the finding.
+ **Local IP** – The original source IP address of the traffic that triggered the finding. This info can be used to distinguish between the IP address of an intermediate layer through which traffic flows, and the original source IP address of the traffic that triggered the finding. For example the IP address of an EKS pod as opposed to the IP address of the instance on which the EKS pod is running.
+ **Blocked** – Indicates whether the targeted port is blocked.
+ **PORT\$1PROBE** – Indicates that a remote host probed the identified EC2 instance on multiple open ports. This action type has the following additional information:
+ **Local IP** – The original source IP address of the traffic that triggered the finding. This info can be used to distinguish between the IP address of an intermediate layer through which traffic flows, and the original source IP address of the traffic that triggered the finding. For example the IP address of an EKS pod as opposed to the IP address of the instance on which the EKS pod is running.
+ **Blocked** – Indicates whether the targeted port is blocked.
+ **DNS\$1REQUEST** – Indicates that the identified EC2 instance queried a domain name. This action type has the following additional information:
+ **Protocol** – The network connection protocol observed in the activity that prompted GuardDuty to generate the finding.
+ **Blocked** – Indicates whether the targeted port is blocked.
+ **AWS\$1API\$1CALL** – Indicates that an AWS API was invoked. This action type has the following additional information:
+ **API** – The name of the API operation that was invoked and thus prompted GuardDuty to generate this finding.
**Note**
These operations can also include non-API events captured by AWS CloudTrail. For more information, see [Non-API events captured by CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-non-api-events.html).
+ **User Agent** – The user agent that made the API request. This value tells you whether the call was made from the AWS Management Console, an AWS service, the AWS SDKs, or the AWS CLI.
+ **ERROR CODE** – If the finding was triggered by a failed API call this displays the error code for that call.
+ **Service name** – The DNS name of the service that attempted to make the API call that triggered the finding.
+ **RDS\$1LOGIN\$1ATTEMPT** – Indicates that a login attempt was made to the potentially compromised database from a remote IP address.
+ **IP address** – The remote IP address that was used to make the potentially suspicious login attempt.
## Actor or Target
A finding has an **Actor** section if the **Resource role** was `TARGET`. This indicates that your resource was targeted by suspicious activity, and the **Actor** section contains details about the entity that targeted your resource.
A finding has a **Target** section if the **Resource role** was `ACTOR`. This indicates that your resource was involved in suspicious activity against a remote host, and this section contains information on the IP or domain that your resource targeted.
The information available in the **Actor** or **Target** section can include the following:
+ **Affiliated** – Details about whether the AWS account of the remote API caller is related to your GuardDuty environment. If this value is `true`, the API caller is affiliated to your account in some manner; if `false`, the API caller is from outside your environment.
+ **Remote Account ID** – The account ID that owns the outbound IP address that was used to access the resource at the final network.
+ **IP address** – The IP address involved in the activity that prompted GuardDuty to generate the finding.
+ **Location** – Location information for the IP address involved in the activity that prompted GuardDuty to generate the finding.
+ **Organization** – ISP organization information of the IP address involved in the activity that prompted GuardDuty to generate the finding.
+ **Port** – The port number involved in the activity that prompted GuardDuty to generate the finding.
+ **Domain** – The domain involved in the activity that prompted GuardDuty to generate the finding.
+ **Domain with suffix** – The second- and top-level domain involved in an activity that potentially prompted GuardDuty to generate the finding. For a list of top-level and second-level domains, see [public suffix list](https://publicsuffix.org/).
## Geolocation details
GuardDuty determines the location and network of requests by using MaxMind GeoIP databases. MaxMind reports very high accuracy of their data at country level, although accuracy varies according to factors such as country and type of IP address.
For more information about MaxMind, see [MaxMind IP Geolocation](https://support.maxmind.com/hc/en-us/sections/4407519834267-IP-Geolocation). If you believe any of the GeoIP data incorrect, submit a correction request to MaxMind at [MaxMind Correct GeoIP2 Data](https://support.maxmind.com/hc/en-us/articles/4408252036123-GeoIP-Correction).
## Additional information
All findings have an **Additional information** section that can include the following information:
+ **Threat list name** – The name of the threat list that includes the IP address or the domain name involved in the activity that prompted GuardDuty to generate the finding.
+ **Sample** – A true or false value that indicates whether this is a sample finding.
+ **Archived** – A true or false value that indicates whether this is finding has been archived.
+ **Unusual** – Activity details that were not observed historically. These can include an unusual (previously not observed) user, location, time, bucket, login behavior, or ASN Org.
+ **Unusual protocol** – The network connection protocol involved in the activity that prompted GuardDuty to generate the finding.
+ **Agent details** – Details about the security agent that is currently deployed on the EKS cluster in your AWS account. This is only applicable to EKS Runtime Monitoring finding types.
+ **Agent version** – The version of the GuardDuty security agent.
+ **Agent Id** – The unique identifier of the GuardDuty security agent.
## Evidence
Findings based on threat intelligence have an **Evidence** section that includes the following information:
+ **Threat intelligence details** – The name of the threat list on which the recognized `Threat name` appears.
+ **Threat name** – The name of the malware family or other identifier that is associated with the threat.
+ **Threat file SHA256** – SHA256 of the file that generated the finding.
## Anomalous behavior
Findings types that end in **AnomalousBehavior** indicate that the finding was generated by the GuardDuty anomaly detection machine learning (ML) model. The ML model evaluates all API requests to your account and identifies anomalous events that are associated with tactics used by adversaries. The ML model tracks various factors of the API request, such as the user that made the request, the location the request was made from, and the specific API that was requested.
Details about which factors of the API request are unusual for the CloudTrail user identity that invoked the request can be found in the finding details. The identities are defined by the [ CloudTrail userIdentity Element](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-user-identity.html), and the possible values are: `Root`, `IAMUser`, `AssumedRole`, `FederatedUser`, `AWSAccount`, or `AWSService`.
In addition to the details available for all GuardDuty findings that are associated with API activity, **AnomalousBehavior** findings have additional details that are outlined in the following section. These details can be viewed in the console and are also available in the finding's JSON.
+ **Anomalous APIs** – A list of API requests that were invoked by the user identity in proximity to the primary API request associated with the finding. This pane further breaks down the details of the API event in the following ways.
+ The first API listed is the primary API, which is the API request associated with the highest-risk observed activity. This is the API that triggered the finding and correlates to the attack stage of the finding type. This is also the API that is detailed under the **Action** section in the console, and in the finding's JSON.
+ Any other APIs listed are additional anomalous APIs from the listed user identity observed in proximity to the primary API. If there is only one API on the list, the ML model did not identify any additional API requests from that user identity as anomalous.
+ The list of APIs is divided based on whether an API was **successfully called**, or if the API was unsuccessfully called, meaning an error response was received. The type of error response received is listed above each unsuccessfully called API. Possible error response types are: `access denied`, `access denied exception`, `auth failure`, `instance limit exceeded`, `invalid permission - duplicate`, `invalid permission - not found`, and `operation not permitted`.
+ APIs are categorized by their associated service.
+ For more context, choose **Historical APIs** to view the details about the top APIs, to a maximum of 20, usually seen for both the user identity and all users within the account. The APIs are marked **Rare (less than once a month)**, **Infrequent (a few times a month)**, or **Frequent (daily to weekly)**, depending on how often they are used within your account.
+ **Unusual Behavior (Account)** – This section gives additional details about the profiled behavior for your account.
**Profiled behavior**
GuardDuty continually learns about the activities within your account based on delivered events. These activities and their observed frequency is known as profiled behavior.
The information tracked in this panel includes:
+ **ASN Org** – The Autonomous System Number (ASN) org that the anomalous API call was made from.
+ **User Name** – The name of the user that made the anomalous API call.
+ **User Agent**– The user agent used to make the anomalous API call. The user agent is the method used to make the call such as `aws-cli` or `Botocore`.
+ **User Type** – The type of user that made the anomalous API call. Possible values are `AWS_SERVICE`, `ASSUMED_ROLE`, `IAM_USER`, or `ROLE`.
+ **Bucket** – The name of the S3 bucket that is being accessed.
+ **Unusual Behavior (User Identity)** – This section gives additional details about the profiled behavior for the **User Identity** involved with the finding. When a behavior isn't identified as historical, this means the GuardDuty ML model hasn't previously seen this user identity making this API call in this way within the training period. The following additional details about the **User Identity** are available:
+ **ASN Org** – The ASN Org the anomalous API call was made from.
+ **User Agent**– The user agent used to make the anomalous API call. The user agent is the method used to make the call such as `aws-cli` or `Botocore`.
+ **Bucket** – The name of the S3 bucket that is being accessed.
+ **Unusual Behavior (Bucket)** – This section gives additional details about the profiled behavior for the S3 bucket associated with the finding. When a behavior isn't identified as historical, this means the GuardDuty ML model hasn't previously seen API calls made to this bucket in this way within the training period. The information tracked in this section includes:
+ **ASN Org** – The ASN Org the anomalous API call was made from.
+ **User Name** – The name of the user that made the anomalous API call.
+ **User Agent**– The user agent used to make the anomalous API call. The user agent is the method used to make the call such as `aws-cli` or `Botocore`.
+ **User Type** – The type of user that made the anomalous API call. Possible values are `AWS_SERVICE`, `ASSUMED_ROLE`, `IAM_USER`, or `ROLE`.
**Note**
For more context on historical behaviors, choose **Historical behavior** in either **Unusual behavior (Account)**, **User ID**, or **Bucket** section to view details about the expected behavior in your account for each of the following categories: **Rare (less than once a month)**, **Infrequent (a few times a month)**, or **Frequent (daily to weekly)**, depending on how often they are used within your account.
+ **Unusual Behavior (Database)** – This section provides additional details about the profiled behavior for the database instance associated with the finding. When a behavior isn't identified as historical, it means that the GuardDuty ML model hasn't previously seen a login attempt made to this database instance in this way within the training period. The information tracked for this section in the finding panel includes:
+ **User name** – The user name used to make the anomalous login attempt.
+ **ASN Org** – The ASN Org that the anomalous login attempt was made from.
+ **Application name** – The application name used to make the anomalous login attempt.
+ **Database name** – The name of the database instance involved in the anomalous login attempt.
The **Historical behavior** section provides more context on the previously observed **User names**, **ASN Orgs**, **Application names**, and **Database names** for the associated database. Each unique value has an associated count representing the number of times this value was observed in a successful login event.
+ **Unusual behavior (Account Kubernetes cluster, Kubernetes namespace, and Kubernetes username)** – This section provides additional details about the profiled behavior for the Kubernetes cluster and namespace associated with the finding. When a behavior isn't identified as historical, it means that the GuardDuty ML model hasn't previously observed this account, cluster, namespace, or username in this way. The information tracked for this section in the finding panel includes:
+ **Username** – The user that called the Kubernetes API associated with the finding.
+ **Impersonated Username** – The user being impersonated by `username`.
+ **Namespace** – The Kubernetes namespace within the Amazon EKS cluster where the action occurred.
+ **User Agent** – The user agent associated with the Kubernetes API call. The user agent is the method used to make the call such as `kubectl`.
+ **API** – The Kubernetes API called by `username` within the Amazon EKS cluster.
+ **ASN Information** – The ASN information, such as Organization and ISP, associated with the IP address of the user making this call.
+ **Day of week** – The day of the week when the Kubernetes API call was made.
+ **Permission** – The Kubernetes verb and resource being checked for access to indicate whether or not the `username` can use the Kubernetes API.
+ **Service Account Name** – The service account associated with the Kubernetes workload that provides an identity to the workload.
+ **Registry** – The container registry associated with the container image that is deployed in the Kubernetes workload.
+ **Image** – The container image, without the associated tags and digest, that is deployed in the Kubernetes workload.
+ **Image Prefix Config** – The image prefix with the container and workload security configuration enabled, such as `hostNetwork` or `privileged`, for the container using the image.
+ **Subject Name** – The subjects, such as a `user`, `group`, or `serviceAccountName` that is bound to a reference role in a `RoleBinding` or `ClusterRoleBinding`.
+ **Role Name** – The name of the role that is involved in creation or modification of roles or the `roleBinding` API.
### S3 volume-based anomalies
This section details the contextual information for S3 volume-based anomalies. The volume-based finding ([Exfiltration:S3/AnomalousBehavior](guardduty_finding-types-s3.md#exfiltration-s3-anomalousbehavior)) monitors for unusual numbers of S3 API calls made to the S3 buckets by users, indicating potential data exfiltration. The following S3 API calls are monitored for volume-based anomaly detection.
+ `GetObject`
+ `CopyObject.Read`
+ `SelectObjectContent`
The following metrics would help to build a baseline of usual behavior when an IAM entity accesses an S3 bucket. To detect data exfiltration, volume-based anomaly detection finding evaluates all the activities against the usual behavioral baseline. Choose **Historical behavior** in the **Unusual behavior (User Identity)**, **Observed Volume (User Identity)**, and **Observed Volume (Bucket)** sections to view the following metrics, respectively.
+ Number of `s3-api-name` API calls invoked by the IAM user or IAM role (depends on which one was issued) associated with the affected S3 bucket over the past 24 hours.
+ Number of `s3-api-name` API calls invoked by the IAM user or IAM role (depends on which one was issued) associated with all S3 buckets over the past 24 hours.
+ Number of `s3-api-name` API calls across all IAM user or IAM role (depends on which one was issued) associated with the affected S3 bucket over the past 24 hours.
### RDS login activity-based anomalies
This section details the count of login attempts performed by the unusual actor and is grouped by the result of the login attempts. The [RDS Protection finding types](findings-rds-protection.md) identify anomalous behavior by monitoring the login events for unusual patterns of `successfulLoginCount`, `failedLoginCount`, and `incompleteConnectionCount`.
+ **successfulLoginCount** – This counter represents the sum of successful connections (correct combination of login attributes) made to the database instance by the unusual actor. Login attributes include user name, password, and database name.
+ **failedLoginCount** – This counter represents the sum of failed (unsuccessful) login attempts made to establish a connection to the database instance. This indicates that one or more attributes of the login combination, such as user name, password, or database name were incorrect.
+ **incompleteConnectionCount** – This counter represents the number of connection attempts that can't be classified as successful or failed. These connections are closed before the database provides a response. For example, port scanning where the database port is connected but no piece of information is sent to the database, or the connection was aborted before the login completed in a successful or failed attempt.
# GuardDuty finding aggregation
GuardDuty updates the generated findings dynamically. If GuardDuty detects a new activity related to the same security issue, then instead of creating a new finding, GuardDuty will update the original finding with the latest details. This behavior allows you to identify any ongoing issues, without the need to look through multiple similar reports, and reduces the overall volume of findings for known security issues.
For example, for UnauthorizedAccess:EC2/SSHBruteForce finding, multiple access attempts against your instance will be aggregated to the same finding ID, increasing the **Count** number in the finding's details. This is because that finding represents a single security issue with the instance indicating that the SSH port on the instance is not properly secured against this type of activity. However, if GuardDuty detects SSH access activity targeting a new instance in your environment, it will create a new finding with a unique finding ID to alert you to the fact that there is a security issue associated with the new resource.
When a finding is aggregated, it is updated with information from the latest occurrence of that activity. This means that in the above example, if your instance is the target of a brute force attempt from a new actor, the finding details will be updated to reflect the remote IP of the most recent source and older information will be replaced. Complete information about individual activity attempts will still be available in your CloudTrail logs or VPC Flow Logs.
The criteria that alert GuardDuty to generate a new finding instead of aggregating an existing one is dependent on the finding type. The aggregation criteria for each finding type is determined by our security engineers to provide an overview of distinct security issues within your account.
When GuardDuty generates an attack sequence finding type in your account, the finding will be aggregated only when you GuardDuty identifies the similar signals in the same sequence in your account. Otherwise, GuardDuty will generate another attack sequence.