Getting Started

Installation

Direct install (requires Go 1.23+):

go install -v github.com/datadog/stratus-red-team/v2/cmd/stratus@latest

Homebrew:

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

Linux / Windows / macOS: Download a pre-built binary.
Docker:

IMAGE="ghcr.io/datadog/stratus-red-team"
alias stratus="docker run --rm -v $HOME/.stratus-red-team/:/root/.stratus-red-team/ -e AWS_ACCESS_KEY_ID -e AWS_SECRET_ACCESS_KEY -e AWS_SESSION_TOKEN -e AWS_DEFAULT_REGION $IMAGE"

Concepts

An attack technique is a granular TTP that has prerequisites infrastructure or configuration. You can see the list of attack techniques supported by Stratus Red Team here.

Warming up an attack technique means making sure its prerequisites are met, without detonating it. Warm-up is a preparation phase, before executing the actual attack. Behind the scenes, Stratus Red Team transparently uses Terraform¹ to spin up and tear down the prerequisites of each attack technique.

Detonating an attack technique means executing it against a live environment, for instance against a test AWS account.

Reverting an attack technique means "cancelling" its detonation, when it had a side effect.

Cleaning up an attack technique means nuking all its prerequisites and making sure no resource is left in your environment.

An attack technique is idempotent if it can be detonated multiple times without reverting it.

Example

Let's take an example with the attack technique Exfiltrate EBS Snapshot through Snapshot Sharing.

Warm-up: Create an EBS volume and a snapshot of it
Detonation: Share the EBS snapshot with an external AWS account
Revert: Unshare the EBS snapshot with the external AWS account
Clean-up: Remove the EBS volume and its snapshot

State Machine

The diagram below illustrates the different states in which an attack technique can be.

Sample Usage

Stratus Red Team is a self-contained Go binary, embedding all the attack techniques it supports emulating.

You can list available attack techniques using:

stratus list

Detonating a specific attack technique is as simple as running:

stratus detonate aws.exfiltration.ec2-share-ebs-snapshot

You will get an output similar to:

2022/01/18 22:32:11 Checking your authentication against the AWS API
2022/01/18 22:32:12 Warming up aws.exfiltration.ec2-share-ebs-snapshot
2022/01/18 22:32:12 Initializing Terraform
2022/01/18 22:32:19 Applying Terraform
2022/01/18 22:32:43 Sharing the volume snapshot with an external AWS account ID...

You can then clean up any leftovers from the technique, which in this case will remove the EBS volume and EBS snapshot:

stratus cleanup aws.exfiltration.ec2-share-ebs-snapshot

For more information, see Usage, Examples and the Command Reference.

Connecting to your cloud account

Stratus Red Team currently supports AWS, Azure, Kubernetes, and Amazon EKS.

Warning

Stratus Red Team is supposed to be used against a sandbox cloud account that does not handle production workloads or infrastructure.

AWS

In order to use Stratus attack techniques against AWS, you need to be authenticated prior to running it, for instance:

Using aws-vault
Using static credentials in ~/.aws/config, and setting your desired AWS profile using export AWS_PROFILE=my-profile

EKS

Stratus Red Team does not create an EKS cluster for you. It assumes you're already authenticated to an EKS cluster.

To use Stratus attack techniques against Amazon EKS, you need to be authenticated against AWS, as described above. Stratus Red Team will use the current AWS credentials and Kubernetes context to interact with the EKS cluster. It will check that the Kubernetes cluster you're connected to is an EKS cluster, and refuse to run otherwise.

Authenticate to AWS (for instance, using aws-vault)
Run aws eks update-kubeconfig --name your-cluster-name --region your-region to update your ~/.kube/config file with the EKS cluster configuration

Azure

Use the Azure CLI to authenticate against your Azure tenant:

az login

Confirm you have access to at least one Azure subscription:

$ az account list
[
  {
    "cloudName": "AzureCloud",
    "homeTenantId": "9bd23af5-8f8b-4410-8418-2bc670d4829a",
    "id": "45e0ad3f-ff94-499a-a2f0-bbb884e9c4a3",
    "isDefault": true,
    "managedByTenants": [],
    "name": "Azure subscription 1",
    "state": "Enabled",
    "tenantId": "9bd23af5-8f8b-4410-8418-2bc670d4829a",
    "user": {
      "name": "you@domain.tld",
      "type": "user"
    }
  }
]

Set the environment variable AZURE_SUBSCRIPTION_ID:

export AZURE_SUBSCRIPTION_ID=45e0ad3f-ff94-499a-a2f0-bbb884e9c4a3

Note

When using Stratus Red Team with Azure, the location in which resources are created cannot be configured and is fixed to West US (California). See why here.

Microsoft Entra ID

Use the Azure CLI to authenticate against your Azure tenant:

az login

GCP

Use the gcloud CLI to authenticate against GCP:

gcloud auth application-default login

Then, set your project ID:

export GOOGLE_PROJECT=your-project-id

Kubernetes

Stratus Red Team does not create a Kubernetes cluster for you. Instead, it assumes you're already authenticated against a test Kubernetes cluster with kubectl and uses your default context.

As a rule of thumb, Stratus Red Team detonates attack techniques against the cluster you see when running kubectl cluster-info.

Tested with Minikube and AWS EKS.

Configuration File

You can create a configuration file at ~/.stratus-red-team/config.yaml (or use the STRATUS_CONFIG_PATH env var) to customize how Stratus Red Team creates resources. The configuration file is validated at startup.

kubernetes:
  # Default configuration applied to all Kubernetes techniques
  default:
    namespace: "security-testing"
    pod:
      image: "your-registry.example.com/busybox:stable"
      labels:
        app: "stratus-red-team"
        team: "your-team-name"
      tolerations:
        - key: "dedicated"
          operator: "Equal"
          value: "security"
          effect: "NoSchedule"
      node_selector:
        team: "security"

  # Per-technique overrides (merged on top of defaults)
  techniques:
    "k8s.privilege-escalation.privileged-pod":
      pod:
        image: "your-registry.example.com/busybox:stable"
        tolerations: ...

This is currently used for Kubernetes techniques and allows you to:

Use a specific namespace instead of creating one, when your user cannot create namespaces
Override container images, when only images from private registries are allowed
Add labels to pods (for attribution, CNP policy selectors, monitoring, etc.)
Add tolerations and node selectors for pod scheduling
Set a security context on containers

The default section applies to all techniques. The techniques section allows per-technique overrides, keyed by technique ID. Overrides are merged on top of defaults, you only need to specify the keys you want to change.

Note

Use the STRATUS_CONFIG_PATH environment variable to use a config file at a different location.

Encountering issues? See our troubleshooting page, or open an issue.

While Stratus Red Team uses Terraform under the hood, it doesn't mess with your current Terraform install nor does it require you to install Terraform as a prerequisite. Stratus Red Team will download its own Terraform binary in $HOME/.stratus-red-team. ↩