SANS DFIR Webcast – APT Attacks Exposed: Network, Host, Memory, and Malware Analysis


(bright electronic music) – [Man] Evening, everyone! – [Audience Member]
Good evening! – [Man] Hi. (cheering and laughing) Welcome to the first
night of SANS Monterey, DFIR Con, for many
of you who were able to actually show up
today on your plane. Just curious, how many
in here were delayed, and you had to spend the
night near an airport, in an airport, on a cot? All right. (audience member
talking quietly) In a car? – [Audience Member] I drove. – [Man] Oh, you drove. That’s right, you
drove all night long. (audience member
talking quietly) (laughs) So this is our- (audience member
talking quietly) As Chad went
through this morning in the welcome to SANS,
DFIR Con is the first SANS all-focused conference
on certain material. In this case, we’re
doing digital forensics and incident response. We have the summits out there, and the DFIR summit’s
gonna be in the summer, as always, when we do a two-day
summit prior to the classes. But this is the first
experiment we’ve done with SANS. I really appreciate
everyone coming here and doing the focused event. Just curious, show of hands, how many people
are here in a group that have people in
different classes together, that you’re here as a team? All right, so there’s
different clusters of people. And that’s kinda the
idea that we’ve had. We had a lot of
requests out there of individuals saying,
“hey, I wanna take “smartphone forensics.” “I wanna take instant response.” And you have different
people wanna to go to different classes. And as a result, you
still wanna hang out together at night and come
to keynotes such as this, but other conferences,
especially the non-Orlando types,
non-network security types, you have a hard time potentially
getting everyone there. That’s why we’re making
this huge attempt out there to do more of these
focus-based events. I know penetration
testing and hacking, ethical hacking, is
gonna be doing one later this year, as well. We’re gonna be here
in Monterey next year, I think a little bit
earlier, late February. So for anyone’s planning
to try and do this a second time, for
a second go of it, we’re gonna definitely do that. So I appreciate
everyone coming here for the inaugural
first SANS DFIR Con, and I really thank you
for your attention. So tonight, for the keynote, we’re really happy to have
a plethora of speakers that are gonna be
presenting to you tonight. The basic idea behind
this presentation that we initially came up with is that someone said, “hey,
it’d be really interesting “to feel, to
approach an incident “from start to finish from
the attacker’s perspective “all the way down to the
entire instant response team.” The way things are going with
the instant response teams today, you no longer
have a single individual that is a network analyst,
a malware analyst, a host space forensic analyst,
an enterprise analyst. Well, some of you, potentially, saying, “well, that
is me,” right now. But we are starting to become, start more in
discrete focus areas as we’re starting to
get more mature as a part of the stock
that’s out there. So what we’re gonna do
for this presentation, basically take a
snapshot of an incident. And this incident,
for those of you who are currently in 572
for Network Forensics, which, by the way, is making
its debut launch here, six tenths of the
malware from it, and then of course in 508, we
have the host space analysis. So we have from a memory
analysis perspective, host space analysis perspective, network forensics perspective, malware analysis
perspective, and finally the just straight Windows
forensics perspective, what actually happened
in this incident? So before I kick off,
I want to acknowledge all of our speakers. So where are they, currently? Where are all the speakers? In the back! They’re all hanging
out in the back there. So we have Alissa
Torres, Phil Hagen, Chad Tilbury, and Lenny Zeltser, who are gonna be kicking us off. And I’m gonna end
tonight with the Windows forensics analysis. So the main goal here is
that each speaker’s gonna get approximately 15 to 20 minutes
to go through their slides. What we’re about
to attempt to do is there are more slides
in this presentation that you’re gonna go through
in the next hour and a half than you went through
today in class. (laughs) And so you’re gonna get
a little bit of each one of those classes, and we
have a special guest star here with us tonight
at this DFIR Con, is we actually have
the evil attackers that we’re investigating
in this incident. So to kick us off,
I actually wanted to have a perspective
from the attack team that was involved in this case, that we actually had to
set up and investigate. And I’m gonna hand it to him. But the base of the
idea behind this attack is this is the beginning of it. You basically
receive a phone call from law enforcement,
said, “hey, guess what? “You have a problem. “Here’s an IP address.” The attack occurred
on this network. We have a system,
the NROMANOFF system, that was highlighted
as compromised. And your instant response team needs to respond to said system. This is, for a lot of
the incidents out there, about 80% of them
currently right now are notified by a
third-party notification. And so as a result,
it’s likely you will, many of you in here have
received this phone call. So to give a couple of
additional perspectives on this, I wanna hand
it off to John Strand, who was our attack
team, our APT team, that compromised this network. And they have no idea,
before they actually entered the network, what
they’re about to find. So I’m gonna first hand it off to our first
speaker, John Strand, and then we’re gonna
start with Alissa Torres, immediately following that
with memory forensics. Big round of applause
for our attack team. (applause) – [John] And just so you
know, I have no slides. So you don’t have to go through. (cheering and applause) All right, I’m gonna
try to make this quick, but I got a couple
key points to make. When Rob approached
us to do this, first we were honored to do it. It was one of the first
things that we did at Black Hills
Information Security. In fact, it helped shape
what our company was and what we did. And I’ll get to that
here in a couple seconds. But the first thing that
went through my head, how many of you guys do pentest? I know we got some
pentesters up here. All right, the first
thing that went through my head when Rob
said, “we want you guys “to come in and replicate
APT,” was, “we’re pentesters. “We don’t care about forensics.” We don’t, and let
me explain why. At the time, whenever a
forensicator comes up, and they’re like,
“look, in memory, “we can find indications
of mem casts, “and we can find indications
of pass the hash, “and we can find
all these things.” And we would think, “when
you’re looking at that, “the bad guys are sitting
on a beach somewhere “sipping Mai Tais.” So honestly, I thought,
why did I care? Why did it matter? Turns out it
matters quite a bit. Let me explain why. When we started this process, we had a defined
way on how we wanted to attack this network. And we approached that network the same way that we
approached every single pentest that we did up until that point. And when we completed
the first day, Rob said, “it’s
wrong, do it again.” We said, “what do
you mean it’s wrong?” We achieved all the goals. We did what we needed to do. And he goes, “we’re
resetting everything. “Start over.” And the reason why
he had us do that is because we
realized very quickly that the world of
pentesting is over here. And how we break into
networks is way over here. The world of reality
and what the attackers are doing in their networks
is on the other side of the room, and they’re
not talking to each other. And we realized that
everything we were doing in pentesting, the
goal of a pentest is to replicate what it is
real attackers do, right? So why would you hire
a firm to come in and do absolutely nothing
the attackers actually do? That changed everything. That changed the process
in how I look at attacks. That changed my really kind
of cocky, arrogant attitude of how I look at
breaking into networks and how I look at forensics. It changed absolutely
everything, because Rob forced
us, the attackers, to go through and mimic
what it is the bad guys do. Even if it’s something that
just makes our skin crawl, like Rob said, “we
want Poison Ivy.” And we were like,
“Poison Ivy sucks. “Why would we use that?” He says, “because they do.” He wanted certain
command and control that you guys will see
a little bit later. We’re like, “we’d never do that. “Why would we do that?” Said, “because they do.” And as I said, at
this point it changed absolutely everything in
the way that I approached pentesting and the way
everybody in my company approaches pentesting, cause
it’s not just enough to get in. And it’s never enough to get it. That’s not what
we teach at SANS. But now whenever we
teach pentesting, whenever we do pentesting, we go out of our
way to try to mimic as much as possible what it is the bad guys do, even
if we think it’s dumb, even if we think it’s insane, even if it’s anathema
to what we normally do, we have to do it because
we need to replicate what the bad guys do. Conversations needed to be had, conversations between
the forensicator to better pentesters. It’ll put you into
that elite category. And I would also request anybody
here that’s in forensics, spend some time learning
what pentesters do, as well. We need to talk to each other. And really, tonight,
and this conference, is the beginning of
that conversation. So I sincerely
hope that you guys enjoy it a tremendous amount. (applause) – [Alissa] He says I’m up,
like I could follow that. Aw, man, that was
inspirational, John. (laughing) Now he’s gonna go grab
a beer, and it’s over. Over, dude, I wanted to go back, cause they call, the three-
or four-letter agency called, and they gave us some
valuable information. What was the
valuable information that’s gonna help us track down the machine of interest? Do you see it jumping
out off the page there? Right? We got an IP address. Is that something we can,
that’s actionable, right? We can kinda circle back around. Do you guys have
this memorized yet? Who’s taking 508 right now? What is, yeah, so some
of you are in the class. What is dot five? What is a dot five machine? 10 dot three dot what? Rob? Which one? Aw, it’s not CDUNGAN. This is a ROMANOFF machine. This belongs to a
user, Natasha Romanoff. So yeah, we’re
particularly concerned about her machine, all right? So of course, the way
we’re gonna respond to it, once we isolate it, the
first people they send in are going to hit memory, right? We need current system state. Why not? You’re laughing already. (laughs) So that’s where I’m gonna start. My name is Alissa
Torres, and I’m co-author of the memory forensics
class that’s going on here. It’s the Forensics 526
class, but I teach 508. It is one of my passions to
talk about instant response. So I share this with you. How am I going to work through if I wanna know what
processes are running, what network connections
this machine is making? So I propose to
you the six-step, yeah, we’re good. In 508, you’re gonna
see this tomorrow. We saw this today
already, right? 526 people, where you at? Seriously? Thanks, man, thanks, man. My one student, yeah,
so the six-step process. I’m gonna be taking you
through the six-step process, but I’m gonna be using
Natasha Romanoff’s machine, the dot five machine,
as a basis for this. The tools I’m gonna use,
Volatility and Redline. You’re familiar with these? Which one is more for managers? Yeah, man, Redline. You’ll see what I
mean when it starts popping off the screen. Whoa, that’s obviously
evil, it’s red. Hey, I’ve offended someone. Aw (laughs) my god. So Volatility’s gonna
be command line based. And let me show you. It needs a little bit of
information about the system, the dot five machine. Do you know yet what
type of system this is? Again, a test for
your 508 knowledge, what type of system
are we dealing with? It matters,
memory-wise, doesn’t it? It’s, yeah, this is
a Windows 7 machine. Server stack one, is it x86
system architecture-wise? There’s 64-bit. Doesn’t matter, who cares? Yeah, this one’s 86. So we take that
knowledge with us. That’s really step
zero is figuring out what system we’re responding to. All of this is good stuff. I would also throw in
getting a system description, like how, what is this
function on the network? Who’s Natasha Romanoff, right? What’s her purpose? It will guide our analysis. So we’re looking at,
just like John said, there’s value to, each
system that they own on the network, looking
at how this system, Natasha Romanoff’s system,
what the real estate is worth to the attacker. It’s gonna help
guide our analysis. I know you’re there with me. So I take this knowledge,
and I continue down the road. Yeah, all that good information. Redline, now that I know
what type of system this is, I’m gonna use Redline
as a tool, you know, because I need to justify
my work to my manager. He sees me playing, he
sees the joy on my face, cause I love freaking
memory analysis, and he’s starting to question, maybe I need to give her
something else to do, cause she’s too happy. You know what I mean? So I run, I take a memory image of the Natasha Romanoff machine, and I throw Redline at it. This is what I get back. It speaks to you, doesn’t it? Can you see what might
be evil up there? Oh, yeah. It’s clearly the McTray,
the empty tray, right? No, come on now, come on now. This is going to be svchost.exe. It’s jumping off the page. Do you see the path
that it’s running from? Huge, right here. Is that a legitimate path? Even a managerial
tool can help you. I’m here to tell you. This is showing you a red icon. It’s pure evil. And the path is rogue, right? It’s DLL host. That’s crazy talk. DLL host, oh, the arrow. So yeah, the Redline tool
walks us through the analysis. The process, it’s been
flagged by Redline. Let’s do a deeper dive. And it turns out, as
we move through this, that Redline says,
“hey, this was spawned “with unexpected arguments.” Dude, SVC host, clearly
needs the arguments to look legit, with
that dash K thing. You know what I’m talking about. Yeah, you do. And this was also spawned
from a strange directory. So Redline’s in
the know on this. It’s totally right. Let’s continue on, cause
there might be some more information. Anyone played around
with MFT Parser? Holy cow. I see my fellow
presenters actually
putting their heads down because they
realize I don’t need file system analysis anymore. Let me convince you of
that as I pull the MFT out of my memory image, right? I just pulled all
of the file zero, the MFT records,
and compiled them, and I found the MFT
record for the svchost.exe that was flagged by Redline. You’re using two tools,
and you’re walking away with a more comprehensive
picture of evil on the Natasha Romanoff box. Flagged by Redline, I
pull the MFT records out of the memory image using
Volatility’s MFT Parser. So what do you spot here? What is this indicative of? When the standard
information creation using a technique
called timestomping. So what did we learn
about the attacker? We’ve isolated a bit of evil. And then using another
tool, we’re actually isolated a little bit of TTP. What? Threat intelligence? Something I can use
to spot him again? Is this a sophisticated
timestomping or just run of the
mill, I know how to use an interpreter too? Yeah, yeah, loser! Right, right, right, right. Because of this built-in time, we know that these are
not the most sophisticated techniques out there. Otherwise, we wouldn’t
be able to spot it with this time and
date stamp delta. But dudes, let’s continue on. I do a timeline analysis. I see some other
notable artifacts, like spinlock.exe. Don’t really know
what that is thus far, but I can see that it
was kicked off by psexec. So what question might
this spawn in your mind? Psexec, what is that used for? I won’t tell, Parker
Simvich, if you don’t know. Come on, man! Dude, hook me up, John. (man talking quietly) Yeah, yeah, so remote execution, largely for lateral movement, or, you know,
system admin stuff. But talking to the
Stark Research Lab. We’re owned, you know. This is an organization. They done use psexec. So it’s kind of, this is rogue. This is anomalous. To see psexec activity, and what you’re seeing here
is psexec spawning spinlock, spawning two. One spinlock spawns
another spinlock. Does this flag? Yeah, this throws up red flags. So we have a svchost.exe
and we have a spinlock.exe. Let’s try to find out more
about that psexec service, because psexec service is
created on the target machine. And that’s what kicks off
spinlock.exe in this instance. So of course I use
my Volatility skills, and I run I plugin
called printkey. I’m able to go in and see
when this psexec service was created. It has a last write time. And if you notice
that last write time, that was 18:52. And we go back,
that’s on the fourth. If I go back here,
does that correlate? 18:54, 18:52, yeah. So I’m bringing
together the pieces using two tools,
Redline, Volatility. It’s just like that, just
marrying up like that. So again, further analysis, now I’ve got
spinlock on my radar. This is your pslist,
Volatility’s pslist output. I have isolated two
additional processes. There you go, two additional
terminated processes of spinlock.exe. Then I have, does
anyone else see evil? There’s another bit
of evil in there that you might have seen
running in your environment. Kind of crazy. If ever you see a.exe, I think you should be concerned, right? I mean, that’s just,
that’s an attacker that didn’t put
any effort into it. He’s clearly like, “dude,
I think I got this one.” So a.exe, the fact
that it’s terminated a couple times over,
it kicks off immediate, well, not really immediately, maybe a few minutes
after explore.exe. I’m starting to find some
very notable files here, stuff that maybe I’ll pass
off to my malware guy, you know what I mean? Lenny’s gonna come up here soon. I think he’s gonna choose
one of these to talk about. So I look forward
to his analysis. Yeah, what is this? What is being shown here,
the current version run? We were playing around in class using a tool to get
access to carver. That was Redline, wasn’t it? What do I use this for? What’s gonna kick off
when this user logs in? Down there at the bottom, you might not be able to see it. That rogue svchost. So not only have I isolated
evil using Redline, big red icon, this is evil
because it was kicked off like this, now I see how many
times it’s gonna kick off. Every time someone logs in,
this is gonna be kicked off, instantiated based on
where the persistence mechanism lies. You got that, cool. We’re tearing this thing up. Did I touch the file system? Did I ask Rob or Chad for help? Hell no, you know what I mean? Hell no. Oh, jeez. I’m not supposed
to be obnoxious. All right, psscan. Psscan is gonna go deeper
than pslist, right, cause it’s scanning
for structures. I come away with four
different instances of a.exe. It was already on my radar. I need to go deeper, right? A.exe, I’m gonna pass
this off to those guys. I think something’s
up with a.exe. What else? Cause I’m gonna
step to DLL list. DLL list is gonna allow
me to go deep on svchost. You can find additional
DLLs that are being brought into the picture that this process
is working with. We’ll continue on. This is step two,
using Volatility. Handles, notable handles. I can’t show you
too much of this, cause this really gives
away the 508, you know? But there is a
notable handle here. It points to something
going outbound, outbound traffic. So this is the handle that’s
a registry key handle, and that might be a
notable registry path if you wanna look at it later. Frankly, again, I don’t
wanna give away too much. I can go in and
printkey, and I can find some beautiful information here. What would you think
if you enumerated a potentially
suspicious registry key and you found an IP address,
hard-coded IP address? And maybe a little bit
of a pause command. Yeah, C2. I like that, John. I like that, excellent. So yeah, I mean, we’re
really just messing around, going back and forth
between schools. It’s dizzying, what I
got going on up here. But you know, step three
is network connections. Let me do a netscan. And why did I choose netscan? Damn, that’s my student. That’s my student. So yeah, once you have a
netscan, you know what I mean? Go team Peter, I
gotta raise him up. So I got some interesting
information here, closed, IP addresses. If you recognize that
these are actually notable and tied back pid-wise,
at least that 1328 is, to previously
identified processes. So we’re highly suspicious. So now looking at step
three, that was important. Step four is, hey, is
there any injected code? Are there any DLLs that
are injected into these, any of my running processes? Malfind makes this pretty easy. And you can see here,
what’s being flagged? Spinlock. Spinlock has memory
sections that are injected, so I gotta take a
look at that deeper. I can, again, pass
this off to Lenny, say, “dude, look at spinlock. “I think there’s something
crazy going on with that thing.” Svchost shows the same signs
and symptoms of DLL injection. You can see that with the
empty header over here. Awesome, yeah. Step five, you know, I
gotta give John props. He tore it up. He got code injection,
he’s got timestomping, got all these cool
persistence mechanisms. No hooking. I’m not seeing any
signs of hooking. And that was my step
five in my analysis. Am I finding any
rootkit behaviors? I’m not seeing anything. But no matter what
tool or where I look, hooking comes up empty. And that’s all right. I’ll give him that,
I’ll give him that. So the next step, and
it’s really going to segue into further conversation
with my team, who I know love me, (laughs) is, hey, I’m gonna pull
out these processes. I’m gonna hand them
off to my malware guys. I’ve isolated the binaries. I can do this with Redline. I can do this with Volatility. But that is step six. You can see me
running procexedump. Yeah, pull that out,
and whatever process this was going to
be, you can see you can upload it
to Virus Total. Actually, my internal malware
reverse engineering team does a much better
job than this. So yeah, awesome. So identified the attack that
you helped me find. I have some remote IP
addresses I need to do some background research
on and run to ground, as well as this
notable directory. If I was gonna build some
behavioral indicators of compromise, that would be
the directory that’s notable. Not typical on a Windows
operating system, and timestomping the
use of psexec, dude, some very specific behaviors
that my attacker is exhibiting. And an outbound beacon, ah, that we identified running
the printkey command. So thank you very
much, you guys, and I hope to see you,
I’m gonna bring Chad up. Yeah, come on up! (applause) – [Chad] All right,
let’s hear it for Alissa. Nice work! (applause) All right, normally
Alissa trash talks file system forensics
quite a bit more, so we’ll take it
easier on this side for you as well. We’ll kinda do a little
tit for tat here. But I will tell you, we
got some great information. So there’s a reason why we often start investigation
with memory forensics. It is one of the fastest
ways to absolutely get that first hit or
get that first piece of information that
can allow us to then really break open our
investigation very quickly. That being said, when
we finally do get a copy of that disk image, look
at that Romanoff system, there’s almost 300,000
files on this system. And I, you’ll find out
tomorrow, for my students, but those of you
that know me well, I am one of memory
forensics’s biggest fans. But I will tell you
that even Alissa, of all people, Alissa, even she couldn’t actually
analyze 300,000 files from a memory image, okay? So, yeah. (laughs) Sorry. Truly do a deep dive on the box. And that’s what this
section’s about, is that I need to be able
to get those 300,000 files down to a manageable piece. If I pass, I don’t
know, 1% of those files over to Lenny, he’s
probably never gonna take my call again, right? I’ve gotta get down
to just what really is going to be the
important files for us and our team to
actually spend time on. So what we’re gonna
go through today is something we call
malware funneling. an idea of hundreds
of thousands of files, maybe even across
multiple systems, how do I reduce those down
to a very, very small, manageable piece
that I can then focus my limited resources on? We certainly, we don’t have
time to cover every piece here, but we’re gonna
cover a few of these. And we’re gonna see that
while memory analysis is incredibly valuable,
sadly, there is simply things that we just can’t
do in memory right now. For instance, digital
signature checks, known good hash checks
and things like that that are gonna be much. Where do you start, right? I hand you the system. Call out, what are
some directories? Where would you start looking? If you had zero
information right now, where are the known, what
are the usual suspects on a system? System 32? Local settings temp, user profile. Anywhere else? How about the recycle bin? Temp folders, Outlook cache. I’ll tell you one I
don’t see very often, but it kinda chills me. What about the McAfee folders? How many of you know every file that should be in an
antivirus folder, right? We have these very, kind
of a relatively small set of actually folders
where we can start to focus our efforts. So now instead of 300,000 files, probably have, I don’t know,
less than 100,000 files kind of in these, and in
some maybe only a handful, all right? That Windows directory
is probably gonna be about 60, 70,000
files in general. But that at least starts
to limit my focus. And that’s what each
step is gonna be doing in this hunting
section, which each step will reduce things down. I’m taking that haystack
and making it smaller and more feasible for us
to be able to identify what’s going on here. So we’ll do this with
a pretty fantastic tool called densityscout. So that’s a great start. Again, something that
we really can only do on the file system
itself, which is check for anomalous files. I’m looking for files
that don’t look normal. And so one way we could do that is look for things like
packing or encryption or compression. These type of files
don’t really exist a lot in legitimate folders
and directories. So by taking a tool to
actually analyze files for ones that we
call kind of packed or highly entropic,
or this tool actually call them dense, will
allow us to very quickly identify anomalies. So this is a tool
actually written by a guy named Christian Wojner. He’s out of the Austrian cert. Super brilliant guy, and it
has some really neat features. The way we’ll be
running it today is, I have a laser pointer,
we’ll be running it with a the dash P option. That means go through
and identify any file that has a portable
executable or DLL header, analyze the density for me and then report it
if it has a density less than this threshold
we’re giving it. So we run that, in this case,
against our Windows directory. So we go through the
Windows directory. The Windows directory
has about 70,000 files on this system. And if you look here,
we actually get a hit on about five. A few of these are duplicates. So it comes back,
out of 70,000 files, and says, “hmm, five of these
don’t look like the others.” That doesn’t mean that
they’re necessarily bad. It just means there’s
something we wanna look a little deeper into. So here’s the collection,
if you’re follow along at home here. Does anyone see anything
that’s obviously bad on that list? – [Man] Spinlock. – [Chad] Spinlock, absolutely. So that’s our second strike,
really, for spinlock, because our memory
analysis team already pointed it out to us. What about, what else? (man talking quietly) F-response, maybe, who knows? Maybe it’s not
really f-response. Maybe it’s just named to
actually look like f-response. At this point, we don’t know. But we do know that
we’ve got several files that are a little strange. Typically, in the Windows
system 32 directory you don’t see compressed
or packed files. It’s relatively rare. So we’ll use this
as a starting point. So now I’ve gone from
70,000 files to five. And we’ll move forward. The next thing we
might try is actually digital signature checks. Now, this is a
32-bit system, but even a 32-bit system,
a large percentage of your legitimate
binaries are going to be digitally signed. If this were a 64-bit
system, I’d say most of your files should
be digitally signed. So we’re getting to a world
where digital signature checks are even more
valuable than ever. Free tool from Sysinternals
to check these. This is, again, something
that cannot be done in memory. It’s something
that you actually. So I run sigcheck against
our Windows directory again. And this is what some of
the output looks like. And we see that at
least one of our files, that bootres.dll,
which I’ll be honest, when I first saw
it, I was 50-50. I thought that one might
actually be malicious. But we see it has a
digital signature. So that will give that
a nice green check. You notice that spinlock
is, not surprisingly, (laughs) unsigned, right? Which, again, doesn’t
mean it’s bad. It just means that’s one extra
kind of strike against it. So when we got through
that, we noticed that two of our files,
luckily f-response was signed. The thing I hate the worst
is when our security software doesn’t actually take the time
to use a digital signature. Makes me wanna kill somebody. So luckily f-response,
in this case, no one will be harmed in the
course of this investigation. But now we’ve got,
instead of five, now I’m down to three. So we continue. The next thing we might do is
actually look at known goods, in particular with
signature checks, because as many of
you probably know, we have several
examples recently of legitimate or actually
illegitimate (laughs) software, malware, using
valid digital signatures. So the best way to beat that is does it have a digital signature and is it part of a known
goods hash database? There are a bunch of great
known goods hash databases. Here’s a free one up here, National Software
Reference Library. It’s also ability to
check a free version of the Bit9 database. Billions of hashes
available for us to bounce things off of, and
getting better every day. So we take those hashes
from those five files. We throw them through
our known goods database. Here’s an example of one
that looked pretty weird. It was a DLL. It’s an Epson printer driver. So it actually
comes up as legit. It actually comes up as part of the MSDN subscriber
downloads in the Bit9 database. I am pretty confident I don’t
have to look any deeper. I don’t need to send that
to Lenny and the team. I’m pretty sure that we
can eliminate that one. What it would look
like if it didn’t match is actually something like that. So now I’ve given it a
hash, that out of billions of files, known
goods that it has, there’s not a single
hit in that database. Doesn’t mean that it’s bad. It just means that
it’s one extra check against that single file. And when we do that,
we actually notice that we’re gonna
have just a handful of files that don’t match. Another example of a free
tool that can dump out or allow you to do digital hash, this is a online
version of the NSRL put out by Kirus. Great option if you need an
online solution for this. But of this, now we
only have two files left that really have that
kind of the three strikes, you’re out kinda of idea. Does anyone actually recognize
frame package, by the way? Must be someone in here. It actually ends up, oh,
Rob Lee does of course. So we’ve got frame
package and spinlock. The next step is I’ve
gotta do a little analysis. Now, I actually (laughs) reverse engineer resources
are extremely thin these days, so I am going to
do whatever I can to validate these files
before I send them to, cause I want them to
take my call next time. And first thing I’ll do is
maybe do a little searching. I do a little searching
for frame package. It actually comes up. It looks like it’s
part of McAfee. And I find some information
related to the files. It turns out that it
is a self-encrypting, or self-decrypting archive. And that’s why it actually
came up as highly entropic. So what it is,
it’s a big package. It’s a deployment
package for McAfee. So I unzip it, it take a look, I match that
information in that file because I have the
file system to do so. And it looks like it matches. So I am pretty
confident that that file is actually alright. So now from 70,000
files, I’m left with one. I do the same thing. I don’t know for
sure spinlock’s bad. I do some searches. I live in Utah. I live not far from
the Novell campus. I’m pretty sure
there’s not a lot of Novell systems
out there anymore. And the fact that
I’m getting hits that go back to 2002
for this file name, I’m relatively confident
that that’s probably something to look a
little deeper into. We also run it through
some online sandboxes. The next thing you know,
spinlock, who knows? So if this is a
big question mark, I’m gonna have to
take it to someone who can actually analyze
it in a little more depth. 70,000 files, now
we’ve got one, right? So we’ll see what
Lenny can do with that in a short time. There are other
things we can do. I can actually do
analysis as well, just like Alissa pointed out. Being able to look into
the master file table, look at the actual metadata for files, it’s
gonna be extremely valuable. Here’s a quick Python
script that will parse that for us. And this is an example. This is the Windows
directory out of that tool. Seven files here
that actually don’t or weren’t put in during the
initial installation phase of that system. So immediately, I’ve
reduced down again from 70,000 files to those
six or seven outliers to look a little deeper into. And I won’t even
ask, because I know a few of you are
ninjas around here. There’s probably more
than a couple in there you might be interested in. You can also do
something even better. You can start to use the idea of how things were installed
in the system for our help. So it turns out that
most of the files in the Windows, this is
Windows system 32 folder, were actually copied
in sequentially when the installation media
is actually first used. As such, you’ll see these
very, very consistent MFT record numbers. So there’s one after another
after another are copied in. You notice that these
ones that showed up long after that fact
actually are wildly different than any of the others. We’re looking for the anomalies. What doesn’t fit? So I would add these to my list. And I’d go do this
same step again. Are they entropic? Do they have digital signatures? And do they actually
match my known goods hash database? We can also do a
timestomp detection. Alissa covered that pretty well, but we’re looking
for those ideas. A lot of people do not realize that files do not have a
single set of timestamps. They actually can
have three, four, five different full
sets of timestamps. You have more timestamps
than you probably have time to even look at. Tools like this allow us
to view the comparison side by side, looking for
the ones that don’t match. In this case, we see
that service host is clearly something
we wanna look a little deeper into. We can also go old school. In many cases, I
actually have a student, I don’t know, Federico,
(laughs) you did this today. So he’s in there, he’s
playing find the hacker. We just got our image mounted. He’s already in the prefetch
looking for strange anomalies. To a trained eye. That on their systems. If you have, you
better call back. It’s a problem. We have a tool that
can parse those, so we can actually get
the embedded information out of the prefetch. So if the pf tool’s on
that SIP workstation, many of you have been working
with already this week, we run that against that
strange TOPLZAGU.exe. Looks like it’s
only been run once. It was run on April third,
right around the time when we saw other
files of interest within memory being run. And we get a full path. Looks like it was running
from the Windows directory. Similar to what Alissa
was doing, we are looking for pivot points. Everything we find allows us
to find other items, okay? So for instance, just
knowing that this was run at 4/3/2012 makes
you really wanna know what else happened
around that timeframe, which gets us into the
idea of what we call kind of super timeline. So we look at our
file system timeline, and now is when we
can really start to go second by second, what
happened on that system. And in fact, we can kind
of see this in action. So if we look at the
top, we see a event log, entry 4624, for an
account named vibranium, followed very closely
by the creation of our TOPLZAGU.exe. Now I’ve tied,
potentially, the existence of that bad file, or what I
believe to be the bad file, to a known account, which
may be a compromised account. Now I’ve added to my list of
indicators in this example. We also see directly
after that, within, I don’t know, 21 seconds
of it showing up, it’s run. I see a file execution. I see a new service created. Actually, those are
reversed. (laughs) So I see the actual
service created here, and I see the execution here. Then I actually see my bad
guy, or vibanium account, I actually see them log out, followed by, bizarrely,
in the exact same second, a new file created. Anybody heard of svc.exe? I haven’t, but it’s sitting
in our temp directory. So now we’ll take that and start our analysis all over again. So one hit leads us to another, which leads us to another,
which leads us to another. What do we do? We build signatures. As we find intelligence
information, we build them. Whatever format that actually
is gonna win the day, we won’t know. There’s several very
good formats out there, from Yara to OpenIOC
to the Miter STIX, but we’ve gotta
have a way to define what we’re finding. These are our lang. Including memory analysis. We take that information, we get it to our RET team, which gives us more
additional intel. We take that information,
like the IP address that Alissa found. We give it to our network team, and then we use all
that information to scope and find a whole
nother set of systems that again, we continue
to move forward with. (laughing) And in the words of the
immortal Charlie Sheen, “that’s when we roll
the magic,” right? So we’ll start off now with Phil to talk about a little
network forensics, with all the information
we’ve kinda handed him. (applause) – [Phil] All right. So first thing I saw
when Alissa started out was she started
out with what piece of information we had from
the third party notification? We had an IP address. What does the IP
address tell us? It’s an address on the what? It’s not a memory offset,
it’s a network address. It’s kinda like saying,
“the robber stole a whole “bunch of cash. “Let’s go to the paper factory.” No, you go to the bank
where it came from. So that’s where we’re
gonna start out. There’s one other thing
that I think is interesting, is that how often
do you usually get notification from a third party that you have a problem
on your network? And that’s within a
period of validity for the memory to still
contain the malware. (laughing) Three times a day? You’re very lucky, sir. Course, memory
certainly has its place. I’m not dogging
it as a practice. I just kinda like to
make fun of Alissa cause she likes to
make fun of me back. So it works out pretty well. So anyway, I’m gonna use
the network perspective on this, as well. And this is the first time
that we’ve approached this in this environment. I think it’s gonna
be a lot of fun. So why do we look at
network forensics? Well, there’s a couple
of things we can do. We can supplement
system-based findings. Hey, look, there was
malware that was executed. We see this in our
super timeline. And immediately thereafter,
the nuclear power plant CAD plans also had an
access time updated. What happens then? Did it traverse
the network or not? Well, we don’t necessarily know unless we go look
at the network. We can identify additional
systems that we want to examine. Here is an IP
address that we know is associated with command
and control traffic. Show me all of the other systems among my 50,000
network environments that have communicated with
that IP address as well. Very useful. Or we could use it as the
only investigative medium. Let’s face it, sometimes
we don’t have the drive, we don’t have the
memory image available. This is all we have. The other thing I like to
say is a lot of this memory evidence is pretty
quick to acquire. My goal is to try
and solve this before Chad gets his disk image
done on the write blocker and before Alissa gets
the memory image created, because if we can solve
the problem more quickly or at least generate
the leads more quickly, we’re gonna come to
findings more quickly, and we’re gonna increase
the quality of our results in terms of timeliness
and accuracy. So I like to say that
network forensics can be the chicken, the
egg, or just the frying pan. But if you don’t
have a plan on how you’re going to
attack this domain, it’s just the
fire, and it hurts. My kids are eight and
five, and they know to keep their hands
off the stove. We need to learn that, as well. So our preferred approach in an, the normal from what
I observe, and I get terms of which systems you’re
contacting on the outside. Here’s the example that I
like to use, real briefly. South Park first came
out in like ’96, ’97. I watched the first
South Park because we all at my school at
the Air Force Academy emailed around a 50 meg AVI file on our Banyan VINE
network and watched the stupid AVI video. (laughing) Well, what would that be now? YouTube, Vimeo, et
cetera, et cetera, all these other sites. The characteristics of the
way our networks behave changes over time,
so we need to have some kind of a
historical information, which, let’s face it,
is either unavailable, nobody bothered to create
it in the first place, or it’s outdated. So we also have to have
some kind of a process that’s a blind approach. If I know nothing
about this environment, how am I going to approach this? And some of the things
I like to look for are first of all,
workstation-to-workstation
communication, just that soft, soggy
middle to the network. It’s gonna be how
does the attacker spread laterally
throughout the environment, because the administrative
assistant’s machine very rarely should talk
directly to the CEO’s machine. They should be talking
through a server of some kind, of course. We look for really
large transfers. Those are gonna tell
us, potentially, where data loss
may have occurred, especially if that’s coming
directly from a workstation. We might look for
suspicious IPs. I put that in quote
because an IP address by itself is just 32 bits of who knows what. We don’t know what
that is until we have some intelligence to
apply over the top of it. And I say that we may be
able to hone our approach by saying, “hey, administrator, “I see this giant
transfer to an EC2 node “at two in the
morning local time. “Does that matter?” Well, the admin’s
gonna say, “well, yeah, “that’s when we do our
backups to an offsite node.” Okay, rule that out. Or we can say, hey, talk
to the administrative assistants again, “you
did a whole lot of work “on this IP address in Shanghai. “What was that all about?” “Oh, well, the CEO’s got
a business meeting there “next week, and I had to
book dinner reservations,” or hotel reservations
or something like that. So that’s gonna be a
completely non-technical layer that we can apply to this
to kinda focus our efforts where they’re gonna
be most productive. I’m gonna constrain
the way we look at this for this presentation
as follows. We’re just looking at lateral, workstation-to-workstation
connectivity. Therefore, we wanna go back
to our network diagram, identify those servers,
and rule them out entirely. Doesn’t mean we can’t go
back to them at a later time. But let’s just
start out by looking for workstation-to-workstation. Now, remember what I said. We’re looking for
fast, decisive, accurate, actionable
type of intelligence. We’re looking for these
findings very quickly because we wanna
be done before Chad gets that disk image
so he owes us beer. Or you can just
owe us beer anyway. And in doing that,
we’re going to seek the artifacts of communication. Folks that are in 572,
you’ve probably heard me say this plenty of times. Please don’t put a tip jar
out for me saying this, cause I’m gonna
say it a lot more. We’re gonna look for
all these sources of evidence that
are gonna tell us about the communications
that occurred. Now, I’m gonna skip to
number two, pcap files. Network captures are great. And if we can get
them, all the better. We’re gonna talk about
that in a minute here. But we don’t always have that. So we’re gonna look
for other mechanisms. We’re gonna look
for NetFlow data, which is my most favorite source of network evidence ever
because it is so valuable. You just cannot even imagine. But all these other log
files, routers and firewalls, tell us where things
are gonna be blocked, tells us where packets
were maybe forwarded along if we have a certain type
of routing logs enabled. Our IDSs are gonna
find anomalous content. And if we’ve got centralized
logging of any kind, logs are great because
they go really far back. Great historical norms, we
can use them to our advantage, and we can use them
to show the evidence of what these communications
were that occurred. Let’s talk about using nfdump. This is NetFlow. We’re parsing NetFlow here. And basically what
I’m doing is saying show me anything coming from
our IP address of concern, 58.5, and show me communicating
with any other system inside except for the servers. And in a whopping seven one
thousandths of a second, I know, it takes a
while, I only had four processors on this system, could’ve done it faster. But in a whopping seven one
thousandths of a second, we were able to
identify that there were these five types of
communications internally. We aggregated this in order of the destination IP
address and by volume. So let’s take a look at
each of these in sequence. First of all, okay,
local broadcast traffic, pretty common with SMB and
a number of other protocols. And it’s only 200 K. Maybe I’ll look at that later. I’m gonna rule that out for now. Well, 58.1, it’s
reasonable to assume that that might be
the default gateway. I’d be able to find
that out pretty quickly through interviews. Let’s roll that out,
cause, by the way, it’s not even a kilobyte. But hey, we’ve got
58.5 talking to these three other workstations
in our environment with some pretty heavy volumes. Let’s dig deeper. I wanna find these
periods of activity, and I’m gonna run
another nfdump command, and if you saw this
one, it also took about four one
thousandths of a second. Trying to get it faster. And we’re able to
see that there are the periods of activity. These are in UTC time. We might be able to say is
this a normal period of time for people to be operating
in this Stark environment? But there are still
550 flows of data. If I take a look at the
protocols, or excuse me, the ports that are
being used here, ports and protocols, I’m
gonna find the following. I’d see 3389 TCP,
possibly remote desktop. We don’t have enough content. I don’t know that
that’s RDP yet, but it’s a reasonable
assumption. I see some SMB potential,
and I see some HTTP potential and some ping stuff. The way that I like
to look at this, high volume tells us where
we need to focus immediately. Low volume tells us those TTPs. It’s gonna tell us our
attacker tool marks. Do they have a toolkit
that they’re using that’s knocking on ports? If they’re looking
across our enterprise for port TCP/22, maybe
they have some kind of SSH credentials or
exploits available to us or to them. So let’s look just
at the RDP traffic. And I’ll get through as
much of these as I can before Rob goes to get
a gong and gongs me off. So the RDP traffic
itself, I’ve isolated, again, just using NetFlow, and I’ve isolated
those communications between just these two
systems, 58.5 and 58.7 on port 3389 TCP. Actually, I didn’t
limit that to TCP, but it works out the same. Well, I see that there
are a number of periods of very reasonably high volume. We’ve got a number of
megabytes of connection between these two systems. And I wanna better identify
what that would be. Now, I’m not gonna be able
to do that from NetFlow. NetFlow has no content. NetFlow is just an aggregation, a high-level summary
of this communication. But if I plot these
out on a timeline, I’m gonna see these different
periods of activity. The first thing I
wanna say is yes, there was successful
RDP activity. We saw traffic flowing
in both directions, we saw byte counts
that were pretty high. There was RDP. That’s a good finding. But I’m gonna go back
one slide right now, the first RDP was from
58.7, communicating to the RDP port on 58.5. Wait a minute, what did our
third-party notification say? Look at 58.5. Ooh, somebody’s out of sequence. That means that the attacker
had an earlier access to the network than we
previously understood. We’ve altered our
timeline significantly. Very valuable finding. Later we see that the
attacker then went from 58.5 back to 58.7. Well, why would they do that? Did they lose access to 58.7? Did it get patched? Did it get pulled
off the network? Did the individual,
was it a laptop, the individual left for the day? A lot of questions
outstanding we don’t know. But we certainly have an
interesting observation to put on the timeline. And then I will go back one. Note that I wanna
identify to see if that might be
a good indicator to look for in
future activities. So that’s the first,
that’s what we can tell from the NetFlow data
on the RDP connection. So looking at the SMB traffic, I wanna look at the timing
and volume to begin with. And what we’ll see
here is that we’re able to establish the
timeline, again, the byte counts. This is great. It’s just gonna give us a
huge list that you see here. It’s giving us a total of
62 flows that are listed. But really, which of
those do I care about? Well, I need some kinda
means of doing that. I wrote this cool little
shell Python script because I had to do
this so many times it’s easier to write a
Python script than not. And I said, just
give me this in CSV. I wanna take the time and I
wanna take the byte count, and that’s all. So I just threw that in here, dumped that into the
timeline, and hey, or dumped that into a
graph, and hey, look, I’ve got this period
of what I believe might be interesting activity. Starts at the time listed here, lasts about 48
hours, and is between our two systems of interest using what appears to
be the SMB protocol. Okay, what’s in the box? I tried to get the video,
but it didn’t work. So what’s in that box? We’re talking about NetFlow. We’re talking about the
high-level information that does not have content. So where do we go? Gotta use the pcap. We’ve gotta go to content. If we use content, what
are we able to say? Oh, hey, that’s cool. One real quick tshark
command, cause as everybody who’s in 572 knows,
if you can’t do it in a shell prompt,
it doesn’t count. (applause) What we see here is
I’m ripping through the pcap with tshark. I’m saying, show me
all the SMB file names that were accessed. Psexec service, did we
hear about that earlier? Yes, we did. But I found that way before
Alissa got her memory image. Oh, hey, a pcap. Do you think a
pcap, or a PST file, do you think a PST
file is interesting? Ayo, yes, absolutely. That’s not something
that two workstations should be exchanging, is it? Generally, I would say not. But here’s some other
cool artifacts we can pull out of a pcap file with
regards to this transfer. We first see, and
I’m not gonna go into the full setup of the SMB here, we first see that yes, the
file was successfully opened. We see these MACB times
at that time of capture. File system forensics,
memory forensics, they only give
you the MACB times at the time you
acquire the image. If we look at this in the pcap, if we look at the
network side of things, I can see how these
change over time. When did the attacker
timestomp the file? Cool finding, really cool
finding, when this changes. When did the attacker
run an executable that accessed or changed
the contents of the file? All that can be
identified from the pcap. And of course we get
the 56 meg file size, all out of the SMB protocol, because when we go
back to our NetFlow, we had this flow
of about 61 megs. Certainly consistent
with a 56 meg file when we consider SMB overhead. We can do a lot of
other cool things. We can confirm that
the account name and the domain name
that were used for this, the timeline lines up, as well, coincides with a large transfer. And just real briefly, yeah,
we saw that HTTP in there. I was kinda surprised
to see that at first. It ends up that it’s WebDAV. Why in the world
would these systems be using WebDAV
between each other? Well, you take a
little step back and you look further, and
it appears to be failover. It attempted to
make a connection on the SMB ports and failed. And for some reason, it
then fell back onto WebDAV. The same things
happens later, after an authentication failure. So it appears that
there was some kind of lateral file
access being attempted that failed, and
that’s why we flipped into HTTP mode. There’s a lot of other
directions we can go from here. Clearly, Lenny’s
gonna get up here in just a minute,
we’ve gotta be able to find those binaries to feed those hungry malware analysts. If the attacker created files, if we found evidence
of that, we’re gonna wanna find those files. When did they get created? How did they get moved? When did they get changed
and accessed and populated? If we have command and control, we can reverse
engineer that, too. The folks in 572,
we’re gonna do that on day five this class. If we identify those
IOCs, we will at least wanna know about them. We may not wanna
block them, because if we block them too
soon, we blow our op sec. And maybe we would wanna
use our DNS query logs to identify which host
names the attacker was using over time,
because everybody knows all good things come from
co.cc top level domains, right? Nothing but good stuff. It’s all totally legit, promise. So with that, I
think we were able to solve it relatively quickly. Again, Chad, what’s your
percent complete by now? (man talking quietly) (laughing) (cheers and applause) Ah. We’re in a properly instrumented
environment, my friend. (laughing) So thanks very much. That’s the network side. But here is Mister Lenny. (applause) – [Lenny] All right. So let’s talk about malware now. So far we’ve been
analyzing the footprints that the attackers have
left on the system. We looked at the
footprints they left in memory, on the network,
on the file system. And malware is the tools that
the intruders left behind. They’re right there, well,
thanks to our other colleagues who found them, and
we can learn a lot about the attackers,
about their capabilities, about what they may have
done on these systems, by analyzing these tools,
by looking at this malware, which provides us
many ways, the window into the soul of the attacker. So that’s what malware
analysis is about. And that’s the course
that I teach at SANS, reverse engineering
malware, 610. And so that’s why I’m
here talking to you about analyzing malware. Now, those of you who are wondering what we’re
gonna be discussing when analyzing malware,
I’m gonna specifically talk about this one
suspicious executable that has come up on several
locations, spinlock.exe. Now, I’ve got a copy
of this executable from my other colleagues. They pulled it off
the file system. I brought it into my
lab, that’s isolated, so that I avoid
infecting systems that I don’t want to infect. And now I’m staring right at it. That’s our adversary, a
cute little icon like this. How could it possibly be bad? And we’re gonna
figure out, sometimes, maybe it’s not bad at all. Maybe it’s a false positive. Let’s take a closer look at it. And if it is malicious,
let’s try to understand the capabilities it might
provide to the attacker. Now, there’s a lot to be
said about malware analysis. We don’t have time for that. There’re different ways
in which you can look at a given executable. For example, you could
reverse engineer its code. We’re not gonna do that. In the few minutes that I have, I’m gonna focus on
understanding the capabilities of this malicious software
by looking at how it behaves. I’m gonna bring it into my lab, I’m gonna run it with
having the right tools, looking at how it executes. And I can learn a whole lot about the malicious
program that way. But even before
running the program, I’m gonna try to look at it to see what else I can
learn about this program. Maybe I don’t
wanna waste my time even infecting a
laboratory system. Maybe it’s not malicious at all. Maybe everything, all the blame that was placed onto
spinlock was misplaced. So I’m gonna use a few
tools, first of all, that run on Linux. These are tools that
are available to you for analyzing a
suspicious executable without even running
that program, so it’s relatively safe,
so that you can determine is it worth your while taking
a closer look in the system. Now I’m gonna run these tools on a Linux distribution that
I maintain called REMnux. It has a lot of tools
useful for malware analysis already pre-installed for you. And those of you who
have not played with it might wanna download it
and start taking a look. It has some of the tools
that you already find on SIP workstations,
but it tends to be a more lightweight environment designed specifically
for malware analysis. Pescanner, it’s a
Python script, actually, so you could run
it on a Windows, in an OS sandbox as well. You point pescanner
to this executable. And you’re wondering,
how likely is it that this executable
is actually malicious? Pescanner will look
at several aspects of the executable,
and it will try to point out those
aspects that might suggest that it’s malicious. Now, in addition to
giving you some hashes of the files that you
could investigate online, this tool also
scans the executable to find out a few
suspicious things about it. For example, a
Windows executable, in most cases, relies on
standard Windows API calls to interact with
its environment, to talk to the network,
access the file system, to modify the registry, to
interact with other processes. All of this is done
through API calls. And for a Windows program
to make those API calls, usually there will be
entries naming those desirable API calls embedded
into the executable. They’re embedded in a
place of the executable called the import address table. And pescanner looks at
the import address table, and it pulls out those entries
that might be suspicious. For example, here we
see that this program wants to be able to
make a Windows API call CreateProcess. Is that bad? Does that mean that
this is malware? Not necessarily. Lots of legitimate
programs wanna be able to create processes. But this is one of those things that we will keep in
the back of our mind when we try to assess, is
this program malicious? It creates processes. Maybe a little bit
suspicious, but not, a Windows executable
is comprised of multiple sections. Some of these
sections store code. Some store data. And pescanner here notices
that one of the sections within this executable
is suspicious. It is suspicious because
it’s highly random, it’s highly entropic. And that is unusual. That indicates that
there is something compressed or maybe encrypted
within this executable. Does that mean that
it’s malicious? Again, not necessarily. Plenty of legitimate
software developers protect their
intellectual property by encrypting some
or all of their code. But this is yet another
one of those flags, red flags, that
suggest that maybe this is indeed a
malicious program, and we might wanna take
a close look at it. We’ve seen it under
suspicious circumstances, as we witnessed in memory
and file system forensics. We know that it makes
a suspicious API call. We know that it tries
to protect itself. And if it’s done
nothing bad, then what does it have to hide? That’s our perspective,
at least in this context. Now, you might wanna start
your analysis of a program, even without getting
into its code, by looking at what strings
are embedded into it because sometimes
these strings can look really nasty and scary
and tell you right away, “I am malware.” Well, it’s not quite as obvious in this particular example. And I’m here using
a tool called pestr. Pestr is a tool for
pulling out strings. And you might wonder,
why didn’t I just use the Unix tool strings? It’s because I wanted to
show you something else. (laughing) I wanted to be different. (laughs) But pestr actually
has some nice properties in that the normal
strings command by default extracts
only ASCII strings. You’ve gotta give it
command line parameters to tell it to also
extract Unicode strings. Pestr extracts all
of them at once. Also, pestr has some nice
parameters you can specify. For example, you can
tell it to automatically pull out only those strings that might have to do
with network properties, like IP addresses and URLs. You can craft your own
regular expressions using graph if you wanted to. But pestr makes
it easier for you. Anyway, here the string
that caught my eye when I was looking
at this was MEIPASS2. Now, maybe it’s ME IP ASS,
or maybe it’s MEI PASS. I don’t know, but it
just looks strange. And so I thought, “all
right, let’s google it.” Let’s take a look to
see what I can find for this string. A lot of malware
analysis starts that way. A lot of forensic
analysis starts that way. You notice something that
is just a little strange, and you decide to
research it a bit further. So when I looked
it up in Google, I found some references
to this string in the context of
Python, and specifically in the context of a program
called P-Y Installer, PyInstaller. So I read up on it. And it turns out that
yeah, this P-Y Installer can generate Windows executables
out of Python programs. So now I have a little
bit more potential context for what this malware
might be doing or how maybe it was created. Now, at this point I
am reasonably certain that I wanna spend at least
a little bit of my time taking a close look
at this executable. So I bring it into a
Windows system in my lab, and I infect the box. But before I infect it,
I launch several tools that can give me some
visibility into what happens on my host when I infect it. One of these tools
is called Ragshot. It’s a freely available utility. You run it while the
system is still clean. Then you infect the Windows box. Then you run it again,
and it’ll tell you what has changed. And lots of changes
occur when Windows runs. Most of those
changes are normal. So there’s gonna be a bit
of noise in this log file that it will generate. But there are some changes
that have occurred here that look meaningful
to an analyst. It turns out when I run
this malicious program, or at least suspicious
at this point, it creates a few DLLs
and a few PYD files within the temporary folder. Now I have something
more I can research. I see that these are
Python-related DLLs, which further confirms my theory that this program might
have been initially written in Python, and then
perhaps it was compiled into a Windows executable. Now, if you wanna see
how the program runs, very handy tool to
replace the basic, boring task manager in
Windows is Process Hacker. It will show you that
when this program runs, it is right there,
visible to you. It’s not trying
to hide from you. It appears to launch a
subprocess under the same name. Is that useful to me? I don’t know, maybe. Maybe not very useful,
but Process Hacker has this tab that lets you look at the network
activity associated with your running processes. And if you look at
the network activity, you can see that
this executable, spinlock.exe, is talking to
a remote IP address on 443. It is trying to
communicate with it in the outbound direction. We see the SYN packet is sent. Now, this information
might be useful for us to pass along to our
network forensics colleagues so that they can
look at the traffic that they have captured
for any activity related to this IP address. I know that we
have focused so far on traffic within the network, but this might give
some useful information for looking at, understanding
what the attacker did when communicating
with the infected host. Now, port 443, any
theories what protocol they might be speaking? HTTPS, I know it’s too obvious, so none of you are
actually saying that. Well, that’s what
I thought, HTTPS. Now, the reason this
is interesting to me is because now I
can try to bring up a web server in my lab, and
I can convince my malware that it should talk to it. Now, the IP address that
it wants to talk to, 199.73.28.114, it’s out there
on the internet somewhere. I don’t wanna talk
to the real host. Who knows who’s
controlling that box? Maybe it’s bad for me to
even try to talk to it. But I have an isolated lab
that’s fully under my control. So what can I do? Well, maybe investigate the
traffic a little bit more, get some additional
perspective into what this protocol might be. Is this indeed HTTPS? Is it indeed the
activity associated with the system
that I’m analyzing? Yeah, I thought I’d
just mention briefly another tool that you
might wanna play with if you haven’t done
this before, CaptureBAT, that reinforces
some of the findings that I had seen. Shows me that indeed
it is this spinlock.exe that creates those files
that I have observed. And this is the tool that
can create a pcap file that I can examine to
reinforce my earlier finding related to that
connection on port 443. So now I’m reasonably certain that this program is malicious. And I think that it might
have been written in Python. Maybe the attacker generated
a Windows executable using P-Y Installer. At least it’s a
theory worth going by. Now, is that useful
for you to know that the attackers used Python? Maybe not, maybe it’s totally
worthless piece of trivia. Or maybe you will say,
ah, I know a group, an attack group, and
this is their MO. They like to do this. And this, now, right
away helps you associate this incident maybe
with some intelligence that you have
gathered from earlier. So you’re looking at how
attackers write their malware and how they use it, to
connect various incidents that otherwise you
would have thought were independent
from each other. So just to summarize
what we’ve done so far, cause I wanna take a
slightly deeper dive into this executable. So far, we have learned at least how to spot this
malware on systems infected in our environment
and on our network. We know how it generates
certain network traffic. We know what files it generates. And now we can take
a comprehensive look at all of the systems
in our enterprise to see if any of them have
this particular program, even if on other systems it
might be called something else, even if on other
systems, it might have a slightly different hash. Chances are it’ll
leave these footprints on the host and on the network. Now, what I wanna
do, though, is to get a better understanding
for what the attacker can do with this system. I mean, fine, it’s malicious. But what does it actually
do, beyond communicating with the attacker by making
an outbound connection? So again, since I have
full control over my lab, I’m gonna bring up a
listener on my system. And I’m gonna configure
one of my own systems to mimic the IP address
that the attacker is trying to connect to. Easy enough, you can
assign an arbitrary IP to a host that you can control. On Linux, you can use
the ifconfig command. You can configure
your Windows host that you’re gonna infect
to belong to this network, make sure that the IP
addresses are compatible so that this conversation
can actually occur in your environment. And now my theory so
far is that the attacker is using HTTPS. But since I have not taken the
network forensics class yet, I don’t know what HTTPS
normally looks like. So I figured, let
me take a look. I’m gonna launch Netcat. Natcat dash L
tells it to listen, in this case on port 443. And I connected to that IP
address using a web browser by typing HTTPS. And I saw that even
though I cannot tell what data is being
sent, even though by simply connecting
to the Netcat instance that’s pretending
to be a web server, there’s some data
that’s being sent over, some gibberish that initiates
the handshaking process. So this is what HTTPS looks
like in the very beginning. Some data is sent to what
appears to be a web server. So then I did the same thing
with the malicious executable. But when I infected my host
and I redirected the traffic and I started the
Netcat listener, even though I saw
this SYN packet and the session was
established via SYNAC, the malicious program
did not send any traffic. So it is not necessarily HTTPS. All of us were wrong,
except those of you who were quiet. Maybe you knew all along. This was not HTTPS,
even though the attacker is using port 443. So what protocol could it be? This is where I
need to experiment. A lot of malware analysis
is trying a theory out, proving yourself wrong,
trying something else. What I thought I’d try
here was Metasploit, just because in my previous job I used to do pentesting and
so Metasploit came in handy. And I thought, “let
me give that a try, “because I know that
Metasploit can create “an executable that can
talk back to the attacker “via a reverse shell.” So if you wanna install
Metasploit on REMnux, cause that’s the tool that I use for analyzing malware,
it’s easy enough. I got some commands
here that just, in a few minutes you
can have Metasploit up and running on a
Linux environment. And then you can use Metasploit. Now, of course, you’re
gonna use the command line version of it, cause that’s
what we do here at SANS. And the command line version
is called MSF console. And I have done what
I would have done if I were the attacker. I’ve got commands
here in Metasploit that say create a reverse
TCP shell listener listening for
connections on port 443, cause maybe that’s what
the attacker is using. Well, long story short, I’ve
got my Metasploit listener listening on 443. I infect my laboratory
system with spinlock. Boom, I’ve got a remote shell. It looks like a DOS window. Of course I can type
arbitrary commands, and as most attackers
would, they type ipconfig. Well, that’s what I
typed, cause that’s been my dream, to type ipconfig
on somebody else’s system. (laughing) And now I can. Metasploit gives me that power. But of course, now I’m in
control of this backdoor. And it is a wonderful feeling, cause now without
analyzing the code, I can experiment
with this backdoor. This is a backdoor,
this is how the attacker is able to remotely
control this system. And once they’re in,
they’re gonna probably do some reconnaissance
and spread laterally throughout the organization. And by the way, here
I used Metasploit in a very, very
basic way just to get this remote console window
using a generic handler. And by the way, I can see
on the infected system that now my spinlock
launched command prompt. But if I were truly an
elite user of Metasploit, I would probably
use Meterpreter. And you can do that. And I gave it a try, said,
“give me a Meterpreter shell,” which is a much
more powerful shell than the basic command prompt. For example, now you can
do truly elite things like take a screenshot of
the infected system remotely. And now we’re truly in business. We can spy on the user. And so all of this is
through malware analysis. We have derived a
lot of information about what probably
happened on this host. And we now understand the
role that spinlock plays. It’s a backdoor that
allows the attacker to remotely control the system
to which they gained access. And they’re doing this
using outbound traffic on port 443, though
it is not truly HTTPS. And this is why we
perform malware analysis. We understand the
attacker’s capabilities. It gives us a fuller perspective on what has happened
in this environment and what might
happen in the future if we don’t properly
contain this incident. So if this topic interests you, I’ve got lots to say
on it on the web. For example, you can
download a cheat sheet on reverse engineering malware. You can easily
find it on the web, and this is as much as I’m
gonna say about spinlock. Rob, it’s all yours. (applause) – [Rob] Gonna fill out the
evals, before. (laughs) Have some really
amazing stuff, folks. I mean, really started
with Alissa at the beginning of this,
with memory forensics, really diving into it. Amazing stuff,
really stupendous. And I’m sure everyone
is still like, “wow.” You’re in shock with that. Phil, on the other hand, came in immediately after Chad. I don’t know, it
was kinda funny. Whenever you talk
to the network guys, they’re always like, “we
don’t need anyone else.” And to prove the
point, I recorded Phil the entire time when
everyone else was presenting. And under his breath,
he’s saying, “saw that, “been there, got that,
saw that, saw that.” (laughing) “Saw that, saw that, of course.” “Duh,” a couple times. (laughs) And so forth. So I just recorded
a couple seconds of what he was
saying in the back. So Phil got up there and
did an outstanding job of showing how important
network forensics is. And of course Lenny came in here and really showing you
how the malware is. Now, somewhere between
Alissa’s first “what” and Phil’s first utterance
of the word “NetFlow,” the executives fell
asleep, who you’re doing your presentation to. Put yourselves in
their shoes real quick. If you’re giving
this presentation to a bunch of executives,
say you’re the executives behind the target breach. You’re sitting there, “hey, wow, “look at all this stuff that
we’re able to determine.” The FBI called, they
gave us an IP address. Out of the blue, they
called, and they said, “yeah, you’re hosed.” And we initially doubted
it because we’re so smart. And we detect things
on our network. And so did an analyze this,
we found all this stuff. And somewhere between
that initial point in where we’re at right
now, they fell asleep. Why? If you’re the executives,
what key questions have been answered? None! None, there’s the
what and the how, and it’s like the
incident response team is up here saying,
“look how smart we are “and how much we were clowned “for the past year that
the APT was on our network. “Oops.” But it’s okay now. It’s okay, we found
everything that they did. And Phil’s like, “yeah, I saw
it actually six months ago. “But no one believed me.” (laughing) When I tried to
tell them about it, I saw some anomalies,
and my boss told me to shut the hell up, and we’re not gonna go
buy a new network tab. So the real question
is what happened? When it comes down to
it, and I’m not saying host-based forensics
is going to answer a lot of those questions. But the so what
comes into effect. And to give Phil some
credit, he actually had a little bit of
so what in there. You did mention like, what,
a PSC file that was grabbed and some other psexec service. But it’s still, if
you’re a target, were credit cards stolen? What specific
intellectual property was stolen from this network? If that is a similar
type of attack here, then the executives are still
going back to the beginning, saying, “listen, we’ve
been in here for an hour “and a half, and you
haven’t told us anything.” Other than, hey,
here’s how they went from point A to point B, the how and the what and the where. That is actually very important, and I’m not meaning
to scoff at that. But from a security
operations center perspective, that’s how you can detect
them in the future. The reason we haven’t been able to detect them in the
past is we’re essentially not learning from our mistakes. We’re not learning in
building security intelligence to be able to actually
apply the tools, techniques, and procedures
of how attackers actually think into our
network detection protocols. The reason instant
response exists is to basically become smarter for our detection side. For many years,
instant response, and a lot of you
out there are part of this surge team element,
that you’re only called in and you put your IR team hat on when stuff really
bad is happening. But now the IR team is, first place, and then
leverage that back into our detection algorithm. We actually do have a chance
to detect them in the future. But part of this question
is what goes back into, say, well,
what did they do and why are they there
in the first place? Half of security
intelligence is being able to do predictive guessing
of why they’re there, what they’re after,
and potentially start building up additional
defenses around that. So the last piece
of this equation, and I’m tongue-in-cheek
a little bit about what the other team did. But in reality, you
could potentially create a really good detection
algorithm for spinlock. That’s true. But what if we’re
now able to determine that the vibranium incursion, why we call it
vibranium is actually goes back into if anyone in 508, it’s actually what
the team is after. Stark Research Lab, if you
really ask the question, what do they do? They’re a biological and
metals research facility. They invented a new
alloy called vibranium. And they just found a
brand-new algorithm. So as a result of
this, if we know this piece of information,
you don’t need to be a rocket scientist to say, “okay, where’s that
information on our network, “and maybe we should
put additional defenses “around those systems.” That’s part of the question here that we’re gonna be
able to answer here. So the question comes
into maybe we’ll be able to answer
some of the who and how we know they’re
targeting vibranium by looking at how
they’re interacting with the system directly. So here’s some artifacts. And we’re not gonna
go into the specifics of each artifact,
because honestly, that’s what all 408 and
all the host space analysis class is about. And we have Windows forensics, as Cindy and Heather talked
about the smartphone side, you’d be able to
do the same thing. And in this, coming
off this paper, we have Mac forensics. So depending on
the actual device you have on a
network, being able to analyze it
properly to be able to answer some of these
questions is gonna be, this is some of the stuff
you might see from this. One of the things we see
as part of our log file analysis on here, I
like throwing this out there almost
immediately, is we see that vibranium logged in. And when they did so,
and this is one of those, for those who do
investigations all the time, RDP’s kind of a, for
your attack team, kind of a great tool to use, but it’s also very telling tool. Most people think, even
though you go through like a Tor network
from point A to point B and go RDP from
here to over here, what ends up happening
on the client side, what’s actually passed is
a remote client credential, even if you’re bouncing
across the entire planet. And on the other
side, this IP address and this client information
is gonna show up over here, despite how
many hops it goes through. A lot of people,
especially attack teams, don’t know that. In your log files, we
actually get the RDP login, we get the vibranium username. But what they don’t
know is the client name for the PC that it logged
in was a PC machine named with LAN Master. People always ask, “how do
we know it’s the Chinese?” Well, a lot of the machine names that we saw there were Chinese, using Chinese keyboards. It’s another profile
that’s passed in. Notice, when you
RDP, could you set your keyboard layout when
you log in to remote systems to be something other than
what the remote system uses? Yes. So we’d actually
see that switch over to something like
Chinese keyboards. Those are some of the
little clues over the years that we were able
to put together and think, “wow, this
is really starting “to smell like
it’s either someone “who speaks Chinese, or
it’s probably the Chinese.” Another thing that
comes in here is IP address. You start doing a lot
of the correlations. And Phil and this network team actually do a lot
of this, as well, watching where all the
hops points come into and see where their
distant end is. And a lot of them
start pointing back to similar ISPs. And that’s one of the
reasons that Mandy was able to determine how
they were able to do so and determine the exact building that a lot of these attacks
were coming in from. Let’s talk about
some of the analysis that we’re actually
able to pull out just from the registry
side, from the host, trying to still
answer the question as to what was this
individual after. So analyzing user activity, we’re able to see that
the vibranium user on the system
started searching for a specific search
term, adamantium, Doctor Myron McClaine, account, the word vibranium,
test plants, alloy. All the search items that
you usually type in here or the upper right hand corner of your Windows search
bar, everything you do on your Windows
system is traceable. Everything you do on your
Windows system is traceable. That should be your mantra. You almost should become
paranoid about it. If you type something
into that menu bar, if you put a directory path, if you type it all
in the search term, anything that’s on the system, Windows is constantly
remembering it and storing that data for you. And for those of you
out there saying, “well, I could
easily delete this. “I know how to use Regedit. “I know how to use
private cleaners.” Most of this data
is still sitting in your unallocated space or
slack space of your registry, still extractable,
still with timestamps of when this occurred, as well. There’s only one
tool I know out there at this point that
I’ve never seen used in an actual attack situation that does registry wiping. You could delete these values. But, again, they’re
recoverable pretty easily with forensics tools. So being able to see
what they search for tells us a little
bit more about them, security intelligence
that we need, what they were
targeting, so we can see which other systems
that these bad guys are likely to be on. So here’s an example of that. Running it through
RegRipper makes it a little bit easier
for you to be potentially able to
see the exact order that they typed these
search terms into the bar. They don’t know
where this data is, just like you don’t
know where this data is. So you end up,
just like they do, they’re gonna use
your own systems to help you identify this data. Part of the things we’re
starting to get into is this mindset of how
do these bad guys know which system they need
to go to on your network? The official answer
is they don’t. Part of what Phil and
others were talking about in here is to be able to
set up an infrastructure that could communicate
across multiple machines in the environment. The reason so much
traffic is going from all these different
machines, back and forth to one another, is
because the bad guys are actually having
to look for your data, and they’re actually using
your network infrastructure because you have
it set up anyways to be able to find data easily, in order to help
themselves find the data, but they’re doing it
right under your nose. So you potentially have
to pull this data out in order to be able to say
what were they looking for and still leverage
this in your own security intelligence
to be able to do predictive where could
they be showing up next, if they’re after this type of
information on our network? What about files they opened up? So let’s say they
found a couple files. What really were
they interested in? So part of the things
we’re able to see in your Windows registry is all the most recent opened
docs on the system. For example, you see
an agents classified top secret file
that was opened up via this RDP session. Notice what happens here
inside the host analysis, again, through your
RegRipper output. We’re able to see all the
files that were opened up. We see credit card
backstop accounts, undercover agent list
for United Kingdom. We see pictures
in here, and more. It doesn’t matter (coughs) what an attacker’s opening up. If it’s a non-executable file, it’s gonna be logged
in the registry. All this stuff is clear as day if you know the right
systems to look at. Now, you won’t be
able to do this against every system. You have to take your
pick of the litter. But Phil and the network team, the instant response team,
memory forensics team will help narrow which systems you should take
this hard look at in order to be able
to pick out if you’re, in answer to your executive, it looks like they’re after
credit card information, undercover agents
in our network, research associated
with vibranium, and potentially more. So anytime you open up a file,
I’ll be able to track you. Anytime you open up, do a
search term on the system, we’ll be able to track you. And also, we’re able
to get the exact time you’re doing most of
this activity, too. What about if you
execute a program? Well, we have that as well. Almost every program
is gonna be traceable through the user sys registry
key on the Windows system. The last time you
executed and total number of times you
executed that program. So when we started
looking at this, we start seeing, dropping
command prompts in here. We see the utilization
of Excel to be able to read that spreadsheet
that looked at earlier. So dropping this
into a timeline, we’re able to see
the command prompt, the time of execution
of each of the programs on each of the systems that
we’re currently examining. Some of the other
registry artifacts are very hacker related,
which are very useful for us to notice, is
that in your registry specifically if anyone ever uses any sys internals
tool out there, it actually writes
in the registry the utilization of that tool, because of that
accept EULA thing. A lot of bad guys forget
about that little one-off, and it ends up
becoming very easy for us to spot from a security
intelligence perspective, that why would a normal
user ever run psexec? They wouldn’t. So the likelihood of
psexec being embedded in the registry for the
execution for a single user is zero to none. But if you scan your environment just looking for
this one artifact, you end up getting
50 systems that have psexec run on them that are
not from system administrators. So you eliminate the
sys admin systems. You’re left with just sets
of one simple artifact, systems that are likely
utilized by our bad guys. Bad guys use psexec,
they use net.exe, they use atcommand, all
these basic commands that normal sys admins use. Again, they’re very
noticeable if you’re looking for additional compromised
systems out there on the network. It does not take a
significant amount of analysis data to potentially do this
type of heuristic look. But understanding
what the attackers traditionally do end
up being very important to us to be able to identify
additional compromised systems. Which folders were
opened by vibranium? Another key artifact that
happens in the registry. So we’re able to tell which
programs they executed, we’re able to tell
which files you opened, we can tell which
search terms you used, we can tell which
folders you were in, even if they’re network folders. Every time you open up a
folder for the first time, it’s gonna make an entry
in the registry shell bag. The shell bag keeps a
record of every folder that you enter for
the first time. So just by analyzing
this location here, just dropping it out
and putting it through, all that. Here are some examples here
of a system 32 DLL host where we found our initial
SVC host compromise and a bunch of other files
that they’re obviously, while they’re looking for are types of directories and tools related to what they’re after. Shortcut files, moving
from the registry. Every time you open up a file, a non-executable
file on a system, a shortcut file’s
gonna be created in your recent folders. How many? You have up to last 150
files that are opened up. We can see first
time, last time opened based off the date
created, date modified. And embedded in the
shortcut file itself, it doesn’t matter if
it’s network drive, a USB key, or others,
we’re gonna be able to tell that you opened that up. What did we see for vibranium? We’re able to see
every single one of these files
that you opened up, first time and last time
opened, based off the, to how do we know they
definitely stole it? Well, we potentially
have to coordinate this with Phil and say,
we see data transfers from one system to
another off this system containing potential data. We’d have to do a
combination look at this. This one goes back to the
instant response team. But they’re interested in this. Did they just look at it? Were they actually
stealing this data from our network? What about jump lists? For those of you who are
saying, “well, 150 files, “well, that’s not very many.” Well, part of the new Windows
7, Windows 8 jump lists, since XP’s now about to
become truly deprecated, jump lists are here to stay. What’s in a jump list? Well, it tracks every
single executable that was ever executed
on your system. In addition to that,
it has this history of every file that
was opened or modified by that executable. It’s going to be embedded
in the jump list. How many of them? As far as I know,
it’s unlimited. We’ve actually seen going to
two bytes, three byte values for the total number of
artifacts that it’s recorded. So first time you execute Word, let’s assume you’re
executing for two to three whole years. I’ve never seen a jump
list cleared unless it’s manually deleted. Privacy cleaners
potentially also delete these at this point, too, but again, it just
becomes a deleted file, which is, again, recoverable. So we have all the history
of every file you open up, every folder you open up,
every program executable you ever executed, every
search term you ever did. Basically, it doesn’t
matter what you used on your Windows system. I could tell what
you did last summer. Everything you did. Literally, for people
who start looking at what artifacts are
left that we don’t know what you did, Windows forensics and Mac forensics and
smartphone forensics, we’re able to tell everything. Everything is recorded. It almost is like, wow,
they truly are watching every single step that I do
on these Windows systems, scarily. So that’s a real reason
that Microsoft is doing this is to be able to create a
better operating system for you. I know it sounds
crazy, but it’s true. It’s trying to
self-configure itself based off of your likes, where
you routinely save files, where you like to
execute programs. It’s trying to remember
your preferences. And the only way to self-modify, to become more of a
pleasing operating system is to watch your own habits. Every operating system,
including your phone, do this. You don’t believe me? Just start noticing,
every time you start typing something in, how
much it autocompletes. The first thing
that’s up at the top is recent search terms
that you typed in there. And any of the search
bars that you have on your phone, on
your operating system, or unit user interface that
you’re currently invoking. It becomes pretty
scary when you realize that’s data that’s stored
somewhere on my system. So here’s the, be able
to analyze the jump list, some of the data we’re
able to pull from it. All the files that
are opened up, and this is just using
extraction information. We’re able to see
the order of entry, when they were opened
up, and exactly what was opened
up per executable. We also have custom
jump lists out there, which gives us something a
little bit more interesting. For the custom jump list
for specific executables, we’re gonna be able
to see like Firefox. Inside the Firefox jump
list, we’re able to see specific command arguments. We’re also able to see
the frequent history list that’s also in there. Just another place for your
browser forensic data to sit. What happens when we
looked at our vibranium custom destinations? Check out what we have here, where we see these IP
addresses that we saw before. Again, this is part
of our command channel that was in use. And we also see some
interesting terms, such as Wikipedia
egress filtering. We see winclient.reg,
which is related to some of our malware. And we also see all the
IP addresses involved. In our case, including
the spinlock one that we have up here. Again, why this is in
there, because our browser was invoked for some of
this data pulling down, because it was utilized
via Poison Ivy. So again, a lot of
this information, the attackers simply
forget that it’s in there. They don’t clear it. They’re not doing
proper anti-forensics. And they probably
won’t for some time. When people talk
about anti-forensics, it’s too much data to
have to worry about. Your attackers get
sloppy, and they get lazy. And as a result,
a lot of this data is still gonna be
left on the system. When we start going into
the browser forensics, again, all your standard
stuff we’re able to see, but we also see download files. And this is, again,
for Internet Explorer. Anytime you open up a
file or do file downloads via the browser, we’re
able to see the clients being downloaded directly to
the system via the browser. And again, we’re able
to pull that out. So in the end, if we
actually put all this data, bunch it together, put it
up in an actual timeline, this is what you’re able to do. Now, automated timeline
generation is possible using tools that
we teach in 508. But initially, in
408, we teach you how to manually do
this because I want you to memorize what
the artifacts are. As we talked about
before, between what Chad is able to accomplish on the instant response
side, which is this type of capability but
he needs to scale it across hundreds of
systems simultaneously. Phil needs to do the same thing, looking at the large-scale,
network-based data. From memory analysis, we need
to do touch and go on this. The time you start going
into doing manual extraction of artifact data
is when you need to really start pulling out what are they after,
why do we really care and presenting it back
to your executives. Here’s why they’re
on our network. They’re here to steal
our data related to the vibranium alloy. So we should potentially
look at all instances of that on our network
and potentially look at that from a
counterintelligence
perspective, too, to say, maybe we should
set up honey nets. Maybe we should get graph. What they’re after, we
can start potentially predicting where the
bad guys are gonna come the next time. The thing about the advanced
persistence threats, the reason it’s called
persistence is cause they simply just don’t go
away cause you catch them. They’ll try to
come back the next. Some people say wave 65. They’ve come in 65 times. We responded to them 65 times. And we still have to
kick their little booties out of the network. But they still were
successful because, unless we end up deciding
to tell all of our end users that we decided to give
up and we’re eliminating the internet from
our infrastructure, users are always gonna
be able to be duped into clicking on stuff that
they shouldn’t be clicking on. Ask Phil. His brother works in a very
interesting firm called PhishMe. And is it still pictures
of funny kitty cats? Is it still number one? Or they have something
replaced that now? (laughs) Okay. So pictures of funny kitty cats pretty basically tell
you how to do that. But you could see in
here that it’s no longer becoming the one individual, the one guy in your
instant response team is able to go do all this stuff. Can anyone in here
potentially accomplish everything I talked
about and my teammates talked about in here? No, cause it takes
a team to do this. And your executives expect
that type of teamwork in order to be
able to rely on you in order to feed the
proper information to your security
operations center. So your instant
response team no longer becomes just reactive. On a daily basis, your
instant response team become the hunters,
that their entire job is to continually identify
where your bad guys are on the network. It’s such a crucial
piece of doing forensics properly at this point,
of doing instant response properly at this point. And it shouldn’t be, we
shouldn’t joke around about it because of the fact,
in all seriousness, that for those of
you who are in here and thinking we’re moving
from an ad-hoc team in which, that when
something happens, we’re all come together
and saying, “now what?” That we have a dedicated team. You’re the malware analysis. You’re network engineer. You’re the instant responder. You’re the memory analyst. You start to become a
little bit more niche as you’re moving your focus. So when you’re going
to our classes at SANS and your going through the
different aspects of this, think about that,
saying, “am I gonna be “the jack of all
trades individual?” We need those people, too. But are you gonna become
more focused, as well? Are you gonna say,
“I’m gonna become “the best network person
there is on my team”? Because you also need to make
that choice at some point. And just like, for those of you who used to play D and
D, sooner or later, you have to choose your cast. Yeah? No? Is it too soon? Is that too close to home? (laughs) Warcraft, I
don’t know, I don’t know. All right, but I want Phil, Alissa, Lenny,
and Chad to stand up. These guys, big round of
applause for our team. (applause) I really thank everyone
for being here tonight. It’s a really fun
presentation to go through. Every time we give it,
it’s always interesting to see what new information
our members are gonna do. Hope to see you tomorrow
morning, bright and early, and thank god that
everyone got here safely after today’s travel issues. Without further ado,
please, when you’re heading out the door, please
fill out your evals. And whatever you do,
please do not say anything about being obnoxious and
refer to Alissa on your forms. (laughs) Is she here? Oh, she’s not even
here to realize, okay. Shoot, okay. Yeah, okay, if you could, put Alissa should be more obnoxious. (laughs) I kid, I’m
kidding, I’m kidding. All right, thanks everyone. I’ll see everyone tomorrow
morning for my class and all the other
classes here at SANS. Please come up and say hi. And I hope if you
haven’t decided to sign up for Net Wars
yet that you consider signing up for Net
Wars, DFIR Net Wars, starting on Saturday
nights here at SANS. If you don’t know what that is, we’ll give you some more
information about that tomorrow. But sign up for Net Wars. Basically it’s gamified,
doing forensics challenges on both Saturday
and Sunday nights. Thanks, everyone, I’ll
see you tomorrow morning.

5 Replies to “SANS DFIR Webcast – APT Attacks Exposed: Network, Host, Memory, and Malware Analysis

  1. malware and all types of viruses ruined one of my accounts on my computer and its starting to take over this account no

Leave a Reply

Your email address will not be published. Required fields are marked *