Malware Defenses Part 1

Video Activity

Welcome to the Malware Defenses module. This module will provide you a deeper insight into the various malware defenses. Malware defenses has several categories such as anti-debugging, anti-virtual machine, anti-disassembly, anti-analysis. Malware goals are to stop automated analysis and slow down the Malware Analysts. We'll also explain using a ba...

Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
or

Already have an account? Sign In »

Time
9 hours 10 minutes
Difficulty
Advanced
CEU/CPE
9
Video Description

Welcome to the Malware Defenses module. This module will provide you a deeper insight into the various malware defenses. Malware defenses has several categories such as anti-debugging, anti-virtual machine, anti-disassembly, anti-analysis. Malware goals are to stop automated analysis and slow down the Malware Analysts. We'll also explain using a basic anti-debugging code example.

Video Transcription
00:03
>> Hi, my name is Sean Pierce.
00:03
I'm a subject matter expert for
00:03
introduction to malware analysis.
00:03
Today we're going to be talking about malware defenses.
00:03
Now when I say malware defenses,
00:03
I'm usually referring to anti-debugging,
00:03
anti-virtual machine or anti-disassembly code.
00:03
But this can also mean anti-analysis code.
00:03
Generally, it's made to
00:03
stop us from analyzing the sample,
00:03
so some samples will look for
00:03
tools and disable them
00:03
or just stop running when they see them,
00:03
or they will do something
00:03
completely different than their original objective is.
00:03
I know one sample, one large botnet,
00:03
when it detects that it is being instrumented,
00:03
or is in a virtual machine or a sandbox,
00:03
it will open up some high-level port,
00:03
or high number port,
00:03
and it will begin listening on that port for
00:03
connections and it will act on those connections.
00:03
It looks like a very simple backdoor,
00:03
but in actuality,
00:03
it is a malicious botnet
00:03
that would go out to the command and control
00:03
server and pull down more instructions if
00:03
it wasn't detecting that it is in a virtual machine.
00:03
Now, defense code,
00:03
I would also say sometimes, often so.
00:03
There were two big samples back in
00:03
the day, Zeus and SpyEye.
00:03
They were going at each other
00:03
and they would take each other out if they
00:03
found that the other family
00:03
was installed on the computer.
00:03
There's a malware family out there called ZeroAccess,
00:03
and it is pretty vicious.
00:03
When antivirus or any
00:03
>> program really tries to access it,
00:03
>> it will go and corrupt
00:03
the file that is trying to
00:03
access it on disk and will kill the process.
00:03
There are defense examples and there's often.
00:03
I generally all group them the same.
00:03
The malware authors is just trying to make it more
00:03
difficult for automated analysis
00:03
in sandboxes or slowing down malware analysts.
00:03
I break these down to three major categories,
00:03
or four major categories.
00:03
The first is anti-debugging.
00:03
In the past, we have pulled up
00:03
all the debug and we've step through some things,
00:03
but we haven't used it a whole lot.
00:03
But that is a big tool used by malware analysts.
00:03
Instead of reverse engineering
00:03
and figuring out every little thing,
00:03
we can just say, "Oh, that looks like
00:03
an interesting spot in memory."
00:03
We place a breakpoint there
00:03
and execute the malware up to that point and then
00:03
look to see what's in that buffer
00:03
or whatever else we want.
00:03
If we want to see what
00:03
that C2 IP address or domain name is,
00:03
we can just place a breakpoint right
00:03
before it's about to make a network connection to it,
00:03
and we can see wherever it grabbed it from memory,
00:03
however it decrypted it, we don't really care.
00:03
We just run to that point and then say,
00:03
"What is it?" Well, we can't really hide it.
00:03
A lot of our build in
00:03
anti-debugging code to stop a debugger from attaching
00:03
or stop a debugger from finding
00:03
out what's going on in that process.
00:03
There's a lot of tricks to that.
00:03
We'll go over some of the major obvious ones.
00:03
The second category is anti virtual machine.
00:03
Now, most malware is executed
00:03
in virtual machines or detonated in virtual machines.
00:03
Some platforms do this automatically like VirusTotal,
00:03
Cuckoo Sandbox, sandbox,
00:03
Joe Sandbox, Threat Grid.
00:03
They all try to hide
00:03
the fact that the malware is in a virtual machine,
00:03
but it's a back and forth battle.
00:03
Sometimes there's really clever techniques.
00:03
Sometimes there's not so clever techniques.
00:03
Like more recently, a lot of pen testers are
00:03
just testing to see how many cores are on the computer.
00:03
If it's more than two cores and it's like
00:03
a modern computer and then they continue execution.
00:03
If it's less, then they figure they're in
00:03
a under-powered VM because these people
00:03
like to build huge clusters under power of
00:03
the VMs to detonate malware
00:03
in there and see what happens.
00:03
They don't really give it a whole lot of resources like
00:03
memory or cores on CPU.
00:03
Anti-virtual machine code can
00:03
be as simple as checking the number of cores
00:03
or advanced as trying to
00:03
execute instructions
00:03
that only virtual machines can execute,
00:03
like the VTX or VM instructions,
00:03
or checking parts of memory
00:03
that a virtual machine can't actually access.
00:03
The next category is anti-disassembly.
00:03
If we pull up sample on IDA,
00:03
we'll sometimes see things that don't make a lot sense,
00:03
or that we can't really continue with.
00:03
If you pull up some malware
00:03
that's written in Visual Basic in VB,
00:03
IDA Pro won't really help you that much.
00:03
You have to do other things or use
00:03
other tools or find other methods.
00:03
Malware that's written in Delphi,
00:03
it's another programming language that's
00:03
a little bit more popular in Russia and Brazil.
00:03
I've never seen anyone use it in America.
00:03
[LAUGHTER] IDA Pro doesn't
00:03
>> really handle that very well.
00:03
>> Or some malware written in.NET or any of
00:03
the.NET style languages like VB.NET,
00:03
or JScript,
00:03
or ASP, C Sharp.
00:03
Those are byte code interpreted or compiled languages,
00:03
so IDA Pro doesn't really help you a whole lot there.
00:03
But when I say anti-disassembly,
00:03
I don't mean the language
00:03
that was used to create the malware,
00:03
I more mean, it's
00:03
usually assembly that the malware author has
00:03
created specifically that will break
00:03
the algorithms used by disassemblers.
00:03
We'll talk about that in a little bit.
00:03
When I talk about malware defenses
00:03
like anti-debugging or anti-virtual
00:03
>> machine or whatever,
00:03
>> those are usually put in by
00:03
>> malware authors, like I said,
00:03
>> to stop automated analysis of
00:03
their malware by using documented,
00:03
undocumented API calls,
00:03
or using anti-disassembly techniques
00:03
like we saw in the illusion bot,
00:03
where dynamically would
00:03
>> call its main function by putting
00:03
>> the return address manually on the stack and then
00:03
using the right instruction to actually jump domain
00:03
instead of returning to the function that called it.
00:03
Now you may ask,
00:03
this is all great,
00:03
and we've seen packers before and we can get
00:03
around those and we can do this type of stuff.
00:03
Why don't antivirus companies
00:03
just look for these techniques and then
00:03
just blacklist smallest malware?
00:03
The answer is because with the same with packers,
00:03
a lot of companies will use
00:03
these techniques to forge pyridine of their software,
00:03
or they try to use it in
00:03
digital rights management or DRM,
00:03
or try to protect their intellectual property,
00:03
try to protect algorithms.
00:03
One anti-disassembly technique, not really,
00:03
it's more of a miscellaneous technique is to
00:03
fill the code with junk code.
00:03
No operational code or not code or whatever else,
00:03
instructions or API calls that really don't result in
00:03
anything functionally changing the malware software.
00:03
Let's look at a basic anti debugging technique
00:03
used by malware.
00:03
There is a function call in Windows that is widely
00:03
supported and it's very simple and it
00:03
just is debugger present.
00:03
If it returns true, that means that
00:03
the function checked a certain location in memory,
00:03
and in that spot in memory,
00:03
it has been marked as yes,
00:03
there's a debugger attached.
00:03
A lot of malware can just do Exit 0,
00:03
or terminate process,
00:03
or launch bad phony code or whatever else.
00:03
Now, we got to be careful
00:03
because I've seen a lot of sandboxes that will say,
00:03
"Oh, this malware called this,
00:03
is debugger present,
00:03
it has this capabilities,
00:03
it has that, it'll do this."
00:03
That's not quite okay
00:03
because I've seen this function
00:03
used in frameworks all the time.
00:03
If I've written a small application
00:03
that takes an image and flips it around,
00:03
just does a little simple transform on it,
00:03
inside the framework, it
00:03
calls this function left and right.
00:03
Because in the framework,
00:03
it needs to know if it should print out
00:03
debug statements or should act a little
00:03
differently or put extra padding
00:03
around its memory buffers.
00:03
Just because you see this function,
00:03
doesn't mean it's malware,
00:03
it just means the code is trying to be more
00:03
aware of whether a debugger is present.
Up Next