TTP Implementation Process

Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
or

Already have an account? Sign In »

Time
8 hours 5 minutes
Difficulty
Intermediate
CEU/CPE
9
Video Transcription
00:00
>> We're now on Lesson 4.2,
00:00
the TTP implementation process.
00:00
We have one key objective for this lesson.
00:00
We will describe the process
00:00
for implementing adversary TTPs.
00:00
On this slide, we introduce
00:00
our process for implementing adversary TTPs.
00:00
But why do we need this exactly?
00:00
Well, I'll share from experience that
00:00
implementing adversary TTPs is difficult.
00:00
It's deeply technical and
00:00
you also have to balance many constraints,
00:00
including available CTI,
00:00
making sure you satisfy your engagement objectives,
00:00
also making sure that you complete
00:00
your work on time and more.
00:00
There's a lot of conditions that can derail you.
00:00
One of the ways of staying on track
00:00
involves following a repeatable process.
00:00
This diagram shows the process we commonly follow up
00:00
MITRE to implement adversary TTPs.
00:00
We find it helps us conduct
00:00
realistic adversary emulation engagements
00:00
and we also augment it to be repeatable and automated.
00:00
As we go forward in this lesson,
00:00
we'll explore each of these steps in detail.
00:00
The first step in the TTP
00:00
implementation process is planning.
00:00
Specifically, we're planning how
00:00
we will implement the TTP.
00:00
Usually during this step,
00:00
I like to start by reviewing
00:00
the adversaries attack page focusing on
00:00
the specific TTP of interest and
00:00
also following any referenced to CTI articles.
00:00
As I'm processing this information,
00:00
I'm focused on trying to understand why
00:00
the adversary use the TTP in the first place.
00:00
I'm also trying to understand how exactly
00:00
the TTP was executed in the wild.
00:00
For example, was it a script,
00:00
was it a binary,
00:00
was it a legitimate system administrator tool
00:00
or perhaps custom malware?
00:00
I'm also trying to evaluate
00:00
what dependencies might exist.
00:00
As an example, maybe it's a TTP
00:00
that requires Microsoft Office functionality.
00:00
I've also add that as I plan my implementation,
00:00
I like to consider the relative value against
00:00
the level of effort required to implement the TTP.
00:00
Some questions to help drive this analysis include,
00:00
does this TTP help satisfy my engagement objectives?
00:00
Is there enough CTI?
00:00
How complex is the TTP?
00:00
That's because if the TTP is fairly complex,
00:00
you could expect it will likely take a greater time
00:00
and effort to implement than a trivial TTP.
00:00
Once you have a plan, you're ready
00:00
to start implementing the TTP.
00:00
During this step, we're focused
00:00
on creating both the procedure and
00:00
also any resources needed
00:00
to execute the TTP in production.
00:00
Now you'll find that some TTPs are trivial to implement.
00:00
For example, if you're emulating an adversary who's using
00:00
living off the land binaries think like net.exe,
00:00
all you really have to do is copy and paste
00:00
the adversary's commands into your emulation plan.
00:00
This can also be the case with common public tools,
00:00
things like PsExec or Mimikatz.
00:00
But then you have TTPs on the other end of the spectrum,
00:00
which are extremely complex
00:00
and may not be readily available.
00:00
In that case, you likely have to
00:00
implement the TTPs yourself.
00:00
Now if you want a good example of
00:00
particularly complex TTPs,
00:00
you might want to check out the attack page that
00:00
describes rootkits that have been observed in the wild.
00:00
Now regardless of the TTP you're trying to implement,
00:00
you want to make sure you're following
00:00
the CTI to the best of
00:00
your ability to ensure
00:00
your TTP is representative of the original threat.
00:00
Now one of the things we practice at MITRE is building
00:00
our TTPs so they're both reusable and easy to automate.
00:00
The reason we do this is
00:00
because it can take a lot of time,
00:00
effort, and resources to implement TTPs.
00:00
State it differently, you don't want to
00:00
spend say four weeks
00:00
implementing a TTP just to
00:00
use it one time and then never again.
00:00
We leverage automation to ensure that
00:00
our TTPs are re-usable by different operators.
00:00
How exactly do we use automation in adversary emulation?
00:00
At MITRE, we commonly use automation for everything from
00:00
automated unit tests to setup scripts,
00:00
to execution, and cleanup.
00:00
The idea is that you try to use
00:00
automation to make it as trivial as
00:00
possible for anyone to execute your TTPs end-to-end.
00:00
In that way, you have
00:00
a reusable capability that
00:00
can be used by anyone on your team,
00:00
or perhaps even given to
00:00
the network owners and network defenders as a leave
00:00
behind capability so that they can
00:00
continue to assess their network after an engagement.
00:00
By this point, we've implemented and automated our TTPs.
00:00
The next step is to integrate the TTPs
00:00
into a cohesive adversary emulation plan.
00:00
It's our adversary emulation plan that contains
00:00
step-by-step instructions for emulating adversary TTPs.
00:00
We also take this opportunity to
00:00
package all of our needed setup scripts,
00:00
binaries, cleanup scripts, and so on.
00:00
Basically anything you need to
00:00
execute the emulation plan in production.
00:00
The last step of the TTP implementation process
00:00
is to identify detections and mitigations.
00:00
When you conduct adversary emulation engagements,
00:00
at some point you can
00:00
expect network defenders will ask you,
00:00
"How do we detect these TTPs?"
00:00
I assert that as
00:00
a professional adversary emulation engineer,
00:00
you better have an answer.
00:00
Therefore, before we can declare a TTP finished,
00:00
we first analyze it in an analysis environment.
00:00
It's in this environment that we examine our TTPs
00:00
at runtime using various forensics tools.
00:00
This enables us to identify ways of
00:00
detecting and mitigating the TTPs we're executing.
00:00
It also gives us a better understanding of how
00:00
our TTPs will affect endpoint systems.
00:00
In that way, if a network owner is ever
00:00
unsure about you running particular TTPs,
00:00
you can explain to the network owner how they
00:00
work and the inherent risks and benefits to doing so.
00:00
That brings us to the Lesson 4.2 summary.
00:00
During this lesson we explored
00:00
our process for implementing adversary TTPs.
00:00
In the next series of lessons,
00:00
we're going to shift gears to a series of
00:00
hands-on labs that are designed to
00:00
walk you through this process so you can gain
00:00
experience implementing high-quality TTPs.
Up Next
Planning TTP Implementations (Lab 4.1 Overview)
10m
Planning TTP Implementations (Lab 4.1 Walkthrough)
30m
Implementing Adversary TTPs (Lab 4.2 Overview)
10m
Implementing Adversary TTPs (Lab 4.2 Walkthrough)
30m
Automating Adversary TTPs (Lab 4.3 Overview)
10m