Atomic Red Team: What It Is and How to Test Detections

Atomic Red Team is an open-source library of small tests, each mapped to a MITRE ATT&CK technique, that you run on your own schedule to check whether your detections still fire. Detections can break without anyone noticing: a log source gets re-onboarded, an EDR policy changes, or a parser renames a field, and the rule stays in the console looking healthy while it matches nothing.

After each test, check whether an alert fired, whether someone picked it up, and whether it gave them enough to act on.

TL;DR:

• Atomic Red Team checks whether your telemetry and alerts work. It does not replace a red team or a full adversary emulation.
• Score every test on two outcomes: the alert appeared, and someone handled it.
• The program is mostly governance. Lab-first runs, change approval, advance notice to whoever watches alerts, and verified cleanup matter more than which runner you pick.
• A passed test proves one procedure on one date. Keep a dated coverage map, feed the gaps into a detection backlog, and retest on a schedule.

What Atomic Red Team Is and Who Maintains It

Red Canary created Atomic Red Team and still hosts it on GitHub. Since Zscaler completed its acquisition of Red Canary in August 2025, the project sits inside a Zscaler company, but it remains free, MIT-licensed, and maintained by its community.

Each test targets one ATT&CK technique or sub-technique and is designed to run in five minutes or less. Tests can include prerequisites and a cleanup step, and they cover Windows, macOS, and Linux as well as Microsoft 365, Entra ID, Google Workspace, and the AWS, Azure, and Google Cloud IaaS platforms. The usual runner is Invoke-AtomicRedTeam, a PowerShell framework with its own setup docs.

If your coverage map is organized by tactic, check it against the current framework. MITRE's April 2026 ATT&CK release split Defense Evasion into two new tactics, Stealth and Defense Impairment, so anything filed under the old name needs remapping. The library's bundled ATT&CK data can lag the current release, so check technique names too.

Where Atomic Red Team Fits in a Detection Program

A penetration test asks whether your controls block an attack. A red team asks whether your people investigate and respond to one. Atomic Red Team checks whether a specific procedure produced the telemetry and the alert you expected. Red Canary describes it as an alert validation tool for finding missing telemetry and broken alert logic.

Detection engineering usually picks the tests and fixes the rules, while SecOps or an MDR provider owns what happens once an alert fires, so one test checks both halves of the program.

Regular atomic tests through the year are more immediate and less expensive than the annual red team engagement most programs default to, Red Canary co-founder Keith McCammon argued in 2023. Atomic Red Team makes that practical: the library is free, so the real cost is your team's time. OWASP's DevSecOps Guideline suggests starting with 10 to 15 high-priority techniques, then moving to weekly automated runs and a quarterly purple team session.

Commercial breach and attack simulation (BAS) platforms add scheduling, scoring, and reporting on top, at a price that varies widely by vendor and scope. Here's how the options compare:

‍

Running a Test Program Safely

Atomic tests run real attack techniques on real machines, and the project's own docs warn they can leave a system "in an undesirable state." Treat each run like a production change:

1. Start in a lab. The project's getting started guide asks you to get the environment owner's permission and to use a test machine that mirrors your build, with your security tools running. Snapshot it so you can roll back.
2. Approve production runs individually. Some tests are destructive: they delete shadow copies, overwrite files, or delete cloud storage buckets. Exclude those by default, and list the approved hosts and tests in the change ticket.
3. Tell whoever watches alerts, including your MDR provider. Share the time window and the hosts so a test alert doesn't turn into a full incident, but don't say which alerts to expect, so you're still testing how alerts get handled.
4. Clean up. Run each test's cleanup step if it has one, then confirm the artifacts are gone or roll back the snapshot.
5. Keep a paper trail. The runner logs every execution by default. Attach that log to the change ticket so any alert can be traced to a planned test.

Also agree in advance what happens if endpoint protection blocks a test: whether a block counts as a pass, and who approves exclusions.

Worked Example: LSASS Memory Dumping (T1003.001)

Credential dumping from LSASS memory, T1003.001 in ATT&CK, makes a good first test because the trail it should leave is well documented. In one variant, close to the library's own test, the Windows utility rundll32.exe loads comsvcs.dll and uses it to write LSASS memory to a file. Expect roughly this sequence, and confirm it in your own stack:

• rundll32.exe starting, with its full command line (Sysmon Event ID 1, Windows Security event 4688, or your EDR)
• comsvcs.dll loading inside rundll32.exe (Sysmon Event ID 7 or your EDR)
• a dump file being written (Sysmon Event ID 11 or your EDR)
• a process opening a handle to lsass.exe (Sysmon Event ID 10)

The lsass.exe access event gets noisy fast unless you filter it, so check that your filters still let this case through.

On the alert side, the public Sigma rule for this variant, "Process Memory Dump Via Comsvcs.DLL," catches the rundll32.exe command line. It's still marked as a test rule, so validate it in your environment before relying on it. ATT&CK's detection strategy DET0363 looks for a full-access handle to lsass.exe followed by a memory dump, a new file, or a registry change. Your EDR may also raise its own alert.

Whoever picks up the alert should check which account and parent process launched rundll32.exe, whether the host and timing match an approved test, and whether the dump file was moved. Then check whether that account logged in anywhere else afterward, because that's where a real attacker would go next.

How to Read Atomic Red Team Results

