What Is Purple Team: Red and Blue Team Collaboration with MITRE ATT&CK

A Purple Team is not a separate third team: it is a way of working in which the offensive side (red) and the defensive side (blue) execute techniques together, with mutual visibility and in real time, to measure what gets detected and what slips through. The red side fires a technique from the MITRE ATT&CK catalogue; the blue side watches its telemetry; both compare what actually happened with what reached the analyst; the gap is identified; the rule is adjusted; the technique runs again to validate the fix. It is detection engineering with immediate feedback and, unlike a pure red team, here both teams sit in the same room. The outcome is a measurable improvement in detection coverage and in mean time to respond.

Key takeaways on Purple Team

• It is a collaborative methodology, not a team separate from red or blue.
• Coverage is measured against the MITRE ATT&CK framework, not by counting findings.
• It allows custom SIEM and EDR rules to be developed and validated against concrete techniques.
• Ideal for SOCs in evolution that want to know what they actually detect.
• Common frameworks: ATT&CK Navigator, Atomic Red Team, Caldera, VECTR.

What a Purple Team is, exactly

A Purple Team is a collaborative, guided exercise in which offensive and defensive professionals work side by side for a bounded period, usually between one and four weeks, to improve detection and response capability in a measurable way. The word "purple" comes from mixing red and blue and describes the dynamic literally: instead of measuring with the blue side in the dark, both sides agree on a catalogue of techniques, execute them in order and document step by step what reached the SIEM, what triggered an alert, what went unnoticed and what to adjust.

The question it answers is not "could we be compromised?" (that one is for a red team) but "what do we detect today of every technique a real attacker would use against us?". It is a shift of focus: from impact to coverage map.

In practice:

• A subset of the MITRE ATT&CK catalogue is selected, filtered by sector, platform (Windows, Linux, cloud) and active threats.
• The red side executes each technique under control, announcing command and timestamp.
• The blue side watches its stack (SIEM, EDR, XDR, network logs) and reports what arrived, what was visible and what was missed.
• Both sides analyse the root cause of each gap: missing telemetry, badly written rule, unparsed event, noise drowning the signal.
• The detection is developed or adjusted, the technique runs again, and the team validates that the alert now fires.

Origin and evolution of the Purple Team model

The term emerges in the cybersecurity community around 2015, popularised by SANS talks and by the consultancy FireEye, when SOCs were starting to see that their SIEM investments did not automatically translate into useful detections. The intuition was simple: if we only measure the blue side when a red team that wants to stay hidden shows up, we miss the chance to learn technique by technique.

From 2017 and 2018 onwards several factors accelerated adoption. MITRE ATT&CK provided a common language between offence and defence. Atomic Red Team put granular executable tests per technique within reach of any organisation. And European consultancies such as Tarlogic published open playbooks that normalised the format. Today the Purple model is essentially standard in mature corporate SOCs and fits with European frameworks that require proof of control effectiveness, such as NIS2 and DORA.

Purple Team vs red team vs coordinated exercise

These three formats get mixed up in tender documents. The distinction matters because it changes scope, cost and, above all, what you learn.

Quick rule: a red team tells you whether they can break in without you noticing; a Purple Team tells you what you detect of each technique and improves rules on the spot; a coordinated exercise validates a single scenario (for example, ransomware on a file server). If you have never run any of these, start with Purple; if you already have decent detections, go for red.

When to choose a Purple Team exercise

Three situations where Purple is the right answer:

• SOC in evolution that wants to measure real coverage. You have invested in SIEM and EDR but do not know what percentage of ATT&CK you actually detect. A Purple gives you that map and tells you which rules are missing.
• Need to develop custom rules. Detection engineering builds new use cases and needs to validate that they fire against real techniques, not theoretical simulations.
• Onboarding new technology. You just rolled out a different EDR, an XDR or an NDR and want to know what it really detects before trusting the vendor's marketing.

It also works as a step prior to a red team. If your blue side has never faced lateral movement, Kerberoasting or EDR evasion, taking them straight into a six-week red team usually ends in frustration. A Purple Team makes no sense if there is no defensive team, internal or external, capable of operating detections: without a blue side there is nobody to collaborate with.

Typical workflow of a Purple Team exercise

The usual structure of a professional Purple Team moves through five recognisable phases:

1. Scoping and technique selection. The most relevant MITRE ATT&CK techniques are selected by sector, platform and active threats. For a European financial client, techniques used by groups such as FIN7, Carbanak or Lazarus. For an industrial client, techniques associated with human-operated ransomware. The catalogue usually holds between 20 and 60 techniques.

2. Telemetry preparation. Before executing anything, the team verifies that the blue side has the minimum telemetry in place: Sysmon on key endpoints, advanced Windows auditing, PowerShell logging, EDR integrated with SIEM, network logs at relevant points. Without this, execution is blind.

3. Execution and observation. The red side runs each technique under control and notifies the blue side, which watches its stack. The blue side reports whether the event reached the SIEM, whether an alert fired, whether the EDR caught it and whether the analyst would actually have seen it among the noise.

4. Gap analysis. After each technique both teams analyse together. If there was no detection, the root cause is identified: missing event at source, badly written rule, excessive noise or unparsed field.

5. Detection development and retest. The rule is adjusted or created, the technique runs again and the team validates that it now fires. Each cycle closes with one deliverable: a validated rule ready for production. The closing of the exercise includes a report with the ATT&CK matrix marked (detected, partial, not detected) and the list of new or adjusted rules.

Fundamental frameworks for Purple Team

There are four or five tools that any Purple Team practice uses almost always, and they are worth knowing to understand proposals and deliverables.

MITRE ATT&CK Navigator. Visual layer over the ATT&CK framework. It allows building maps (layers) with colours indicating coverage per technique. The standard deliverable includes a layer exported in JSON the client can maintain over time. See our MITRE ATT&CK guide.

Atomic Red Team. Project maintained by Red Canary gathering atomic tests tied to each ATT&CK technique. Every test is a concrete command or script that runs the technique in its minimal form. The library exceeds thousands of tests and is versioned on GitHub.

MITRE Caldera. Automated adversary emulation platform maintained by MITRE. It allows defining adversaries (combinations of techniques) and running complete chains with agents deployed on target machines. Useful for complex scenarios that go beyond an isolated atomic test.

VECTR. Tracking tool designed for Purple Team exercises. It records each technique tested, the detection result, the rules created, the owner and validation status. It is the difference between a scattered spreadsheet and a historic repository of coverage per technique.

PurpleSharp. Framework in .NET that runs adversary techniques in Windows environments. It provides specific coverage on Active Directory, Kerberos, LSASS and lateral movement in domains. It complements Atomic Red Team in corporate Windows environments. The usual approach is to combine Atomic Red Team or PurpleSharp for execution, ATT&CK Navigator for the map and VECTR for tracking.

Measurable metrics in a Purple Team exercise

A reason the model has spread is that it produces hard metrics, not just impressions. The ones most frequently seen in serious reports:

• Detection coverage: percentage of tested techniques detected, expressed as a map over the ATT&CK matrix. Main indicator, comparable between exercises.
• MTTD (Mean Time To Detect): average time between execution and first alert in SIEM or EDR. Per technique and aggregate.
• MTTR (Mean Time To Respond): average time from alert to containment (endpoint isolation, account disabling).
• False positive rate: how many legitimate alerts are noise after new rules. A rule that detects 100 percent but fires 200 false positives a day is not useful.
• Alerts per analyst per shift: SOC operational load. A well-run Purple reduces noise without losing coverage.

Ideally compared between successive exercises. A semi-annual or annual Purple lets you see real progress and justify investment to leadership.

Common use cases for Purple Team

The Purple exercises we see most often fall into five scenarios:

• Validating a new EDR or XDR investment. You just switched EDR vendor and want to know, before trusting the demo, what it really detects. A short Purple over key techniques answers without waiting for the first incident.
• Onboarding and training new analysts. Watching the red side execute the technique, observing the event in the SIEM and understanding why the rule fires or not accelerates learning by months compared to theoretical training.
• Compliance pre-audit. Ahead of an NIS2 audit or DORA follow-up, a Purple lets you document objective evidence that controls are tested, an explicit requirement in both regimes.
• Post-incident lessons learned. After a real incident, replaying attacker techniques in Purple format closes identified gaps in a structured way.
• SIEM tuning regression. When you switch SIEM, upgrade the engine or migrate to cloud, a Purple acts as functional regression: confirming that detections that worked still work.

Common mistakes in Purple Team exercises

Purple exercises that go wrong fail in recognisable patterns:

