Threat Detection with AWS GuardDuty

Introduction

This is a walkthrough of an AWS Security Workshop with scenarios covering threat detection and remediation using Amazon GuardDuty. Amazon GuardDuty is a “threat detection service that continuously monitors for malicious activity and unauthorized behavior to protect your AWS accounts and workload”. This walkthrough will demonstrate how to analyze, review, and remediate GuardDuty findings. The three scenarios I will cover are:

1. Compromised EC2 Instance
2. Compromised IAM Credentials
3. IAM Role Credentials Exfiltration

For this workshop, AWS GuardDuty is enabled and launched the workshop provided CloudFormation stack to set up my lab environment. More information on CloudFormation can be found here.

Compromised EC2 Instance

This first scenario uses Amazon GuardDuty, Amazon CloudWatch Event Rules and AWS Lambda to detect and remediate a compromised host.

Architecture Overview

Walkthrough

1. For the setup of this lab, a custom threat list is created with a list of malicious elastic IP addresses and stored in S3. In a real-world environment, the malicious host(s) may come from outside your network, but the malicious host is within our network to stimulate the attack in a controlled environment. The compromised EC2 instance pings the EIP of a malicious instance off of the threat list created.

2. GuardDuty monitors the VPC Flow Logs and analyzes this based on threat lists created.

Sidenote: GuardDuty allows expanding the monitoring scope by creating custom trusted IPs lists and threat lists.

3. GuardDuty generates a finding and sends this to the GuardDuty console and CloudWatch Events.

4. CloudWatch Event rule triggers an SNS topic and a Lambda function.

5. SNS sends an e-mail with the finding information (the first email).

6. The Lambda function isolates the compromised instance (second email sent within a minute of the first email) (see note*).

* The EC2 instance started with a different security group prior to remediation. The initial security group was removed and the “ForensicSecurityGroup” (shown in above) was added to isolate the previously compromised instance.

Compromised IAM Credentials

In this second scenario, we manually remediate an identified malicious host attempting to make API calls.

This is a lab and no IAM credentials will be exposed if you decide to run this lab.

Architecture Overview

Walkthrough

1. As mentioned in the first scenario, a custom threat list is created with a list of malicious elastic IP addresses. The malicious instance makes API calls and are logged in CloudTrail.
2. GuardDuty monitors the CloudTrail Logs (see note*) and analyzes this based on the custom threat list.
3. GuardDuty generates a finding and sends this to the GuardDuty console and CloudWatch Events.
4. CloudWatch Event rule triggers an SNS topic.
5. SNS sends you an email with the finding information.

6. In the GuardDuty console the finding is titled UnauthorizedAccess:IAMUser/MalicousIPCaller.Custom and it contains the Access Key ID of the malicious user.

7. Manually remediate credentials by going to IAM > Users > Security credentials tab > find “Access Key ID” mentioned in GuardDuty finding > change status to Inactive.

* GuardDuty analyzes tens of billions of events across multiple AWS data sources, such as AWS CloudTrail, Amazon VPC Flow Logs, and DNS logs.

IAM Role Credential Exfiltration

The last scenario demonstrates how GuardDuty findings can detect high severity alerts and trigger AWS Lambda to automate the remediation of credentials that have been exfiltrated.

Sidenote: GuardDuty findings have severity levels (low, medium, or high) to help determine the potential security risk to your environment.

Architecture Overview

Walkthrough

1. An attacker compromises an EC2 instance and exfiltrates the IAM role credentials via the metadata service.
2. The attacker sets up a CLI user to make API calls.

First attempt: Below depicts an attack invoking an AWS API call.

3. GuardDuty generates a finding and sends this to the GuardDuty console and CloudWatch Events.

4. A CloudWatch Event rule triggers a SNS topic and a Lambda function.

5. SNS sends you an email with the GuardDuty finding information.

Alert: EC2 Compromised and Invoked AWS API

6. A Lambda function attaches an IAM policy to the role revoking all active sessions and a remediation e-mail is sent within one minute of GuardDuty finding.

Second Attempt: Compromised IAM role is remediated and access is revoked for all active sessions. Below depicts an attacker trying the same AWS API call a minute later.

Conclusion

If you are just starting out with AWS GuardDuty, I would recommend getting your hands dirty and playing around with the provided templates to customize your environment. You can find this workshop Getting Hands on with Amazon GuardDuty and other AWS Security Workshops located here.

Additional AWS GuardDuty Resources

• AWS GuardDuty Overview
• AWS GuardDuty User Guide
• AWS GuardDuty API Reference
• Monitoring GuardDuty Findings with Amazon CloudWatch Events
• CloudWatch events rule for GuardDuty to send custom SNS notifications