For each test, record whether the activity was blocked, logged, or alerted on, and whether anyone actually handled the alert. VECTR, a free tracking tool, records the first three outcomes but not handling, so add that column yourself.

No Alert

Check the raw logs before you touch the rule. If the events never arrived, you have a telemetry gap, and the fix is onboarding or agent configuration. If the events arrived and nothing fired, the rule is broken.

An Alert Nobody Acted On

This result is easy to miss, because the alert technically fired. Find out why it stalled. A low severity rating may have buried it, or routing sent it to a queue nobody watches. It may also have lacked the business context the analyst needed to tell it apart from routine admin work.

An Alert Investigated Properly

The analyst reached a verdict and tied the alert to the planned test, and the alert carried enough context to decide without digging through three other consoles.

Turning Results Into a Coverage Map and Detection Backlog

Log each run as one row: technique, procedure tested, expected alert, what actually happened, whether it was handled, and the date. Over time those rows become your coverage map, and ATT&CK Navigator can turn them into a heat map. VECTR can import Atomic test definitions and execution logs to build the rows for you, and SCYTHE's open-source sigma-regression-testing project shows how to automate the loop in Splunk: it pairs Sigma rules with atomic tests and builds a Navigator layer from the results.

Rank the backlog by threat data. MITRE's CTID prioritizes techniques by how common they are, how many attacks pass through them, and how actionable a detection is, and the techniques that rank high for your environment go first.

Every gap turns into one kind of fix: onboard a missing log source, repair the rule, correct its severity or routing, or add the context the alert lacked. The test result tells you which one you need. Whether your own team or a detection engineering service does the work is a staffing decision.

Date every row, and treat each technique mapping as a claim to test. When CTID checked one rule set, most of the techniques it was mapped to weren't meaningfully covered, and a stale mapping "can create the appearance of coverage" long after the analytic and the technique have drifted apart.

Where Atomic Red Team Stops

Atomic tests run one technique at a time, so they can't tell you whether you'd catch a full intrusion. Production detections often require a chain of related activity before they fire, and Red Canary tunes its own detections that way, so a single isolated test can come up empty even when the detection works. For chained behavior, you need a separate emulation plan.

Each test covers one procedure. LSASS memory can be dumped several ways, and each may leave a different trail.

Cloud and identity coverage is thin, and Red Canary's 2026 report ranks abuse of cloud accounts as the most common technique it saw. Many cloud entries in the project's index are still placeholders waiting for someone to contribute a test.

Results also go stale. A parser upgrade can quietly break a detection that depends on a renamed field, so a test that passed last quarter may fail today.

Choosing Between Atomic Tests, BAS, and Purple Teaming

Use the narrowest method that answers the coverage question in front of you:

• If you have detections but no evidence they fire, start with Atomic Red Team on a short list of priority techniques.
• If your top-priority techniques are in the cloud or identity layer, add a cloud-focused tool such as Stratus Red Team, run against a sandbox account.
• If leadership wants scheduled, scored reporting across many controls and your team lacks time to run tests, BAS is the better fit.
• If you need to know whether the SOC would catch a full intrusion, book an emulation-based purple or red team engagement and use your atomic results to set its agenda.
• If atomic tests keep producing alerts that nobody handles, the bottleneck is investigation capacity, and more rules won't fix it.

For an investigation-capacity gap, the options are more staff, workflow changes, or a managed service such as Daylight's MDR, which investigates and responds to the alerts your detections produce.

Frequently Asked Questions About Atomic Red Team

How Often Should We Run Atomic Tests?

Weekly is a sensible default, and it's what the project's continuous-testing runner is set up to do. Add a rerun before and after any change to parsers, EDR policies, or log pipelines. Red Canary has described running a short daily set as an "is this thing on?" check, so a few core procedures can run more often than the rest.

Can We Run Them in Production?

Yes, once a test has run cleanly in the lab and the production run is approved. The most valuable production use is regression testing: run the same test before and after a planned change, such as an EDR policy update, a parser upgrade, or a log pipeline migration, and compare the results.

If Every Atomic Test for a Technique Passes, Are We Covered?

Not necessarily. Collecting a log source isn't the same as collecting the fields a detection needs. Process creation logs without command lines, for example, would miss the comsvcs.dll variant above. Before you trust a pass, confirm that the fields your rule depends on, such as parent process and full command line, reach your SIEM intact.

Who Should Own the Program?

Split ownership by the type of failure. Missing telemetry goes to whoever runs logging and agents, a silent rule goes back to detection engineering, and an alert nobody handled goes to SOC leadership or the MDR provider. If you use a provider, agree up front whether its handling of test alerts is part of what you're measuring. Findings that point to behavior no rule could catch belong with hypothesis-driven hunting.

Can Atomic Red Team Replace a BAS Platform?

For a small, engineering-led program, it can cover much of the same ground. The project's runner handles scheduling and VECTR tracks results over time, so what you give up is vendor-maintained scenarios, guaranteed-safe execution, and polished reporting. BAS earns its license when those gaps cost more in your team's hours than the subscription does.

How Is Atomic Red Team Different From MITRE Caldera?

MITRE Caldera is an open-source platform that automates adversary emulation by chaining techniques into multi-step operations, while Atomic Red Team supplies single, standalone tests. The two work together: Caldera's Atomic plugin imports Atomic Red Team tests, so procedures that pass on their own can later run inside a chained emulation.