>> Welcome to the Cybrary. My name is Sean Pierce.
I'm the subject matter expert for
introduction to malware analysis.
Today we are going to be going over the basics
of static analysis part 5,
more on the basic malware tricks.
Last time we were talking about
Obfuscated Strings and I said
I was going to show an easy way to deal with them.
The hard way is to fully reverse engineer the code,
really understand what's going on,
and then re-implement it to write
your own Python or assembly code to do the same process
to those strings you want to deobfuscate
and if you are rewriting
>> the assembly code just for fun,
>> and I have done that before,
you start to feel like you can just copy and
paste most of it and then you start thinking,
well, why can't I just run
the code and you can't and that is the easy way.
To use the native code and the malware to
do the deobfuscation because they have to do it right.
Anyways, it's unlikely that they
have some super tricky code doing
something crazy during the
>> deobfuscation of some string.
>> We're going to look at this.
Last time we were here,
we were looking at
this decrypt string function that we had named.
We don't know for sure if it's doing
that but it looks pretty obvious that
it is and we started to look at this and we said,
okay, maybe it's not really encryption.
Encryption is more like some
>> encoding but whatever it is,
>> it's obfuscating these strings
so that we can't easily see it.
We could right-click and run our little strings
command and whatever these
are going to be won't show
up so that's why malware authors do it.
We can jump over to where we last had
our VM and we can see the bot builder is
right here but we're interested in
the spine area and I haven't
modified the binary in any way
and I'm just going to right-click here
and say extract a ladybug 2.0.
1.1 is still pretty popular.
2.0 has some improvements but a lot of plugins still
work with 2.0 or excuse me.
A lot of plugins still work with 1.1.
We're just going to start executing.
Before I execute, I always check
the network settings to make sure it's not connected,
it is connected but a host-only network
can't go anywhere.
I'm going to drag and drop this sample
onto Ali and Ali will begin executing it.
It'll load up the libraries which is
what that loading was and it
will analyze them just like it analyzed
this bit of code and
I'm going to make this a little more readable.
Options. The default appearance is terminal 6,
and code highlighting, Christmas tree.
I'd like to pay attention to jumps and calls.
Let's try that out. Didn't really help much.
Want to make it more readable for people.
Slow screen resolution.
Six, change.
That's easier to read.
Even if we are a little scrunched up.
Ali debugger that will
execute one instruction at a
time and will by default break
on the module that you've loaded.
The module, it's in the PE file
and that's where it is right now
and we can see that this memory address here,
that's the memory where this executable said,
I prefer to be loaded at this address
and that's encoded in the PE header,
the container for the EXE file and IDA also
looks at that and also tries to
do its addressing in a similar manner.
We can use that to our advantage.
We press Space here and we can get more an older type
of view where it's just a linear view of
the code and we can go here
where we see this perimeter
of this obfuscated string being
pushed and we see it's at this address that's in
the text section and we can flip back over to Ali.
Where is Ali? Of course.
I can hit Control G for go and I can say,
just paste that address and say zero x
because it's a hex address and jump straight there.
We want the code to execute and to this location.
Most of the time, F2 will
just put a software break-point
there and I've mentioned them before.
I've mentioned that it's actually an int three
or the hex CC where it goes,
where as soon as I hit F2 hear,
it went into that address
and changed out the instruction.
Some malware will look for this and
attempt to do something strange
if it found a break-point there.
A better way to do it is by using hardware breakpoints.
We can do that here.
I can find a
break-point
and we can say hardware break-point upon execution.
Hardware breakpoints are a bit different in
that there is no changing of the instruction.
The malware can't see that the code is changed at all
because it hasn't but instead, this address,
this 131453A0 address, was put inside
the CPU and the Ali debug said,
whenever this address is executed,
just stop the program right
there and hand control back over to me.
The three software break-point
except we're not actually
changing the code. It's a bit better.
The gatches, there's
only four hardware breakpoints in the CPU.
It can only hold four addresses.
There's actually I think eight debug registers
but I think we can only use four of them at
a time. I'm going to hit run.
My program will run to this and it stopped here.
You may be wondering what's going on down here
and it says it's analyzing this and that.
You'll remember it can flip back over to our data here.
Remember, up here,
to resolve all the functions down here I had to
load in several libraries, so blurred.
I got the address to NTDLO because
NTDLO has always loaded into every single process.
I don't think it's possible not to have it in there.
It alerted and this and
whatever the dependency DLLs were to those DLLs.
As soon as they were loaded in,
Ali started to analyze them
just in case we want to jump into one of
those DLL but the end result
is the break-point triggered
and it stopped at this location.
With Ali, we can see that it's going to push,
push, do a move,
and then a call and that
call is with what we named decrypt an IDA.
>> We see Redkey delete
that was clean up from the last function.
See how much easier it is to read it and
all that which key deletes would be from there.
I want to do Dynamic Analysis with [inaudible] and then
stack analysis with IDA.
We can do a push
and then over on the lower right-hand side,
we have this stack window.
The top of the stack is the top of this Window.
The lower memory address is up here.
If that makes any sense.
If it doesn't quite make sense,
it's okay, just play with it
a bit more and get the hang of it.
But it is important, as we saw
with the beginning of this executable,
it manipulated the stack to use
a return function or a return instruction to jump
to its real main code as opposed
to just a jumper or call
instruction as an effort to fool these assemblers.
But I didn't catch that pretty fast.
There's some older malware.
Anyways, so we saw that
it's about to push another argument onto the stack.
If we flip back over to IDA,
we see that this is
referenced a few other places
that is pushed in as a primary here,
and the address is moved into an EAX here and ESI here,
and another EAX here and some different functions.
We could dive into those and try to figure out what
exactly is going on here or where this thing came from.
But I'm willing to bet,
since there's two things going
into this decryption function,
and it doesn't look like EAX is messed with,
or modified, or stored anywhere else.
I would say this is an input
and this is actually an output.
It's handing in an address
where right now it's filled with
all zeros and later is
probably going to be filled with the decrypted address.
I don't know for sure, but with ALI we can find out.
I'd like to right-click and say,
"Follow and Dump" right here.
I want to say Immediate Constant.
It looks at the constant in this instruction,
and so it's okay, that's an address and I
say just go to that address.
We could try to figure out where exactly it is,
either in the text section or the resource section,
or if it's in the heap or whatever.
But right now it doesn't really matter to me.
I just want to see what happens.
I'm going to say step over,
it's going to do that move.
Then now we're on the call instruction.
I'm just going to say step over again.
If I want to say step in,
we could actually go through the decryption process.
But [LAUGHTER] we see here
that we just stepped over and boom,
out pops this string.
We can even see up here that ALI
has looked at that reference again and said,
"This is not change, this is now an ASCII string."
We now know that this string was a few skated,
and it was easily just df few skated.
We don't know the algorithm,
but we don't really care.
We have this, which is what we wanted.
We can take
that copy
somewhere.
It's a little trickier with
list because sometimes you just want to copy the hex,
sometimes you just want to copy the memory address,
sometimes you just want to copy the string.
I need a copy.
I'm going to try that.
Moped, but didn't really work.
I'm just going to open up IDA.
We can say this string.
We can hit "N" to rename the string.
Falling out of convention when we
start an ASCII string with A,
and we're going to say software
Microsoft Windows
T/current fashion/on sole/namespace.
These characters are probably illegal with IDA naming.
I have to replace the slashes with underscores.
That's a register key. I'm going to say registry key,
it's going to complain that it's a bit long and it's
got to make the columns a bit longer.
But there's some illegal character.
The bad character is,
I don't know. Maybe a space.
I don't know. We can continue this process.
We can see that passes on
another parameter because
>> it's calling the same function,
>> it's probably under the same thing and there's
another registry key that has just come out,
and we can do the same thing.
There's another path that looks like
some file, 0XDEAD.DMP.
Can do that. Another ASCII string of salt.
We can see in here,
in the same memory space,
memory location that all the strings
were allocated next to each other.
This function is not supported by
Windows 9x. That's interesting.
If we were fully reversing this malware,
and we knew we're going to spend a whole day on it,
I would say record everything,
take down everything and really document it,
because documenting is the key
to really understanding how malware works.
Even if it's documenting
something that you don't think is
very important because you've
gone through the trouble of finding that out,
and it couldn't become helpful later.
Bookmarks are also very useful,
but I haven't put them here yet.
This function, or it was 0XDEAD-DMP.
That's the easy way of going about decrypting strings.
If you play with IDA a lot,
and you seem to be doing this a lot,
then I would suggest a plug-in put out by fire,
I believe, because they do a lot of
>> reverse engineering,
>> and it basically uses
the debugging component of IDA
and when you select a function,
you can just say run
this function with these parameters,
and it'll automatically decrypt something for you.
Of course, this is dangerous if
you're running real malware system.
But most decryption functions do just that,
just encryption because
a malware author had to make this,
and he had to make it modular and functional for him
or her to be keep track
of logically separating out functionality.
It's uncommon that a decryption function
would do anything else but decryption,
but it is possible.
I would err on the side of caution and if you want to,
you can run IDA inside your debugger or inside
a VM and just be cautious.
That's it for this video.
Once again, we were dealing with
obfuscated strings and instead
of reverse engineering the code,
we use a hybrid analysis,
leveraging both static and dynamic techniques to
very quickly DFT escaped
strings and aid in our analysis further.
If I were you, I would check into where else
that 0XDEAD.DMP file was being
referenced and see if that is a mechanism I wish
and our author used to avoid infecting themselves.
Sometimes, that is the case.
Our authors usually keep something in
their code to keep from infecting themselves.
Be it a registry key or something else,
filename, process name, a machine name.
These are indicators of not compromise, but authorship,
because malware authors will frequently use
the same file names over and
over again across different malware families.
Thanks for watching. Next class we'll be
covering more static analysis,
where we will be going through and enumerating
the capabilities of the malware.
>> I hope to see you then.