This post was inspired by Florian Roth's / (cyb3rops)'s / (Neo23x0)'s post, "
The Problems with Today's Red Teaming". I have put a lot of thought into those issues and want to offer methods for people to improve their red teaming. This type of adversarial testing has many names, but for the sake of this post and simplicity we are just going to sum it all up as "
purple teaming". I've used these methods to both write new alerts and hone blue team skills; I do this regularly in my practice, and have seen these methods improve defenses time over time. I just put out a
piece looking at doing indepth threat emulation, I put out
a workshop on purple teaming this year, and I'm planning on an upcoming and cooperative, macOS purple teaming series. I really believe in these methods, in terms of honing a blue team's effectiveness, writing better alerts through greater attack understanding, and working together as one team, with one objective. Let's look at some of Florian's issues with purple teaming from his article. His major points are bulleted bellow, followed by some of my advice on each:
- Single Point of Failure or a Singular Kill Chain
- Aka too much depth and not enough breadth
I suggest using atomic testing to both lay out all of the techniques you are interested in and to break down each technique in its most simple way. This can be as simple as a spread sheet, wiki page, or knowledge base covering each technique, or as complex as an automated framework like
VECTR. Once each of the techniques are broken down in a basic manner, I like to iterate on the procedures and generate many variations on the same technique. This is really useful for making sure you cover every technique in some way. Later when you go to build your kill chain/s, you can select from a variety of techniques and procedures at each stage in the chain. You can continue to build on this over time, testing response times or performing blind tests after you confirm you have telemetry and your team knows how to respond to these incidents in a controlled manner. You can take this even further by automating and randomizing the techniques or procedures used week over week. Proper threat modeling can help them pick the most likely techniques for your atomic research pool, more on this later.
- Focus is on the Kill Chain
- Aka not enough context in the execution
This is a fair argument in regards to a lot of the adversarial testing I've seen. When building the kill chains it's important to pick some techniques which will be detected and some which won't, with a focus on the alerts and techniques that you are trying to hone. This can include a lot of supplemental techniques, such as persisting or collecting data that many never be used. Often times you need context in regards to an alert, albeit other processes in a tree or other actions having executed in a short time period, which gives the end to end testing far different weight then all of the previous atomic testing. Don't be afraid to make mistakes in the kill chain execution or leave mistakes in your malware, even a mistaken attempt at a technique can provide insight. In that regard, I like to pack my kill chains with as much as possible, making them rich, contextual adventures to explore; personally I think this makes it more fun as an analyst. Again, the goal is not to disappear and leave the blue team guessing, but to highlight and call out the techniques they care about in a meaningful way. I also try to automate as much of this as possible, using tools like
gscript where possible, so that people can do on-demand retesting with or without me operating.
- Incomplete Simulations
- Aka red teams don't actually emulate threat actors
Threat modeling your industry or other victims in your vertical can help you narrow down your specific threat actors. You can look at the reported techniques those threat actors employ to help get a better idea of the exact techniques you can emulate. I talk about this a lot in my
recent post on threat emulation. Proper threat emulation often requires a lot of threat intelligence research and reverse engineering, to get a deeper understanding of the target's techniques and procedures. I've also been known to both neuter or re-purpose my target threat actor's malware and tools. While being one of my favorite ways to emulate an actor this can also have its own limitations in later stages of execution. Unfortunately this level of recreation is often a matter of red team talent and skill. If your red team isn't technically up to snuff they won't be able to emulate the same or more advanced capabilities. On the flip side, a great red team will be highlighting all of the strange things the target actor's malware does, things that stray from the normal like this can often be exploited for detection. Finally, it's important to not over-fit a single threat model. Being flexible, unless you know a specific threat is targeting you, will likely get you more longevity.
My biggest piece of advice is don't make this adversarial. Use the red team as a type of threat intelligence or technique research group, and get them to do the work you want in exploring specific techniques. Get them to help you write the rules and alerts you want. Refocus them on areas your interested in getting a better understanding in or want to hone your detections. That said, it's probably a good idea to listen to them if they keep bringing a specific threat or technique to your attention. By hindering the red team you are just hindering your own ability to train and go deeper on different techniques. Finally,
as Daniel Miessler says, a purple team is often a solution to a communications breakdown. If a red team and a blue team are already working together well, there is almost no need to introduce a purple team.
