Emulation Planning for Purple Teams - 

Student Guide 
 

 
 

Table of Contents 
Why Are We Here, Again? 6 

What You’ll Learn 7 

What’s In It For You 8 

Background & Orientation 9 

What is it, Actually? 9 

Technique Selection 13 

Threat Selection 13 
Emulation Patterns 20 
Technique Pairing 25 

Aligning to Defenses 29 

Defense Pairing 29 
SIGMA Rules 32 

Lab: Emulation Planning 39 

Your Next Steps 40 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
"All right. They're on our left, they're on our right, they're in front of us, they're behind us ... 
They can't get away this time." 
  
-LtGen Lewis B. “Chesty” Puller, USMC 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

 
 

 
 

Why Are We Here, Again? 

Because this is the Fun Part 
Planning emulations is the best of both the red teamer’s art and the blue 
teamer’s science. It’s a chance to see things happening at the point of 
interaction and truly gain an appreciation for the complexity and nuance of 
our field 
 
Because this is how we Win 
These plans represent a leap forward in how security teams perceive their 
environment and jobs. I’m not the first to do it and you won’t be the last, but even 
getting to this point as an operational reality demonstrates a maturity of craft and 
organization measurably greater than before doing so. 

Because this is how we move forward 

Emulation is the foundation of purple teaming, and purple methodologies are the 
foundation of being threat informed defenders. 

 
 

 
 

What You’ll Learn 

In this hour and a half long course you are going to learn: 
1) How to select relevant TTPs to emulate 
2) How to pair those TTPs with defenses 
3) How to design emulation plans to your needs 
 
We will be learning these different topics through a combination of instructor 
lecture, instructor provided text, lab, and a final assessment at the end of the course. 
You will need to get at least an 80% on your assessment to pass this course. 

 
 

What’s In It For You 

A new skill in a rapidly expanding field of security 
Knowing how to assess your defenses in a meaningful and measurable way isn’t the 
kind of thing that needs explaining as far as usability goes. 

Certification 
Once again, there’s a certification involved, but for Purple Teaming Level II you’ll 
need to complete both this and PT201: Threat Alignment. 

CPE Credits 
We’re Still partnered with ISC(2) and you’ll receive CPE credits once we’re done! 

60-Day Free License For AttackIQ 

If you don’t have one from PT101, we’re offering this so that you can put these 
courses into action. There’s fertile ground for a savvy operator to use an enterprise 
grade BAS platform for free after taking these courses—just saying. 

 
 

Background & Orientation 

What is it, Actually? 

 
Adversary Emulation is actually really simple. It’s the practice of picking out attack 
techniques that present a relevant threat to your organization and throwing them at 
the defenses you think should stop them.   
 
Then you do it again. 
And again. 
And again, and so on and so forth until you’ve hammered your defensive 
architecture into the steel you need to defend your mission. 
 
Put simply, it’s the operational testing and validation of defenses against relevant 
threats. 
 
 

Context: Evolving a Threat-Informed Defense 

 
 
Here’s a familiar diagram-the threat informed defense cycle we talked about in PT 
201. This is how I’ve come to understand the major muscle movements involved in 
maintaining a defensive capability set that’s flexible, current, and relevant—and 
therefore effective. Last time we focused on Orientation and Modeling as our means 
of aligning ourselves to the threats most likely to impact our mission. Today, we’re 
stepping forward. 
 
 
 
 
 
 
 

 
 
We’re picking up where Threat Alignment left off: with a threat model and profile of 
our organization and the threats to it. This is the raw contextual information from 
which we’re going to distill an emulation plan. 
 
 

 
 

Process Outputs Supporting Emulation Planning 

 
The key output from the Modeling phase is that threat profile I keep mentioning. It’s 
the layout of who would want to kick over our server racks and how they’re likely to 
try. 
 
Emulation Planning is that red arrow, the process of pulling out the actual 
techniques the adversary would try and determining just how we intend to stop 
each one. Actually emulating stuff happens next and that’s what gives us the goods: 
a mitigation plan for all the holes we just found i.e. what’s broken and what to fix first 
and how.  
 
 
 
 

 
 
 

Technique Selection 

Threat Selection 

Telling a Story 

 
What we’re doing here is taking the storyboards and writing the script to make it 
real. Not that kind of script. Movie Script, but one where the hackers have day jobs 
and have to listen to that sweet industrial techno with headphones on so they don’t 
wake up their neighbors. 
 
The idea is to fill in the blanks between initial access and Profit—MITRE ATT&CK gives 
us set of easily visible guideposts for this process. Now, running every tactic in 
sequence isn’t the only way to do this as you’ll see later, but it’s the best place to start 
because it forces you to consider all aspects of your defense as they interrelate. 
 
 

Employing Threat Models 

