Amazon GuardDuty

(1)

Amazon GuardDuty

Amazon GuardDuty User Guide

(2)

Amazon GuardDuty: Amazon GuardDuty User Guide

Amazon's trademarks and trade dress may not be used in connection with any product or service that is not Amazon's, in any manner that is likely to cause confusion among customers, or in any manner that disparages or discredits Amazon. All other trademarks not owned by Amazon are the property of their respective owners, who may or may not be aﬃliated with, connected to, or sponsored by Amazon.

(3)

What is Amazon GuardDuty?

Amazon GuardDuty is a continuous security monitoring service that analyzes and processes the following Data sources (p. ): VPC Flow Logs, AWS CloudTrail management event logs, CloudTrail S3 data event logs, and DNS logs. It uses threat intelligence feeds, such as lists of malicious IP addresses and domains, and machine learning to identify unexpected and potentially unauthorized and malicious activity within your AWS environment. This can include issues like escalations of privileges, uses of exposed credentials, or communication with malicious IP addresses, or domains. For example, GuardDuty can detect compromised EC2 instances serving malware or mining bitcoin. It also monitors AWS account access behavior for signs of compromise, such as unauthorized infrastructure deployments, like instances deployed in a Region that has never been used, or unusual API calls, like a password policy change to reduce password strength.

GuardDuty informs you of the status of your AWS environment by producing security ﬁndings (p. 13) that you can view in the GuardDuty console or through Amazon CloudWatch events (p. 107).

Pricing for GuardDuty

For information about GuardDuty pricing, see Amazon GuardDuty Pricing.

Accessing GuardDuty

You can work with GuardDuty in any of the following ways:

GuardDuty Console

https://console.aws.amazon.com/guardduty

The console is a browser-based interface to access and use GuardDuty.

AWS SDKs

AWS provides software development kits (SDKs) that consist of libraries and sample code for various programming languages and platforms (Java, Python, Ruby, .NET, iOS, Android, and more). The SDKs provide a convenient way to create programmatic access to GuardDuty. For information about the AWS SDKs, including how to download and install them, see Tools for Amazon Web Services.

GuardDuty HTTPS API

You can access GuardDuty and AWS programmatically by using the GuardDuty HTTPS API, which lets you issue HTTPS requests directly to the service. For more information, see the GuardDuty API reference.

(10)

Before you begin

Getting started with GuardDuty

This tutorial provides a hands-on introduction to GuardDuty. The minimum requirements for enabling GuardDuty as a standalone account or as a GuardDuty administrator with AWS Organizations are covered in Step 1. Steps 2 through 5 cover using additional features recommended by GuardDuty to get the most out of your ﬁndings.

Topics

• Before you begin (p. 2)

• Step 1: Enable Amazon GuardDuty (p. 3)

• Step 2: Generate sample ﬁndings and explore basic operations (p. 4)

• Step 3: Conﬁgure GuardDuty ﬁndings export to an S3 bucket (p. 5)

• Step 4: Set up GuardDuty ﬁnding alerts through SNS (p. 6)

• Next steps (p. 7)

Before you begin

GuardDuty is a monitoring service that analyzes AWS CloudTrail management and Amazon S3 data events, VPC Flow Logs, and DNS logs to generate security ﬁndings for your account. Once GuardDuty is enabled, it starts monitoring your environment immediately. GuardDuty can be disabled at any time to stop it from processing all AWS CloudTrail events, VPC Flow Logs, and DNS logs.

NoteYou do not need to enable AWS CloudTrail, Amazon S3 data events, VPC Flow Logs, and DNS logs before starting GuardDuty. Amazon GuardDuty pulls independent streams of data directly from those services. For more information see How Amazon GuardDuty uses its data sources (p. 10).

Note the following about enabling GuardDuty:

• GuardDuty is a Regional service, meaning any of the conﬁguration procedures you follow on this page must be repeated in each region that you want to monitor with GuardDuty.

We highly recommend that you enable GuardDuty in all supported AWS Regions. This enables GuardDuty to generate ﬁndings about unauthorized or unusual activity even in Regions that you are not actively using. This also enables GuardDuty to monitor AWS CloudTrail events for global AWS services such as IAM. If GuardDuty is not enabled in all supported Regions, its ability to detect activity that involves global services is reduced. For a full list of regions in which GuardDuty is supported see Regions and endpoints (p. 194).

• Any user with administrator privileges in an AWS Account can enable GuardDuty, however, following the security best practice of least privilege, it is recommended that you create an IAM user, role, or group to manage GuardDuty speciﬁcally. For information on the permissions required to enable GuardDuty see Permissions required to enable GuardDuty (p. 160).

• When you enable GuardDuty for the ﬁrst time in any region, it creates a service-linked role for your account called AWSServiceRoleForAmazonGuardDuty. This role includes the permissions and the trust policies that allow GuardDuty to consume and analyze events directly from AWS CloudTrail, VPC Flow logs, and DNS logs in order to generate security ﬁndings. For more information, see Service- linked role permissions for GuardDuty (p. 167). For more information about service-linked roles, see Using service-linked roles.

