Purple teaming describes the close cooperation between the red team (attacker perspective) and the blue team (defender perspective) to improve a company’s security situation in a targeted and measurable way. Techniques, tactics and processes (TTPs) as well as findings and observations are shared directly and promptly. The exercise should be based on real threats, for example MITRE ATT&CK – Enterprise Techniques or specific threat actors. The goal of such purple team projects is to demonstrably improve the company’s existing security measures and to uncover any gaps in monitoring and response.

Why purple teaming? Goals and added value

Purple teaming is most effective when it is understood as an exercise rather than a test of individual teams. One of the most important fundamentals is cooperation between the red and blue teams. The focus is on detection and response capabilities along a realistic attack flow (kill chain) and/or TTPs, including clear measurability:

• What was detected?
• How quickly?
• With what quality (triage, context, escalation, containment)?

Equally important are clearly defined success criteria such as desired telemetry, new detection use cases, playbook improvements, reduced mean time to repair (MTTR), scope and risk governance (production risks, data access, approvals), defining or improving common internal vocabulary (TTP mapping, severity logic, alert definitions). The objectives should be tailored to the company and take into account the current maturity level of the IT security system. Typical objectives could be as follows:

• Improve visibility and detection for defined TTPs
• Check and reduce time to detect and time to respond
• Identify and address potential blind spots and detection gaps
• Validate processes and controls: Do triage, incident handling and internal/external handover work? Do the control mechanisms used, such as MFA, hardening and block/allow listing, work?

Another success factor is the balance between realism and the learning curve: Purple teaming should be iterative. This creates a continuous improvement process in which the red and blue teams do not work against each other, but rather work together to improve the security system.

While pure red teaming primarily demonstrates vulnerabilities and blue teaming often works reactively on alerts, purple teaming combines both into a measurable improvement cycle

• Detection engineering with a focus on reality: Detection use cases can be created based on real TTPs and kill chains instead of working through generic best practice lists
• Improvement of telemetry: Due to the previously defined environment or framework conditions, it is possible to quickly identify whether important data sources are missing.
• Alert quality: Reduce false positives while improving context, prioritisation and correlation.
• Know-how transfer and culture: During the project, a direct transfer of know-how between the teams can take place, and risks, feasibility and possible effort are made visible.

Pitfalls

Since the maturity level of IT security varies from company to company, it is important to define transparent goals in advance and discuss them within the team (red and blue together) in order to address potential pitfalls right from the start. Good purple team exercises are goal- and measurability-driven. It is clearly defined which kill chain or TTPs are to be tested. This prevents false expectations from arising and ensures that everyone involved knows what is being tested. It is important to ensure that the scope is not too broad and that prioritisation is not neglected. A previously defined kill chain or a small number of TTPs, such as the top threats in your own industry, should be addressed. During the project, retests can be carried out and, if possible, sustainable countermeasures/fixes can be created. Of course, this is not possible if the necessary telemetry and data quality are not available. This brings us to the third pitfall. Purple teaming is only really worthwhile if clean data sources and telemetry are available. This includes all types of missing logs, missing process or network details, and short data retention times. Once data quality and telemetry are in place, care must be taken to ensure that no silos are created. Often, despite EDR being rolled out on all clients, SIEM being deployed and SOC processes being defined, end-to-end ownership and thus responsibilities are not clearly defined.

Certain TTPs could disrupt systems. The framework conditions must be clearly defined. These include permitted payloads, the performance of certain tests during change or maintenance windows, and rollback or even failover plans. Of course, it also makes sense to test such TTPs in a test environment or to exclude them completely in an initial purple team project. Finally, one of the biggest pitfalls of a purple team exercise: No clean documentation and a lack of follow-up work. The tools and techniques used by the red team must be documented in detail: On which system, with which user, at what time, and which tool or technique was executed or started? This information must be made available to the blue team so that it can generate added value during the follow-up work. Detections can be rechecked and adjusted if necessary. Missing data sources can be identified and addressed. Playbooks can be improved and retests planned.

Pyramid of Pain

Thirteen years ago, David J. Bianco published the Pyramid of Pain in a blog post and released an update in 2022. He describes how much more difficult, or painful, it is for attackers to succeed when defenders recognise and block certain indicators.

