Red Team and Purple Team Exercises: Using Threat Intelligence to Simulate Real Adversaries

Red Team and Purple Team Exercises: Using Threat Intelligence to Simulate Real Adversaries

Red team and purple team exercises that are driven by threat intelligence simulate the tactics, techniques, and procedures (TTPs) of real adversaries, so defenders can measure how their people, processes, and technology actually perform when a known threat actor comes knocking. This article presents an original benchmark analysis of how organizations turn intelligence reports into executable TTP-based attack plans, and it provides a practical framework you can copy.

This analysis is a qualitative benchmark, not a quantitative survey. It draws on three practitioner sources: a step-by-step process for developing attack plans from threat intelligence, published by Security Risk Advisors; a SANS Institute guide to running a first purple team exercise using a public TTP report; and a SANS Institute framework for continuous security validation using adversary emulation tools. No reliable quantitative dataset on exercise frequency, cost, or detection rates was available in these sources, so this article does not invent one. Instead, it benchmarks the processes that make adversary simulation repeatable and measurable.

The table below summarizes the benchmark metrics this article evaluates across the three source workflows. A reader who extracts only this table gets the core comparison: the maturity difference between one-off exercises and a continuous purple team operating loop.

Key Findings Summary

The single biggest differentiator between one-off adversary simulation and a mature purple team program is whether threat intelligence is translated into reusable test content. Every source in this benchmark describes translation as the hard part: collecting a report is easy, but extracting TTPs and turning them into executable test cases is what determines whether the exercise produces defensible improvement.

The key findings are:

• Threat-intelligence-driven scoping beats generic TTP testing when a specific actor is a likely threat. If a threat actor is likely to target the organization, focusing on the TTPs they have been observed using — and the TTPs they are likely to use — makes sense for determining whether security controls work against that actor.
• Generic TTP reports are the recommended starting point for organizations without a threat intelligence function. Selecting frequently used, non-advanced behaviors makes the first purple team exercise achievable for a red team to emulate.
• A one-time red team assessment is raw material, not an endpoint. The most valuable output of a red team engagement is the set of TTPs and successful attack chains, which can be mapped into an emulation tool and replayed on a schedule.
• Tooling choice is downstream of process. One source manages test case content in MITRE's open-source Market Maker according to its schema; another uses CALDERA to schedule continuous simulations. The tool matters less than whether TTPs are mapped and stored.
• The people-and-process dimension is not optional. The stated purpose of the first exercise is not only technology but also collaboration between teams and processes.

How Does Threat Intelligence Become an Executable Attack Plan?

Converting intelligence into an attack plan follows a recognizable pipeline: scope the collection, gather reports, analyze them for TTPs, then assemble the attack plan and supporting resources. Each stage reduces a broad intelligence picture into something a red team can execute and a blue team can detect.

The first stage, scoping intelligence collection, is where most programs quietly fail. Instead of collecting everything, the analyst defines which actor or threat matters and limits collection to that scope. A ready-made attack plan for that actor may not exist, which is precisely why analysts need to learn how to build their own intelligence-based test plans.

The analysis stage is the translation core. Reports are reviewed for the adversary's tactics, techniques, and procedures — the how of an intrusion, as distinct from indicators of compromise, which are the what left behind. TTPs describe behavior. Behaviors survive infrastructure changes; IP addresses and file hashes do not. That distinction is why intelligence-driven adversary simulation maps to the MITRE ATT&CK framework rather than to an indicator blocklist.

Featured answer: Threat-intelligence-driven red team and purple team exercises work by scoping collection to a likely threat actor, extracting their TTPs from reports, mapping those TTPs to MITRE ATT&CK, and assembling them into an executable attack plan. The plan is then run against production defenses while defenders watch, so control efficacy is measured against behaviors real adversaries actually use.

Once intelligence is reviewed, the extracted information becomes test cases. How test cases are stored depends on how they will be executed; one published approach uses MITRE's open-source Market Maker to manage test case content and develops new test cases in accordance with its schema. This is a small detail with large consequences: a test case stored in a structured schema is reusable, versionable, and shareable. A test case written into a slide deck is not.

What Is the Difference Between a Red Team and a Purple Team Exercise?

A red team exercise is an adversarial assessment in which a red team emulates an attacker against a pre-defined scenario. A purple team exercise is the collaborative layer that sits on top of adversarial testing: red and blue work the same technique at the same time, and the emphasis falls as much on team collaboration and process as on technology.