(11)

Step 1: Enable Amazon GuardDuty

• When you enable GuardDuty for the ﬁrst time in any Region your AWS account is automatically enrolled in a 30-day GuardDuty free trial for that Region.

Step 1: Enable Amazon GuardDuty

The ﬁrst step to using GuardDuty is to enable it in your account. Once enabled, GuardDuty will immediately begin to monitor for security threats in the current region.

If you want to manage GuardDuty ﬁndings for other accounts within your organization as a GuardDuty administrator, you must add member accounts and enable GuardDuty for them as well. Choose an option to learn how to enable GuardDuty for your environment.

Standalone account environment

1. Open the GuardDuty console at https://console.aws.amazon.com/guardduty/

2. Choose Get Started.

3. Choose Enable GuardDuty.

Multi-account environment Important

As prerequisites for this process, you must be in the same organization as all the accounts you wish to manage, and have access to the AWS Organizations management account in order to delegate an administrator for GuardDuty within your organization. Additional permissions may be required to delegate an administrator, for more info see Permissions required to designate a delegated administrator (p. 127).

To delegate an Administrator for GuardDuty

1. Log in to the AWS Organizations management account

2. Open the GuardDuty console at https://console.aws.amazon.com/guardduty/.

Is GuardDuty already enabled in your account?

• If GuardDuty is not already enabled, you can select Get Started and then designate a GuardDuty delegated administrator on the Welcome to GuardDuty page.

• If GuardDuty is enabled, you can designate a GuardDuty delegated administrator on the Settings page.

3. Enter the twelve-digit AWS account ID of the account that you want to designate as the GuardDuty delegated administrator for the organization and choose Delegate.

NoteIf GuardDuty is not already enabled, designating a delegated administrator will enable GuardDuty for that account in your current Region.

To add member accounts

This procedure covers adding members accounts to a GuardDuty delegated administrator account through AWS Organizations. There is also the option to add members by invitation. To learn more about both methods for associating members in GuardDuty see Managing multiple accounts in Amazon GuardDuty (p. 124).

1. Log in to the delegated administrator account

2. Open the GuardDuty console at https://console.aws.amazon.com/guardduty/.

3. In the navigation panel, choose Settings, and then choose Accounts.

(12)

Step 2: Generate sample ﬁndings and explore basic operations

The accounts table displays all of the accounts in the organization.

4. Choose the accounts that you want to add as members by selecting the box next to the account ID. Then from the Action menu select Add member.

TipYou can automate adding new accounts as members by turning on the Auto-enable feature, however, this only applies to accounts that join your organization after the feature has been enabled.

Step 2: Generate sample ﬁndings and explore basic operations

When GuardDuty discovers a security issue it generates a finding. A GuardDuty finding is a data set containing details relating to that unique security issue. The finding's details can be used to help you investigate the issue.

GuardDuty supports generating sample findings with placeholder values, which can be used to test GuardDuty functionality and familiarize yourself with findings before needing to respond to a real security issue discovered by GuardDuty. Follow the guide below to generate sample findings for each finding type available in GuardDuty, for additional ways to generate sample findings, including generating a simulated security event within your account, see Sample findings (p. 21).

To create and explore sample ﬁndings 1. In the navigation pane, choose Settings.

2. On the Settings page, under Sample ﬁndings, choose Generate sample ﬁndings.

3. In the navigation pane, choose Findings. The sample findings are displayed on the Current findings page with the prefix [SAMPLE].

4. Select a ﬁnding from the list to display details for the ﬁnding.

• You can review the different information fields available in the finding details pane. Different types of findings can have different fields. For more information on the available fields across all finding types see Finding details (p. 13). From the details pane you can take the following actions:

• Select the finding ID at the top of the pane to open the complete JSON details for the finding. The complete JSON file can also be downloaded from this panel. The JSON contains some additional information not included in the console view and is the format that can be ingested by other tools and services.

• View the Resource aﬀected section. In a real ﬁnding the information here will help you identify a resource in your account that should be investigated and will include links to the appropriate AWS console for actionable resources.

• Select the + or - looking glass icons to create an inclusive or exclusive filter for that detail. For more information on finding filters see Filtering findings (p. 91)

5. Archive all your sample ﬁndings

a. Select all ﬁndings by selection the check box at the top of the list.

b. Deselect any ﬁndings you wish to keep.

c. Select the Actions menu and then select Archive to hide the sample ﬁndings.

Note

To view the archived ﬁndings select Current and then Archived to switch the ﬁndings view.

(13)

Step 3: Conﬁgure GuardDuty ﬁndings export to an S3 bucket

