Purple-Team Lab — Zion Boggan

What this is

Detection rules in isolation are claims, not proofs. This lab is the validation step: I emulate ATT&CK techniques against an instrumented Ubuntu endpoint and confirm that each one raises the right alert, mapped to the correct technique at a severity level that would actually trigger a response. The rules validated here come from detection-as-code; the SOC automation lab is the SIEM they fire in.

The target is a dedicated Ubuntu 22.04 VM, not a container. Kernel-level telemetry needs a real kernel. A containerized target would miss the auth log and real-time FIM events the detections key on.

Why FIM instead of auditd

The four persistence detections key off file integrity monitoring, not syscall auditing. That's a deliberate choice: Wazuh FIM is native and works everywhere, including hardened hosts and containers where the kernel audit framework isn't available or boots disabled. Auditd execve rules silently do nothing on a host that doesn't have auditing enabled, but FIM events arrive regardless.

An auditd ruleset for hosts that do have kernel auditing is included at agent/auditd-purple.rules, but the validated detections don't depend on it.

atomics/run_atomics.sh: the six-technique validation set
#!/usr/bin/env bash
set -u

log() { echo "[$(date +%H:%M:%S)] $*"; }

log "T1053.003 - cron persistence"
echo '* * * * * root /usr/bin/id' | sudo tee /etc/cron.d/atomic-persist >/dev/null

log "T1543.002 - systemd service persistence"
printf '[Unit]\nDescription=atomic test\n[Service]\nExecStart=/usr/bin/id\n[Install]\nWantedBy=multi-user.target\n' \
  | sudo tee /etc/systemd/system/atomic-evil.service >/dev/null

log "T1098.004 - SSH authorized_keys persistence"
mkdir -p "$HOME/.ssh"
echo 'ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIAtomicRedTeamTestKeyDoNotUse attacker@evil' >> "$HOME/.ssh/authorized_keys"

log "T1543 - tooling drop into /usr/local/bin"
printf '#!/bin/bash\nid\n' | sudo tee /usr/local/bin/definitely-not-malware >/dev/null
sudo chmod +x /usr/local/bin/definitely-not-malware

log "T1110 - SSH brute force (18 invalid users)"
for i in $(seq 1 18); do
  ssh -o BatchMode=yes -o ConnectTimeout=2 -o StrictHostKeyChecking=no \
      -o PreferredAuthentications=password -o PubkeyAuthentication=no \
      "evil_user_${i}@127.0.0.1" true 2>/dev/null
done

log "done - check Wazuh for rule.id 100410-100413 and 5712"

Validation matrix

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

Technique	Atomic	Telemetry	Rule	Result
T1110 Brute Force	18 invalid SSH logins	auth log	`5712` (built-in)	detected
T1053.003 Cron persistence	drop job in `/etc/cron.d`	FIM	`100410` (custom)	detected
T1543.002 Systemd persistence	create `.service` unit	FIM	`100411` (custom)	detected
T1098.004 SSH authorized_keys	append attacker key	FIM	`100412` (custom, level 12)	detected
T1543 Tooling drop	binary into `/usr/local/bin`	FIM	`100413` (custom)	detected
T1078 / T1548.003	login + sudo to root	auth log	`5501` / `5402`	informational baseline

The custom rules are in rules/local_purple_rules.xml and are deployed to the Wazuh manager. MITRE 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.