What’s in a name? Thoughts on Red Team nomenclature

In my previous post, I promised to expand on the distinction between adversary emulation, adversary simulation, red teaming, and purple teaming, or at least how I tried to distinguish these terms in a way that made sense to me

Emulation and simulation; I’ve heard both terms used interchangeably to refer to the same type of testing. Erik, who’s author and instructor for the SANS purple teaming and adversary emulation curriculum, once told me that the correct term is in fact adversary emulation, as confirmed by his students in the US. This piqued my interest in figuring out if it might make sense to distinguish between both terms and if so, what each of them might signify. I started out looking for a definition of each of the terms:

Emulate – verb [ T ] ​ /ˈem.jə.leɪt/
To behave in the same way as someone else.

Simulate – verb [ T ]​ /ˈsɪm.jə.leɪt/
To produce something that is not real but has the appearance of being real.

Based on these descriptions, it is possible to differentiate when applying the terms to how an attack is carried out:

• Adversary emulation is an impersonation, mimicking of someone or something else. Based on threat intelligence, you determine APT28 is most likely to target your organization. To emulate this adversary, you mimic the TTPs they use and test those in your environment. You behave exactly like they would.
• During an adversary simulation, you want to make it look like a real attack is happening while there is no real adversary. You make use of TTPs that work in the environment at hand, irrespective of which APT actually uses them. This could be based on the red team’s experience, or using the global most popular techniques. Does this emulate a specific threat group? No. Does this simulate a “real” attack? Yes, to a certain extent at least.

Concrete examples can be visualized using the MITRE ATT&CK navigator. If you wanted to emulate APT28, you could select all of the techniques they use:

When looking at the technique details, it is possible to identify and imitate the threat group’s procedures and how they operationally execute the techniques (e.g. using which tools or exact commands).

On the other hand, when you have performed an adversary simulation and were able to obtain the objectives through a successful kill chain, you can visualize the result using the ATT&CK navigator:

This could be a representation of a simulated threat by using the TTPs that work for that target/environment.

So, as a first axis to clarify nomenclature, we can distinguish between adversary emulation and adversary simulation. Looking back at the previous post, a TIBER test could mostly be considered an adversary emulation, as you use the results of a threat intelligence phase to determine relevant threat actors and create attack scenarios that mimic their TTPs. However, the scenario X that is defined as part of TIBER-BE/NL would more closely resemble an adversary simulation, as it allows you to be creative instead of following the rules set out by another threat group. This is also where the red team approach criticized in Florian’s post would fall under.

Adversary emulations and simulations in the form of red team exercises still have something in common though; perform the test without the blue team knowing it is taking place. This is the second axis where we can make a differentiation: does the red team cooperate with the blue team or not? In a red team exercise, interaction with the blue team is limited or non-existent. The goal is to assess the blue team’s prevention and detection capabilities. In a purple team exercise, interaction with the blue team is maximized to improve on the blue team’s prevention, but mostly detection capabilities.

The big difference here is that a red team exercise allows to assess the blue team’s response procedures and playbooks, which is not possible as part of a purple team exercise. Examples of metrics that you could get from both types of exercises and that can thus be used to track improvement are:

• Red team: time to objectives, time to detection, time to eradication, objectives reached.
• Purple team: number of prevented TTPs, number of detected TTPs, TTPs for which logs are available but no alerting is in place yet. This is visualized below using the ATT&CK navigator.

However, we’re diverging from the original blog purpose, which was to discern red team nomenclature. Based on the distinctions we’ve made above, there are two axes:

• Adversary Emulation versus Adversary Simulation
• Remain undetected versus blue team cooperation

We can try to summarize them using a quadrant that maps these two axes, with some examples or a short description for each square:

In conclusion, I think the distinction between red teaming and purple teaming is pretty straightforward. As for the emulation versus simulation part, I’m sure there will be people who disagree, which is fine. I just tried to make a (perhaps unnecessary?) distinction between both terms to nuance how a red/purple team can be implemented. Looking back at Florian’s post, most of his criticism seems to be aimed at what I call adversary simulation, while he’s advocating to perform more adversary emulation.

About the author

Jonas is NVISO’s red team lead and thus involved in all red team exercises, either from a project management perspective (non-technical), for the execution of fieldwork (technical), or a combination of both.
Next to offensive assessments, he also likes to perform defensive work, allowing him to combine the red and blue points of view, to better understand how both sides operate and obtain expertise in the fields of adversary emulation and purple teaming.
You can find Jonas on LinkedIn