GuardDuty is a continuous monitoring service offered by AWS that identifies and alerts about suspicious or unwanted behavior within an account. There are currently three data sources that it analyzes, which are virtual private cloud (VPC) flow logs, CloudTrail event logs, and domain name system (DNS) logs. Note that VPC flow logging and CloudTrail event logging do not need to be enabled on your account for GuardDuty to use them, and there is currently no way to review DNS logs in AWS. This means that even if there are no flow logs active in the environment and CloudTrail is disabled, GuardDuty will still generate findings from VPC flow logs, CloudTrail event logs, and DNS logs.

It is also important to note that GuardDuty can only ingest DNS logs if the requests are routed through AWS DNS resolvers, which is the default for EC2 instances. If this is changed and requests are using an alternate DNS resolver, such as Google or CloudFlare, then GuardDuty cannot ingest and alert on that DNS data.

GuardDuty can be managed cross-account as well, where a single master account controls the GuardDuty monitoring and configuration for one or more member accounts. If you ever find yourself in the GuardDuty master account of an organization, you will potentially be able to manipulate monitoring configuration across every account connected with it.

At a high level, GuardDuty will basically alert you about events that may resemble malicious behavior, such as if an EC2 instance is communicating with a known malware command and control server, an EC2 instance is communicating with a known Bitcoin mining pool, or a known hacking operating system is being used. These alerts can then be set up to send notifications to CloudWatch Events, where you can then react to the findings:

Most GuardDuty finding types rely on machine learning to establish a baseline of normal activity by users in an account. It will alert on something if it is outside of that baseline and matches that finding type. Consider an example AWS account with two IAM users and GuardDuty enabled. One of those users is frequently using the IAM service to manage users, groups, and roles, and to manage the permissions of all of those. The other user only uses the EC2 service, even though they have permission to do more than that. If both users attempted to enumerate permissions of IAM users, groups, or roles, GuardDuty will likely not trigger the IAM user, because it is part of that user's baseline to interact with the IAM service like that. On the other hand, the EC2 user will likely generate the Recon:IAMUser/UserPermissions GuardDuty finding type, which indicates a user is trying to enumerate permissions in the account (and it breaks the baseline established for them).

There are many GuardDuty finding types that are very simple and are meant to catch low-hanging-fruit from attackers. These types of findings are generally simple or obvious enough that you shouldn't be triggering them anyway, even if you aren't directly thinking of them. Some of those findings include things such as port scanning an EC2 instance, brute-forcing a secure shell (SSH)/remote desktop protocol (RDP) server, or using Tor for your communications with AWS. In this chapter, we are going to focus on the more AWS-specific findings and more advanced findings, as the simple finding types are not necessarily within the scope of this book and they should be easy to bypass or avoid anyway.

Another important note to consider is how GuardDuty uses machine learning and baselines to determine if it should trigger a finding or not. If you are within a sandbox environment that is constantly being attacked because you are testing out tools and attack methods, it is possible that GuardDuty will detect this activity as the baseline for your account. If that is the case, then it may not trigger certain findings that you will expect it to because it has established that type of activity as normal within the environment.