Hacker Tradecraft · Volume 12
Hacker Tradecraft Volume 12 — The Purple Hat: The Synthesis
Purple as the integration of red and blue — the collaborative adversary-emulation-to-detection-engineering feedback loop, Atomic Red Team / CALDERA / VECTR as the canonical tooling, SANS SEC599 and SEC699 as the canonical curriculum, and the practitioner-vs-practice disambiguation that keeps purple from being read as a third role parallel to red and blue
Contents
About this volume. Volume 12 is the synthesis volume. It treats the purple hat as the field actually uses the term in 2026 — not primarily as a third role parallel to red and blue, but as the collaborative practice that integrates red-team adversary emulation with blue-team detection engineering into a single feedback loop. The volume’s load-bearing structural point is that purple is predominantly a verb in 2026, not a noun — purple-team is what an organization does, not (primarily) what a person is. Few practitioners identify their primary professional role as “purple-team operator” the way many identify as “red-team operator” or “blue-team SOC analyst”; almost all purple-team work is done by red-team practitioners and blue-team detection engineers collaborating in a structured exercise format. The volume’s secondary structural point is that purple-team work, when done well, is the mechanism through which a security organization’s detection coverage measurably improves — the cycle of red executes a known TTP, blue observes whether the detection fires, the detection-engineering function closes any gap, the next iteration of red re-validates, is the discipline that converts threat intelligence into deployed detection. The cycle exists because pure-red and pure-blue, run independently, do not close it on their own: pure-red finds gaps but doesn’t write the detections; pure-blue writes detections but doesn’t validate them against an adversary; purple is the integration that closes the loop. This volume closes the seven-hat cluster (Vols 6–12); the rest of the deep dive turns to the tradecraft-reference cluster (Vols 13–17), the careers and legal synthesis (Vols 18–19), and the cheatsheet and glossary (Vols 20–21). The reader (tjscientist, 45+-year EE/SW engineer) is not a working purple-team practitioner, but the engineering instincts the practice rewards — running an experiment with the instrumentation in place to measure whether it succeeded, iterating until the measurement converges, refusing to declare the work done until the loop closes — map directly onto how an EE thinks about a control system whose feedback path is the load-bearing structural feature.
1. Definition and boundary
The purple hat is the synthesis of the red hat (Vol 11) and the blue hat (Vol 10) into a collaborative integration practice. The primary modern meaning of “purple team” in 2026 industry usage is the practice: a structured exercise format in which red-team operators execute documented adversary techniques against an authorized environment while blue-team detection engineers observe the telemetry in real time, with the two teams collaboratively identifying detection gaps and writing detections to close them across the exercise. The secondary meaning of “purple hat” is the person: the (rarer) practitioner whose primary professional identity is the purple-team-integration role, typically someone who has worked both red and blue and now orchestrates the integration between them. This volume treats the practice as the primary subject and the practitioner as a secondary disambiguation; the practitioner population is small, the practice population is the entire field.
The authorization model for purple-team work is the same model the red hat shares with the blue hat: the engagement is authorized because both halves of the work — the red-team TTP execution and the blue-team monitoring — sit on the same side of the Axis 1 (ethical stance) line from Vol 5 §6. The red-team half operates under the same SOW + scope document + ROE that Vol 11 §1.2 walked; the blue-team half operates under the same employment-or-contract structural authorization Vol 10 §1.1 walked. The combination doesn’t change the authorization picture; it changes the engagement’s structural shape from sequential (red runs, blue eventually reads the report) to integrated (red runs while blue watches, with feedback loops between them). The hats are siblings to each other and to the white hat (Vol 6); the discriminator against the black hat (Vol 7) is, again, authorization and not technique.
This positioning matters because the popular framing — “red attacks, blue defends, purple is the third team in the middle” — collapses the practice into a role and loses the integration-loop point that is what actually makes purple-team work work. The accurate framing is red and blue are different posture-roles in the same organization; purple is the collaborative practice that integrates them. Vol 10 §8.2 made this point from the blue side; Vol 11 §8.2 made it from the red side; this volume makes it as the primary subject.
A second clarification — the load-bearing distinction this volume opens with — is that “purple” in 2026 carries two related-but-distinct meanings, and exactly one of them is the primary subject:
(a) Purple as PRACTICE (the primary meaning) — the collaborative red-and-blue exercise format, the detection-engineering feedback loop driven by adversary-emulation findings, the continuous adversary-emulation-to-detection-validation cycle, the integration discipline that closes the loop between offensive findings and defensive measurable improvement. This is what almost everyone means in 2026 when they say “we ran a purple team last quarter” or “our purple-team program is mature” or “we need to do more purple-team work.” This volume is primarily about this meaning.
(b) Purple as PERSON (the secondary meaning) — the purple-hat practitioner, typically a senior individual who has worked both red and blue and now orchestrates the integration practice. The role exists in some larger organizations (a “Purple Team Lead” job title appears at some Fortune 500 security organizations and at MSSPs with mature purple-team service offerings) but is rarer than the red-team-operator or blue-team-analyst role. Most purple-team work in 2026 is done by red-team practitioners and blue-team detection engineers collaborating in a purple-team exercise format, not by people whose full-time job is “purple-team operator.” This volume covers this meaning at §1.1 and §6.2 but does not center on it.
The popular shorthand “purple = red + blue” is correct in the same way that “an op-amp = transistors + feedback” is correct: technically true, but loses what the integration actually does. The feedback loop is the point. Without the loop, the red half is a report and the blue half is a wish-list; with the loop, the two halves become a measurable cycle of improvement. The next several sections walk what that loop looks like, who builds it, and what makes it work.
Purple is a verb, not a noun — load-bearing callout. Purple-team is overwhelmingly what an organization does, not what a person is. The 2026 practitioner population identifies its primary role as red-team or blue-team or detection-engineering, with purple-team work as a mode of engagement the same individuals participate in. The exception — the small population of practitioners whose primary identity is purple-team-integration — exists, but does not change the predominantly-practice character of the work. The volume’s structural treatment reflects this: §3 walks the purple-team tooling (the BAS platforms, the exercise-tracking platforms, the detection-engineering integration tools); §4 walks the purple-team exercise loop (the practice’s structural form); §5 walks the purple-team engagement composites (what running a purple-team exercise actually looks like day-to-day); §6 walks the purple-team career stage (the path most practitioners arrive at after red or blue experience, rather than the entry path). This callout appears in §8 again because it is the volume’s most-frequently-misread structural point.
1.1 The purple-team practitioner — when the role does exist
A purple-team-as-job-title role exists in three structural patterns. Naming them up front clarifies §6.2’s career-stage discussion:
- The in-house Purple Team Lead. A larger enterprise security organization with both a meaningful in-house red-team capability and a meaningful detection-engineering function will sometimes establish a dedicated purple-team coordination role — the person whose job description is running the integration practice between the two functions. The role is typically senior (10+ years of combined red + blue experience), reports to the CISO or the head of security operations, and owns the cadence of purple-team exercises across the organization. JPMorgan Chase, Microsoft, Google, Meta, the major federal-government security organizations, and the larger defense contractors are the canonical employers; the role-title varies (“Adversary Emulation Lead,” “Detection Engineering Program Manager,” “Purple Team Lead”) but the function is the same.
- The MSSP purple-team practice lead. A managed security service provider whose service offering includes purple-team engagements for client organizations will have a senior individual who owns the practice. The role is structurally similar to the in-house version but with the consultancy-side rotation across multiple clients per quarter. SCYTHE, Mandiant, CrowdStrike Services, IBM X-Force Red, NCC Group, Bishop Fox, and the broader specialist-firm market all have practice leads on the purple-team side; the role is rarer than the corresponding red-team-practice-lead role because the purple-team practice market is smaller than the red-team-engagement market.
- The senior detection engineer with adversary-emulation depth. The detection-engineering specialization track that Vol 10 §6.4 walked has a natural progression into purple-team work as the engineer’s TTP fluency deepens. A senior detection engineer who can also execute the adversary-emulation half of the loop is, structurally, a purple-team practitioner — the engineer’s individual capability spans both halves of the loop without requiring two separate teams. This is the smallest of the three sub-populations and the most-skilled; the engineer’s career trajectory is often “detection engineer → senior detection engineer → purple-team practitioner → detection engineering program lead” or similar.
The three patterns share a common feature: the practitioner reaches the purple-team role after substantive experience in one or both of the contributing functions. Purple-team work is not an entry-level career stage; §6.2 will walk the typical pathways. The career-stage character of the role is itself part of why purple-team work is more of an integration practice than a free-standing role — the field’s senior practitioners are doing the work, but they’re not all called “purple-team operator” in their job titles.
1.2 The boundary tested by hard cases
Three hard cases that test the purple-team boundary, with the working answer for each:
- The “test environment versus production” line. A purple-team exercise validates detection coverage by executing TTPs and observing whether detections fire. The TTPs should ideally run against production infrastructure to validate the production detection pipeline, but the operational risk of running attacker techniques against production is real. The mature posture is “production with carefully chosen techniques,” with the discipline being to select TTPs whose collateral risk is low (a Mimikatz invocation against a controlled-test endpoint in production); reserve the high-risk TTPs (destructive techniques, denial-of-service-adjacent techniques) for staged-environment exercises; and instrument enough rollback capability that an unexpected outcome can be reversed quickly. The white-hat-pentest tip-over discipline (Vol 6 §4.6) and the red-team tip-over discipline (Vol 11 §1.3) both apply; the purple-team variant adds the consideration that the engagement coordinator’s role includes the production-vs-test scoping conversation.
- The “detection-rule attribution” question. A purple-team exercise produces a working Sigma rule that catches the tested TTP. The rule gets deployed to the SIEM. Who owns the rule going forward — the red-team operator who triggered the gap discovery, the blue-team detection engineer who wrote the rule, the joint authorship of the purple-team exercise, or the SIEM administrator who manages the rule lifecycle? The mature posture is joint ownership during the exercise; detection-engineering ownership in production; the rule gets handed off to the detection engineering function for long-term maintenance, validation, and tuning, with the original purple-team exercise documented as the rule’s provenance. The detection-engineering team owns the rule’s lifecycle (the rule will need tuning as the environment evolves, as the TTP variant changes, as the SIEM’s data model changes); the purple-team exercise owns the rule’s initial authorship and validation.
- The “blue-team-knew-it-was-coming” critique. A purple-team exercise where the blue team knows what TTP is about to be executed is, in some sense, “not a real test” of the detection — the analyst is watching for the specific signal they know is coming. The critique is fair in the abstract but misreads what the purple-team exercise is for. The purple-team exercise is not a test of the blue team’s vigilance; it is a test of the blue team’s detection coverage. The question being asked is “if this TTP runs in our environment, does our detection-and-alerting pipeline produce the right alert?” — not “will the analyst notice the alert in their queue?” The former is a tooling-and-rule-coverage question; the latter is a vigilance-and-process question. The two are different; the purple-team exercise validates the first, not the second. Adversary-emulation engagements (Vol 11) validate the second, where the blue team is deliberately unaware. The purple-team practice and the adversary-emulation engagement are complementary, not substitutes; the mature 2026 enterprise security program runs both, on different cadences.
These cases reappear throughout the volume — the production-vs-test discipline in §4’s exercise design, the rule-ownership question in §4.4’s detection-engineering integration, the vigilance-vs-coverage distinction in §4.6’s mode comparison.
2. Origin and how the term is actually used
“Purple team” as engagement-vocabulary emerged later than red-team or blue-team; it’s the youngest of the three engagement-role colors and the most recently institutionalized in the cybersecurity field. The emergence has two parallel threads — a vocabulary thread (the word “purple” stabilizing as the integration-practice label across the 2013-2018 window) and an institutional thread (SANS curriculum and the broader practitioner-conference content cementing the practice as a named discipline starting ~2016).
2.1 The 2013-2015 emergence — the integration practice gets a color
The historical separation of red-team and blue-team functions was the foundational condition for purple-team’s emergence. In the 2000s commercial cybersecurity adoption pattern, red-team consultants would run engagements against client environments, deliver narrative reports weeks later, and move on; blue-team SOC analysts would receive the reports as feedback on detection coverage and would (eventually, sometimes, partially) act on the findings. The structural problem with the sequential pattern was that the institutional memory of the engagement faded between the report delivery and the detection-engineering work; the red-team operator who knew what TTP triggered which detection-gap finding was no longer engaged when the detection engineering work started, and the detection engineer who could write the corresponding rule didn’t have direct access to the operator’s contextual knowledge.
The “purple team” framing — integrating the red-and-blue work into a single concurrent feedback loop instead of running them sequentially — emerged from the practitioner community across the 2013-2015 window as a response to this structural inefficiency. The exact first-citation is hard to primary-source (the same difficulty Vol 5 §3 noted for the broader hat-vocabulary migration into computing), but the FireEye / Mandiant consulting practice carried the term in client engagements through this period, and the CrowdStrike Services arm carried similar framing. By approximately 2015, “purple team” was a recognized industry term for the integration practice; by 2018 it was conventional enough that DEF CON’s Blue Team Village programming consistently included purple-team content alongside the defender-side material.
The vocabulary’s resonance is intuitive — purple is the mix of red and blue in the color wheel, and the integration practice mixes red-team and blue-team work. The framing is rhetorically clean enough that it survived the inevitable critiques (Daniel Miessler’s “Purple Team Pentests Mean You’re Failing at Red and Blue” essay, published 2019, argued that the existence of a purple-team category meant the red and blue functions were not integrating effectively on their own — a defensible position that has not, however, displaced the working vocabulary)1. As of 2026 the term is mature and uncontested in industry usage; the active discussion is at the practice-execution level (how often to run purple-team exercises, which TTPs to prioritize, how to measure the practice’s value) rather than at the term-meaning level.
2.2 The SANS curriculum cementing — SEC599 and SEC699
The institutional event that crystallized purple-team practice as a named discipline was the 2016 launch of SANS SEC599: Defeating Advanced Adversaries — Purple Team Tactics and Kill Chain Defenses, authored by Erik Van Buggenhout (NVISO) and Stephen Sims2 (matches Vol 5 §5.4’s institutional-cementing framing). The course is the canonical curriculum for purple-team work: a six-day intensive walking the kill-chain phases (initial access through actions-on-objectives) with each phase covered from both the red-team-execution side and the blue-team-detection side, with the two halves explicitly interleaved as the pedagogical structure rather than treated sequentially. The course’s premise — that the kill-chain phases are the structural backbone of both offensive and defensive work, and the integration practice is the discipline of working both sides of each phase together — is the methodological framing that the rest of the field has substantially adopted.
The followup course SANS SEC699: Advanced Purple Teaming — Adversary Emulation and Detection Engineering (Van Buggenhout, premiered 2020) extended the curriculum into the engineering-depth territory: building custom adversary-emulation infrastructure, authoring custom detection rules, integrating BAS (Breach and Attack Simulation) platforms into ongoing detection-validation work, and the operational rhythm of running a continuous purple-team program rather than discrete one-off exercises3. The 2025-2026 SEC699 update added AI-enabled detection content, expanded purple-team lab work, and refreshed the Terraform-managed range infrastructure — reflecting the field’s continued evolution.
The SANS curriculum is not the only educational institution serving the purple-team space (Black Hat training tracks include purple-team content; Hack The Box’s “Cybernetics” labs incorporate purple-team challenge structure; X33fcon has dedicated purple-team programming), but the SANS pair (SEC599 + SEC699) is the canonical credential ladder. The MITRE ATT&CK Defender (MAD) program (now operated by MAD20 Technologies after MITRE Engenuity spun the curriculum out in 2023) provides a complementary framework-fluency credential4.
2.3 The Threat-Informed Defense framework and the formalization
Vol 11 §2.4 walked the MITRE Threat-Informed Defense framework that the Center for Threat-Informed Defense (CTID) articulated starting 2019. The framework’s premise — that defensive work should be informed by what threat actors actually do, with the engagement substrate being MITRE ATT&CK — is the methodological underpinning of modern red-team-engagement design. The same framework applies to purple-team work, with an explicit collaboration dimension: a Threat-Informed Defense practice runs the red-team-TTP-execution half against the same MITRE ATT&CK technique catalog that the blue-team-detection-engineering half is structured around, with the ATT&CK Navigator layer as the shared artifact both teams reference.
The 2020-2026 maturation of the Threat-Informed Defense framework’s purple-team integration has produced a working pattern that is increasingly the default in larger enterprise security programs: a per-quarter purple-team exercise cadence, with the exercise’s TTP selection driven by the threat-intel function’s current focal threat actors, with the detection-engineering function responsible for closing the gaps identified, with the next quarter’s exercise re-validating the previous quarter’s gap closures. The practice has its own metrics (the “detection coverage” metric, treated at §4.5), its own tooling (the BAS platforms, treated at §3), and its own credentialing path (the SANS pair and the MAD program); all of these have stabilized in the 2020-2026 window.
| Term | Meaning | Origin | Typical 2026 usage |
|---|---|---|---|
| Purple team (lowercase, two words) | The collaborative red-and-blue integration practice | Industry coinage, 2013-2015 emergence | Job postings, conference village content, exercise vocabulary |
| Purple-team exercise | A specific instance of the integration practice — a structured red-and-blue collaborative session | Industry coinage | Standard exercise-vocabulary; the modal unit of purple-team work |
| Purple-team program | The continuous practice across multiple exercises, with detection-engineering integration and metrics tracking | Industry coinage, ~2018 onward | Mature-enterprise vocabulary; the program-management framing |
| Purple Team Lead / Purple Hat | The (rarer) job-title role for the practitioner who orchestrates the practice | Industry coinage, ~2018 onward | Senior-role vocabulary; not the modal practitioner identity |
| Adversary emulation | The methodologically-precise term for the red-team-execution half of the practice | MITRE / DoD vocabulary | The Threat-Informed Defense vocabulary; substantially shared with Vol 11’s red-team usage |
| Detection engineering | The blue-team detection-rule-authoring half of the practice | Industry coinage, ~2015-2018 onward | Standard role-and-function vocabulary; substantially shared with Vol 10’s blue-team usage |
| Breach and Attack Simulation (BAS) | Automated TTP-execution-against-environment platforms that drive continuous purple-team validation | Vendor coinage, ~2017 onward | Standard product-category vocabulary; AttackIQ / SafeBreach / Cymulate / Pentera as canonical vendors |
| Continuous purple-team | The BAS-platform-driven engagement mode where TTP execution and detection validation run continuously | Industry coinage, ~2020 onward | The aspirational mature-program vocabulary |
| Threat-Informed Defense | The MITRE-articulated framework for ATT&CK-driven offensive and defensive integration | MITRE / CTID, 2019 onward | The methodological framing of purple-team work in mature programs |
Table 12.1 — Purple-team-related vocabulary in 2026 industry usage. The “Purple team” and “Purple-team exercise” rows are the load-bearing primary meanings. The “Adversary emulation” and “Detection engineering” rows are the role-function vocabulary that the practice integrates. The “BAS” row is the product-category vocabulary for the automated-engagement mode. The “Continuous purple-team” and “Threat-Informed Defense” rows are the aspirational/methodological vocabulary that distinguishes a mature program from a one-off exercise.
3. Tools of the trade
The purple-team toolset is structured around three working layers: the adversary-emulation execution tooling (the platforms that drive the red-team-execution half of the loop), the exercise tracking and reporting tooling (the platforms that capture what was tested and what was caught), and the detection-engineering integration tooling (the platforms that convert findings into deployed detection rules). The section walks each layer with representative tools. The purple-team’s broader tooling overlap with the red-team’s working set (Vol 11 §3) and the blue-team’s working set (Vol 10 §3) is substantial — purple-team work uses essentially all the same C2 frameworks, AD attack tools, SIEM platforms, and EDR products that the constituent functions use; this section focuses on the purple-team-specific additions, the tools that the practice introduces beyond what red-and-blue already carry separately.
A core principle restated from Vol 6 §3, Vol 7 §3, Vol 10 §3, and Vol 11 §3: the dual-use principle applies to purple-team work the same way it applies to red and blue work. The Atomic Red Team test that validates a detection rule under a purple-team exercise is the same test catalog that an unsanctioned actor could use as a tradecraft reference; the CALDERA platform that drives a sanctioned purple-team exercise is the same platform-class that could drive unsanctioned adversary emulation. The discriminator is authorization, not gear. Nothing in this section is purple-team-exclusive; the same tools appear in red-team and blue-team work, sometimes in the same workflows. The hat is on the engagement, not on the device.
3.1 The atomic-test execution layer — Atomic Red Team
The center of the modern purple-team execution toolchain is Atomic Red Team — Red Canary’s open-source library of small, focused, MITRE-ATT&CK-mapped detection tests, released October 2017 by Casey Smith and Michael Haag at the Carbon Black User Exchange5. The library’s structural unit is the atomic test: a single self-contained TTP execution, mapped to a specific ATT&CK technique ID, runnable from a command line without C2 infrastructure or framework dependencies, with the explicit purpose of generating the telemetry signal that a corresponding detection rule should fire on. As of early 2026 the library carries approximately 1,500 atomic tests across the ATT&CK technique catalog, with active community contribution and continuous Red-Canary-maintained release cycles.
The library’s design philosophy is the key to its purple-team value. Atomic tests are not adversary simulations; they are detection-validation tests. A typical atomic test executes a single specific TTP variant (a single Mimikatz invocation, a single PowerShell encoded-command execution, a single LSASS-memory read) without the broader campaign context an actual adversary would carry. The narrow focus is the point: the test exercises one rule’s input condition at a time, in a way the corresponding detection rule’s logic can be measured against. This makes Atomic Red Team the canonical tool for the purple-team feedback loop’s measurement step — the red-team execution that produces the specific telemetry the blue-team detection rule is designed to catch.
A representative atomic-test invocation (the canonical “OS Credential Dumping: LSASS Memory” technique, T1003.001 — the same technique Vol 10 §3.1 walked from the detection side and Vol 11 §3.8 walked from the engagement-vocabulary side):
# Atomic Red Team invocation via the Invoke-AtomicTest PowerShell module
# Reference: https://github.com/redcanaryco/atomic-red-team
#
# Test T1003.001-1 (Dump LSASS.exe Memory using ProcDump):
# - Downloads ProcDump if not present (configurable)
# - Executes: procdump.exe -accepteula -ma lsass.exe lsass_dump.dmp
# - Generates the canonical LSASS-process-access telemetry signal that
# a corresponding Sigma rule should fire on (Vol 10 §3.1's example)
# - Exits cleanly; cleanup step removes the dump file
#
# The test is intentionally narrow — one specific dumping technique, not
# a broader credential-access campaign. The purple-team exercise that runs
# this test is measuring whether the deployed Sigma rule for LSASS-process
# read access fires correctly; it is NOT measuring whether the SOC analyst
# notices the resulting alert (that is the adversary-emulation engagement's
# question, Vol 11).
Invoke-AtomicTest "T1003.001" -TestNumbers 1 -GetPreReqs
Invoke-AtomicTest "T1003.001" -TestNumbers 1
Invoke-AtomicTest "T1003.001" -TestNumbers 1 -CleanupThe Invoke-AtomicTest PowerShell module is the canonical execution wrapper; the equivalent functionality in Python (the chain-bench ecosystem; some community runners) and via direct shell-script invocation is available. The Red Canary team maintains the canonical execution wrapper and the test-catalog YAML structure that the wrappers consume.
The atomic-test catalog’s structural fit with the purple-team practice is the property that makes Atomic Red Team the canonical tool: the catalog is organized around the ATT&CK technique catalog, which is the same vocabulary the detection-engineering function uses, which is the same vocabulary the threat-intel function uses to describe adversary behavior. The shared vocabulary means a purple-team exercise can be designed in ATT&CK-technique terms (“we will validate detection coverage for the techniques our threat intelligence says APT29 uses”), and the execution can pull directly from the Atomic Red Team catalog without translation overhead.
3.2 The automated adversary-emulation platform layer — CALDERA and friends
Where Atomic Red Team’s atomic tests are designed for individual narrow execution, the automated adversary-emulation platform category extends the same principle to multi-step adversary campaigns. The canonical open-source platform is CALDERA (MITRE; first public release 2017), which executes ATT&CK-mapped TTPs against client agents deployed in the test environment, with the platform orchestrating a multi-step campaign rather than a single atomic test6. CALDERA’s adversary profiles are JSON-described campaigns specifying the sequence of TTPs to execute; the platform’s operations are running instances of a profile against the agent-instrumented environment; the platform’s plugins extend the capability catalog (compass, training, fieldmanual, plus others). The framework is actively developed under MITRE’s stewardship; the CISA-MITRE collaboration on CALDERA for OT extended the platform to operational-technology environments.
Adjacent platforms in the automated-adversary-emulation category:
- Prelude Operator (Prelude Research, founded by David Hunt who was CALDERA’s original technical lead) — open-source adversary-emulation tooling derived from CALDERA-influenced design, with multi-platform agent support. As of 2024-2025, Prelude’s commercial positioning has shifted toward continuous security-control validation and compliance monitoring rather than operator-driven adversary emulation; the open-source Operator persists, but the commercial product is no longer marketed as the “professional-grade CALDERA” alternative.
- AttackIQ — commercial BAS platform (founded 2013); the canonical “enterprise BAS” vendor in the category. AttackIQ’s Security Optimization Platform runs continuous TTP-execution against the customer’s environment, validates detection coverage, and integrates with the customer’s SIEM and EDR to measure outcomes. The platform’s strength is the breadth of TTP coverage and the integration depth with major enterprise SIEM and EDR products.
- SafeBreach — commercial BAS platform (founded 2014); a second canonical enterprise BAS vendor. SafeBreach’s Hacker’s Playbook is the platform’s TTP catalog; the platform’s Continuous Security Validation is the engagement model. The platform competes directly with AttackIQ for the enterprise BAS market.
- Cymulate — commercial BAS platform (founded 2016); the third major BAS vendor. Cymulate’s Exposure Validation Platform covers the BAS use case plus broader exposure-management functionality (vulnerability validation, attack-surface management). The platform’s positioning has shifted toward the broader exposure-management category as that category has matured.
- Pentera — commercial automated penetration-testing platform (founded 2015, originally “Pcysys”); the platform’s positioning is “automated red-team” rather than “BAS” — the engagement model is the platform actively penetrating the customer’s environment using real exploits, not just executing TTPs against agents. Pentera occupies a distinct niche between traditional BAS and full red-team engagement.
The BAS market is competitive; no single vendor dominates the way Cobalt Strike dominates the commercial C2 market (Vol 11 §3.1). The platform-selection conversation for an enterprise considering purple-team tooling typically involves a multi-vendor evaluation across the four-to-six leading platforms (CALDERA + the four commercial vendors above, plus regional alternatives) and considers the platform’s specific integration with the organization’s existing SIEM, EDR, and threat-intel stack.
3.3 The exercise tracking and reporting platform layer — VECTR
The execution-side tooling (Atomic Red Team, CALDERA, the BAS platforms) handles the red-team-execution half of the purple-team exercise. The exercise tracking and reporting platform layer handles the documentation half — capturing what TTPs were executed, what detections fired (and what didn’t), what the resulting findings were, and how the findings get tracked through to detection-engineering closure. The canonical open-source tool in this category is VECTR (Security Risk Advisors, originally released 2018; SRA continues active development with the free Community Edition + commercial Enterprise Edition released August 2024)7.
VECTR’s data model is structured around the purple-team exercise as the primary unit. An exercise has a defined scope, a defined test plan (the TTPs to be executed), a defined cadence, and an exercise-execution record where each tested TTP is logged with the execution outcome (executed successfully or not; detection fired or not; alert generated or not; alert reached the SOC analyst or not). The platform’s reporting view produces the per-exercise summary, the multi-exercise trend view (detection coverage over time), the MITRE ATT&CK Navigator overlay showing which techniques have been validated, and the threat-resilience benchmark view (comparing the organization’s coverage against industry benchmarks). The Enterprise Edition (2024+) adds the benchmark data and the Azure Marketplace deployment integration.
The structural value of a VECTR-style exercise-tracking platform is the longitudinal view of detection coverage over time. A single purple-team exercise’s findings are useful; the multi-exercise trend that shows whether detection coverage is improving (and at what rate) is what makes the practice a measurable engineering program rather than an isolated event. The metric — “fraction of ATT&CK techniques our environment has validated detection coverage for” — is the load-bearing indicator that VECTR (and its commercial competitors) is designed to track and report on.
Adjacent platforms in the exercise-tracking category:
- Atomic Red Team’s GitHub-based exercise repository pattern — for organizations not deploying VECTR or a similar platform, the exercise documentation pattern often defaults to a Git-based markdown structure with one directory per exercise. This works but loses the structured-data analysis VECTR provides.
- Splunk BOTS (Boss of the SOC) format — Splunk’s annual “Boss of the SOC” competition format has been published as a recurring training exercise dataset that organizations use as a purple-team training rhythm. The format is open-source datasets representing simulated breaches; the exercise is investigative (the SOC team works through the dataset to identify the adversary’s TTPs). BOTS is more of a training exercise than a detection-validation exercise but is widely used in the purple-team practitioner community.
- MITRE ATT&CK Navigator itself — the JSON-layer-based visualization that both red and blue teams use to communicate engagement scope and outcome. The Navigator is not exercise-tracking per se but is the canonical shared artifact across exercises, and most exercise-tracking platforms (VECTR included) export Navigator layers as the canonical output format.
3.4 The detection-engineering integration layer — Sigma and the detection-as-code stack
The detection-engineering side of the purple-team loop produces the artifact that closes the loop: the detection rule that catches the tested TTP. The canonical artifact format is Sigma — the platform-agnostic detection-rule language that Vol 10 §3.5 walked at depth. A Sigma rule is a YAML-formatted detection specification that compiles to a query in any of the major SIEM platforms (Splunk, Elastic, Sentinel, QRadar, Sumo Logic, others). The rule format’s value in purple-team work is that the rule is the deliverable — a successful purple-team exercise produces working Sigma rules that get deployed to the SIEM and tested in the next exercise’s re-validation step.
A representative Sigma rule produced from a purple-team exercise (continuing the T1003.001 LSASS-memory-dump example from §3.1):
# Sigma rule: detects LSASS-process memory-read access by non-trusted processes
# Author: <Detection engineering team> via purple-team exercise <ID>
# Date: 2026-02-XX (during purple-team exercise)
# Validated: 2026-02-XX (re-run via Atomic Red Team T1003.001-1)
# References:
# - MITRE ATT&CK T1003.001 (OS Credential Dumping: LSASS Memory)
# - Sigma project: https://github.com/SigmaHQ/sigma
#
# Purple-team-loop provenance: this rule was authored during purple-team
# exercise PT-2026-Q1-04 after Atomic Red Team T1003.001-1 (ProcDump
# variant) executed without detection. The Sigma rule logic was authored
# during the exercise; deployment to Sentinel completed within the same
# session; re-validation via the same Atomic Red Team test confirmed
# the rule fires correctly. Next-quarter exercise PT-2026-Q2-01 will
# re-validate as part of the standard regression sweep.
title: LSASS Process Access by Suspicious Process Name
id: f5e3a2b1-4c6d-4e7f-8a9b-1c2d3e4f5a6b
status: stable
description: Detects suspicious processes accessing LSASS memory, a canonical credential-dumping indicator
references:
- https://attack.mitre.org/techniques/T1003/001/
- https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1003.001/T1003.001.md
author: <PurpleTeam>
date: 2026/02/15
tags:
- attack.credential_access
- attack.t1003.001
- purple_team.pt_2026_q1_04
logsource:
product: windows
category: process_access
detection:
selection:
TargetImage|endswith: '\lsass.exe'
GrantedAccess|contains:
- '0x1010' # PROCESS_VM_READ | PROCESS_QUERY_INFORMATION
- '0x1410' # extended variant
- '0x1438' # extended variant
filter_legitimate:
SourceImage|endswith:
- '\MsMpEng.exe' # Windows Defender
- '\MsSense.exe' # Microsoft Defender for Endpoint
- '\CSFalconService.exe' # CrowdStrike Falcon
# Add additional EDR / security-tool exclusions as discovered
condition: selection and not filter_legitimate
fields:
- SourceImage
- TargetImage
- GrantedAccess
- ProcessId
falsepositives:
- Legitimate EDR / AV products (add to filter_legitimate)
- Authorized red-team / purple-team engagement work (deconfliction via VECTR exercise ID)
level: highThe rule’s purple-team-loop provenance is captured in the rule’s comments and tags — the exercise ID under which the rule was authored, the next-exercise validation plan, the relationship to the Atomic Red Team test that originally triggered the gap discovery. The detection-as-code discipline (Vol 10 §3.5) extends naturally to the purple-team exercise’s deliverables: the rule lives in version control, the CI/CD pipeline validates and deploys the rule to the SIEM, the next purple-team exercise’s regression sweep re-validates the rule against the original triggering TTP.
The Sigma rule format is the industry-standard artifact, but the detection-engineering integration layer extends to the broader detection-as-code tooling: Panther (commercial detection-as-code platform with a Python-based rule format), Tines (commercial security workflow automation platform with detection-engineering hooks), Datadog Cloud SIEM (commercial SIEM with its own detection-rule format), the Splunk Security Content Repository (Splunk’s open-source detection content), and the broader CI/CD-integrated detection-rule lifecycle. The purple-team exercise’s output integrates into whichever detection-engineering stack the organization runs; Sigma’s value is the platform-agnostic intermediate format that lets the exercise output remain portable across SIEM technology changes.
3.5 The C2 framework in purple mode — transparency vs evasion
The C2 framework discussion from Vol 11 §3.1 applies directly to purple-team work, with one structural difference: purple-team mode is white-box-by-construction. The blue team knows the exercise is running, knows what TTPs are being executed, and knows the engagement is collaborative rather than adversarial. The C2 framework’s evasion-focused features — the Malleable C2 profiles that make Cobalt Strike Beacon traffic look like benign web traffic, the Mythic per-agent customization that makes detection-rule matching harder, the Brute Ratel evasion focus — are not the primary value in purple-team mode. The primary value is the framework’s operator-driven TTP execution — the ability to drive specific multi-step engagement work that exercises the kill-chain phases the exercise is testing.
The practical implication is that purple-team exercises often use the same C2 frameworks as Vol 11’s red-team engagements (Cobalt Strike, Sliver, Mythic, Havoc), but with different configuration: the evasion features turned off or minimized, the operator transparency turned up, the exercise execution explicitly logged for the blue-team observation. Some purple-team practitioners argue for a simpler C2 framework for purple-team work specifically — the framework’s role is execution-and-observation, not stealth, so a less-sophisticated framework with better operator visibility may serve the exercise better. The 2026 modal practice is to use the same C2 framework as the red-team work (re-purposed in transparent mode) rather than maintaining a separate purple-team-specific framework; the operational simplicity of one framework with two configurations wins over the conceptual cleanliness of two frameworks.
The BAS platforms (§3.2) substitute for the C2 framework in fully-automated purple-team work — AttackIQ, SafeBreach, Cymulate, and Pentera all carry their own agent-and-execution infrastructure that replaces the operator-driven C2 framework’s role with an automation-driven equivalent. The trade-off is the BAS platform’s ease-of-use against the C2 framework’s flexibility; both modes exist in mature 2026 enterprise purple-team programs, sometimes simultaneously (BAS for continuous regression, operator-driven C2 for the deeper quarterly exercises).
3.6 The substantive tools table
| Category | Tool | License model | Approx 2026 cost | Role in purple-team practice | Cross-reference |
|---|---|---|---|---|---|
| Atomic TTP execution | Atomic Red Team | Open-source MIT | Free | The canonical narrow-TTP detection-validation test library | This §3.1; 5 |
| Atomic TTP execution | Invoke-AtomicTest (PowerShell wrapper) | Open-source MIT | Free | The execution wrapper for the Atomic Red Team catalog | This §3.1 |
| Automated adversary emulation | CALDERA | Open-source Apache-2 | Free | The canonical open-source automated multi-step emulation platform | This §3.2; 6 |
| Automated adversary emulation | Prelude Operator | Open-source + commercial | Free (OSS) / Subscription (commercial) | Open-source operator + commercial control-validation platform (positioning shifted 2024-2025) | This §3.2 |
| Breach and Attack Simulation | AttackIQ | Commercial | Enterprise pricing (six-figures common) | The canonical enterprise BAS platform | This §3.2 |
| Breach and Attack Simulation | SafeBreach | Commercial | Enterprise pricing | Second canonical enterprise BAS platform | This §3.2 |
| Breach and Attack Simulation | Cymulate | Commercial | Enterprise pricing | Third canonical enterprise BAS platform; expanding to exposure-management | This §3.2 |
| Automated penetration testing | Pentera | Commercial | Enterprise pricing | Automated-red-team alternative to BAS | This §3.2 |
| Exercise tracking | VECTR Community Edition | Open-source Apache-2 | Free | The canonical purple-team exercise-tracking platform | This §3.3; 7 |
| Exercise tracking | VECTR Enterprise Edition | Commercial | Subscription (per-org) | Adds benchmark data + Azure Marketplace deployment | This §3.3 |
| Training exercise format | Splunk BOTS (Boss of the SOC) | Open-source datasets | Free | The canonical recurring training-exercise format | This §3.3 |
| Shared artifact | MITRE ATT&CK Navigator | Open-source Apache-2 | Free | The shared red+blue technique-coverage visualization | This §3.3; Vol 11 §4.3 |
| Detection-rule format | Sigma | Open-source (DRL — Detection Rule License) | Free | The canonical platform-agnostic detection-rule format | This §3.4; Vol 10 §3.5 |
| Detection-as-code platform | Panther | Commercial | Subscription | Python-based detection-as-code SIEM | This §3.4 |
| Detection-as-code platform | Splunk Security Content | Open-source | Free | Splunk’s open-source detection content repository | This §3.4 |
| C2 framework (transparent mode) | Cobalt Strike / Sliver / Mythic / Havoc | Per Vol 11 §3.1 | Per Vol 11 §3.1 | Red-team-execution-side of the purple-team loop, with evasion features turned down | This §3.5; Vol 11 §3.1 |
| Credentialing | MITRE ATT&CK Defender (MAD) | Commercial ($499/yr) | Annual subscription | Practitioner-credential program for ATT&CK fluency | This §6.1; 4 |
Table 12.2 — The purple-team toolchain working set, organized by category. The atomic-test execution layer (Atomic Red Team + Invoke-AtomicTest) is the canonical narrow-TTP execution layer; the automated adversary emulation layer (CALDERA + the BAS platforms) extends to multi-step engagement; the exercise-tracking layer (VECTR + the GitHub-based pattern + BOTS) handles documentation; the detection-engineering integration layer (Sigma + Panther + the SIEM-content repositories) handles the output side. The C2 framework discussion is shared with Vol 11; the credentialing entry is forward-referenced to §6.1. None of these tools is purple-team-exclusive — the discriminator is engagement context, not gear.
3.7 The Aggressor Script / atomic-test integration pattern
The mature purple-team practice integrates the atomic-test execution layer with the C2 framework execution layer — the operator drives a C2 framework’s implant through a series of atomic-test invocations rather than running atomic tests as standalone PowerShell. The integration is straightforward and worth illustrating because it shows how the C2 framework’s operator-driven engagement model coexists with the atomic-test detection-validation model.
A representative Aggressor Script pattern (continuing Vol 11 §3.8’s example):
# Aggressor Script — purple-team mode integration of Atomic Red Team
# This snippet adds a command that executes a named Atomic Red Team test
# via the Beacon's PowerShell execution context, logs the execution to
# the engagement's VECTR-compatible audit log, and tags the Beacon's
# notes with the exercise context.
#
# The integration assumes Invoke-AtomicTest is loaded into the Beacon's
# PowerShell environment (via a prior `powershell-import` of the Atomic
# Red Team PowerShell module).
alias atomic {
local('$bid $technique $testnum $note');
$bid = $1;
$technique = $2;
$testnum = $3;
blog($bid, "Executing Atomic Red Team test " . $technique . "-" . $testnum);
# Execute the test via Beacon's PowerShell context
bpowershell($bid, "Invoke-AtomicTest \"" . $technique . "\" -TestNumbers " . $testnum);
# Log the test execution to the engagement audit trail
$note = "PT exercise: " . $technique . "-" . $testnum . " executed " . formatDate("yyyy-MM-dd HH:mm:ss");
bnote($bid, $note);
}
# Usage from operator console:
# atomic 12345 T1003.001 1 # execute T1003.001 test 1
# atomic 12345 T1059.001 4 # execute T1059.001 test 4The pattern’s value is that the exercise’s execution context is captured in the C2 framework’s per-Beacon audit log and in the atomic-test catalog’s vocabulary and in the engagement-tracking platform’s record. The three layers — operator-driven engagement, atomic-test detection validation, exercise-tracking documentation — integrate into a single workflow the operator drives through the C2 framework’s interface.
4. Methods and tradecraft — the purple-team exercise loop
The purple-team exercise has a defined structural form. The lifecycle is shorter than the red-team-engagement lifecycle (Vol 11 §4) — a single exercise typically runs hours to days rather than weeks to months — and the engagement-coordination overhead is structurally different because both teams are operating in the same room (literally or virtually) on the same schedule. The lifecycle is, however, no less rigorous; the discipline of running an exercise as a purple-team exercise rather than as an ad-hoc red-and-blue conversation requires the shape walked below.
4.1 The exercise lifecycle in one diagram
PRE-EXERCISE EXERCISE (4-8 hours typical) POST-EXERCISE
┌───────────────────────────────────────────────────────────────────┐ ┌───────────────────────────────────────────────────────────────────────────────────────────────────────┐ ┌──────────────────────────────────────────────────────┐
│ │ │ │ │ │
│ THREAT-ACTOR ─► TTP SELECTION ─► SCOPE ─► RED & BLUE ROSTER │ │ EXECUTE ─► OBSERVE ─► IDENTIFY ─► AUTHOR ─► DEPLOY ─► RE-VALIDATE ─► NEXT TTP │ │ REPORT ─► RULE HANDOFF ─► METRICS UPDATE │
│ PROFILE (Navigator DEFINITION │ │ TTP TELEMETRY DETECTION DETECTION │ │ ↓ │
│ layer) │ │ GAP RULE │ │ Exercise report │
│ ▼ ▼ ▼ ▼ │ │ ▼ │ │ + Navigator layer │
│ Threat-intel Pick techniques Test/prod Red roster: │ │ Atomic Red Team │ │ + per-TTP outcome │
│ informed from ATT&CK env; operators │ │ or CALDERA or │ │ + Sigma rules authored │
│ (APT29 / catalog; VECTR drive TTP │ │ BAS platform │ │ │
│ Conti / exercise ID exercise execution │ │ ▼ │ │ Rules handed to detection-eng team │
│ FIN7 / etc.) assigned tracking Blue roster: │ │ SIEM / EDR │ │ for long-term lifecycle ownership │
│ detection │ │ shows what │ │ │
│ Authorization engineers │ │ fires, what │ │ Detection coverage metric updated │
│ envelope: + analysts │ │ doesn't │ │ in VECTR; next exercise's regression │
│ internal joint + threat-intel│ │ ▼ │ │ sweep plan updated │
│ exercise = no │ │ Per-TTP gap → Sigma rule authored → deployed → re-run TTP → │ │ │
│ external paper │ │ detection fires → move to next TTP │ │ Next exercise scheduled (quarterly cadence) │
│ │ │ │ │ │
└───────────────────────────────────────────────────────────────────┘ └───────────────────────────────────────────────────────────────────────────────────────────────────────┘ └──────────────────────────────────────────────────────┘Figure 12.1 — The purple-team exercise lifecycle. Pre-exercise (threat-actor profile selection → TTP catalog selection from MITRE ATT&CK → scope and environment definition → red and blue rosters defined) establishes the exercise’s design. The exercise itself (the inner loop: execute a TTP via Atomic Red Team / CALDERA / BAS platform → observe what telemetry the SIEM and EDR collected → identify whether the corresponding detection fired → if not, author the missing Sigma rule → deploy the rule → re-run the TTP to validate the rule fires → move to the next TTP) is the structural heart of the practice. Post-exercise (exercise report → detection-rule handoff to the detection-engineering function for long-term lifecycle ownership → metrics update in VECTR → next exercise scheduled, typically quarterly) closes the loop. The lifecycle’s load-bearing structural feature is the inner re-validate step: the detection rule’s authoring is not the exercise’s deliverable; the validated rule that fires correctly on re-execution is the deliverable.
4.2 The four engagement modes — from one-shot to continuous
Purple-team work has four recognized engagement modes, each with different trade-offs. The four are presented as a spectrum from most-collaborative to most-automated; mature 2026 enterprise programs typically run multiple modes simultaneously on different cadences.
Mode 1 — Transparent (also called “fully announced”). Red team announces every action before executing it; blue team has full awareness of what is being tested at every step; the two teams are typically in the same room (literal or virtual) for the exercise. The exercise’s pacing is conversational — the blue-team detection engineer asks “what telemetry should we expect from this?”, the red-team operator describes the expected telemetry signal, the team observes whether the SIEM fires, and the conversation continues. The mode’s value is maximum knowledge transfer: the blue team learns the red-team-side context for each TTP, and the red team learns the blue-team-side detection considerations. The mode’s cost is throughput — a fully-announced exercise covers fewer TTPs per hour than the more-automated modes. Best fit: training-oriented exercises, new-hire onboarding for the detection-engineering team, and quarterly deep-dive exercises where the knowledge-transfer value is the primary objective.
Mode 2 — Coordinated (also called “batched announcement”). Red team executes a batch of TTPs in sequence; blue team observes the resulting telemetry; the two teams review the batch’s outcomes together before red proceeds to the next batch. The exercise’s pacing is faster than Mode 1 — the red team can execute 10-20 TTPs per hour, the per-batch review consolidates the outcome discussion. The mode’s value is balanced knowledge-transfer and throughput. The mode’s cost is the loss of fine-grained per-TTP coordination — if a batch contains a TTP that triggers an unexpected outcome, the team may have to revisit the specific TTP during the batch review. Best fit: regular purple-team exercises on a monthly cadence, where the practice is mature enough to handle batched review and the throughput is needed to cover the planned TTP catalog.
Mode 3 — Adversary-emulation (also called “deferred review”). Red team executes the planned TTP catalog as if running an actual adversary-emulation engagement (the engagement is not announced to the blue team in real time, though the exercise itself is sanctioned — the blue team’s senior leadership and the engagement coordinator know the exercise is running); blue team receives the execution log after the engagement completes; the two teams review the outcomes together in a structured post-exercise debrief. The mode’s value is realistic detection-pipeline test — the blue team is not watching for specific signals, and the SIEM-and-EDR pipeline is tested as it would respond to an actual adversary. The mode’s cost is the loss of real-time knowledge transfer — the post-exercise debrief recovers some but not all of it. Best fit: quarterly or semi-annual exercises where the realistic-test value is the primary objective; effectively a small-scale grey-box red-team engagement (Vol 11 §1.2’s grey-box transparency tier) with purple-team-style post-engagement integration.
Mode 4 — Continuous (BAS-platform-driven). Automated TTP execution runs continuously against the customer’s environment via a BAS platform (AttackIQ, SafeBreach, Cymulate, Pentera); the platform reports per-TTP outcome (fired or not) on a daily / weekly / per-test cadence; the detection-engineering function processes the platform’s findings as a continuous backlog rather than as discrete exercise events. The mode’s value is continuous validation at scale — the entire MITRE ATT&CK catalog can be exercised across a quarter rather than the much smaller catalog a manual exercise could cover. The mode’s cost is the loss of operator-driven creativity and the loss of the collaborative-learning value the other modes carry; the mode is also commercially expensive (the BAS platforms carry six-figure enterprise pricing). Best fit: mature enterprise programs with the budget and the engineering capacity to operate the BAS platform productively, typically running alongside one of the other modes for the deeper qualitative work.
| Mode | Cadence (typical) | Throughput (TTPs/hour) | Knowledge transfer | Detection-pipeline realism | Cost | 2026 modal adoption |
|---|---|---|---|---|---|---|
| Transparent | Quarterly deep-dives; new-hire training | 3-6 | Maximum | Lower (blue knows what’s coming) | Low ops, high time | Used in mature programs for deep-dive sessions |
| Coordinated | Monthly exercises | 10-20 | High | Moderate | Moderate | Modal pattern for organizations with mature purple-team practice |
| Adversary-emulation | Quarterly or semi-annually | 5-15 (per real-time engagement window) | Moderate (recovered in post-exercise debrief) | High | Higher ops (engagement-coordination overhead) | Common in larger enterprise programs |
| Continuous (BAS) | Daily / weekly automated | Hundreds per week (automated) | Lower (no real-time interaction) | Moderate (BAS scope is narrower than human-driven) | High commercial cost, lower ops | Adopted in larger enterprise programs with budget |
Table 12.3 — The four purple-team engagement modes, with trade-offs and 2026 modal adoption patterns. The modes are not mutually exclusive; mature enterprise programs typically run multiple modes on different cadences (continuous BAS for the broad regression sweep + monthly coordinated for the deeper exercises + quarterly transparent for the knowledge-transfer-oriented deep dives + semi-annual adversary-emulation for the realistic-pipeline-test). The selection of modes is part of the purple-team program’s design conversation, with the program’s overall budget, staff bandwidth, and detection-engineering function size as the input constraints.
4.3 Threat-informed TTP selection — the engagement’s pre-exercise design
The pre-exercise TTP selection is the conversation that distinguishes a deliberate purple-team exercise from an ad-hoc one. The conversation typically opens “Which TTPs are we testing today?” and proceeds through:
- Threat-intelligence input. The threat-intel function provides the current focal threat actors and their documented TTP catalogs. A quarterly cadence often aligns to threat-intel reporting cycles (Mandiant’s M-Trends annual report; CrowdStrike’s Global Threat Report annual; Microsoft’s Digital Defense Report annual; the per-quarter threat-actor briefings the threat-intel firms publish). The TTPs that show up in current threat-intel reporting against the organization’s vertical become the candidate set.
- Current detection-coverage assessment. The exercise tracking platform (VECTR or equivalent) provides the current detection-coverage map — which ATT&CK techniques have validated detection coverage, which have not been tested in the recent window, which are flagged as recently-failed-and-fixed and due for re-validation. The candidate TTP set narrows to the techniques where validation is most-needed.
- Environment fit. The TTPs must be executable in the test environment. A TTP that requires Linux infrastructure that isn’t present in the test environment is not executable; a TTP that requires destructive actions against production data is not executable without separate authorization; a TTP that exercises a network segment the exercise scope excludes is not executable. The candidate set narrows to the executable subset.
- Exercise time budget. The exercise’s planned duration (the modal 4-8 hour Mode-2 exercise budget) limits how many TTPs can be exercised. The candidate set narrows to the time-budget-fitting subset.
The resulting TTP catalog — typically 15-30 TTPs for a single-day exercise — is recorded in the exercise’s MITRE ATT&CK Navigator layer as the planned-execution scope. The Navigator layer is the exercise’s primary planning artifact and becomes the primary reporting artifact; the post-exercise Navigator layer shows the same techniques color-coded by outcome (green: detected; yellow: partially detected; red: not detected — the same three-color convention Vol 11 §4.3 walked).
4.4 The detection-engineering feedback loop — the practice’s structural heart
The inner loop of the exercise lifecycle (Figure 12.1’s center panel) is where purple-team work earns its keep. The loop’s six-step structural form:
- Execute the TTP. Red team triggers the planned TTP via Atomic Red Team, CALDERA, the BAS platform, or operator-driven C2 framework execution. The execution generates telemetry — process-creation events, network-flow records, file-system events, authentication events — that flow into the SIEM and EDR.
- Observe the telemetry. Blue team checks whether the corresponding detection rule fires on the generated telemetry. The check is direct: the detection engineer queries the SIEM for the expected alert; the alert either appears or doesn’t.
- Identify the detection gap (if any). If the detection fires, the TTP is recorded as detected (green in the Navigator); the loop proceeds to the next TTP. If the detection does not fire, the team has identified a detection gap — the loop continues into the rule-authoring step.
- Author the detection rule. The detection engineer writes a Sigma rule (or equivalent in the organization’s detection-as-code stack) that should catch the TTP’s telemetry signal. The rule-authoring conversation is collaborative — the red-team operator provides the technical context for what telemetry the TTP generates, and the detection engineer translates that into the rule’s logic. The rule’s first-draft is typically written during the exercise; the final-form may need post-exercise refinement.
- Deploy the rule. The rule gets deployed to the SIEM through the organization’s normal detection-deployment pipeline (the detection-as-code CI/CD if mature, manual SIEM-administration push if not). The deployment is fast (the exercise’s value depends on the rule being deployable during the exercise window).
- Re-validate. Red team re-runs the same TTP. Blue team confirms the newly-deployed rule fires on the re-execution. The loop confirms the rule works; the TTP is recorded as detected; the exercise proceeds to the next TTP.
The six-step loop is the practice’s structural heart. Without the loop’s closure — without the re-validation step that confirms the rule actually works — the exercise has produced a candidate rule, not a validated detection. The discipline of running the loop to closure on every TTP is what distinguishes a mature purple-team practice from an ad-hoc red-and-blue conversation; the discipline takes time, and the time cost is what limits the per-exercise TTP throughput.
The rule’s ownership transfers at the end of the exercise. The exercise authored the rule; the detection-engineering function owns the rule’s long-term lifecycle (tuning as the environment changes, validating against the TTP variant evolution, integrating into the regression-test catalog). The handoff is documented in the rule’s provenance (the exercise ID in the rule’s tags); the next-exercise’s regression sweep re-validates the rule as part of the standard pre-exercise check.
4.5 The “detection coverage” metric — what the practice measures
The purple-team practice’s load-bearing metric is detection coverage: the fraction of relevant MITRE ATT&CK techniques for which the organization has validated detection coverage. The metric is computed as:
- Numerator: number of ATT&CK techniques the organization has tested AND validated detection coverage for in the current measurement window (typically 12 months)
- Denominator: number of ATT&CK techniques the organization considers in-scope for its threat model (typically the union of the techniques used by the organization’s threat-intel-informed focal threat actors)
The metric is aspirational — the practical reality is that most organizations cover 20-30% of their relevant ATT&CK technique catalog as of 2026 industry surveys8. The number sounds low; the absolute scale of the ATT&CK catalog (196+ techniques and 440+ sub-techniques in the Enterprise matrix as of ATT&CK v15/v16; higher if counting all ATT&CK platforms — ICS, Mobile, etc. — across 14 tactics, with a substantial fraction of the catalog applicable to most enterprise threat models) makes the achievable target lower than the intuitive “we should detect everything” framing. A program that improves detection coverage from 20% to 35% over twelve months is doing well; a program that holds steady at 25% with continuous re-validation is also doing well (the validation maintenance is itself work, even when the coverage doesn’t expand).
The metric’s value is the longitudinal view. A single point measurement is less informative than the trend over multiple measurement windows: an organization whose detection coverage is growing at 5% per quarter is improving its security posture in a measurable way; an organization whose coverage has stagnated for four quarters is either at a structural ceiling (further coverage requires investments the organization isn’t making) or has a process problem (the exercises are running but the rules aren’t being deployed). The VECTR platform (and its commercial competitors) is designed around producing this longitudinal view as the primary management-reporting artifact.
The metric has critiques worth naming. A technique with detection coverage may still be detectable in only one specific variant (the Atomic Red Team test exercises one variant; the actual adversary may use a different variant that the rule misses); the coverage measurement therefore overstates the actual operational detection capability. The mature counter is to test multiple variants per technique — the Atomic Red Team catalog provides multiple tests per technique for exactly this reason — and to track variant coverage separately from technique coverage. The metric also doesn’t capture detection quality (a rule that fires correctly but produces 100 false positives per day for every true positive is a worse rule than one that fires correctly with 10 false positives per day, but both count the same in the coverage metric); the mature counter is to track false-positive rates alongside coverage as a complementary metric. The metric is useful, not complete; it is the best single number the practice has produced and its limitations are well-documented.
4.6 Adversary emulation vs detection validation — the vigilance-vs-coverage distinction
A structural distinction worth naming, because it is the single most-misread point about purple-team work: purple-team exercises validate detection coverage; they do not validate analyst vigilance. The distinction is the same one §1.2’s third hard case raised. Restating it in §4 because it determines what the exercise is testing and what it is not:
- Detection coverage is the SIEM-and-EDR pipeline’s capability to generate an alert when a TTP runs in the environment. The question is “did the rule fire?” The rule firing is the success condition. The analyst seeing the alert is a downstream question.
- Analyst vigilance is the SOC’s capability to notice, triage, and respond to the alert the SIEM generates. The question is “did the analyst notice?” The notice-and-act is the success condition. The rule firing is the upstream condition.
The two are different. A purple-team exercise validates the first by design — the blue-team detection engineer queries the SIEM for the expected alert as part of the exercise, regardless of whether the SOC analyst would have noticed it in their queue. The second is what an adversary-emulation engagement (Vol 11) validates — the engagement runs the TTP without announcing it, and the SOC’s actual response is observed. The two engagement formats are complementary; the mature 2026 enterprise security program runs both, on different cadences.
The implication for exercise design is that purple-team exercises should not be evaluated on “did the analyst catch us in real time?” — that question is structurally irrelevant to the exercise’s purpose. The evaluation should be on “did our rules fire correctly?” — the question the exercise was structured to answer. The conflation of the two questions produces purple-team exercises that fail their actual purpose by trying to also be adversary-emulation engagements; the discipline is to keep them separate.
5. A day in the life
The abstract loop of §4 looks much more concrete from inside a working purple-team exercise. This section walks three composite narratives — drawn from publicly available consulting-firm writeups, SANS course materials, conference talks (DEF CON Blue Team Village’s purple-team programming, X33fcon, RingZer0, BSides purple-team content), and observable patterns in the field — to give the texture of what purple-team work actually looks like day to day. The narratives are composite, not single-person biographies; the patterns are real.
5.1 A classical purple-team exercise day — the 8-hour transparent workshop
8:30 AM. A conference room at the headquarters of a regional health-care provider in the U.S. Midwest. Eight people are setting up laptops around a long table. The composition: 3 red-team operators from an external consultancy delivering the engagement, 4 blue-team practitioners from the client (the head of detection engineering, two senior detection engineers, and a SOC tier-3 analyst with detection-engineering responsibilities), and 1 engagement coordinator from the consultancy who will run the exercise’s pacing. A second remote analyst joins via video — one of the consultancy’s detection engineers, providing Sigma-authoring depth that the client team will work alongside.
The exercise’s planning conversation happened two weeks ago. The threat-actor profile is a ransomware-affiliate-class operator — the client’s threat-intel function identified ransomware-as-a-service operators as the modal threat against their environment, and the exercise scope is built around the documented Conti / Black Basta / BlackCat affiliate TTPs. The exercise’s planned ATT&CK technique catalog is 22 techniques covering credential access (T1003.001 LSASS memory, T1003.006 DCSync, T1558.003 Kerberoasting), discovery (T1018 remote system discovery, T1083 file and directory discovery, T1057 process discovery), lateral movement (T1021.002 SMB/Admin Shares, T1021.006 WinRM), persistence (T1053.005 scheduled task, T1547.001 registry run-key), and exfiltration (T1041 exfiltration over C2 channel). The exercise’s mode is transparent — Mode 1 from §4.2; the red team announces every action, the blue team observes in real time, the conversation is the exercise’s primary value.
9:00 AM. The engagement coordinator opens the exercise. The exercise’s logging is set up in the consultancy’s VECTR instance (the client doesn’t yet have its own VECTR deployment; the consultancy’s exercise-tracking platform will hand off the exercise’s findings as the deliverable). The MITRE ATT&CK Navigator layer is on the projector with the 22 planned techniques highlighted; as each technique is exercised, the Navigator layer will be color-coded with the outcome.
9:15 AM. First TTP: T1003.001 (LSASS memory dump via ProcDump, the canonical “credential access via LSASS” technique). The red-team operator describes the technique aloud — “I’m going to run ProcDump against the LSASS process on the test-environment endpoint. The expected telemetry is a Sysmon Event 10 with TargetImage ending in lsass.exe and GrantedAccess containing 0x1010. The expected detection is the Sigma rule that catches non-EDR processes accessing LSASS with that access mask.” The operator runs the Atomic Red Team test (T1003.001-1, the ProcDump variant). The blue-team detection engineer queries the client’s Sentinel SIEM for the expected alert. The alert appears. Detected. The Navigator turns green for T1003.001. Three minutes elapsed.
9:30 AM. Second TTP: T1558.003 (Kerberoasting). The red-team operator runs Rubeus’s kerberoast command against the test environment. The blue-team detection engineer queries Sentinel. The alert appears. Detected. Navigator green for T1558.003.
9:45 AM. Third TTP: T1003.006 (DCSync). The red-team operator runs Mimikatz’s lsadump::dcsync against a non-domain-controller endpoint with stolen credentials. The blue-team detection engineer queries Sentinel. The alert does not appear. Not detected. Navigator red for T1003.006. The team pauses to author the detection rule.
10:00-11:00 AM. The DCSync rule authoring is the exercise’s first detection-engineering work. The red-team operator describes the expected telemetry — a directory-replication request from an unexpected source IP, observable through Microsoft Defender for Identity’s MDI alerts or through Domain Controller’s directory-service-access events. The client team confirms MDI is deployed but the alert was not configured to fire to Sentinel. The remote consultancy detection engineer drafts the corresponding Sigma rule; the rule deploys to Sentinel within 20 minutes. The red-team operator re-runs the DCSync command. The newly-deployed rule fires. Re-validated. Navigator green for T1003.006. One hour elapsed (the gap-closure step is the time-intensive one; the loop’s value is concentrated here).
11:00 AM-12:30 PM. Discovery techniques (T1018, T1083, T1057) and lateral-movement techniques (T1021.002, T1021.006). The red-team operator runs each; the blue-team confirms detection for 4 of the 5 (the WinRM lateral movement T1021.006 fires only partially — the SIEM logs the authentication event but the corresponding alert rule is misconfigured). The team authors the fix for the WinRM rule; deploys it; re-validates; moves on.
12:30 PM. Lunch break. The team’s discussion over lunch is the exercise’s secondary value — the informal knowledge transfer between the red-team operators (who carry the engagement-realistic context) and the blue-team practitioners (who carry the production-environment context).
1:30-4:30 PM. Persistence techniques (T1053.005, T1547.001), additional credential-access TTPs (T1110.001 password guessing, T1110.003 password spraying), and exfiltration (T1041). Of the remaining 11 TTPs, 7 are detected immediately, 3 require rule authoring (one for the scheduled-task persistence, one for the password-spraying detection, one for the exfiltration channel), and 1 is identified as out-of-scope for the test environment (T1041 over a specific C2 channel that the test environment doesn’t permit).
4:30-5:30 PM. Exercise debrief. The engagement coordinator walks through the exercise’s outcomes: 18 of 22 techniques validated as detected (green); 4 had gaps that were closed during the exercise (the rules are now in Sentinel and will be in the regression sweep for the next exercise); 1 was scoped out. The exercise’s findings:
- The client’s detection coverage for the tested catalog was 82% on entry; the exercise’s gap-closure work brought it to 95% by end-of-day.
- The four detection rules authored during the exercise are handed to the client’s detection-engineering function for long-term lifecycle ownership. The rules are documented with the exercise’s ID, the TTP they catch, and the next-exercise regression-validation requirement.
- The next quarterly exercise is scheduled for three months from now. The TTP catalog will be re-selected from the threat-intel function’s then-current focal threat actors; the four rules authored today will be in the regression sweep.
- The client’s overall ATT&CK coverage metric (computed against the client’s broader threat model, not just today’s tested subset) is approximately 24% as of the exercise’s exit measurement. The 12-month trajectory target is 35%; the quarterly exercises are the primary mechanism for moving the metric.
5:30 PM. End of exercise day. The consultancy team packs up; the client team’s detection-engineering lead schedules a follow-up meeting next week to walk through the rule-ownership handoff. The exercise’s documentation (the VECTR records, the Navigator layer, the four authored Sigma rules) is the deliverable; the metric movement is the outcome.
5.2 A continuous-purple operator’s week — large enterprise BAS-platform-driven program
Monday 9:00 AM. The senior detection engineer — call her Priya — opens her laptop at the headquarters of a Fortune-500 financial-services firm. She’s the detection-engineering lead on the firm’s continuous-purple program; the BAS platform (AttackIQ in this firm’s case) runs continuously against the firm’s environment and produces a daily backlog of TTP-execution outcomes. Her week’s rhythm is the backlog-processing rhythm: each morning she reviews the previous 24 hours of BAS findings, prioritizes the new detection gaps, and works through them with her two-person detection-engineering team.
Monday 9:30 AM. Today’s backlog: 8 new detection gaps surfaced by the BAS platform overnight. Three are repeats of gaps already in the team’s backlog (the BAS platform tests each TTP multiple times; the repeat findings get consolidated rather than re-prioritized). Two are new gaps in techniques the team hasn’t tested before. One is a regression — a previously-validated detection that has stopped firing (likely because the underlying SIEM data model changed when the EDR vendor pushed an update last week). Two are noisy — the rules are firing but generating excessive false positives that need tuning.
The Monday morning meeting (Priya + her two detection engineers + the threat-intel analyst who supports the program) goes through the eight items. The regression gets top priority (a working rule that stopped firing is the highest-urgency item; the gap may be already-exploited). One of the new gaps is from a TTP that the firm’s threat-intel analyst flagged as recent — a specific Volt Typhoon-associated technique that’s gotten coverage in the past quarter’s threat-intel reporting. The other new gap is from a less-prioritized TTP that goes into the backlog for the week.
Monday 11:00 AM. Priya works on the regression. The investigation shows that the EDR vendor’s update changed the event-format for process-creation events, and the existing Sigma rule’s field-mapping no longer matches. The fix is straightforward (update the rule’s field mappings to the new event format); the deployment takes 30 minutes; the BAS platform’s next regression-sweep at 2 PM confirms the rule is firing again. The regression item closes by end-of-day.
Tuesday-Wednesday. The two senior detection engineers work the two new-gap items. The Volt-Typhoon-associated technique requires custom rule authoring; the engineer building the rule consults with one of the firm’s red-team operators (a member of the in-house red team, not the external consultancy — the firm’s red team is in-house) for the technique’s expected telemetry signature. The rule’s first-draft is written Tuesday; the BAS-platform’s validation sweep confirms the rule fires Wednesday morning; the rule is handed to the regression-test catalog Wednesday afternoon. The second new gap is closed by Wednesday end-of-day.
Thursday. The two false-positive-noisy rules get the team’s attention. The investigation is detection-engineering bread-and-butter work: examine the false-positive instances, identify the systematic feature that distinguishes the false-positives from the true-positives, update the rule’s filter logic to exclude the false-positive feature, re-validate that the true-positive cases still fire, re-deploy. By Thursday end-of-day both rules’ false-positive rates have come down by approximately 80%; the rules will be re-validated against the BAS platform’s tests over the weekend.
Friday. The week’s red-blue sync meeting. Priya, the two detection engineers, the threat-intel analyst, and three members of the in-house red team meet for 60 minutes. The agenda: review the week’s BAS-platform findings, discuss the upcoming month’s planned purple-team exercise (the firm runs a monthly coordinated-mode exercise alongside the continuous BAS work — Mode 2 from §4.2), and align on the next quarter’s TTP-catalog priorities. The meeting is the firm’s structural integration mechanism — the BAS platform handles the continuous regression sweep; the monthly coordinated exercises handle the deeper qualitative work; the weekly meeting integrates the two.
The week’s outcomes: 1 regression closed; 2 new gaps closed; 2 noisy-rule tuning items resolved; the BAS platform’s overall detection-coverage metric has moved from 38% to 38.6% (continuous-purple’s rate of metric improvement is structurally slower than the discrete exercise’s pulse-and-jump pattern; the trade-off is the continuous baseline-validation that catches regressions immediately rather than at the next exercise window). The next week’s backlog is already accumulating; the BAS platform’s tests continue to run.
5.3 A purple-team consulting engagement — multi-week capability uplift for a client SOC
A different consultancy engagement. The client is a manufacturing firm with a relatively-immature security operations program — they have a SOC (small, three tier-1 analysts and one tier-2 lead), an EDR product deployed across the endpoint fleet (CrowdStrike Falcon), and a SIEM (Splunk Cloud) that is mostly ingesting logs without much detection-rule authoring. The firm’s CISO has hired an external consultancy for a 12-week purple-team capability uplift engagement — the engagement’s deliverable is not just a single purple-team exercise’s findings but a transferred capability: at the end of the engagement, the client’s detection-engineering function should be able to run its own purple-team exercises without consultancy participation.
The engagement’s consultant — call him Marcus — has been on-site (and remote across video) for 8 weeks. The engagement structure:
- Weeks 1-2: assessment. Marcus reviews the client’s current detection-rule catalog (small, mostly the SIEM vendor’s out-of-box content); the current EDR alerting (deployed but the alert-tuning hasn’t been done); the SIEM data model (the right logs are being ingested but the parsers need work); the SOC’s current alert-triage workflow. The deliverable is a current-state assessment + a 10-week uplift plan.
- Weeks 3-4: foundation. Marcus works with the client’s SOC tier-2 lead to introduce the MITRE ATT&CK framework as the detection-coverage organizing structure, deploy a VECTR Community Edition instance for exercise tracking, and stand up the Invoke-AtomicTest PowerShell module in the client’s test environment. The deliverable is the infrastructure for the rest of the engagement.
- Weeks 5-8: exercises and rule authoring. Marcus runs four purple-team exercises (one per week), with the client’s detection-engineering capability scaling up: the first exercise is Marcus-led with the client observing; the second is Marcus-and-client co-led; the third is client-led with Marcus assisting; the fourth is client-led with Marcus observing only. The exercises target progressively-narrower TTP catalogs (the first covers a broad sweep; later exercises focus on specific technique families). By end of week 8, the client’s detection-engineering capability has authored approximately 25 Sigma rules across the four exercises; the firm’s detection coverage metric has moved from approximately 8% on entry to approximately 22%.
- Weeks 9-10: process formalization. Marcus works with the client to formalize the firm’s go-forward purple-team practice — the exercise cadence (proposed monthly), the TTP-selection conversation (proposed quarterly threat-intel-informed planning), the rule-lifecycle ownership (the detection-engineering function owns post-exercise; the exercise itself owns during-exercise), the metrics reporting (the VECTR dashboard, the per-quarter coverage trajectory report to the CISO).
- Weeks 11-12: handoff and capability validation. The client’s detection-engineering function runs the final purple-team exercise of the engagement entirely independently; Marcus observes only. The exercise covers 15 TTPs across the same kill-chain phases the earlier exercises covered. The client team’s execution is independent and successful; the exercise’s findings are documented; the metric movement is recorded. The engagement closes with the consultancy’s formal handoff documentation and the client’s commitment to the continued cadence.
The engagement’s value to the client is the transferred capability — at end of engagement, the client can run its own purple-team practice without consultancy participation. The engagement’s cost is in the range of $250-400K for the 12-week consultant time + materials + supporting infrastructure; the client’s CISO has justified the spend against the SOC capability gap and the regulatory-compliance reporting that the practice supports. Marcus’s role across the engagement is the purple-team practice consultant specialization that §6.3 will treat — the consultant whose expertise is uplifting other organizations’ practices, not running the practices themselves.
Figure 12.2 — A network security operations center floor — the working environment of the purple-team exercise’s blue-team participants. File:NSOC-2012.jpg by Unknown photographer. License: Public domain. Via Wikimedia Commons (https://commons.wikimedia.org/wiki/File%3ANSOC-2012.jpg).
6. How they get hired
The purple-team career path is less well-formalized than red-team (Vol 11 §6) or blue-team (Vol 10 §6). Purple-team work is more often a career stage that practitioners reach after substantive experience in one or both of the contributing functions than a direct entry path; the relatively-small purple-team-as-job-title role population (§1.1) reflects this. The certification ladder, the typical career-stage progression, and the four specialization paths within the practice are walked below.
6.1 The purple-team cert ladder
The certification landscape for purple-team work is structured around the SANS pair (SEC599 + SEC699), the MITRE-Engenuity MAD program (now operated by MAD20 Technologies), and a small set of complementary credentials. The ladder is less linear than the red-team or blue-team cert ladders because the purple-team role’s heterogeneity allows multiple valid paths in.
| Certification | Issuing organization | Approximate cost (2026) | Focus | Career stage |
|---|---|---|---|---|
| GIAC GDAT — Defending Advanced Threats | SANS GIAC2 | ~$2,000 (cert only); SANS SEC599 course ~$8,000 | Purple-team tactics, kill-chain defenses, the integration practice. The canonical purple-team-curriculum cert; built on SEC599 | Mid-to-senior — the role-specific cert |
| GIAC GAPT — Advanced Purple Teaming (newer cert; emerging from SEC699 curriculum) | SANS GIAC3 | ~$2,000 (cert only); SANS SEC699 course ~$8,000 | Advanced adversary emulation and detection engineering; building custom adversary infrastructure; BAS-platform integration | Senior — the depth-specialization cert |
| MAD ATT&CK Adversary Emulation | MITRE ATT&CK Defender (MAD20)4 | ~$499/yr individual subscription (badge series) | ATT&CK framework fluency from the adversary-emulation side | Entry-to-mid — the foundational ATT&CK-fluency credential |
| MAD ATT&CK Cyber Threat Intelligence | MITRE ATT&CK Defender (MAD20) | Per MAD subscription | ATT&CK fluency from the threat-intel side | Entry-to-mid — complementary ATT&CK credential |
| MAD ATT&CK Security Operations Center Assessment | MITRE ATT&CK Defender (MAD20) | Per MAD subscription | ATT&CK fluency from the SOC-assessment side | Entry-to-mid — complementary ATT&CK credential |
| MAD ATT&CK Threat Hunting | MITRE ATT&CK Defender (MAD20) | Per MAD subscription | ATT&CK fluency from the threat-hunting side | Mid-level — complementary credential for hunting-track practitioners |
| CRTO — Certified Red Team Operator | Zero-Point Security | ~$500 | Cobalt Strike operations + AD attack + the engagement-realistic red-team workflow | Mid-level — the canonical red-team-side prerequisite per §6.2 |
| GIAC GCDA — Certified Detection Analyst | SANS GIAC | ~$2,000 (cert only); SANS SEC555 course ~$8,000 | Detection-engineering and SIEM-content authoring | Mid-level — the canonical blue-team-side prerequisite per §6.2 |
| OSCP — Offensive Security Certified Professional | Offensive Security | ~$1,600 | Network penetration testing fundamentals | Entry-to-mid — broad offensive baseline |
Table 12.4 — The purple-team cert ladder, with approximate 2026 costs. The SANS pair (GDAT/SEC599 + GAPT/SEC699) is the canonical purple-team-specific curriculum; the MAD program provides the ATT&CK-fluency credentials that complement the SANS depth; the CRTO and GCDA represent the red-team-side and blue-team-side prerequisite certifications most purple-team practitioners hold. The certification landscape is less consolidated than the red-team (CRTO-centered) or blue-team (GCIH/GCFA-centered) landscapes — the purple-team practitioner’s portfolio typically reflects their entry path (red-side, blue-side, or detection-engineering-side) more than a single canonical credential.
6.2 The “purple as career stage” pattern
The modal career path into purple-team work: 5-10 years in either red-team or blue-team work → purple-team practitioner. The transition is gradual; practitioners accumulate increasing exposure to the other side’s work, eventually reaching the point where they can comfortably operate the integration practice. The three typical pathways:
Pathway A — Red-to-purple. The practitioner starts as a pentester (Vol 6), transitions to red-team work (Vol 11), and in the senior-operator phase begins to take on detection-engineering responsibilities through purple-team exercise work. The transition is gradual; the senior red-team operator gradually develops the SIEM-and-detection-engineering depth required to author rules, gradually shifts their engagement mix from pure red-team to red-and-purple, and may eventually settle into a primarily-purple role. The pathway is canonical for the “I want to see my engagement findings actually become deployed detections” career motivation.
Pathway B — Blue-to-purple. The practitioner starts as a SOC analyst (Vol 10), transitions to detection engineering, and in the senior-detection-engineer phase begins to take on adversary-emulation responsibilities through purple-team exercise work. The transition is gradual; the senior detection engineer gradually develops the offensive-tooling depth required to execute TTPs, gradually shifts their engagement mix from pure detection-engineering to detection-and-purple, and may eventually settle into a primarily-purple role. The pathway is canonical for the “I want to validate my detections against an actual adversary technique catalog” career motivation.
Pathway C — Combined-from-start. The smaller but distinct pathway: the practitioner enters with a deliberate purple-team focus from early career, building red-team and blue-team experience in parallel through deliberate role-rotation, conference content engagement, and the SANS curriculum. The pathway is rarer because it requires deliberate planning at junior-career stages where the field’s standard advice is to specialize; the practitioners who follow it often have non-traditional educational backgrounds (military, IC, or self-directed) and a clear early intent.
Most senior purple-team practitioners in 2026 came from Pathway A or B; Pathway C exists but is the minority. The implication for hiring is that purple-team job postings typically require demonstrated experience in both red-team and blue-team work — the “5+ years red-team plus 3+ years detection engineering” or equivalent. Entry-level direct-to-purple is rare; the role’s depth-of-knowledge requirements make it structurally difficult to fill from outside the field.
The compensation picture (the 2026 US-coast-and-major-metro reference points): a mid-career purple-team practitioner — typically Year 8-12 of combined red + blue experience — earns approximately $200k-$320k base + bonus, comparable to the cloud red-team specialization (Vol 11 §6.3) and the senior detection-engineering specialization (Vol 10 §6.4). The senior-most purple-team roles (Purple Team Lead at major enterprises; Practice Lead at major consultancies) reach $280k-$420k base + bonus + equity for the tech-firm and major-bank tier. The compensation premium over pure-red or pure-blue at the same experience-level is modest but real, reflecting the combined-skill scarcity.
6.3 The four specialization paths within purple-team work
Senior purple-team practitioners typically specialize. The four canonical specialization paths:
| Specialization | What it is | Typical employer pattern | Mid-career US comp band (2026 reference) |
|---|---|---|---|
| Detection-engineering-lead (blue-heavy purple) | The detection-engineering function leadership role with adversary-emulation depth as the validation mechanism. The senior detection engineer who can also execute the red side of the loop; the canonical “purple practitioner via Pathway B” senior outcome | Major enterprise in-house programs; MSSPs with mature detection-engineering offerings; specialized detection-engineering consultancies | $220k-$320k base + bonus |
| Adversary-emulation-with-handoff (red-heavy purple) | The senior red-team operator whose engagements explicitly include the purple-team handoff to client detection-engineering teams. The canonical “purple practitioner via Pathway A” senior outcome | Major consultancies (Mandiant, CrowdStrike Services, IBM X-Force Red, Bishop Fox, NCC Group); specialized purple-team consultancies (SCYTHE, NVISO’s purple-team practice) | $200k-$300k base + bonus |
| BAS platform engineer / continuous-purple specialist | The detection-engineering and DevSecOps-adjacent specialist who operates a BAS platform as the continuous purple-team substrate; integrates BAS findings into the detection-engineering pipeline; manages the platform’s TTP catalog and per-rule validation | Larger enterprise programs with BAS-platform investment; BAS-vendor customer-success or solutions-engineering roles | $190k-$280k base + bonus |
| Purple-team consulting (capability-uplift specialist) | The external consultant who delivers purple-team capability uplift to client organizations (the §5.3 composite); multi-week engagements with hands-on training and process formalization; the “uplifting other people’s programs” specialist | Specialized purple-team consultancies; some major consultancy purple-team practices; some independent consultants | $200k-$310k base + bonus + per-engagement margin if practice partner |
Table 12.5 — Four purple-team specialization paths at the senior career level. The first two paths represent the natural extensions of the Pathway A and Pathway B career-stage transitions; the third represents the technical-specialist track around the BAS platform tooling; the fourth represents the consulting-track for practitioners whose primary value is uplifting other organizations’ practices. The compensation bands are early-2026 US-coast-and-major-metro reference points; specific role compensation varies by employer scale, geography, equity component, and specific role-and-title structure. The four paths share the structural feature that they all require demonstrated depth in both red-team and blue-team work; the specialization is in which side of the integration the practitioner’s primary leverage comes from.
6.4 Vol 18 forward-reference
Vol 18 (Careers, pending Phase 3 authoring) will treat the full career synthesis across the seven hats, including the purple-team integration of red and blue at the senior career stage. This §6 is the purple-team-specific cut; Vol 18 will walk the full picture, including the cross-hat mobility patterns (how practitioners move between specializations across career), the compensation maps at the executive level (CISO compensation, head-of-security-operations compensation, CTO-of-security compensation), and the founder track (the senior practitioner who leaves the consultancy or enterprise to start their own purple-team-focused firm — SCYTHE, NVISO, and several others are exemplars).
7. Famous figures
A short roster of purple-team practitioners and educators whose work has shaped the field. The selection emphasizes people whose impact is broad rather than narrow — the curriculum authors, the tool authors, the practitioners whose published methodology has changed how others run the practice. The intent is not exhaustive coverage of the field’s notable purple-team figures; that’s well beyond a single volume’s reach. The intent is to ground the discussion of purple-team practice in real people whose careers and decisions exemplify what purple-team contribution has looked like over the field’s professional history.
Career role claims in the profiles below are accurate as of early 2026; verify current employer via the cited footnote primary sources before relying on this for outreach.
7.1 Erik Van Buggenhout — the canonical purple-team educator-and-architect
Erik Van Buggenhout is the canonical figure for the modern purple-team curriculum and the institutional architecture that defines the practice. He is a Belgian information-security practitioner whose two principal threads of contribution are (a) co-founding NVISO, a Belgian security consultancy where he leads the Managed Security Services practice (the firm’s 24x7 Managed Detection and Response services), and (b) the SANS Institute curriculum authorship that has substantially defined how the field teaches purple-team work9. He has been involved with SANS since 2009 (initially as a Mentor; progressing through Community Instructor in 2012, Certified Instructor in 2016, and Senior Instructor in 2020), and is the lead author of two of the curriculum’s load-bearing courses: SEC599: Defeating Advanced Adversaries — Purple Team Tactics and Kill Chain Defenses (launched 2016) and SEC699: Advanced Purple Teaming — Adversary Emulation and Detection Engineering (premiered 2020). He is also a co-author of SEC560: Network Penetration Testing and Ethical Hacking, the canonical SANS pentest course.
As of early 2026, Van Buggenhout’s roles are: Partner and Head of Managed Security Services at NVISO (the Belgian consultancy he co-founded), SANS Senior Instructor and lead author of SEC599 and SEC699, and co-author of SEC560. The 2025-2026 SEC599 update he delivered — adding AI-enabled detection content, expanded purple-team labs, and Terraform-managed range infrastructure — reflects the course’s continued evolution and his sustained ownership of the curriculum10. Prior to NVISO, his career included five years at a Big 4 consulting firm where he developed into the EMEA-region subject-matter expertise that NVISO subsequently built on. The two-thread profile (consultancy partner-and-practice-lead + SANS curriculum author) is unusual at his seniority and is what makes him the canonical educator-and-architect figure.
Why he matters for this volume: Van Buggenhout exemplifies the curriculum-author-and-practitioner career arc in the purple-team space. SEC599 is the course that has substantially defined how purple-team work is taught; the curriculum’s structural framing — kill-chain phases as the organizing structure, with red-and-blue treated as integrated rather than sequential — is the methodological framework that the modern purple-team practice rests on. The NVISO managed-services parallel work gives the curriculum its operational grounding; the SANS instructor work gives the operational practice its educational reach. The combination is the model for the small population of senior purple-team educators whose influence is structural to the field’s working practice.
7.2 Daniel Bohannon — the canonical “red researcher writes detections” figure
Daniel Bohannon is the canonical figure for the offensive-research-feeds-defensive-engineering career pattern that purple-team work institutionalizes. His public-record arc starts with the Invoke-Obfuscation PowerShell obfuscation framework (released 2016; the canonical reference tool for PowerShell-payload obfuscation that adversaries use to evade signature-based detection)11, followed by the Invoke-CradleCrafter and Invoke-DOSfuscation companion projects. The obfuscation-research output put him in the small population of researchers whose tooling is studied by both the offensive and defensive sides of the field — a structural prerequisite for the kind of purple-team integration work that came later. His subsequent work — including the Revoke-Obfuscation detection-side companion project (co-authored, focused on detecting PowerShell obfuscation) — shifted from purely-offensive research into the offensive-and-defensive integration that purple-team work exemplifies.
His career arc tracks the offensive-to-purple pathway. Prior incident-response consulting at Mandiant (the canonical commercial IR consultancy, Vol 11 §2.2) and security research at FireEye (the parent company through Mandiant’s 2013-2022 ownership window) gave him the offensive-and-defensive consulting context. Threat-hunting at Microsoft gave him the operational-defender depth. As of early 2026, Bohannon is Principal Threat Researcher on Permiso Security’s P0 Labs team, with over 14 years of information-security experience across the offensive-research, defensive-engineering, and threat-hunting domains12. His 2026 research includes the Cloud Console Cartographer project (co-authored, focused on cloud-environment defensive coverage) and recent prompt-injection research documenting a Microsoft Copilot Cross Prompt Injection (XPIA) issue filed as CVE-2026-26133.
Why he matters for this volume: Bohannon exemplifies the single researcher whose output feeds both offensive and defensive practice — the structural pattern that purple-team work institutionalizes at the team level. Invoke-Obfuscation is read by red-team operators developing payload-evasion capability and by detection engineers developing obfuscation-detection rules; the dual readership is the kind of integration that purple-team practice scales up to a team-level capability. The career arc — offensive researcher → incident-response consultant → security researcher → threat hunter → cloud-and-AI threat researcher — covers the breadth of working contexts that senior purple-team practitioners typically span; the engineering-depth output (working tooling that the field uses) is the substantive credibility that supports the career-stage transition.
7.3 Christopher Peacock — the Atomic-Red-Team-meets-SCYTHE practitioner
Christopher Peacock is the canonical figure for the purple-team practitioner whose primary contribution is the practice-itself rather than a single tool. As of early 2026, Peacock is Distinguished Engineer at Verizon (Readiness and Proactive Security team, joined when SCYTHE’s team migrated into Verizon; previously Principal Detection Engineer at SCYTHE)13. His public profile is author of the TTP Pyramid (a structural taxonomy for adversary-emulation work that has been adopted in some practitioner communities), Black Hat course author and instructor, Top-20 Sigma rule contributor, and Top-10 LOLBAS (Living Off the Land Binaries and Scripts) contributor. His SCYTHE library content carries multiple long-form posts on the detection-engineering process, the relationship between Atomic Red Team and SCYTHE platform work, and the broader purple-team methodology.
Peacock’s substantive contribution is the integration discipline itself — the working practice of converting threat-intel reporting into adversary-emulation profiles, running the profiles against the environment, and feeding the findings into detection-engineering work. The SCYTHE platform’s recent integration with Atomic Red Team (the “SCYTHE Goes Atomic” release) reflects this integration discipline at the product level; Peacock’s blog content explains it at the practitioner level. His Sigma-contributor and LOLBAS-contributor activity sit on the defensive-and-offensive integration territory that purple-team work occupies; the dual contribution is the structural feature.
Why he matters for this volume: Peacock exemplifies the practitioner-author whose contribution is the practice-itself — the integration discipline, the documentation of the integration discipline, the consultancy-side delivery of the integration discipline to client organizations. Unlike Van Buggenhout (the educator-architect at the curriculum level) or Bohannon (the researcher with single-tool legacy), Peacock’s contribution is the working-practitioner output of someone who runs purple-team work as a primary daily job and writes about it as the secondary activity. The career profile is recognizable in the broader population of senior purple-team consultants who deliver both client engagements and community-content output; Peacock is the canonical exemplar of the type.
7.4 Casey Smith and Michael Haag — Atomic Red Team’s founding co-creators
Casey Smith and Michael Haag are the co-creators of Atomic Red Team (§3.1) — the open-source detection-test library that has become the canonical narrow-TTP execution layer of the purple-team practice. The project was originally named Bookish-Happiness in summer 2017 when Smith and Haag built it for Red Canary’s internal evaluation work; the public release came in October 2017 at the Carbon Black User Exchange, with approximately 75 atomic tests at launch5. The project’s subsequent growth — to approximately 1,500 atomic tests across the ATT&CK catalog by early 2026, with active community contribution and continuous Red-Canary stewardship — has made it the field’s canonical detection-validation test library. The PowerShell-execution wrapper (Invoke-AtomicTest) and the YAML-test-format that the wrappers consume were added in 2018 and have remained the framework’s stable architecture since.
As of early 2026: Casey Smith is Senior Security Researcher at Thinkst Applied Research (the deception-and-canary research arm of Thinkst, the firm behind the Thinkst Canary deception product) after his earlier role at Red Canary as Director of Applied Research14. Michael Haag is Principal Threat Research Engineer at Splunk, where his work continues across the Splunk Threat Research Team’s security content15 and includes substantial ongoing Atomic Red Team community contribution. The career arcs diverge — Smith into deception research at a different firm, Haag into the Splunk security-content-engineering practice — but the Atomic Red Team co-authorship remains the load-bearing community contribution of both careers.
Why they matter for this volume: Smith and Haag exemplify the practitioner-authors whose project becomes a field-standard tool. Atomic Red Team’s adoption — by enterprises as the detection-validation substrate, by consultancies as the engagement-execution catalog, by BAS-platform vendors as the integration baseline (SCYTHE’s “SCYTHE Goes Atomic” release is one example), by educators as the curriculum-execution catalog — is the kind of structural influence that defines what the field’s working practice looks like. The career arcs after the project’s release (different firms, different specializations) are typical for senior practitioners whose canonical contribution is a project rather than a continuous practice; the project’s stewardship has shifted to the broader Red Canary team and the open-source community, and the original co-creators have continued into their next projects.
7.5 Justin Henderson — the canonical detection-engineering-curriculum author
Justin Henderson is the canonical figure for the SANS detection-engineering curriculum thread that complements Van Buggenhout’s purple-team curriculum thread. As of early 2026, Henderson is Founder and CEO of H&A Security Solutions (the consultancy he founded, focused on SIEM-and-NSM-and-detection-tooling deployment and tuning for client organizations) and a SANS Instructor and course author for the detection-and-monitoring curriculum16. His canonical SANS work is SEC555: SIEM with Tactical Analytics, the detection-engineering-focused course that has trained substantial parts of the detection-engineering practitioner population since its release. He has also authored or contributed to additional SANS curriculum including SEC455 (the SIEM-focused complementary course).
His career arc tracks the detection-engineering-from-the-ground-up pattern. The H&A Security Solutions consultancy work is the operational grounding (deploying and tuning SIEM and NSM tooling for clients); the SANS curriculum work is the educational reach. The combination — operational consultancy + curriculum authorship — is the pattern that several senior SANS instructors share, and it’s what gives the curriculum the operational credibility that pure-academic curriculum would lack.
Why he matters for this volume: Henderson exemplifies the detection-engineering-side educator whose contribution is the curriculum that trains the blue-team-side of the purple-team integration. The detection-engineering depth that a senior purple-team practitioner needs comes substantially from curriculum like SEC555; the operational practice that the curriculum enables is what makes purple-team integration work at the practitioner level. Van Buggenhout’s purple-team-integration curriculum (SEC599 + SEC699) and Henderson’s detection-engineering-foundation curriculum (SEC555) are complementary; together they cover the curriculum needs of the senior purple-team practitioner population at the SANS-track level.
7.6 The five-figure summary
| Figure | Role / employer (early 2026) | Specialty | Canonical contribution | Arc type |
|---|---|---|---|---|
| Erik Van Buggenhout | Partner, Head of Managed Security Services at NVISO; SANS Senior Instructor and lead author of SEC599 + SEC699; co-author of SEC560 (verify9) | Purple-team curriculum architecture; managed-services consultancy practice | SEC599 (2016) and SEC699 (2020); the canonical purple-team curriculum; NVISO co-founding | Curriculum-author + consultancy-partner; the educator-architect type |
| Daniel Bohannon | Principal Threat Researcher at Permiso Security P0 Labs (verify12) | Offensive-research-to-defensive-engineering integration | Invoke-Obfuscation (2016); Invoke-CradleCrafter; Invoke-DOSfuscation; Revoke-Obfuscation co-authorship; Cloud Console Cartographer; CVE-2026-26133 research | Offensive researcher → IR consultant → threat hunter → cloud-and-AI threat researcher; the canonical “red researcher writes detections” arc |
| Christopher Peacock | Distinguished Engineer at Verizon (Readiness and Proactive Security team; previously Principal Detection Engineer at SCYTHE — verify13) | Atomic-Red-Team-meets-SCYTHE; the integration practice itself | TTP Pyramid taxonomy; Black Hat course authorship; Top-20 Sigma contributor; Top-10 LOLBAS contributor; SCYTHE library content | Working-practitioner author; the “practice-itself” contribution type |
| Casey Smith & Michael Haag | Smith: Senior Security Researcher at Thinkst Applied Research. Haag: Principal Threat Research Engineer at Splunk (verify14 15) | Atomic Red Team co-creation and ongoing stewardship | Atomic Red Team (October 2017); the canonical narrow-TTP detection-validation library; the YAML-test-format architecture | Project co-creators; their canonical project has become field-standard tooling |
| Justin Henderson | Founder and CEO of H&A Security Solutions; SANS Instructor and course author (verify16) | Detection-engineering curriculum (the SANS blue-side track that complements Van Buggenhout’s purple-team-integration track) | SEC555 SIEM with Tactical Analytics course authorship; H&A Security Solutions founding | Curriculum-author + consultancy-founder; the detection-engineering-side educator type |
Table 12.6 — The five-figure roster in shorthand. Each entry is a practitioner whose work has shaped substantial parts of the purple-team community’s working practice; the selection covers curriculum architecture (Van Buggenhout), offensive-to-defensive integration research (Bohannon), working-practitioner-author (Peacock), the canonical narrow-TTP execution library (Smith and Haag, treated jointly as the project’s co-creators), and the detection-engineering-side curriculum complement (Henderson). The roster is not exhaustive — Tim Schulz (SCYTHE / formerly at MITRE) on adversary-emulation methodology; Jorge Orchilles (formerly SCYTHE; now Senior Director at Verizon, leading the Readiness and Proactive Security team) on the broader purple-team practice; David J. Bianco (sqrrl/Splunk) on the Pyramid of Pain that informed detection-engineering thinking; the broader CALDERA contributor population at MITRE; many others — belong in a longer roster. The five chosen here span the principal flavors of the senior purple-team career.
8. Callouts and cross-references
The purple-hat treatment lands on the rest of the deep dive as a set of explicit forward- and back-references. This section makes those explicit, plus the mandatory load-bearing callouts and the cheatsheet bullets that will end up in Vol 20. As the last of the seven hat volumes (Vols 6-12), this section also serves as the closing summary of the hat-cluster’s structural relationships.
8.1 Purple is a verb, not a noun — load-bearing callout (restated)
Purple is a verb, not a noun. Purple-team is overwhelmingly what an organization does, not what a person is. The 2026 practitioner population identifies its primary role as red-team or blue-team or detection-engineering, with purple-team work as a mode of engagement the same individuals participate in. The small population of practitioners whose primary identity is purple-team-integration exists but is rarer than the corresponding red-team-operator or blue-team-analyst populations. This is the volume’s most-frequently-misread structural point. The implication for organizational structure is that building “a purple team” as a third standing function alongside red and blue is usually the wrong design; the right design is establishing the purple-team practice that the existing red and blue functions execute together on a structured cadence. The integration is the deliverable, not the headcount. Restated from §1 because it is the volume’s load-bearing rhetorical anchor.
8.2 The red/blue/purple Venn — the centerpiece visual
The relationship between red, blue, and purple — visualized. The three colors are not three teams; they are two functions and the integration practice that connects them. The Venn-style representation:
┌──────────────────────────────────────────────────────┐ │ │ │ PURPLE-TEAM │ │ (the practice) │ │ │ │ ┌────────────────────────┐ │ │ │ RED-TEAM │ │ │ │ │ │ │ │ - Adversary │ │ │ │ emulation │ │ │ │ - C2 framework │ │ │ │ operation │ │ │ │ - TTP execution │ ←─── INTEGRATION ───→ │ │ │ - Engagement work │ LOOP │ │ │ │ │ │ └────────────────────────┘ │ │ │ │ ┌────────────────────────┐ │ │ │ BLUE-TEAM │ │ │ │ │ │ │ │ - SOC operations │ │ │ │ - Detection │ │ │ │ engineering │ │ │ │ - Incident response │ │ │ │ - Threat hunting │ │ │ │ │ │ │ └────────────────────────┘ │ │ │ │ The integration loop is what makes "purple" purple:│ │ red executes → blue observes → gap identified → │ │ rule authored → rule deployed → red re-validates → │ │ loop closes → next TTP │ │ │ └──────────────────────────────────────────────────────┘Figure 12.3 — The red/blue/purple relationship as a Venn-style representation. The two functions (red-team and blue-team) operate as distinct organizational units with their own toolchains, working rhythms, and career paths; the purple-team practice is the integration mechanism that connects them via the structured feedback loop §4.4 walked. The accurate framing is “two functions and an integration practice,” not “three teams.” The relationship is complementary, not adversarial; the integration is the structural feature that distinguishes a mature program from one that runs red and blue separately and hopes the findings transfer.
8.3 Purple closes the loop — the value-delivery callout
The detection-engineering-to-adversary-emulation iteration is what generates measurable defensive improvement. A red-team engagement produces a report. A blue-team detection-engineering function produces rules. Neither alone produces the validated outcome that the engagement found a detection gap AND the gap got closed AND the next iteration confirmed the closure. The purple-team practice is the iteration mechanism that produces the validated outcome — and the validated outcome is what moves the detection-coverage metric, which is what makes the practice measurable as engineering work rather than as an isolated event. The implication for program-management framing: purple-team work is the mechanism through which the organization’s threat-intel investment becomes the organization’s deployed detection capability. Without purple, threat-intel produces reports that may or may not become detections; with purple, threat-intel produces reports that drive exercises that produce validated detections. The loop’s closure is the value.
8.4 Cross-references within this series — closing the seven-hat cluster
This volume closes the seven-hat cluster (Vols 6-12). The cluster’s structural shape:
- Vol 6 (White hat) — the authorization-paperwork-anchor for the rest of the cluster. The white-hat pentester’s SOW + scope + ROE + GOJL paperwork stack is the canonical model that red-team work (Vol 11) and purple-team work (this volume) substantially share.
- Vol 7 (Black hat) — the unauthorized adversary. The discriminator between black-hat and the authorized hats (white, blue, red, purple) is the authorization stack, not the technique. Vol 7’s criminal-economy treatment provides the threat-actor context that purple-team adversary emulation models against.
- Vol 8 (Grey hat) — the unauthorized-but-constructive case. The grey-hat boundary is structurally adjacent to white-hat work; purple-team work is firmly white-hat-authorized and does not occupy the grey zone.
- Vol 9 (Green hat) — the newcomer / on-ramp. Not the typical entry point for purple-team work (per §6.2’s career-stage pattern), but Vol 9’s foundation-skill treatment is the prerequisite ladder that practitioners climb before reaching the red or blue specializations that feed into purple.
- Vol 10 (Blue hat) — the defender half of the purple-team integration. Vol 10 §8.2 is the blue-side forward-pointer to this volume; the integration practice’s blue-side context (the detect/triage/respond/hunt loop, the detection-engineering function, the SIEM/EDR tooling) is treated at depth in Vol 10. The four-phase loop diagram in Vol 10 §4 and the detection-engineering integration in Vol 10 §3.5 are the structural foundations that purple-team work builds on.
- Vol 11 (Red hat) — the offensive half of the purple-team integration. Vol 11 §8.2 is the red-side forward-pointer to this volume; the integration practice’s red-side context (the engagement lifecycle, the C2 framework operation, the MITRE ATT&CK Navigator as the shared artifact, the assumed-breach starting condition, the engagement-coordinator function, the purple-team transition in Vol 11 §4.7) is treated at depth in Vol 11. The §4.7 purple-team transition is the foreshadowing that this volume’s §4 expanded into the full exercise loop.
- Vol 1 §3 — the decision graph for navigating the series; the hat-spectrum table from which Vol 12’s position derives.
- Vol 5 §5.4 — the chronological emergence of purple via FireEye/Mandiant 2013-2015 and SANS SEC599 2016. §2 of this volume carried the chronological framing forward to 2026; Vol 5’s broader chronological framing was the foundation.
- Vol 5 §6 — the two-axis problem that locates purple-team work on Axis 2 (engagement-role) as the integration practice that combines red-team and blue-team positions on the same axis.
- Vol 5 §8 — the master taxonomy diagram that locates the seven hats together; this volume closes the seven-color treatment.
The cluster’s overall structural arc: white-and-black establish the ethical-stance axis (Vols 6-7); grey-and-green fill in the corners (Vols 8-9); blue-and-red establish the engagement-role axis on the authorized side (Vols 10-11); purple closes the integration practice that connects them (this volume). The next phase of the deep dive turns to the reference cluster (Vols 13-17), the careers and legal synthesis (Vols 18-19), and the cheatsheet and glossary (Vols 20-21). The hat cluster’s structural treatment is complete.
8.5 Cross-tool references — where purple-team practice validates the rest of the Hack Tools hub
The purple-team practice’s tooling overlap with the Hack Tools hub’s broader coverage is more selective than the red-team’s (Vol 11 §8.4) — purple-team work is primarily software-and-cloud-environment-focused, with the physical-entry RF/HID staging layer that Vol 11 walked typically not exercised in purple-team format. The cross-tool references that do apply:
- WiFi Pineapple — rogue-AP detection validation.
../../WiFi Pineapple/03-outputs/WiFiPineapple_Complete.html. The Pineapple’s role in purple-team work is the red-side of a wireless-detection purple-team exercise: red executes a rogue-AP / KARMA / evil-twin attack via the Pineapple; blue observes whether the wireless IDS detects the deployment; the resulting gap (if any) becomes detection-rule authoring work. Vol 10 §3.7 walked the defensive-side wireless tooling; Vol 11 §3.6 walked the offensive-side; this volume’s purple-team practice integrates the two. - Ducky Script — HID-injection detection validation.
../../Ducky Script/03-outputs/DuckyScript_Complete.html. The Hak5 implant family (USB Rubber Ducky, Bash Bunny, Key Croc, O.MG Cable/Plug/Adapter) is the red-side of a HID-injection purple-team exercise: red deploys an implant via a controlled test (typically a sanctioned lab environment rather than production); blue observes whether the EDR’s HID-enumeration alerting fires; the resulting gap becomes detection-engineering work. The Ducky Script deep dive’s Vol 14 (combined-workflow patterns) is the canonical reference for the implant-deployment workflow that the purple-team exercise validates against. - HackRF One — SDR-based purple-team scenarios.
../../HackRF One/03-outputs/HackRF_One_Complete.html. The HackRF’s role in purple-team work is the red-side of an SDR-based detection-validation scenario: red executes a wideband RF transmission (e.g., a specific protocol-replay against a target device class); blue observes whether the RF-monitoring instrumentation detects the transmission. RF-side purple-team work is rarer than computer-side purple-team work because the corresponding blue-side instrumentation (wireless IDS, RF spectrum monitoring) is less commonly deployed; the exercises are typically scoped to specific high-stakes-environment contexts.
The cross-tool refs are sparser for purple-team work than for red-team work because purple-team practice is structurally focused on the IT-side detection-engineering integration; the physical-entry and RF-spectrum work that the Hack Tools hub covers heavily is more often a red-team-engagement subject than a purple-team-exercise subject. The exception is the wireless-detection scenario, where the WiFi Pineapple’s adversary capability and the corresponding wireless-IDS deployment make the integration practice tractable; the other RF and physical-entry cross-tool work is typically Vol 11-territory rather than Vol 12-territory.
8.6 Cheatsheet bullets — Vol 20 candidates
The following one-liners are the load-bearing rules of the purple-hat, destined for Vol 20’s laminate-ready synthesis:
- Purple is a verb, not a noun. Purple-team is what an organization does, not (primarily) what a person is. Build the practice, not the headcount.
- Purple is the integration of red and blue. The practice’s value is the structural feedback loop that converts adversary-emulation findings into validated detection rules; without the loop closure, the work is incomplete.
- The four engagement modes are not mutually exclusive. Transparent (training, deep-dive), Coordinated (modal monthly), Adversary-emulation (semi-annually, realistic test), Continuous BAS (daily, regression). Mature programs run multiple modes simultaneously on different cadences.
- The exercise’s deliverable is the validated detection rule, not the report. The rule fires correctly on re-execution; the rule’s authoring is incomplete until the re-validation step confirms it.
- The “detection coverage” metric is the load-bearing program-management indicator. Most organizations cover 20-30% of their relevant ATT&CK technique catalog as of 2026. The longitudinal trajectory is the more-informative view than any single measurement.
- Purple-team exercises validate detection coverage; adversary-emulation engagements validate analyst vigilance. The two are different. Run both, on different cadences, with the exercises explicitly focused on the rule-firing question.
- Atomic Red Team is the canonical narrow-TTP execution library. Casey Smith and Michael Haag, Red Canary, October 2017. The PowerShell-execution wrapper (Invoke-AtomicTest) and the YAML-test-format are the framework’s stable architecture.
- CALDERA is the canonical open-source automated adversary-emulation platform. MITRE, 2017. The BAS-platform commercial alternatives are AttackIQ / SafeBreach / Cymulate / Pentera.
- VECTR is the canonical purple-team exercise-tracking platform. Security Risk Advisors, 2018+, Community Edition free, Enterprise Edition commercial.
- Sigma is the canonical platform-agnostic detection-rule format. The exercise’s authored rules are the deliverable; Sigma’s portability across SIEM platforms is the value.
- SANS SEC599 + SEC699 is the canonical purple-team curriculum. Erik Van Buggenhout (NVISO) is the lead author; the courses cover the curriculum that the field’s practitioner training is substantially built on.
- MITRE ATT&CK Defender (MAD) is the ATT&CK-fluency credentialing program. Now operated by MAD20 Technologies; $499/year individual subscription.
- Most purple-team practitioners come from either red or blue, not directly. The “5-10 years red or blue → purple” pattern is the modal career arc; entry-level direct-to-purple is rare.
- The four specialization paths are detection-engineering-lead, adversary-emulation-with-handoff, BAS-platform-engineer, and purple-team-consulting. Each requires demonstrated depth in both red-team and blue-team work; the specialization is in which side of the integration provides primary leverage.
9. Resources
The footnoted bibliography for this volume. Sources organized by category for easier scanning.
Cross-volume references (the load-bearing structural anchors):
SANS curriculum and the MITRE ATT&CK Defender program:
Atomic Red Team origin and current stewardship:
CALDERA and the BAS platform market:
VECTR exercise-tracking platform:
Famous-figure primary sources:
Detection-coverage metric and industry surveys:
Cross-volume references (this series):
- Vol 1 §3 — the decision graph for navigating the series; the hat-spectrum table from which Vol 12’s position derives.
- Vol 5 §5.4 — the chronological emergence of purple via FireEye/Mandiant 2013-2015 and SANS SEC599 2016. Foundation for §2.
- Vol 5 §6 — the two-axis problem locating purple-team work on Axis 2 as the integration practice.
- Vol 5 §8 — the master taxonomy diagram closing the seven-color treatment.
- Vol 6 §1 — white-hat authorization-paperwork stack. Foundation for §1’s authorization framing.
- Vol 7 §3 — black-hat toolchain. Foundation for §3’s dual-use principle.
- Vol 10 §3 — blue-hat defender toolchain (SIEM/EDR/detection-engineering/threat-intel/IR/forensics/RF-defensive). Foundation for §3 (blue-side tooling).
- Vol 10 §3.5 — the detection-engineering function and Sigma. Foundation for §3.4 and §4.4.
- Vol 10 §4 — the detect/triage/respond/hunt loop. Foundation for §4’s integration-loop framing.
- Vol 10 §8.2 — the blue-side forward-pointer to this volume. Symmetric pointer that §8.4 answers.
- Vol 11 §3 — red-team toolchain (C2 frameworks, AD attack, initial access, lateral movement, post-exploitation, physical RF/HID). Foundation for §3 (red-side tooling).
- Vol 11 §4 — the red-team engagement lifecycle. Foundation for §4’s exercise-lifecycle structural template.
- Vol 11 §4.3 — MITRE ATT&CK as the engagement’s structural backbone. Foundation for §3.3 and §4.3.
- Vol 11 §4.7 — the purple-team transition as the engagement’s post-engagement workflow. Foreshadowing that §4 of this volume expanded into the full exercise loop.
- Vol 11 §8.2 — the red-side forward-pointer to this volume. Symmetric pointer that §8.4 answers.
- Vol 16 (Computer-hacking tradecraft) — pending Phase 3 authoring. The engineering depth on offensive-and-defensive computer-hacking tooling lives there; the purple-team integration practice that validates the corresponding detection coverage is treated at depth in this volume.
- Vol 17 (Social engineering tradecraft) — pending Phase 3 authoring. The phishing-driven initial access that purple-team exercises sometimes validate the detection of lives there.
- Vol 18 (Careers) — pending. The career synthesis across all the hats; §6 of this volume is the purple-team-specific cut, Vol 18 will walk the full picture.
- Vol 19 (The legal line and ethics) — pending. The CFAA framing for authorized-defensive work, the legal posture of cross-organization investigations, the data-protection geometry for SIEM-and-detection content; all of these constrain purple-team work as much as they constrain pure red or pure blue work.
- Vol 20 (Cheatsheet) — pending. §8.6’s bullets are the candidate set for the purple-hat row in the laminate-ready cheatsheet.
- Vol 21 (Glossary and canonical anchor index) — pending. The seven-hat cluster’s anchors (Vols 6-12) will be the load-bearing canonical-index entries; the cluster’s structural completeness as of this volume makes the index work tractable.
Footnotes
-
Daniel Miessler, “Purple Team Pentests Mean You’re Failing at Red and Blue” (2019), arguing that the existence of a purple-team category indicates inadequate baseline integration between red and blue functions. The essay is referenced as the canonical critique of the purple-team-as-product framing; the working vocabulary has not adopted the critique as a corrective. Miessler’s Unsupervised Learning podcast and newsletter (https://danielmiessler.com/; newsletter at https://newsletter.danielmiessler.com/) carry his broader cybersecurity-and-technology commentary as of early 2026. ↩
-
SANS Institute, SEC599: Defeating Advanced Adversaries — Purple Team Tactics and Kill Chain Defenses. Lead author: Erik Van Buggenhout. Course home: https://www.sans.org/cyber-security-courses/defeating-advanced-adversaries-kill-chain-defenses. Launched 2016; substantially updated 2025-2026 with AI-enabled detection content, expanded purple-team labs, and Terraform-managed range infrastructure. The course carries the GIAC GDAT (Defending Advanced Threats) certification; ~$2,000 cert-only; ~$8,000 course-and-cert bundle. ↩ ↩2
-
SANS Institute, SEC699: Advanced Purple Teaming — Adversary Emulation and Detection Engineering. Lead author: Erik Van Buggenhout. Course home: https://www.sans.org/cyber-security-courses/purple-team-tactics-adversary-emulation. Premiered 2020. The course’s GIAC certification (GAPT — Advanced Purple Teaming) is emerging from the curriculum; verify the cert’s exact name and pricing on the SANS GIAC site (https://www.giac.org/) as the program continues to evolve. ↩ ↩2
-
MITRE ATT&CK Defender (MAD) program. As of late 2023, MITRE Engenuity spun the MAD credentialing program out to MAD20 Technologies, which operates it as part of MAD20’s core product offering (https://mad20.com/). MAD covers four primary credentialing tracks: Adversary Emulation, Cyber Threat Intelligence, SOC Assessment, and Threat Hunting. Individual subscription ~$499/year; some foundational content remains free via Cybrary. MITRE Engenuity’s announcement of the MAD20 partnership: https://www.mitre.org/news-insights/news-release/mitre-engenuity-teams-mad20-technologies-expand-mitre-attck-defender. ↩ ↩2 ↩3
-
Atomic Red Team (Red Canary, 2017+). Project home: https://github.com/redcanaryco/atomic-red-team. Casey Smith and Michael Haag are the co-creators; the project was originally named Bookish-Happiness in summer 2017 and was publicly released at the Carbon Black User Exchange in October 2017 with approximately 75 tests. The PowerShell-execution wrapper (Invoke-AtomicTest) and the YAML-test-format architecture were added in 2018. The Red Canary blog post “One Year of Atomic Red Team! Looking Back and Ahead” documents the early-project history; the project’s continuous stewardship under the Red Canary team has continued through the project’s growth to approximately 1,500 tests by early 2026. ↩ ↩2 ↩3
-
MITRE CALDERA project home: https://github.com/mitre/caldera. First public release approximately 2017 (presented at Black Hat EU 2017). MITRE’s stewardship includes the CALDERA-for-OT extension (with CISA, focused on operational-technology environments) and continued framework development. Adjacent BAS-platform vendors: AttackIQ (https://attackiq.com), SafeBreach (https://safebreach.com), Cymulate (https://cymulate.com), Pentera (https://pentera.io); Prelude Operator (https://www.prelude.org) as the commercial CALDERA-derived alternative. ↩ ↩2
-
VECTR (Security Risk Advisors). Project home: https://github.com/SecurityRiskAdvisors/VECTR. VECTR Community Edition (free, open-source under Apache-2 license) and VECTR Enterprise Edition (commercial, launched August 2024). The platform’s documentation site: https://docs.vectr.io. SRA’s broader purple-team-services practice: https://sra.io/purple-teams/. ↩ ↩2
-
Detection-coverage metric surveys. Multiple 2024-2026 industry surveys (Picus Security’s Blue Report, Tidal Cyber’s Threat-Informed Defense Maturity benchmarks, the MITRE-Engenuity Center for Threat-Informed Defense working papers) consistently report enterprise detection coverage in the 20-30% range against the relevant MITRE ATT&CK technique catalog as of 2026. The coverage is structurally lower than the intuitive “we should detect everything” framing because of the catalog’s scale (196+ techniques and 440+ sub-techniques in the Enterprise matrix as of ATT&CK v15/v16) and the practical reality of detection-engineering resourcing. ↩
-
Erik Van Buggenhout. NVISO co-founder and Partner / Head of Managed Security Services (verify via https://www.linkedin.com/in/erikvanbuggenhout/). SANS Senior Instructor and lead author of SEC599 and SEC699 (verify via https://www.sans.org/profiles/erik-van-buggenhout). The “Instructor Spotlight” SANS blog post carries his self-narrative (https://www.sans.org/blog/qa-with-erik-van-buggenhout). RSAC Conference profile: https://www.rsaconference.com/experts/erik-van-buggenhout. Current-role claims carry “as of early 2026” qualifier. ↩ ↩2
-
SANS SEC599 update (2025-2026) covered in a SANS Offensive Operations announcement; the update includes AI-enabled detection content, expanded purple-team labs, Terraform-managed range infrastructure, and revamped tradecraft content. SANS Offensive Operations social: https://x.com/SANSOffensive. ↩
-
Daniel Bohannon, Invoke-Obfuscation (PowerShell obfuscation framework). Project home: https://github.com/danielbohannon/Invoke-Obfuscation. Released 2016; the canonical reference tool for PowerShell-payload obfuscation that adversaries use to evade signature-based detection. Subsequent projects Invoke-CradleCrafter and Invoke-DOSfuscation (Black Hat USA 2017 and Asia 2018 presentations). ↩
-
Daniel Bohannon, current role as of early 2026: Principal Threat Researcher on Permiso Security’s P0 Labs team. Verify via his website (https://www.danielbohannon.com/) and LinkedIn (https://www.linkedin.com/in/danielhbohannon/). Prior roles include incident-response consulting at Mandiant, security research at FireEye, and threat hunting at Microsoft. The 2026 P0 Labs research output includes Cloud Console Cartographer and the CVE-2026-26133 Microsoft Copilot prompt-injection research. Current-role claims carry “as of early 2026” qualifier. ↩ ↩2
-
Christopher Peacock, current role as of early 2026: Distinguished Engineer at Verizon (Readiness and Proactive Security team). SCYTHE’s team migrated into Verizon, and Peacock’s role transitioned accordingly; his prior title was Principal Detection Engineer at SCYTHE. Verify via his LinkedIn (https://www.linkedin.com/in/securepeacock/); the SCYTHE Library author page (https://scythe.io/library/author/christopher-peacock) reflects the prior affiliation. Profile attributes: author of the TTP Pyramid, Black Hat course author and instructor, Top-20 Sigma contributor, Top-10 LOLBAS contributor. Current-role claims carry “as of early 2026” qualifier. ↩ ↩2
-
Casey Smith, current role as of early 2026: Senior Security Researcher at Thinkst Applied Research. Co-creator of Atomic Red Team (with Michael Haag, October 2017 public release). Prior role at Red Canary as Director of Applied Research. Verify via Red Canary’s archive of Casey Smith’s content (https://redcanary.com/authors/casey-smith/) and Thinkst’s research publications. Current-role claims carry “as of early 2026” qualifier. ↩ ↩2
-
Michael Haag, current role as of early 2026: Principal Threat Research Engineer at Splunk. Co-creator of Atomic Red Team (with Casey Smith, October 2017 public release). Splunk Threat Research Team author page: https://www.splunk.com/en_us/blog/author/mhaag.html. Red Canary archive of his content: https://redcanary.com/authors/michael-haag/. Current-role claims carry “as of early 2026” qualifier. ↩ ↩2
-
Justin Henderson, current role as of early 2026: Founder and CEO of H&A Security Solutions; SANS Instructor and course author of SEC555 (SIEM with Tactical Analytics). Verify via SANS Edu profile (https://www.sans.edu/profiles/justin-henderson/), H&A Security Solutions site (https://hasecuritysolutions.com/about.html), and LinkedIn (https://www.linkedin.com/in/securitymapper). Current-role claims carry “as of early 2026” qualifier. ↩ ↩2