This slide comes up a lot for defenders to change how they’re approaching the problem of identifying the adversary.
This is helpful to change the red teamer’s frame of mind as well. As a red teamer, you need to be thinking, refining, expanding your TTPs and Tools rather than simply thinking about domain names, hash values, binary strings, etc. These are important to consider when creating payloads and planning operations, but they should be second nature by now to randomize them all the time.
What is needed for this kind of language to work well for purple teaming?
It means that red and blue need to be able to communicate effectively to articulate what happened in a test and the results
It means that there needs to be a way to talk about what was done during a test so that it’s repeatable
And it means that the language needs some way to measure improvement between tests
We like to use ATT&CK for purple teaming.
ATT&CK is Adversary Tactics, Techniques, and Common Knowledge
We have a small sample of it here. There are currently 11 Tactics across the top - each one refers to a ‘goal’ of the attacker. This equates to the reason why an attacker is doing any given technique.
Down each column are different techniques that achieve that tactic. These techniques equate to what the adversary is doing (creating services, using WMI for persistence, dumping credentials, etc).
If you just glance across the different techniques we have listed, you’ll notice something start to jump out - these are descriptions of adversary behaviors, not indicators of compromise. The same holds true for the information we capture about different threat groups on ATT&CK - we tie everything back to behaviors.
We focus on adversary TTPs and behaviors because that’s the hardest thing for an adversary to change.
Ok, so we talked about a common language to use, but ATT&CK is getting pretty big! We’ve scoped the realm of the possible down to the realm of the probable, but can we start to prioritize a bit more from there? We sure can! This is where we start doing Adversary Emulation, or sometimes called Threat-based Red Teaming.
In our case, we don’t want to just look like advanced adversaries, we want to look like a very specific adversary. We want to look like the adversary you’re most likely going to face (based on your industry, your company, your past incidents, etc) so that we can prioritize working on defenses for those techniques first.
Remember, this is a prioritization mechanism to help frame where you should start working on defenses and forcing your offense and defense to work together to build stronger behavior-based defensive measures.
Ok, this is cool, but how can I do this adversary emulation thing you describe?
We like ATT&CK, so we do this adversary emulation thing with ATT&CK (and we already have one example here for you).
More emulation plans to come, and we welcome all community additions or edits to the emulation plans (email email@example.com)
We break it down into 5 steps for doing adversary emulation.
For this first step, Threat intel acquisition, consider the following
Start by simply googling the name, but then start following the leads
You should also gather info on the tools that adversary uses
Aliases is a really hot topic in the threat intel community right now, and I'm not going to throw that into the mix of what we're covering today, but just keep that in mind as you start searching for reporting.
Threat intel is also binned into broad categories like campaigns, so be sure to look into those as well.
Lastly, keep in mind when these reports are released. Reports about an adversary 5 years ago shouldn't carry as much weight as a report released yesterday.
Lets take a few examples to see how this looks in practice.
Here's a report on APT3, and you'll see right here at the beginning it refers to them as Buckeye. Lots of times these aliases are indicated front and center in reporting.
Remember when I said to not forget campaigns? Operation Double Tap and Operation Clandestine Fox are both attributed to APT3, or UPS.
Sometimes these aliases start to get a little conflated though, so you need to be careful
Here we see the APT3 group referred to as 'Pirpi', which is actually the name of one of their tools. Because of this, it's sometimes hard to differentiate between what the behavior of the group is vs the behavior of a tool
So, we've gathered a bunch of threat intel. Cool. Now what?
In step 2, we need to actually go through that threat intel to figure out what the behaviors are, determine capabilities, and establish motives.
There are a few things to keep in mind as we go through this next piece:
the what, the why, and the how
This is one reason why it's nice to use ATT&CK because it captures a lot of this information already in its TTP format
There are three main kinds of reporting I see with information needed for Adversary Emulation:
Prose writing in paragraphs (like you see here)
In-depth analysis of specific malware samples (which you'll see next)
Prose writing of specific malware samples (somewhere between the two and that's our last example)
So, how do you approach something like this, and what is interesting for you as a red teamer wanting to do adversary emulation