AWS Threat Emulation and Detection Validation With Stratus Red Team and Datadog Cloud SIEM | Datadog

AWS threat emulation and detection validation with Stratus Red Team and Datadog Cloud SIEM

Author Dayspring Johnson

Published: July 25, 2023

As attackers get more creative in their malicious tradecraft, cloud security teams must be able to keep up with detections that provide adequate coverage against the diverse threats to their cloud environments. Threat emulation enables cloud security teams to leverage their understanding of threat actor behaviors as a feedback loop for developing cloud-based detections and validating their resilience. However, the processes involved in setting up and tearing down the necessary infrastructure, as well as replicating attacker techniques during threat emulation exercises, introduce friction and may potentially hinder the efficiency of both the detection development and validation processes. Stratus Red Team is an open source project that comes packaged with a number of AWS and other cloud provider-specific attack techniques, enabling cloud security engineers to seamlessly emulate adversary behavior within sandboxed environments. By abstracting the intricacies of infrastructure setup and teardown, Stratus Red Team allows security engineers to focus solely on detection development and validation. 

Cloud security teams can further elevate their threat detection and investigation capabilities for their dynamic, cloud-scale environments with Datadog Cloud SIEM. Cloud SIEM lets security engineers analyze operational and security telemetry in real time while utilizing curated, out-of-the-box rules to detect and respond to threats.

In this post, we’ll cover how you can use Stratus Red Team and Cloud SIEM together to boost your cloud threat detection and uphold resilient strategies in your AWS environments. This includes:

  • Threat emulation and detection validation requirements
  • Sample AWS attacks
  • Using Threatest for continuous validation

Threat emulation and detection validation requirements

Stratus Red Team has a Getting Started guide that highlights setup and introduces the various concepts referenced in this post. To get started with threat emulation, you can use the Stratus CLI from an authenticated AWS account to list all AWS techniques available:

List of AWS attack techniques available with Stratus Red Team

Attacks can be detonated by running a simple CLI command such as stratus detonate aws.credential-access.ec2-get-password-data.

To simultaneously clean up the infrastructure deployed to detonate an attack, you can run a separate cleanup command as highlighted in Stratus Red Team’s command reference, or you can append the --cleanup flag: stratus detonate aws.credential-access.ec2-get-password-data --cleanup.

It’s important to note that Stratus Red Team’s techniques are mapped to the MITRE Cloud Matrix in order to easily classify attacker behaviors. This makes it easier for cloud security teams to understand what corresponding detections they have in place for these attacks.

Stratus Red Team currently supports 27 AWS attack techniques spanning across various MITRE tactics, including Discovery, Privilege Escalation, Persistence, Exfiltration, and more.

With the focus of this post on AWS, our source of logging and monitoring for attacks is CloudTrail. Datadog Cloud SIEM has a comprehensive guide for setting up your AWS environment to send CloudTrail logs to Datadog.

Once CloudTrail logs are being ingested by Datadog, you can begin viewing signals generated by Stratus Red Team in the Cloud SIEM signals explorer by filtering for the CloudTrail source and a user agent containing “stratus-red-team”:

Datadog Cloud SIEM Signals page

Datadog Cloud SIEM provides several out-of-the-box rules that detect attacks including but not limited to the techniques that can be detonated by Stratus Red Team.

In the following sections, we’ll go over a few sample threat emulations and detection validation workflows in various AWS services, including Amazon EBS, Amazon S3, and AWS IAM roles.

Sample attack: Amazon EBS snapshot exfiltration

Amazon Elastic Block Store (EBS) is a persistent block-level storage solution designed for use with EC2 instances. It allows the creation and attachment of volumes to EC2 instances in order to facilitate reliable and scalable storage. Exfiltrating an EBS snapshot poses the risk of exposing valuable and potentially sensitive data to attackers.

Stratus Red Team replicates this attack by creating an EBS volume and snapshot and then sharing the snapshot with an external, fictitious AWS account.

We can detonate this attack and subsequently clean up by using the CLI command stratus detonate aws.exfiltration.ec2-share-ebs-snapshot --cleanup. Below is an example of the output of this command:

Expected output for AWS EBS attack emulation

This attack might work differently if EBS default encryption is enabled in the AWS region. Nonetheless, you should still get the signal from Datadog’s out-of-the-box detection—AWS EBS Snapshot possible exfiltration.

Amazon EBS Snapshot possible exfiltration detection rule

Sample attack: Backdoor S3 bucket via bucket policy

