# Purple-Team Lab

Emulate adversary techniques, then prove the detections fire. This is the validation

half of [detection-as-code](https://github.com/zionboggan/detection-as-code): I run

ATT&CK techniques against an instrumented Ubuntu endpoint enrolled in my

[SOC automation lab](https://github.com/zionboggan/soc-automation-lab), and confirm

each one raises the alert it's supposed to - mapped to the right technique, at a

severity that would actually page someone.

Writing a detection is a hypothesis. This is the test.

![Emulated techniques detected in Wazuh](docs/screenshots/01-detections-fired.png)

Every row is an atomic I executed on the endpoint and the rule that caught it - five of

the six are detections I wrote (`100410`-`100413`) plus the brute-force rule, all on the

`purple-target` agent, all ATT&CK-tagged.

## How it's wired

```mermaid

flowchart LR

    A[Atomic Red Team atomics<br/>run on purple-target VM] --> B[Wazuh agent<br/>auth log + real-time FIM]

    B -->|1514/tcp| C[Wazuh manager<br/>analysisd: built-in + custom rules]

    C --> D[Indexer]

    D --> E[Dashboard<br/>ATT&CK-mapped alerts]

    F[MITRE Caldera<br/>adversary emulation] -.-> B

```

The target is a dedicated Ubuntu 22.04 VM (not a container - kernel-level telemetry

needs a real kernel). It runs the Wazuh agent shipping auth logs and **real-time file

integrity monitoring** on the paths attackers use for persistence. Caldera is available

for graph-based adversary emulation; the day-to-day validation uses Atomic Red Team

because it maps cleanly one-atomic-to-one-detection.

## Validation matrix

Each technique was executed on the endpoint and confirmed in the SIEM:

| Technique | Atomic | Telemetry | Rule | Level | Result |

|-----------|--------|-----------|------|-------|--------|

| T1110 Brute Force | 18 invalid SSH logins | auth log | `5712` (built-in) | 10 | ✅ detected |

| T1053.003 Cron persistence | drop job in `/etc/cron.d` | FIM | `100410` (custom) | 10 | ✅ detected |

| T1543.002 Systemd persistence | create `.service` unit | FIM | `100411` (custom) | 10 | ✅ detected |

| T1098.004 SSH authorized_keys | append attacker key | FIM | `100412` (custom) | 12 | ✅ detected |

| T1543 Tooling drop | binary into `/usr/local/bin` | FIM | `100413` (custom) | 10 | ✅ detected |

| T1078 / T1548.003 | login + sudo to root | auth log | `5501` / `5402` | 3 | ✅ (informational baseline) |

The custom rules are in [`rules/local_purple_rules.xml`](rules/local_purple_rules.xml);

the atomics that exercise them are in [`atomics/run_atomics.sh`](atomics/run_atomics.sh).

## Why FIM for persistence

The persistence detections key off **file integrity monitoring**, not syscall auditing.

That's deliberate: FIM is Wazuh-native and works everywhere - including containers and

hardened hosts where the kernel audit framework isn't available to you - whereas auditd

execve rules silently do nothing on a host that boots with audit disabled. The auditd

ruleset I'd layer on a host that *does* have kernel auditing is included in

[`agent/auditd-purple.rules`](agent/auditd-purple.rules), but the validated detections

above don't depend on it.

## Run it

On the endpoint (enrolled Wazuh agent + the FIM config from `agent/`):

```bash

sudo bash atomics/run_atomics.sh          # execute the technique set

```

Then in the Wazuh dashboard, filter Threat Hunting → Events to

`rule.id:(100410 or 100411 or 100412 or 100413 or 5712)` and confirm the hits.

Caldera (adversary-emulation UI, optional):

```bash

cd caldera && docker compose up -d         # http://localhost:8888

```

## Layout

```

rules/local_purple_rules.xml   custom FIM detections (deploy to the manager)

agent/fim-directories.xml      real-time FIM config for the agent's syscheck block

agent/auditd-purple.rules      auditd rules for hosts with kernel auditing

atomics/run_atomics.sh         the ATT&CK technique set

caldera/docker-compose.yml     MITRE Caldera server

docs/validation-matrix.md      the matrix above, with notes per technique

```