We derive our Emulations first from a threat profile generated during threat 
alignment. That process begins with determining our centers of gravity, the things 
that if broken, compromised, or otherwise get messed with too hard, will cause us to 
fail all or a significant portion of our mission as an organization. Next, we figure out 
the critical vulnerabilities which, if exploited, can cause the center of gravity to fall 
over. Then it’s picking out who’s most likely to come at that center of gravity and 
why. Last is describing possible courses of action for those baddies based on 
rationale and means of attack. Rack and stack those and we get Most Likely and 
Most Dangerous Courses of Action (COAs). Keep in mind that MLCOA and MDCOA 
are starting points— and while there’s a lot of ground to cover yet even after 
addressing the most relevant threats, we have to start somewhere both impactful 
and easy to communicate the benefit of. These COAs are the basis of our Emulation 
plan as you’ll see presently. 

 
 

COAs into TTPs 

The courses of action generated from threat profiling describe possible means of attack against
our organization/mission but in general terms—we have to go deeper.

Let’s take the COAs from our Threat Alignment lab. We have Anonymoose coming at our
production figures, That Jerk Dave “totally not meaning to click” a spearphishing link and
exposing our customer details, some nation state cyber ninjas causing a unnatural disaster, and
a bunch of multiclassed nerd-thieves holding our IP for ransom. Now as bad as a facility full of
steel cylinders leaking Uranium Hexafluoride would be, I’d judge COA 4 to be at the most
threatening off the bat given its relatively high severity and likelihood.

We break this down into techniques by looking for 2 things: Intelligence describing things
they’ve done in the past, and detailed specifications of tools they’ve been known to use or
could be used to do what they did. Attributed reports of what our assessed threat actor has
done as well as reports concerning attacks on similar organizations to our own give us
invaluable context for the threat’s behavior and habits of action. Breaking into the tools is
where we get our listing of TTPs. Most actors use a combination of custom tools and stuff
we’ve all seen e.g. cobalt strike, mimikatz, and tor—all of which are thoroughly documented.
But where would you find this kind of information and make sense of it? I dunno, really.
 

More On TTPs 

Let me simplify even further. To get good techniques out of your threat profile, ask these
questions:

How has it been done?

How Can it be done?

The answer to the first question should look like a list of the techniques your actors have used
in past attacks. The answer to the second should look like a list of tools that provide the ability
to execute those techniques. Spending time researching the second question is critical because
adversaries are flexible. Not only are they likely to swap tools for better OPSEC while achieving
the same ends, but they’re not the only ones coming after you. Our profiling will never be
comprehensive and this is how we increase the “Area of Effect” of our emulation plan. Check
out ATT&CK!
 

In the Details 

There’s going to be a ton of information. Techniques galore to choose from, but at the end of
the day what you need are commands to run on your platform of choice to give you a real look.

The emulation plan is your execution checklist, but it’s a guide. Your tool tables give you
context and options but you’ve got to pull out the no-joke-does-stuff-stuff. You should break
down all the way to a full menu of commands, what they do, and which technique they
implement.

 
 

Tool Tables 

What a tool table? Exactly what it says on the tin. List out the tools your threat has used and
add in any others that can implement the same techniques.

 
 

 
 

List TTP-implementing Commands from Tools 

Once you’ve scoped out your exercise, break out the functions and capabilities of the tool into
actual implementations. Here we’ve got 3 options to emulate every capability resident in the
OSInfo discovery tool used by APT3 and others (and you only have to pay for one of them).

You won’t generally be able to just run malware in your environment—red teams approach this
but remember that they’re experts who refactor legitimately bad stuff into safer versions in
addition to custom development. Even then, you want to run the same emulation in a slightly
different way so as to further tighten your defenses against that technique. Does this mean
you should go and install Metasploit on your work box? No. It means you can put options on
the table for approval and careful execution.

 
 

Emulation Patterns 

Choosing an Emulation Pattern is when you ask “what specifically do I want to test?”

You’ve probably already asked yourself this question sometime back in orientation and
modeling, but now you’re faced with a list of emulations spanning the entire ATT&CK
framework and have an entire enterprise to test. What to do? Keep getting specific.

 
 

 
 

Emulate All the Things 

First, there’s the classic emulation plan, running the Matrix from Access to Impact. This is going
to give you results, no doubt, but it’s going to take time to plan and scaling it into meaningful
slices of an average enterprise is difficult without a degree of automation.

 
 

Emulate by Data Source 

You could choose instead to take it a piece at a time. What you see here is focused on network
detections. Pick out the techniques from your list that will really stress your snort savvy and
then let the IDS engineers have at the mitigations while you work a host-centric test.

You might choose to emulate against your SIEM rules or log correlations—this would similarly
inform how you choose and order your emulations as we spoke about in the previous section.
 

Emulating By ATT&CK Tactic 