This distinction is commonly blurred, and blurring it causes real measurement failure. In a pure red team engagement, the deliverable is a report describing techniques used and which attack chains succeeded. The blue team often reads that report weeks later. In a purple team exercise, the desirable state is that the red team shares their screen so everyone sees the execution in real time, and techniques can be run one at a time or in sequence. Detection engineering happens in the room, not in a retrospective.

The purple model also changes what "success" means. A red team succeeds when it evades detection. A purple team exercise succeeds when it produces an accurate, jointly verified answer to the question: did our controls see this, and if not, why not? That reframing is what makes purple teaming a continuous improvement loop rather than a scoreboard.

For organizations connecting this work to broader detection operations, the same intelligence that fuels adversary simulation should also feed hunting. The techniques in Threat Hunting Techniques Using Intelligence Feeds are the natural downstream consumer of a TTP library built during purple teaming, and pairing the two avoids duplicating intelligence work across teams.

Detailed Results: Benchmarking the Three Source Workflows

The Intelligence-Priority Path

When a specific threat actor is a likely threat, prioritization is straightforward: test what that actor does. The rationale is that focusing on the TTPs the actor has been observed using, and the TTPs they are likely to use, determines the efficacy of the organization's controls against that actor.

This path delivers the highest relevance per test and the highest analyst cost. It requires scoping, collection across reports, and manual analysis. If a given actor's TTP set is small or poorly documented in open reporting, the pipeline stalls — a real limitation that argues for maintaining a secondary generic path in parallel.

The Generic-TTP Path

The generic path inverts the logic. Rather than starting from an actor, it starts from what adversaries do most often. One published approach uses an annual threat detection report — Red Canary's 2022 Threat Detection Report — and selects the most observed TTPs of the past year as the basis for a first purple team exercise. These TTPs are used frequently and are not very advanced for a red team to emulate.

The Red Canary report is useful here because it provides MITRE ATT&CK mapping for each behavior and organizes content into analysis, visibility, collection, detection, and testing sections. That structure effectively pre-packages the translation work: the analyst inherits the ATT&CK mapping instead of producing it.

The tradeoff is precision. Frequently observed TTPs may not correspond to the actors most likely to target a specific organization. This path works best as a starting point for teams without an internal cyber threat intelligence function, or for a newly formed one.

The Continuous-Validation Path

The third workflow treats a completed red team assessment as the seed for an ongoing program. After the assessment, a debriefing workshop is typically held or detailed reports are provided, outlining the techniques used and which attack chains succeeded. That information is then used to transform a one-time red team assessment into a continuous purple teaming effort.

The mechanism is mapping. Identified TTPs are mapped to specific "abilities" in an adversary emulation tool, which reconstructs the entire attack chain the red team used. With those details defined, regular simulations of the same scenarios can be scheduled — for example, using an open-source framework such as CALDERA. Multiple strategies exist for using such an automation framework for continuous assessments of infrastructure, including researching techniques used by known adversaries.

Visualizing the Maturity Curve

Chart description: A three-stage ascending line chart showing program maturity on the Y axis against time on the X axis. Stage 1 is a single red team engagement producing a report. Stage 2 is a first purple team exercise using a generic TTP report. Stage 3 is a scheduled, tool-driven simulation of mapped attack chains. The chart's central claim is that value compounds only at Stage 3, because Stages 1 and 2 produce findings while Stage 3 produces recurring evidence that controls still work.

Analysis by Category

Category 1: Intelligence Sourcing and Scoping

The benchmark reveals two sourcing models operating side by side. Actor-specific sourcing starts from a named threat and scopes collection accordingly. Population-level sourcing starts from aggregate observed behavior, such as an annual report of most-observed TTPs.

These are not competing philosophies; they answer different questions. Actor-specific sourcing answers, "Are we ready for this adversary?" Population-level sourcing answers, "Are we ready for common adversary behavior?" An organization that can only run a few exercises per year will get more value from the actor-specific question if it has credible intelligence about which actor is most likely to target it. An organization without that intelligence gets more value from the population-level question because it can start immediately.

One nuance practitioners should weigh: the population-level approach explicitly selects frequently used, non-advanced TTPs so the exercise is achievable. That makes it a poor test of resilience against sophisticated, targeted adversaries. Treat it as a baseline hygiene check, not a worst-case evaluation.

