>> Welcome to Lesson 2.4,
raw data to narrative reporting.
In this lesson, we're going to be
practicing the process we went over in
the last couple of lessons with
an exercise mapping raw data to attack,
and then we're going to be reviewing those results.
We're also going to be talking
about some best practices for
featuring your attack map data and narrative reporting.
Exercise 2, working with broad data.
This exercise is broken down into two tickets from
assimilated intrusion and you can
access the tickets under the resources section.
For the first ticket, you're
going to be looking at some content that
is similar to the examples we
walked through previously in the module,
where we had a series of commands interactively
executed via command.exe on an end system.
The second ticket feature some analysis of
the primary remote access Trojan
used during the incident.
You can record your results in
whatever way works best for you.
You can edit the tickets directly or use notes,
but try to identify as many behaviors as possible.
Then once you have those behaviors,
work through the mapping process
and map them to the relevant tactics,
techniques or sub techniques.
We recommend that you now pause for
around 25 minutes to do
this exercise. Welcome back.
When reviewing your experience with this exercise,
did you have any specific questions that you would
have gone back and asked your incident responders?
Were there places where there just wasn't
enough information for you to
really determine what was going on?
Or were there any areas where you wanted to do
some additional research or
pull in more data than what was provided?
Was this exercise more challenging or simpler than
the Module 1 exercise
where you are mapping to narrative reporting?
Do you encounter this type of
data when you're looking at activity?
Are there other things that you
think should have been in here for behaviors?
Finally, did you find any behaviors that you
weren't able to map to a technique or sub technique?
We're now going to be walking through and
reviewing the exercise results,
starting with Ticket 473822.
First off, ipconfig/all.
As you'll recall, we use this as
an example throughout the beginning of this module,
and we saw that it directly mapped to
system network configuration discovery.
Arp-a, another one you'll find
mapping to system network configuration discovery.
It's not irregular to see
the same technique twice in a row.
The echoed username is showing the adversary,
the currently logged in username and
this maps to system owner user discovery.
Tasklist/v is displaying currently running processes on
Windows and this is process discovery.
Sc query is obtaining information on
all the different services running within Windows,
and this is system service discovery.
System info is displaying
detailed configuration information and
patch levels of the systems,
and this is system information discovery.
Net group domain admins.
This is showing a specific domain
group and the members of it,
and we map this to permission groups,
discovery domain groups.
Net user/domain.
We map this to account discovery domain account.
Net group domain controllers.
This is looking at the list of
domain controllers that are within the domains where
the adversaries found themselves and
this maps to remote system discovery.
Netsh advfirewall.
This is showing another system
network configuration discovery.
Then finally netstat-ano is
showing all the connections at the system currently has,
and this maps to system network connections discovery.
You might've noticed that all of
these techniques feature the word discovery.
It probably won't surprise you that they all
fall under the discovery tactic.
It's not unusual for an adversary to go through and
sequentially perform a number of discovery commands.
As we discussed earlier in the module,
these are all also execution,
so command and scripting interpreter.
These were all run on command at exe,
and we saw them via Sysmon.
The second ticket is a little more challenging.
As I mentioned, this is text information
coming out of remote access Trojan,
has some flaws and there are also
some activities occurring behind the scenes.
First off, we have the winspool.exe file,
and that's defense evasion masquerading.
Next we have the C2 protocols, base-64 encoded.
This is command and control
data encoding, standard encoding.
Then commands over HTTPS,
which is command and control application layer protocol,
web protocols.
We have that it's downloading files and
this maps to command and control Ingress tool transfer.
We can see that it's able to do a shell command,
and we map this to execution command
and scripting interpreter.
We also have PowerShell commands,
and this is execution command
and scripting interpreter PowerShell.
Next we see that it can execute a PE via an API call.
That's the create process and we
map this to execution native API.
We see another defense evasion
masquerading as they're trying to copy
something that's attempting to pretend to be
a legitimate winspool.exe file.
Finally we have the adversary adding a run key.
That's actually in the description
that you'll find within
boot or log on autostart execution,
registry run keys, startup folder.
Now as you're going through this exercise and came to
any different conclusions or had different answers,
this doesn't necessarily mean that you're wrong.
As Adam noted in Module 1,
mapping can be subjective,
but I would encourage you to review how
you're mapping is different from ours,
and then look at
the different procedure details within each of
these techniques or sub techniques
and if you're able to,
collaborate with another analyst and compare
your results and identify where any potential gaps are.
Now that we've gone through the process of
mapping this raw data into attack,
I want to discuss some options
for using that information.
We've touched on enriching
narrative reporting with attack
and analyzing original data
into attack to create these reports,
and we have a couple of recommendations for
enhancing those narrative reports.
Either by augmenting them with the attack map data,
or by including in some procedures
from the original data.
A key element is that we recommend keeping the techniques
with the related procedures
and the information around it,
so there's enough context for
people to understand the mapping.
This enables other analysts to
evaluate the intelligence in the mapping,
and it ensures that everyone's on the same page in terms
of what behavior is mapped to
which techniques or sub techniques.
It also allows for
more uncomplicated capture of these procedures and this
can be a core part of crafting
those defenses against specific adversary behavior.
Walking through a couple of examples
of effective reporting formats.
In instance 1, we added footnotes with the techniques to
avoid disrupting the report with in-text techniques.
In instance 2 the report author has included
the information that actually describes
the activity along with the techniques.
This is similar to the format that our team
uses in the procedure examples with an attack.
Instance 3 is an example
of a format that is a little less effective.
When you include mappings to the end of the report,
you lose a lot of that context.
This is similar to having
the IOCs at the end of the report,
where you can have no idea what it actually means,
or what the recommended action associated with it is.
Ensuring that these techniques are
tied to that relevant context
can be really important and will enhance
the effectiveness of your reports.
In this lesson, we practiced mapping raw data to
attack with two tickets
and then walk through the results.
We reinforced the value of
collaborating with other analysts and we reviewed
a couple of best practices for enriching
narrative reporting with attack map data.
In this module, we reviewed the mapping process that
Adam introduced in Module 1 and applied it to raw data.
We practice mapping that raw data to attack and whatever
some approaches for expressing
attack map data narrative reporting.
In Module 3, my colleague Jackie will discuss
this concept in depth and outline how you can store,
display, and analyze your attack map data
in order to make it actionable.
This is the end of Module 2.