>> Hey everyone, welcome back to the course.
In the last video, we talked about
the different components of
malware with similar definitions.
I bet you understand all of those terms for your exam.
In this video, we're going to cover static versus
dynamic analysis for malware,
but I want to stress that this is
going to be a high-level overview.
We are not going to deep dive into
malware analysis in this particular module.
Basic Static Malware Analysis.
As the name implies, we're
not executing the actual code,
we're just taking a look at it.
First step is generally always
scanning it with some type of tool we have,
like your Malwarebytes, Sophos,
TrendMicro, et cetera.
Whatever you decide to use, or
whatever your company's using,
we just scan it with that first.
Then we can also take a hash
for finger printing purposes.
For example, if we want to upload that hash
to something like Virus Total to see
if it's been found before,
and so we can get information about
that particular malware, and even see if it is malware.
Or, if we don't find it on a site like that,
then we have a hash that we can then report to them,
and say, hey, found this new malware or whatever.
Searching strings so we can
search any type of URL connections.
Does it copy files to a specific location?
Then also, if the malware is Pax over Packer was used,
then generally we're going to see few strings
showing, and that could potentially
indicate that the file is malicious.
Here's an example of just taking a look at a string.
Again, we're not diving into
actual malware analysis, or deep dive, or anything.
I just want to show you what we
might look for as an investigator.
You'll see things like VP3, VW3 et cetera.
Those look like just random characters.
Generally you can ignore those.
The things you want to focus on,
we see an IP address right there.
That's definitely one.
We also see GetLayout GDI32.DLL set layout.
We also see an error message back.
Those are things we would want to focus on.
The Getlayout here, and also SetLayout.
These are windows functions that are used
by Windows graphics library.
These are meaningful things to look
at because these are actual legitimate things in use,
not just some jumpy characters like
the T$@ symbol or whatever.
Also, GDI32.DLL.
That's [inaudible] because it's a name of
a common Windows DLL that's used by graphics programs.
This contains executable code
that the malware could be using in some capacity.
Finally, the error message.
Oftentimes when you're doing static analysis,
oftentimes the error messages are very
valuable, because they can show you different things.
In this example, this can
show us that the malware probably does
send messages because we see
a mail system error and a send mail error.
Then, also,
it may indicate to us that we want to go ahead,
and check email logs for suspicious traffic.
In this example that we
can use as a forensic investigator.
Again, I want to stress we are not deep
because you can actually have a whole course on
malware analysis as you probably see out
there. We're not taking a deep dive.
I just want to show you an example of
static analysis as a very basic level.
Portable executable format PE
is something that you just want to know for your exam.
Just understand that the PE header
can contain the code information,
the application type,
library functions that will be used,
requirements of the malware.
Different files in there you
>> might see like the text file
>> contains instructions at the CPU executes.
That's the executable code
>> information in the text file.
>> The rdata contains import, and export information.data,
as the name implies, but it contains global data,
not local data, but the global data.
Just keep that in mind for your exam.
Then rsrc contains a resources used,
so things like your icons, or images, or
even menus that the malware is calling.
Linking libraries, you'll just
want to be familiar with this.
Specifically, you'll want to be familiar
with a tool called Dependency Walker.
Runtime linking only when
the function is needed, static linking,
all the library code is
copied into the executable, and more commonly,
the dynamic linking is probably
the most common one that you see out there.
That's only one that the program is loaded
does it pull the information.
The Dependency Walker tool that I mentioned,
you'll want to know for the exam that one lists
out the dynamically linked function.
Just know for the exam that Dependency Walker
is used for static malware analysis.
We can use it for static malware analysis.
Just keep that aspect in mind.
I should correct myself there.
Basic static malware analysis continued.
We can look here
in CurrentVersion\Run, and that'll show us basically
controls which programs are run at startup, and
then we can also see
registry strings commonly used by malware as well.
This one here, you may commonly see in the malware,
especially if you decide to unpack it, or if
you can unpack it or honestly,
if you can just see the code of
it If it's not using a packer,
It's probably the easiest way.
Just a quick post assessment on question of static.
Dynamic linking is generally
the most common form of linking seen in malwares.
Is that true, or false?
That one's true. Again,
that's the most common one that we see.
Basic dynamic malware analysis.
The main difference here is we're
actually executing the malware.
We're trying to see what's it doing when it runs.
We want to do that inside of
a virtual machine, or a sandbox, so to speak.
We don't want to do that on
your regular computer because you
don't know exactly what that malware is going to do.
Even if you look at it from a static standpoint,
you may not fully understand
what all the code is going to be
doing, so that's why you don't
want to run it on your own machine.
Keep it in mind though that when we do
basic dynamic malware analysis,
we may not see,
all the execution of the Malware,
because sometimes it may require user interaction so
we may not be able to see
>> what it's actually going to do.
>> Now, if we deep dive into
advanced dynamic malware analysis,
we're actually cracking,
open the malware, and looking at
the code of it, and going through, and
understanding how does this particular line of
code function, then sure.
We might be able to figure out
exactly how it's functioning.
But in this case,
for a very basic dynamic malware analysis,
you may not understand fully
what the malware is going to do.
That's why again, we want to make sure we
run it inside of a sandbox.
Things like the process monitor can be used for PDF.
Dependency Walker, as I mentioned, again,
that can be used for static or dynamic
to look at the linking of registry shots.
We basically copy the registry
and then execute the malware, and compare
the different registries to see
if there was a change to the registry by the malware.
Netcat so we can look at what's open,
open sessions, that stuff.
Then Wireshark, of course we know that's for
packet capturing so we could
potentially look at the network traffic
after we're executing a malware.
Just a quick assessment question here.
I mentioned it a few times,
but you do not need to use
a sandbox environment for
>> basic dynamic malware analysis.
>> Is that true or false?
We know that's false. I mentioned a few times
that if you're going to do dynamic analysis,
you definitely want to do it inside of a sandbox.
I should recommend static analysis,
any type of malware analysis for static, or dynamic,
do those inside of a sandbox environment.
In this video, we just wrapped up
our discussion on malware.
We talked about static versus dynamic malware analysis.
Again, we just touched it on very high level.
In the next module we're going to go over email crime.
We'll talk about things like the canned spam act
and analyzing a different email files.
In the next module.