The under-appreciated value of Purple Teaming

Purple teaming exercises can be incredibly valuable in terms of providing real-world improvement to an organisation’s security posture. Even within the realm of ‘adversarial simulation’ (red team, purple team, attack path mapping, and attack surface management, for example) purple teaming stands out in how advantageous it can be in raising security standards. 

Of course, different projects serve different purposes. For example, if you’ve recently released a new 2024 marketing website that is an entirely new code base then it 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. 

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 article might help you understand the myriad benefits of purple teaming. 

What is Purple Teaming?

Purple teaming gets its name from the combined effort of blue (defensive) and red (offensive) teams. While 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?

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 trying 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 your goals while remaining undetected. Having identified the path 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 will not attempt to circle back after having achieved your goal and see if there were other routes that could have got you there. 

This is where purple teaming has a distinct advantage in terms of coverage. Without the pressure of ‘getting burned’, purple teams can openly validate several potential attack paths to achieve their objectives, providing several learning opportunities at each attack phase. 

A red team will generally deploy the most sophisticated tradecraft at its disposal to avoid detection. Depending on the security level the red team comes up against, it may dial down sophistication in favour of productivity. 

This is a great approach when mimicking the likes of highly sophisticated Advanced Persistent Threats. What this approach does not lend itself to is covering the ‘low-hanging fruit’, that many more actors continue to find fruitful. 

Ultimately, you don’t need a sledgehammer to crack a nut, and the most advanced and novel Tactics, Techniques and Procedures (TTPs) are not the culprit for the vast majority of successful cyberattacks. 

Taking command and control (C2) frameworks (such as Cobalt Strike, Sliver, Havoc, Mythic) as an example, 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. 

While detection of modern TTPs should be tested, it is remiss not to take a step back and try some vanilla (unaltered or default) payloads from the most used C2 frameworks. Purple teams can do this. These payloads are likely to be leveraged by many actors, versus a custom payload, specifically written 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 abused C2 framework, or a custom implant you are likely never to see again.

Understand and test your tooling

How often do your defensive security teams get the opportunity to validate that their suite of tooling is working as expected? 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? 

This does not happen as often as it should and maybe 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. While 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 made more difficult if the red team packed up and left two weeks prior to the client receiving the report. 

One example springs to mind, demonstrating this: in a recent purple team test environment, we discovered a security tool designed to detect password spraying and pass-the-hash attacks was not operating as expected. This detection gap was raised with the client immediately. 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. 

Knowledge sharing and improved collaboration

One of the distinct outcomes of this recent 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. It’s easy to lose count of the number of messages firing back and forth between teams about particular security controls, their configurations, potential solutions and general observations. 

For certain, this prolonged period of collaboration and knowledge sharing will grow to underpin JUMPSEC’s relationship with this client. Purple team engagements are a hugely overlooked security exercise. While every red teamer wants to get a shell externally and escalate privileges to domain administrator, this formed just one small facet of our most recent purple teaming engagement. 

In just six short weeks we triaged and tested some of the most worrisome security concerns across an organisation's entire external, third-party, and internal estate. 

So next time you are looking to ascertain your security posture, please consider purple teaming.