Atomic Red Team: MITRE ATT&CK Detection Tests for Security Teams

What Atomic Red Team Tests and Who Uses It

Detection engineering teams at organizations with security monitoring infrastructure face a practical problem: how do you know your detection rules and SIEM alerts actually fire when an attacker uses a technique they are supposed to catch? Manually simulating every adversary technique is slow, and hiring a red team for each detection validation cycle is expensive.

Atomic Red Team addresses this by providing a library of small, discrete tests, each simulating a specific adversary technique from the MITRE ATT&CK framework. The tests are designed to be run on the systems being monitored, generating the signals that detection tools should observe. Security engineers, blue teams, and detection content authors are the primary users. The README describes the tests as "quickly, portably, and reproducibly" executable.

How Tests Map to the MITRE ATT&CK Framework

MITRE ATT&CK is a publicly available knowledge base of adversary tactics and techniques observed in real-world attacks, organized into a matrix covering initial access, execution, persistence, privilege escalation, defense evasion, credential access, discovery, lateral movement, collection, command and control, exfiltration, and impact. Each Atomic Red Team test is mapped to one or more ATT&CK technique identifiers.

This mapping means that when a security team wants to verify coverage for a specific technique, they can look up the corresponding atomic tests and run them directly. The atomics/ directory at the repository root organizes tests by ATT&CK technique ID. Each test is defined in a YAML file that describes the technique, the test procedure, the required platform, cleanup steps, and the detection guidance.

The repository is described as community-developed and open source. New tests are contributed through pull requests, and the contribution guide is linked from the README via the project wiki.

Running Tests: No Installation Required

The README's first sentence on getting started is that atomic tests can be executed directly from the command line with no installation required. For individual tests, users can follow the YAML definition and manually execute the commands it describes on the target system. The Getting Started wiki page documents the specifics.

For a more structured approach, the README recommends Invoke-Atomic, a PowerShell-based execution framework at github.com/redcanaryco/invoke-atomicredteam. Invoke-Atomic reads the atomics/ YAML files and can run, test, and clean up atomic tests programmatically, which is more practical when running many tests or scheduling recurring detection verification.

The project also provides a Codespaces configuration for contributing Linux atomic tests directly from a browser-based development environment, which the README links to and highlights as a quick path for new contributors.

The Python Tooling Around the Test Library

The atomics/ YAML files are the core deliverable, but the repository also contains Python tooling used for validation, schema checking, and maintenance. The pyproject.toml shows a Python 3.11+ requirement and a dependency list that includes pyyaml for parsing YAML files, jsonschema for schema validation, pydantic for data modeling, and typer for command-line interfaces. The testing dependencies include pytest and hypothesis.

This Python layer is the contributor tooling, not something an end-user needs to install to run atomic tests. It ensures that contributed tests conform to the expected schema and that the atomics/ library remains internally consistent. The build system uses Poetry, and the project metadata lists the maintainer email as [email protected].

Where Atomic Red Team Has Limitations

Atomic Red Team is a detection validation tool, not a full adversary emulation platform. Each test is intentionally small and isolated: it simulates a specific technique, not a complete attack chain. This means it does not validate detection coverage for multi-step attacks or chained techniques, only for individual ATT&CK entries.

The tests generate signals only if the underlying monitoring infrastructure is in place and configured to observe them. Running atomic tests on a system with no EDR, SIEM, or logging configured produces no meaningful detection results. The value depends entirely on what is already observing the system.

Some tests require administrative or root privileges to execute. Running tests on production systems carries risk: cleanup steps are defined in the YAML, but a failed cleanup can leave artifacts behind. The README and community guidance strongly recommend using dedicated test environments.

The MIT license allows commercial use, but it places no restriction on using the tests for offensive purposes. Organizations deploying Atomic Red Team should have clear rules of engagement and authorization documented before running any tests.

Atomic Red Team vs CALDERA

CALDERA is a separate adversary emulation platform from MITRE, the same organization that created the ATT&CK framework. Where Atomic Red Team provides a library of discrete, individually executable tests, CALDERA is a server-based platform that chains techniques together into automated adversary operations. CALDERA agents run on target systems and execute operations as directed by a central server, making it suited for simulating multi-step attack chains.

The difference in approach is granularity and infrastructure. Atomic Red Team requires minimal setup: look at the YAML, run the command. CALDERA requires deploying a server, configuring agents, and building operations. Atomic Red Team is better for spot-checking specific technique coverage; CALDERA is better for simulating a complete attack campaign. Some security teams use both: Atomic Red Team for continuous detection validation and CALDERA for periodic full-chain exercises.

License, Maintenance, and Community

The repository is MIT licensed, which allows unrestricted use, modification, and redistribution. The last push was on 2026-09-14. The project has a Slack community at atomicredteam.io/slack, a newsletter at redcanary.com/atomic-newsletter/, and a wiki for documentation. Issues and feature requests go through GitHub.

The community development model means the quality and coverage of tests varies by ATT&CK technique. High-visibility techniques with broad detection tool support tend to have more tests and more maintained definitions than obscure or platform-specific techniques. Contributors can add tests via the GitHub contribution guide and the Codespaces integration.

Editorial conclusion

Security engineers who want to verify that their SIEM, EDR, or detection rules fire on known ATT&CK techniques should start with the atomics/ directory and run individual tests by hand against a non-production system before deploying Invoke-Atomic for automation. Teams without detection infrastructure in place first should invest in building that before running Atomic Red Team, since the tests produce results only as good as the logging and alerting pipeline that observes them.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. redcanaryco/atomic-red-team on GitHub