Malware Defenses Part 3
Video Activity
In this module, we'll begin with some anti-debugging techniques such as NtGlobalFlag, FindWindow(), OutputDebugString(), int 0XCC scanning. Anti-debugging techniques slows down a Malware Analysts. We'll discuss the anti-virtual machine techniques such as process name check, timing checks, registry checks, anti-cuckoo, virtual MAC addresses, LDR_Mod...
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 »
Difficulty
Advanced
Video Description
In this module, we'll begin with some anti-debugging techniques such as NtGlobalFlag, FindWindow(), OutputDebugString(), int 0XCC scanning. Anti-debugging techniques slows down a Malware Analysts. We'll discuss the anti-virtual machine techniques such as process name check, timing checks, registry checks, anti-cuckoo, virtual MAC addresses, LDR_Module, VMware special I/O instructions and many more. Next, we'll see some anti-disassembly examples. We'll also discuss anti-anti-debugging techniques like hook function calls, running without a debugger and logging API calls or dumping memory, and modifying/patching the malware code. We'll then quickly recap the defense categories discussed earlier. To enhance your skills and expertise in the topic, you can read or refer to the following resources:
-
Practical Malware Analysis
-
Virustotal.com
-
Hybrid-analysis.com
-
https://www.symantec.com/connect/articles/windows-anti-debug-references
-
https://www.codeproject.com/Articles/30815/An-Anti-Reverse-Engineering-Guide
-
Anti-Debugging – A Developer's Viewpoint
-
Scientific but Not Academical Overview of Malware Anti-Debugging, Anti-Disassembly and Anti-VM Technologies
Video Transcription
00:03
>> Now, we saw like it's being debugged and we saw
00:03
a find window Anti-Debugging trick and
00:03
OutputDebugString trick and there are many more.
00:03
There are lots of things like if you see in the bottom
00:03
right end 0xCC scanning,
00:03
that scan for the three soft breakpoint instruction.
00:03
Remember how I said that with a debugger,
00:03
if we hit "F2", it will replace that instruction
00:03
>> with the CC byte,
00:03
>> which is the N3 instruction that when the process is
00:03
executing and it hits
00:03
that instruction and hands over
00:03
control to the anti-debugger,
00:03
which is in another process.
00:03
Now some malware will look for that byte,
00:03
the 0xCC byte and its own code.
00:03
It's just looking for debuggers and the way around
00:03
that would be to use a hardware breakpoint,
00:03
instead of a software breakpoint like 0xCC or N3.
00:03
There's lots of API function calls,
00:03
both documented and undocumented
00:03
that malware authors will use.
00:03
They'll look at various data structures in memory.
00:03
They'll look at whether certain memory flags are set.
00:03
They'll look at many, many things.
00:03
The time, as I mentioned
00:03
before but this is not an exhaustive list.
00:03
In fact, there are many more techniques and
00:03
tricks that come out not all the time,
00:03
but it's not uncommon for a new technique to come out.
00:03
The thing about these tricks and techniques is
00:03
>> they only slow down malware analysts.
00:03
>> They don't stop us and it's
00:03
a losing battle in terms of time.
00:03
If a malware author spends three or four days figuring
00:03
out a new anti debugging technique
00:03
it'll take us 10 or 15 minutes.
00:03
If we're decent reverse engineer,
00:03
it will take us 10 or 15 minutes to bypass that,
00:03
either patch it or whatever.
00:03
There was a trend awhile ago about
00:03
more anti-virtual machine techniques
00:03
and there are lots of cool things you can do with this.
00:03
But that's faded away because a lot of
00:03
infrastructure nowadays and small companies
00:03
or medium-sized companies is all virtual.
00:03
If you hardcode stuff into your rat
00:03
>> or Trojan or malware,
00:03
>> that just kills itself
00:03
when it's detected in a virtual machine.
00:03
You can't infect like 90 percent
00:03
>> of the infrastructure of your
00:03
>> target company because they virtualize
00:03
>> your Active Directory service or server,
00:03
>> they virtualize file server,
00:03
they virtualize their ORTP server,
00:03
they virtualize their whatever else.
00:03
A lot of malware will say,
00:03
"okay, I'll infect it, I'll even run,
00:03
I'll even do a normal thing,
00:03
but I am going to report back as
00:03
soon as possible that I am running in a VM."
00:03
But it's more common to say,
00:03
I'm anti-cuckoo sandbox or
00:03
I'm anti Geo Sandbox or I'm anti firearm,
00:03
anti whatever else, threat creditor,
00:03
glue court or whatever.
00:03
I mentioned anti disassembly earlier and
00:03
here's a pretty basic example of that.
00:03
We saw before with like illusion bot where
00:03
>> IDA Pro didn't pick up the fact
00:03
>> that it was just going to another section of memory.
00:03
It figured out that that was code,
00:03
but didn't figure out how it was
00:03
being called but IDA Pro has
00:03
a very advanced disassembly algorithm.
00:03
However, not all disassemblers are,
00:03
only debugging has a pretty good one.
00:03
But there are some disassemblers
00:03
that will just look at one instruction,
00:03
say, "okay, this instruction is four bytes in length.
00:03
What's the next one? This one is
00:03
two bytes in length, what's the next one?
00:03
It's three bytes in length. What's the next one?"
00:03
That's called a linear disassembler.
00:03
On the left we can see
00:03
some basic assembly that you can put into
00:03
your C code or
00:03
Visual Studio project and the first instruction is XOR,
00:03
EAX, EDX, that's just zeros out EAX as we've seen.
00:03
We can say jump zero,
00:03
it will jump somewhere else and then right after that,
00:03
we can put a byte like 0xEA,
00:03
where that doesn't actually disassembled to anything.
00:03
Or if the disassembly gets confused and says,
00:03
"okay, it's part of a larger byte, 0xEA, AB,
00:03
Ff or whatever," is still
00:03
going to break all of the code beneath it,
00:03
because it's trying to say, okay,
00:03
this instructions is this, how many
00:03
bytes onto the next one.
00:03
This instructions one byte,
00:03
this instruction is two bytes,
00:03
whatever and your program could have jumped to where
00:03
the real good code is and
00:03
the disassembler will just
00:03
break because it's not following that jump.
00:03
However, IDA Pro
00:03
has a pretty good disassembly algorithm and
00:03
will follow the jumps if it can
00:03
and some malware authors as
00:03
a way to fool IDA Pro will do this,
00:03
say XO EAX EX jump,
00:03
you know, EDX plus EAX.
00:03
IDA Pro doesn't know that the final jump destination is
00:03
a constant value but IDA Pro
00:03
is pretty good at
00:03
this stuff and IDA Pros been around for a while,
00:03
it's the best in the industry, I think.
00:03
They've developed a lot of
00:03
algorithms to get around that type of stuff.
00:03
Over on the right,
00:03
we can see another kind of trick and
00:03
that's dynamic co-generation colic packers.
00:03
Where one instruction like move
00:03
EAX is moving in there a pointer,
00:03
a label called changeMe,
00:03
EAX is right there,
00:03
has the address of changeMe and then
00:03
the next instruction is move 0x90,
00:03
which is a NOP, no operation code,
00:03
and moves it into the location of EAX,
00:03
NOP is one byte.
00:03
Let's say the first byte of what
00:03
changeMe is pointing at could make no sense whatsoever.
00:03
It could be just jump code
00:03
until that first byte is knocked out and then
00:03
>> the rest of the code will just makes sense because
00:03
>> the processor doesn't actually check to
00:03
>> make sure that what it's doing makes sense.
00:03
>> The processor just executes code,
00:03
it just executes the bytes, whatever it gets.
00:03
If it gets an invalid instruction,
00:03
it throws an exception otherwise
00:03
it'll just keep chugging through.
00:03
You can actually jump
00:03
into another instruction and that is
00:03
a technique that some packers or malware authors will
00:03
use where they say,
00:03
okay, here's a bunch of move instructions.
00:03
Now here's a jump instruction that jumps into one
00:03
of the previous move instructions and this
00:03
breaks all disassemblers currently
00:03
because they only look at something as,
00:03
okay, this has been assembled
00:03
despite it has been accounted for.
00:03
This has been assembled, these three bytes have been
00:03
accounted for and can't really
00:03
comprehend the idea that this byte could be
00:03
this instruction and can also be part of
00:03
this instruction and some other ways.
00:03
Some newer ways that malware is one family that I know
00:03
of is breaking disassemblers is it's
00:03
like switching between 32-bit and 64-bit code,
00:03
which is really tricky,
00:03
hard to do and it's currently breaking all disassemblers.
00:03
Back to debugging real quick.
00:03
If we're running Ali debug and we
00:03
saw that that call is being debugged and we thought,
00:03
what is it actually doing and
00:03
>> jumped into that function.
00:03
>> We would see there's only three instructions
00:03
or four instructions
00:03
where it's only checking a little bit.
00:03
Like literally it's checking a bit in memory to see if
00:03
it's one or a zero and then returns that bit,
00:03
wouldn't it be cool if we just patched that bit to be
00:03
zero and there are plugins for Ali, like LTE-Advanced.
00:03
>> I think all the AD or
00:03
>> all the anti-debugger or whatever,
00:03
>> where it basically goes through a bunch
00:03
of these anti-debug checks and neutralism.
00:03
This is an anti-anti-debugging technique,
00:03
where the code has some anti or the malware has
00:03
some anti-debugging technique and we
00:03
are taking care of that.
00:03
We are either hooking that function,
00:03
or we're modifying the result of that function,
00:03
or we're modifying the memory address
00:03
which is that function checks,
00:03
or whatever we're doing.
00:03
We can lie to the application.
00:03
I've used this all the advanced plug-in before.
00:03
It's for only 1.1,
00:03
I believe, or one.xx.
00:03
We'll work on one dot,
00:03
whatever versions of volley.
00:03
I haven't really played with all the 2.0,
00:03
all that much and I haven't really played for,
00:03
played with their debugging capabilities
00:03
or anti-anti-debugging capabilities.
00:03
Mainly because I'd like
00:03
to know actually what my tools are doing,
00:03
and if I don't know what a plugin is doing,
00:03
I can't really account for it.
00:03
I use the light, usually I like to run
00:03
without any plugins unless I absolutely have to.
00:03
What we did was patch the program.
00:03
We can also patch the memory and we can
00:03
also use a plugin like this.
00:03
However, what we did when we
00:03
patched the executable was we
00:03
changed machine code and that can be accounted for.
00:03
The malware could have
00:03
some integrity checking algorithms,
00:03
it could have anti-dumping code.
00:03
It could have a few different things that could happen.
00:03
What I mean by that is,
00:03
there's a simple CRC check.
00:03
I think it's correction
00:03
or code or cyclic redundancy check what CRC stands for.
00:03
I've seen some malware where it'll
00:03
run some code and then do it,
00:03
check where it says,
00:03
for the last 100 bytes or something,
00:03
hash that in to tool like an output of
00:03
a four byte hash and then check it against this value.
00:03
It's this value, then great, keep going.
00:03
If it's not, the mouth or nose has been tampered
00:03
with and can terminate or do whatever,.
00:03
Not only more now we'll do this,
00:03
but commercial software do this to.
00:03
The worst I've seen is Skype.
00:03
Skype has a ton of anti-reversing,
00:03
anti-debugging, and anti-patching,
00:03
things built into it.
00:03
I think I've seen a malware where it'll check
00:03
its own code two or three times and Skype,
00:03
I think I've seen it, do it 33 different times.
00:03
Skype can be pretty tricky about what it does because
00:03
is very protected software.
00:03
More than anything else I've ever seen,
00:03
>> more than games,
00:03
>> which is the biggest user of anti-debugging stuff
00:03
or anti-reversing or anti-pattern
00:03
or ant-modification, whatever.
00:03
Of course, the other technique we can use
00:03
besides anti-anti-debugging techniques is
00:03
we can just not use a debugger.
00:03
There are programs out there that
00:03
will just inject a DLL into a process,
00:03
and this monitor everything it does.
00:03
There are things that try to instrument hook
00:03
all the functions that might be
00:03
called and they just monitor through those.
00:03
There are software out there
00:03
that just all run them our and then dump
00:03
the memory and pause it if it's a virtual machine or
00:03
just stop it when it
00:03
gets to a certain code page
00:03
by throwing an exception or something like that.
00:03
Just a quick recap and a little brush up.
00:03
Usually malware has a goal of
00:03
stopping automated analysis,
00:03
so they have anti-sandbox and anti-VM stuff,
00:03
and to slow down our analysts,
00:03
so they'll have anti-debugging or
00:03
anti-virtual machine stuff or anti-disassembly stuff.
00:03
With anti-debugging, we've seen
00:03
some API calls is being debugged, being called.
00:03
We've seen some process and thread stuff.
00:03
Whether you I knew it or not,
00:03
when I said that is being
00:03
debugged is only three or four instructions,
00:03
and it checks a certain part of the memory.
00:03
It was checking a
00:03
>> certain data structure called the PEB,
00:03
>> the process environmental block,
00:03
and it was just
00:03
checking for that one little bit in there.
00:03
It was just in the user land,
00:03
and the malware didn't even need to call that function.
00:03
It could have just executed
00:03
those four instructions by itself.
00:03
Which is not something a lot of malware authors do.
00:03
But as an analyst,
00:03
you should be familiar with those instructions,
00:03
particularly the FS register,
00:03
because it checks the PEB,
00:03
the process environmental block,
00:03
and there are a lot of flags,
00:03
there's a lot of bits and bytes in there that will
00:03
indicate whether a process is being debugged.
00:03
Anti-debugging, hardware and register
00:03
based ways of getting rid of debugger.
00:03
Like I was mentioning earlier, hardware breakpoints,
00:03
certain registers that debuggers use.
00:03
If you want to know more,
00:03
I will give you more resources here in the next slide.
00:03
There's exception base. We didn't really cover that.
00:03
But because debuggers want to instrument a program,
00:03
they will get what's called a first chance exception,
00:03
so if your program does a divide by 0,
00:03
it will throw an exception.
00:03
The process here will throw an exception,
00:03
and if you have a try catch block in your code,
00:03
your C code or C# code or
00:03
for C# uses SEH, structured exception handling.
00:03
Other programming languages have other things built-in,
00:03
but they're mainly based
00:03
around exceptions, structured exceptions,
00:03
and when an exception happens within a process,
00:03
the first chance exception goes to the debugger
00:03
before the malware will
00:03
take care of a problem like divide-by-zero.
00:03
The debugger will take over first,
00:03
and then it'll give you the ability to look at memory,
00:03
look at values and variables that we'll look at
00:03
the call stack will look at all this other stuff
00:03
because there's debugger is meant to get rid of bugs.
00:03
It's meant to help you. If you just say, continue,
00:03
if you change something remembering say,
00:03
there's a bug and it's malware
00:03
which happens all the time.
00:03
I was dealing with it today actually.
00:03
Then continue, it won't call
00:03
the exception handler or
00:03
the exception code in the malware.
00:03
The malware could have a flag in there.
00:03
It says, if this flag didn't get checked,
00:03
we know that a debugger is
00:03
attached and intercepting those exceptions.
00:03
There's a few different methods built around that idea.
00:03
>> We talked about the modified code based anti debugging,
00:03
where it checks its own code either for the CC byte
00:03
or Syriac CC byte or the N3 instruction.
00:03
Or it'll just do a hash check or CRC check of
00:03
the code that it's about to execute or that it has
00:03
executed and checks it against usually
00:03
>> a four byte hash.
00:03
>> If it's different than what it's expecting,
00:03
then it knows it's been modified and
00:03
will take whatever actions at once.
00:03
We also talked about timing based,
00:03
where I mentioned that
00:03
some malware we'll just call asleep function.
00:03
We'll see if it actually slept that long or if
00:03
it's being short circuited
00:03
or knocked or hooked or whatever.
00:03
But an older technique is actually where
00:03
the malware will execute a number of
00:03
instructions and then see how
00:03
fast it took to execute those instructions.
00:03
There are instructions in X86 that says, oh,
00:03
give me the real time clock rate,
00:03
or give me whatever.
00:03
You can actually determine how much time has
00:03
passed between executing different instructions.
00:03
It used to be based off the idea
00:03
that virtual machines are
00:03
usually jam packed onto
00:03
very high and powerful computers,
00:03
but there's several virtual machines going at once,
00:03
the processes switching between them.
00:03
Virtual machines actually take much longer to execute
00:03
instructions, than physical ones.
00:03
The timing based attack was,
00:03
or detection was meant to determine if
00:03
you're in a virtual machine
00:03
via how fast you are executing code.
00:03
There is lots of anti virtual machine things
00:03
that we talked about,
00:03
not just API calls, or not just
00:03
>> programmed process names or memory constants,
00:03
>> or things in the API,
00:03
or instructions that you can or
00:03
can't execute within a VM.
00:03
But there are things like
00:03
certain API calls or
00:03
ports that are open to virtual machines only.
00:03
VM ware, what we've been running,
00:03
or what I've been running, opens
00:03
up a special input and output port.
00:03
That's how copy and paste works and that's
00:03
how drag and drop works,
00:03
is it communicates information through
00:03
this port that doesn't exist in normal machines.
00:03
A popular anti, or
00:03
a popular virtual machine detection trick
00:03
is to see if that port is available.
00:03
As I mentioned earlier,
00:03
a lot of malware doesn't
00:03
seem to concern the disinfection in a virtual machine
00:03
anymore because targets are
00:03
usually on virtual machines as well.
00:03
We went over some anti disassembly
00:03
techniques ware like dynamic code generation,
00:03
or assembly meant to
00:03
specifically break algorithms of disassemblers.
00:03
If you want to know more,
00:03
I would suggest going online to
00:03
symantec's anti debug reference
00:03
where they've collected from over the years,
00:03
malware doing various things for
00:03
anti debugging or anti reversing,
00:03
anti analysis, whatever.
00:03
The open RCE forum, open RCE.org.
00:03
They have a pretty impressive library
00:03
and source code available for
00:03
anti reversing or anti debugging examples.
00:03
If you're interested in
00:03
>> anti virtual machine techniques,
00:03
>> Pafish or paranoid fish made
00:03
by Alberto Ortega is pretty good.
00:03
The code project.com,
00:03
that article shows a lot of source code,
00:03
sea level, assembly level source code
00:03
of how to implement reverse engineering techniques.
00:03
It's not aimed at malware authors,
00:03
it's more aimed at people who want to protect
00:03
their game from being pirated or
00:03
protect their intellectual property.
00:03
The two papers at the bottom I highly suggest
00:03
reading and there are talks that go along with them.
00:03
Source code, anti debugging and developers
00:03
>> view is really good as scientific but not academic.
00:03
>> Academic overview of malware anti debugging,
00:03
anti disassembly anti,
00:03
VM ware technologies, that's really good.
00:03
The scientific, the last one I just
00:03
mentioned is Rodrigo Branco,
00:03
Gabriel Barbarossa, and Pedro Nieto.
00:03
Tyler Shields is the one who
00:03
did the developer's viewpoint.
00:03
Practical malware analysis has
00:03
some good chapters devoted to it.
00:03
Two years ago about I did a talk at NoVA hackers,
00:03
a Chaconne epilogue, where I had collected
00:03
>> all of the techniques that I had ever observed.
00:03
>> I put them in one giant project and I
00:03
had taken all this code
00:03
and I developed a game around it,
00:03
where you can execute this piece of malware and it will
00:03
choose a random anti debugging trick,
00:03
random anti VM trick,
00:03
random technique of communication via
00:03
IRC or HTTP or random install persistence mechanism,
00:03
via registry run,
00:03
via service or whatever else.
00:03
Then it would hide on the system and then
00:03
the malware analyst would have to go and look for it
00:03
and then bypass those anti debugging or anti VM tricks,
00:03
to get at an encrypted string.
00:03
Then the encryption was random as well,
00:03
or you can specify all of them.
00:03
If you're interested in these techniques,
00:03
this technology as I am,
00:03
I would suggest implementing
00:03
a lot of these things yourself.
00:03
Don't go just writing malware and releasing it,
00:03
but it's good to be familiar
00:03
with how these things work at a pragmatic level,
00:03
so you can not only develop it
00:03
yourself and reverse engineer it yourself,
00:03
but understand where the pivot points are.
00:03
Like say, oh,
00:03
I made some anti VM code based on paranoid fish,
00:03
but it doesn't actually work under this circumstance.
00:03
One technique doesn't work if you're
00:03
running multiple cores in
00:03
your VM. It's good stuff to know.
00:03
It's good to be aware of this stuff.
00:03
Again, my name is Sean Pierce,
00:03
I've been the resident expert
00:03
for malware reverse engineering.
00:03
If you have any questions,
00:03
my Twitter is here
00:03
and I've mentioned my email
00:03
before, Cybrary@SecureSean.com.
00:03
I hope you enjoyed this video series.
00:03
I wish you good luck.
Instructed By
Similar Content