Category 2: Translation and Test-Case Management

Translation is the category where programs differentiate. The published pipeline is explicit: scope collection, collect reports, analyze reports for TTPs, assemble the attack plan and related resources. Test-case storage is a deliberate design decision tied to execution method, and structured schemas such as Market Maker's exist for that reason.

There is a practical implication most teams miss: if test cases live in a schema, the same content can drive manual purple team sessions and automated emulation runs. That is the bridge between the first purple team exercise and continuous validation. Teams that skip structured storage end up rebuilding test content every cycle.

Category 3: Execution and Collaboration Model

The execution model separates red from purple. A red team runs its pre-defined scenario and reports afterward. A purple team runs techniques with the blue team watching, one TTP at a time or as a sequence, sharing the attacker's screen so execution is visible to everyone.

The collaboration model is a design constraint, not a courtesy. Because the exercise explicitly targets team collaboration and processes alongside technology, a purple team session fails if the blue team is absent or passive. The observable output — a technique executed, a detection confirmed or missed, a gap logged — only materializes when both sides are in the same channel at the same time.

Category 4: Continuity and Automation

Automation converts findings into recurring assurance. Mapping TTPs to emulation-tool abilities reconstructs the full attack chain, and scheduled simulation runs turn a one-time assessment into a repeatable test. CALDERA is cited as one framework for continuous assessment of infrastructure, with multiple strategies available, including research into known-adversary techniques.

Automation has a maintenance cost that sources imply but do not quantify: abilities must be updated as tooling and environments change, or scheduled simulations will test yesterday's attack chain. Teams should plan for periodic re-mapping, not set-and-forget scheduling.

For organizations operationalizing this output at scale, the integration patterns in Integrating Threat Intelligence with SIEM and SOAR Platforms are relevant, because detection gaps found during purple teaming need to flow into the same platforms that handle the rest of the intelligence lifecycle.

Recommendations

1. Choose your starting path deliberately.

If you have credible intelligence naming a likely threat actor, build an actor-specific attack plan through the scope-collect-analyze-assemble pipeline. If you have no internal threat intelligence function, or it is new, start from a public TTP report with ATT&CK mapping and select frequently used, non-advanced behaviors.

2. Store test cases in a structured schema from day one.

Adopt a schema such as Market Maker's and develop new test cases against it. The cost is upfront discipline; the payoff is reuse across manual and automated execution.

3. Run the first exercise purple, not red.

Share the red team's screen so everyone sees execution in real time, and work one TTP at a time. Treat the collaboration between teams and processes as a first-class objective alongside technology.

4. Convert every red team engagement into emulation content.

Hold the debriefing workshop or produce the detailed report, then map the techniques used and the successful attack chains to abilities in your emulation tool. This is the single highest-leverage step for turning a point-in-time assessment into continuous validation.

5. Schedule simulations, then maintain the mapping.

Use an automation framework to run regular simulations of the reconstructed attack chains. Calendar the simulation runs, and calendar a review of the ability mappings themselves, because stale mappings produce false assurance.

6. Tie exercise output to the rest of the intelligence lifecycle.

The TTPs you validate in purple teaming should feed detection engineering, hunting, and platform integration. A structured program — see Building a Threat Intelligence Program: A Step-by-Step Guide — keeps exercise findings from becoming another orphaned report.

Conclusion

Threat-intelligence-driven red team and purple team exercises are a translation problem before they are a technology problem. The benchmark across these practitioner workflows shows a consistent three-stage progression: ad hoc red team assessments produce reports, first purple team exercises produce joint detection findings, and continuous purple teaming produces recurring proof that controls still work. The movement from stage to stage depends on structured test-case storage and on mapping exercises to emulation-tool abilities.

Three ideas are worth carrying forward. First, the question that determines your starting path is whether you know which actor is likely to target you; if you do, scope to that actor, and if you do not, start from frequently observed TTPs and accept the precision tradeoff. Second, purple teaming is defined by real-time collaboration, not by the color of the team running the tooling — if the blue team is not watching the execution, you are running a red team exercise. Third, the value of a red team engagement is realized only when its attack chains are mapped and replayed on a schedule.

The next step is organizational, not technical. Pick one path, run one exercise end to end, and store the results in a schema you can automate later. The teams that do this once tend to have a second exercise already scheduled — and that scheduling habit, more than any tool, is what separates a mature adversary simulation program from a periodic checkbox.