GuardDuty recommends setting up findings export, which allows you to export your findings to an S3 bucket for indefinite storage beyond the GuardDuty 90 day storage limit. This allows you to keep records of findings or track issues within your environment over time. The process outlined here walks you through setting up a new S3 bucket and creating a new KMS key to encrypt findings from within the console, for more information about this, including how to use your own existing bucket or a bucket in another account, see Exporting findings (p. 101).

To conﬁgure S3 export

1. In the navigation pane, choose Settings.

2. Under Findings export options select Conﬁgure now.

3. Select New bucket.

• Enter a unique name for your bucket.

4. To encrypt ﬁndings, you will need a KMS key with a policy that allows GuardDuty to use it. You can attach the policy outlined in the following section to an existing key or create a new KMS key from the console. The key must be in the same Region as your S3 bucket. For more information on KMS keys see create a key.

To create a new key, Select Go to KMS console to create a new key to open the KMS console in a new tab and follow these instructions:

a. In the KMS console select Create key.

b. Choose Symmetric then choose Next.

c. Give your key an alias and choose Next.

d. Choose Next and then Next again to accept the default administration and usage permissions.

e. In the Review and edit key policy pane add the following statement to the "Statements":

section.

Replace Region with the Region that the KMS key is in. Replace 111122223333 with the AWS account number of the account that owns the bucket. Replace KMSKeyId with the key ID of the key that you chose for encryption and replace SourceDetectorID with the source account's GuardDuty detector ID for the current Region.

This statement allows GuardDuty to use only the key that you changed the policy for. When editing the key policy make sure your JSON syntax is valid, if you add the statement before the ﬁnal statement you must add a comma after the closing bracket.

{

"Sid": "AllowGuardDutyKey", "Effect": "Allow",

"Principal": {

"Service": "guardduty.amazonaws.com"

},

"Action": "kms:GenerateDataKey",

"Resource": "arn:aws:kms:Region:111122223333:key/KMSKeyId", "Condition": {

"StringEquals": {

"aws:SourceAccount": "111122223333", "aws:SourceArn":

"arn:aws:guardduty:Region:111122223333:detector/SourceDetectorID"

} }

(14)

Step 4: Set up GuardDuty ﬁnding alerts through SNS

}

5. Return to the GuardDuty console tab where you were conﬁguring ﬁndings export.

• Refresh the console by selecting the Refresh icon next to S3 bucket, now choose the key you just created from the Key alias list then choose Save.

6. (Optional) you can test your new export settings by generating sample ﬁndings with the process in Step 2. The new sample ﬁndings will appear within 5 minutes as entries in the S3 bucket created by GuardDuty in step 3.

Step 4: Set up GuardDuty ﬁnding alerts through SNS

GuardDuty integrates with Amazon EventBridge which can be used to send findings data to other applications and services for processing. With EventBridge you can use GuardDuty findings to trigger automatic responses to your findings by connecting finding events to targets such as AWS Lambda functions, Amazon EC2 Systems Manager automation, Amazon Simple Notification Service (SNS) and more.

In this example you will create an SNS topic to be the target of an EventBridge rule, then you'll use EventBridge to create a rule that captures findings data from GuardDuty. The resulting rule forwards the finding details to an email address. To learn how you can send findings to Slack or Chime, as well as modify the types of findings alerts are sent for, see Setup an Amazon SNS topic and endpoint (p. 109).

To create an SNS topic for your ﬁndings alerts

1. Sign in to the Amazon SNS console at https://console.aws.amazon.com/sns/v3/home.

2. Select Topics from the navigation pane and then Create Topic.

3. In the Create topic section, select Standard. Next, enter a Topic name, for example GuardDuty.

Other details are optional.

4. Choose Create Topic. The Topic details for your new topic will open.

5. In the Subscriptions section select Create Subscription.

6. From the Protocol menu, select Email.

a. In the Endpoint field add the email address you would like to receive notifications at. You will be required to confirm your subscription through your email client after creating it.

b. Choose Create Subscription.

7. Check for a subscription message in your inbox and choose Conﬁrm Subscription.

NoteYou can check email conﬁrmation status by selecting the subscription name from the Topics list in the SNS console.

To create an EventBridge rule to capture GuardDuty ﬁndings and format them 1. Open the EventBridge console at https://console.aws.amazon.com/events/.

2. Select Rules from the navigation pane and then Create Rule.

a. Choose Event Pattern and then Pre-deﬁned pattern by service.

b. From the Service provider menu, choose AWS.

c. From the Service name menu, choose GuardDuty.

d. From the Event Type menu, choose GuardDuty Finding.

(15)

Next steps

3. In the Select targets pane, from the Target menu, choose SNS Topic.

4. For Topic select the name of the SNS topic you created earlier.

5. Expand Conﬁgure Input and Choose Input transformer. The Input transformer code will allow you to format the JSON ﬁnding data sent from GuardDuty into an easy human-readable message.

6. Copy the following code and paste it into the Input Path ﬁeld.

