Adversary emulation on AWS with Stratus Red Team and Wazuh

Adversary emulation provides a way to test the resilience of infrastructure in response to advanced cyber attacks. It helps verify that an organization’s security tools are functioning as required, whether closed source or open source. This approach allows defenders to utilize cyber threat intelligence to better understand and combat real-world adversaries.

In the cloud, these emulations can be particularly challenging due to the distributed and dynamic nature of cloud environments. However, with the right tools and techniques, it is possible to effectively conduct adversary emulation in the cloud. 

Stratus Red Team is a collection of cloud-native attacks written in Go programming language. It contains various red team automated attacks for AWS, Azure, Kubernetes, and GCP. All the attacks are mapped with MITRE ATT&CK tactics and executed via CLI.

This blog post focuses on emulating attacks on AWS infrastructure, and using Wazuh security capabilities to detect and alert in real time. 

Infrastructure for adversary emulation

Stratus Red Team automatically creates the necessary infrastructure using Terraform and attacks it so that we can analyze the whole process and respond efficiently. Thus, frees the user from creating any resources such EC2 instances, S3 buckets, and IAM roles. For this, it requires the emulation endpoint to have valid credentials to an AWS account.

Also, it is not required to install Terraform since it is already embedded in its packages.

The main source for monitoring these attacks on AWS is the built-in CloudTrail logging. In our test environment, we ingest these logs into the Wazuh server for analysis using the Wazuh module for AWS. This module allows gathering and parsing logs from multiple AWS services.

Key concepts for a Stratus Red Team attack execution

• Warmup: Uses Terraform to spin up the prerequisite infrastructure without detonating. Initially, all attacks are in a cold state.
• Detonate: Executes the attack technique when the infrastructure  is in a warm state.
• Revert: Reverts to a warm state where an attack can be detonated again.
• Cleanup: Removes all prerequisite infrastructure from the environment. This sets the infrastructure in a cold state.

Detection with Wazuh

Requirements

• A pre-built ready-to-use Wazuh OVA 4.3.10. Follow this guide to download the virtual machine.
• An AWS account with AdministratorAccess permission. We recommend using a test account that does not handle production workloads.
• A local endpoint to install Stratus Red Team and run the attacks against AWS infrastructure. We used Ubuntu 22.04 in this blog post.

Configure CloudTrail service

1. Access the CloudTrail service using the AWS console.

2. Go to CloudTrail > Create trail to start creating a new trail.

3. Choose between creating a new S3 bucket or specifying an existing one to store CloudTrail logs. Note down the name of the S3 bucket used as it’s necessary to specify it in the Wazuh configuration.

Configure AWS credentials

Perform the following steps on both the Wazuh server and the emulation endpoint to authenticate to your AWS account and manage your resources from the command line.

1. Download and install the AWS CLI:

$ if [ -f /etc/lsb-release ]; then sudo apt-get update -y && sudo apt-get install -y unzip; elif [ -f /etc/centos-release ]; then sudo yum update -y && sudo yum install -y unzip; else echo "Unsupported OS. Can't install unzip."; fi
$ curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
$ unzip awscliv2.zip
$ sudo ./aws/install

2. Configure your AWS credentials: To do this, run the following command and follow the prompts to enter your AWS Access Key ID, AWS Secret Access Key, and AWS_REGION.
You can find your access keys in the AWS Management Console under “My Security Credentials”.

$ sudo /usr/local/bin/aws configure

3. Verify the configuration: In ~/.aws/ directory, check that your config and credentials  files look as follows:

config

[default]
region = <AWS_REGION>

credentials

[default]
aws_access_key_id = AKIXXTYHXXXXXXXXX
aws_secret_access_key = /VTwSJDmSk9cxxx+xxxxxxxxxxxxxx

4. Run a simple AWS CLI command to test the connection to your AWS account:

$ sudo /usr/local/bin/aws s3 ls

2023-01-09 12:26:07 aws-cloudtrail-logs-729622462904-xxxxxxxx
2023-01-05 06:19:59 aws-cloudtrail-logs-729622462904-xxxxxxxx

This command lists the Amazon S3 buckets in your account. If the command executes successfully, it means that you have successfully authenticated to your AWS account.

Configure the emulation endpoint

