Red Canary’s Atomic Red Team library has quietly become one of the most widely cloned security repositories on GitHub, and 2026 gave it two reasons to matter more than ever. First, MITRE shipped ATT&CK version 19, splitting the old Defense Evasion tactic into two separate tactics, Stealth and Defense Impairment, which broke test mappings that security teams had relied on for years, and MITRE’s own site now announces that ATT&CK v20 has been released, so the v19.2 named in the title is no longer the newest release. Second, Red Canary itself changed hands: Zscaler closed its $651.4 million acquisition of the company on August 1, 2025, folding Atomic Red Team’s maintainers into a much larger security vendor. Anyone running adversary emulation tests against outdated mappings, or assuming the project’s ownership and roadmap haven’t shifted, is working from a stale picture.
This tutorial walks through a full atomic red team setup from a clean virtual machine to a working purple-team exercise: installing the execution framework, pulling the current atomics library, checking and resolving prerequisites, running tests safely, validating detections, cleaning up afterward, and automating the whole cycle. Thirteen numbered steps, five-plus code blocks, a working multi-technique project, and a troubleshooting section cover the gaps that trip up most first-time users. By the end, you’ll have a repeatable process you can run on a schedule, not a one-off exercise that gets forgotten after the first demo to leadership.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
What Atomic Red Team Actually Does
Atomic Red Team is an open-source library of small, single-technique tests, called atomics, each mapped to a specific MITRE ATT&CK technique or sub-technique. The project lives at redcanaryco/atomic-red-team on GitHub, carries roughly 12,600 stars, and ships under the MIT license. Each atomic test is defined in a structured YAML file that documents the technique it exercises, the platforms it supports, any prerequisites, the exact command to run, cleanup steps, and input arguments you can override.
Crucially, atomic red team tests are narrow by design. A single atomic might just spawn a suspicious child process, drop a file in an unusual location, or query a credential store, mirroring one documented adversary behavior rather than a full breach chain. That focus is what makes the library useful for detection engineering: when an atomic test fires and your SIEM stays silent, you’ve found a real coverage gap, not noise from an overly complex simulated attack.
This narrow scope is also why Atomic Red Team pairs so naturally with detection-as-code practices. Instead of waiting for a real intrusion to reveal whether a detection rule actually works, a team can run the exact atomic that exercises the behavior the rule claims to catch, on a schedule they control, with full knowledge of what should happen. That turns detection validation from a reactive, after-the-fact exercise into a proactive one that fits into the same release cadence as the rules themselves, whether those rules live in a commercial EDR console or a self-managed rule set.
The official project FAQ is explicit that Atomic Red Team has no built-in mechanism for chaining tests into a full adversary campaign automatically. If you want to emulate “APT29’s attack chain,” you select the relevant atomics and run them in sequence yourself, or you reach for a different tool. That limitation shapes several of the steps below, including the multi-technique project near the end of this guide.
Understanding the Atomic Test File Format
Every atomic test is a YAML document, and understanding its shape before you start running tests makes the rest of this tutorial far less mysterious. The schema is public and documented in the atomic-red-team repository itself, and a simplified version of a typical test looks like this:
attack_technique: T1059.001
display_name: PowerShell
atomic_tests:
- name: PowerShell Command Execution
auto_generated_guid: 4fdf4-example
description: Execute a basic command via powershell.exe
supported_platforms:
- windows
input_arguments:
command_to_execute:
description: Command to run
type: string
default: Write-Host "atomic test"
executor:
command: |
powershell.exe -Command "#{command_to_execute}"
cleanup_command: |
Remove-Item -Path C:\temp\atomic-artifact.txt -ErrorAction Ignore
name: command_promptFour fields matter most when you’re deciding whether to run a given test: supported_platforms tells you whether it applies to your lab at all, input_arguments shows you what you can safely override instead of running the default, executor.command is the literal thing that will execute on your host, and executor.cleanup_command tells you whether the framework can revert the change automatically or whether you’ll need to do it by hand. Reading this block is what -ShowDetails renders for you in Step 8, so once you understand the underlying YAML, the command-line output stops feeling like a black box.
Who Runs Atomic Red Team and How Often
Atomic Red Team sits at the intersection of two functions that don’t always talk to each other: offensive testing and detection engineering. In most organizations that run it successfully, it isn’t owned by a single standalone “red team” but by a purple-team function, a small working group that pairs someone comfortable running adversary-style commands with someone who owns the detection rules those commands are supposed to trigger. That pairing matters because the value of an atomic red team exercise isn’t the test execution itself, it’s the conversation that happens immediately afterward about why an alert did or didn’t fire.
Smaller security teams often run this as a part-time responsibility rotated among two or three engineers rather than a dedicated full-time role, since a single test run with proper mapping and cleanup rarely takes more than a few minutes once the lab is built. Larger security operations centers tend to formalize it into a recurring calendar item, commonly tied to major change events: a new detection rule shipping, a SIEM migration, an EDR agent upgrade, or a quarterly compliance cycle. None of that cadence is officially mandated by Red Canary or MITRE, so treat it as a starting point to adapt rather than a fixed rule, and lean on Atomic Runner, covered in Step 13, once the manual cadence is established and you want lighter continuous checks between full exercises.
Atomic Red Team vs Caldera vs Stratus Red Team
Atomic Red Team is not the only adversary emulation option, and picking the wrong one for your use case wastes a setup cycle. MITRE Caldera is a full automated adversary emulation platform with a server, agents, and planner logic that can chain techniques into an orchestrated campaign without manual sequencing. Stratus Red Team, by comparison, focuses specifically on cloud control-plane attacks (AWS, Azure, GCP) rather than endpoint behavior. The table below lines up the three on the dimensions that matter when you’re choosing.
| Tool | Maintainer | Execution model | Primary target | Attack chaining | License |
|---|---|---|---|---|---|
| Atomic Red Team | Red Canary (Zscaler) | Invoke-AtomicRedTeam PowerShell module, per-test | Windows, Linux, macOS, IaaS | Manual, test by test | MIT |
| MITRE Caldera | MITRE | Server + deployed agents, automated planner | Windows, Linux, macOS, network | Automated campaigns | Apache 2.0 |
| Stratus Red Team | DataDog | CLI, single cloud API call per attack | AWS, Azure, GCP control plane | Manual, attack by attack | MIT |
Many detection engineering teams run all three in rotation: Atomic Red Team for fast, granular technique-level validation; Caldera when they need to test whether their SOC can follow an orchestrated multi-stage intrusion; and Stratus Red Team when the environment in question is a cloud control plane rather than an endpoint. This tutorial focuses on Atomic Red Team because it has the lowest setup cost and the most direct mapping to individual detection rules, which makes it the right starting point for a team building its first purple-team workflow.
The setup cost difference is not a minor detail. Caldera requires standing up a server component and deploying agents to every target host before you can run a single operation, which is a reasonable investment once you’re ready for orchestrated campaigns but overkill for validating one detection rule. Atomic Red Team, by contrast, needs nothing beyond a PowerShell module and a folder of YAML files on the same host you’re testing, which is why most teams reach for it first and graduate to Caldera only once they’ve exhausted what single-technique validation can tell them.
Prerequisites and Lab Requirements
Atomic Red Team’s execution framework, Invoke-AtomicRedTeam, is a PowerShell module, which means Windows gets the smoothest ride, but PowerShell 7 (PowerShell Core) runs the same module on Linux and macOS. Budget about an hour for the full setup and first test run, plus more time if you want to walk through the complete project at the end of this guide. The table below lists what you need before starting.
| Requirement | Minimum | Notes |
|---|---|---|
| Operating system | Windows 10/11, Windows Server 2019+, or Linux/macOS with PowerShell 7 | Windows atomics are the most numerous; Linux/macOS atomics also exist |
| PowerShell | PowerShell 7.x (PowerShell Core) | Windows PowerShell 5.1 also works for Windows-only atomics |
| PowerShell modules | invoke-atomicredteam, powershell-yaml | Both install from the PowerShell Gallery in one command |
| Disk space | About 500 MB | Covers the execution framework and the full atomics folder |
| Privileges | Local administrator or sudo | Many atomics touch the registry, processes, or system services |
| Network access | Outbound HTTPS to github.com and powershellgallery.com | Needed once during install, then optional unless prereqs require downloads |
| Environment | Isolated VM or lab, never a production host | Non-negotiable; see the pitfalls section below |
You also need a target to measure against. If you already run a SIEM or detection rule set, such as a Sigma rule deployment, this is the moment to have it running in the same lab so you can watch alerts fire in near real time as you execute tests.
If you don’t already have detection tooling in the lab, don’t let that block you from starting. Install a lightweight log collector or EDR agent first, point it at the same VM, and confirm it’s actually ingesting process-creation and command-line events before you run a single atomic. Skipping that check is one of the most common reasons teams conclude they have a “detection gap” that’s actually just a telemetry gap: the alert rule was fine, but the raw event never reached the SIEM in the first place.
Step-by-Step Setup: Building Your Atomic Red Team Lab
Step 1: Build an isolated test environment
Provision a dedicated virtual machine or lab host that is not connected to production systems, shared drives, or anything you’d mind rebuilding from scratch. Atomic Red Team tests simulate real adversary behavior, including credential access, process injection, and persistence mechanisms, so running them anywhere outside an isolated lab risks tripping real alerts, corrupting real data, or handing an opportunistic attacker a live proof of concept against your own infrastructure. A fresh Windows 11 or Windows Server VM with snapshotting enabled is the simplest starting point, since you can roll back to a clean state after a messy test run.
Step 2: Install PowerShell 7 and confirm your execution policy
Install PowerShell 7 if you’re not already on it, since it’s required for cross-platform use and recommended even on Windows for its improved module handling. Then confirm your execution policy allows local scripts to run, which the PowerShell Gallery installation step depends on.
Get-ExecutionPolicy
Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned
$PSVersionTable.PSVersionIf Windows Defender’s real-time protection is active, expect it to flag or quarantine some atomic test files, since several are deliberately written to resemble malicious patterns. Decide now whether you’ll disable real-time protection temporarily or add a scoped exclusion for your atomics folder, and document that decision so nobody mistakes a lab exclusion for a production security gap later.
Step 3: Install Invoke-AtomicRedTeam and its dependency
Invoke-AtomicRedTeam is Red Canary’s PowerShell execution framework and the standard way most teams run atomic tests today. Install it along with the powershell-yaml module it depends on, directly from the PowerShell Gallery.
Install-Module -Name invoke-atomicredteam,powershell-yaml -Scope CurrentUser
Import-Module invoke-atomicredteam -ForceWorth noting for planning purposes: the Python-based alternative to this framework, atomic-operator, built by Swimlane as a cross-platform executor, was archived by its maintainer on March 17, 2026, and is now read-only. That leaves Invoke-AtomicRedTeam as the actively maintained path for running atomics, which is one more reason to build your workflow around it rather than an abandoned side project.
Step 4: Pull the atomics library
With the execution framework in place, download the actual test definitions. Red Canary provides a bootstrap installer that fetches both the framework and the full atomics folder in one pass, which is the fastest path for a new lab.
IEX (IWR 'https://raw.githubusercontent.com/redcanaryco/invoke-atomicredteam/master/install-atomicredteam.ps1' -UseBasicParsing)
Install-AtomicRedTeam -getAtomicsBy default this installs to C:\AtomicRedTeam on Windows or ~/AtomicRedTeam on macOS and Linux. Pass -InstallPath to redirect it, and -Force if you need to wipe a previous installation and start clean, which is useful if a prior attempt left a partial atomics folder behind.
Step 5: Verify the installation and list available tests
Confirm the module loaded and the atomics folder is populated before you try to run anything. The -ShowDetailsBrief switch gives you a quick summary of a technique’s available tests without dumping full command output.
Invoke-AtomicTest T1059.001 -ShowDetailsBriefA healthy install returns a short list of numbered tests for that technique, each with a one-line description. If PowerShell instead returns an error that it can’t find the atomics path, double check the -PathToAtomicsFolder value or rerun the installer from Step 4 with -Force.
Step-by-Step Setup: Mapping, Checking, and Running Tests Safely
Step 6: Map your target to current MITRE ATT&CK techniques
Before running anything, decide which ATT&CK techniques you actually want to test, and do it against the current framework version. MITRE’s ATT&CK version history shows the v19 release landed April 28, 2026, with a v19.2 Agile update in August 2026 refreshing Groups and Software entries, and v19 restructured the old Defense Evasion tactic into two separate tactics: Stealth (TA0005) and Defense Impairment (TA0112). MITRE’s site now states that ATT&CK v20 has been released, so v19.2 is no longer the newest version, and the figures here describe the v19.2 Enterprise matrix: 15 tactics, 222 techniques, and 475 sub-techniques, tracking 949 pieces of adversary software, 178 threat groups, and 59 documented campaigns. If your atomic red team test plan was built against an older ATT&CK release, re-check technique IDs tied to defense evasion behavior specifically, since some of them now live under a different tactic name, and verify them against v20 as well.
The ATT&CK Navigator remains the fastest way to see which techniques your existing atomics already cover, letting you color a matrix cell for every technique with at least one available test. Cross-reference that against your own detection rule set, your Sigma rules, or any custom correlation logic in your SIEM, to find techniques with zero coverage on either side.
Step 7: Check and resolve prerequisites
Many atomics assume a dependency is already present, such as a specific binary, a sample file, or a registry key. Running the test without checking first just produces a confusing failure. Use -CheckPrereqs to verify, and -GetPrereqs to let the framework resolve anything missing automatically.
Invoke-AtomicTest T1059.001 -TestNumbers 1 -CheckPrereqs
Invoke-AtomicTest T1059.001 -TestNumbers 1 -GetPrereqsExpect -CheckPrereqs to print either a confirmation that requirements are met or a specific list of what’s missing, such as a sample executable the atomic expects in a known path. -GetPrereqs then runs the commands defined in that atomic’s dependency block to fetch or create whatever’s absent.
Step 8: Review full test details before you run it
Never run a test blind. Use -ShowDetails to print the full description, the exact executor command, input arguments, and the cleanup commands before you pull the trigger, especially on a technique you haven’t run before.
Invoke-AtomicTest T1059.001 -ShowDetailsRead the executor command carefully. Some atomics are genuinely benign (writing a harmless file), while others trigger behavior that most endpoint protection products will flag immediately, including process injection or credential dumping techniques. Knowing which category you’re about to run changes how you’ll interpret silence from your detection stack afterward: silence on a loud technique is a real finding, while silence on a quiet one may just mean the test didn’t generate enough signal to alert on.
Step 9: Run the test
With prerequisites resolved and the command reviewed, execute the specific test number you want.
Invoke-AtomicTest T1059.001 -TestNumbers 1A typical successful run prints the technique name, the test name, and the executor output inline, something like:
PathToAtomicsFolder = C:\AtomicRedTeam\atomics
Executing test: T1059.001-1 PowerShell Command Execution
Done executing test: T1059.001-1 PowerShell Command ExecutionThat’s your signal to immediately pivot to your detection stack and check whether the corresponding alert fired within the expected window.
Step-by-Step Setup: Detection Validation and Cleanup
Step 10: Validate the detection, not just the execution
Running the atomic is only half the exercise. Immediately check whether the behavior generated the telemetry and alert you expected. If you’re running an open-source SIEM or EDR in your lab, check its event log or alert console for the matching technique ID. Teams running Falco for runtime detection on Linux atomics, or a Windows-focused SIEM for PowerShell and process-creation atomics, should see a corresponding rule fire within seconds of the test completing. If nothing fires, you’ve just found a genuine detection gap rather than a false sense of coverage, which is the entire point of running Atomic Red Team in the first place.
Log the result in a simple spreadsheet or tracker: technique ID, test number, expected detection source, whether it fired, and the timestamp. That record becomes your coverage map and the input to the reporting step later in this guide.
Step 11: Clean up after every test
Most atomics define explicit cleanup commands to reverse whatever they changed, whether that’s deleting a dropped file, removing a scheduled task, or reverting a registry key. Always run cleanup immediately after validating detection, before moving to the next test, so leftover artifacts from one atomic don’t contaminate the next one’s results.
Invoke-AtomicTest T1059.001 -TestNumbers 1 -CleanupNot every atomic ships a cleanup block. If -Cleanup returns nothing to do, check -ShowDetails again to confirm whether the test is genuinely stateless or whether you need to revert something manually, such as a snapshot rollback for tests that modify system-level configuration.
Step-by-Step Setup: Chaining Tests and Automating the Cycle
Step 12: Chain multiple atomics into a mini campaign
Since Atomic Red Team doesn’t automate full attack chains, build your own short sequence manually for a more realistic purple-team scenario. A simple loop that runs several related techniques back to back, with a pause between each for your detection stack to catch up, gets you most of the value of a scripted campaign without needing a separate orchestration tool.
$chain = @("T1059.001","T1055","T1003.001","T1070.004")
foreach ($t in $chain) {
Write-Host "Running $t..."
Invoke-AtomicTest $t -GetPrereqs
Invoke-AtomicTest $t -TestNumbers 1
Start-Sleep -Seconds 30
Invoke-AtomicTest $t -TestNumbers 1 -Cleanup
}That four-technique example moves from command execution, to process injection, to credential dumping, to indicator removal, roughly mirroring the shape of a real post-exploitation sequence without requiring a dedicated campaign engine like Caldera.
Step 13: Automate continuous testing with Atomic Runner
Invoke-AtomicRedTeam includes an Atomic Runner function built specifically for unattended, scheduled execution of a configured list of tests, aimed at ongoing prevention and detection reporting rather than one-off manual runs. Once your initial coverage pass is done, wire Atomic Runner into a scheduled task so regressions in your detection stack, caused by a config change, a rule that got disabled, or an agent update, surface automatically instead of waiting for the next manual purple-team exercise.
Community tooling has also started filling the CI gap: a GitHub Action called invoke-atomic-action, built by an independent maintainer, lets you run atomics inside a pipeline job rather than only interactively, which is worth evaluating if your team already runs detection validation as part of CI. An Atomic Red Team MCP package is also published on PyPI, with v1.3.2 released in April 2026, for teams that want to drive atomics from an AI assistant.
Complete Working Project: A Five-Technique Purple Team Exercise
Putting the previous thirteen steps together, here’s a complete, runnable exercise that covers five ATT&CK techniques spanning execution, persistence, defense evasion, credential access, and exfiltration-adjacent behavior. Run this on your isolated lab VM after completing Steps 1 through 5.
# 1. Define the exercise scope
$techniques = @(
"T1059.001", # PowerShell command execution
"T1053.005", # Scheduled task persistence
"T1070.004", # File deletion (defense evasion)
"T1003.001", # LSASS credential dumping
"T1041" # Exfiltration over C2 channel
)
# 2. Resolve prerequisites for every technique up front
foreach ($t in $techniques) {
Invoke-AtomicTest $t -GetPrereqs
}
# 3. Run each test, pausing to let detection tooling catch up
$results = @()
foreach ($t in $techniques) {
$start = Get-Date
Invoke-AtomicTest $t -TestNumbers 1
Start-Sleep -Seconds 45
$results += [PSCustomObject]@{ Technique = $t; RanAt = $start }
}
# 4. Clean up every test before closing the exercise
foreach ($t in $techniques) {
Invoke-AtomicTest $t -TestNumbers 1 -Cleanup
}
# 5. Export the run log for your detection coverage report
$results | Export-Csv -Path .\purple-team-run-log.csv -NoTypeInformationAfter the run, cross-reference purple-team-run-log.csv against your SIEM’s alert history for the same time window. Every technique with a matching alert goes in your coverage map as confirmed; every one without goes on the backlog for new detection rule work, whether that’s a new Sigma rule or a tuning change to an existing one. Teams that also run a vulnerability and finding tracker like DefectDojo can import the gap list directly as findings tied to specific ATT&CK technique IDs, which keeps detection debt visible alongside other security backlog items instead of living in a separate spreadsheet nobody revisits.
Common Pitfalls When Running Atomic Red Team
These mistakes account for most of the frustration teams report in their first few weeks with the framework, and nearly all of them trace back to skipping one of the thirteen steps above rather than a flaw in the tooling itself.
- Running tests on a production host or shared system instead of an isolated lab, which risks real alerts, real data loss, or handing an adversary a working exploit path if the host is ever compromised.
- Skipping -CheckPrereqs and -GetPrereqs, then misreading a prerequisite failure as a detection gap when the test never actually ran as intended.
- Forgetting -Cleanup after a test, which leaves dropped files, scheduled tasks, or registry changes behind that quietly skew the results of the next test you run.
- Testing against an outdated local ATT&CK mapping after the v19 tactic split, leading to confusion when a technique you expected under Defense Evasion now sits under Stealth or Defense Impairment.
- Assuming atomic-operator is still a viable cross-platform option, when the Swimlane-maintained Python project was archived in March 2026 and no longer receives updates or security fixes.
- Running a long chain of atomics back to back with no pause, so overlapping telemetry makes it impossible to tell which test triggered which alert.
- Treating a single clean test run as proof of full coverage for a technique, when most techniques have multiple atomic tests exercising different sub-behaviors that each deserve their own pass.
Troubleshooting Guide
The table below covers the issues that come up most often during setup and the first few test runs, drawn from the same installation and execution steps covered earlier in this guide.
| Symptom | Likely cause | Fix |
|---|---|---|
| Install-Module fails with a trust prompt | PSGallery isn’t a trusted repository yet | Run Set-PSRepository -Name PSGallery -InstallationPolicy Trusted, then retry |
| Invoke-AtomicTest: command not found | Module wasn’t imported after install | Run Import-Module invoke-atomicredteam -Force and confirm with Get-Module |
| “Unable to find path to atomics folder” | Atomics weren’t downloaded, or path differs from default | Rerun Install-AtomicRedTeam -getAtomics -Force or pass -PathToAtomicsFolder explicitly |
| Antivirus deletes atomic test files mid-run | Defender or third-party AV quarantines files matching malicious patterns | Add a scoped lab exclusion for the atomics folder, never disable AV lab-wide permanently |
| -CheckPrereqs always reports missing dependencies | Sample files or binaries the atomic expects aren’t present | Run -GetPrereqs first, or check the atomic’s YAML for manual download instructions |
| Test runs but no detection fires anywhere | Could be a genuine coverage gap, or detection tooling isn’t ingesting the right log source | Confirm your SIEM or EDR agent is actually collecting the expected event source before concluding it’s a gap |
| PowerShell 5.1 throws YAML parsing errors | powershell-yaml module version mismatch on older PowerShell | Upgrade to PowerShell 7 and reinstall powershell-yaml in that session |
| -Cleanup appears to do nothing | That atomic doesn’t define a cleanup command | Check -ShowDetails for a cleanup_command field; if absent, revert manually or via VM snapshot |
| Technique ID returns “not found” | Technique was renumbered or moved under ATT&CK v19’s tactic split | Search the current ATT&CK Navigator for the technique’s new ID before assuming it was removed |
| Atomic Runner job fails silently on schedule | Scheduled task runs under a user context without the needed privileges | Run the scheduled task under an account with local admin rights in the lab |
Advanced Tips for Purple and Detection Engineering Teams
Once the basic workflow is routine, a few refinements make the exercise far more useful to the rest of the security team. Export every test result with timestamps, as shown in the complete project above, and feed that log into whatever platform aggregates your findings, whether that’s a ticketing system or a dedicated tool like DefectDojo for tracking detection debt alongside vulnerability findings. Pair atomic red team runs with a vulnerability scanner pass from a tool like OpenVAS so you’re validating both “can an attacker get in” and “would we notice if they did” in the same testing cycle rather than treating them as unrelated programs.
For incident response teams, pair atomic testing with a forensic collection tool such as Velociraptor so you can practice the full loop: trigger a technique, confirm detection, then collect forensic artifacts from the test host as if it were a real incident. That turns a detection-validation exercise into tabletop practice for the response team at the same time, without any extra setup cost beyond what you’ve already built in this guide.
Finally, revisit your technique list every time MITRE ships an ATT&CK update. The v19 Defense Evasion split, followed by the release of ATT&CK v20, is a reminder that technique IDs and tactic groupings aren’t permanent, and a coverage map built against last year’s framework can quietly drift out of sync with the one your SOC actually reports against.
One more refinement worth building early: version-control your coverage spreadsheet or tracker the same way you version-control code. A plain CSV committed to a private git repository, with one commit per exercise, gives you a historical diff of exactly when a technique’s detection status flipped from covered to uncovered, which is far more useful during a post-incident review than a single snapshot spreadsheet that only reflects the most recent run.
Security and Operational Risks to Plan For
Atomic Red Team’s own documentation is blunt about this: these tests execute real commands that mimic real adversary behavior, including credential access, persistence, and process manipulation. That means the same safeguards you’d apply to any red-team activity apply here. Keep a written rules-of-engagement document that defines exactly which hosts are in scope, a stop condition for aborting the exercise if something behaves unexpectedly, and a named owner who can authorize or halt testing. Never let an atomic red team job run unattended against a host you don’t fully control, and never grant a CI pipeline broader privileges than the specific test actually needs just to avoid troubleshooting a permissions error.
It’s also worth tracking Red Canary’s roadmap now that it operates inside Zscaler. Zscaler’s announcement of the completed acquisition states that Red Canary will initially run as a separate business unit focused on agentic AI-driven security operations, integrated with Zscaler’s Data Fabric for Security, which could eventually change how Atomic Red Team’s open-source tooling connects to commercial detection products. Nothing in the public record points to the open-source library itself being restricted, and the repository remained active, with automated labeling and stale-issue workflows running on October 4â23, 2026, but any team building long-term automation on top of it should keep an eye on the project’s GitHub activity for signs of a roadmap shift.
Before your first exercise, get sign-off in writing from whoever owns the systems you’re testing against, even if that’s just a short email thread confirming the lab VM is isolated and out of scope for change-management alerts elsewhere in the business. That small step avoids the awkward scenario where a help desk ticket gets opened, or a security operations analyst escalates a real incident, over what turns out to be your own scheduled atomic test. Treat every run the way you would any other authorized security testing activity: scoped, logged, and reversible.
Frequently Asked Questions
Is Atomic Red Team safe to run on a production server?
No. The project’s own documentation and the broader security community are consistent on this: atomics execute real adversary-style commands, including credential access and persistence techniques, and should only run in an isolated lab or an explicitly authorized test environment, never on production infrastructure.
Does Atomic Red Team require Red Canary’s commercial platform?
No. The atomics library and the Invoke-AtomicRedTeam execution framework are both open source and MIT licensed, and run completely independently of any Red Canary commercial product or the company’s Zscaler ownership.
What’s the difference between Atomic Red Team and MITRE Caldera?
Atomic Red Team runs single, narrowly scoped tests per ATT&CK technique that you select and sequence manually. MITRE Caldera is a full adversary emulation platform with a server, deployed agents, and an automated planner that can chain techniques into an orchestrated multi-stage campaign on its own.
Can I run Atomic Red Team on Linux or macOS?
Yes, using PowerShell 7 (PowerShell Core), which runs the Invoke-AtomicRedTeam module cross-platform. Atomic tests exist for Linux and macOS, alongside the larger Windows-focused set, and the installer supports all three operating systems plus infrastructure-as-a-service platforms.
Why did some of my technique IDs stop matching current ATT&CK documentation?
MITRE ATT&CK v19, released April 28, 2026, split the former Defense Evasion tactic into two separate tactics, Stealth (TA0005) and Defense Impairment (TA0112). Any technique mapping or coverage spreadsheet built against an older ATT&CK version should be re-checked against ATT&CK v20, which MITRE’s site now announces as released, rather than the v19.2 matrix of 15 tactics and 222 techniques.
Is atomic-operator still a good option for running tests from Python?
No. The Swimlane-maintained atomic-operator project, which offered Python-based cross-platform execution, was archived by its owner on March 17, 2026, and no longer receives updates. Invoke-AtomicRedTeam is the actively maintained execution framework going forward.
How often should a team re-run its Atomic Red Team coverage tests?
There’s no single official cadence, but most detection engineering teams run a baseline pass after any significant change to detection rules, SIEM configuration, or endpoint agents, and use Invoke-AtomicRedTeam’s Atomic Runner feature to schedule lighter continuous checks between full manual exercises.
Do I need special licensing to use Atomic Red Team commercially?
No. Both the atomics library and Invoke-AtomicRedTeam are released under the MIT license, which permits commercial use, modification, and redistribution without a separate license fee.