{ "severity": "$.detail.severity", "Finding_ID": "$.detail.id", "Finding_Type": "$.detail.type", "region": "$.region",

"Finding_description": "$.detail.description"

}

7. Copy the following code and paste it into the Input Template ﬁeld to format the email.

"You have a severity <severity> GuardDuty finding type <Finding_Type> in the <region>

region."

"Finding Description:"

"<Finding_description>. "

"For more details open the GuardDuty console at https://console.aws.amazon.com/

guardduty/home?region=<region>#/findings?search=id%3D<Finding_ID>"

8. Choose Create to ﬁnalize your rule.

9. (Optional) you can test your new rule by generating sample ﬁndings with the process in Step 2. You will receive an email for each sample ﬁnding generated.

Next steps

As you continue to use GuardDuty, you will come to understand the types of findings that are relevant to your environment. Whenever you receive a new finding, you can find information, including remediation recommendations about that finding, by selecting Learn more from the finding description in the finding details pane, or by searching for the finding name on the Finding types (p. 26) page.

The following features will help you tune GuardDuty so that it can provide the most relevant ﬁndings for your AWS environment:

• To easily sort findings based on specific criteria, such as instance ID, account ID, S3 bucket name, and more, you can create and save filters within GuardDuty. For more information see Filtering findings (p. 91).

• If you are receiving findings for expected behavior in your environment, you can automatically archive findings based on criteria you define with suppression rules (p. 94).

• To prevent ﬁndings from being generated from a subset of trusted IPs, or to have GuardDuty monitor IPs outside it's normal monitoring scope you can set up Trusted IP and threat lists (p. 97).

(16)

Concepts and terminology

As you get started with Amazon GuardDuty, you can beneﬁt from learning about its key concepts.

Account

A standard Amazon Web Services (AWS) account that contains your AWS resources. You can sign in to AWS with your account and enable GuardDuty.

You can also invite other accounts to enable GuardDuty and become associated with your AWS account in GuardDuty. If your invitations are accepted, your account is designated as the administrator GuardDuty account, and the added accounts become your member accounts. You can then view and manage those accounts' GuardDuty ﬁndings on their behalf.

Users of the administrator account can conﬁgure GuardDuty as well as view and manage GuardDuty ﬁndings for their own account and all of their member accounts. You can have up to 5000 member accounts in GuardDuty.

Users of member accounts can configure GuardDuty as well as view and manage GuardDuty findings in their account (either through the GuardDuty management console or GuardDuty API). Users of member accounts can't view or manage findings in other members' accounts.

An AWS account can't be a GuardDuty administrator and member account at the same time. An AWS account can accept only one membership invitation. Accepting a membership invitation is optional.

For more information, see Managing multiple accounts in Amazon GuardDuty (p. 124).

Detector

All GuardDuty ﬁndings are associated with a detector, which is an object that represents the

GuardDuty service. The detector is a regional entity, and a unique detector is required in each region GuardDuty operates in. When you enable GuardDuty in a region a new detector with a unique 32 alphanumeric detector ID is generated in that region. The detector ID format looks like this:

12abc34d567e8fa901bc2d34e56789f0

You can ﬁnd your detector ID for your current region in the console from the Settings pane, or programmatically using the ListDetectors API.

NoteIn multiple account environments all ﬁndings for member accounts roll up to the administrator account's detector.

Some GuardDuty functionality is configured through the detector, such as configuring CloudWatch Events notification frequency and the enabling or disabling of optional data sources for GuardDuty to process.

Data source

The origin or location of a set of data. To detect unauthorized and unexpected activity in your AWS environment, GuardDuty analyzes and processes data from AWS CloudTrail event logs, VPC Flow Logs, and DNS logs. For more information, see How Amazon GuardDuty uses its data sources (p. 10).

Finding

A potential security issue discovered by GuardDuty. For more information, see Understanding Amazon GuardDuty ﬁndings (p. 13).

(17)

Findings are displayed in the GuardDuty console and contain a detailed description of the security issue. You can also retrieve your generated ﬁndings by calling the GetFindings and ListFindings API operations.

You can also see your GuardDuty findings through Amazon CloudWatch events. GuardDuty sends findings to Amazon CloudWatch via HTTPS protocol. For more information, see Creating custom responses to GuardDuty findings with Amazon CloudWatch Events (p. 107).

Suppression rule

Suppression rules allow you to create very speciﬁc combinations of attributes to suppress ﬁndings.

For example, you can deﬁne a rule through the GuardDuty ﬁlter to auto-archive Recon:EC2/

Portscan from only those instances in a specific VPC, running a specific AMI, or with a specific EC2 tag. This rule would result in port scan findings being automatically archived from the instances that meet the criteria. However, it still allows alerting if GuardDuty detects those instances conducting other malicious activity, such as crypto-currency mining.

Suppression rules deﬁned in the GuardDuty administrator account apply to the GuardDuty member accounts. GuardDuty member accounts can't modify suppression rules.

With suppression rules, GuardDuty still generates all ﬁndings. Suppression rules provide suppression of ﬁndings while maintaining a complete and immutable history of all activity.

Typically suppression rules are used to hide ﬁndings that you have determined as false positives for your environment, and reduce the noise from low-value ﬁndings so you can focus on larger threats.

For more information, see Suppression rules (p. 94) Trusted IP list

A list of trusted IP addresses for highly secure communication with your AWS environment.

GuardDuty does not generate ﬁndings based on trusted IP lists. For more information, see Working with trusted IP lists and threat lists (p. 97).

Threat list

A list of known malicious IP addresses. GuardDuty generates ﬁndings based on threat lists. For more information, see Working with trusted IP lists and threat lists (p. 97).

(18)

AWS CloudTrail event logs

How Amazon GuardDuty uses its data sources

To detect unauthorized and unexpected activity in your AWS environment, GuardDuty analyzes and processes data from AWS CloudTrail event logs, VPC Flow Logs, and DNS logs to detect anomalies involving the following AWS resource types: IAM access keys, EC2 instances, S3 buckets, and Amazon EKS resources. While in transit from these data sources to GuardDuty, all of the log data is encrypted.

GuardDuty extracts various ﬁelds from these logs for proﬁling and anomaly detection, and then discards the logs.

The following sections describe how GuardDuty uses each supported data source.

Topics

• AWS CloudTrail event logs (p. 10)

• AWS CloudTrail management events (p. 11)

• AWS CloudTrail S3 data events (p. 11)

• Kubernetes audit logs (p. 11)

• VPC Flow Logs (p. 12)

• DNS logs (p. 12)

AWS CloudTrail event logs

AWS CloudTrail provides you with a history of AWS API calls for your account, including API calls made using the AWS Management Console, the AWS SDKs, the command line tools, and certain AWS services.

CloudTrail also allows you to identify which users and accounts called AWS APIs for services that support CloudTrail, the source IP address that the calls were made from, and when the calls occurred. For more information, see the AWS CloudTrail User Guide. GuardDuty can monitor both CloudTrail management events, and optionally, CloudTrail data events for S3.

When you enable GuardDuty, it immediately starts analyzing your CloudTrail event logs. It consumes CloudTrail management and S3 data events directly from CloudTrail through an independent and duplicative stream of events. There is no additional charge for GuardDuty to access CloudTrail events.

GuardDuty does not manage your CloudTrail events or aﬀect your existing CloudTrail conﬁgurations in any way. To manage access and retention of your CloudTrail events directly you must use the CloudTrail service console or API. For more information see Viewing Events with CloudTrail Event History.

How GuardDuty Handles AWS CloudTrail Global Events

Another important detail about the way GuardDuty uses CloudTrail as a data source is the handling and processing of CloudTrail global events. For most services, events are recorded in the Region where the action occurred. For global services such as IAM, AWS Security Token Service, Amazon S3, Amazon CloudFront, and Route 53, events are delivered to any trail that includes global services, and are logged as occurring in the US East (N. Virginia) Region. For more information, see About Global Service Events.

(19)

AWS CloudTrail management events

GuardDuty processes all events that come into a Region, including global events that CloudTrail sends to all Regions. This allows GuardDuty to maintain user and role proﬁles in each Region, and enables it to accurately detect credentials that are being maliciously used across Regions.

We highly recommend that you enable GuardDuty in all supported AWS Regions. This enables GuardDuty to generate ﬁndings about unauthorized or unusual activity even in Regions that you are not actively using. This also enables GuardDuty to monitor AWS CloudTrail events for global AWS services. If GuardDuty is not enabled in all supported Regions, its ability to detect activity that involves global services is reduced.

AWS CloudTrail management events

Management events are also known as control plane events. These events provide insight into management operations that are performed on resources in your AWS account.

The following are examples of CloudTrail management events that GuardDuty monitors:

• Conﬁguring security (IAM AttachRolePolicy API operations)

• Conﬁguring rules for routing data (Amazon EC2 CreateSubnet API operations)

• Setting up logging (AWS CloudTrail CreateTrail API operations)

AWS CloudTrail S3 data events

Data events, also known as data plane operations, provide insight into the resource operations performed on or within a resource. They are often high-volume activities.

The following are examples of CloudTrail S3 data events that GuardDuty can monitor:

• GetObject API operations

• PutObject API operations

• ListObjects API operations

• DeleteObject API operations

S3 data event monitoring is enabled by default for new accounts. However, this data source is optional and can be enabled or disabled for any account or Region at any time. For more information about conﬁguring Amazon S3 as a data source see Amazon S3 protection in Amazon GuardDuty (p. 141).

Kubernetes audit logs

Kubernetes audit logs capture sequential actions within your Amazon EKS cluster, including activities from users, applications using the Kubernetes API, and the control plane. Audit logging is a component of all Kubernetes clusters. To learn more, see Auditing in the Kubernetes documentation.

Amazon EKS allows Kubernetes audit logs to be ingested as Amazon CloudWatch Logs through the EKS control plane logging feature. When you enable Kubernetes protection in GuardDuty, GuardDuty immediately starts analyzing Kubernetes audit logs for your Amazon EKS resources. It consumes audit log events directly from the Amazon EKS control plane logging feature through an independent and duplicative stream of flow logs. This process does not require any additional set up or affect any existing Amazon EKS control plane logging configurations that you might have.

GuardDuty doesn't manage your Amazon EKS control plane logging or make Kubernetes audit logs accessible in your account if you have not enabled them for Amazon EKS. To manage access to and

(20)

VPC Flow Logs

retention of your Kubernetes audit logs, you must conﬁgure the Amazon EKS control plane logging feature. For more information, see Enabling and disabling control plane logs In the Amazon EKS documentation.

Kubernetes audit log monitoring is enabled by default all GuardDuty accounts. However, this data source is optional and can be enabled or disabled for any account or Region at any time. For more information about conﬁguring Kubernetes audit logs a data source, see Kubernetes protection in Amazon GuardDuty (p. 137).

VPC Flow Logs

The VPC Flow Logs feature of Amazon VPC captures information about the IP traﬃc going to and from network interfaces within your environment.

When you enable GuardDuty, it immediately starts analyzing your VPC Flow Logs data. It consumes VPC Flow Log events directly from the VPC Flow Logs feature through an independent and duplicative stream of flow logs. This process does not affect any existing flow log configurations that you might have.

GuardDuty doesn't manage your flow logs or make them accessible in your account. To manage access to and retention of your flow logs, you must configure the VPC Flow Logs feature.

There is no additional charge for GuardDuty access to ﬂow logs. However, enabling ﬂow logs for retention or use in your account falls under existing pricing. For more information, see VPC Flow Logs.

DNS logs

If you use AWS DNS resolvers for your Amazon EC2 instances (the default setting), then GuardDuty can access and process your request and response DNS logs through the internal AWS DNS resolvers. If you use another DNS resolver, such as OpenDNS or GoogleDNS, or if you set up your own DNS resolvers, then GuardDuty cannot access and process data from this data source.

When you enable GuardDuty, it immediately starts analyzing your DNS logs from an independent stream of data. This data stream is separate from the data provided through the Route 53 Resolver query logging feature. Conﬁguration of this feature does not eﬀect GuardDuty analysis.

(21)

Finding details

Understanding Amazon GuardDuty ﬁndings

A GuardDuty ﬁnding represents a potential security issue detected within your network. GuardDuty generates a ﬁnding 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 GuardDuty CLI or API operations. For an overview of the ways you can manage findings see Managing Amazon GuardDuty findings (p. 91).

Topics:

Finding details (p. 13)

Learn about the types of data available within GuardDuty ﬁndings.

Sample ﬁndings (p. 21)

Learn how to generate sample ﬁndings to test or better understand GuardDuty.

GuardDuty ﬁnding format (p. 19)

Understand the format of GuardDuty ﬁnding types and the diﬀerent threat purposes tracked by GuardDuty.

Finding types (p. 26)

View and search all available GuardDuty finding by type. Each finding type entry includes an explanation of that finding as well as tips and suggestions for remediation.

Finding details

In the Amazon GuardDuty console, you can view finding details in a finding summary section. Finding details vary based on finding type.

There are two primary details that will determine what kinds of information are available for any ﬁnding.

The first is the resource type, which can be AccessKey, Instance, or S3Bucket. The second detail that determines finding information is Resource Role. Resource role, can be Target for access keys, 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.

Finding summary

A ﬁnding's summary section contains the most basic identifying features of the ﬁnding, including the following information:

• Finding type – A formatted string representing the type of activity that triggered the ﬁnding. For more information, see GuardDuty ﬁnding format (p. 19).

(22)

Resource

• Finding ID – A unique Finding ID for this ﬁnding type and set of parameters. New occurrences of activity matching this pattern will be aggregated to the same ID.

• Severity – a ﬁnding's assigned severity level of either High, Medium, or Low. For more information, see Severity levels for GuardDuty ﬁndings (p. 23).

• Region – the AWS Region in which the ﬁnding was generated. For more information about supported Regions, see Regions and endpoints (p. 194)

• Count – The number of times GuardDuty has aggregated an activity matching this pattern to this ﬁnding ID.

• Account ID – the ID of the AWS account in which the activity took place that prompted GuardDuty to generate this ﬁnding.

• Resource ID – the ID of the AWS resource against which the activity took place that prompted GuardDuty to generate this ﬁnding.

• 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.

NoteTimestamps for ﬁndings in the GuardDuty console appear in your local time zone, while JSON exports and CLI outputs display timestamps in UTC.

• Updated at – The last time this ﬁnding was updated with new activity matching the pattern that prompted GuardDuty to generate this ﬁnding.

NoteTimestamps for ﬁndings in the GuardDuty console appear in your local time zone, while JSON exports and CLI outputs display timestamps in UTC.

Resource

The Resource aﬀected gives details on the AWS resource that was targeted by the trigger activity. The information available varies based on resource type and action type.

Resource role – The role of the AWS resource that triggered the ﬁnding. This value can be TARGET or ACTOR, and represents whether your resource was the target of the suspicious activity or the actor that preformed the suspicious activity.

Resource type – the type of the affected resource. A finding can include multiple resources types if multiple resources were involved. The resource types are AccessKey, S3 bucket, KubernetesCluster or Instance. 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 terminated or if the underlying API invocation originated from an EC2 instance in a diﬀerent 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 ﬁnding.

• Instance Type – the type of the EC2 instance involved in the ﬁnding.

• Launch Time – the time and date the instance was launched.

• Outpost ARN – The Amazon Resource Name (ARN) of the AWS Outposts. Only applicable to AWS Outposts instances. For more information, see What is AWS Outposts?

• Security Group Name – The name of the Security Group attached to the involved instance.

(23)

Resource

• 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.

Access Key

Access Key details:

• Access key ID – access key ID of the user engaged in the activity that prompted GuardDuty to generate the ﬁnding.

• Principal ID – the principal ID of the user engaged in the activity that prompted GuardDuty to generate the ﬁnding.

• User type – the type of user engaged in the activity that prompted GuardDuty to generate the ﬁnding. For more information, see CloudTrail userIdentity element.

• User name – The name of the user engaged in the activity that prompted GuardDuty to generate the ﬁnding.

S3 bucket

S3 bucket details:

• Name – The name of the bucket involved in the ﬁnding.

• ARN – The ARN of the bucket involved in the ﬁnding.

• Owner – The canonical user ID of the user that owns the bucket involved in the ﬁnding. For more information on canonical user IDs see AWS account identiﬁers.

• Type – The type of bucket ﬁnding, can be either Destination or Source.

• Default server side encryption – encryption details for the bucket.

• Bucket Tags – a list of tags attached to this resource, listed in the format of key:value.

• Eﬀective Permissions – An evaluation of all eﬀective permissions and policies on the bucket that indicates whether the involved bucket is publicly exposed. Values can be PUBLIC or NOT PUBLIC.

Kubernetes Cluster

Kubernetes Cluster details:

• User details – Details of the Kubernetes user that performed the API action that prompted GuardDuty to generate the ﬁnding.

• Username – The name of the Kubernetes user that performed the API action that prompted GuardDuty to generate the ﬁnding.

• Groups – A list of permissions groups the Kubernetes user belongs to.

• Access key details – This section includes Access key details identifying the IAM User or Role associated with the activity when the user is an IAM identity accessing the cluster through EKS.

• Access key ID – Access key ID of the user engaged in the activity that prompted GuardDuty to generate the ﬁnding.

• Principal ID – The principal ID of the user engaged in the activity that prompted GuardDuty to generate the ﬁnding.

(24)

Action

• User type – The type of user engaged in the activity that prompted GuardDuty to generate the ﬁnding. For more information, see CloudTrail userIdentity element.

• User name – The name of the user engaged in the activity that prompted GuardDuty to generate the ﬁnding.

• Cluster details – Details on the Kubernetes cluster involved in the ﬁnding.

• EKS details – Details about the Amazon EKS resource involved in the ﬁnding.

• Workload Details – Details on the Kubernetes workload resources that were involved in the ﬁnding,.

• Workload Type – The type of workload resource used to manage the pod implicated in the ﬁnding, this value can be either Deployment, ReplicaSet, StatefulSet, DaemonSet, Job, or CronJob.

Action

A ﬁnding's Action gives details on the type of activity that triggered the ﬁnding. The information available varies based on action type.

• Action type – The ﬁnding activity type. This value can be NETWORK_CONNECTION, PORT_PROBE, DNS_REQUEST, or AWS_API_CALL. The information available varies based on action type:

• NETWORK_CONNECTION – indicates that network traﬃc was exchanged between the identiﬁed 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 ﬁnding. The values can be one of the following:

• INBOUND – indicates that a remote host initiated a connection to a local port on the identiﬁed EC2 instance in your account.

• OUTBOUND – indicates that the identiﬁed 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 ﬁnding.

• Local IP – The original source IP 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_PROBE – indicates that a remote host probed the identiﬁed EC2 instance on multiple open ports. This action type has the following additional information:

• Local IP – The original source IP 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.

• DNS_REQUEST – indicates that the identiﬁed 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 ﬁnding.

• AWS_API_CALL – indicates that an AWS API was invoked. This action type has the following additional information:

(25)

Actor or Target

NoteThese operations can also include non-API events captured by AWS CloudTrail. For more information, see Non-API events captured by CloudTrail.

• 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 ﬁnding 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 ﬁnding.

