>> Now let's just jump into a demo
and see what we're looking at.
This particular hash I'll
make available to you, and here,
let's just say the scenario
is dynamic analysis is failing.
Someone who doesn't know as much as
you do about malware has said,
"Hey, I can't get the sample to do anything.
It just starts up, it executes, it just dies."
We can replicate that here.
Let's say they were looking for network traffic.
Here I've installed Wireshark.
I'll start it up here and
>> here's our sample, extract it.
>> The standard password is infected.
[NOISE]
We'll start Wireshark.
As always, just check and make sure that the network
is exactly how we want it.
It's not net, it's on our virtual net
2 and we haven't powered up a router. It's okay.
Start CaptureBAT and execute our malware.
If you see a few uprequest trying to get out,
give it a few seconds and end it or open up
our log and says it was created, then it terminated.
We can run a few more times just to make sure,
but rest assured the person
that needed our malware before us and
can't get it to run anymore, is right.
There's something about the sample
that makes it just terminate.
It could be a kill date, it could be VMware,
it could be doing any number of things,
it could be checking the MAC address of
the virtual machine to see if it's a real MAC address,
not one allocated to VMware,
it can be doing lots of stuff.
How do we get in there,
into that sample, and figure out what's going on.
As you'd imagine, we use our reverse engineering skills.
In this VM, I've installed IDA Pro here.
Latest version is 6.8.
Since it's the demo version, we won't be
able to save our analysis, but that's okay.
You can still look to see what's going on.
These symbols are just fine and we can go and do this,
we can just go click around,
but our goal is to figure out why it's not
running in our little sandbox and our virtual machine.
For that we shouldn't just go jump into
the code because that's an easy way to get lost.
Because you'll pop up an hour later
after reverse engineering this thing
and say "What was I supposed to do again."
Here I'm just going to look at something that's usually
a good indicator for getting an idea of what
this malware does and that's go to view.
Subviews and strings.
Now IDA looks at these strings that are referenced.
We can always use map pack and
just right-click on whatever file and say strings.
Thank you, Dave Zimmer. We can
see usually a few more strings,
but I'm just going to look inside IDA
and just get an idea of what's going on.
I see Rudy, I see a few things that are interesting.
Current user's, more
permission aware that's probably
>> a registry key it uses,
>> Google Chrome, Opera, Firefox, Internet Explorer,
Maxthon, these are interesting things that I can
dive in at any
second and try to figure out what's going on.
Private mesh is notice kick.
IRC commands, it's probably an IRC bot,
paying you can do some network stuff, Gmail,
Yahoo, Facebook, Hotmail.
This is interesting here, sandboxing.
I look at this and I say, " Okay, sandboxing,
he Joe sandbox, these are sandboxes,
these are commercially available
malware analysis solutions,
automated analysis solutions.
I can see the string is referenced here.
I can hit X,
see where it's referenced or just click over here.
I can see where
the string is moved into someplace on the stack.
Instead of pushing,
the compiler made these function calls,
just take the arguments on the stack.
It looks like this function is being called each time,
string is being moved here.
That's moved in the same location,
even though there are pushes,
pops here at the end.
I see that it takes in a parameter,
string has escaped, jump back up and say okay.
I'm going to guess this is
either a process name or a filename,
but I've been around,
I've been doing this for awhile and usually malware
cares about what's running right now.
If I go here and hit "Y",
then I can say string,
I can say process name.
I usually want to name things
as I go along like this function,
I want to take a quick look and
figure out what's going on, but if I hit "X,"
I can see it's referenced in several other places,
I should probably go ahead and
figure out what this function does,
I can do that pretty
easily because it's only making a few calls,
it's not going any deeper.
They're all standard API calls,
create Tool Snapshot 32 or create tool help 32 Snapshot.
If you're not familiar with Windows programming,
you can easily Google this or
hover over it and you can see the parameters.
You can get an idea for what it does,
but I'd suggest googling these things and,
or manually programming them
so you can get an idea as a developer,
what's required for what malware author is trying to do.
I can see it does create tool help
32 snapshot and then does process 32 first.
If you Google this and you go on to
MSDN and these websites,
you can see that these functions are required and
the most common use of them is to
iterate through all the running processes.
I can see there's a string compare,
there's the same move convention as we saw earlier,
where instead of pushing,
it's just moving, it's a bit faster.
We can see there's two strings being compared,
these may or may not match up as the actual parameters,
or IDA may not have properly named
these because this is a struct or these aren't structs,
these are parameters,
but for string compare,
we know we're taking in two strings and
we know that DW flags,
DW means Double Word,
in Windows language that would be
>> 32 bits or four bytes.
>> Because the original word was 16 bits or two bytes.
We see that there's two strings being
compared and we know we're getting
in process name as a parameter here.
These things right here,
the IDA Pro has looked at,
it knows that there's much space
on the stack because it's allocated right here.
It took its best guess at what those things were.
It says, this is a struct,
and I'm going to name it here,
and string 2, which was what was passed in here,
is the parameter here.
No, normally IDA renames that,
but we can do
it manually and see it knows the same thing.
We can see the process name is moved into
EAX and EAX is one of the things that's
comparing the string compares being compared
to and then attest EAX the result of string compare.
If we can look at
the results of string compare and we can
see what the output is,
if it's what we expect it to be,
be it like zero if the strings are matching
or 1 if they're not, or vice versa.
We can see that there's a loop here and it's iterating
through each process name and it
is testing it to see if process 32 next return 0.
If it did, it would quit,
it would exit the loop.
We can see here that it probably was looking for
a process name very
specifically and if it didn't find it returns zero,
but if it did find it, it returns one.
AL is the lower part of EAX.
It's a little sloppy by the compiler,
is trying to be more efficient, but frankly,
EAX something could have been put in the higher bits,
like AH and it's only storing
one and the lower bit, but it's okay.
It probably figured out some mathematical way
of determining that this is an okay instruction to do.
We can see that
given a process name it tests to see, is this running.
False 0, true if one.
I'm going to name it N or I can hit
"Y." I can say, is process running.
>> Why didn't it take? That's weird.
I'll just use N process running.
We can see that it does the same curve test.
These instructions are a little redundant here.
It could have easily just left
this value n here and just put the return up here.
But compilers do what they do.
We can name this function as Joe,
anti-ad and for anti-debug,
Joe Sandbox check.
We'll see what calls this,
by pressing X and you see only one function calls it,
we jump up here,
you can see what other things it calls,
it calls a few other functions.
We can jump into one of those. Look, Wireshark.
It's not really anti-debugging,
it's a tool check, but
I'll just say anti-debugging or AD.
Wireshark check is process running is also in there.
Since its process running seems to be
a commonly-used function by
the stuff we can see Is Joe Sandboxes, Wireshark.
Then there's two other functions that use it.
It's doing the same thing Sandboxing.
I'm going to say AD_Sandboxing check.
Is process running. Let's just
"X" again to see what other function is left.
Vbox service, this is our Virtual Vbox check.
There seems to be it's like anti-tool, anti-analysis,
anti sandbox, anti-Bm stuff in here.
If we "X" and pop up here.
We can see what other functions are being called.
There is an anti-Geo Sandbox,
anti-Wireshark, anti Virtual Box, anti sandbox.
There looks to be another function here,
>> and jump in it.
>> Debug output string,
this is actually a specific string
that will break OllyDbg.
This function is used by programs to print out
messages that when a debugger is
touched will display or will be able to process.
This is useful for an application
as a driver or something else that may not
have access to a front end
or doesn't want to create a console or whatever.
But if there's some problem you can want to find out,
so you can redirect debug messages to logs or you can use
a program that Microsoft provides to read output debug,
or to read debug strings.
OllyDbg has a little bug in it
that when it tries to process a string, it will fail.
I happen to know that because I've seen it before.
If you just Google around for it,
you can find stuff.
I'm going to call this AD anti or
AD OllyDbg breaker really.
It moves it 0 and to find file,
and calls file close.
I happen to know that's another little anti-debug trick.
If I jump in here,
I can see is trying to find
a particular Window and it's moving.
I'll see what are the parameters to that.
That's a long pointer C string as Windows name.
I can look at this and say,
that's interesting. It's right here.
This value here, looks interesting to me.
Usually, constants at large
aren't usually use all often,
most are used for comparison checks or whatever.
If we right-click on this,
we can display it as a decimal,
we can display it as octal,
we can display as binary,
or we can display it as ASCII.
That's interesting. If we
do the same to this other value we can
see O-L-L-Y-D-B-G, OllyDbg.
It is looking for the Window with the name of OllyDbg.
It's trying to find
or it's trying to get a handle to OllyDbg, the Window.
I'm going to rename this as OllyDbg finder.
It tried to break OllyDbg with this to
try to find OllyDbg.
Call Is debugger present.
It is using that function call that we discussed earlier.
It does a simple test, jump if 0.
It goes here that test BL,
which was which these other things would use to say,
"Hey, I'm being debugged or hey,
>> I'm in a virtual machine."
>> Then it would call this function if it
determines that it is in a virtual machine.
Say test jump not zero,
so it will jump around if not 0.
This would be called
if there was a virtual machine detected.
Lets see. BL.
>> If a tool was detected,
it'd be marked as one.
For right now I'm just going to say tool analyses,
tool for environment detected.
As probably some terminate thing, so it is asleep.
This value is interesting, so 500.
It's doing basically asleep.
Then it keeps going. That's interesting.
Move A0. If it's in a VM, it does asleep.
Now normally I would have little notes file
opening or I would have notes file open,
and I would be making notes about the stuff
I'm finding as I'm finding it,
>> but now we get to the end,
>> and it's time to name this function.
Even if I don't know exactly what it is,
I want to do my best to name
the functions as being debugged.
I'm going to hit "X" and see what calls that.
I can see it's called by this function.
We can repeat this process over and over again and climb
up the ladder and
completely reverse engineer the program.
But we basically accomplish our goal.
We figured out why
the program wasn't running and we can test this.
We can be scientific about it and run it before in
a virtual machine with
the same conditions as the other guy did.
Then we can do something about it.
We can change the environment
or as something that I will talk about later,
we can actually patch the program.
We can change the malware
so that it no longer does this check.
Where if this returns true,
if it returns a non-zero, basically,
it will go execute this and terminate the process.
It's interesting. If nothing
is detected, everything is fine.
It will take this jump, jump is zero,
and it will do a little sleep for
one millisecond and set this byte to zero.
Now this byte is interesting because it's also
compared up here to see if it even do this at all.
If it's compares to zero and and jump
not zero. Let's see.
The green is if it takes the jump.
If this is zero,
then it would fall through to here.
If it's not zero, it would jump here.
That's interesting. I'm going to call this for
right now the debug flag.
This is not exactly the debug flag
because it doesn't seem to be checking for debuggers.
If there is a debugger, it would just terminate.
But it looks pretty interesting nonetheless
>> because I can see that it is referenced
>> throughout the program.
>> We can jump into some of these and we
can reverse engineer the program more.
We can say, oh look, there's
a create process and then it checks
this flag and then changes its behavior.
Me being a little paranoid, I would think, okay,
maybe this is another anti debugging technique because
another technique is relying on
the fact that you can only debug
a program with one debugger at a time.
Some malware will launch
another process of itself
>> and then can tell that process,
>> "Hey, try to debug me."
If you can, then great.
You're the only one that can debug me.
If you can't attach to me as a debugger,
that means there's another debugger
attached and I should just go ahead and die.
I'll try to reverse engineer this
more and see if that is the case,
but for now I'm just going to jump
around and see where else this flag is referenced.
I can see that there's more sleeping involved.
I'm a paranoid person,
but this reminds me of another anti debug technique,
which is that a lot of malware will just say, oh,
you just install one system, okay,
we'll sleep for 10 minutes,
two hours a day or whatever.
It's relying on the fact that sandboxes and
automated analysis solutions will only wait
30 seconds or a minute
or two minutes or five minutes or whatever,
and the malware can just simply outlast them.
A lot of sandboxes will hook
this function sleep and we'll speed it up.
It will just say, oh, you want to sleep for 10 minutes,
okay, well done.
Announced 10 minute later. Malware as
a sandbox detection method,
will see if that time actually did pass.
They can use that with tick count.
They can use an instruction to
see how long the computer has been online,
how long it's been on, and then
compare that before and after the sleep.
It can do a lot of things to determine if it was
actually a certain period of time has elapsed.
I dig into this a bit more to see
if this is that technique that they're using.
Probably not because it's only
sleeping for one millisecond.
Usually when I see a flag that I find interesting,
I start upfront because
generally these addresses are
shorted from beginning to end,
and generally code upfront is executed first.
Obviously, you can have a jump instruction
that jumps all around,
but compilers tend to
make the code linear and where it is being executed.
I find this interesting,
where it'll check this can't debug flag and
then go to I see
this string where it says quit uninstalling.
I see it's shutting down a socket and
closing down the Windows socket library,
and then calling this function,
just dive into it really quick.
I see that it's accessing
the registry keys that is probably
>> using for persistence.
>> I can see after it accesses those,
it opens switch key,
then does out switch key delete.
It looks like it is indeed uninstalling.
I'll just make a quick note of that,
uninstall H keys, hit "Escape",
go back up and say, okay,
so this flag may not be a debug flag,
but may just be
uninstall debug flag.
Hit "Escape" or just hit "X" again and say,
okay, where else is it referenced?
It's referenced here.
Somewhere we'd been before.
It looks like an ROC command processing module version,
request destination.
This looks interesting, but it's not what I'm after.
There's my other flag again.
What I'm after is to see,
is there any more anti debugging things going on?
Is there anything else built into
the code that will hinder dynamic analysis?
Because as soon as I figure that out,
I can be like, oh, no,
it's just don't want to run
Wireshark on your own victim machine.
>> X again, find all the places it's being referenced.
X to this one. Just climb up.
X is called in a few places.
Right now I'm just wandering around the code.
Another thing I'm interested in since
this flag was seen around.
I'm just hitting "Escape" a few times.
Since this flag was seen around
this area and it's been debugged.
I'm going to name this function as
terminate if been debugged.
I'm interested in where this flag was written.
Where it is accessed
and what's paying attention to it
because if this has anything to do with debugging,
I would like to know about it.
I can hit "X, " and over here on the Type,
I can see it's only written
two and three places and in all the rest of the places,
here it's being read from.
Investigating those places will tell me what criteria
this code is using to access or to write that variable.
This is very interesting.
I can see down here in the bottom left,
that this is a fairly big function
and I'm willing to bet just from the structure of it,
it looks very much like
a command processing module
or very large switch statement.
I can see where it writes
one and two this uninstall of
debug flag and by
just double-clicking on this arrow here,
I can jump all the way to
>> what code block had that jump.
>> Here, I can see it's
checking something against a string of uninstall.
It's looking more and more like
this flag doesn't really have much to do with
debugging so much as some uninstall feature.
Of course, if we wanted to do
>> a full reverse engineering,
>> this would be a great place to
start because we can enumerate
all the commands and probably get
a good idea of capability in function and purpose.
This is just as
like a good habit and then jump back up here and
say main
command processes.
It doesn't make sense. Processing. You might be like,
okay, great, good.
That's some interesting stuff.
Hit "Escape, " go back,
check out these other places where
it's written quit updating.
Another quit slash uninstall thing, go X,
and go to the last place this flag was written to.
We can see this and you might be like,
what's this? What's going on here?
Well, I can see a zero,
and a bunch of other constants being moved
into these flags, not just this flag.
This looks like program data,
the registry key, user profile,
Windows XP, Windows 2000, all this stuff.
It looks like this is setting
global variables.
Hit "X" It's only called by one place.
Thank you, Ida. We like your product very much.
We can see that
we already begun digging into this program,
but we got what we came for.
We don't really see any other anti-analysis strings.
We don't really see
any anti-debugging stuff other than what we pinpointed.
What are we going to do about it?
If a person says, "Well,
I really have to have Wireshark on
my analysis machine based on all the
VMs," or "I really have to use Sandbox here.
I really have to do this or that. What should I do?"
Well, I would go back to
the place where we saw the debugging action here.
Here is where the program says, am I being debugged?
Then gets the return value
>> from all these checks that it
>> does and then it acts on it.
It says, test return value and if it's zero,
keep going with our thing.
If it's anything else, terminate process.
We can actually patch the program. We can modify it.
How do we do that? With our good old friend OllyDbg.
You can use 2.01,
you can use 2, you can use 1.1.
They all do a fine job of this.
They are plugins. They can help,
but I'm just going to do this without plugins.
We know it has anti-debugging
and we know in fact that one string might
even break OllyDbg or try to kill
it or just detect that it's there,
but we can go ahead and load it up,
and by default Olly,
it'll break when
the main module loads and begins executing.
Just as a note for the paranoid,
there is code that is supplied by this executable
here that gets executed
before the main function does like a TLS callback.
Some malware authors will hide
either the main code in the TLS callback,
or they will hide
their anti-debug stuff in the TLS callback.
Sometimes you might have to modify Olly through Options,
where instead of [inaudible],
you can say break at a TLS callback,
or just wherever the main module begins,
or maybe whenever the system takes over,
or whenever DLL loads,
or whatever it is,
but this is just fine for our purposes.
Here in Olly, we can see this function being called.
I'm going to hit "Space" and I'm going
to go to this location.
This is the relative virtual address,
the RVA, and
this is basically the executable said, hey,
I want to load at 40100
is usually where it says I want to be loaded.
All this code either has said, okay,
if this were actually a memory,
it would be at this address.
Olly has begun this program and it
has loaded into memory at the address that it wanted.
We can just hit "Control, G".
I can say I want to be taken to 0X.
We can see that it's the same assembly code.
Let me make this bigger.
Over here we see this address.
We can copy and paste it and just hit "Control,
G" and paste that address in.
We can see that dysfunction call.
The assembly matches exactly as what Ida has produced.
Ida just made it a bit prettier where there's
a call, a function,
and there's a test AL,
jump zero, etc.
Hit "Space", we can see similar,
and this is just because Olly
has pretty good dissembler and so does Ida.
Let me move this over so we can
see the stack a bit better.
[NOISE].
>> We don't actually need to do very much.
We can see right here is the only place if we hit "X,"
only place that this function is being called.
Unless the program's doing something tricky,
which by the looks of it
>> isn't doing anything too tricky.
>> Now, the strings were very obfuscated.
Nothing was really encrypted that we saw.
I'm going to guess that this
is the only place this is called,
just like other stack analysis has determined.
Here we can hit F2,
which places a soft breakpointer.
It replaces E8 and 7F right here with,
or just E8 replaces with the byte CC,
which is a software breakpoint.
These bytes are left here
and they don't actually make any sense if
the hardware were to try to execute it.
We can hit "Play" and it will run the program,
the Malware up to this point.
If we hit up to again,
it's removed the breakpoint.
If we just hit Play again,
it would remove the breakpoint and let it go anywhere.
Here it's about to call this function and it's going to
return A1 because we'll
be able to find all if it doesn't crash it.
We can do something pretty cool.
Where since we want AL or
the lower parts of EAX to always be zero.
We always want to take that jump
around the terminate process.
We can just say,
we've just type a sudden.
We can just say,
[NOISE] MOV EAX,0,
and I can assemble it.
Now, this is really cool
because we just replace some code there.
Instead of calling that function and returning a value,
we just manually put a value we wanted into EAX.
This is how a lot of people who crack software work,
where they will make a patch, which is what we did.
We made a patch to this program.
We can even test it.
We can say, now execute that.
We can see that EAX is 0,
and then we can step over, which is F8.
Or we can say that jump zero is taken,
and it does that one milliseconds sleep,
and it repairs the stack from that call,
and it goes about its business.
That's fantastic. How does that really help us?
We want to give this back to
the malware analysts who can
only donate stuff in sandboxes,
tremendous dynamic analysis or whatever.
Wouldn't it be cool if we could make
this patch stick to the executable? Well, we can.
All the debug has given us
that capability because all he is awesome.
But it is a little confusing about how to do it.
I'm just going to right-click anywhere in this pane.
Go to Edit, and go to
the bottom where it says Copy
all modifications to executable.
Or you can just say Copy to executable.
I want to say Copy all modifications.
It's going to pop up and says,
"Hey, what you did here is a bit different.
I'm going to arrange all the stuff from this executable,
and I'm going to put it up in a new window."
That's basically what it's saying.
I hit Okay, that's cool,
and this is the new window.
I'm going to right-click and just say "Save
file" it says, "Are you sure?"
Same thing. We have here, this new binary.
I can say blah, blah,
the hash value underscore patched.EXA.
Go to the folder.
Now we have our new binary right
here, underscore patched.
Now what, we should test.
I'm going to Add to archives,
make it a zip file,
and encrypted with the password infected.
Then I'm going to pull it off of my VM.
I pulled it off my VM,
and normally, I'd be a little more
careful about saving my files.
I would save my analysis that I've done or whatever.
But I'm just going to go ahead and revert it.
Now I've reverted my VM.
I'm going to delete these files,
drag over my file.
That's where it is infected.
I'm going to run Wireshark as I did before,
and execute capture byte,
and execute the original binary again.
Do it a few seconds,
hit Control C and get the log.
As we saw before,
our explorer executed the file and then it terminated.
Now normally I would say revert again, just to be sure.
But I'm just going to go ahead and capture that again,
and then run our patched version
and give it a few seconds.
I know that from looking at the code
manually that it used a lot of sleep functions,
usually with small intervals,
but it doesn't hurt to let it run for awhile.
I want to hit "Control C."
Look at the log, and there we go.
We see our Malware has done
quite a bit more than just start and die.
You explore, execute it.
Let's see. Well,
it's was just Explorer, so process created.
There's our process.
We see that it run itself.
We saw that in the code,
that creates a file and the temp directory,
something that bad, and it does other things with it.
Add some registry keys,
and goes about its business.
Now, that's plenty of information for our other guy,
the one who's doing dynamic analysis,
for him to go and figure out
what exactly just happened with this malware,
since dynamic analysis is a lot easier.
Stack analysis.
We can just go into our capture and we can see
what deleted files there were.
Yeah, I was wondering if that file got deleted.
This is interesting.
It tries to delete itself
>> after making a scheduled task.
>> That's interesting. Next,
I would just run Autoruns to see if it
actually maintained
any other persistence, scheduled tasks.
We happen to know that who's doing something with that.
It looks like Autoruns is having a problem.
It could be some more anti-tool code.
But I think we would have seen that.
But I happen to know that
this piece of malware does other things.
If you'd like to find out what those other things are,
then I'd suggest you go through
the process of reverse engineering it completely.
It's a good exercise.
A nice old piece of malware.
We just went through the demo of
reverse engineering a piece
of malware and then patching it,
so that it will go through dynamic analysis just fine.