DataDog/stratus-red-team: atomic attack emulation for cloud platforms

Installing one self-contained Go binary

There is no agent, no server and no cloud account to stand up. The install paths are all one command:

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

That needs Go 1.23 or newer. Homebrew works through a tap:

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

Pre-built binaries cover Linux, Windows and macOS from the releases page, and there is an asdf plugin for people pinning versions across a fleet. Docker is also documented, as a shell alias rather than a compose file:

IMAGE="ghcr.io/datadog/stratus-red-team"

One thing to know before using the container: it exists to run the tool, not to hold state. State lives under `~/.stratus-red-team/` in the container user's home, and the documented alias bind mounts that directory so warmup and cleanup survive between invocations. Getting that mount wrong means a detonate run has no record of what it created, and cleanup becomes guesswork.

The `Formula/` directory in the tree is the Homebrew formula, and `.goreleaser.yaml` is what produces the pre-built binaries for all three platforms.

The warmup, detonate, cleanup cycle is the actual interface

Stratus Red Team is described as Atomic Red Team for the cloud, and that analogy sets expectations correctly. Atomic Red Team is a library of small self-contained tests, and Stratus applies the same idea to cloud platforms. Each technique is self-contained, granular, and mapped to MITRE ATT&CK, which is the point: you are not trying to compromise anything, you are trying to confirm that a specific detection rule fires.

The workflow is three steps. Warmup creates the prerequisites a technique needs, such as the IAM user or the instance the technique will later abuse. Detonate performs the actual offensive action. Cleanup removes what warmup and detonate created. The README's development section shows the same subcommand family used directly against the source tree:

