AWS GuardDuty
An overview of AWS GuardDuty
Last updated
Was this helpful?
An overview of AWS GuardDuty
Last updated
Was this helpful?
AWS GuardDuty is a paid security service offered by AWS. Using AI/ML, anomaly and malicious file detection, and threat intelligence, GuardDuty can monitor and alert you to malicious activity in your AWS environment. It leverages foundational data sources such as CloudTrail Management Events, VPC Flow Logs, and Route53 Resolver DNS queries for these detections. For an additional cost, you can expand coverage and detection capabilities to S3 data events, EKS, Lambda, and more with optional protection plans.
Integration with AWS Organizations allows for convenient control and deployment of GuardDuty across all your AWS accounts.
AWS GuardDuty is a regional service. For the most complete coverage, deploy and enable all features for all AWS accounts and regions in your AWS Organization. We'll look at how to do this in the lab Deploying AWS GuardDuty via Terraform later.
It essentially boils down to setting up an AWS Delegated Administrator account to manage GuardDuty, as it's not advisable to use the AWS Management Account due to the level of access the Management Account has to your AWS Organization accounts, and that organizational policies like SCPs, RCPs, etc., do not affect this account. Once a Delegated Administrator account is set up, we can enable GuardDuty across all accounts and regions.
If integrated and deployed with AWS Organizations, an AWS IAM Service-Linked Role called AWSServiceRoleForAmazonGuardDuty gets deployed to all accounts with the IAM permission policy, AmazonGuardDutyServiceRolePolicyallowing GuardDuty appropriate permission to set up its features.
A GuardDuty detector is created in each region you've configured and used to monitor the environment.
As mentioned in the Introduction, GuardDuty leverages default data sources to analyze your AWS environment for potentially malicious activity. These are used to identify and generate EC2 and IAM-related findings, at least at this time.
For EC2, this includes unusual traffic volume, port scanning, SSH and RDP brute force attacks, and more. A full listing of EC2-related findings can be found here.
For IAM, this includes activity generated by systems such as Kali Linux, Parrot OS, or Pentoo Linux, disabling of CloudTrail logging, utilizing EC2 credentials from another AWS account or external IP address, and more. A full listing of IAM-related findings can be found here.
As of this writing, GuardDuty has several optional protection plans at an additional cost. We'll take a deeper dive into some of these in future labs. One to keep in mind is that GuardDuty is a detection service only; it does not prevent activity from occurring, malicious or otherwise. Personally, I think it's a bit of a misnomer calling these "protection" plans because of this.
Enabling this protection plan will immediately begin monitoring CloudTrail S3 data events for potentially malicious activity such as data exfiltration and destruction. CloudTrail does not automatically log S3 data events, this has to be enabled explicitly. However, enabling S3 Protection in GuardDuty is enough - "...you don't need to explicitly enable or configure S3 data event logging in AWS CloudTrail".
Once enabled, GuardDuty begins to monitor for the Get/Put/List/Delete Object API actions. This looks for S3-related activities being performed by malicious IPs, Tor networks, suspicious/anomalous behavior, and more. A full listing of S3 Protection-related findings can be found here.
If running AWS Elastic Kubernetes Service (EKS) clusters, it's worth enabling this plan to monitor EKS audit log events. No additional configuration is required on the EKS side.
Once enabled, GuardDuty begins to monitor EKS clusters, looking for anomalous/suspicious EKS-related activities being performed, exposed Kubernetes dashboards, successful access, and more. A full listing of EKS Protection-related findings can be found here.
Extended Threat Detection was added to AWS GuardDuty in December 2024 and is enabled by default. This feature analyzes activity and events across multiple data sources and detects multi-stage attacks in your AWS environment. Currently, it leverages the foundational data sources discussed in the 📖 Introduction to AWS GuardDutyand S3 Protection if enabled.
When an alert is generated, we get a history of Signals (correlation of data points and findings), impacted AWS resources, and more. The attack sequence is aligned with MITRE tactics (Discovery, Initial Access, Defense Evasion, Exfiltration, etc.). A full listing of attack sequence finding types can be found here.
If running AWS EKS, AWS Fargate Amazon Elastic Container Service (ECS), and/or Amazon Elastic Container Compute Cloud (EC2) resources, then this may be a beneficial capability. This requires a GuardDuty agent to be deployed (automatically or manually) before it will monitor runtime events on containers and workloads.
Once enabled and the associated agent is deployed, we'll get alerted to activity like discovery of reverse shells, crypto miners, container escapes, and more. A full listing of runtime monitoring-related findings can be found here.
Malware Protection for EC2 enables scanning EC2 instances and container workloads (EKS Auto Mode) running on EC2 for malware.
Once enabled, GuardDuty will conduct a malware scan on Elastic Block Store (EBS) volumes when a finding is discovered, indicating the presence of malware. It does this by taking a Snapshot (backup) of the EBS volume and scanning it. This ensures workloads are not interrupted or otherwise impacted during the analysis. On-demand scans can optionally be performed by an administrator by targeting a specific resource by its Amazon Resource Name (ARN). A full listing of EC2 malware protection-related findings can be found here.
Malware Protection for S3 enables scanning S3 buckets whenever an Object or a new version of an Object is uploaded.
Once enabled, GuardDuty will monitor up to 25 S3 buckets per Region. It can also scan archived files up to 5 levels and up to 1000 files per archive, provided nothing is password protected. Some additional limitations apply depending on S3 storage class and encryption settings. A full listing of S3 malware protection-related findings can be found here.
RDS Protection enables behavior-based detection of RDS login activity for supported databases.
Once enabled, GuardDuty will monitor RDS login behavior for 2 weeks before it generates detections. Likewise, newly spun-up databases will require 2 weeks of monitoring. It will detect activity like successful database login brute force, malicious/anomalous activity, and more. A full listing of RDS protection-related findings can be found here.
Lambda Protection enables network traffic monitoring of your Lambda functions by leveraging VPC Flow Logs and function invocation logs.
Once enabled, GuardDuty will monitor these logs for activity like querying IPs related to cryptocurrency activity, connections to a Tor network, and more. A full listing of Lambda protection-related findings can be found here.
GuardDuty maintains logs for 90 days. If you wish to maintain logs for longer and/or you want to export these logs into another platform like a SIEM (Security Information and Event Management), such as Google SecOps, then you'll want to set this up.
Currently, the logs can be exported to an S3 bucket. From there, you'll need to set up something like DataDog's Vector or an alternative integration if you need the logs available on other platforms.
