>> What are the tools
>> we just copied in our virtual machine?
>> The first is SysInternals from Microsoft,
made by Mark Russinovich.
They are very useful.
I think, they're fantastic, they're amazing.
The second is the MAP Pack by Dave Simmer.
We discussed some of these tools last time,
and we installed them,
and I showed you how to use all of them.
I suggest 010, the hex editor,
some PE viewer like CFF Explorer,
PE Explorer, PE View, PE Studio.
I just saw another one today that I didn't know
of, it's like beardiff.
IDA Pro is a free disassembler, at least,
a 5.0 version or five point something version.
The 6.0 version is also free,
but will not let you save your analysis.
But if you upgrade to a pay for version,
it will let you save it, and it's about $700.
There are free versions out there,
but they're not nearly as good.
As I said last time,
Cygwin with GCC, Binutils, XXT,
and has its own version of Python built-in,
this is something I suggest as a personal preference
of mine, and Notepad++.
Tools for our virtual machine
for dynamic malware analysis,
I would suggest these;
Capture BAT is usually my first since my default.
It just captures major system events.
Regshot captures changes to the registry and it
can also be configured to watch
for any file system changes.
PEiD is a static file analysis,
and parser, and signature scanner.
It will look for common packers,
see if the malware is encrypted with
something that we can easily find.
LordPE helps you dump something out of memory.
If you start executing something,
a piece of malware and it's
just running as a regular program,
you can just dump it straight to disk,
and then you can use Import Reconstructor to
rebuild some of the structures that
lost when you dumped it to disk.
This is useful for malware that's packed.
If it unfolds or decrypts in memory,
you just want that end result,
you don't want to have to
unpack it manually. Although, you can.
It's a bit harder. OllyDbg is
a very common debugger for reverse engineers.
It's just very user-friendly comparatively.
It has a lot of plugins,
but we'll cover that later in
more advanced dynamic analysis
because it allows you to step through
the instructions and execute them one-by-one.
Just a few notes about
what we did before just like I said,
VirtualBox, or VBox, Oracle.
VirtualBox is open-source,
it's free, it's very useful.
I find it that it runs very fast,
but it sometimes corrupts a little easier.
There is some differences.
Like I said, one of the reasons why I chose Windows XP,
because the permissions are a lot easier to deal with.
A lot of malware targets Windows XP,
because it's still fairly common not the wild.
But Windows Vista and up,
7, 8, 10,
they have different permission architectures,
and different security architectures,
and usually, much better security.
But a lot of malware will mess up,
or fail, or just assume the wrong things.
That's why I like working with
Windows XP, but generally,
I have a Windows 7 computer
on-hand for more modern threats.
Rootkits and 64-bit programs really need WinDbg.
It is the debugger supplied by Windows.
It is very powerful,
very difficult to use.
It's [LAUGHTER] not user-friendly at all.
If you get good at it, you will absolutely know what
was going on within your operating system,
within any program you want?
That includes the kernel,
the core operating system.
You can really figure out what's going on in there.
Even with Vista 7, 8, and 10,
even when they have all the security precautions
like the UAC prompt,
the user account control, ALSR,
the address layout space randomization,
DEP, data execution prevention, and so on.
As I said before, I took a snapshot of
every major update every month
>> after every patch Tuesday.
>> I really never had to use that to
verify that vulnerability was
being exploited by malware,
but you might want to.
I want to talk about the
>> different levels of automation.
>> We just set up a local VM,
we just put some tools in there,
and we can throw some malware in there,
and just start executing it, and see what comes out,
and we will do that in the next video,
just coming right up.
But I do want you to know that VMware can be scripted.
There is an API,
an application programming interface
>> for VMware and VBox.
>> That's awesome. You can write
a program to download some malware automatically,
and then pop it in the virtual machine,
automatically set up your tools,
and execute the malware.
Then you can write
some more programs plot report
and then you can just go on and on.
These solutions already do exist.
There are people who've automated things
and scripted ESXi,
which is the server hypervisor version of VMware.
Zen is another VM hosting
hypervisor and HyperV is
Microsoft's version. Zen is open-source.
There's Cuckoo Sandbox,
which is built on
VirtualBox and it does automated malware analysis.
You can just upload malware to it,
and it has a little web interface,
and it'll produce this nice report
afterwards about what the program did.
There's whole malware farms out there and then there's
websites that do this on
a massive scale like VirusTotal,
or Anubis, or any of the others.
They go through tens of thousands
of malware samples per minute.
There's even commercial products like
Joe Sandbox and Threat Grid that do this.
There's even appliances like FireEye,
they sell you a computer and sits on your network.
Any program that gets downloaded over your network,
FireEye will just grab out of the network and
throw in it's proprietary virtual machines,
execute it, and just immediately
tell you if there's something dangerous about it.
You might be thinking, ''Well,
why am I even dealing with any of this
since there's already tools
>> out there to do it for me.''
>> When we go back to what I said before,
which was, you really need a human
to analyze this stuff.
Antivirus companies have been trying for
years to develop algorithms,
to develop software, to
determine if something is malicious,
and they have come up against a wall,
they really cannot do it.
Part of being a malware analyst is being able to just
look at something and get a good feeling for it.
You get these uncanny feelings
because you know what
a normal program is supposed to look like,
you know what malware is supposed to look like?
Every time you automate something,
>> you assume something.
>> Most sandboxes out there,
like Joe Sandbox or Threat Grid,
they'll only run the malware for five minutes.
A lot of malware have built-in timers to
just wait longer than
five minutes before it starts executing.
It's a very simple defense mechanism.
Or a lot of malware out there
will look to see if it's on a real machine
or if it's running very slow because a lot of
these systems like VirusTotal or Threat Grid,
they have thousands of
virtual machines running on the same hardware,
so of course, they're going to run a bit slower.
The malware thinks like,
''I'm going to run on Windows 7,
or I'm going to run on XP.''
It's like, I should be on
some relatively modern hardware.
If I'm not executing fast enough,
then I'm just going to die
because I'm probably in a virtual machine,
someone's trying to analyze me.
Cuckoo, Sandbox,
and others are great for
collecting indicators of compromise,
and just turning out reports, and signatures,
but it really doesn't help when it comes down to it.
When you get some incident in your organization,
and your boss goes over,
and he's just like, "What is this?"
You can't pop it into
Cuckoo and it give you a good answer.
You can't use FireEye and it give you a good answer.
Those solutions are great generally,
but if something actually
happens to you and you need to know what it is,
you can't really rely on those solutions.
It says, generic threat or generic Trojan.
It's like, now what?
It's like, how much of a risk is it?
How much of an impact we'll have on our organization?
How much resources do we put in this?
Those appliances, those solutions don't tell you that.
Since they've automated everything,
they make really common mistakes.
I have seen malware out there that checks to
see if it's filename is
sample or if it's filename is malware?
If it is, it just dies,
it doesn't execute, or does something crazy.
It just creates tons of random events and
so the logs just turn out and say,
''This thing created 1,001 files,
it beaconed out to Google,
it beaconed out bing.com,
maybe those are now malicious domains,
and blah-blah, so it's really
easy to just mess things up.
>> One of those sandboxes made the mistake of saying,
I'm just going to rename all the malware samples,
malware.exe and then execute it or
sample.exe and then drop it into the VM and execute it.
It's making an assumption and
the malware is taking advantage of that assumption
and that's really why humans still
needed to do all this
and I don't see that changing anytime soon.
A human has the intelligence to
just look at these things and know
them and computers and algorithms just simply do not.
Notes for the paranoid.
There have been vulnerabilities in VMware.
I've never seen malware exploit any of them in
the wild but there have
been proof of concepts where
some malicious code could theoretically get out.
There have been proof of concepts where malware will
act differently if VMware Tools is
installed in its environment.
I've heard about it a few times,
I've never really seen it
and I think it's becoming less common
because more and more people
>> are working on workstations.
>> I think it's more common that malware chooses
not to be all crazy units in a virtual machine
but instead to have other kind of anti analysis
and other kind of defenses
built-in that we'll go over in the future.
But some of them do
so that's why I recommend changing your MAC address.
That's why I recommend only
running one or two virtual machines on
your computer at a time and maybe
letting the malware out onto the Internet to not spoof
every IP address that you see because I have seen
some malware that will do an IP address check.
It'll go and check for
google.com and see what IP addresses come back.
If it's not any of
the Google IP addresses that it knows about,
it just will not work,
it assumes that it can't get to
the Internet and if it can't get to the Internet,
then it's useless as a bot so it doesn't need
to run and it's probably in a virtual machine anywhere.
If you're worried about your privacy being
compromised by running malware,
like if you got some malware from a sensitive source,
you can run it through a VPN.
May or may not be a good idea
depending on your situation.
I've seen malware where it executes in
the target environment only and
it does that by checking it's IP address.
It goes out to some servers and
says what is my IP address and it's like,
okay, I'm in the range of
the company I'm attacking, okay good.
But if you say, oh,
I'm going to upload it to VirusTotal
or I'm going to upload it to Joe sandbox or
whatever and it does
a check to see what IP address its coming from.
It says, oh, I'm coming from
an IP address that's
known to be from an antivirus or I know
I'm coming from an IP address known to becoming
from something other than
my target company, it won't work right.
It will alert the attacker that something is going on,
that someone is analyzing their malware.
I suggest having in your organization
your own dedicated environment
>> that's routed straight to
>> the Internet or is proxied or
something so that you can simulate it
kind of being in a real environment and
use generic names for your user,
for your computer, but not so
generic as to like the username be
user or your malware always
being a file called malware.exe.
Because I've seen malware that checks to see
if the username is user or
analysis machine or malware machine,
and it won't work if it sees that.
Just a recap of what we did,
we set up our malware analysis lab in here.
In the next video, we're just going to start running
some malware and seeing what we can do with it.
You can do it all for free and
there are multiple levels of automation,
you can make this, I suggest for now,
let's not do any automation.
Let's just run some tools,
let's see what we can get from
our malware samples and let's just have fun with it.
That's really the best way to go but we are
going to have to configure them and slightly
tune them and I'll show you that in the next video.
Some good resources if you like this kind of stuff,
there is a book out there like
the Cuckoo Malware Analysis book and
there's a malware analysts cookbook and DVD,
I highly suggest that.
It's written by a very smart guy or guys
and they've contributed a lot of
code to malware analysts.
A lot of it's really helpful,
a lot of it is in Python if you like that
and when you start looking at the stuff,
you're just like, wow, that's hopefully.
This dumps all the function calls it's going to make.
Wow, this program will generate your signatures or
this program will automatically
hash it and check bars total,
>> this program will do this.
>> It's really easy to get carried away with
automating whatever setup you have and I
would suggest doing your analysis
and then if you have a question about something,
check the cookbook, see if they already have
an answer for that and
occasionally read through what
you can do with it but it's
important not to let your tools drive your analysis.
Your analysis should drive your tools.
If you think there's
a resource in your malware that you need to pull out,
then look up a recipe for pulling out
the resource or do it however, you can.
Don't just make a giant script
to do 99 percent of what could be done.
I remember when I first started in this industry,
I read through a bunch
of these books and I was just like, oh,
I can do this and this and this and I wrote
five or six different scripts
to dump the headers and then dump
the sections and show me
the entropy of the sections to show me if there's
any major differences between virtual size and size
on disk and any interesting sections and dump
the process once it's in memory and just see
if it's injected any other processes,
all this other stuff.
I remember I got into this reversing group at
my company and really smart guys,
they're watching me do this,
they got a sample and I'm just like,
I have all these scripts, blah, blah.
I went and I run all my scripts I'm just like, okay.
They looked at me and they're just like,
>> "Okay now what?
>> I was just like, "I don't know.''
They're just like, ''You don't know
because the question you were asked was,
is this plug x,
is this Zeus, is this whatever the question was,
does this beacon out to this IP address?''
That was the question and my tools didn't
answer that and to answer that question,
all I had to do was execute it in
a VM and see if it was doing anything or
execute it on a real machine and see if it was doing
anything but just in case it was VMware.
That was the question I needed to answer.
My scripts were driving my idea
of what I should do and that's
not how we should do things.
We should be thinking,
what is the information we need?
Usually, the thing that your boss wants to know is,
what is the risk?
What is the impact? Who sent this?
Can we expect them again?
How can we better defend ourselves?
These questions we can answer with our analysis.
Thank you for watching the video,
and I'll see you next time.