Purple teaming gets its name from the combined effort of both the blue (defensive) and red (offensive) teams. Whereas a typical 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 a basic understanding of a purple team, let’s draw your attention to some of the fundamental differences compared to other adversarial engagements.
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 blow your cover, causing the engagement to be burned and, in some cases, marking the end of the exercise. You are simply there 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 almost 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 and realistic coverage – not just the ‘sophisticated’.
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’ or APTs. What this approach does not lend itself towards 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.
We recognise that whilst detection of modern Tactics, Techniques and Procedures (TTPs) should be tested, it would be remiss of us not to 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.
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? This happens nowhere near as frequently as it should, making it perhaps 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.
For instance: in a recent engagement we discovered 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.
A final distinct outcome with a purple team engagement is the incredible amount of knowledge sharing and collaboration between the two security teams. There is near-constant communication between both sides about activities performed, observations and vulnerabilities discovered in real-time, conversations around how certain attacks are performed or detected, and much more.
To quantify the improved collaboration and trust between the two teams both during an engagement and continuing forward is difficult, however, on average JUMPSEC:
- Define and validate approximately 30 attack paths (10 internal, 22 external)
- Simulate over 100 common TTPs across all phases of the MITRE ATT&CK framework (mapping new test cases on TI, 7 external and 56 internal)
- Create and validate 63 custom test cases related to the clients critical assets and greatest concerns
- Discover ~20 previously unidentified vulnerabilities
- Create and validate ~35 customs detections in the client estate
- Identify a further 20 detection opportunities for future exploration
Furthermore, internal security teams do not wait for our technical report to address our findings. Several security gaps can be fixed as they emerge in tandem, without disrupting the flow of a typical adversarial simulation.
How long does a Purple Team take?
Naturally this varies greatly depending on the size and scope of the organisation. However, in a number of weeks we can triage and test some of the most worrisome security concerns across most organisation’s entire external, third-party, and internal estate. We can achieve this in an open and comprehensive manner, with both teams walking away the wiser for the collaborative approach which is inherent, and essential, to a purple team project.