Making sense of Amazon GuardDuty alerts

Gone are the days when we only had to protect some physical servers and all of the associated networking gear used to route traffic to and from those servers in our data centers.

Fast forward to today—most companies are running at least some of their workloads in the cloud. Today we’ve got virtualized servers, abstracted services and a simplified networking layer all managed through an API. Amazon Web Services (AWS) offers lots of security services to help protect their customers’ data. One of the more well-known services for detection and response is Amazon GuardDuty.

If you’ve heard of Amazon GuardDuty but aren’t exactly sure how to get the most out of it, then this post is for you. I’ll talk about Amazon GuardDuty works, share the kinds of threats it’s looking for, show you some sample alert investigations and offer a couple tips for how to make more sense of the signals you get from Amazon GuardDuty.

What is Amazon GuardDuty in AWS?

Amazon GuardDuty is a continuous threat monitoring service available to AWS customers that works by consuming AWS CloudTrail logs (Amazon Web Services (AWS) native API logging), Virtual Private Cloud (VPC) flow logs and DNS logs. Fortunately, AWS CloudTrail logging is enabled by default—and you don’t even have to pay for VPC flow logs or Amazon Route 53 (AWS DNS) to benefit from Amazon GuardDuty as long as you’re using an Amazon Web Services (AWS) DNS resolver (versus using something like Google or OpenDNS). However, having VPC flow logs enabled provides defenders another tool in their toolbox to use when investigating potential security incidents (more on this later). Now, if you consider what visibility AWS has into its customer’s data and services, then the Amazon GuardDuty use of these 3 datasets make sense.

Let’s look at what types of alerts Amazon GuardDuty might generate for us by using flow, DNS and API activity logs.

As of today, there are 54 unique Amazon GuardDuty findings, more commonly known as rules. These are all based on easy to understand logic or basic anomaly detection. Each finding has the following naming convention:

ThreatPurpose:ResourceTypeAffected/ThreatFamilyName.ThreatFamilyVariant!Artifact

We’ll focus on the ‘ResourceTypeAffected’ portion of that convention because this is the most important section to understand when you’re reviewing Amazon GuardDuty alerts. Today, this field consists of either ‘IAMUser’ or ‘EC2’. All Elastic Cloud Compute (EC2) rules are based on VPC flow logs or DNS logs, while the ‘IAMUser’ rules generate alerts from AWS CloudTrail API logs and possibly in conjunction with flow and DNS logs. We’ve found the ‘IAMUser’ rules to be quite valuable, as they indicate authenticated access into your Amazon Web Services (AWS) account.

Because of Amazon Web Services (AWS)’ visibility into our data, many of the ‘EC2’ rules are based on an Amazon Web Services (AWS)-curated threat lists of atomic IOCs such as domains and IPs. These are then filtered against the flow and DNS logs. But there’s a problem: just like with most security tech, we don’t have any visibility into the threat lists that Amazon Web Services (AWS) is using and how they match up or don’t match up with the threats we’re concerned with for our own org.

However, there’s a silver lining here: You can provide your own threat lists from third parties and even automate the ingestion of these lists into Amazon GuardDuty. This can be IOCs you’ve identified internally to your org or external feeds you subscribe to or consume through something like a Threat Intelligence Platform.

When considering the pyramid of pain—a model focusing on how best to disrupt attackers—many of these Amazon GuardDuty alerts correspond to the bottom of the pyramid. When consuming lower fidelity alerts, we recommend enriching those with additional context to provide analysts with more decision support. Here at Expel we take advantage of some third-party enrichment services, such as passive DNS, WHOIS information, OSINT and other data to get a better understanding of the potential threats associated with these IPs and domains identified by Amazon GuardDuty.

Investigating Amazon GuardDuty alerts

Now that we have an idea of what to expect in a Amazon GuardDuty alert, let’s take a look at a couple different example alerts. Expel uses the Amazon Web Services (AWS) API to consume our customers’ Amazon GuardDuty alerts directly from their Amazon Web Services (AWS) Accounts and then we normalize the Amazon GuardDuty alert data in Expel Workbench for our SOC analysts.

Here we get a pretty straightforward explanation in Expel Workbench that our EC2 instance is making connections with a known Tor exit node. Given what we know about these EC2 rules, this alert was simply generated from the VPC flow logs based on an AWS threat list for known Tor exit nodes.

This is where those VPC flow logs would really come in handy. Flow logs contain not only the source and destination IP and ports, but also how much traffic was actually passed. Depending on the function of your EC2 instance, this can paint a pretty telling picture as to whether there might be an instance compromise or not.

If we need more answers, then you’ll need a snapshot of that EC2 for a deeper dive or potentially having some other endpoint software such as EDR running inside of that instance. The latter depends on your organization’s risk tolerance for security software running on your production (AKA revenue generating) assets.

Next, let’s look at another alert that looks similar at a glance but with drastically different implications.

This alert isn’t quite as straightforward as the previous, but if we revisit what we know about Amazon GuardDuty alerts with ‘IAMUser’ as the ResourceTypeAffected, then we know this originated from a AWS CloudTrail log(s). This is where we might sound the alarm. What you’re looking at is someone with API credentials making successful API calls to your Amazon Web Services (AWS) account from the Tor anonymizing network. Unless your org has some privacy-averse AWS admins or developers, then there’s little reason for you see this particular alert.

Now you need to do some analysis. Determine if an AWS Identity and Access Management (IAM) user or role was compromised as this could help you determine how those credentials may have been compromised. The key difference between these two are that User credentials are permanent whereas Role credentials are temporary, lasting between 1 – 12 hours. A user compromise might imply leaked API access keys on GitHub or something similar, while a role compromise generally implicates some other deeper-rooted issue in your environment such a Server Side Request Forgery (SSRF) vulnerability.

Lastly, let’s look at a real-world Amazon GuardDuty alert.

In this alert, SOC analysts identified the anomalous detection of an Amazon Web Services (AWS) service user (a Continuous Integration/Continuous Delivery IAM user) making a suspicious API call, ListAccessKeys, that should never be attempted by that user given its purpose. Fortunately, Amazon GuardDuty has some insight into what API calls a user or role normally makes. This threat actor was able to initially compromise a less privileged user access key for the Amazon Web Services (AWS) account and then the attacker pivoted with a variety of methods to expand access and privileges into other IAM users and roles.

4 things to remember when reviewing Amazon GuardDuty alerts