Lab: Adversary Simulation Detection with Stratus Red Team and GuardDuty

Detecting Adversaries with GuardDuty

Already Know Terraform?

If you're already familiar with Terraform, feel free to hop over to the AWS Security Cookbook by Tyler GitHub repository to grab and deploy the code. Otherwise, stick around and we'll walk through it together!

Overview

In this lab, we'll explore a free tool from DataDog called Stratus Red Team. To keep things short, I'll just refer to it as "stratus" from here on out. Stratus enables us to simulate adversarial attacks against cloud environments like AWS using attack techniques aligned to MITRE ATT&CK. It's a useful tool for evaluating our defenses and ensuring the ability to detect these techniques. We'll take a look at how we can use GuardDuty to detect some of these threats although it will not be able to detect everything. This is why it's crucial to continuously be testing our detection ability.

Deployment

Cost Alert

AWS GuardDuty is a paid service. Enabling related protection plans and features has an additional cost.

https://docs.aws.amazon.com/guardduty/latest/ug/monitoring_costs.html

Stratus Red Team deploys resources to your account, so depending on the attacks you choose to use, there may be additional costs.

We will reuse the code from Lab: Deploying AWS GuardDuty via Terraform

# clone the AWS Security Cookbook repository
git clone https://github.com/Ty182/AWS-Security-Cookbook-by-Tyler

# navigate to AWS GuardDuty directory
cd AWS_Cookbook_by_Tyler/recipes/aws_guardduty/Lab:Deploying_AWS_GuardDuty_via_Terraform

# initialize the directory and download the required terraform providers
terraform init

# check formatting and validate the syntax is correct
terraform fmt && terraform validate

# check the resources that will be created
terraform plan 

# deploy the resources
terraform apply

Validating Deployment

Make sure that your GuardDuty instance is functioning. You can run this command to check the presence of a detector. (Your detector id will be different)

aws guardduty list-detectors --region us-east-1                                                   
{
    "DetectorIds": [
        "38cb09ae7f41a0a239d93849ec821660"
    ]
}

Stratus Red Team

Installation

The official GitHub repo for stratus provides installation instructions. I'll be using Homebrew to install like so,

brew tap datadog/stratus-red-team https://github.com/DataDog/stratus-red-team
brew install datadog/stratus-red-team/stratus-red-team

We can then validate it installed,

stratus version 
2.23.1

Documentation

Stratus provides nice documentation so I won't duplicate here. Check out the User Guide or view all the types of attacks to dive deeper.

Attack Simulation

Disabling CloudTrail Logging

AWS GuardDuty is able to detect when CloudTrail logging gets disabled via Stealth:IAMUser/CloudTrailLoggingDisabled without enabling additional protection plans. Stratus can be used to test the detection. It works by creating a new CloudTrail trail and then stopping the trail.

Detonating the attack

stratus detonate aws.defense-evasion.cloudtrail-stop   
    
2025/04/07 21:51:55 Checking your authentication against AWS
2025/04/07 21:51:57 Warming up aws.defense-evasion.cloudtrail-stop
2025/04/07 21:51:57 Initializing Terraform to spin up technique prerequisites
2025/04/07 21:52:04 Applying Terraform to spin up technique prerequisites
2025/04/07 21:52:12 CloudTrail trail arn:aws:cloudtrail:us-east-1:796973515159:trail/stratus-red-team-ct-stop-trail-vtnvgeugpz ready
2025/04/07 21:52:12 Stopping CloudTrail trail stratus-red-team-ct-stop-trail-vtnvgeugpz

Checking trail status

We should be able to see the trail in AWS.

aws cloudtrail describe-trails | jq -r '.trailList[].Name'

stratus-red-team-ct-stop-trail-vtnvgeugpz

And check whether it's logging or not (it should be set to false)

aws cloudtrail get-trail-status --name stratus-red-team-ct-stop-trail-vtnvgeugpz | jq -r '.IsLogging'

false

Detecting the attack

Give this some time for the detection to show up. For me it took 17 minutes before the finding was available.

