>> We just looked at some of
these basic tools that you can use.
I would say go ahead and download
some more malware and play with
it and just see what these tools do or
even just normal software because,
like I said, malware analysis
is still software analysis.
You should, like I said,
use multiple tools to confirm your findings
because this is all software and all software has bugs,
even malware which we'll talk about in just a second.
I know you may think we're focusing a lot on Windows,
but most malware is for Windows.
But a lot of the stuff can be applied
to Linux malware as well because most malware will
do the same type of things where
it's picking out to the network
or hooking certain functions
which we'll talk about later,
use simple encryption method on both Linux and Windows.
It is key to know that we can get into this a lot more.
Some of those tools are the tools and just internals,
like ProcMon is very powerful,
but you have to spend a lot more time looking
through those logs and we'll cover that later.
If you wanted to step through
exactly what the program is doing,
and slow it down,
and step through it and control every little bit,
debugger is perfect for that.
There's one in your VM that I
told you to to get called OllyDbg,
which we will cover later.
Now, some notes for the paranoid.
Some malware will not run
because certain security products are installed.
Some malware will not run just
because it thinks it's in a sandbox,
like I saw some malware where it
wouldn't run if the user name was user,
they wouldn't run if the username was
analysis machine, stuff like that.
But beyond malware purposely
trying to detect that type of stuff,
there are other reasons why it might not run,
such as it's in the wrong environment.
Some malware is targeted like that.
If the wrong version of Word is installed,
it will not run because it cannot exploit it.
Or if it's on the wrong version of Windows,
it will not run because it doesn't have access to
certain features or whatever the case may be.
It doesn't run because certain software is or is not
there or even language packs are not installed.
Citadel, a big banking trojan,
huge banking trojan that is tapered off of last year or
so I will not run if it
detects it is running in a CIS country.
Basically any country that has
a Russian or Ukrainian keyboard attached to it.
The malware authors do not want to
upset the law enforcement
in those countries for obvious reasons.
I saw that there's some false Pearl Harbor malware
where it would only execute and do damage on
the anniversary of Pearl Harbor if
a Japanese language detected or Japanese keyboard.
Or a lot of times,
actually, I've seen where
malware has multiple components.
It'll hide one part of itself in one service or hide
another part of itself in the registry and hide
another part of itself in a file they infected.
If any one of the components aren't there,
it won't work properly or if it doesn't have
a network connection directly to
the Internet, it won't work.
Some malware will ping
Google.com or try to act as a certain webpage,
and if it can't get to it, it's just not going to work.
It says, well, if I can't get to the Internet,
then I'm useless anyway,
and just won't work.
Some other not so purposeful things
include bugs in the malware.
I've seen lots of malware with so many bugs.
It reads the date wrong or it
tries to read in
a value from something that doesn't exist,
and it just crashes it though the divide-by-zero.
Malware is software like any other and it has bugs.
Even the malware authors wrote
the program and it worked fine for Windows XP,
but then it didn't work on 7 or there's
one where I saw that it did work on Windows 95,
it didn't on Windows 98,
but then it did again on
Windows 2000, which was pretty funny.
Sometimes the dependencies aren't met.
When I first installed Windows XP here,
there is no.NET runtime libraries.
This is interesting because some malware up
there is written in.NET and needs those libraries.
There have been times where I've
had to go and download the.NET libraries
because I couldn't get the malware to execute.
Some malware I've seen
in point-of-sale system compromises,
there are kill dates in the malware,
the actors have a certain campaign time frame so that,
if it's beyond this week or if it's beyond this month,
then it doesn't do anything.
It kills itself or goes crazy on and cause a lot
of events to be logged,
has nothing to do with anything.
Sometimes there's a specific target in mind.
I remember one time I spent a whole week
reversing the sample and
it did a whole bunch of nothing,
what we call junk code.
It was handed to me because no one could
figure out what it was doing.
They just executed it and just didn't do anything.
When I was looking at and stepping through it,
I realized a part it was doing that
was it was trying to get the processor ID or it
was trying to get the GUID from the system and
was using that as the key to decrypt the payload.
That meant that my computer did not have the
proper key. I didn't know where the sample came from,
I didn't know who it was targeting,
and I didn't know that Zeus did this,
the common way to update.
It had already infected the system.
If sent back home to
the command control server, the GUID, and then
the command control server will send an update,
an executable that would only run on that system.
When I found that out, I was like,
well, thanks, Zeus.
A major malware family if she hadn't heard of it.
Then some malware knows
that it will be analyzed at some point.
>> We've got some malware authors
as an anti-dynamic analysis.
Defense mechanism will employ
certain functions that take a lot of time,
such as the sleep function in Windows,
it'll specify that the malware should sleep for
a day or two.
It will sleep for an hour or a day for a week,
and then it will become active and then do
its damage or collect information or do whatever.
So common sandbox counter technique,
an anti-analysis technique, is to
hook the sleep function and just short-circuit it,
we can know of so that it doesn't do anything.
Let's say, sleep for 10 minutes and then do
this then it just short-circuits and says,
sleep for zero seconds,
and then it goes about its business.
That is also a sandbox detection technique.
If they try to sleep for a certain amount of time,
and it returns immediately,
then the malware knows it's in the sandbox.
But they play this game back and forth constantly.
But then again, a lot
of malware will still run virtual machines.
Because a lot of virtual machines
nowadays are actually
significant pieces of infrastructure,
like, there's a lot of web servers or
virtual machines that malware authors
would love to infect.
If there are malware sample will just
not work on virtual machines,
that's a disadvantage now.
there's lots of IT companies
who only have virtual machines for their users.
If you'd make your sample not work in a virtual machine,
then you may not
become very effective in infecting people.
Just another good OPSEC,
operational security tip,
is to use this command in Windows, icacls,
and pick a directory like C:\malware/deny,
and then use a string so that no one can
accidentally execute malware on that Windows machine,
like a host machine.
I do this Work Folder on my machine just in
case I double-click on this click and infect myself.
I definitely don't want to do that,
because when I run and rob
the network cable and pull it
out before the malware can be taken out.
Because sometimes I don't want malware authors to know
that I have their sample and that I'm analyzing it.
I remember one time I was looking at
malware sample and I was running it over
and over and over again in a VM.
I noticed that every time I would execute it,
it would go and download a command and control list,
list of all the machines that were
infected most recently,
and it will give me their IP address so the malware
has been contacting those machines like, updated
instructions was kind of a peer-to-peer network.
I saw my machine's name
picks it up like the last 10 or 15 entries.
My VM's like, Zack Johnson or something like that.
It was like, Zack Johnson,
Zack Johnson over and over and over again.
It was pretty obvious to anyone who's looking at it,
that someone was executing that malware over and
over and over again on
that computer and it was picking out.
The malware authors, the botnet operators,
could easily see that I was analyzing their malware.
They probably did know that.
On a Linux hosts,
you can take away the ability for anyone to actually
execute something by doing those chmod 600,
it's a read, write, execute.
These three groups were
your user group and everyone else and read,
write, execute are the bits in there.
If you want to read more on that, you
just typing in man chmod.
Another note for the paranoid is that
some malware will only become
active if it can
really detect that there was a user there.
We'll watch for user interaction.
Such as mouse movement, window movement,
other programs executing,
just someone using the computer,
or else it will not execute.
Sometimes you need to move around the mouse or open up
Explorer or surf the Internet or something like that.
Just a recap of what we covered here today.
We covered what the basics are, dynamic analysis,
at least the host-based part,
we covered the tools that we put in our VM last time.
How to use them, what are the best practices for them,
and how you might set them up, figure them,
and automate them if you wanted to.
We talked about a lot of reasons why
the analysis might fail.
But it does work a lot of the time,
most of the time, actually.
If you want to do further reading on this,
Practical Malware Analysis has a great chapter in
basic dynamic analysis with
some tools that I'm not too fond of,
but they're all pretty good.
Then have a advanced dynamic analysis section
for debugging and doing a lot of that stuff.
If you're interested in that, I would
definitely say you should get
your own samples like
from the Malware Zoo with the malware database.
Because you can see that they've been classified,
they've been marked as to what they are,
and they've been known for a while and you can go
around to see what the malware does.
You can see what registry keys of other.
You can see exactly what
other people like myself have done,
written up reports about how dangerous the malware is,
exactly what it does,
exactly how it spread,
and stuff like that.
You can make your own indicators of compromise.
Then you can go and look at
other people's indicators of compromise.
I would suggest not only doing this for malware
but doing this for software in general.
Again, my name is Sean Pierce.
Thank you for watching Cybrary and goodnight.