| 1 | --- |
| 2 | title: Atomic Red Team (detection simulation) |
| 3 | description: Run Atomic Red Team simulations to verify telemetry flow and validate that Wazuh detection rules fire as expected. |
| 4 | --- |
| 5 | |
| 6 | Atomic Red Team is a detection validation workflow: you simulate known adversary behaviors (“atomic tests”) and confirm your stack detects what it should. |
| 7 | |
| 8 | In CoPilot, this is commonly used to: |
| 9 | - validate that **telemetry is flowing** end-to-end |
| 10 | - verify your **Wazuh detection rules** are triggering as expected |
| 11 | - identify blind spots and tuning opportunities before a real attacker shows up |
| 12 | |
| 13 |  |
| 14 | |
| 15 | --- |
| 16 | |
| 17 | ## What it is |
| 18 | |
| 19 | Atomic Red Team is a library of small, self-contained tests mapped to the **MITRE ATT&CK** framework. |
| 20 | |
| 21 | Regularly running these tests helps: |
| 22 | - prevent detection drift |
| 23 | - validate new rules and changes |
| 24 | - confirm the “alerting pipeline” still works after upgrades |
| 25 | |
| 26 | --- |
| 27 | |
| 28 | ## Why this is a power feature |
| 29 | |
| 30 | Detection simulation isn’t required for initial SIEM bring-up, but it’s one of the best ways to build confidence in your detections. |
| 31 | |
| 32 | It’s especially valuable when: |
| 33 | - you just deployed new Wazuh rules |
| 34 | - you changed Sysmon collection or agent group configs |
| 35 | - you’re onboarding a new customer and need to prove coverage |
| 36 | |
| 37 | --- |
| 38 | |
| 39 | ## How it works (high level) |
| 40 | |
| 41 | The workflow shown in the videos: |
| 42 | |
| 43 | 1) Install Atomic Red Team on an endpoint (Windows or Linux) |
| 44 | 2) Use a **Velociraptor artifact** to run a chosen atomic test remotely |
| 45 | 3) Confirm events are collected and shipped (agent → manager/indexer → Graylog/CoPilot) |
| 46 | 4) Validate: |
| 47 | - the expected alert fired |
| 48 | - the alert arrived in the right place (SIEM views and/or Incident Management) |
| 49 | |
| 50 | --- |
| 51 | |
| 52 | ## Operator workflow (practical) |
| 53 | |
| 54 | 1) Choose a technique/test you want to validate (start with something safe) |
| 55 | 2) Run it on a **dedicated test endpoint** (recommended) |
| 56 | 3) Watch for: |
| 57 | - Wazuh alert firing |
| 58 | - the event appearing in SIEM search |
| 59 | - the alert being routed into Incident Management (if that’s part of your pipeline) |
| 60 | 4) If it didn’t fire: |
| 61 | - validate telemetry collection (Sysmon/auditd) |
| 62 | - validate rule logic and mapping |
| 63 | - validate routing/streams/event definitions |
| 64 | |
| 65 | --- |
| 66 | |
| 67 | ## Setup checklist |
| 68 | |
| 69 | ### 1) Use a safe test target |
| 70 | |
| 71 | - Prefer a **lab endpoint** (not production) |
| 72 | - Document which tests you run and when |
| 73 | |
| 74 | ### 2) Install Atomic Red Team |
| 75 | |
| 76 | The videos demonstrate installing Atomic Red Team so the test library exists locally on the endpoint. |
| 77 | |
| 78 | ### 3) Import Velociraptor artifacts to run tests remotely |
| 79 | |
| 80 | A key improvement is using Velociraptor artifacts to run tests without manually SSH/RDP’ing into hosts. |
| 81 | |
| 82 | Canonical repo for the Atomic Red Team Velociraptor artifacts: |
| 83 | - https://github.com/socfortress/VELOCIRAPTOR-ATOMIC-RED-ARTIFACTS |
| 84 | |
| 85 | The videos reference: |
| 86 | - a Windows Atomic test execution artifact |
| 87 | - a Linux attack simulation artifact |
| 88 | |
| 89 | Once imported into Velociraptor, CoPilot/Velociraptor can run tests in a repeatable way. |
| 90 | |
| 91 | ### 4) Validate detection + routing |
| 92 | |
| 93 | Use CoPilot to confirm the end-to-end path: |
| 94 | - detections trigger in Wazuh |
| 95 | - events are searchable in your datastore |
| 96 | - alerts show up where you expect (SIEM views vs Incident Management) |
| 97 | |
| 98 | --- |
| 99 | |
| 100 | ## Where to find it |
| 101 | |
| 102 | - UI: [Atomic Red Team (alerts view)](/user/ui/alerts-atomic-red-team) |
| 103 | |
| 104 | --- |
| 105 | |
| 106 | ## Gotchas |
| 107 | |
| 108 | - Don’t run aggressive tests on production systems. |
| 109 | - Some tests can create artifacts (scheduled tasks, registry changes, etc.). Understand cleanup behavior before running. |
| 110 | - A “failed” test is still useful: it often reveals missing telemetry, broken routing, or overly strict rule logic. |
| 111 | |
| 112 | --- |
| 113 | |
| 114 | ## Related repositories |
| 115 | |
| 116 | - Velociraptor Atomic Red artifacts: |
| 117 | - https://github.com/socfortress/VELOCIRAPTOR-ATOMIC-RED-ARTIFACTS |
| 118 | |
| 119 | ## Video context |
| 120 | |
| 121 | - Windows-focused validation workflow: |
| 122 | - https://www.youtube.com/watch?v=TMJOBATTK9M |
| 123 | |
| 124 | - Linux-focused validation workflow: |
| 125 | - https://www.youtube.com/watch?v=tL3oNEx_3M8 |