>> Welcome to Cybrary. My name is Sean Pierce.
I'm a subject matter expert
for introduction to malware analysis.
Today we are going to be covering
more stack analysis, particularly Part 6,
where we're going to enumerate the capabilities of
the illusion bot that we were looking
at the last few videos.
When we were doing this capability enumeration earlier,
we were looking at
only the dynamic analysis and saying, okay,
well we see it's modifying
the registry and opening up the firewall rules,
we know it has that capability.
We know it's going to the IRC.
We know it can take commands from there.
We opened up the illusion Bot Builder.
We saw some other capabilities there.
But none of that actually means what it says it means.
I might sound a little silly,
but I've dealt with plenty of malware,
plenty of builders and controllers where there's
unimplemented functionality either in
the sample or in the builder or the controller,
where it may say it can communicate over HTTP or it may
say it can funnel traffic over DNS,
but it can't actually.
Maybe the malware author forgot to load
it in or he wanted to
say it had that capability but it actually didn't,
so he can sell it at a higher price.
Whatever the deal is, you really can't trust what
an interface says or
what it might even look like it's doing.
I've seen samples out there
that'll try to communicate over
HTTP or some other method and
the controller can't actually understand it.
It looks like it could do it,
but you can't take the word for it
or you can't count on that actually being there.
As malware analysts, we think, well,
we're not often going to get to the controller.
We're not often going to get the source code
or the builder,
so that's a moot point.
It's not because we do have the sample.
Earlier we were looking at
what functions it was calling
to guess at the functionality.
But we can actually dig down into the code and
see what the malware author has actually put in there.
We can say, okay, definitely for sure,
it makes a POST request,
but it doesn't do
anything with the response it gets back.
It just immediately moves on.
We know it can't
actually receive information from a GET request.
We can say that for sure.
Having said that, it
can be a little tricky sometimes especially
with the sophisticated actor
because assembly can be very tricky.
It can be hard to read and with a lot
of junk code in there because some malware authors will
fill their malware with
useless assembly that won't do
anything and it gets a little confusing to look at.
They can hide some clever instructions
strung together that
will dynamically call something that doesn't
look like code and do something you may not expect.
For instance, there was a piece of
malware that would download
a web page do a standard
HTTP GET request and it would
look for certain strings on
the web page and go on its business.
But a lot of malware analysts miss the fact
that it would go and find
an image later on that web page,
I think in the temporary Internet files and then it
would decrypt a hidden configuration inside an image.
They were using a form of stenography,
which means that they hide an image or that they hide
information as opposed to cryptography,
which just scrambles the information.
Inside this configuration, inside this image,
there was more information
that a lot of analysts were missing.
It can be tricky unless you have
a whole and complete understanding of the code,
which you really can't all the time.
There's even more functionality that may be
hidden in say a downloadable component.
We will look at this malware and we will find
that there is a download and execute command.
If you go to your
superior or if your superior comes to you and says,
"Hey, I know you analyzed this piece of malware.
Can it do something like wipe the master boot record?"
Having analyzed it, you can say no,
it doesn't have that capability,
and then turn around and
a few days later your boss comes back and says, "Hey,
that malware infected one of
our machines and the master boot record got wiped."
WTF. Well, in this executable,
in this piece of malware
like most other pieces of malware,
there's the ability to
>> download and execute other files.
>> While you can't say it doesn't
have that capability someone else
can easily add more capability
by downloading more malware.
Even if it's not, just download and execute the swiper,
which you can easily download
from all over the Internet,
several newer malware families
out there that are more sophisticated.
They're really malware platforms.
I've even done proof-of-concept stuff where basically,
it's just a platform
for going to a command and control server and
downloading an encrypted module
which has a persistence mechanism
or downloads another module after that,
which has a command
and control server functionality mechanism
or downloads another
>> component and that's an FTP server.
>> If a malware analyst were to
ever find my executable on disk,
they would just find this platform.
They would just find only a small amount of code which
would just go out to
an IP address and download
>> some things and decrypt them.
>> They would need my command and control server to
be up in order to get those components.
With luck, a lot of this malware tends to be more
targeted and the command and control servers
are quickly taken down.
The malware author thinks
that their operation was burned.
This is not uncommon,
especially with malware that has
been infecting a particular company.
If a malware author wants to
just do POS infections where point-of-sale
systems are only going to be within
a certain IP address range and he
restricts downloads of his malware
or component tree to that.
Then as soon as he sees another IP address,
try to get those components, he thinks,
well, they've put in my malware in a sandbox.
I'm bringing down the whole operation
and moving to another command
and control server and etc, etc.
That actually does happen.
If you ever do any botnet tracking,
where you get a piece of
spam and you say I wonder what this is.
You popped into a malware analysis machine.
You'll notice that the command and
control server is already
dead especially if you get
the piece of spam a few days
late or even a few hours late
sometimes because the malware authors
don't want to burn
their command and control infrastructure.
We can use both static and
>> dynamic analysis to enumerate
>> capabilities but you really shouldn't
say this malware only has these capabilities.
If you do, you should say,
hey, it can download and execute things.
It's a common function
and a high sophistication actor could be using
this lower sophistication tool as initial beachhead
to then download and execute
something else that's much more dangerous.
It's much more capable.
Determining intent is important and
people behind this but
when you're doing your malware analysis,
it's easy to say, look,
this code definitely won't
do this or it definitely does do this.
Having said that, let's jump right in to where we
last were which was,
we were decrypting the strings.
I'm going to pause this VM
right when it was decrypting the machine.
I'm going to put it away and
>> jump back to my either here.
>> As I said in my previous slide, document everything.
If I was being a good reverse engineer
and I had all day to work on this
and I wasn't just making a video,
I would say this would be my next step is to
go through these and label
them and properly document them.
One method to determine
capabilities of a piece of malware is to follow
each of these functions and see where they're
called and classify all of the function calls.
You could burn through each of
these subroutine calls and you can say this is this,
this is this, this is maybe this,
I'll come back to this if I have time, etc, etc.
But a better way to determine
capability is by going to
where the command processing happens,
where the configuration processing happens.
The malware author wants to control
a machine with this piece of malware or steal
data or whatever his goal is that you usually
will be able to determine after analyzing the malware.
He or she will want to
just be able to command this bot usually.
I'm going to go over here to Open
Subviews and then Strings
>> and I'm going to look for help.
>> I figure that this malware author has built-in
some help menu and
they will be controlling it from the IRC,
so they can just give it some commands
and that hasn't turned up anything.
I'm just going to look for,
expand this, go back Open the Subview to Strings.
>> I'm going to go through. I'm going to say,
they don't have a help menu or maybe it's encrypted or
whatever but I do know that it has some capabilities.
It can open something called a DCC shell.
It can download and execute something.
That's probably a command that
a malware author would want to remotely execute.
I'm going to double-click and jump
to where the string is.
I can see that it is referenced.
By pressing X, I can see that the string is
referenced at this location and only this location.
It looks like in this subroutine in this function,
there's the option to download and execute something.
Looks like KB is showing you
a meter of how
fast it's downloading and executing something.
We could dig into that and see exactly what's going on.
I'm going to say
>> download and execute subroutine.
>> Say display. Download and execute is fine.
I know this has to be called from somewhere because
this probably isn't the command processing subroutine
or the configuration process subroutine.
I'm going to say, it's probably called from
that or something it's calling
it that will call this eventually.
I'm going to climb on up this ladder and say,
this is calling a few things.
I can scroll over.
It's another function I haven't resolved yet,
but I could in fact,
looks like it's called a lot.
I'm just going to go ahead and help myself and say,
press "X" and say, want
to just go ahead and figure this out.
Was moved into by EAX.
EAX was last modified by GetProcAddress,
which was the perimeter
to get this GetProcAddress was wsprintf.
Going back to that logic.
Wsprintf is pushed onto
the stack where GetProcAddress was
called and modified EAX.
This is wsprintf. Jumping back.
We don't know, this is a good way to document.
Download and execute print.
You see where this is called from and Bingo.
Over in the lower left-hand side,
we can see that there's a lot of code here.
We can hit our Control key
and scroll wheel and we can zoom out.
We can get a much larger
>> picture of what's going on here.
>> We can see that there's a lot of stuff going on here.
We can Zoom in and see
a lot of error messages about socks,
proxies, FTP, all this other stuff.
That's cool. That's useful.
If we wanted to see usage HTTP flood,
we can just click where this code came from,
where this control flow came from.
We can just double-click the arrow.
It'll jump straight to where that line was leading,
that jump was coming from.
But I'm interested in
the capabilities of this malware, if you'll remember.
I want to quickly to be able to say, it can do this.
I want to look at the commands
that a malware author could give
it or the botnet herder or the controller.
If I look at this,
I take this broad view,
I can see that there's an interesting set of
instruction or an interesting
control flow happening here.
Where if it's not one thing,
then it'll do another little thing.
All these jumps, will
jump off into their own respective columns.
I'm willing to bet that
each one of these little boxes is simply just testing it.
You can see here by hovering over it.
Each of these little columns is testing to see if
a certain string is in a certain memory location.
Probably it gets in a string from the IRC program.
This is probably wild true or
wild not kill yourself command loop is going on.
It is constantly checking to see
which command it received on the command line.
I can quickly zoom in and see if that's the case.
We can say, beep it's like,
that might sound like a command.
Jump over here and say FTP stop.
That does sound like a command.
Jump over here, FTD sounds like a command.
Stop all, that definitely sounds like
a command and do another jumps, socks 5 stopped.
This seems like this command tree.
If I were a betting man I would say,
this is probably a switch statement.
But then again, I usually
catches switch statements pretty easily.
Maybe it's just if else,
situation. It doesn't really matter.
We have a list of functions here.
If I were documenting everything,
I would keep a notepad open.
I'm following these functions down to the end.
I can hit "Escape" and jump back to where I was.
I can see here web admin,
just above it is IRC admin and just above that
is IRC admin again.
That seems to be all
for the commands, at least right here.
I would open up
notepad and I just start copy and pasting.
Another thing I would do, I would see where
the string is kept and see
if all the other commands
strings were there so it means we just copy paste.
It looks like a lot of them were there,
but I can't guarantee you that they're going to be
in the proper order. See that?
>> IGMP exploit. That sounds interesting.
Config, that sounds interesting in case
we got onto the IRC channel where this bot is hiding.
Maybe we can reconfigure the bots.
I think technically that would be illegal
because you are still running
instructions on a machine which you have
not been authorized to run instructions on.
But some security researchers do it anyway.
Some people like from
Microsoft go and when they take down a botnet,
they will get law enforcement
on their side and walk into a data center and say,
"Hey, this is used for criminal use.
We are going to help shut it down."
But I'm not one of those people.
Even if you have good intentions,
I would not suggest going onto
a IRC channel bot and trying to take down the botnet.
Even if you have the best intentions in mind
and you're seeing bad stuff
happen all the time with his botnet,
there could be security researchers or
law enforcement also doing what you're doing.
But they're listening on the channel to see if they
can get to the author or
the botnet herder or whatever
else because they will do that as well.
I can do this for a while.
It looks like this bot supports a lot of commands.
After I'm done with this,
I could tell someone or do it
myself for verification purposes.
I could tell someone to run
>> these commands and make sure
>> they actually do what you would think they do this.
Ftpd command might start an FTP server,
but it might only do it on Linux.
D is usually daemon or daemon.
Maybe it runs better on Linux.
You might think, "Well,
it's a PE file an EXE file.
What makes you think you would run
an FTP server on Linux?"
It's like, well,
with a source code, you can recompile
a piece of malware like in the other program.
Author made it so
that you can just easily recompile for Linux
and that functionality doesn't exist on Windows because
it may just call
the command-line equivalent to start an FTP server,
which may not exist on newer version of Windows.
Like I said, we can do this for a while
and it would be a much better indicator
of capabilities than just
looking at the functions and guessing.
If we had help, we
could pass these things over to someone and say,
"Hey, while I'm doing this,
fire up the bot,
make a fake IRC channel, connect to it,
and just start running
these commands and see what happens."
A lot of the stuff
is pretty common malware functionality.
I might dig into it a little
bit like this inversion function.
I would say, so
this function gets called immediately after it.
What happens there? Is there anything important?
Does it just set some flags?
Does it check to see if there's some information?
Does it just return the version?
What happens on it's
not zero loop if it doesn't take that condition?
It looks like it just prints something.
It's like this condition
probably will print the version
>> number out to the screen.
>> If it takes this path, it tries to see if this
variable which I'm going to just name right
here as input command.
Say nick, I'll filter out
the quotes later, reconnect. That's interesting.
Shut down. That's interesting.
I can see it has nowhere to go.
I'll just name this with the N key,
shut down, command.
Whether that shuts down the bot or if it shuts down
the computer, I don't know.
Icmpfloodstop, Icmpflood.
I'm going to stop for
now and we can see where we are on this graph.
We can see that we're probably right about there or
probably right about here.
I'm going to say 10, 15
other commands that we could enumerate.
We've got quite a ways to go.
The important part is that we can do it.
Furthermore, we can verify
that the code actually exist to implement
that functionality or the implemented code
is there to fulfill that capability.
If you're looking at this, if you're
reading this all day,
it's a very detailed view and it's
easy to get lost and forget things.
IDA provides a pretty cool tool.
Let's take this column for instance.
It says kill.
Test the input command against the string
kill and it'll call this function,
which looks very simple.
We can dive into it for just a second.
It seems to test something,
two arguments that are passed into it which
is an ECX and EDX.
It's probably testing for validity.
It's probably testing to
make sure they're not just empty strings.
If we do x, it seems like it's
called all over the place.
It's probably important that we get
this analysis out of the way.
It takes in two strings which were EAX,
the input command, and a kill.
I'm going to call this string compare.
It does a pop do you see that?
If we look at string compare, if we google that,
I'm willing to bet if we return zero,
it's the same string.
Or the strings have
the equivalent characters until the first null byte.
I just happen to know that's
>> true because I've done this
>> before and the output is put into EAX.
Test instruction, test to see if EAX is
zero by saying EAX pop.
It jumps if it's not zero.
It continues on it's path of checking against
other commands if it is not zero.
If it is zero, it is that command,
so this logic makes a bit more sense here.
The functionality that I was telling you
that IDA does that's really cool is,
we know that this code eventually will
have a process killing
functionality built into it.
We can see here that I'm able
to kill the process with the process ID.
Process has been killed.
We can see that there's a positive and a negative to
this outcome so we know
>> what this code does. Fairly sure.
>> Something cool that we can do to get out of
the way while we're still reversing these other things,
is we hold down control and we
can select these boxes here.
We can right-click and say group nodes.
We can label it for kill process.
All these are code blocks.
Let's include this here.
Same name, kill process.
That looks pretty clean.
We can continue the same effort here.
We can look at this command above it, kill all.
We can keep going down that path.
>> Obviously, we're not catching
all the related blocks because
>> if you'll look down here,
>> there's some error conditions like,
"Oh, you didn't pass in the parameter."
This is the usage for that thing and "Oh,
unable to do it, " or "Oh, it worked."
We could group these in as well.
We can continue on this path until we
have all of these trees,
these command functionality columns, accounted for.
If we find something that's out of the
ordinary or something that doesn't make a lot of sense,
we can investigate that further.
But we can effectively group things and we don't have
such a detailed view
of what every little instruction is doing.
That's really the rabbit hole that you'll get into
when you're doing reverse engineering,
since you have such a detailed view and you can say,
"Oh, yeah, I can jump into this function.
I can completely figure
out what it's supposed to be doing and it's
really important because it's called
by all these other things.
Oh look, I can go and resolve it
again and see exactly what's going on."
It's great, but for now, determining capability.
Capability will lead to risk to your organization,
it will lead to impact,
and maybe if you're good,
it'll lead to attribution to intent,
and it will lead to you being
>> very valuable to your team.
>> Because if you have an incident,
unless your IR guy is really clever,
the malware guy is the person
that really understands what's
going on behind the scenes.
There is a trend that a lot of
bad guys are trying to avoid malware because of this.
They try to do what's called living
off the land and only doing
things that don't leave any forensic evidence,
like they drop a piece of malware
that just launches a reverse command shell.
Then they can execute
>> commands without anyone seen that.
>> But, most hackers still use
malwares and all of the
>> breaches 97 percent of the time.
>> I believe the rise in breach report
said malware was present.
Malware analysts definitely have
a job and they are definitely needed.
We went over finding
the command processing subroutines and/or
the configuration processing subroutines
because that's where you're going to find
a lot of how you can enumerate
a lot of the capabilities of a piece of malware.
While reversing, I would
>> suggest documenting everything.
>> Use good variable names,
just like as if you're writing software.
Because you're taking it apart, you're discovering it.
To fully enumerate capabilities,
I would say test the software afterwards.
As I mentioned, there are plenty
of times where malware has
had bugs or compatibility issues,
or they simply just
do not implement the functionality as they say they do.
Keep in mind, when you're enumerating functionality,
malware can extend its own
>> functionality by downloading,
>> executing new code,
or having some hidden feature in it that you might miss.
All those function call
all hundreds or thousands of function calls.
There could be just some instructions in there that
jump into what appears to be
data but is actually shellcode.
Even strings. Strings can be shellcode,
they can be executable x86 machine code.
I know a guy who published a black hat paper
over generating his program would write
English language shellcode so
>> that string that look like
>> a normal English string could
be executable x86 shellcode.
While you can enumerate
functionality in malware a lot of times,
keep in mind, that it can extend
its functionality and it's not a for sure thing.
Keep in mind, there's no undo in IDA.
You might be flabbergasted by that.
But seriously, if I were
to tell IDA to analyze something as data and step code,
it would break a lot of things.
In the newer versions of IDA,
you can do a snapshot of your current IDA database.
That might save you from something catastrophic,
but you might have to redo a lot of analysis.
I have messed up. My house is pretty good sometimes.
I just had to start over
because it would have been too much of a pain
to try to fix the damage I had done.
As a recap in general,
static reverse engineering, I showed this before,
but I highly suggest the IDA Pro book,
that's the unofficial version because
the developers of IDA they're
good and brilliant and they'll
respond to email very quickly.
Because they're the only,
IDA that's all they do.
If you email, they email right back,
and they're really nice and good.
They never wrote a book about how to use it.
Someone did and it's actually
>> a really good introduction
>> to not just IDA but reverse engineering in general.
Because IDA is an extremely powerful tool
and we've barely scratched the surface
of what it's capable of.
If you get the, I will want to say
>> professional version,
>> but it's actually the paid-for version
because IDA Pro is this free by default,
you can't save your analysis unless you use
an older version IDA 5 point something,
you can actually save your analysis, your IDB file.
In the newer version, you cannot
save your analysis unless you pay for it.
That's like $6,700 or something.
Do not try to crack it or torrent it.
You will be put on
a blacklist and they will never
>> sell your software again.
>> Or I think when you work for IDA,
I don't remember the rules on that,
but it's a big no. Don't do that.
Don't crack IDA,
or download, or use cracked copies.
Because the IDB files are
actually signed/encrypted, I think.
If you get a version,
a cracked version of IDA,
and you save your analysis,
your disassembly of a file,
no one else with IDA can even open that.
Because that cracked version will be
blacklisted and no other version of IDA can open it.
There are ways around it, but I wouldn't suggest it.
Another really good book for
reverse engineering is Reversing
Secrets of Reverse Engineering,
is a bit old, but it's really good. I like it a lot.
There's plenty of tutorials online out
there for reverse engineering,
a lot of tutorials and
little things are mainly built around the crack means,
which are little programs written
by reverse engineer enthusiasts to stump each other.
Those are pretty good and I also would suggest
going to past CTF websites,
Capture the Flag websites,
usually they're hacker competitions, jeopardy style,
where they choose a category and
a level and they go and try to solve the problem.
There's usually reverse
>> engineering challenges in there.
>> Where you're trying to
get a program to do something or find a vulnerability,
your decrypted string,
or whatever the case is.
Those can be excellent learning experiences.
Corkami, this website
is fantastic for explaining PE headers.
It really takes it apart and goes through the binary.
If you really want to understand
how the code is organized,
when you're looking at it, I
would definitely suggest that.
But honestly, it's not very
necessary until you get
into some of the more tricky stuff.
I would also suggest
opensecuritytraining.info from my miter.
They have an intro to x86.
They also dive into
other architectures like ARM and x64,
which if you get the paid-for version of IDA,
will actually not just do x86
but they'll do tons of architectures.
The most popular one being x64 and ARM,
because a lot of reverse engineers don't just
reverse engineer Windows executables.
Reverse engineer firmware from routers, from toys,
from cell phones, switches,
lots of computers that
most people don't think of as computers.
Also just say, it's good to read
the Wikipedia entries for
the x86 assembly language and
the x86 calling conventions.
They're very approachable,
they're very easy to read,
and have lots of examples.
If you really want to get into
>> writing assembly language,
>> I would suggest the Art of Assembly Language.
Other than that, that's
plenty of information for you to get started.
Hope you watch the next video.
Again, my name is Sean, and I'll catch you later.