Yet again, you might decide to hammer down on one ATT&CK tactic at a time. Not only do you
get a thorough upgrade to defense against the tactic, but your team gains a great deal of insight
into how adversaries think about each step of their attack process—a 360 win.

 
 

 
 

Emulating By Infrastructure Component/Tech 

Or, and bear with me here, or we can deviate from dogma and let ATT&CK tactics chill for a
round while you test your infrastructure, piece by piece. Active Directory is an EXCELLENT place
to start. You could also check out your password strength with a few different toolsets. Maybe
get a feel for how people are securing sensitive data throughout the enterprise, find shadow IT,
look in on your VPN clients, take a swipe at outward facing services, put your email security
through the wringer, you name it!

 
 

Technique Pairing 
 

Consider the Following: 

The “How” of your emulations and what may detect it at some point during execution and what
you think should detect it i.e. you want to see if you can pick up DCShadow but only have
Mimikatz to execute it with…we all hope that your EDR will stomp that kiwi flat before it does
anything bad, right? What if it Does? And if it doesn’t? Then you’re in a pickle—you haven’t
really tested the control you meant to and if you don’t realize it you’ve likely left open a hole
that really shouldn’t be there.

 
 

Detection Planning 

This highlights the importance of validating your security capabilities individually—you need to
know where something happened and if/where it was caught in order to generate accurate
outputs that support further improvement of your pipeline. Planning in detail where each
emulation should hit and having reasonable confidence that you’re right is a means of ensuring
you don’t make bad assumptions. This situation plays out one of three ways:

The first is what we want to happen: your emulation passes by defenses you don’t intend to
test and ends up caught by the one you’re looking to validate.
The second is also good (remember, failure is success if you fix the failure in post!): your
emulation blows right by everything and you now know you have a hole to plug.
The third is what we should be most aware of: your emulation gets stomped by another
control that you weren’t monitoring closely enough or didn’t intend to do the stomping. You
then need to refactor your emulation to ensure your test is complete.

 
 

Avoid Confusion 

The second situation most often happens with T1059 and that’s for a reason. There’s not much
you can’t do with Command and Scripting interpreters, especially with all the tasty toolkits
popping up left and right for powershell and the like. The problem with T1059 is that it’s all
about capabilities that are either OS-resident or prolific enough in the environment such as to
be saturated with noise. Saying you’re using powershell as your emulation is like saying you’re
bringing in Gordon Ramsay to make lunch. Cool, what’s he making? And when he screams at
you will it be in bright red text on a blue background?

 
 
 

Plan in Detail 

An example of doing it right looks like this. I borrowed this from Alissa Torres (check her out on
twitter!). We can still use T1059.001 (nee T1086) but we have to chain it with what it’s being
used for. In this case, we’re planning on an adversary using it to modify registry keys for
persistence. This requires us to set up a correlation somewhere that’s looking for powershell
commands (which we ARE LOGGING) or process spawns happening within 90 seconds of a
registry key update. This will filter out a bunch of noise and let our analysts apply their
expensive brains to determining next steps.

 
 

Aligning to Defenses 

Defense Pairing 

What’s a Defense? 

First off, you need to know what you’ve got online to catch emulations with. This is 
an output of Threat Alignment, but let’s review: 

IDS/IPS to alert on and control network traffic 

EEMSG to filter and control email 

CASB to manage cloud resource access 

EDR to do that good host work 

EUBA to correlate on user entity behavior 

And SIEM to pull all that data together if you’re so inclined. 

 

Simple Alignment 

In a simple alignment of capability to emulation, a perfectly acceptable method, just 

put down the technique ID and let the red team do their stuff. Tie the technique to 
the tool or defensive architecture component which should be catching your 
emulation and watch them both carefully to ensure the emulation landed--if it 
doesn’t alert you can dig into the tool to see what went wrong. 
 
 
 

 
 

Simple-ish Alignment 

In a still simple but more technical and finely-grained alignment, you can use actual 
commands and functions aligned to specific detection logic or rules associated with 
your tools. In this case, we’ve got a Metasploit command and a SIGMA rule. SIGMA 
rules are really neat because even though they’re specific to log files, they’re at the 
same time incredibly flexible—we’ll talk more about those next. 
 
 
 

 
 

SIGMA Rules 

The SIGMA Project 

SIGMA is A Generic and Open Signature format that allows you to describe relevant 
log events in a straightforward manner. Think of it like yara with files or snort with 
network traffic, but with log files. SIGMA rules are built with a generic format which 
can be translated by a script into a multitude of query languages. It allows the same 
detection logic to be applied to just about any SIEM or SIEM-like platform out there, 
commercial or open source and has accelerated the pace of defenders protecting 
against 1-day attacks and the like. There’s a huge and always growing repository of 
SIGMA rules on Florian Roth’s (the creator) github along with great documentation. 
 
