Good evening, Red Team Village. My name is Adam Pennington, and tonight I'm going to
be talking about emulating an adversary with imperfect intelligence.
So before I get into content, I wanted to start off with a little bit about who am I.
So I'm the lead of a project called MITRE ATT&CK. I'm guessing some of you are probably familiar with it.
Several of the other talks in the Red Team Village have been leveraging it.
I've been with MITRE for about 12 years now. If you're not familiar with MITRE, we're a not-for-profit
who primarily runs federally funded research and development centers for the federal government,
and does work in the public interest in things similar to ATT&CK that we're putting out there for people to use.
My principal focus is around threat intelligence and deception, but I've been working with
adversary emulation teams for years on looking at what sorts of intelligence they're pulling together,
and how well the profiles they're building up look like real adversaries.
Most of my time today is spent on MITRE ATT&CK, but I've been an operational defender,
as well as a cyber threat intelligence analyst. I've spent time in multiple security operations centers.
I've been a part of ATT&CK for quite a while, so I've been around since it was a spreadsheet with no ampersand.
ATT&CK originally was an Excel spreadsheet, and I helped gather a lot of the intelligence that we use
to create ATT&CK in the first place. I was at MITRE, I was at Carnegie Mellon for 11 years
trying to collect all the degrees. I'm also a scuba diver. I'm certified for technical diving,
so decompression, rebreather diving. And I've spent time as a professional live sound engineer,
which might explain some of my taste in home audio equipment. I've been around DEF CON for quite a while.
Obviously, first one through home, like all the rest of you.
Some of the key points I wanted to get to today. So I'm going to be looking at a very intelligence-focused
approach to adversary emulation. I want to start off by setting the stage in adversary emulation,
getting into the definition I'm using. Now, I'm not expecting that people here haven't heard of adversary emulation.
I really just want to make sure that we're on the same page using the same definition,
because adversary emulation is something that I've seen mean different things to different people.
I'm going to talk about gathering and extracting the intelligence necessary to do adversary emulation.
Where do we find it? How do we pull it together? And I'm going to talk about some of the flaws in that intel.
So what's wrong with it? How do we recognize some of those imperfections? And then how do we deal with it?
How do we find the gaps in our intel, fill them in, and leverage those to create a complete plan
that we can use to actually emulate an adversary? So I said I was going to start with the definition.
This is the definition of adversary emulation that I'm using for the rest of this talk.
Adversary emulation is a type of red team engagement that mimics a known threat to an organization
by leveraging threat intelligence to influence what actions and behaviors the red team does.
Pretty straightforward. Leveraging threat intel, trying to use that to influence what we're going to do.
So what's different? The big one is that it's driven by threat intelligence.
So it's driven by how the adversary actually looks.
There's a good chance we're going to use that threat intelligence to scope things more than we might in a normal engagement.
So we want things to look like an actual threat.
And so there are things we might not do and take out of our playbooks in order to stick to that.
There's a good chance it follows a constructed scenario in order to stick to what a real adversary looks like.
We might ahead of time create the set of activities, the set of behaviors that we plan to do so that we can keep to that.
And the hope with all of this is that we're getting some idea of how our defenses might fare against a given adversary.
It's still not the real threat. It's still not going to be the same.
But we're hoping to get close enough to start to get some ideas.
So there's a bunch of new challenges that emulation brings in around intelligence.
And I'm going to be covering several of these in my talk tonight.
The first and most basic one, the need for intelligence in the first place.
So needing to know what an adversary looks like.
We might not have enough intelligence out there on an adversary that's in a form we can use.
It might not describe the sorts of activities that we need as an adversary emulation team to go out and look like the adversary.
The adversary we want to emulate, there may just not be enough intel on.
We may not know about them.
And so we might need to fill in the picture a little bit more to be able to really emulate them.
And finally, you know, we're pulling all this intel.
We need to be able to turn it into a workable scenario.
So my team has an adversary emulation process that we've used in several other places in presentations, as well as documents.
But it originally comes from a presentation a few years ago by then ATT&CK team members, Katie Nichols and Cody Thomas.
And the process we work from is to first gather threat intelligence.
So figure out who your adversaries are and start to pull in all the information you can find on the adversary you picked to emulate.
Extract techniques from that intelligence.
So start to look at what the behaviors are in that intelligence, so that we can pull them together into a plan to be able to look like those behaviors.
Analyze and organize that intelligence.
So taking those behaviors, looking at what's there, what isn't there, filling in any gaps, and then pulling that together into a plan we can actually use.
Develop tools.
So we need malware utilities and other things to be able to operate with.
And then finally, do the emulation.
So I'm a threat intel guy. I'm going to cover the most threat intel focused pieces of this process.
And so what I'm going to focus on today is the first three steps in this process.
So start with the first step, gather threat intelligence.
So we're going to need to choose an adversary and then pull in information that we can find about them.
So before we can start gathering data, we need to identify the adversary.
I'll cover two ways to do this in looking at gaps that we're hoping to assess in our environment and considering who is targeting us in the first place.
I'll then go through a couple of processes for gathering data on that adversary.
So pulling in information on things that they do after they break into environments, that's likely to be most of the space of our engagement.
And beyond behaviors, there are some things to think about beyond just what techniques they do.
So what tools are adversaries using? What other groups are associated with them?
So what other names might we have that are describing some of the same activity?
As well as an adversary's campaigns.
So a series of intrusions that are happening in a time period that are attributed to the same actor.
And on top of all this, we probably want to think about the timeframe.
Some of the actors we might want to emulate might have been in this business a very long time.
So I'll be using an actor later, who is thought to have been around since at least 2004.
What they looked like in 2004 is probably a little bit different than what they look like today.
So there are a lot of ways that you can find lists of adversaries, you know, information on starting points for who it is you want to emulate.
I've got my biases, I'm going to leverage attack, but you don't have to.
But a decent number of red teams we have seen using it for adversary emulation.
So some other options instead of attack.
If you have an internal threat intelligence team that is tracking on groups that are, you know, hitting your own organization,
that might be your best source of threat intelligence.
So they know about the threats that matter most to your organization.
They may have the best picture of the techniques that are really relevant to you.
So that could be a really good place to start.
There are people that might be able to sell this information to you.
So there are commercial threat intelligence providers where, you know, for a fee,
you can get information on different adversaries you might be interested in.
Or you can go to the same well that we do.
So everything that we're pulling into attack is coming from open source threat intelligence reporting.
And so you can go out and look at some of the same sorts of reports we do ourselves.
Because I'm going to be using ATT&CK for the rest of this talk,
I'm just going to quickly get into a few of the specific aspects of it that I'm going to be leveraging here.
So I'm not going to get into, you know, the defensive use cases, things like that.
Just sort of the basics of the framework structure and then the groups information that we're going to be pulling from it.
So I think probably a lot of you have already heard of ATT&CK.
But at its core, ATT&CK is a knowledge base of adversary behaviors.
It's like an encyclopedia of things that real actors have been seen to do in the wild.
So not just things a red team has done, not just theoretical, but it's actual adversary behaviors.
It's freely available. Everything I'm going to be talking about today,
every resource I'm using is out there for free.
And if it's code is open source.
So let's talk about structural here.
This is the view most people use of ATT&CK. It's what we call the matrix.
It's a layout of different activities that adversaries do.
The way it's organized is across the top here, we have what we call tactics.
These are the adversary's broad technical goals.
So it's something like initial access.
The adversary is trying to get into my network or exfiltration.
The adversary is sending stuff that they've stolen out of my environment.
Or something a little different like impact, where an adversary is trying to cause destruction
or disruption to systems or my environment.
Under each of these tactics, we have what we call techniques.
And those are how the technical goals are achieved.
And these are sort of the basic unit of ATT&CK.
I've seen a bunch of techniques.
So Cirio was just using several technique IDs in her talk.
And so these are getting down to more specific ways.
So instead of initial access, we now have something like phishing.
The adversary is sending a malicious email.
That's kind of an exciting talk for me,
because this is the first time I've given a talk in years
that I've been able to fit the matrix on a single slide.
So we recently did a fairly big refactoring of ATT&CK
and going from just tactics and techniques
to tactics, techniques, and sub-techniques.
So there's now another layer of abstraction under a lot of the techniques.
Sub-techniques are just more specific techniques.
So instead of phishing, we have something like spear phishing attachment
or spear phishing link.
So it's, again, getting more specific.
These sub-techniques have all the same properties behind them as techniques.
They have all the same mitigations, detections, everything else.
It's just a deeper level of specificity, and they have a parent technique.
Finally, getting all the way down to detail, we've got procedures.
These are specific adversary implementations of techniques and sub-techniques.
So instead of spear phishing attachment,
we might have the APT12 that sent emails
with malicious office documents and PDFs attached.
Okay, our goal was to find out stuff about groups.
Something else that ATT&CK has is profiles
on a number of different threat actors, over 100 of them.
This is what a group page looks like.
We've got a brief text description of the group itself,
some metadata associated with it.
We have what we call associated group descriptions.
Different companies, different threat intelligence providers
use different names to describe the same or closely related groups.
And this is natural.
These organizations have their own definitions of these groups
that may not be quite the same.
That's one of the reasons we call it associated groups
instead of what we used to call it, which is aliases.
We keep track of what techniques are used.
So we've taken open source threat intelligence reporting,
gone through, and figured out what those reports say
that the adversary has been doing.
Similar to our groups pages, we also have software pages.
Those keep track of different pieces of software
the adversary is using, everything from utilities
to things that they've custom written,
as well as all of the techniques
that that particular piece of software is able to do.
And finally, there's references for all of it.
You can go back, you can check our work,
you can see the original references,
and make sure that you believe what we say about it.
People use ATT&CK for a lot of different things.
I'm only touching on adversary emulation tonight.
It's kind of a good use case for ATT&CK, though.
So it turns out that adversary emulation
is what ATT&CK was created for in the first place.
The reason we originally created ATT&CK
was that we had a red team
who wanted to look like some specific actors,
wanted to create playbooks, create plans,
operate, and then wanted to be able
to compare notes with the blue team
and see if they saw the same things
that the adversary had done.
Okay.
So if I want to actually start
to pick out an actor from all this set,
you've got 100 actors.
So we can start by looking at how specific actors
align with some of the gaps
that we think we might have in our defenses.
So this is coming from APT28.
Everything in blue here
is techniques that we've identified
from multiple open-source threat intelligence reports.
It's not using any commercial or government reporting.
It's just things that you also have access to.
I'm going to be showing a bunch of diagrams
that look like this.
This is basically the same matrix layout
I showed in the introduction a second ago.
I do have a number of the sub-techniques
expanded out to show a bit more of the detail.
But you're probably not going to be able to read the labels
at least over on Twitch or YouTube.
But all these diagrams I'm creating
are using ATT&CK Navigator,
which is an open-source tool we provided.
That's a URL to actually work with it yourself.
And I'll release the slides for this
right after the talk
and work on getting the navigator layers out I'm using.
So if we're looking at the techniques
that APT28 has used,
we can then compare that with
our own defenses.
So if we take the same ATT&CK Navigator,
we lay out where we think
that our defenses can catch
or not catch an adversary.
So what's in red here is notional gaps
in the defenses for an organization.
So what I think that I can't detect today.
Okay?
So if I take that adversary,
I add the gaps to it,
I can then create something
that looks like this.
So I now have the APT28 in blue,
our gaps in red,
and the green here is, you know,
where we think we might have gaps.
So again, without the slides,
probably not going to be able to see
which individual techniques are highlighted.
But we can see, you know,
maybe APT28 isn't the best match for us.
You know, they've only got maybe 10 techniques
that overlap with things that we think are gaps.
So, okay.
What else can we look for?
We can also look at adversaries
who are targeting us.
So especially if we've got our own internal
threat intelligence team to help us,
they may be able to help us prioritize here
because hopefully they know
who it is who's been coming after us.
And again, there's a couple different ways
that we can prioritize based on this.
So we can start with an adversary
who targets us regularly.
Now, maybe we've got some actor
who the first Monday of every month,
like clockwork, sends us a spearfish.
You know, maybe they're not the best.
We don't, you know, maybe that we think
that our defenses are pretty good about them,
but they may be of a lot of interest to us
just because they're trying so regularly.
They're definitely a persistent threat.
We can look at adversaries
who have targeted others like us.
If we've got some actor
who's tried to break into
every other peer in our industry
and has succeeded in places,
well, we're probably somewhere
on their priority list.
We're in their priority intelligence requirements
for who they should be breaking into.
So we might want to understand
how it is that we might face against them.
Finally, you might want to pick
an adversary who doesn't target us very much
or we've never actually seen,
but they might, but has a high skill level.
You know, the actor who keeps us up at night
because we think that if they came after us,
they'd probably succeed.
You know, they've got the high skill set.
So the adversary I'm leveraging today
for a lot of organizations
probably more fits into this last group.
The keep you up at night adversary.
So the adversary I'm going to leverage
for the rest of this talk is Turla.
Turla has been attributed to Russian state activity.
They've been around for quite a while.
They've been seen since at least 2004.
I kind of like this group
and that they're cross-platform
so they don't just stick to Windows systems,
but they've been known to go after macOS and Linux.
And they use some interesting techniques
that we don't see a lot of actors use.
And so everything in ATT&CK has been seen somewhere
by some actor, but there are techniques
that there are really only, you know,
a certain number of high-end adversaries
that are getting into them.
So we've picked our actor.
It's time to start gathering data on them.
So if I'm not using ATT&CK as my data source,
I'm going to want to probably go out there
and start gathering intel.
And so, you know, I can start looking
through open source publicly available
threat intelligence reports.
There are quite a lot of them out there these days.
There really weren't that many when ATT&CK started,
but we do have quite a wealth out there
of reporting now.
Or I can leverage the version
of a lot of these techniques that's in ATT&CK.
So we're going through some of these exact same reports,
trying to find what behaviors and techniques
are in there, and then we're putting out
that same information in ATT&CK.
So it's information you already have access to
just in a digested form.
So we've got this intel.
If we're going from our own sources,
if we're bringing in open source threat intelligence
reporting ourselves, we're going to need to go
through a process of extracting techniques.
Internally, we tend to call this mapping.
So the quick process that you're going to go through
in these reports is something along the lines
of first finding the behaviors in the report.
So figuring out what is it that are activities
that the adversary did, the things that we're going
to want to later be doing ourselves.
Figure out the tactics.
So it takes a little bit of experience
in understanding what you're reading
with adversary behavior.
But what is the adversary's goal
for each of those behaviors?
Move down to more specifics.
Move down those columns of ATT&CK.
Go from the tactic to a technique,
or even better, all the way down into a sub-technique.
And I recommend doing this as a team.
You know, everyone has their own biases
and preconceptions in how they read intel,
something I'll talk about a bit more in a minute.
But comparing notes can be super effective
for canceling out different issues you might have.
So I'm only going to be briefly talking
about how to do this, but my friend
and former ATT&CK teammate Katie Nichols
released training earlier this year
on how to do this mapping in much more detail.
The URL for it is available in the slides.
Again, I'll release the slides later.
And it's completely free.
The videos for it are up on YouTube.
So this process of mapping ATT&CK techniques.
You know, this little snippet of reporting
has quite a few of them in it
in the way that we would interpret
an open-source threat intelligence report.
So first we're going through,
we're identifying each of the behaviors.
There's the highlighted in yellow bits
where they're either describing something
an adversary did or, you know,
they're using a tool where it's relatively clear
what the behavior is that they're using it for.
We're going through, we're getting down
into tactics and getting down into techniques.
So instead of create batch scripts,
we're interpreting that into ATT&CK
for our Windows command shell, T10-59-003.
Instead of Windows run key,
we now have registry run keys, startup folder.
So T15-74-001.
And we're just going through the entire document,
repeating this process over and over again,
and pulling out the full set of techniques
that we're able to find.
So once you've pulled out all those techniques,
you need to structure your intel.
And so I'm, you know, again, using the ATT&CK Navigator.
This is the full set of Turla techniques
that I've extracted from ATT&CK,
pulled out of their page that's in there.
Again, everything that's here is only based
on open source threat intelligence reporting.
So it has the limitations of that.
And so that's, this is the sum total
of all of those threat intelligence reports
we mapped with Turla.
Okay, so we've got a pile of intel.
What do we actually do with it?
You know, is this any good?
Do we have a picture of the adversary yet?
And so we're going to need to go through some more work
to figure out what we've got,
you know, what the adversary is trying to do.
And do we even have enough of a picture
to be able to make a plan here?
So the first two steps I'm going to work through
are establishing the adversary's goal.
So what is it that they're trying to do?
Understand their modus operandi a little bit better
in terms of what we're later going to want to operate like.
And an important point to remember
is that this goal is probably not technical.
The adversary is probably not focused
on getting domain administrator
or stealing a particular password.
They're probably interested in fulfilling
an intelligence requirement.
You know, they have some piece of information
that they want to steal from your environment.
So the goal is likely to be something more like data theft
or to stop you from operating
than, you know, hack the Gibson
or, you know, brick a particular computer.
After you've determined what that goal is,
you need to look at what the gaps are
between an adversary getting in and reaching that goal.
What is it I don't know about the middle
that would let me look like that adversary?
So to go through those first two steps of it,
so establishing an adversary goal.
You could take a look at which tactics
the adversary is using.
So we can see that TERLA has some stuff
in collection and exfiltration.
They've got nothing in impact.
But instead, I'm going to go back to the original reporting.
So this is a Kaspersky report on TERLA.
And so they talk about how TERLA went through,
they're searching for emails.
They were specifically looking for emails
related to NATO energy dialogue.
And then shortly afterwards, the report talks about them
exfiling the information.
So, okay, they're stealing information
around particular topics.
Similarly, an ESET report.
They're going through,
they're getting into the victim's Microsoft SQL database.
Pulling documents out of it,
and again, exfiling,
and taking specific information.
So we've got a relatively clear picture,
and we can look at other reports
and see the same thing,
where over and over and over again,
TERLA is stealing information.
So it looks like they're focused on
theft of information and exfiltration.
So I said that we need to then
examine gaps between access and goal.
I'm going to cover for a few minutes first,
why are there gaps?
So we've got this intel,
it's an attack, it's all out there.
Why isn't that enough for us
to be able to work with?
Open source intelligence
likely doesn't paint a complete picture
of an adversary.
Frankly, commercial and closed intelligence
probably doesn't either.
So there are biases
in the information, in how it's gathered,
and what information is gathered,
as well as nobody has perfect visibility.
It's very rare that you have intelligence
that tells you everything an adversary does
from the point when a victim clicks
to the point when they actually
are stealing information.
And by putting it into attack,
we add our own problems.
So group intelligence in attack
is subject to our own biases,
and then we're very similar.
And, you know, we're adding on
to the biases that are coming
from this open source intelligence.
So some of that is from how we map
from these intelligence reports
and what it is we actually choose to come in.
Now, bias is usually a negative word
in the English language.
It sounds bad, you know,
sounds like we may not like
certain intelligence,
but in threat intelligence,
we accept that all sources
have certain information.
And so we work to understand those
and what they are
so that we can account for them.
So some of why we have
these biases in our reporting.
Any reporting source
is going to have a visibility bias.
There are only certain types
of information that a given
source is going to have,
and they might only have
certain types of sensors.
An incident response firm may only
have whatever sensors were in the
environment at the time.
Whereas things that can only be
seen in real time,
so maybe decoded command and control
traffic or registry monitoring,
other things that don't really leave
much of a forensic trace,
might not be in their visibility.
So there's novelty bias.
So I'm kind of a beer snob.
In normal pre-COVID times,
I walk into a good beer bar,
I look at the taps that are there,
and I see
a bunch of stuff I've had before.
It's been on my untapped list for
years now, and I see the one tap
that was the thing I've wanted to try
for a while.
Reporting can be a lot like that.
So I've got my reports,
I've got my
APT 1-8 report where
I've got a new actor,
we've never seen him before,
they're doing something new,
and I've got my APT Elite report.
I'm going to put out the one
that's brand new,
is more likely to make a headline.
And so our intel is biased by this,
where some reports are more likely
to come out than others.
As people are creating
the intelligence in the first place,
they have availability bias.
Availability bias is a
classic cognitive bias.
I have some things that I am
more familiar with,
that I'm more used to seeing,
that I'm more likely to recognize.
So somebody who's done a ton
of incident response,
they've seen PowerShell over
and over again, they might be more
likely to notice the PowerShell activity
and not notice that,
say the adversary got into the
BIOS over here or something
super novel.
Victim bias.
So there are some victims where
there is more likely for reporting
to come out than others.
So there are only
certain firms that can afford
some of the companies that are
putting out a lot of this threat
intelligence reporting.
Some victims are also in industries
where they're a lot more likely
to allow reports to come out.
There may be issues with regulators
if there's any information about
them having been hacked.
And so who the victim is,
is going to matter a lot for if
we ever hear about it.
Victim bias.
So some sources write more
reports than others.
If, you know, one company
is writing, you know,
dozens and dozens of reports that
all have
active behaviors in them and
another company is just putting
out a couple,
we're going to have more
information to work with from
another.
And so I said we compound it.
And so we add our own biases to
these and the types of sources
we select.
And so a lot of the stuff I've
been talking about is in terms
of information from security
vendors and threat
intelligence firms.
So 92% of the reports that
we have in ATT&CK,
as a point when I made this
slide, are coming from security
vendors.
3% are coming from government
reports.
These are things like public
indictments and other public
available government reports.
And a few are coming from press
reports.
Sometimes there's an article
in Wired or the Register that
describes really good, unique
adversary activity.
We have our own availability
bias.
So in that mapping process of
going through reports, we've
reduced the number of techniques
in ATT&CK a little bit recently,
but there's still over 160 of
them.
And so it's hard
for us to keep a working set
of all of those techniques.
And so we've got the techniques
that we remember in there and
are at the tip of our tongue.
And then we have the techniques
in ATT&CK, like hidden file
system that we almost never
see in reporting.
We have our own novelty bias.
So we've got, you know,
dozens and dozens of reports
on FuzzyDeck using PowerShell.
But we've got this one brand
new report on APT Elite using
transmitted data manipulation,
a fairly new technique.
We're probably going to go
for the shiny new report.
And so if you're using
Intel from ATT&CK, there's a
couple of other caveats to
realize.
So our reporting that we've
got in there on a given group
page is from all different
time periods combined.
There's some reasons why
we do this.
Reporting frequently doesn't
say when the activity happened.
So a report, we might
have a date on the report
itself, not always, and a
pox on people that put out
threat intelligence reports
about dates.
But we don't even know
necessarily when the intrusion
happened. And I've seen
reporting where I know the
intrusion that they were
talking about was four or
five years old, where it
sounded like they were
talking about something
recent.
Some reports might only talk
about a small range of
activity. So some why we
end up adding stuff together
is so that we can talk
enough about a single
actor to paint a picture.
So if I only have one
report with, you know, ten
techniques in it, it's
probably not telling me the
range of activity that an
actor can do.
Our group pages only
include behaviors that are
directly tied to actor
activity.
So our standards for what
we're adding into those
pages is that the reporting
says that the actor did
it.
And so that doesn't include
behaviors of software that
adversaries use.
So if there is a malware
analysis report out there
that we're putting in attack,
that's going on those
software pages.
And we're not including that
into the activity of the
given adversary.
And finally, the reporting
we're using doesn't always
agree on attribution.
And so we're sometimes
left trying to figure out
what the heck group we
should be even putting this
into.
And hopefully in most cases
it's accurate.
So that sounds awful.
You know, so what do we
what do we do about it?
I've talked about this as
our source of intel.
And now I've talked about
all these problems with it.
So the important part
is to understand that
there are these types
of limitations and biases
in the intel that we're
using to do this
emulation.
Once we know that there
are these limitations and
gaps are there,
we can start to determine
where the gaps are in our
specific intelligence.
And so we don't
just throw up our hands
and say, well, I don't
know anything.
I'm just going back to
normal red teaming.
We need to account for
these gaps and
fill them in as we build
our adversary emulation
plan.
That was a long aside
away from Turla.
But let's start to look
at how we might spot
gaps in our
specific adversary
picture.
So taking Turla as
an example, how
might we see some evidence
that our information on
Turla isn't perfect?
I can first look for
missing dependencies.
So my colleague
Amy Applebaum wrote a
blog post a couple
years back on
trying to find related
attack techniques.
So both dependencies
where in order to
do one technique, you
might need this other
technique first, or
techniques that are
very often seen
together.
And so that can be a
useful source for
doing this.
But I'm going to zoom
in on a couple
places in our
profile of Turla.
So let's look at
initial access.
So we've got some
pretty simple
techniques here
that drive by
compromise.
We have fishing,
spearfishing attachment,
fishing, spearfishing
link.
Okay, relatively
germane.
But if they're doing
each of these things,
these successful
intrusions, there
are actions that
need to follow that
for the intrusion
to have been
successful as it
was.
So I take a look
at our execution
for Turla.
And I look at,
you know, I've got
user execution
malicious link.
So they sent a
malicious spearfishing
link.
We clicked on it.
Okay.
They sent us a
spearfishing
attachment.
I don't actually
have an execution
technique for that.
So there's
clearly a gap here.
It's something we
probably need to fix.
But it,
there's, I would expect
there to be here
either user
execution malicious
file, or, you
know, potentially
if they're being
really ninja
exploitation for
client execution.
So, you know,
maybe they're,
maybe it's a user
clicking on the
attachment, or
maybe they're popping
the outlook.
But something is
missing here.
We can also look
for hints of
dependencies, you
know, and so we're
trying to create
something in the
style of an adversary,
not necessarily
exactly what they
did.
But so I can look
at something like
lateral movement.
So, okay, we
see them doing
lateral tool
transfer and
Samba
Windows
admin
shares.
Windows admin
shares, if
they're doing
this technique,
it's usually
something where
they're being
driven by
operating system
credentials to
get around the
network.
So, okay, there's
something that
should be in here
as a credential
access so that
they've got the
creds to do
that.
Well, what I've
got here is
brute force,
which they could
be using to
do OS
credentials.
Credentials
from password
stores is
usually other
types of
credentials rather
than operating
system.
So I'd really
expect there to
be something
more like OS
credential
dumping or
something with
Kerberos
tickets.
So domain
authentication
here.
So a sign that
I might have
another gap that
I need to deal
with.
Less dependable,
but another way
that we might be
able to see
signs of this
is looking for
things like
unusually
sparse
tactics.
So in the
case of
Turla,
we've got an
adversary who's
been around
since at least
2004, as I said
in the beginning
of this.
Most adversaries
over time are
definitely developing
multiple techniques
to do a given
tactic that's
important to them.
And in the case
of Turla, all
we've got here
for exfiltration
is exfiltration
of cloud
storage.
And another
reason why
that's a little
bit suspicious
for Turla
is that Turla
is older than
cloud storage,
at least in the
sense that we
would generally
mean by it.
And so there's
some signs that
there might be
another gap
here in our
picture of
Turla.
Okay, so if
there are gaps
and we don't
have necessarily
everything we
need to get
from the
adversary getting
in to achieving
their goal,
let's look at
some ways of
filling these in
in a logical
fashion that
sticks to the
spirit of the
adversary as
much as
possible.
I'm going to go
over four techniques
for filling in
gaps.
First is
adding techniques
from the software
that the
adversary is using.
I'm going to fill
in some of those
dependencies that I
just identified
and add those
in.
I'm going to take
a look at peer
adversaries.
So maybe we're
still not able to
get enough
intelligence on
stuff that's
directly related
to the one
we've chosen.
Let's look at
their peers.
Let's look at
people who are
operating like
them.
And we can borrow
from as well.
And finally, if
all of that
fails, let's
look at what
lots of
adversaries are
doing.
It might be
something that
they're doing as
well.
So if I go back
to the attack
group page,
this is all
the software
that we've
associated with
Terla.
There's a mix of
different types of
things in here.
For starters, we
have what I'm
going to call
utilities.
So these are
tools that are
in every case,
but PSExec
built into
Windows.
PSExec
obviously being
part of Sys
internal, so
something that
they probably
downloaded over
the course of
the intrusion.
But it's a
general purpose
tools that
anyone's going
to have
access to
it.
Next, we've
got public
tools.
So our
public
offensive
tools.
Terla, like a
lot of actors
out there, is
a user of
MimiCats, as
well as
Empire.
And so this is
something that,
you know, it's
not just
specific to
Terla.
We see tons
of different
adversaries
using.
But Terla
has a lot
of possibly
unique software.
So these are
pieces of
software we
have listed
for no
other adversary
but Terla.
We think
that maybe
they were
written for
them or
written by
them, but we
at least don't
have evidence of
them being
used elsewhere.
And so for
filling in
software, I'm
going to start
with just
this possibly
unique
to Terla
set.
And I've
got a
couple of
reasons I'm
going to
do that.
So the
first is
that some
of the
other tools
like
Mimi
Cats,
Empire, or
if they've
been using
something like
Cobalt, those
tools have a
ton of
functionality.
Off the top
of my head,
I think
Cobalt,
we've got
over 65
techniques
mapped to.
And so it
starts to
just color
in the
entire
matrix, not
necessarily
the pieces
that Terla
is actually
using.
Something I've
seen is that
adversaries have a
tendency to use
more of the
functionality of
their own
tools, too,
than general
purpose they're
using.
And that makes
a lot of sense.
If you are
commissioning
these or
buying these
tools, you're
probably not
going to ask
for a lot of
functionality
that you
never use.
So if I
take all of the
techniques that
are associated
with each of
these tools,
add them
together, I
get something that
looks like this.
And again, I'll
release the
slides so you
can zoom in a
bit better.
Right now, I'm
just more
showing sort of
the shape of
the coloring.
You can see
that this
adds in
activity
across a
lot of
different
tactics.
So we've
got a
bunch of
material
here.
And if I go
back and add
my Turla
profile back
into that,
I've now got
quite a bit
more there.
So blue was
what we already
had with Turla.
Red is what we
just added in
with the
software that
they're using.
And green is
the overlap.
So green is
what we already
had.
And so I
pointed out
exfiltration
was kind of
thin in
the original
profile.
Well, so adding
in the software
they're using
has helped
fill that in
a bit.
So we've now
got something
like not just
cloud storage,
but also
exfiltration
of a command
and control
channel.
And so some
more options
for us to
be able to
work with
too.
So I've
still got
some of
those missing
dependencies
though, even
with the
software added
in.
So the next
thing I'm going
to go through
is filling
the missing
dependencies.
I didn't
actually find
a lot of
those in
Turla
specifically,
but there
are definitely
actors where
there are
more of
these that
you'll find.
And so I'm
going to
take the
fairly simple
step with
the missing
dependencies
I'd found
to simply
fill them
in.
So, you know,
we're trying to
stick in the
sphere of the
adversary.
They probably
did these
things in
order to
accomplish
those other
techniques or
after those
other
techniques.
So I'm
going to
bring those
into our
profile.
So that
now gives
me a
relatively
well-fleshed
out adversary
profile.
So this also
isn't
coloring in
quite as
much of
the
attack
matrix
as it
might
appear
here.
I have
only
expanded
out
sub
techniques
where
there are
techniques
selected
in them.
So again,
I'm trying
to keep
the
matrix
actually
fitting on
the slide.
But there are
quite a few
sub
techniques that
are still
tucked in
here.
So this is
still keeping
us to
a scoping
that is
in the
spirit of
Turla.
So I
think we're
good here.
I think
for Turla
itself,
this is
probably
sufficient
for us
to work
with in
any scenario
we want to
create.
But what if I
was working
in an actor
where I
couldn't do
that?
So the
next thing I
can do
is start
examining
peer
adversaries.
Turla
is
attributed
to be
a Russian
state
actor
who
likes to
steal
information.
So who
else in
the tech
do we
have that
looks like
them?
The ones
that jump
out are
APT28 and
29.
These are
the two
groups
that were
attributed
by the
US
government
to be
behind
the
DNC
hacks
a couple
years
ago.
They
have been
very
prolific.
They do a
wide range
of their
own
activities.
I could
use them
like this
where I'm
just taking
every
technique
from
both
mashing
them
together
or maybe
I just
want to
use it
as a
way of
seeing
what's
popular
for them.
So the
green techniques
are where
there's overlap
between these
two
adversaries.
Lastly,
you know,
so if the
peers aren't
enough,
maybe I can
just look at
what techniques
are common
out there.
So a
number of
companies over
the past
couple
years have
started
publishing
annual reports
on what
attack
techniques
that they've
seen over
the past
year.
And so
looking at
a couple
of
companies'
reports on
what
techniques
they saw
in 2019,
we can
start to
use those
to fill
in gaps.
So the
first one
I'm going
to use
is red
canary.
So they
put out
a report.
It's actually
got top
20 in it,
but you can
actually read
the text on
this one.
So it
is going
through,
and it's
in order,
but it's
important to
understand,
again,
what this
means.
This is
the top
10 techniques
that they
saw in
the places
that they
have
sensing
in and
compared
with their
actual
detectors.
So it's not
necessarily the
10 most
popular
techniques,
it's the
10 most
popular
techniques
they saw.
Another
company who
put out
top 20
techniques this
year,
I'm again
cutting them
down to
10 for
the slide,
but you'll
note that
the only
overlap
between these
two lists is
process injection.
So we may want
to combine a couple
of these together
in order to
see where the
overlaps are,
add their data,
but these are
giving us some
ideas of things
that we know at
least have been
out there in the
wild a bunch
in the past
year.
So it doesn't
tell us that
Turla did
these, it
doesn't tell
us that
28 or
29 did
these, but
a bunch of
people did
them somewhere.
So adding them
into our
profile may
be still
sticking to
a realistic
APT profile.
And again,
I wouldn't do
this unless
I wasn't able
to get it
directly from
the threat
intelligence on
the actor.
So we've
filled in some
gaps.
We've got a lot
of things colored
in now.
We've got our
pretty picture.
So what do
we do with it?
How do we
actually turn
this into
more of a
profile?
So I talked
about a couple
gap techniques
that I didn't
use.
So going back
to my Turla
profile that
is Turla
plus the
software that
appears to be
unique to
them plus
filling in
those
dependencies.
So I'm going
to want to do
something like
this.
So I've got
my techniques,
I've got my
tactics, and
I'm going to
want to start
to carve down
to the techniques
I want to
actually use.
And those
techniques have
a flow to
them.
So I've talked
a teeny bit
about dependencies
like where one
technique is
going to
require another.
There are
often spaces
where one
tactic is
generally going
to require
another one
too.
Attack is
not ordered.
Obviously,
yes, things
off to the
left in
attack often
happen before
things to the
right in
attack, but
there is no
strict ordering
to it.
It is not a
kill chain.
And so
tactics may
happen in
different
orders, they
may not
appear at
all in
the
intrusion,
but we
are going to
want to
force some
ordering on
them for
operation so
that we can
actually build
up a plan.
So here what
I've done is
I've started
with initial
access, so
I've got the
adversary breaking
into the
environment.
Followed by
execution, so
the code
actually getting
run, so
that's also
got the most
file in here
that I filled
in using
dependencies.
From execution,
they are going
to be doing
both discovery
and privilege
escalation, so
I'm going to
be able to do a
lot of my
discovery without
needing extra
privileges.
At the same time,
I'm going to be
building up so
that I can do
my
defensivation
credential access
and persistence.
Some of
Turla's
defensivation
does require
privilege
escalation, so
they do things
like hidden
file systems,
which is a
fairly unusual
technique.
And then,
you know, so
from my
credential access,
I'll then be able
to do lateral
movement.
I've got my
OS credential
dumping, which
lets me do my
Samba, Windows
administrative
shares, and
the arrow is
supposed to
loop around
from one side
to the other,
back to
execution, and
start it all
over again.
So, in
order to
bring this
even closer
to something
I can operate
with, the
final organizational
step I'm going
to do is
organized technique
flow into
plan phases.
So, everything I've
talked about here
is started at
initial access.
And so, that's
using what's in
enterprise attack
today.
But obviously,
there are some
steps that an
adversary, as
well as an
adversary emulator,
is going to need
to do before
they get into
the environment.
So, that's
this phase
one.
And so, you
might not be
familiar with
the tactics,
reconnaissance,
and resource
development.
And that's because
they won't be
in attack for
another few
months.
But stay
tuned.
We actually
are extending
attack to
match the
scope of
the cyber kill
chain and
activities that
come before
you break
into an
environment.
Phase two,
I've got the
adversary
operating,
setting down
their
footprint,
while I've got
this particular
adversary doing
their collection
and exfiltration
at the end.
So, they've got
the footprint and
then they steal
the information.
And so, I'm
putting these in
order so that we
can use them for
operations.
This isn't going
to be perfect,
but a lot of
these techniques
and tactics
have required
ordering to
them.
So, the
pieces I'm not
really going to
cover today,
but just a
few thoughts
on making sure
that we're applying
Intel as we go
through the entire
process.
So, we're going to
want to develop
tools to be able
to do this.
You know, want to
be able to think,
can we do this
with COTS free
open source?
Are those reasonable
for the given
actor?
So, in some
cases, we may
have an actor
who's using
Empire or
Cobalt.
So, the
answer to
that is fairly
obvious.
If we have an
actor that's
doing nothing
but bespoke
tool development
and using techniques
that aren't really
supported by much
that's out there in
public, we may need
to do some custom
work.
But, regardless,
trying to keep
those payloads
inspired by the
APT.
So, you're
looking at how
they're packing
and everything
else, trying to
stick to that
intelligence.
And finally, as
you actually
operate,
obviously, you're
going to have to
set up all the
infrastructure, test
it out and get it
going.
But once you're
emulating the
adversary, try to
think about the
modus operandi
that we thought
about earlier.
Adversary is trying
to steal targeted
information.
The goal is not
to get into
the domain
controller.
I saw somebody
on Discord
that I said
hacked the
Gibson.
Think about your
goal throughout
this and where
is it you're
actually trying
to get to.
And then think
about pacing.
How is it that
the adversary
actually operates?
Are they somebody
that is slow
and methodical
in how they're
spreading out?
Are they doing a
smash and grab?
Think about that
as much as
possible.
In closing,
some of the
things I hope
to take away
from this is
pick your
adversary wisely.
There are a lot of
things you can
think about to
leverage Intel
in the selection
of an adversary
in the first
place.
The Intel
in your adversary
isn't going to be
perfect.
It doesn't matter
if you're getting
it from attack,
original sources,
or wherever.
But it is not
going to be
perfect.
But you can
still emulate
an adversary
with imperfect
Intel.
So this is
something you
can pull off
even though
you're not
going to know
absolutely
everything
about an
adversary.
I'll post
my slides, but
some of the links
to resources I
used in here
between
ATT&CK
Navigator and
ATT&CK
itself.
We've put out
a couple of
emulation plans
where we've used
a lot of this
process and how
we've actually
done it.
And we've got
our own
Red Team
automated
tool, Caldera,
that we've
actually ported
the APT29
emulation plan
over to.
And I'm
reachable
in a couple
different venues
via ATT&CK,
via Twitter,
whatever.
And that's it
for me.
And so I'm
going to be
answering questions
in Discord
after this,
but a couple I
did catch
scroll by that
I'll take on
now.
So I saw
somebody saying,
am I talking
about the
pre-ATT&CK
stuff?
Yes.
So we're
undergoing a
merger right
now of the
information that's
in pre-ATT&CK.
We are refactoring
it down to
just
information
that is
technical,
things that
some defenders
somewhere can
see.
So some of the
intelligence planning
steps are going
to be going
away.
And we're
refactoring that
into two new
tactics,
reconnaissance
and resource
development.
So that's
something you
can expect
to see in
the next
release of
pre-ATT&CK.
And with
that, I
will be
answering
questions in
Discord.
And thank you
for attending
my talk.
Thank you so
much, Adam.
And thank you
for supporting
not only
the community
and the
DEF CON,
but the
Red Team
Village as
well.
Amazing talk.
And for
those of you
that are
watching
in Twitch,
YouTube,
that's where
you can get
access to
the Discord
server that
Adam was
mentioning.
We're going to
go on a
brief break
and the
next presentation
will start
in just a