Stratus Red Team is a tool developed by Datadog, inspired by Atomic Red Team, which allows you to automate the spinning up of vulnerable cloud resources, exploit vulnerabilities, and perform any clean up of the deployed infrastructure.

The value of carrying out these tests comes from finding out how discoverable the attacks are within our cloud environments. Do we have the appropriate levels of visibility, logging, monitoring, alerting, and remediation - whether through automation or manual playbooks - to deal with potential threats to our cloud estate?

How it works

Stratus Red Team works much like other testing strategies in software engineering, and aligns with the arrange, act, assert format.

image of a diagram showing the looping flow of the warmup, detonate, and cleanup commands using stratus red team
  1. Arrange - The warmup command deploys the necessary infrastructure to your cloud account, and the test is ready to go.
  2. Act - The detonate command triggers the Go cloud SDK code to execute the attack.
  3. You can then use the cleanup command to run a terraform destroy and remove the infrastructure from your cloud account.
  4. Assert - The command line displays insights into whether the test was successfully carried out, but unfortunately the assertion will likely be done manually by checking monitoring, alerts, and auto-remediation. Steps 1-3 can be looped through for each test, with step 4 being carried out afterwards.

Getting a list of available attack techniques

We can run the following command to get a list of possible techniques to deploy:

stratus list
Image showing the list of possible attack techniques that can be executed using stratus red team

My focus is on the AWS techniques; we will deploy and execute attacks within an AWS account and observe the actions being carried out.

Backdoor an IAM Role

I started by warming up the technique using:

stratus warmup aws.persistence.iam-backdoor-role
Image showing the warmup command for stratus red team

This command authenticates with AWS and deploys the prerequisite infrastructure for the attack.

Image showing the IAM Role with administrator permissions, which was created during warm up of the attack technique

Now that the technique is set up and ready to go, we can execute the attack using the detonate command:

stratus detonate aws.persistence.iam-backdoor-role
Image showing the detonate command for stratus red team

The attack adds a statement to the trust relationship of the IAM Role, with administrator permissions, which was created during warmup. This allows the AWS account 193672423079 root user to assume the IAM Role within our account, facilitating cross account administrator access.

image showing the trust relationship statement which was added in the AWS Console for IAM

Now the attack has been carried out successfully we can cleanup the attack and the infrastructure used for the technique with the cleanup command:

stratus cleanup aws.persistence.iam-backdoor-role
Image showing the cleanup script for stratus red team

Conclusion

The idea behind Stratus Red Team is a great one, and an area that organizations should be investing more attention to ensure their defences are robust enough.

I will use the Stratus Red Team attack techniques in follow up posts to show how we can detect and prevent attacks as they happen within our AWS accounts.

Although it's easy enough to install and get started with Stratus Red Team, an issue I've found is that the tool requires excessive permissions to deploy resources to an AWS account, which unfortunately might mean in an organization with mature security controls the tool might not be a viable option. Even while using my own test AWS account with over permissive temporary credentials, I still had some problems spinning up infrastructure for some of the tests.

A point worth highlighting is the nature of the resources and attacks being carried out. My example shows an IAM Role being manipulated to give assume role permissions to an external AWS account... although the account is an AWS owned account for Amazon Redshift logs, it's still actually carrying out the attack in your account.

I'd advise caution, and consider automating cleanup after warmup and detonation commands to prevent accidentally leaving vulnerable resources in your account. For the specific test I carried out the risk is small, but the resource names appear to be static, which means some other tests might be at higher risk of enumeration. That being said the tool is open source, so you can change details of the tests to satisfy your requirements.

If you've given Datadog Stratus Red Team a go, drop a comment with your experience. It would be great to hear how others are using the tool.

Notes

Image showing the region error

When deploying some of the Terraform, which runs under the hood, you might have to set a default AWS Region using (replace "eu-west-1" with an appropriate region):

export AWS_DEFAULT_REGION=eu-west-1

Here's a link to the GitHub repo to check it out for yourself: https://github.com/DataDog/stratus-red-team