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