Actor or Target

A ﬁnding 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 on the entity that targeted your resource.

A ﬁnding 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:

• IP address – the IP address involved in the activity that prompted GuardDuty to generate the ﬁnding.

• Location – location information for the IP address involved in the activity that prompted GuardDuty to generate the ﬁnding.

• Organization – ISP organization information of the IP address involved in the activity that prompted GuardDuty to generate the ﬁnding.

• Port – the port number involved in the activity that prompted GuardDuty to generate the ﬁnding.

• Domain – the domain involved in the activity that prompted GuardDuty to generate the ﬁnding.

Additional information

All ﬁndings 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 ﬁnding.

• Sample – a true or false value that indicates whether this is a sample ﬁnding.

• Archived – a true or false value that indicates whether this is ﬁnding has been archived.

• Unusual – activity details that were not observed historically. These can include an unusual (previously not observed) user, or location, or time.

• Unusual protocol– the network connection protocol involved in the activity that prompted GuardDuty to generate the ﬁnding.

Evidence

Findings based on DNS logs have an Evidence section that includes the following information:

• Threat intelligence details – the name of the threat list that the recognized Threat name appears on.

• Threat name – the name of the malware family, or other identiﬁer, associated with the threat.

(26)

Anomalous behavior

Findings types that end in AnomalousBehavior indicate that the ﬁnding was generated by the

GuardDuty anomaly detection machine learning (ML) model. The ML model evaluates all API requests to your account and identiﬁes 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 speciﬁc 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 ﬁnding details. The identities are deﬁned by the CloudTrail userIdentity Element, 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 ﬁnding. 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, operation not permitted.

• APIs are categorized by their associated service.

Note

For more context, select Usual APIs to open a pane that gives details on 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 on the proﬁled behavior for your account. The information tracked in this panel 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.

• Unusual Behavior (User Identity) – this section gives additional details on the profiled behavior for the User Identity involved with the finding. When a behavior is identified as unusual this means GuardDuty's ML model has not 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.

(27)

GuardDuty ﬁnding format

NoteFor more context on Unusual behaviors, select Usual behaviors in either the Account or User ID panel to open a pane that gives details on the expected behavior for you 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.

GuardDuty ﬁnding 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 finding details (p. 25) include information about what happened, which AWS resources were involved in the suspicious activity, when this activity took place, and other information.

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 ﬁndings that it generates:

ThreatPurpose:ResourceTypeAﬀected/ThreatFamilyName.DetectionMechanism!Artifact Each part of this format represents an aspect of a ﬁnding 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 EC2, IAM, and S3 resources.

• 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 ﬁnding based on your custom threat lists, while .Reputation indicates that GuardDuty detected the ﬁnding using a domain reputation score model.

• Artifact - describes a speciﬁc resource that is owned by a tool that is used in the malicious activity. For example, DNS in the ﬁnding type CryptoCurrency:EC2/BitcoinTool.B!DNS indicates that an EC2 instance is communicating with a known Bitcoin-related domain.

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. The MITRE ATT&CK tactics indicate diﬀerent phases in an adversary's attack cycle. In the current release of GuardDuty, ThreatPurpose can have the following values:

(28)

Threat Purposes

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 diﬀerent 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 account IDs or passwords, from your environment. This threat purpose is based on MITRE ATT&CK tactics

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 inﬁltrating your environment. This threat purpose is based on MITRE ATT&CK tactics

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.

Exﬁltration

This value indicates that GuardDuty has detected activity or activity patterns that an adversary may use when attempting to steal data from your network. This threat purpose is based on MITRE ATT&CK tactics.

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

InitialAccess

This threat purpose is based on MITRE ATT&CK tactics Pentest

Sometimes owners of AWS resources or their authorized representatives intentionally run tests against AWS applications to ﬁnd 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 oﬀ. For

Amazon GuardDuty

Amazon GuardDuty

Amazon GuardDuty User Guide

Amazon GuardDuty: Amazon GuardDuty User Guide

Table of Contents

What is Amazon GuardDuty?

Pricing for GuardDuty

Accessing GuardDuty

Getting started with GuardDuty

Before you begin

Step 1: Enable Amazon GuardDuty

Step 2: Generate sample ﬁndings and explore basic operations

Step 3: Conﬁgure GuardDuty ﬁndings export to an S3 bucket

Step 4: Set up GuardDuty ﬁnding alerts through SNS

Next steps

Concepts and terminology

How Amazon GuardDuty uses its data sources

AWS CloudTrail event logs

How GuardDuty Handles AWS CloudTrail Global Events

AWS CloudTrail management events

AWS CloudTrail S3 data events

Kubernetes audit logs

VPC Flow Logs

DNS logs

Understanding Amazon GuardDuty ﬁndings

Finding details

Finding summary

Resource

Action

Actor or Target

Additional information

Evidence

Anomalous behavior

GuardDuty ﬁnding format

Threat Purposes