If you have invested in buying attack detection tooling, building a Security Operations Centre, or even outsourcing your attack detection capability to a third party, you want to be sure that these defenses can respond effectively when the worst happens. Many security teams are turning to Purple Team exercises to test and improve their defenses, but what is a Purple Team, how does it work, and what benefits could you get from it?
This article will help with all these questions and more
What is a Purple Team exercise?
A Purple Team exercise is a collaborative security assessment where a Red Team (offensive security experts) and a Blue Team (defensive security professionals) work together to test an organization’s security defenses against real-world attack scenarios.
By working closely together through targeted attack scenarios tailored to your organization, Purple Team exercises help fine-tune security monitoring, detection, and incident response capabilities. These tests identify gaps or misconfigurations that could lead to real attacks being missed or not managed correctly—whether you rely on an internal security team or a third-party managed SOC provider.
Red Team, Purple Team or both?
Red Teaming and Purple Teaming have a lot in common, and both offer tests of your security against simulated real-life attacks, but they are different exercises with important differences.
Red Teaming: Unlike a penetration test, which uncovers all the vulnerabilities present within a set asset, a Red Team exercise begins by outlining a realistic attack scenario. The Red Team are given a specific goal, and they must reach it using any tactic available to them (within a safely pre-defined scope). Such targeted attack simulations are designed to test your defenses against real-life scenarios, and see what can be achieved, but for this very reason, they do not test a broad range of attack types against many different security controls. This is because testers will – just like real life attackers – look for the easiest path to achieve their goals.
Purple Teaming: Organizations with a SOC (or a blue team), can test the effectiveness of their defenses in a similar targeted attack simulation by collaborating with a Security Services Provider in a Purple teaming exercise. First, the provider will devise multiple detailed cyber-attack scenarios to test whether your security controls work as intended and where there are gaps. That means your provider will work with your SOC, assisting the blue team, as well as performing the Red Team element of the simulated attack.
A Purple Team emphasizes learning and evolving by ensuring that both teams exchange insights during the process and should therefore give you more detailed recommendations for ways to improve the design and configuration of your monitoring and response systems.
How to pick? Choosing between the two depends on a range of factors, including the maturity of your security posture, the range of your testing program and the extent of your monitoring and response systems. The two tests are not mutually exclusive; an organization may conduct a Red Team engagement first to expose vulnerabilities, followed by a Purple Team to collaboratively address the gaps and enhance the defenses.
We work with many organizations who undertake both types of tests and we’re happy to talk to you about what we’d recommend for you at any given moment in time.
How does a Purple Teaming exercise work?
- Threat assessment and exercise review and design
An effective Purple Team should be based on the real-life threats facing your company. This should be a collaborative exercise in which the attacks are based on your industry, the type of data your business stores, as well as recent trends in cyber-attacks. As with a Red Team exercise, you may decide that certain assets in your IT estate and certain attack techniques should be out of bounds for the purposes of safety, or business continuity. In many cases these can be figured out with a workaround.
In most instances, the blue team is the client’s own internal SOC. If they have contracted an Managed Security Services Provider to outsource their SOC, they must also be aligned to collaborate for an effective Purple Team.
The testing plan can be broad or narrow, but as standard we recommend testing a range of TTPs over the entire attack chain from initial compromise through persistence, lateral movement, to actions on objective like data exfiltration.
Once the test plan is reviewed and agreed with your security team, ways of working are established such as how often you will communicate, how frequently reports are delivered throughout the engagement, and how your chosen partner will assist your blue team.
- Observed attack simulation
The Red Team undertake the tests according to the schedule and timings agreed with your blue team – it is essential that the teams work closely together to see what attack techniques raise the alarm, how your attack detection tools are configured, how your teams respond, and if the tools they use are working as they should. Finding out how quickly you can identify the attack and how effective you can stop it is the name of the game.
- Detect and respond activity and analysis
All testing outcomes and timings are carefully logged, including the details captured within the alerts and how long it took the blue team to respond. When certain tactics, techniques and procedures do not raise alerts, or the blue team do not respond as expected, it’s crucial to understand why, and where the gaps in your defenses are, so that clear recommendations and improvements can be made.
- Reporting, review and closure
Detailed reporting is key so that improvements can be planned and changes tracked, ultimately proving a full log and record of the test and all the recommendations.
Ultimately, while a test is a one-off project, it should form part of your continuous security improvement and will generate improvement actions and future retesting requirements.As well as our penetration testing and Red Team experience, Claranet Cyber Security has extensive managed SOC offerings, and the teams behind these often assist with our Purple Teaming projects to provide advice and guidance as to how to improve the design and configuration of the defenses.
Preparing for a Purple Team
To be effective, a Purple Team needs to be tailored to your organization and the threats you face. It requires planning and the right resources to be effective.
Tailoring: Purple Teaming isn’t a one-size-fits-all exercise; it requires careful design leveraging threat intelligence and frameworks like MITRE ATT&CK. This ensures that the project focuses on tactics, techniques, and procedures (TTPs) relevant to your business, and simulates attacks on your most important data and the security controls and processes which protect it. The scale and scope of the exercise must also be considered. Do you undertake a large attack simulation testing many security controls at once, or conduct smaller, more focused tests?
Building the team: Beyond the design of the exercise, stakeholder buy-in and close collaboration between all teams involved is crucial. It is essential that your security team (especially your SOC) are engaged from the outset. This leads to more thorough and comprehensive testing, with more informed results, and more effective improvements to your security posture.
Planning: The team then input into the design of the exercise and agree the specific tests to be run, but also ensure the teams are ready to support the actual assessment with the right resources at pre-agreed times. It doesn’t matter if this is 3rd party managed security provider, in-house teams, or a combination of both; the correct engagement of the right resources is key, and we notice significantly more effective outcomes when this has been well managed.
What can a Purple Team test?
The following examples come from within real Purple Team engagements run by Claranet Cyber Security:
Example 1: Data Exfiltration Using Encrypted Channels to Steal Sensitive Credit Card Data (T1048)
Scenario: The Red Teams goal was to exfiltrate encrypted credit card data or other sensitive information without triggering alerts. The aim of this assessment is to evaluate the effectiveness of DLP systems and encryption monitoring tools in identifying anomalous data transfer activities.
Assessment Details: In this Purple Team simulation, the Red Team exfiltrated data over the internet by tunnelling it through the ICMP. Additionally, the Red Team uploaded an Excel file containing dummy data mimicking sensitive information patterns and Personally Identifiable Information (PII) to a test site over HTTP (clear text), testing the organization’s ability to detect unauthorized data uploads.
Attack Simulation:The Red Team exfiltrated a small file named dummy.7z using ICMP tunnelling via PowerShell scripts. The tools icmpExfiltrater.ps1 and Powershell-ICMP-Sender.ps1 were used to encode and send the file to an internet-based endpoint controlled by the Red Team. In parallel, a test Excel file containing dummy data resembling sensitive information and PII patterns was uploaded to a public DLP-test site using HTTP, an unencrypted protocol, to assess the organization’s ability to detect and block such file uploads.
Example 2: Simulation of ransomware attack
Scenario: The goal was to simulate file encryption activities often associated with ransomware attacks to test the organization’s detection and response capabilities.
Assessment Details: In this simulation, the Red Team simulated a ransomware attack by generating and encrypting dummy Microsoft Office files using a custom tool.
Attack Simulation: The Red Team used a custom application to generate dummy Microsoft Office files (e.g., .docx, .pptx, .xlsx), mimicking those commonly found in an organization. To simulate ransomware tactics, they then used another custom-created tool to encrypt the files and rename them with a custom file extension. The objective was to test whether conventional monitoring systems could detect and respond to custom encryption methods and file modifications, helping improve the organization’s ransomware readiness.
Example 3: C2 implant using DLL Hijacking (Microsoft Teams / OneDrive)
Scenario: The aim was to execute a Command and Control (C2) implant by leveraging DLL injection vulnerabilities in Microsoft Teams and Microsoft OneDrive.
Assessment Details: The Red Team executed a Command and Control (C2) implant by leveraging DLL injection vulnerabilities in Microsoft Teams and Microsoft OneDrive. These vulnerabilities allowed the Red Team to load unsigned malicious DLLs into memory by exploiting a weakness in the way Microsoft applications allowed unsigned libraries to be loaded.
Attack Simulation: The Red Team exploited DLL injection/hijacking vulnerabilities in Microsoft Teams and OneDrive, both of which allowed the loading of unsigned libraries. The malicious DLLs were placed in the following directories:
- \AppData\Local\Microsoft\Teams\current\iphlpapi.dll
- \AppData\Local\Microsoft\OneDrive\version.dll
By placing these malicious DLLs in these folders, the attacker was able to execute the C2 implant without raising immediate suspicion. The DLLs were loaded into memory by the affected Microsoft applications, allowing the attacker to maintain control over the compromised system and potentially escalate privileges or exfiltrate data.
What outcomes can I expect from a Purple Team exercise?
The following are examples of findings from real Purple Team exercises run by Claranet Cyber Security:
Improper logging and monitoring:
In one exercise, we observed that critical servers such as a domain controller and the AD sync server were not onboarded with the client’s EDR tool, meaning no logs were collected and monitored from them. This created blind spots where the team had no visibility of attacks executed on high-privilege user accounts and critical systems. As a result, we were able to target the customer’s Azure AD environment and on-premises AD sync server and extract credentials and other sensitive data, without being blocked or detected.
We demonstrated that insufficient logging meant these attack techniques were not detected and make recommendations on the changes needed to close these gaps in their defenses.
Inability to detect certain attack techniques:
On this test we noted that many early warning indicators such port scanning, password sprays through the network, and even impossible travel events (such as users logging on in multiple countries in a day) were not raised as alerts. As a result, we were able to create an antivirus exclusion directory and create new local administrators without raising alerts or full logs of our activities being created.
However, we did observe that the blue team detected some of these activities through their threat hunting activities. This showed some positive proof of the skills within the client’s security team, but the gaps in alerting meant a much slower detection and a risk of it being missed entirely.
Various Log Resources and Owners:
A variety of log sources were managed by different owners or teams through the client’s organization. For instance, endpoints, servers and email management were handled by different security vendors, while their in-house team managed other security products independently. This decentralized approach resulted in inconsistencies and blind spots and posed challenges for the client to efficiently manage and analyze their logs.
As a result, the blue team struggled to quickly triage alerts, correlate events, and identify attack patterns, leading to delayed threat detection and response. This lack of centralized visibility prolonged the attacker's dwell time, increasing the risk of potential data breaches or security incidents going unnoticed.
Limited Command-Line Visibility in EDR Detection
During the engagement, we identified that the client’s End point security solution had no detection rules configured for and alerting on command-line-based activity, leaving a blind spot in the organization’s security monitoring.
We also observed that raw logs in the client’s end point tool were retained for 14 days, but only EDR logs that generate an alert were sent to the SIEM. Hence, command-line arguments were not being adequately captured. As a result:
- Living-off-the-Land (LotL) attacks using built-in tools like PowerShell, WMIC, and CMD.exe were not generating sufficient telemetry for effective threat detection.
- Adversaries could execute encoded or obfuscated commands without triggering alerts, making it difficult to track initial access, persistence mechanisms, or lateral movement.
- Threat hunting became significantly more complex, as analysts lacked historical command-line data to correlate and investigate suspicious processes effectively.
This gap increased the risk of stealthy attacks going undetected and delayed incident response efforts, highlighting the need for enhanced EDR configurations, extended log retention, and command-line monitoring policies.
All these examples identified gaps in processes or tools that could prevent effective alerting or management of a security incident. However, tweaks to attack detection tools or configurations made as a result of the findings from a Purple Team exercise can make a significant improvement to your security posture.
Why should I take a Purple Team exercise?
For those organizations that invested significant resources into Security Operations Centers (SOCs) and advanced security tools, Purple Team exercises are the best way to test their effectiveness against real world attack scenarios and identify where improvements can be made.
Talk to us today about how we can help you improve your security posture through a Purple Team exercise.
Authors
Akshay Sudan – Principal Consultant – Claranet Cyber Security
Akshay is a security consultant specializing in network, red and Purple Team engagements. He has led cybersecurity teams and project engagements with leading financial institutions worldwide. As passionate about research as he is about his hands-on security practice, he builds state of the art custom toolkits for security testing and defined numerous testing methodologies.
Pratik Shah, Technical Director – Claranet Cyber Security
Pratik is an information security enthusiast with a strong interest in infrastructure penetration testing and web application security assessments, which has led to extensive penetration testing experience for Fortune 500 companies involving web applications, networks, infrastructure, device testing, red and Purple Team work. He’s trained at Black Hat events worldwide and leads a large team of cybersecurity trainers, consultants and researchers.