Purple Team in Practice: Building a Red vs Blue Feedback Loop

Purple Team is not a quarterly workshop with pizza and pretty slides, it is an engineering cadence where every TTP executed by Red becomes a detection hypothesis for Blue within 72 hours. At Basilisk OffSec we run two-week sprints: 10 techniques cherry-picked from ATT&CK, controlled execution in a corporate lab, and closure with a Sigma rule shipped to production. The KPI is not how many shells Red popped, it is how many techniques moved from 'undetected' to 'alerted with low false positive'. Anyone not measuring that delta is running expensive security theater. This guide breaks the cycle into reproducible steps, concrete tooling, and metrics that survive a board review.

What Purple Team actually means

Running Red and Blue in isolation produces two truths: attackers writing reports nobody turns into detections, and defenders building rules no real adversary ever trips. Purple Team erases the boundary by binding both sides to the same timeline and the same artifact. It is a function, not a permanent headcount: the same people swap roles each exercise. The operational goal is collapsing the feedback loop from months to days. A mature cycle produces at least one versioned detection per sprint, a linked response playbook, and a measured drop in mean time to detect for the practiced technique. Everything else is preparation.

Prioritize techniques by real threat intel

The starting point is a technique catalog prioritized by real threat intel, not conference hype. We grab fresh reports (Mandiant M-Trends, CrowdStrike OverWatch, CISA advisories) and cross-reference them with the ATT&CK Enterprise v15 matrix. For a financial operation, for example, T1078.004 (cloud accounts), T1558.003 (Kerberoasting) and T1059.001 (PowerShell) end up at the top. Prioritization follows three axes: likelihood against our sector profile, blast radius on success, and current detection gap per the ATT&CK Navigator. Techniques we already catch reliably drop down the list; the dark cells of the heatmap set the sprint. That keeps the exercise anchored to measurable risk instead of personal curiosity.

The written contract between Red and Blue

Before execution, Red documents the exact procedure and Blue sketches which telemetry should capture each step. This written contract kills the classic 'we did not see it because Splunk was not ingesting that index'. The contract names, per technique: expected data source (Sysmon Event ID 1, 4688, 4104, a Zeek log), expected field, and baseline noise. If the data source is missing, that is a finding before the first payload. This dry run routinely surfaces a sensor that is deployed but not collected, or PowerShell Script Block Logging switched off. Those exact blind spots are what save a real incident later.

Controlled execution inside the window

Execution happens in an agreed window, with an exercise flag in the logs and a Slack #purple-live channel open. Every Red action gets a UTC timestamp, target hostname and binary hash. When we run Kerberoasting via Rubeus, the operator notes the exact extracted ticket and the targeted service account. In parallel, a SOC analyst tries to detect in real time without knowing which step comes next, mimicking the real scenario. If they catch it in four minutes, we mark green. If it slipped through, it becomes a Jira ticket with priority set by the criticality of the touched asset. We deliberately run with OPSEC disabled (loud flags, default named pipes) so Blue can actually see the artifacts.

From finding to durable rule

Post-execution, the hard work begins: turning a finding into a durable rule. We convert hypotheses into Sigma first as a vendor-neutral source of truth, then into EQL on Elastic and KQL on Sentinel. A rule only merges to main if it meets three criteria: it covers the exercise technique, generates fewer than 5 false positives per week in staging, and has a linked response playbook. Evasion techniques force the team to move past signatures into behavioral detection, watching NtAllocateVirtualMemory calls, anomalous parent-child patterns, and LSASS handle access. A rule with no test case that provably triggers it is considered unfinished.

Auditable exercise infrastructure

Exercise infra must be auditable. C2 runs in an isolated VLAN with full PCAP capture, and traffic is mirrored to the staging SIEM via port mirror. Lateral movement follows a fixed playbook with Impacket and Evil-WinRM, always with loud flags so Blue sees the artifacts. Internal pivoting uses Chisel or Ligolo-ng over cleanly documented tunnels. Everything is logged in a private Git repo: every Red commit is referenced by the corresponding Blue rule PR, creating traceability that auditors love and managers love to show the board. VM snapshots before and after the exercise allow clean replay whenever a rule needs tuning.

Metrics and shared language

Communication kills more Purple Team programs than tooling gaps. We establish shared vocabulary: 'detected' means an alert was generated and triaged, not just that a log sits in some cold index. Retros run 60 minutes with three slides: techniques executed, detections shipped, open technical debt. Metrics we track: MTTD per ATT&CK category, percentage of Tactics coverage in the environment, and count of rules with FP rate above threshold. In six months, one customer went from 23% Credential Access coverage to 71%, with a 40% drop in noisy alerts. Those numbers are the language that frees budget.

Common pitfalls

The first pitfall is competition: the moment Red wants to 'win', it stops playing loud and Blue learns nothing. The second is the rule with no playbook that fires at 3 a.m. and directs nobody to act. The third is the rule never tested in staging that produces 200 false positives a day in production and gets muted within a week. The fourth is the absence of versioning: a detection that lives only in an analyst's head disappears with them. The fifth is skipping the dry run, so missing telemetry only surfaces mid-execution and blows up the sprint.

Practical checklist

Before the sprint: pick five sector-relevant techniques, sign a written contract with the SOC, verify data sources per technique. During the sprint: execute in the window with an exercise flag and full logging, note every action with timestamp and hash, mark detections live in #purple-live. After the sprint: write the Sigma rule, translate it into EQL and KQL, test it in staging against the FP threshold, link the response playbook, merge to Git, measure MTTD. No sprint counts as done without a single versioned artifact. That artifact is exactly what separates continuous detection from one-off entertainment.

Roles, rotation, and psychology

Purple Team only works when roles rotate and nobody holds a permanent winner's seat. In practice, an analyst who played Blue for three sprints deliberately switches to the Red side to feel how fragile their own detections are under light variation. This rotation builds empathy and dissolves the silo mentality where Red thinks the defenders are slow and Blue thinks the attackers are show-offs. The facilitator, often a detection engineer, keeps the exercise honest: no gotcha moments, no hidden payloads, no piling on in the retro. When a technique slips through, that is a systemic gap in telemetry, not a personal failure of the analyst. This exact culture decides whether the program is still alive after the third sprint or suffocates in mutual blame. A board funds measurable maturation, not a mud fight between two teams. Treat the relationship as one team wearing two hats, and the numbers follow.

Automation with Atomic Red Team and CI

Once the manual cycle is solid, we automate the regression. Atomic Red Team ships atomic, YAML-described tests per ATT&CK technique that run in a pipeline against a throwaway VM. After every SIEM content update we re-fire the relevant atomics and check whether the associated Sigma rule still triggers; if it breaks, the build fails, exactly like a unit test. This prevents detection drift, where a working rule silently goes quiet because a field was renamed in the log schema. The results land as a coverage report in the same Git repo, versioned alongside the rules. The boundary matters: automation does not replace the human hypothesis, it only protects what has already been achieved. New techniques still come from threat intel and manual emulation; CI merely guarantees that no existing detection decays unnoticed while the environment keeps evolving underneath it.

FAQ: How often should a Purple Team cycle run?

Two-week sprints are the sweet spot for most teams: short enough to keep momentum, long enough to actually harden a rule into production. Weekly burns the team out and ships half-baked detections; monthly lets the feedback loop lose its edge. Five to ten techniques per sprint is realistic when each one ends in a versioned rule.

FAQ: Do you need expensive tools for Purple Team?

No. Sysmon with a hardened config, the ELK stack or Wazuh, Atomic Red Team for execution, and Sigma for portable rules are enough for a full cycle with zero licensing cost. The bottleneck is never the tool, it is the discipline to close the loop and turn every technique into a versioned artifact.

Conclusion

Practical takeaway: start small and measurable. Pick five techniques relevant to your sector, write a contract with the SOC, execute in a short window with full logging, and do not close the sprint without a Sigma rule versioned in Git. Purple Team that leaves no versioned artifact behind did not scale, it only entertained. The cycle Red-builds-hypothesis, Blue-validates-telemetry, team-merges-rule-to-production must fit in two weeks. If it takes longer, you are managing a project, not operating continuous detection. Repeat the cycle until the dark cells of the ATT&CK heatmap turn into measured coverage.