emulating-cloud-attacks-with-stratus-red-team

Files (5)

• LICENSE
• SKILL.md
• api-reference.md · references/
• standards.md · references/
• agent.py · scripts/

SKILL.md (first lines)

# Emulating Cloud Attacks with Stratus Red Team

> **Legal Notice:** This skill is for authorized security testing and detection-validation purposes only. Stratus Red Team spins up and modifies real cloud infrastructure in the account whose credentials you supply. Only run it in accounts you own or are explicitly authorized to test. Always `cleanup` afterwards to avoid orphaned, billable, or insecure resources. Unauthorized use against systems you do not control is illegal.

## Overview

Stratus Red Team is an open-source "Atomic Red Team for the cloud," maintained by Datadog. It is a self-contained Go binary that programmatically *detonates* granular, well-documented offensive techniques against AWS, Azure, GCP, and Kubernetes, then lets you cleanly revert and remove everything it created. Unlike a full exploitation framework, Stratus is purpose-built for **detection engineering and purple teaming**: each technique maps to a MITRE ATT&CK tactic and ships with a precise description of the cloud API calls it generates, so a blue team can confirm whether their CloudTrail/GuardDuty/Sentinel/Falco detections actually fire.

Every technique has a deterministic lifecycle. Stratus first provisions any prerequisite infrastructure with embedded Terraform (the **warmup** phase), then performs the malicious actions (**detonate**), optionally **revert**s the side effects so you can detonate again, and finally **cleanup**s the prerequisite infrastructure. Because the prerequisites and the attack are decoupled, you can iterate on a detection by detonating the same technique repeatedly without re-provisioning. The tool uses your standard cloud SDK credential chain (AWS profiles/env vars, `az login`, GCP ADC, kubeconfig), so it operates with exactly the permissions of the identity you authenticate as.

This skill covers installing Stratus, listing and filtering the technique catalog, running the full warmup-detonate-revert-cleanup lifecycle, mapping detonations to the telemetry they produce, and wiring the results into a detection-validation workflow. Source: github.com/DataDog/stratus-red-team and stratus-red-team.cloud official documentation.

## When to Use

- Validating that a new or existing cloud detection rule (CloudTrail, GuardDuty, Microsoft Sentinel, GCP SCC, Falco) actually triggers on real attacker activity
- Building a repeatable purple-team exercise for cloud TTPs without writing bespoke attack scripts
- Generating realistic, MITRE-mapped telemetry to test SIEM ingestion and alert routing
- Measuring detection coverage of a cloud environment against a known catalog of techniques
- Onboarding analysts with safe, reversible hands-on cloud attack simulations

## Prerequisites

- Stratus Red Team binary (Go 1.23+ to build from source, or Homebrew/Docker):
  ```bash
  # Go install
  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

  # Docker
  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 \
    ghcr.io/datadog/stratus-red-team list
  ```
- Authenticated cloud credentials for the target provider:
  ```bash
  # AWS — verify identity before detonating
  export AWS_PROFILE=stratus-lab
  aws sts get-caller-identity

  # Azure
  az login

  # GCP
  gcloud auth application-default login

  # Kubernetes
  kubectl config current-context
  ```
- A dedicated, non-production lab account or subscription (techniques create real resources)
- Terraform is embedded; no separate install is required, but outbound HTTPS to download provider plugins on first warmup is needed

## Objectives

- Install Stratus Red Team and confirm the target cloud identity
- Enumerate and filter techniques by platform and MITRE ATT&CK tactic
- Execute the warmup -> detonate -> revert -> cleanup lifecycle safely
- Map each detonation to the cloud API calls and log sources it generates
- Validate detection rules against the produced telemetry and track coverage
- Guarantee no residual infrastructure remains after testing

## MITRE ATT&CK Mapping

| ID | Name | Use in this skill |
|----|------|-------------------|
| T1078 | Valid Accounts | Emulation runs as a valid cloud identity; many techniques abuse legitimate credentials/API access |
| T1078.004 | Valid Accounts: Cloud Accounts | e.g. `aws.credential-access.ec2-steal-instance-credentials` produces cloud-account abuse telemetry |
| T1580 | Cloud Infrastructure Discovery | Discovery-tactic techniques such as `aws.discovery.*` |
| T1530 | Data from Cloud Storage | Exfiltration techniques such as `aws.exfiltration.ec2-share-ebs-snapshot` |
| T1098 | Account Manipulation | Persistence techniques such as `aws.persistence.iam-create-admin-user` |

## Workflow

### 1. Confirm identity and list the technique catalog
Always confirm which account you are about to attack, then browse the catalog.
```bash
aws sts get-caller-identity
stratus list
# Filter to a single platform
stratus list --platform aws
# Filter by MITRE ATT&CK tactic
stratus list --mitre-attack-tactic credential-access
```

### 2. Inspect a specific technique before running it
Read exactly what a technique will do and which detonation/telemetry it produces.
```bash
stratus show aws.credential-access.ec2-steal-instance-credentials
```

### 3. Warm up prerequisite infrastructure
Provision the prerequisites with embedded Terraform without performing the attack yet.
```bash
stratus warmup aws.credential-access.ec2-steal-instance-credentials
stratus status
```

### 4. Detonate the technique
Execute the malicious actions; this is what your detections must catch. Warmup is implicit if not already done.
```bash
stratus detonate aws.credential-access.ec2-steal-instance-credentials
# Detonate and force a re-warmup in one step
stratus detonate aws.persistence.iam-create-admin-user --force
```

### 5. Inspect status and the telemetry generated
Check lifecycle state, then pull the corresponding control-plane logs to confirm the attack landed.
```bash
stratus status
# Pull recent CloudTrail events to verify the detonation
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=CreateAccessKey \
  --max-results 10
```

### 6. Validate the detection
Confirm your SIEM/detection fired. Example: query Athena/CloudTrail or check GuardDuty findings.
```bash

From mukul975/Anthropic-Cybersecurity-Skills, Apache-2.0.

More from mukul975/Anthropic-Cybersecurity-Skills