go run cmd/stratus/*.go list

`list` enumerates available attack techniques, and the documentation site carries the full list mapped to ATT&CK technique IDs.

The split matters more than it sounds. Warmup is deliberately slow and deliberately boring, because creating a realistic target is separate work from attacking it. It also means warmup is where most of the cost and most of the risk sits: the resources it creates are realistic enough that leaving them behind in a shared account is a genuine problem. The `state` directory inside the code and the state manager interface in the source both exist to make cleanup reliable.

Warmup cost, tags and prefixes, and what came in 2.36

Three releases are tagged, and together they show what actually makes this tool usable in a shared environment.

Version 2.36.0, released 2026-08-18, added the most important feature: correlation IDs. It lets you isolate concurrent executions by correlation ID, programmatically or by setting the `STRATUS_RED_TEAM_CORRELATION_ID` environment variable, so you can detonate techniques in the same environment without collisions or duplicate errors. That same release added configurable AWS tags and resource prefixes for resources created at warmup, driven by the configuration file. Both of these are about not fighting with your colleagues: one engineer running a technique should not collide with another engineer running a different one in the same account.

That release also added a new attack technique, deregistering an Amazon EC2 AMI, mapped under disruption, and the same pattern continues: version 2.35.0 from 2026-07-31 added an Azure technique for exfiltrating AI Foundry API keys under persistence, plus a documentation change mapping IAM role backdooring to ATT&CK technique T1098.003.

Version 2.36.1, from 2026-09-22, tightened things further: Azure correlation id propagation, an opt-out for the Terraform cache that fixed a concurrency issue, a bump of the azurerm Terraform provider to 4.81.0 to drop the dependency on the Azure CLI, unique resource names across all providers for concurrent detonation, and support for a KUBECONFIG holding multiple colon-separated paths. The Terraform angle is worth noting. Stratus creates its attack resources through Terraform, which is why the Docker image installs git at runtime, since Terraform needs it to fetch external modules while running.

Using it as a Go library rather than a command

The README points at the `examples/` directory for programmatic usage, and the directory names are a good index of what people actually build. There is `examples/basic/` for the simplest case, `examples/credential-injection/` for supplying cloud credentials, `examples/custom-logger/` for routing the tool's own log output into your pipeline, `examples/custom/` for a custom attack technique, and `examples/custom_expand_cli/` for extending the command line interface itself.

Three of those are about operations rather than detection. `examples/runner-options/` shows what you can change about how techniques execute, and `examples/s3-remote-state/` addresses the fact that Terraform needs somewhere to keep state, which in a CI environment means configuring S3 as a backend rather than relying on local files that vanish between runs.

`examples/detonate-and-dump-cloudtrail-logs/` is the one most worth reading if you are validating detections, because it closes the loop: detonate, then pull the relevant CloudTrail records, so you can check the audit trail directly rather than waiting for your SIEM to ingest and alert.

The release notes show this surface is kept current: the changelog for each release includes automated dependency bump entries naming the example directory affected, which means the examples are compiled and tracked rather than drifting.

What the repository root says about governance

This is one of the better-documented open source projects in the cloud security space, and the root of the tree is where that shows. The README badges include an OpenSSF Scorecard badge, a CII Best Practices badge, a test workflow badge and a static analysis workflow badge. Those four together are a claim about process rather than about code, and they are the ones most projects omit.

`SECURITY.md` exists, `LICENSE` is Apache 2.0 and there is a `LICENSE-3rdparty.csv` alongside it. That third party file is regenerated by a Makefile target rather than maintained by hand, using `go-licenses` to walk the dependency graph and emit CSV. Doing that automatically is the difference between a licence file that is current and one that is decorative.

`repository.datadog.yml` is a metadata file describing the repository for Datadog's own internal tooling, and `.adms/` appears in the changelog entries as the automated dependency management system that generates those per-example version bumps. `AGENTS.md` and `.claude/` sit at the root alongside the usual `.github/` workflows.

Documentation is MkDocs based, with `mkdocs.yml` at the root and the theme packages named in the README as `mkdocs-material` and `mkdocs-awesome-pages-plugin`. The docs directory is generated from the source by a `make docs` target that runs a Go program under `tools/`, which means the published site and the technique definitions cannot drift apart. The site itself lives at stratus-red-team.cloud.

How this sits against Atomic Red Team and the cloud SDKs

The comparison page on stratus-red-team.cloud lists the neighbours, and the README repeats four of them: Atomic Red Team from Red Canary, Leonidas from F-Secure, pacu from Rhino Security Labs, and Amazon GuardDuty Tester from AWS Labs. Placing the tool against these four makes its position clearer than any feature list would.

Against the cloud SDKs, pacu and GuardDuty Tester, the difference is intent and reversibility. The SDKs are general exploitation libraries: they can be used for many things and leave state that is yours to clean up. Stratus is built around a technique catalogue where every entry declares its own warmup and cleanup, which is what makes it safe to point at a shared account and safe to run in CI. The cost of that design is that you can only do what a technique already implements.

Against Atomic Red Team, Stratus is the cloud counterpart in the sense the project claims: same atomic granularity, same MITRE mapping, different platform. Leonidas sits in between, being an agent-style tool rather than an atomic one.

The honest limit is coverage. Techniques are added one at a time by contributors, so there will always be a gap between what ATT&CK describes and what this catalogue detonates, and the gap is widest on Azure and GCP where the project is newer. The technique list on the documentation site is the thing to read before planning a detection validation programme around it.

Editorial conclusion

stratus-red-team earns its place by being narrow where most tools are broad. It does not run campaigns or provide stealth, it detonates one mapped technique at a time so you can watch which detection fires, and the warmup, detonate, cleanup cycle is the whole workflow. Start with the available attack techniques list on stratus-red-team.cloud, pick one ATT&CK technique in a non-production account, and run the three subcommands in order rather than assuming cleanup will handle a failed detonation. If you want it in your own code, the Go library entry points under `examples/` cover the basic, credential injection, custom logger, runner options and Terraform remote state cases. The releases show where the work is going: correlation IDs for concurrent detonations, provider-level resource name uniqueness, and Azure correlation id propagation.

Frequently asked questions

Official sources

1. DataDog/stratus-red-team on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases