This chapter covers Atomic Red Team, an open-source framework for executing adversary simulation tests. For the CS0-003 exam, understanding Atomic Red Team is critical because it appears in Domain 3 (Security Operations) and is a primary tool for validating detection and response capabilities. Approximately 5-10% of exam questions may reference attack simulation tools, with Atomic Red Team being the most commonly tested open-source option. You will need to know its purpose, architecture, how to execute tests, and how it integrates with other security tools.
Jump to a section
Atomic Red Team is like a fire drill conducted by a safety officer in a large office building. The safety officer (the red teamer) doesn't start real fires; instead, they activate pre-defined, controlled 'alarm triggers'—like pulling a fire alarm or setting off a smoke machine in a specific zone. Each trigger is documented in a binder (the Atomic Red Team library) with exact steps: 'Go to stairwell B, pull the alarm handle, and note the time.' The building's security systems (SIEM, EDR) detect these triggers and respond as if a real fire occurred—alarms sound, doors unlock, sprinklers activate (in simulation mode). The safety officer then reviews the logs to see if the security team responded correctly: Did the fire department get notified? Did the evacuation proceed? Did the alarm system report the correct location? The key difference from a real fire is that the triggers are harmless and reversible—no actual smoke damage, no false alarm fines. Similarly, Atomic Red Team executes atomic tests that mimic adversary techniques (like creating a scheduled task or modifying a registry key) without causing real damage, allowing defenders to validate their detection and response capabilities. The tests are 'atomic' because each one is a single, self-contained action that represents a specific MITRE ATT&CK technique, not a multi-step attack chain.
What is Atomic Red Team?
Atomic Red Team is an open-source library of small, highly-specific test cases (called 'atomic tests') that map directly to MITRE ATT&CK techniques. Each atomic test executes a single adversary behavior without requiring a full attack chain or a dedicated infrastructure. It is developed and maintained by Red Canary and is available on GitHub. The purpose is to allow blue teams to validate their security controls (SIEM, EDR, NGFW, etc.) against known adversary techniques in a safe, repeatable manner.
Why Atomic Red Team Exists
Traditional penetration testing often involves complex, multi-step attacks that can be time-consuming and difficult to reproduce. Atomic Red Team simplifies this by breaking down attacks into individual, atomic actions. For example, instead of simulating a full ransomware attack, you can test just the 'Process Injection' technique (T1055) or 'Disabling Windows Defender' (T1562.001). This allows teams to:
Test specific detection rules in isolation.
Validate that a single control works before combining techniques.
Quickly reproduce a test across multiple endpoints.
Share tests with a common vocabulary (MITRE ATT&CK IDs).
How It Works Internally
Atomic Red Team is essentially a collection of YAML files, each defining one atomic test. The YAML file specifies:
The MITRE ATT&CK technique ID (e.g., T1059.001 for PowerShell).
The test name.
A description.
Supported platforms (Windows, macOS, Linux).
Dependencies and how to satisfy them.
The execution command(s) to run the test.
Expected output or artifacts.
The tests are executed by the Invoke-AtomicRedTeam PowerShell module (for Windows) or via Python for cross-platform use. The module reads the YAML files, checks dependencies, and runs the commands. For example, to execute a test that creates a scheduled task (T1053.005), the YAML might contain:
command: |
schtasks /create /tn "AtomicTask" /tr "calc.exe" /sc once /st 00:00The module runs this command on the target system, and the defender can observe the event in their SIEM or EDR.
Key Components and Defaults
- Atomic Red Team Library: The GitHub repository containing hundreds of atomic tests. The library is versioned and updated regularly.
- Invoke-AtomicRedTeam (PowerShell module): The primary execution tool for Windows. Installed via PowerShell Gallery: Install-Module -Name invoke-atomicredteam -Scope CurrentUser.
- Atomic Red Team Python Executor: For cross-platform use (Linux, macOS). Installed via pip: pip install atomic-operator.
- Execution Flags: Common flags include:
- -TestNumbers: Specify which tests to run (e.g., T1059.001-1).
- -Path: Path to the local copy of the Atomic Red Team folder.
- -GetPrereqs: Check and install dependencies before running the test.
- -Cleanup: Revert changes made by the test.
- Default Location: After cloning the repository, the atomic tests are in atomic-red-team/atomics/.
Configuration and Verification Commands
To set up Atomic Red Team on Windows:
1. Clone the repository: git clone https://github.com/redcanaryco/atomic-red-team.git
2. Install the PowerShell module: Install-Module -Name invoke-atomicredteam -Scope CurrentUser
3. Import the module: Import-Module invoke-atomicredteam
4. List available tests: Invoke-AtomicTest All -ShowDetails
5. Run a specific test: Invoke-AtomicTest T1059.001 -Path C:\atomic-red-team
6. With cleanup: Invoke-AtomicTest T1059.001 -Path C:\atomic-red-team -Cleanup
On Linux/macOS using Python:
1. Clone the repository.
2. Install the Python executor: pip install atomic-operator
3. Run a test: atomic-operator T1059.001 -p /path/to/atomic-red-team
Interaction with Related Technologies
Atomic Red Team integrates with: - SIEM (Splunk, ELK, Sentinel): By generating logs that SIEMs ingest, allowing validation of correlation rules. - EDR (CrowdStrike, Defender for Endpoint): EDRs detect atomic test behaviors and generate alerts. The blue team can verify that the EDR detects the technique. - MITRE ATT&CK: The tests are mapped to ATT&CK IDs, providing a common language between red and blue teams. - AttackIQ, SafeBreach: Commercial alternatives that also use ATT&CK mappings but offer more automation and reporting.
Important Technical Details
Dependencies: Many tests require prerequisites (e.g., a specific file, a tool like Sysinternals). The -GetPrereqs flag automatically downloads required files to the $env:TEMP directory.
Cleanup: Not all tests have cleanup routines. Always run with -Cleanup to revert changes. If cleanup fails, manual remediation may be needed (e.g., delete scheduled tasks, restore registry keys).
Execution Policy: On Windows, PowerShell execution policy may need to be set to RemoteSigned or Bypass.
Logging: Atomic tests generate standard Windows Event Logs (e.g., 4688 for process creation, 4698 for scheduled task creation). Ensure logging is enabled.
Common Test Categories
Execution: PowerShell, CMD, Bash.
Persistence: Scheduled tasks, registry run keys, services.
Defense Evasion: Disabling Windows Defender, clearing logs.
Credential Access: Dumping LSASS, keylogging.
Discovery: System information discovery, network share discovery.
Lateral Movement: Remote desktop, PsExec.
Exfiltration: FTP upload, HTTP POST.
Performance Considerations
Atomic tests are lightweight by design—each test runs a single command or script. However, running hundreds of tests simultaneously on a single system can cause resource contention. It is recommended to run tests sequentially or in small batches. The cleanup process may also take time if many tests are run.
Version and Update Frequency
The Atomic Red Team library is updated monthly with new tests and improvements. The current stable version as of 2024 is v2.0+. Always use the latest version to ensure compatibility with current ATT&CK techniques.
Security and Safety
While Atomic Red Team is designed to be safe, it does modify the system (e.g., creates files, processes, registry keys). Always run in a test environment or on endpoints designated for testing. Some tests may trigger security alerts or cause false positives in production monitoring systems.
Set Up the Environment
Clone the Atomic Red Team repository from GitHub to a local directory. Install the execution framework: for Windows, install the Invoke-AtomicRedTeam PowerShell module from the PowerShell Gallery; for Linux/macOS, install the atomic-operator Python package via pip. Ensure the target systems have the necessary permissions and logging enabled (e.g., Windows Event Logging, Sysmon). Set PowerShell execution policy to RemoteSigned if needed. Verify the installation by listing available tests using `Invoke-AtomicTest All -ShowDetails` on Windows or `atomic-operator -l` on Linux.
Select an Atomic Test
Identify the MITRE ATT&CK technique you want to test. For example, to test process injection (T1055), locate the corresponding atomic test in the repository. The test ID is typically in the format T1055-1. You can list all tests with `Invoke-AtomicTest All -ShowDetails` and search for specific techniques. Each test YAML file contains the exact commands to execute, dependencies, and cleanup steps. Review the test description to ensure it matches your objective.
Check and Install Prerequisites
Before executing the test, run the prerequisite check using `Invoke-AtomicTest T1055 -GetPrereqs`. This command evaluates whether all required files, tools, or configurations are present. If any are missing, the module automatically downloads them to the temporary folder (usually `$env:TEMP\AtomicRedTeam`). For example, a test that uses Sysinternals' PsExec will download PsExec.exe if not found. This step ensures the test can run without manual setup.
Execute the Atomic Test
Run the test using `Invoke-AtomicTest T1055 -Path C:\atomic-red-team`. The module reads the YAML file, executes the defined command(s) on the target system, and outputs the results to the console. For example, a test for scheduled task creation might run `schtasks /create ...`. The test runs in the context of the current user, so ensure the user has appropriate privileges. On Linux, use `atomic-operator T1055 -p /path/to/atomic-red-team`.
Monitor and Validate Detection
During and after execution, monitor your security tools (SIEM, EDR) for alerts generated by the test. Check if the expected logs are created (e.g., Windows Event ID 4688 for process creation, 4698 for scheduled task). Validate that detection rules fire correctly. If no alert is generated, investigate why—the rule may be missing, the log source may not be ingested, or the test may have failed silently. This step is the core purpose of Atomic Red Team.
Clean Up the Test Artifacts
After validation, run the cleanup command: `Invoke-AtomicTest T1055 -Path C:\atomic-red-team -Cleanup`. The module executes the cleanup commands defined in the YAML file, such as deleting scheduled tasks, removing files, or reverting registry changes. If cleanup fails, manually check for leftovers (e.g., `schtasks /delete`, `reg delete`). Always clean up to avoid system clutter or unintended persistence.
Enterprise Scenario 1: Validating SIEM Detection Rules
A large financial institution uses Splunk as its SIEM with custom correlation rules for detecting privilege escalation. The security team wants to ensure that a rule for 'Service Creation' (T1543.003) actually triggers when a new service is installed. They deploy Atomic Red Team on a test workstation and run the atomic test for T1543.003-1 (Create Service using sc.exe). The test creates a service named 'AtomicService'. The Splunk rule is expected to generate an alert based on Windows Event ID 4697 (Service Installed). After execution, the team checks Splunk—no alert. Investigation reveals that the Splunk forwarder on that workstation does not forward Event ID 4697 due to a misconfigured inputs.conf. The team fixes the configuration, re-runs the test, and the alert fires. This validates both the detection rule and the log collection pipeline.
Enterprise Scenario 2: Testing EDR Blocking Capabilities
A healthcare organization uses Microsoft Defender for Endpoint (MDE) and wants to verify that it blocks known ransomware techniques like 'Process Hollowing' (T1055.012). They run the atomic test for T1055.012 on a non-production endpoint. However, MDE does not block the test—it only generates an informational alert. The security team realizes that MDE is configured in 'Audit Mode' for that endpoint. They change the policy to 'Block Mode' and re-run the test. This time, MDE terminates the process and prevents the hollowing. The team documents the test results for compliance audits, demonstrating that the control is effective.
Common Pitfalls and Scale Considerations
In production, running Atomic Red Team across hundreds of endpoints requires careful planning. The tests generate significant log volume—a single test can create multiple events. Running dozens of tests simultaneously can overwhelm SIEM ingestion rates or trigger false positive suppression logic. It is best to schedule tests during maintenance windows and use the -TimeoutSeconds parameter to limit execution time. Also, some tests require administrative privileges; if the test user lacks admin rights, the test may fail silently. Always run tests with a dedicated service account that has the necessary permissions. Finally, cleanup is critical—forgetting to clean up can leave backdoors or persistent artifacts that real attackers could exploit.
What CS0-003 Tests
This topic falls under Domain 3 (Security Operations), specifically Objective 3.1: 'Explain the importance of security automation and orchestration practices.' Atomic Red Team is a key example of automation for attack simulation. The exam expects you to know:
The purpose of Atomic Red Team (validating detection and response).
How it maps to MITRE ATT&CK.
The difference between atomic tests and full attack simulations.
Basic execution commands (e.g., Invoke-AtomicTest).
The importance of cleanup.
Common Wrong Answers and Why Candidates Choose Them
'Atomic Red Team is a penetration testing tool for exploiting vulnerabilities.' Candidates confuse it with Metasploit or Cobalt Strike. Reality: Atomic Red Team does not exploit vulnerabilities; it simulates adversary behaviors that assume initial access already exists.
'Atomic tests are designed to be chained together to simulate full attacks.' Candidates think atomic tests are building blocks for a full kill chain. Reality: Each test is standalone. While they can be run sequentially, they are not designed to be chained automatically.
'Atomic Red Team requires a dedicated server and agents.' Candidates assume it works like commercial tools. Reality: It runs locally via PowerShell or Python; no server infrastructure is needed.
'Cleanup is optional because tests are harmless.' Candidates skip cleanup. Reality: Tests modify the system; cleanup is essential to avoid unintended persistence.
Specific Numbers, Values, and Terms That Appear on the Exam
Invoke-AtomicRedTeam (PowerShell module name).
Atomic-Operator (Python executor).
-GetPrereqs (flag to install dependencies).
-Cleanup (flag to revert changes).
MITRE ATT&CK technique IDs (e.g., T1059.001).
Red Canary as the developer.
GitHub as the distribution platform.
Edge Cases and Exceptions
Cross-platform: Atomic Red Team supports Windows, macOS, and Linux, but the PowerShell module only works on Windows. For other platforms, use the Python executor.
Dependency failures: If a prerequisite download fails (e.g., blocked by proxy), the test may not run. The exam may test that -GetPrereqs is used to check dependencies.
Cleanup failures: Some tests lack cleanup commands. The exam may ask what to do if cleanup fails—answer: manual removal.
How to Eliminate Wrong Answers
Focus on the core purpose: detection validation, not exploitation. If an answer mentions 'exploiting vulnerabilities' or 'gaining initial access,' eliminate it. If it mentions 'chaining tests' or 'automated kill chain,' eliminate it. Remember that Atomic Red Team is open-source and agentless (runs via PowerShell/Python). Any answer suggesting a proprietary server or agent is wrong.
Atomic Red Team is an open-source library of atomic tests that map to MITRE ATT&CK techniques.
Each atomic test is a single, self-contained action to validate detection and response controls.
The primary execution tool on Windows is the Invoke-AtomicRedTeam PowerShell module.
The primary execution tool on Linux/macOS is the atomic-operator Python package.
Always use the -GetPrereqs flag to install dependencies before running a test.
Always use the -Cleanup flag after a test to revert system changes.
Atomic Red Team does not exploit vulnerabilities; it simulates adversary behaviors assuming initial access.
The library is maintained by Red Canary and hosted on GitHub.
These come up on the exam all the time. Here's how to tell them apart.
Atomic Red Team
Open-source, free to use.
Focuses on detection validation, not exploitation.
Maps directly to MITRE ATT&CK techniques.
Runs as standalone atomic tests via PowerShell/Python.
Does not require a central server; agentless execution.
Metasploit
Open-source but with commercial versions (Metasploit Pro).
Focuses on exploitation and gaining initial access.
Has its own module database but can be mapped to ATT&CK.
Runs as a full framework with payloads, exploits, and post-exploitation modules.
Requires a Metasploit console or server; agents for payloads.
Mistake
Atomic Red Team is a vulnerability scanner like Nessus.
Correct
Atomic Red Team does not scan for vulnerabilities. It executes predefined adversary behaviors to test detection controls, not to find missing patches.
Mistake
Atomic tests are designed to be chained into a full attack simulation automatically.
Correct
Each atomic test is standalone and represents a single MITRE ATT&CK technique. While they can be run sequentially, there is no built-in chaining mechanism.
Mistake
Atomic Red Team requires a central server and agents on endpoints.
Correct
Atomic Red Team is agentless. It runs locally via PowerShell or Python scripts. No server infrastructure is needed.
Mistake
Cleanup is optional because atomic tests do not modify the system.
Correct
Atomic tests create files, processes, registry keys, and scheduled tasks. Cleanup is essential to revert these changes and avoid system clutter or security risks.
Mistake
Atomic Red Team can be used for initial access exploitation.
Correct
Atomic Red Team assumes the attacker already has access. It simulates post-exploitation behaviors like persistence, privilege escalation, and defense evasion.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Atomic Red Team focuses on individual adversary techniques (e.g., creating a scheduled task) rather than a full kill chain. Penetration tests often involve multiple steps to gain access, escalate privileges, and move laterally. Atomic Red Team assumes the attacker already has access and tests specific behaviors to validate detection. It is faster, more repeatable, and safer for production environments.
On Linux, use the atomic-operator Python package. Install via pip: `pip install atomic-operator`. Then clone the Atomic Red Team repository and run a test with: `atomic-operator T1059.001 -p /path/to/atomic-red-team`. The Python executor supports the same flags as the PowerShell module, including -GetPrereqs and -Cleanup.
First, check if dependencies are met by running with -GetPrereqs. Verify that the test is supported on your platform (Windows, macOS, Linux). Ensure you have appropriate permissions (admin rights). Check the test's YAML file for any hardcoded paths or prerequisites. If the test still fails, it may be due to security software blocking the command—temporarily disable the control or whitelist the test.
Yes, but with caution. Run tests on non-production systems or during maintenance windows. Some tests may trigger security alerts or cause system instability. Always use the -Cleanup flag and verify that cleanup completes. Avoid running tests that modify critical system components (e.g., disabling security software) on production systems without approval.
Atomic Red Team generates standard operating system logs (e.g., Windows Event Logs, syslog). These logs are ingested by the SIEM. The blue team can then check if their detection rules trigger on the events. For example, a test that creates a scheduled task generates Event ID 4698, which a SIEM rule might correlate to a persistence technique.
Each atomic test is associated with a specific MITRE ATT&CK technique ID (e.g., T1059.001 for PowerShell). The YAML file includes the technique ID, tactic, and platform. This mapping allows teams to align their testing with the ATT&CK framework and ensure coverage of known adversary behaviors.
No. While the PowerShell module is Windows-only, the atomic-operator Python executor supports Windows, macOS, and Linux. The library includes tests for all three platforms, though Windows has the most coverage.
You've just covered Attack Simulation Tools: Atomic Red Team — now see how well it sticks with free CS0-003 practice questions. Full explanations included, no account needed.
Done with this chapter?