• Scope too wide. Trying to cover a hundred techniques in a week guarantees superficial execution and zero retest. Better twenty techniques well than a hundred badly.
• Executing without measuring. Running techniques like a script without documenting what each one detected turns the exercise into theatre. Without a final matrix there is no aggregate learning.
• No retesting after the fix. Creating the rule, assuming it works and moving on leaves invisible gaps. Retesting separates Purple from blind detection engineering.
• Blue team in defensive mode. If the blue side feels evaluated and hides gaps, the exercise breaks. The sponsor (CISO) has to make clear that the goal is collective improvement, not individual examination.
• Insufficient telemetry. Starting without verifying Sysmon, advanced Windows auditing or SIEM integration leads to wrong conclusions: it looks like nothing is detected when nothing is being observed.
• Not maintaining the result over time. An isolated Purple loses value if deliverables are not versioned and revalidated six months later, when the environment has already changed.

Regulatory fit of Purple Team

Several European frameworks require, explicitly or implicitly, proof of control effectiveness and objective evidence. Purple Team fits well in that gap:

• NIS2, article 21. Measures for essential and important entities include regular testing of the effectiveness of technical and organisational measures. A periodic Purple evidences that compliance.
• DORA, article 24. Financial entities must run basic and advanced operational resilience testing. Without reaching the TLPT level (intelligence-led red team), a Purple serves for the basic tests and prepares maturity ahead of the TLPT.
• ISO/IEC 27001:2022, control A.5.35. The independent review of information security includes reviewing the effectiveness, not just the existence, of controls. A Purple provides clear technical evidence.
• ENS. The periodic verification of security measures set out by ENS also fits with the Purple mechanic when applied to in-scope systems.

Documenting the exercise with an exported ATT&CK matrix, the rules created and pre/post metrics turns it into auditable evidence reusable in ISO 27001 audits or NIS2 follow-ups.

Frequently asked questions about Purple Team

Do I need my own SOC to run a Purple Team?

It is not essential. If your defence is outsourced to an MSSP, the exercise can be run if the MSSP agrees to participate and dedicates hours to observe telemetry and tune rules during sessions. What is essential is someone with access to the SIEM and the EDR being in the room. Without that piece, there is no exercise.

How long does a typical Purple Team exercise take?

Between one and four weeks depending on scope. A Purple focused on a concrete scenario (for example, techniques of a specific ransomware family) can close in five days. A broad Purple covering several ATT&CK tactics over Windows and cloud usually moves in three or four weeks, with execution sessions interleaved with detection development.

How much does it cost compared to a red team?

Substantially less. As a public sector reference, an average European Purple Team runs between 15,000 and 50,000 euros, versus the usual 40,000 to 150,000 euros for a full-scope red team. The difference is explained by shorter duration, no long OSINT phase, and the collaborative nature that does not require dedicated offensive infrastructure.

Is it realistic to cover 100 percent of the ATT&CK matrix?

No, and nobody serious aims for that. The matrix contains hundreds of techniques with multiple variants. The goal is to cover the techniques relevant to your sector and environment. A good Purple selects techniques associated with the APT groups active against your vertical and prioritises by likelihood and impact.

Is there an industry favourite tool?

For execution, Atomic Red Team is essentially standard. For tracking, VECTR is the most widespread option in consultancies. For coverage visualisation, ATT&CK Navigator has no practical rival. What matters is not the tool but documenting every step and keeping the deliverable alive over time.

How often should detections be retested?

Critical detections are ideally retested every time the EDR or SIEM version is updated or the environment changes (cloud migration, new Active Directory domain, deployment of new services). As a minimum cycle, a semi-annual review of the rules from the previous Purple separates living detection from obsolete detection. Environments and attackers change, and a rule that worked a year ago may have stopped working without anyone noticing.

Related resources

• What Is a Red Team: Complete Business Guide
• Penetration Testing vs Red Team: Practical Differences
• What Is MITRE ATT&CK: Tactics and Techniques
• EDR vs XDR vs MDR: Comparison
• What Is Threat Hunting: Methodology
• Active Directory Pentesting and Tier Model

Purple Team with Secra

If your organisation has its own or outsourced SOC and you want to know what real percentage of the relevant techniques it detects today, a Purple Team is the most efficient way to get that answer and, at the same time, leave the SOC better prepared than it was. At Secra we design Purple exercises aligned with MITRE ATT&CK, integrating Atomic Red Team and VECTR as versionable deliverables you can maintain over time. If it fits your pipeline, let's talk and we will frame the scope; if we are not the right fit, we will tell you which sector provider to approach and why.