This pyramid can still be used today. We can try to choose our goals during the project in such a way that we systematically tackle the pyramid from trivial to challenging.

First level (hashes, IPs, domains) Volatile indicators, due to new infrastructure or hashes

• Are such IOCs cleanly logged and processed (SIEM, proxy, EDR)?
• How quickly are they detected and how long does it take for them to be blocked? Is this automated or does it have to be processed manually by a SOC employee?
• How many and what kind of false positives occur?

Middle level (artefacts) Patterns, anomalies or malicious activities on one or more hosts

• Process chains, registry changes, unusual processes identifiable?
• Known, potentially malicious files or directories in specific locations on the client?
• Anomalies in running services or new, unknown services?

Top level (TTPs) Tools as well as techniques (credential dumping, privilege escalation, lateral movement) if the tools change

• Can the technique be detected rather than the tool? What if a different tool is used?
• Are suitable response procedures in place, have they been tested and can they be used, for example, client isolation or token revocation?
• This concerns the entire procedure of an attacker, from reconnaissance to the exfiltration or destruction/encryption of data

The primary focus of a purple team should be on the middle to upper levels. Defence is improved and aligned with or expanded to include behavioural patterns and tactics/techniques.

Automation and purple teaming tools

Sufficient resources are required for clean, well-prepared and structured purple team exercises. A red team (internal or external), a blue team, and up-to-date IT systems and their monitoring are required. The planning phase, documentation, testing and everything else involved can also be resource-intensive. It would therefore make sense to use tools or automation to automate the technical test or part of it, for example. There are a variety of tools available, but most of them cannot automate an entire purple team protocol in a short period of time.

One example is Atomic Red Team, an open source library of tests for checking the security mechanisms in place. The tests are mapped and assigned according to MITRE ATT&CK Techniques. For example, if you want to check whether new detection rules or SOC use cases are effective with the OS Credential Dumping technique, you can use the MITRE T-number, in this case T1003, a suitable test can be selected and executed. As with all tests, it is essential that you are aware of and understand what is being executed or downloaded. It is essential to check the scripts or tools to be executed. The Clean Source Principal must not be neglected. Some tests of these open source libraries use the PowerShell command Invoke-WebRequest to download another tool or DLL files that we do not want to have in a productive environment. There are also providers who offer purple team projects as an automated service in the form of tools or similar. Here, too, the clean source principle applies: If a company decides to use such a tool, it trusts the provider and their tools. Alternatively, it requires a code review of the tools used, which is highly likely to negate the resource savings achieved by such a service.

Summary

Purple teaming is a very effective method not only for testing security, but also for demonstrably improving it. Through close cooperation between the red and blue teams, realistic TTP selection, fast feedback loops and clear measurement criteria, the existing security system can be tested and further expanded. The biggest pitfalls rarely lie in the technology itself, but rather in scope, telemetry, responsibilities, governance and a lack of follow-up work. The Pyramid of Pain offers a useful conceptual model: Purple teaming helps shift detection from fragile IOCs to behaviour- and technology-based detection – where it really becomes expensive for attackers. Tools and automation can scale purple teaming and make regressions visible. However, sustainable added value only comes from clean documentation, reviews, continuous development of detection rules and use cases, process improvements, and consistent retesting and validation.

About the Author

Eric Maurer completed his IT training in the financial sector and then gained experience in the roles of administrator, engineer and consultant. He was involved in the development, setup and operation of an Enhanced Security Administrative Environment and the international rollout of Active Directory Services. In addition he is experienced in Microsoft Entra ID with a focus on security.

Links

• https://attack.mitre.org/techniques/T1003/
• https://attack.mitre.org/techniques/enterprise/
• https://detect-respond.blogspot.com/
• https://detect-respond.blogspot.com/2013/03/the-pyramid-of-pain.html
• https://github.com/redcanaryco/atomic-red-team
• https://github.com/redcanaryco/atomic-red-team/tree/master/atomics/T1003
• https://specterops.io/blog/2025/10/08/the-clean-source-principle-and-the-future-of-identity-security/
• https://vuldb.com/?actor
• https://www.atomicredteam.io
• https://www.scip.ch/?defense
• https://www.scip.ch/?labs.20220407
• https://www.scip.ch/?labs.20241114
• https://www.scip.ch/?offense
• https://x.com/DavidJBianco