Take the following steps to install Stratus Red Team on your emulation endpoint to perform the attacks. 

1. Download Stratus Red Team binary:

$ wget https://github.com/DataDog/stratus-red-team/releases/download/v2.4.10/stratus-red-team_2.4.10_Linux_x86_64.tar.gz
$ tar xvf stratus-red-team_2.4.10_Linux_x86_64.tar.gz

2. Test Stratus Red Team by listing the attacks available for AWS:

$ sudo su
# ./stratus list | grep 'aws.' | awk '{ print $ sudo su
# ./stratus list | grep 'aws.' | awk '{ print $2 }' | cat -n }' | cat -n

     1	aws.credential-access.ec2-get-password-data
     2	aws.credential-access.ec2-steal-instance-credentials
     3	aws.credential-access.secretsmanager-retrieve-secrets
     4	aws.credential-access.ssm-retrieve-securestring-parameters
     5	aws.defense-evasion.cloudtrail-delete
     …

3. Export your profile and region as environment variables for Stratus:

# export AWS_PROFILE=<AWS_PROFILE_NAME>
# export AWS_REGION=<AWS_REGION>

Replace <AWS_REGION> with your AWS region and <AWS_PROFILE_NAME> with your current profile. For example, us-east-1 and default.

Configure the Wazuh server for log ingestion and detection

1. From the Wazuh dashboard, navigate through Settings > Modules and enable the Amazon AWS module dashboard which is disabled by default.

2. Enable the Wazuh AWS module in the Wazuh server /var/ossec/etc/ossec.conf configuration file:

<wodle name="aws-s3">
  <disabled>no</disabled>
  <remove_from_bucket>no</remove_from_bucket>
  <interval>10m</interval>
  <run_on_start>yes</run_on_start>
  <skip_on_error>no</skip_on_error>

  <bucket type="cloudtrail">
    <name><AWS_BUCKET_NAME></name>
    <aws_profile><AWS_PROFILE_NAME></aws_profile>
  </bucket>
</wodle>

Replace <AWS_BUCKET_NAME> with the bucket attached to your trail and <AWS_PROFILE_NAME> with your current profile.

Add only the AWS buckets of interest.

3. Create a custom rule file named amazon_rules.xml on the Wazuh server /var/ossec/etc/rules/ directory and add the following custom rules:

<group name="amazon,aws,">

<!-- Rules to detect attempts to retrieve RDP passwords on a high number of Windows EC2 instances -->

 <rule id="100100" level="5" >
    <if_sid>80200</if_sid>
    <field name="aws.eventName" type="pcre2">GetPasswordData</field>
    <description>Credentials access : Attempt to retrieve EC2 credentials</description>
    <mitre>
      <id>T1530</id>
    </mitre>
  </rule>

  <rule id="100101" level="12" frequency="15" timeframe="300">
    <if_matched_sid>100100</if_matched_sid>
    <description>Credentials access : Multiple attempts to retrieve EC2 credentials</description>
    <mitre>
      <id>T1530</id>
    </mitre>
  </rule>

<!-- Rule to detect newly-created security group policies that allow ingress channels over port 22  -->

  <rule id="100102" level="12">
    <if_sid>80202</if_sid>
    <field name="aws.eventName" type="pcre2">AuthorizeSecurityGroupIngress</field>
    <field name="aws.requestParameters.cidrIp" type="pcre2">0.0.0.0\/0</field>
    <field name="aws.requestParameters.fromPort" type="pcre2">22</field>
    <field name="aws.requestParameters.toPort" type="pcre2">22</field>
    <description>Security group with inbound rules allowing $(aws.requestParameters.cidrIp) on port $(aws.requestParameters.fromPort) detected</description>
    <mitre>
      <id>T1562.007</id>
      <id>T1105</id>
      <id>T1041</id>
    </mitre>
  </rule>

<!-- Rule to detect IAM role backdooring -->

  <rule id="100103" level="12">
    <if_sid>80202</if_sid>
    <field name="aws.eventName" type="pcre2">CreateRole|UpdateAssumeRolePolicy</field>
    <match type="pcre2">sts:AssumeRole</match>
    <description>Possible IAM Role backdooring: IAM role granted from an external account</description>
    <mitre>
      <id>T1098.001</id>
    </mitre>
  </rule>

