What is Purple Team?

The Purple Team Exercise Framework (PTEF), the methodology SCYTHE publishes on GitHub, now at version 4, defines a purple team as a collaboration of three skill sets: cyber threat intelligence, which researches adversary TTPs; the red team, which emulates them; and the blue team, its catch-all for the SOC, hunt team, DFIR and any MSSP. It calls the exercise a full-knowledge assessment: attack activity is exposed, explained and shown as it happens, while defenders show how they detect and respond. That openness is the difference from a red team engagement. NIST SP 800-53 control CA-8(2) describes red team exercises as simulating adversary attempts to compromise organizational systems under rules of engagement, and full-time red teams run what PTEF calls zero-knowledge exercises, so the test measures what defenders catch on their own. PTEF describes three ways to organize the work: one-off exercises, an operationalized purple team (a virtual team that emulates each new TTP as intelligence arrives) and dedicated purple team roles.

PTEF's exercise flow has six steps. The coordinator or CTI presents the adversary and its TTPs. The group runs a tabletop on each TTP: the SOC says which logs or alerts it expects, the hunt team names any hunt for it, and DFIR explains how it would prove the technique was used. The red team executes while sharing its screen and gives the attacker IP, the target and the exact time. The blue team follows its normal process to find the evidence, and the metrics go on record. If the gap can be closed on the spot, detection engineering adjusts and the red team runs the technique again. Then the next TTP.

The TTPs come from intelligence about a specific adversary, and several public libraries turn that into something runnable. MITRE built its adversary emulation plans so red teams could model the behavior described in ATT&CK, and so defenders could write analytics for behaviors rather than for one indicator or tool. The Center for Threat-Informed Defense maintains a library with two kinds of plan: full emulation of one adversary from initial access to exfiltration (FIN6 and APT29 among them) and micro emulation of compound behaviors seen across many groups, such as web shells. Atomic Red Team, from Red Canary, is a library of small tests mapped to ATT&CK, built to test an environment quickly, portably and reproducibly, which suits single-technique sessions.

One technique through the loop (simulated example generated by SOCSimulator Research; host names are invented). The CTI brief says the emulated group persists with Scheduled Task/Job: Scheduled Task (T1053.005), which ATT&CK files under Execution, Persistence and Privilege Escalation. In the tabletop the SOC says a rule covers it. At 10:42 the red team runs the first Atomic Red Team test for the technique on ws-fin-031:

Invoke-AtomicTest T1053.005 -TestNumbers 1

That test, Scheduled Task Startup Script (GUID fec27f65-db86-4c2d-b66c-61945aee87c2), needs elevation and creates two tasks:

schtasks /create /tn "T1053_005_OnLogon" /sc onlogon /tr "cmd.exe /c calc.exe" schtasks /create /tn "T1053_005_OnStartup" /sc onstart /ru system /tr "cmd.exe /c calc.exe"

Nothing alerts, so the blue team looks for telemetry. The Security log holds two 4698 events, A scheduled task was created, which Windows writes only when the Audit Other Object Access Events subcategory is enabled; each carries the TaskName and the full task XML in TaskContent. Sysmon event ID 1 has both schtasks.exe process creations with their command lines. A 4688 event would carry the command line only if the Include command line in process creation events policy is on, and here it is not. So the telemetry exists. The SOC's rule fires on 4698 only when the task's action points into a user-writable folder such as AppData or Temp, and cmd.exe starting calc.exe matches neither. PTEF calls that a detection logic gap and would score the technique 1 out of 5: telemetry available, no rule or hunt uses it.

Still on the call, the detection engineer writes a hunting query in Defender advanced hunting:

DeviceProcessEvents | where Timestamp > ago(1d) | where FileName =~ "schtasks.exe" and ProcessCommandLine has "create" | where ProcessCommandLine has_any ("onlogon", "onstart") | project Timestamp, DeviceName, AccountName, InitiatingProcessFileName, ProcessCommandLine

It returns both commands from ws-fin-031 at 10:42, which moves the score to 2, hunt capable. Before it becomes a rule, the same query runs over 30 days, because updaters and management agents also register logon and startup tasks; the parent process and the account separate them from an interactive user running schtasks.exe through cmd.exe. The engineer excludes the software deployment tool's parent process, deploys the rule, and the red team cleans up with Invoke-AtomicTest T1053.005 -TestNumbers 1 -Cleanup and runs the test again. At 10:58 the alert reaches the queue (3), and the L1 analyst escalates it within the agreed time (4). The row that goes on record names the technique, the test GUID, the scores before and after, the gap type, the rule ID and the false positives found in the 30-day run.

A workable rule for closing a technique has three parts: the test was re-run after the change and the alert fired, the rule's false-positive volume over a month of history is written down, and the test sits in a regression suite. PTEF asks for that last part explicitly, so a detection that quietly stops firing is noticed instead of discovered during an incident. Across techniques the output is a coverage map. PTEF keeps it as ATT&CK Navigator layers (a baseline before the exercise, the results with a 0 to 5 score per technique, and a post-remediation layer to compare against), and VECTR, which describes itself as tracking red and blue team testing activities to measure detection and prevention capabilities, records the same outcomes per test case. A score beats a checkmark, because telemetry exists and an alert reached someone who acted are different findings.

PTEF sorts every miss into one of five gap types, because each has a different fix: visibility (the telemetry isn't collected), detection logic (collected, no rule), alert suppression (a rule exists but was tuned out or disabled), process (the alert fired and nobody acted) and timeliness (found, but too late to matter). Its own suppression example is a rule for suspicious scheduled task creation, disabled six months earlier because a software deployment tool kept tripping it. When most misses are visibility gaps, PTEF reads that as a data engineering problem; when most are process gaps, the problem is people or workflow.

Purple teaming and breach and attack simulation (BAS) solve different halves. MITRE's Caldera describes itself as an adversary emulation platform for running autonomous breach and attack simulation exercises, and PTEF uses BAS for continuous testing: import the TTPs validated in an exercise, schedule them against production, and alert when a previously detected TTP stops firing. A BAS run tells you a test produced no alert. It doesn't tell you whether the cause was collection, logic or suppression, and it doesn't write the fix. Teams that have both use the exercise to build detections and the schedule to keep them working.

On cadence, NIST leaves the frequency of penetration testing to each organization; in CA-8 it is an organization-defined parameter. PTEF proposes layers: weekly automated regression of the existing TTP library, a monthly mini-exercise on 5 to 10 new or changed TTPs, a quarterly full exercise, and an annual comprehensive one with executive reporting. A small team can start with the monthly session alone. It needs no BAS platform, and the first few sessions show which data sources never reach the SIEM.