Amazon Simple Storage Service (S3) is a cloud object storage solution that allows for easy storage and retrieval of data. S3 bucket policies are a set of rules that define access for an S3 bucket by determining who can perform specific actions on the bucket and its contents. Backdooring an S3 bucket via its bucket policy allows an attacker to gain unauthorized access to objects within the bucket and gives them the ability to exfiltrate sensitive data.

Stratus Red Team replicates this attack by creating an S3 bucket and then backdooring the bucket’s policy with permissions that allow unauthorized access from an external, fictitious AWS account.

We can detonate this attack and subsequently clean up by using the CLI command stratus detonate aws.exfiltration.s3-backdoor-bucket-policy --cleanup. Below is an example of the output of this command:

Expected output for Amazon S3 bucket attack emulation

Datadog’s out-of-the-box Amazon S3 bucket policy modified rule will detect the attack, as shown here:

Amazon S3 bucket policy modified detection rule

Sample attack: Backdoor an IAM role

AWS IAM roles define specific permissions for identities within AWS. Identities (users or accounts) can assume IAM roles that they have been given appropriate permissions for. This allows those identities to access specific resources without using long-term static credentials like access keys. Backdooring an IAM role by modifying its assume role policy can allow an attacker to maintain persistence within an AWS environment

Stratus Red Team replicates this attack by creating an IAM role and then backdooring it by modifying its policy for continued access from an external, fictitious AWS account.

We can detonate this attack and subsequently clean up by using the CLI command stratus detonate aws.persistence.iam-backdoor-role --cleanup. Below is an example of the output of this command:

Expected output for AWS IAM role attack emulation

This attack can be observed by multiple Datadog out-of-the-box detection rules: AWS IAM AdministratorAccess policy was applied to a role and AWS IAM policy changes.

AWS IAM policy changed detection rule

Using Threatest for continuous validation

In order to further make the detection validation process efficient, Datadog’s open source project Threatest can be used to detonate an attack technique and verify that the alert you expect was generated in Datadog Cloud SIEM.

To get started, ensure that you have the $DD_API_KEY and $DD_APP_KEY environment variables from your Datadog account set on the local machine you’ll be testing from. Then define a scenarios.threatest.yaml file that will contain the attack technique and signal you expect from Cloud SIEM. Although Threatest can run Stratus Red Team attack techniques, you can also run arbitrary commands. For more information, check out the Threatest usage guide.

In the below example, we detonate the Stratus Red Team attack technique Backdooring an IAM Role and verify that the corresponding alert is created in Datadog.

---
scenarios:
- name: Backdooring an IAM Role
  detonate:
    stratusRedTeamDetonator:
      attackTechnique: aws.persistence.iam-backdoor-role
  expectations:
  - timeout: 15m
    datadogSecuritySignal:
      name: "AWS IAM AdministratorAccess policy was applied to a role"

We’ll then run threatest lint scenarios.threatest.yaml to make sure we have no syntax issues.

Finally, we’ll run threatest run scenarios.threatest.yaml to run the test scenario.

Threatest will invoke Stratus Red Team programmatically to detonate the attack technique and poll the Datadog API until the expected alert appears. Finally, it will close the alert in the Datadog platform.

---
INFO[0000] Running 1 scenarios with a parallelism of 1
INFO[0000] Detonating 'aws.persistence.iam-backdoor-role' with Stratus Red Team
INFO[0014] Execution ID: ee7c1379-6cac-41fd-8100-98e48a5d1360
INFO[0226] Backdooring an IAM Role: Confirmed that the expected signal (Datadog security signal 'AWS IAM AdministratorAccess policy was applied to a role') was created in Datadog (took 205 seconds).
INFO[0226] Backdooring an IAM Role: All assertions passed
INFO[0227] Scenario 'Backdooring an IAM Role' passed in 227.18 seconds
Continuous validation of AWS IAM policy was applied to a role detection rule

Get started emulating and detecting AWS threats with Stratus Red Team and Datadog Cloud SIEM

By harnessing the power of threat emulation and leveraging Stratus Red Team, cloud security teams can effectively improve their cloud detection capabilities against malicious activities while ensuring the resilience of their detection strategies using Datadog Cloud SIEM.

For more information about using Datadog Cloud SIEM with Stratus Red Team to detect and alert on AWS threats, see the Datadog AWS threat emulation guide.

If you’d like to learn more about Datadog’s overall security portfolio, be sure to check out our upcoming annual DASH conference, where we’ll cover our latest security features and detection and response capabilities. And if you’re interested in reading more about Datadog and security, visit our Security Labs blog.