<!-- Rule to detect when a CloudTrail event selector is used to disable management events -->

  <rule id="100104" level="12">
    <if_sid>80200</if_sid>
    <field name="aws.eventName" type="pcre2">PutEventSelectors</field>
    <field name="aws.requestParameters.eventSelectors.includeManagementEvents" type="pcre2">false</field>
    <description>Possible disruption of CloudTrail Logging: Management events logging disabled with an event selector</description>
    <mitre>
      <id>T1562.008</id>
    </mitre>
  </rule>

</group>

Where:

• Rule ID 100100 detects when someone tries to retrieve the encrypted administrator password for a running Windows instance. 
• Rule ID 100101 detects a large number of requests made for ec2:GetPasswordData API call in a short time interval for running Windows Instances.
• Rule ID 100102 detects an adversary exfiltrating data from an Amazon Web Services (AWS) Elastic Compute Cloud (EC2) instance by exploiting an open inbound port 22 (SSH) on the instance’s security group. 

This rule is effective for organizations that strictly follow the principle of “least privilege” when it comes to access. It can be customized to fit the specific security practices and protocols of an organization, specifically in regard to security groups.

• Rule ID 100103 detects when a role is created or modified with the permission "sts:AssumeRole" granted to an external AWS account. Our detection logic monitors both CreateRole and UpdateAssumeRolePolicy events respectively.
• Rule ID 100104 detects when a PutEventSelectors API call uses event selectors to disable logging of management event logging on an existing CloudTrail.

4. Restart the Wazuh manager to apply the changes:

$ sudo systemctl restart wazuh-manager

Attack emulation

On the emulation endpoint, perform the following four attacks to test our ruleset.

Retrieve EC2 Password Data

This attack emulates an adversary attempting to retrieve RDP passwords on Windows EC2 instances:

# ./stratus warmup aws.credential-access.ec2-get-password-data 
# ./stratus detonate aws.credential-access.ec2-get-password-data

Open Ingress Port 22 on a Security Group

This attack emulates an adversary exfiltrating data from an AWS EC2 instance by exploiting an open inbound port 22 (SSH) on the instance’s security group:

# ./stratus warmup aws.exfiltration.ec2-security-group-open-port-22-ingress
# ./stratus detonate aws.exfiltration.ec2-security-group-open-port-22-ingress

In a production environment, this API call may be legitimate as port 22 allows for remote administration. Thus, in order to reduce the amount of false-positives, it is important to ensure that security groups are configured securely and that only necessary ports are opened. This includes closing unnecessary inbound ports, such as port 22 (SSH) if it is not needed, and implementing strong authentication measures, such as multi-factor authentication, to protect against unauthorized access.

Backdoor an IAM Role

This attack emulates an adversary establishing persistence by backdooring an IAM role policy with a malicious policy:

# ./stratus warmup aws.persistence.iam-backdoor-role 
# ./stratus detonate aws.persistence.iam-backdoor-role

Once this privilege is granted, the external account can use it to access the role and carry out actions within the compromised AWS account.

Disable CloudTrail logging through EventSelectors

This attack emulates an adversary disrupting CloudTrail Logging by creating an event selector on the trail that excludes all management events:

# ./stratus warmup aws.defense-evasion.cloudtrail-event-selectors 
# ./stratus detonate aws.defense-evasion.cloudtrail-event-selectors

Cleanup the infrastructure

At the end of the emulation, use the following command to destroy all the infrastructure created:

$ ./stratus cleanup --all

Detection results

On the Wazuh dashboard, navigate to Modules > Security events.

Then use the following to filter the alerts: rule.id: is one of 100101, 100102, 100103, 100104, or go directly to  Modules > Amazon AWS > Events to view all AWS events.

Conclusion

The use of cloud infrastructure is on the rise, and with that, the need to ensure the security of these environments is also increasing. Adversary emulation is a great way to evaluate the security of an environment.

By using Stratus Red Team to orchestrate and automate attack emulations, organizations can gain a deeper understanding of their cloud security posture. Furthermore, by using Wazuh to detect and respond to these emulations, organizations can improve their defenses against potential threats.

References

• FalconFriday — Detecting realistic AWS cloud-attacks using Azure Sentinel — 0xFF1C
• Stratus Red Team – User Guide
• AWS Threat Simulation and detection