Clicking into this detection we can get some more info about the attack and the resources impacted.

Cleaning up the attack

stratus cleanup aws.defense-evasion.cloudtrail-stop --force 

2025/04/07 22:38:48 Cleaning up aws.defense-evasion.cloudtrail-stop
2025/04/07 22:38:48 Cleaning up technique prerequisites with terraform destroy
+-------------------------------------+-----------------------+--------+
| ID                                  | NAME                  | STATUS |
+-------------------------------------+-----------------------+--------+
| aws.defense-evasion.cloudtrail-stop | Stop CloudTrail Trail | COLD   |
+-------------------------------------+-----------------------+--------+

S3 Ransomeware via Client-Side Encryption

AWS GuardDuty detected this S3 ransomware attack via AttackSequence:S3/CompromisedData which requires the S3 Protection Plan. Stratus can be used to test the detection. It works by creating an S3 bucket with objects and then re-encrypting them with an external KMS key thereby mimicking a ransomware attack.

Detonating the attack

stratus detonate aws.impact.s3-ransomware-client-side-encryption

2025/04/07 22:46:17 Checking your authentication against AWS
2025/04/07 22:46:19 Warming up aws.impact.s3-ransomware-client-side-encryption
2025/04/07 22:46:19 Initializing Terraform to spin up technique prerequisites
2025/04/07 22:46:24 Applying Terraform to spin up technique prerequisites
2025/04/07 22:46:36 S3 bucket stratus-red-team-ransomware-bucket-snqkxj containing 51 fake objects ready
2025/04/07 22:46:36 Simulating a ransomware attack on bucket stratus-red-team-ransomware-bucket-snqkxj
2025/04/07 22:46:40 Successfully downloaded all objects from the bucket
2025/04/07 22:46:40 Listing objects in bucket stratus-red-team-ransomware-bucket-snqkxj
2025/04/07 22:46:40 Found 51 objects to encrypt
2025/04/07 22:46:40 Encrypting all objects one by one with the secret AES256 encryption key '427fc7323cfb4b58f630789d372476fb'
2025/04/07 22:46:45 Successfully encrypted all objects in the bucket
2025/04/07 22:46:45 Uploading fake ransom note

Detecting the attack

Give this some time for the detection to show up. For me it took nearly an hour before the finding was available.

Clicking into this detection we can get some more info about the attack and the resources impacted.

Cleaning up the attack

stratus cleanup aws.impact.s3-ransomware-client-side-encryption --all --force 

2025/04/07 22:50:16 Cleaning up aws.impact.s3-ransomware-client-side-encryption
2025/04/07 22:50:16 Reverting detonation of technique aws.impact.s3-ransomware-client-side-encryption
2025/04/07 22:50:16 Decrypting all files in the bucket
2025/04/07 22:50:16 Listing objects in bucket stratus-red-team-ransomware-bucket-snqkxj
2025/04/07 22:50:17 Found 52 objects to encrypt
2025/04/07 22:50:17 Decrypting all objects one by one with the secret AES256 encryption key '427fc7323cfb4b58f630789d372476fb'
2025/04/07 22:50:29 Successfully encrypted all objects in the bucket
2025/04/07 22:50:29 Cleaning up technique prerequisites with terraform destroy
+-------------------------------------------------+----------------------------------------------+--------+
| ID                                              | NAME                                         | STATUS |
+-------------------------------------------------+----------------------------------------------+--------+
| aws.impact.s3-ransomware-client-side-encryption | S3 Ransomware through client-side encryption | COLD   |
+-------------------------------------------------+----------------------------------------------+--------+

Backdoor an IAM User

AWS GuardDuty will not detect this technique unless it can be correlated with other anomalous/suspicious activity. Stratus creates an IAM Access Key for an IAM User which is a technique adversaries might use to maintain access in an environment. IAM Users can have up to 2 access keys.

Detonating the attack

stratus detonate aws.persistence.iam-backdoor-user  
                                                 
2025/04/07 22:16:11 Checking your authentication against AWS
2025/04/07 22:16:13 Warming up aws.persistence.iam-backdoor-user
2025/04/07 22:16:13 Initializing Terraform to spin up technique prerequisites
2025/04/07 22:16:19 Applying Terraform to spin up technique prerequisites
2025/04/07 22:16:24 IAM user stratus-red-team-backdoor-u-user ready
2025/04/07 22:16:24 Creating access key on legit IAM user to simulate backdoor
2025/04/07 22:16:24 Successfully created access key AKIA[SNIP]

Checking IAM User

We can validate the access key was created.

aws iam list-access-keys --user-name stratus-red-team-backdoor-u-user

{
    "AccessKeyMetadata": [
        {
            "UserName": "stratus-red-team-backdoor-u-user",
            "AccessKeyId": "AKIA[SNIP]",
            "Status": "Active",
            "CreateDate": "2025-04-08T04:16:25+00:00"
        }
    ]
}

Detecting the attack

As mentioned, GuardDuty doesn't pick up on this particular action unless the access key is later used for malicious/anomalous activity which can be picked up by other GuardDuty findings types. However, we can rely on CloudTrail logs to discover the activity (and the same can be done for the other attacks).

If there isn't a CloudTrail lab by the time you're reading this, I'll have one in the future.

The CloudTrail event name is called CreateAccessKey and the raw log can be seen below.

{
    "eventVersion": "1.10",
    "userIdentity": {
        "type": "IAMUser",
        "principalId": "AIDA3TD2SYGLUBO6EUVLE",
        "arn": "arn:aws:iam::111111111111:user/stratus",
        "accountId": "111111111111",
        "accessKeyId": "AKIA3T[SNIP]",
        "userName": "stratus"
    },
    "eventTime": "2025-04-08T04:16:25Z",
    "eventSource": "iam.amazonaws.com",
    "eventName": "CreateAccessKey",
    "awsRegion": "us-east-1",
    "sourceIPAddress": "[SNIP]",
    "userAgent": "stratus-red-team_588b9cbb-c712-4e8e-841f-604e6e6b7b78",
    "requestParameters": {
        "userName": "stratus-red-team-backdoor-u-user"
    },
    "responseElements": {
        "accessKey": {
            "userName": "stratus-red-team-backdoor-u-user",
            "accessKeyId": "AKIA3T[SNIP]",
            "status": "Active",
            "createDate": "Apr 8, 2025, 4:16:25 AM"
        }
    },
    "requestID": "16d3e3ef-e863-47f7-b5cc-ddd22445a479",
    "eventID": "8a210698-8dcd-4817-9e3a-687315b823a1",
    "readOnly": false,
    "eventType": "AwsApiCall",
    "managementEvent": true,
    "recipientAccountId": "111111111111",
    "eventCategory": "Management",
    "tlsDetails": {
        "tlsVersion": "TLSv1.3",
        "cipherSuite": "TLS_AES_128_GCM_SHA256",
        "clientProvidedHostHeader": "iam.amazonaws.com"
    }
}

Cleaning up the attack

stratus cleanup aws.persistence.iam-backdoor-user --all --force

2025/04/07 23:28:18 Cleaning up aws.persistence.iam-backdoor-user
2025/04/07 23:28:18 Cleaning up technique prerequisites with terraform destroy
+-----------------------------------+-------------------------------------+--------+
| ID                                | NAME                                | STATUS |
+-----------------------------------+-------------------------------------+--------+
| aws.persistence.iam-backdoor-user | Create an Access Key on an IAM User | COLD   |
+-----------------------------------+-------------------------------------+--------+

Cleanup

Clean up the resources

Avoid unnecessary costs by deleting the created resources (your GuardDuty deployment)

terraform destroy

This should delete all resources created by Stratus

stratus cleanup <attack> --all --force

e.g., stratus cleanup aws.persistence.iam-backdoor-user --all --force

PreviousLab: Logging GuardDuty Findings to S3 NextAWS Organizations

Last updated 1 month ago

Was this helpful?