For years, the cybersecurity industry operated according to a clearly defined division of roles: the red team attacks, the blue team defends, and the results of both sides end up in a report that gets filed away on a shelf. This model has its own logic — simulating a real attacker requires isolation so that the blue team does not know what is coming or when. Yet that same isolation becomes a systematic brake on progress. The red team discovers weaknesses that the blue team cannot see, while the blue team implements detection rules without knowledge of how real attackers actually operate. The result? The organization walks away from the exercise richer by a report but poorer by the opportunity to genuinely improve its defensive capability.
Purple teaming is the answer to this dysfunction. It is not a third team category — it is a collaboration model in which offense and defense operate simultaneously, share observations in real time, and jointly verify whether a specific attack technique is detected, blocked, and correctly reported. The outcome is not a report — it is a measurable increase in the organization’s detection maturity, technique by technique, following a structured MITRE ATT&CK map.
What is purple teaming and how does it differ from classic red/blue team testing?
Purple teaming is a security testing methodology in which the red team and blue team collaborate in real time to evaluate and improve the effectiveness of an organization’s detection and response mechanisms. The name comes directly from mixing colors — red (red team) and blue (blue team) — and represents a fusion of offensive and defensive perspectives.
The classic red team operates in black-box style: it simulates a real attacker, conceals its actions, applies evasion techniques, and measures success by the number of compromised systems and the data it accessed. The final report reaches the blue team weeks or months after the exercise. The blue team then learns that it was compromised, but often does not know why its SIEM rules were silent or how a specific technique appeared in the logs. The knowledge gap remains — and the entire cycle repeats itself at the next test.
Purple teaming reverses this dynamic. Instead of full isolation, the exercise is conducted as a series of coordinated sessions. The red team executes a specific attack technique and immediately notifies the blue team: “I just executed technique T1059.001 — PowerShell Execution — on host WORKSTATION-04. Check whether you can see this event in the SIEM.” The blue team reviews the logs, analyzes whether the detection fired, identifies missing telemetry data, and adjusts rules on the fly. The red team then executes the next technique.
Flashcard: Red team vs. Blue team vs. Purple team
- Red team — simulates the attacker under isolation conditions. Measures the ability to break through defenses.
- Blue team — monitors the environment, responds to alerts, manages incidents. Measures detection and response time.
- Purple team — combines both approaches in an iterative feedback loop. Measures ATT&CK coverage and detection improvement over time.
The key difference lies in the objective. The red team answers the question: “Can an attacker get in?” The purple team answers the question: “When an attacker gets in — do we see it?” This is a subtle but fundamental shift in perspective. Organizations that regularly conduct purple team exercises stop asking about the mere fact of a breach and begin asking questions of maturity: what percentage of ATT&CK techniques do we have covered by detection? Where are our biggest blind spots? Which technologies are not delivering the telemetry we need?
Purple teaming does not replace traditional red team engagements. A full, blinded exercise simulating a real APT still has value — it tests processes, response times, and coordination under conditions close to a real incident. Purple teaming complements those exercises, filling the gap between penetration testing and operational SOC improvement.
📚 Read the complete guide: OT/ICS Security: Bezpieczeństwo systemów OT/ICS - różnice z IT, zagrożenia, praktyki
How does the purple team use MITRE ATT&CK to structure tests?
MITRE ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) is an open knowledge base documenting the tactics, techniques, and procedures (TTPs) observed in real attacker campaigns. For purple teaming it is the foundational framework — a shared language that allows both the red team and the blue team to speak about the same reality.
The framework is organized hierarchically. At the highest level are tactics — the goals an attacker wants to achieve: Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Collection, Command and Control, Exfiltration, Impact. Each tactic contains techniques — specific ways of achieving the goal, identified by an ID in the format T[number] (e.g., T1566 — Phishing). Many techniques have sub-techniques that specify a variant (e.g., T1566.001 — Spearphishing Attachment, T1566.002 — Spearphishing Link).
In the practice of purple teaming, ATT&CK serves three functions. First, it acts as a checklist — the organization systematically works through techniques relevant to its environment and threat profile, testing each one. Second, it serves as a common communication language — when the red team executes technique T1003.001 (OS Credential Dumping: LSASS Memory), the blue team knows exactly what to look for in Windows Security Event ID 10 (process access to lsass.exe). Third, ATT&CK enables gap analysis — visualization of which techniques are covered by detection and which remain invisible to the SOC.
Flashcard: Structure of MITRE ATT&CK Enterprise
- 14 tactics — stages of the attacker kill chain (from Initial Access to Impact)
- 200+ techniques and 400+ sub-techniques — specific methods of operation
- APT groups — mapping TTPs to known threat actors (e.g., APT28, Lazarus, Cozy Bear)
- Software — malware and tools associated with techniques
- Mitigations and Detections — recommended countermeasures and detection guidance
The practical workflow looks like this: before the exercise, the purple team defines the tactical scope — typically a full kill chain or a selected subset of tactics relevant to the given environment (e.g., Lateral Movement + Credential Access for an organization with an extensive Active Directory). Then, for each technique in scope, the red team prepares an execution procedure while the blue team reviews existing detection rules. During the session, the red team executes the technique, the blue team verifies detection, and the result — detected / not detected / partially detected — is recorded in a tracking system (e.g., Vectr). At the end, the organization has a measured ATT&CK coverage score and a prioritized list of detection gaps to remediate.
A key decision in structuring tests is technique prioritization. Not all 600+ techniques in the Enterprise matrix are equally relevant to every organization. A good purple teaming program starts with an analysis of threats specific to the sector and environment (threat-informed defense), then maps the techniques used by APT groups that attack similar organizations. Data from Mandiant, CrowdStrike, and CISA Advisory reports is an invaluable source here.
How do you plan and conduct a purple team exercise?
Planning a purple team exercise requires organizational precision comparable to planning a full red team engagement, but with additional coordination layers with the blue team. A good purple team session is not improvisation — it is a carefully prepared scenario with clearly defined objectives, scope, and success metrics.
Phase 1: Threat Profiling and scope selection. Before the exercise, the organization must answer the question: “Which techniques are most relevant to us?” The answer comes from threat analysis — which APT groups attack our sector? Which techniques dominated industry incidents in the last 12 months? Which vulnerabilities in our environment are most exploitable? Based on this, a list of priority ATT&CK techniques is created — typically 20–50 techniques per quarterly exercise, grouped into logical kill chains.
Phase 2: Test environment and procedure preparation. The red team prepares detailed execution procedures for each technique — specific commands, tools, parameters. The blue team reviews existing detection rules in SIEM, EDR, and other tools. It is critical to ensure that the test environment has full telemetry — missing logs guarantee a false “not detected” result.
Phase 3: Exercise session. The exercise is conducted as a series of iterations. For each technique: the red team announces its intent to execute → executes the technique → the blue team analyzes for a defined time window (e.g., 15 minutes) → the result is recorded → a discussion is held about what worked, what did not, and why → action items for the blue team are documented. The pace of the session must be realistic — trying to work through 40 techniques in one day leads to superficial analysis.
Phase 4: Remediation and retest. The fundamental difference between purple teaming and a traditional report is that the exercise does not end with a list of gaps. The blue team implements missing detection rules, supplements telemetry, adjusts EDR configurations, and then — in the next session or within the same one — the red team retests those same techniques. The improvement in detectability is measurable and repeatable.
Phase 5: Reporting and planning the next cycle. The exercise report contains ATT&CK coverage statistics (before/after), mapped gaps, implemented fixes, and recommendations for the next session. This cycle — test, remediate, retest — is the core of the continuous improvement program.
Key roles in the exercise: Purple Team Lead (coordinates the entire exercise, often an external consultant or experienced internal specialist), Red Team Operator (executes techniques), Blue Team Analyst (analyzes telemetry), SIEM Engineer (available to modify rules during the session), Scribe (documents results in real time).
How to test individual ATT&CK techniques — from initial access to exfiltration?
Testing ATT&CK techniques requires practical knowledge of how they look in reality — at the level of specific commands, process behaviors, and events in logs. Below are representative examples for each stage of the kill chain that constitute the typical scope of a purple team exercise.
Initial Access (T1566 — Phishing): The red team sends a simulated spearphishing message with an attachment or link to a controlled environment. The blue team verifies whether the email gateway alerted on the suspicious attachment, whether the proxy/DNS blocked the connection to the C2, whether the EDR detected the opening of a macro-enabled document. Technique T1566.001 (Spearphishing Attachment) in the logs produces a characteristic chain: winword.exe spawning cmd.exe or powershell.exe, Event ID 4688 with a suspicious command line.
Execution (T1059.001 — PowerShell): The red team executes malicious PowerShell code — an encoded command, DownloadString from the internet, an AMSI bypass. The blue team verifies whether Script Block Logging (Event ID 4104) is enabled and collected by the SIEM, whether detection rules respond to encoded commands (-enc, -EncodedCommand), whether the EDR blocks AMSI bypass techniques. Many organizations discover here that Script Block Logging is disabled or that logs are not reaching the SIEM.
Persistence (T1547.001 — Registry Run Keys): The red team adds a key to HKCU\Software\Microsoft\Windows\CurrentVersion\Run. The blue team verifies whether Sysmon Event ID 13 (RegistryEvent — Value Set) is collected and tied to a rule. A typical gap: organizations collect Registry events but have no correlation rules that distinguish malicious entries from legitimate ones.
Credential Access (T1003.001 — LSASS Memory Dump): The red team uses Mimikatz, ProcDump, or a custom tool to dump the memory of the lsass.exe process. The blue team verifies Event ID 10 in Sysmon (ProcessAccess targeting lsass.exe), EDR alerts, and rules detecting known tools (Mimikatz strings, ProcDump arguments). This is one of the key tests — compromising LSASS is often a turning point in an attack.
Lateral Movement (T1021.002 — SMB/Windows Admin Shares): The red team uses PsExec, SMBExec, or built-in commands for lateral movement over SMB. The blue team verifies Event ID 4624 (logon type 3), 4648 (explicit credential use), 7045 (new service). Sysmon Event ID 3 (NetworkConnect) with destination port 445 and Event ID 11 (FileCreate) under ADMIN$ or C$ paths are characteristic traces.
Exfiltration (T1048.003 — Exfiltration over HTTP): The red team transmits synthetic data to a controlled server over HTTPS. The blue team verifies whether the proxy/DLP detected large outbound transfers to an unknown host, whether UEBA/NDR flagged an anomalous communication pattern, and whether transfer-volume-based rules are functioning correctly over time. Exfiltration is technically a simple stage, yet organizations most frequently fail to detect it because outbound traffic has historically been monitored less rigorously than inbound traffic.
Flashcard: Testing priorities by kill chain phase
- Initial Access — verifies the effectiveness of the email security gateway and proxy
- Execution — verifies script logging, AMSI, Application Control
- Credential Access — verifies LSASS protection, PAM/Privileged Access
- Lateral Movement — verifies network segmentation and internal traffic monitoring
- Exfiltration — verifies DLP, proxy, and UEBA
How to measure organizational detectability — coverage gap analysis?
Coverage gap analysis is a systematic assessment of what portion of the ATT&CK techniques relevant to the organization are covered by its current detection mechanisms. It is the foundation of the purple teaming program — without measurement there is no improvement, and without a measurement structure results are not comparable across exercises.
The detection assessment model for each technique should be four-tiered. Detected and Alerted — the technique generated an alert in the SIEM or EDR that reached an analyst. This is the highest level of effectiveness. Detected, No Alert — the telemetry contains traces of the technique, but no rule generated an alert; an analyst would have to search for that data manually during threat hunting. Data Available, Not Correlated — logs exist but do not contain a sufficiently contextual scope of the technique to enable confident detection. Not Detected — there is no telemetry data whatsoever indicating that the technique was executed; the technique is completely invisible.
Coverage gap analysis results should be presented in three dimensions. First, as ATT&CK tactic coverage percentage — how many techniques within each of the 14 tactics are covered at the Detected and Alerted level. A security-mature organization should aim for 70%+ coverage of priority techniques. Second, as an ATT&CK Navigator heatmap — a visualization of the matrix with colors representing the detection level for each cell. This visualization is highly effective in communication with the CISO and board — it shows blind spots directly on the attacker’s map. Third, as a coverage trend over time — comparing results across successive exercises shows whether the program is genuinely raising maturity or standing still.
Flashcard: Four detection levels in coverage gap analysis
- Level 4 — Detected and Alerted — automatic alert reaches the SOC analyst
- Level 3 — Detected, No Alert — data in logs, no correlation rule present
- Level 2 — Partial Data — telemetry incomplete or too noisy for confident detection
- Level 1 — Not Detected — technique completely outside visibility
The key pitfall of coverage gap analysis is a false sense of security due to incomplete telemetry. If an organization does not collect logs from a specific source (e.g., no Sysmon on workstations, no Windows Advanced Audit Policy on servers), a “not detected” result may stem from missing telemetry rather than a missing detection rule. Therefore, gap analysis must include a telemetry completeness assessment layer — mapping log sources to the detection requirements of individual techniques.
Practical tools for conducting gap analysis: ATT&CK Navigator (free MITRE tool for visualizing and annotating the matrix), Vectr (platform for tracking exercise results), DeTT&CT (framework for mapping telemetry and detection quality to ATT&CK). Organizations with a mature SOC often integrate gap analysis results directly with their SOAR or SIEM platforms to automatically prioritize work on new detection rules.
How does purple teaming improve SIEM rules and SOC processes?
SIEM (Security Information and Event Management) is the nerve center of every SOC, but without regular calibration its rules quickly become stale. Rules written two years ago may fail to detect techniques that attackers discovered a year ago. Purple teaming is the most effective mechanism for keeping SIEM rules current — because it tests them under controlled conditions, exactly as real attackers operate.
A typical cycle of SIEM rule improvement through purple teaming looks like this. The red team executes technique T1547.001 (Run Key Persistence). The SIEM is silent — no alert. The blue team checks whether Event ID 13 from Sysmon is reaching the SIEM: it is. They examine existing rules: a rule exists, but it filters legitimate software through an allow list that has not been updated for 18 months. The SIEM engineer updates the rule, removes outdated exceptions, and retests. The next time the same technique is run — an alert is generated within 2 minutes of execution.
This cycle exposes several categories of problems that would otherwise remain invisible. False positive suppression — rules that were deliberately silenced or burdened with an overly broad whitelist filter because they were generating too much noise. Purple teaming identifies which of those suppressions were justified and which were hiding real activity. Missing data sources — often the issue is not a missing rule but a missing log. Sysmon not installed on 30% of workstations, Windows Advanced Audit Policy misconfigured on domain controllers, no logging from network devices. Stale correlation logic — rules based on specific file names or malware hashes that attackers changed long ago. Purple teaming forces a shift toward behavioral detection rules — based on behavioral patterns, not signatures.
Improving SOC processes goes in parallel with improving technical rules. When the purple team tests a technique that generates an alert — but the blue team takes 45 minutes to analyze it because the playbook is outdated or the analyst did not know how to interpret a given event — that is a signal that not only the rule needs attention but the incident response playbook does as well. Purple teaming regularly exposes gaps in SOC procedural documentation: missing playbooks for specific ATT&CK techniques, inconsistent alert priorities, lack of escalation for high-severity events during night hours.
Flashcard: Types of SIEM problems detected by purple teaming
- Missing telemetry — logs do not reach the SIEM or are collected selectively
- Dead rules — signature-based rules that attackers have long since bypassed
- Overly broad whitelists — legitimate exceptions hiding malicious activity
- Missing correlation — data is present but there are no rules connecting it into a meaningful alert
- Stale priorities — critical techniques marked as “low” due to historical decisions
One of the most valuable practices is creating Detection-as-Code — storing SIEM rules in a Git repository together with ATT&CK metadata (tactic, technique, sub-technique), the date of the last test, and the result. This gives the organization a complete history of rule evolution, the ability to roll back to previous versions, and the option to automatically retest rules whenever the environment changes. This closes the loop between purple teaming and day-to-day SOC operations.
How to integrate purple teaming with a threat hunting program?
Threat hunting and purple teaming are two complementary practices that mutually reinforce each other. Threat hunting asks: “Is an attacker already here?” Purple teaming asks: “Would we see them if they were?” An organization that runs both programs simultaneously achieves a level of security maturity that neither program can reach on its own.
The integration works in both directions. Purple teaming feeds threat hunting in several ways. First, purple team exercises produce detailed information about how specific techniques appear in the telemetry of the given environment — which events they generate, which process names, which command-line parameters. These are ready-made hypotheses and leads for hunters. If the purple team discovered that technique T1218.011 (Signed Proxy Execution: Rundll32) is not detected by the SIEM, a hunter can proactively search historical logs looking for signs that this technique was already used by a real attacker.
Second, coverage gaps identified by purple teaming define priorities for hunting campaigns. A hunter should not search everywhere — they should focus where detection is weak and where the organization has the largest blind spots. The coverage gap analysis from purple teaming is an ideal map for planning hunting campaigns.
Threat hunting feeds purple teaming in turn by supplying hypotheses based on observations of the real environment. If a hunter during a hunting campaign noticed unexplained PowerShell activity on several workstations during night hours — that observation becomes a priority for the next purple team exercise: test PowerShell techniques and verify whether the SIEM is configured to detect them.
Flashcard: Purple Team + Threat Hunting integration loop
- Purple team tests a technique → identifies a detection gap
- The gap becomes a hunting hypothesis → hunter searches historical logs
- Hunter discovers potential real activity → escalation to incident response or a new purple team exercise
- Hunting results feed the scope of the next purple team exercise
The common denominator of both programs is the MITRE ATT&CK framework. Hunters build hypotheses based on ATT&CK techniques. The purple team structures exercises around ATT&CK techniques. Thanks to shared nomenclature, the results of both programs can be compared, combined, and reported in a consistent manner. The organization has a single, unified view of its ATT&CK coverage — from both the perspective of controlled testing (purple team) and historical data analysis (threat hunting).
Mature organizations formalize this integration through joint planning meetings between the purple team and threat hunters, shared result management platforms, and a unified ATT&CK coverage report updated after every exercise and every hunting campaign.
What tools automate purple teaming — Atomic Red Team, CALDERA, Vectr?
The purple teaming tool ecosystem has developed significantly in recent years in response to growing interest in the methodology. The most important tools can be divided into three categories: test atom libraries, attack automation platforms, and result tracking systems.
Atomic Red Team (Red Canary, open source) is a library of over 1,100 “atomic” tests — minimal, isolated execution procedures for individual ATT&CK techniques. Each atom is a specific script (PowerShell, Bash, Python) that executes one technique in the simplest possible way. Atomic Red Team does not attempt to simulate a full attacker — instead, it delivers standardized, repeatable execution of each technique. For purple teaming it is an ideal tool for verifying detection: does the EDR detect T1003.001 executed by this specific atom? If not — that is a detection gap. Atoms are launched from the command line (Invoke-AtomicTest T1003.001) or through a dedicated framework.
MITRE CALDERA (open source) is an advanced platform for automating adversarial operations. Unlike Atomic Red Team, CALDERA simulates full campaigns — sequences of techniques forming a coherent kill chain. The agent (Sandcat) installed on the target autonomously executes assigned techniques and reports results to the CALDERA server. For purple teaming, CALDERA is particularly useful for testing Lateral Movement, Command and Control, and Persistence techniques in an automated manner. The “Stockpile” plugin contains a library of ready-made operational capabilities, and the “ATT&CK Evaluations” plugin maps results to the ATT&CK matrix.
Vectr (Security Risk Advisors, freemium) is a platform for managing purple team exercises and tracking results. Vectr allows planning test campaigns, recording the result of each technique (detected / not detected / alerted), tracking remediation, and generating ATT&CK coverage reports. It is the de facto standard for managing a purple teaming program — many organizations and external consultants use Vectr as the primary documentation system. Integrations with Atomic Red Team and CALDERA allow test results to be imported automatically.
Flashcard: Comparison of key purple teaming tools
- Atomic Red Team — test atom library; ideal for verifying detection of individual techniques; open source
- CALDERA — adversarial campaign automation platform; simulates a full kill chain; open source (MITRE)
- Vectr — purple team result management platform; coverage tracking, reporting; freemium
- ATT&CK Navigator — ATT&CK matrix visualization; coverage heatmaps; open source (MITRE)
- Prelude Operator — commercial purple team platform with pre-built APT scenarios; paid
- DeTT&CT — framework for mapping telemetry and detection quality to the ATT&CK matrix; open source
In addition to these tools, purple team exercises use a standard red team toolset: Cobalt Strike or Havoc C2 for advanced C2 simulation, Mimikatz for testing Credential Access, BloodHound for analyzing and testing Active Directory paths, Metasploit for Initial Access and Exploitation. The key point is that in purple teaming these tools are used in a controlled and transparent manner — the red team reveals to the blue team what it executed and how, so that the blue team can learn to recognize the traces of these tools in logs.
Automation through Atomic Red Team and CALDERA has its limits. Autonomous atoms cannot replace an experienced red team operator who can adapt techniques to the specifics of the environment, apply custom evasion, and simulate the real sophistication of an APT. Best practice is a combination: automated tests for broad coverage of dozens of techniques, manual exercises for key scenarios requiring creativity and adaptation.
What does the purple teaming cycle look like in an organization?
An effective purple teaming program is not a one-time project — it is a continuous cycle that embeds itself in the operational rhythm of the organization. The table below describes a mature purple teaming cycle model, from organizations taking their first steps to those with a fully operational program.
| Maturity phase | Description | Frequency | Scope | Success metrics |
|---|---|---|---|---|
| Phase 1: Initiation | First purple team session; establishing ATT&CK coverage baseline; identifying critical telemetry gaps | One-time / kickoff | 10–20 high-priority techniques | Baseline coverage score; list of critical gaps |
| Phase 2: Building foundations | Regular quarterly sessions; supplementing telemetry; writing the first dedicated detection rules | Quarterly | 20–40 techniques; retests from previous sessions | Coverage score per tactic; % of gaps addressed |
| Phase 3: Optimization | Monthly sessions focused on specific tactics; integration with threat hunting; Detection-as-Code | Monthly | 30–50 techniques; APT scenarios | MTTD for tested techniques; false positive rate |
| Phase 4: Continuous improvement | Bi-weekly atomic tests; continuous coverage monitoring; purple team embedded in security CI/CD pipeline | Bi-weekly / continuous | Full ATT&CK Enterprise for priority; custom APT scenarios | 70%+ coverage for priority techniques; detection trend year-on-year |
| Phase 5: Mature program | Purple team operationally integrated with SOC; threat hunting fed by results; external validations and comparisons with sector benchmarks | Continuous + semi-annual audit | Full ATT&CK Enterprise; custom TTPs; supply chain scenarios | Full-spectrum coverage; MTTD <15 min for critical; 0 critical blind spots |
A quarterly rhythm is the starting point for most organizations. Over the course of a year, four sessions allow the full scope of priority techniques to be covered and progress to be measured between sessions. For organizations with a mature SOC and a dedicated red team, moving to monthly sessions focused on specific tactics accelerates iteration and enables more granular optimization.
Key success factors for the program: CISO and management support for allocating blue team time to exercises (this is the greatest organizational barrier — SOC analysts are always under pressure from production alerts), a dedicated test environment or a detailed protocol for running tests in the production environment without risky side effects, a result and remediation tracking system (Vectr or equivalent), and an organizational culture in which “not detected” is a result to fix rather than a reason to hide problems.
How does nFlo conduct purple team exercises for clients?
nFlo conducts purple team exercises as part of a comprehensive Advanced Security Testing offering, combining experience from 500+ security projects with a structured methodology based on MITRE ATT&CK. Our approach is grounded in the philosophy of “threat-informed defense” — before we test anything, we understand the threat profile of the specific organization, its sector, and the history of industry incidents.
A typical nFlo purple team engagement consists of three stages. In the preparatory phase we conduct threat profiling: we analyze which APT groups and techniques are relevant to the client based on sector (finance, industry, public administration, healthcare), analyze the existing technology stack (what telemetry does the client’s SOC have?), and establish the priority ATT&CK scope for the exercise. The output is a personalized “adversary profile” and a list of 25–50 techniques to test.
In the exercise phase, our red team operators execute each technique in the client’s dedicated environment or in close coordination with their IT team, within a maintenance window that minimizes the risk of disrupting operations. We use a combination of Atomic Red Team for standardized atoms, custom tools for techniques requiring adaptation to the client’s environment, and a full red team toolset (C2, post-exploitation frameworks). Each technique is immediately verified with the blue team — we record results in real time in Vectr.
After the exercise we deliver an ATT&CK coverage report with a Navigator heatmap, a prioritized list of detection gaps with recommendations for implementing SIEM/EDR rules, a mapping of missing telemetry to the log sources that need to be supplemented, and a retest plan. If the client decides to engage remediation support, we assist the blue team in implementing fixes and conduct a retest session confirming the effectiveness of the changes.
From the experience of 200+ nFlo clients, organizations approaching their first purple team exercise discover on average that 40–60% of the tested techniques generate no alert in the SIEM whatsoever. The most common causes are incomplete telemetry (no Sysmon, incorrectly configured Windows Advanced Audit Policy), signature-based SIEM rules instead of behavioral ones, and overly broad whitelists created during historical efforts to reduce false positives. After the first exercise cycle and remediation, that figure drops to 15–25%, and organizations report a 90% reduction in risk for key attacker scenarios.
We also offer a continuous program — monthly purple team sessions as a subscription, integration with nFlo’s Managed SOC service (response time under 15 minutes for critical incidents), and access to our threat intelligence on APT groups active in Poland and Central Europe. 98% of clients who implemented a purple teaming program with nFlo continue the collaboration the following year — because they see a measurable, repeatable improvement in their security posture.
Related topics
If you are interested in purple teaming, it is worth exploring related topics from our knowledge base:
- Threat Hunting — proactive hunting for threats in the network (hypotheses, MITRE ATT&CK, hunting tools)
- Red Team Engagements — full APT simulations under isolation conditions
- SIEM and log correlation — the fundamentals of building an effective monitoring center
- MITRE ATT&CK Framework — a guide to adversarial tactics, techniques, and procedures
- SOC and Security Operations — organization and maturity of the security operations center
- Infrastructure penetration testing — differences between a pentest and purple teaming
Learn more
- MITRE ATT&CK Enterprise Matrix — official MITRE knowledge base
- Atomic Red Team — test atom library (GitHub)
- MITRE CALDERA — adversarial automation platform (GitHub)
- Vectr — purple team exercise management platform
- ATT&CK Navigator — coverage visualization tool
- DeTT&CT — telemetry quality mapping framework
Check out our services
Want to implement a purple teaming program in your organization? nFlo offers:
- Purple Team Engagements — one-time or recurring exercises with ATT&CK coverage reporting
- Red Team / Adversary Simulation — advanced APT simulations
- SOC Advisory — consulting on security operations maturity
- Managed SOC — continuous monitoring with a response time under 15 minutes
Contact nFlo and schedule a free consultation on your organization’s security testing needs.
FAQ
How does purple teaming differ from traditional red teaming?
Red teaming is a simulation of the attacker under conditions of full isolation — the blue team does not know when or what will happen. The goal is to assess the ability to break through defenses. Purple teaming is a collaboration model in which the red team and blue team work together, sharing observations in real time. The goal is to improve detection and refine SIEM rules. Red teaming simulates a real APT campaign; purple teaming is a systematic verification and improvement of detection mechanisms. Both methods complement each other — they are not mutually exclusive.
How often should an organization conduct purple team exercises?
The minimum frequency for an organization with a mature SOC is once per quarter. This allows all priority ATT&CK techniques to be covered over the course of a year and progress to be measured between sessions. Organizations with a dedicated security team should aim for monthly sessions focused on specific tactics. The most mature programs combine automated atomic tests (Atomic Red Team) run on a regular basis with manual sessions for scenarios requiring the red team’s expert knowledge.
What tools are needed to start a purple teaming program?
Three elements are sufficient to get started: the Atomic Red Team library (open source) for executing standard ATT&CK technique tests, ATT&CK Navigator (open source) for visualizing coverage results, and Vectr (freemium) for tracking results and remediation. A SIEM and EDR environment on the blue team side is a prerequisite — without telemetry there is nothing to verify. Full platforms such as CALDERA and commercial red team tools (Cobalt Strike) come into play at a higher level of program maturity.
Does purple teaming require an external red team?
No, although an external red team brings value in the form of fresh perspective and experience across many environments. An internal red team or even a single security operator can conduct purple team exercises using Atomic Red Team — the required knowledge is familiarity with ATT&CK techniques and the ability to interpret logs, not advanced offensive skills. An external red team is particularly valuable for advanced APT scenarios, custom evasion, and initial exercises when an organization is building its methodology. For regular, operational sessions — an internal team is fully sufficient.
How do you measure the success of a purple teaming program?
Key metrics are: ATT&CK coverage score — the percentage of priority techniques detected at the Detected and Alerted level (target: >70% after 12 months of the program); coverage trend between sessions — improvement of 10–20 percentage points after each remediation cycle; Mean Time to Detect (MTTD) for tested techniques — how quickly the SIEM/EDR generates an alert after a technique is executed; number of addressed detection gaps — how many of the action items from the previous session have been implemented. The success of the program is not a single result — it is a repeatable, measurable trend of improving organizational detection maturity over time.
Sources
- MITRE Corporation. (2025). MITRE ATT&CK Enterprise Matrix v15. https://attack.mitre.org/
- Red Canary. (2025). Atomic Red Team — Library of adversary emulation tests. https://github.com/redcanaryco/atomic-red-team
- MITRE Corporation. (2024). CALDERA — Cybersecurity Operations Research. https://github.com/mitre/caldera
- Security Risk Advisors. (2024). VECTR Purple Team Exercise Platform. https://vectr.io/
- Rabobank CDC. (2024). DeTT&CT — Detect Tactics, Techniques & Combat Threats. https://github.com/rabobank-cdc/DeTTECT
- CISA. (2024). Known Exploited Vulnerabilities Catalog. https://www.cisa.gov/known-exploited-vulnerabilities-catalog
- Mandiant. (2024). M-Trends 2024: Special Report. https://www.mandiant.com/m-trends
- CrowdStrike. (2025). 2025 Global Threat Report. https://www.crowdstrike.com/global-threat-report/
- Scythe. (2024). Purple Teaming: The Definitive Guide. https://scythe.io/library/purple-team-guide
- Pols, P. (2021). The Unified Kill Chain: Designing a Complementary ATT&CK-based Kill Chain for Threat Intelligence. SANS Institute.
Need expert support? nFlo team can help secure your organization:
Related topics
See also:
