Purple Team Operations: Lessons From 3 Years of SOC Work
Purple team exercises — where red and blue work together in real time rather than in isolated phases — are standard practice at serious security programs now. But the execution gap between theory and what actually produces detection improvements is wide.
Here's what 3+ years of enterprise SOC operations and purple team coordination taught us at FLLC.
The Coordination Problem Nobody Talks About
Most purple team failures aren't technical. They're coordination failures. Red comes in with a list of techniques. Blue tries to write detections on the fly. The debrief happens a week later when institutional memory has faded.
The fix: real-time atomic detection building.
For every red team technique executed, the blue team writes a detection rule while the red operator is still in the environment. The red operator re-runs the technique. The detection either fires or doesn't. Iterate until it does. Document the final rule in the runbook before moving to the next technique.
This sounds slow. It is, compared to a pure red team assessment. But the output — a validated detection library tied directly to observed adversary behavior — is worth more than any report.
The 5 Techniques That Produce the Most Detection Value
Based on our engagements, these techniques have the highest ROI for purple team coverage because they appear in nearly every real intrusion and are frequently undetected:
1. LSASS Memory Access
Technique: T1003.001
Tool: Mimikatz, Nanodump, custom
Detection anchor: Sysmon Event ID 10 on lsass.exe
False positive rate: Low with proper process exclusions
2. Scheduled Task Persistence
Technique: T1053.005
Detection anchor: Windows Event 4698 + Task Scheduler operational log
Key signal: Tasks created by non-SYSTEM accounts in unusual paths
3. PowerShell Encoded Commands
Technique: T1059.001
Detection anchor: Process command line containing -enc or -EncodedCommand
False positive rate: Higher in environments with legitimate automation
Fix: Allowlist known encoded commands by hash
4. WMI Lateral Movement
Technique: T1047
Detection anchor: WMI subscription events + remote process creation via wmiprvse.exe
Often missed: Network connection from wmiprvse.exe to non-standard destinations
5. Kerberoasting
Technique: T1558.003
Detection anchor: Event 4769 with Ticket Encryption Type 0x17 (RC4)
Strong signal: Multiple 4769 events from single source in short window
Building the Runbook
Every detection we validate in a purple exercise goes into a structured runbook entry:
## Detection: LSASS Memory Access
**MITRE**: T1003.001
**Severity**: Critical
**Log Source**: Sysmon Event ID 10
**Query** (Splunk):
index=windows source=XmlWinEventLog:Microsoft-Windows-Sysmon/Operational
EventCode=10 TargetImage="*lsass.exe"
| where NOT (SourceImage IN (known_av_processes))
**Response**: Isolate host, pull memory for forensics, escalate to IR
**Last Validated**: 2026-05-01
**Validated By**: Purple Exercise #14
The "Last Validated" date matters. Detections rot. Vendors update software, environments change, and a rule that caught a technique in 2024 may miss it in 2026 due to environment drift.
What Actually Improves Security Posture
After 3 years of this work, the honest answer is: logging fidelity beats detection sophistication every time.
The best detection rule is worthless if the log source isn't configured correctly. Before every purple engagement, we run a logging audit:
- Sysmon deployed and current config? (SwiftOnSecurity/sysmon-config as baseline)
- PowerShell Script Block Logging enabled?
- WMI activity logging configured?
- Network traffic logs (NetFlow or full PCAP) available?
- EDR coverage gap analysis completed?
Log gaps are more dangerous than detection gaps. You can write a detection rule in an hour. Fixing log coverage across a distributed enterprise takes weeks.