performing-purple-team-atomic-testing

name	performing-purple-team-atomic-testing
description	Executes Atomic Red Team tests mapped to MITRE ATT&CK techniques, performs coverage gap analysis across the ATT&CK matrix, and runs detection validation loops to measure blue team visibility. Covers Invoke-AtomicRedTeam PowerShell execution, ATT&CK Navigator layer generation for heatmaps, Sigma rule correlation, and continuous atomic testing pipelines. Activates for requests involving purple team exercises, atomic test execution, ATT&CK coverage assessment, detection engineering validation, or adversary emulation testing.
domain	cybersecurity
subdomain	purple-team
tags	["purple-team","atomic-red-team","mitre-attack","detection-engineering","adversary-emulation"]
version	1.0.0
author	mukul975
license	Apache-2.0
nist_ai_rmf	["MEASURE-2.7","MAP-5.1","MANAGE-2.4"]
atlas_techniques	["AML.T0070","AML.T0066","AML.T0082"]
d3fend_techniques	["Executable Denylisting","Execution Isolation","File Metadata Consistency Validation","Content Format Conversion","File Content Analysis"]
nist_csf	["ID.RA-01","DE.AE-07","GV.OV-02"]

Performing Purple Team Atomic Testing

When to Use

• Validating detection coverage against specific MITRE ATT&CK techniques
• Running purple team exercises using Atomic Red Team test library
• Performing ATT&CK coverage gap analysis to identify blind spots in SIEM/EDR
• Building a detection validation loop: execute atomic test, check SIEM, tune rule, retest
• Generating ATT&CK Navigator heatmap layers for executive reporting
• Automating continuous atomic testing in CI/CD or scheduled pipelines
• Mapping threat intelligence reports to executable atomic tests

Do not use for full-scope red team engagements requiring custom implants or live adversary simulation beyond atomic tests; use Caldera, SCYTHE, or Cobalt Strike for advanced adversary emulation.

DISCLAIMER: Atomic Red Team tests execute real attack techniques. Run only on systems you own or have explicit written authorization to test. Many tests modify system state, create artifacts, or trigger security alerts. Always execute cleanup commands after testing. Never run atomic tests in production without risk acceptance from stakeholders.

Most Often Missed & How to Confirm

• "Executed" is not "detected": Invoke-AtomicTest T1059.001 returning success only proves the technique ran. The metric that matters is whether the SIEM/EDR raised an alert. Treat any test that executes without a corresponding detection as a blind spot, not a pass.
• Map to ATT&CK before testing: drive selection from the matrix (e.g. T1059.001 PowerShell, T1003.001 LSASS, T1547.001 Run keys, T1053.005 Scheduled Task, T1218.011 Rundll32) so coverage is measured against techniques, not ad-hoc scripts.
• Logging vs alerting gap: an event landing in the index (Sysmon EventCode 1/13, 4104, 4663) is telemetry, not detection. Confirm a rule fired and an alert/case was created — not just that the raw log exists.
• Cleanup and prereqs skew results: missing prerequisites cause silent no-ops, and skipped -Cleanup leaves artifacts that taint later runs. Use -CheckPrereqs/-GetPrereqs and always run -Cleanup.
• How to confirm a detection end-to-end: after execution, query the SIEM (Splunk SPL on the relevant index/EventCode, or Elastic KQL on event.code) and verify the matching Sigma/EDR rule produced an alert within the ingestion window. Allow for log-ingestion delay (Start-Sleep between test and query) before declaring a gap.
• Don't conclude a technique is "covered" until the test executed, the telemetry arrived, the rule fired, and the alert is visible to the analyst — verified per ATT&CK technique, ideally rendered as an ATT&CK Navigator heatmap layer.