Using ThreatStream Indicators of Compromise with AWS GuardDuty

GuardDuty threat lists allow ThreatStream users to import known malicious IP addresses to identify malicious activity

It has been a busy week for AWS at their re:Invent 2017 conference in Las Vegas. One of the new product launches that caught my eye yesterday was GuardDuty, a managed threat detection service that continuously monitors for malicious or unauthorized behavior to help protect AWS accounts and workloads.

One way GuardDuty protects AWS environments is through the use of trusted IP lists and threat lists, the latter being particularly useful from a ThreatStream perspective. GuardDuty identifies suspected attackers by comparing threat lists against VPC Flow Logs, AWS CloudTrail event logs, and DNS logs in an AWS account. When a potential threat is detected, the service delivers a detailed security alert to the GuardDuty console and AWS CloudWatch Events. This makes alerts actionable and easy to integrate into existing event management and workflow systems.

GuardDuty threat lists allow ThreatStream users to import known malicious IP addresses from the ThreatStream platform to generate findings of threats in their AWS account. Let me show you how.

Step One: Select and Export Indicators

Using ThreatStream’s search functions it is possible to isolate specific indicators. For instance, you can use basic and advanced search operators to pick specific indicators based on information such as confidence, indicator type, ASN, or a specific tag. In the screenshot above I’ve used filters to limit the results to known malware IP’s recently identified by PhishMe with a high confidence score. Currently GuardDuty only considers IP based indicators, therefore it is important to use a filter that only considers IP based indicator types.

After the results are returned you can export the results from ThreatStream. GuardDuty accepts either a simple list of IP’s in a text file or structured IP lists in STIX 1.x format. As ThreatStream supports STIX 1.2 export, use this option.

Step Two: Upload Indicators to S3

Upload the downloaded XML file of indicators in STIX format to an S3 bucket in your AWS account. I created a new S3 bucket named “threatlists” to manage multiple threat list files. You might want to consider a static filename like “threatstream-indicators.xml” (versus the dynamic one created by the ThreatStream export) so that the S3 URL remains static if you append or modify the list of indicators within the file. Currently GuardDuty can support up to 6 threat lists. As a result it makes sense to update a single file where possible. Make a note of the S3 URL as it will be required during step three.

Step three: Add the Threat List to GuardDuty

Adding new threat lists can be done simply inside the GuardDuty console under “Lists”. Creating a new threat list from the STIX file in the S3 bucket is simple; give the threat list an appropriate name, paste the S3 URL into the location field (why using a static URL is recommended), and select “Structured Threat Information Expression (STIX)” as the format.

Once the threat list is added successfully, GuardDuty will begin using the contents of the file in the S3 bucket to compare against events in your AWS environment to deliver “findings” when a threat is observed.

Anomali x AWS

As GuardDuty grows you can expect to see much tighter integration with ThreatStream. If you’re considering using GuardDuty alongside ThreatStream, or any Anomali products, please do send any questions you have my way via email: dgreenwood [-at-] anomali [-dot-] com

Originally published at www.anomali.com.