https://github.com/Neo23x0/sigma 
 
 
 
 
 
 
 

SIGMA Rules 

It’s not doctrine, but SIGMA rules are comprised of 4-ish parts. The first is the “what it 
does and who made it” stuff at the top which also offers references to research that 
led to the rule’s creation. The next is a definition of what kind of logs this rule will 
look in to find what’s in the third section, which is the detection logic and search 
criteria for the rule. The last part consists largely of enrichments to the rule’s 
functionality such as custom field definitions, tags, and severity levels. 

   

 
 

Building A Rule 

So let’s build one shall we? Suppose we wanted to look for evidence of 
kerberoasting in our environment. First thing we do is figure out what kerberoasting 
is. Great stuff on adsecurity.org for that so we’ll go ahead and give Sean Metcalf the 
credit he’s due in the reference field. Then we’ll give our rule a title that makes sense 
for what we want it to do and get a unique ID for it. Lastly in this section is a 
description of the rule’s functionality and tags for related ATT&CK tactics and 
techniques. 

https://adsecurity.org/?p=3458 

 
 

Now we define our log sources. In this case, it’s windows security logs. This updates 
the source field in the translated rule so that the SIEM search engine knows where to 
look. 

 
 

Now the meat, our detection logic. The detection field defines a set of criteria 
subject to a Boolean OR condition, or that one statement between detection: and 
condition must be true in the search results for this rule to hit on a log.   

The selection field similarly defines a Boolean AND condition wherein everything 
within that field must be true for the selection: statement to be true. Reduction: 
defines another field which allows a Boolean operation at the condition: field. 
Condition overrides some of the logic above by stating that we consider this rule to 
have hit on something if the selection field is met AND the reduction field is 
specifically NOT met.  

In this case, we’re looking for security logs with event ID 4769, specific ticket options, 
and RC4 encryption specified, but to disregard logs that meet both those conditions 
AND have a service name that starts with $. 

This logic filters out a lot of noise from the security log to let us see only those logs 
which are specifically suspicious with regard to kerberoasting activity. 

 
 

And finally we add some information to help other analysts understand what could 
cause a false positive and give this rule a priority level of medium because a hit has 
some chance of being benign but still deserves a hard look. 

 
 

Some Tips 

When you emulate, be ready for defenses to fail—that’s the whole idea. Factor in the 
time it will take, technical issues, and having enough people to do it right. 

Start small with a modest emulation plan and build complexity as you smooth out 
your organizational wrinkles 

Pain points are your tough-love buddy who just wants you to be better. 

Document everything you do 

Don’t stop—you’ve taken a step not every security shop is willing to. Let this build 
itself into the program it needs to be. 

 
 

Lab: Emulation Planning 

 
 

Lab Instructions: 
 

 
Using the Scenario Handbook and Lab Materials: 
 
1) Select a COA from the Threat Profile 
2) Choose an Emulation Template and fill it in! 
3) Pick out some SIGMA rules instead of defenses if you’re 
feeling frisky 
 
 
 
 
 
 
 
 
 

 
 

Your Next Steps 

Assessment Test 
Your next immediate step is to take the assessment for this course.  

● The assessment can be found in your student portal. 

● You must get at least an 80% to pass this course and will be able to attempt 
the test twice. 
● If you do not pass the first time, you will have to wait 24 hours before taking 
the assessment again. If you need assistance with the assessment outside of 
this instructor lead training, please email academy@attackiq.com 

Digital Credentials 
After you pass the assessment, you will receive your digital credentials through the 
Credly Acclaim platform​. 

Digital credentials are the badges you may have seen people sharing on LinkedIn. 

Digital credentials go beyond paper certificates. They are portable, verifiable, and 
uniquely linked to you. They also ensure that your hard-earned achievements are 
owned by you, not us - you can access and utilize your digital credential whenever, 
however you see fit – including adding it to blockchain. Digital credentials make you 
and your achievements - more visible to employers and your professional network. 

 
  

Share Your Achievements with Your Network 

Your skills, competencies, and certifications are worth more than a static bullet point 
on a resume or a paper certificate hanging on the wall in your office. When 
represented as a digital credential, you can share your achievements with your 
network in one click from Credly’s Acclaim platform. Peers and employers can verify 
and learn more about what it is you can do thanks to earning a digital credential 
from AttackIQ. And research shows that professionals who share their digital 
credentials to professional networking sites are discovered by employers, on average, 
six times more often than those who do not. 

Share Your Knowledge With Your Network 

If you enjoyed this course, please tell your colleagues about the AttackIQ Academy 
and share with them the things we’ve discussed today. 

Share Your Opinions 

The survey is optional and doesn’t affect your course results. However, if you do fill it 
out we will send you an AttackIQ Academy t-shirt. 

Get After it 

Grab the templates off the student portal and see what you can do! 
 

 
40