Skip to main content

Having recently finished an extensive and eye-opening purple team engagement, I took some time to reflect on the sheer amount of ground that we had covered in just 6 short weeks. 

To summarise, over that time we conducted an in-person threat modelling session to identify known security concerns across an organisation’s entire estate, generated hundreds of individual test cases off the back of that session, then moved to the execution phase in which we exploited externally facing servers to gain remote code execution, moved internally to validate more test cases, and got domain administrator in the process. 

This inspired me to write a blog post about how incredibly valuable purple teaming exercises can be in terms of providing real-world improvement to an organisation’s security posture. I am framing this having served as a ‘traditional’ penetration tester for several years prior to working in a purely ‘adversarial simulation’ role here at JUMPSEC. Even within the realm of ‘adversarial simulation’ (red team, purple team, attack path mapping, attack surface management, etc.) I believe purple teaming to be an outlier in how advantageous it can be in raising security standards. 

Firstly, I should preface this bold statement by explaining that different projects serve different purposes. For example, if you’ve recently released a new marketing website that is an entirely new code base then you would be best to pursue a penetration test, with the scope limited to just that new application. On the other hand, if you have been consistently spending on improving your security posture for a sustained period and want to assess how this has affected the true exploitability of your estate, then a covert red team would best answer that question. In fact, there are plenty of reasons why you would look to perform a red team engagement, many of which overlap with a purple team project. If you are deciding between the two approaches, have never solicited a purple team project, or are simply interested, then this blog post might open your eyes to the myriad benefits of purple teaming.

What is Purple Teaming?

Purple teaming gets its name from the combined effort of both the blue (defensive) and red (offensive) teams. Whereas a traditional red team engagement would see the red team working largely in the dark and attempting to remain undetected, a purple team is a collaborative effort. Full transparency is required between both teams and a near-constant communication flow is advised to allow both sides to work in tandem to improve technical controls, understanding of tooling, and much more.

Why Purple Teaming?

So with an understanding of what a purple team project looks like I would like to draw your attention to some of the key advantages of such an engagement.

1. Cover many paths, not just the path of least resistance.

Picture this: you are on a red team engagement. You are unsure how sharp the opposing blue team is when it comes to detecting your presence in their network. One noisy command here or common tool there and you could have blown your cover, causing your engagement to be burned and, in some cases, marking the end of the exercise. You are there to try to achieve an objective, whether that be ransomware, stealing intellectual property, exfiltrating client data, or otherwise. 

Naturally, in high-pressure scenarios like this you will take the path of least resistance to achieve your goal. A successful project will see you achieve all of your goals whilst remaining undetected. Therefore, having identified the path you would like to take to achieve your goal you will, in most cases, attempt to get there with the least chance of tipping off the blue teamers to your presence. You most certainly will not attempt to circle back after having achieved your goal and see if there were other routes that could have gotten you there. 

This is where purple teaming has a distinct advantage in terms of coverage. Without the pressure of ‘getting burned’, purple teams are able to openly validate several of the potential attack paths to achieve their objectives, therefore providing not just one learning opportunity, but several at each phase of the attack.


2. Broad coverage – not just the ‘sophisticated’.

In a similar vein to the above-mentioned predicament, during typical red team engagements it goes without saying that a red team will generally deploy the highest sophistication tradecraft at their disposal to avoid detection. Depending on the level of security that the red team comes up against they may dial down their sophistication in favour of productivity. 

This is a great approach when mimicking the likes of highly sophisticated so-called Advanced Persistent Threats. What this approach does not lend itself to covering is the ‘low hanging fruit’, that many more actors continue to find fruitful. Ultimately, you don’t need a sledgehammer to crack a nut, and most advanced and novel TTPs are not the culprit for the vast majority of successful cyber attacks. 

Let’s take command and control (C2) frameworks (such as Cobalt Strike, Sliver, Havoc, Mythic) as an example for this particular point. Due to the plethora of security controls and products in most mature environments it is becoming increasingly difficult to establish communication channels with compromised machines. To combat this, many threat actors are seeking novel command and control (C2) frameworks, custom implants, obfuscation and evasion, and obscure payload types. On the aforementioned purple team engagement we recognised that whilst detection of modern Tactics, Techniques and Procedures (TTPs) should be tested it would be remiss of us not to take a step back and try some vanilla (unaltered or default) payloads from the most commonly used C2 frameworks. These are the payloads likely to be leveraged by the majority of actors, versus a custom payload that has been written specifically for that organisation. 

Ask yourself which you would rather ensure you have detections and protection from: a default or lightly customised payload from the most commonly abused C2 framework, or a custom implant that you are likely never to see again?

3. Understand and test your tooling.

Another rhetorical question…how often do your defensive security teams get the opportunity to validate that their suite of tooling is working as expected? Furthermore, do they regularly get the opportunity of seeing known-positive attacks taking place in their environment from which they can dial in their tooling, reduce false positives, and build detections to cover gaps in their detection and monitoring? 

My experience suggests this does not happen as often as it should do. This may be the single greatest benefit of a purple team engagement. 

Typically for a red team engagement, a full list of attacks carried out with time stamps may (should) be included as an appendix in the final report. Whilst this is advantageous, it does not offer a complete solution. Often, test cases need repeating several times before high-fidelity detections can be created, a feat which is made even more difficult if the red team packed up and left two weeks prior to the client receiving the report. 

One example springs to mind to demonstrate this: we discovered that a security tool designed to detect password spraying and pass-the-hash attacks was not operating as expected. This was raised with the client immediately after it became clear there was a detection gap. Both teams worked collaboratively to identify the root cause of the issue and make iterative improvements. At every stage we (the red team) repeated the attacks and awaited feedback. Within an hour or so we had successfully debugged the root cause, remediated the issue, and the client could rest easy that if someone was password spraying in their network they had high-fidelity detections in place to catch them. Talk about an immediate security enhancement!

4. Knowledge sharing and improved collaboration.

To refer back to the project which inspired this blog post, one of the distinct outcomes of the engagement was the incredible amount of knowledge sharing and collaboration between the two security teams. There was near-constant communication between both sides about activities performed, observations and vulnerabilities discovered in real-time, conversations around how certain attacks were performed or detected, and much more. 

To quantify the improved collaboration and trust between the two teams both during the engagement and continuing forward is difficult. I lost count of the number of messages firing back and forth between the two teams about particular security controls, their configurations, potential solutions, and general observations. 

I believe this prolonged period of collaboration and knowledge sharing will grow to underpin JUMPSEC’s (or at least my!) relationship with this particular client. It was foundational in building a good relationship with a client who I had not had the pleasure of working with until now, and opened many doors for future collaboration down the line.


Speaking (writing) plainly, I feel that purple team engagements are a hugely overlooked security exercise. Whilst every red teamer wants to get a shell externally and escalate privileges to domain administrator, this formed just one small facet of my most recent purple teaming engagement. In just 6 short weeks we triaged and tested some of the most worrisome security concerns across an organisation’s entire external, third-party, and internal estate. We did so in an open and comprehensive manner, and both teams walked away the wiser for the collaborative approach which is inherent, and essential, to a purple team project. 

I hope this blog post has opened your eyes to the wide-reaching reasons to consider a purple team exercise, and thank you for reading!

Max Corbridge

Max Corbridge

Head of Adversarial Simulation

As Head of adversarial simulation, Max leads the team, delivering adversarial simulation projects such as red and purple team engagements.