Skip to content

getting-started.md

Latest commit

 

History

History
234 lines (159 loc) · 8.53 KB

getting-started.md

File metadata and controls

234 lines (159 loc) · 8.53 KB
Raw

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
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 Terraform1 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.

![](./state-machine.png) State Machine of a Stratus Attack Technique

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](https://github.com/DataDog/stratus-red-team/discussions/125).

Microsoft Entra ID

  • Use the Azure CLI to authenticate against your Azure tenant:
az login

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 to customize behavior:

kubernetes:
  default:
    namespace: "security-testing" # Namespace for k8s techniques, for instance if your user is not allowed to create a namespace
    # You can add labels that can help you find the generated IoCs, attribute the pod, etc.
    labels:
      app: "stratus-red-team"
      team: "your-team-name"
    tolerations: # Tolerations, in case your cluster requires this kind of information to schedule pods correctly
      - key: "dedicated"
        operator: "Equal"
        value: "security"
        effect: "NoSchedule"
    nodeSelector:
      team: "security"
  techniques:
    "k8s.privilege-escalation.privileged-pod":
      image: "your-registry/busybox:stable"
      tolerations: ...

This is currently only used in some Kubernetes attacks and allows you to:

  • Add labels to your pods (Attribution, CNP policy selectors, monitoring...)
  • Use a specific namespace instead of creating one (if you don't want to give permissions to create namespaces)
  • Override container images (useful when there are restrictions to use only images from private registries)
  • Add tolerations and node selectors for pod scheduling
  • Use a custom SecurityContext

The kubernetes configuration has a default subsection. This subsection is applied to all techniques and can be overridden key by key in the techniques.attack-id subsection.

!!! 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.

*[TTP]: Tactics, techniques and procedures

Footnotes

  1. 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. ↩