FORENSIC
ANALYSIS OF MALCODE - STEP BY STEP
This paper is the work of The Master Jedi Pimpsor AKA
thehorse13, who has kindly consented to it being hosted here on the
TAZ.
The original post can be found here:
http://www.antionline.com/showthread.php?s=&threadid=272469&perpage=10&pagenumber=1
Overview: (Please Read)
=+=+=+=+=+=+=+=+=+=+=+=+=+
As many of you venture into a pervasive computing environment, it will
not be long before
you will be faced with a situation where forensics will be needed. This
is an upcoming, and
in my opinion, will be the hottest area of security. If you’re one to
chase the big bucks and
you want to stay in the technology track, then this is the route for
you. Otherwise, go off
and write documentation for all of the new regulations. That too is hot
and returning hefty salaries.
I’m going to step you through the process of dissecting a malcode
sample using tools and
techniques that are commonly used by forensic teams. Keep in mind that
at the time of
this writing there are no set standards in forensics. This means that
you may find other
forensic teams doing things differently but rest assured that the
techniques I’m about to
show you are used by the top minds in the discipline, including myself.
Throughout this tutorial, all operations will be done in a 6 gig
Windows 2000 professional
VM environment. The OS is fully patched and there are no antivirus
scanners or firewalls
running (A virgin installation). The VM does have network connectivity
and the network it
sits on is VLANed into a network segment that only has internet access
upon manual
activation. There are no routes to production or other lab
environments. In other words, it’s
in complete isolation from areas where it could cause harm.
Typically you want to use a VM instance to conduct your initial testing
of the code or any
other host that you can reformat or otherwise abuse for the purposes of
analysis without
affecting production hosts/environments. I use VMs because when a
problem crops up I
can simply regenerate a fresh image in seconds instead of hours if I
had to do a fresh
install. The point here is to have a controlled throw away environment
to conduct your
examination.
This tutorial is limited to one very small part of forensics. If this
tutorial proves valuable
based on feedback, I will move on to other situations/techniques such
as scraping data
from a hard drive to establish what users have done on the host
including attempts to
remove traces of their activities, what disposable media was used on
the host, etc.
Network forensics is another area I can touch on but would require me
to write a book to be
thorough.
One last thing. Because I don’t want to attach images and such to the
thread, I’ve decided
to describe what I can without screenshots. I will insert text where I
can but things should be relatively clear. If not, PM me
and I will put together a screen shot library for you.
Our Malcode: hax0r.exe
=+=+=+=+=+=+=+=+=+=+=+=+=+
You find a piece of malcode on a host. No antivirus company knows what
it is and you want
more information about it.
TIP: Norman Sandbox: http://sandbox.norman.no/live_4.html Is a place
where
malcode is run in a sandbox and the results are returned to you. I use
this for quick and
dirty analysis. All you do is upload a sample and it maps out what the
malcode does. This
can be very helpful in a zero day scenario. As we will see, this method
may not always
work for you.
Let’s begin by doing a tool inventory. Whenever you’re going to do an
examination of code,
you’re going to need a few base tools.
a) A good hex editor. I use OllyDbg (Free) or if you have a few
thousand dollars, SoftICE will
be an excellent selection.
b) A Strings program. Strings.exe on Win32 is not native. You’ll have
to grab a third party
tool such as strings.exe (command line) or BinText (Win32 GUI). Both
are free and do the
same thing.
c) A Win32 Portable EXE identifier. A key part of analysis will be to
identify what packer was
used to compress an EXE. If you cannot identify the packer, you’ll be
forced to actually run
the malcode to see what it does. This isn’t necessarily a problem but
for this tutorial, we’re
going to want to identify the packer. I use PEiD for identification.
Again, a free tool found
here: http://peid.has.it/
d) Once we ID the packer, we’ll need to unpack it. UnFSG and Procdump
will be needed for
this case. Both are free.
e) A program to monitor changes to your environment. I use install
watch pro. http://www.epsilonsquared.com/installwatch.htm
TIP: There are hundreds of PE packers out there. You may not always be
able to unpack
them and will be forced to try to run the malcode to see what it does.
For a list of PE
packers, see: http://www.exetools.com/compressors.htm. Note that the
site also
has a bunch of unpackers as well. Depending upon successful
identification of the packer,
you may be able to use one of them to unpack the malcode.
OK, so here we go.
1) Using strings.exe, I first determine if the exe is compressed with a
Win32 packer. Typically, you will see
short bursts of 4 or so random characters and maybe a line or two of
text if it is packaged/encrypted. Once you’ve seen a few packaged exe
files you’ll quickly be
able to tell when an exe is packaged or not. Even if you fail to do so,
OllyDBG will throw a
warning up if it detects that the exe is packaged/encrypted.
First let’s look at an example of a non packaged exe: sid2user.exe.
This is totally random. I
chose it simply because I had it in the same folder as my strings
executable.
code:--------------------------------------------------------------------------------
c:\temp\strings.exe sid2user.exe
string:utofrange
Borland C++ - Copyright 19
Evgenii Rudnyi (C) All rig
Chemistry Department, Mosc
119899 Moscow, Russia, htt
rudnyi@comp.chem.msu.su
This utility is freeware a
distribute it. Optionally,
you may send me a bottle o
Disclaimer of warranty:
This utility is supplied a
express or implied, includ
merchantability and of fit
no liability for damages d
the use of this utility.
The goal of the utility is
sid2user [\\computer_name]
where computer_name is opt
sid2user 5 32 544
By default, the search sta
could not allocate SID
Name is
Domain is
Type of SID is
SidTypeUser
SidTypeGroup
SidTypeDomain
SidTypeAlias
SidTypeWellKnownGroup
SidTypeDeletedAccount
SidTypeInvalid
SidTypeUnknown
LookupSidName failed - no
<notype>
**BCCxh1
__GetExceptDLLinfo
Stack Overflow!
Error 0
Invalid function number
No such file or directory
Path not found
Too many open files
Permission denied
Bad file number
C:\temp>
--------------------------------------------------------------------------------
As you can see, strings can be helpful in identifying potential help or
avenues of
investigation against standard output statements. Notice lots of plain
text and system error
syntax.
And now, here is what a packaged exe looks like: hax0r.exe.
code:--------------------------------------------------------------------------------
c:\temp>strings.exe hax0r.exe
.text
.idata
hvGz)
f?m+1
$;9C8
K(~C,
[k{XA0CI-tz
n4?z+
QIY
QP@XY
=n p>+
Q1,$]Yu
C:\temp>
--------------------------------------------------------------------------------
So as you can see, spotting a packaged exe is pretty easy. Now we have
to figure out what
the exe is packed with. Let’s open hax0r.exe in PEiD and see what it
has to say.
NOTE: This is where a screen shot would be nice but instead, I will
give you simple steps to
perform.
code:--------------------------------------------------------------------------------
1) Open PEiD
2) Browse to the hax0r.exe file
3) Look at the bottom of the dialog box to see the packager. In our
case, it shows FSG,
which is a acronym for Fast, Simple, Good. There is other info returned
about the file such
as entry point, offset, first bytes, etc. These values are important
but will not play heavily
in this tutorial.
--------------------------------------------------------------------------------
TIP: Evil mean haxors will repackage their malcode with different
packers as soon as they
discover that anti virus companies have a signature out for it. It is
not uncommon to see
the same malcode show up with 20 or 30 different hash values. This is
done to beat AV
signatures
OK, so we now know that our hax0r.exe malcode is packed with FSG. It is
useless to us
until we unpack it. This is where UnFSG comes in.
code:--------------------------------------------------------------------------------
1) Open UnFSG
2) Select the file to “UnFSG”
3) Tell it where to write the file.
--------------------------------------------------------------------------------
OK, so now we have a good unpacked copy right? Wrong. During the
unpack, damage is
done to the PE headers and tables and we need to fix that before going
forward. Procdump
will do this for you.
code:--------------------------------------------------------------------------------
1) Open procdump
2) Select the file to fix
3) Select a place to write the file.
--------------------------------------------------------------------------------
NOTE: There is a command line and GUI version of this tool. The
commands vary slightly on
each.
OK, we now have a unpacked malcode executable that we can run. OH NO!
The malcode is
password protected. What ever will I do?
TIP: Sometimes malcode is password protected so that only the C&C
master can run it.
This is the case in our example. Also, some malcode is very advanced
and can detect when
it’s being run in a hex editor such as OllyDBG and will crash the
system. Be aware of this
because it’s not your PC or software, it’s done by design of the
malcode author.
OK folks, time to break open this malcode to find the embedded
password. Incidentally, the
technique I’m about to show you is close to that used when stripping
license info out of
commercial software. Please don’t abuse this knowledge.
code:--------------------------------------------------------------------------------
1) In the OllyDBG main window, select F9 or select debug-run from the
main menu.
2) The malcode executes and we see a “Enter password” prompt at the
command prompt.
Since we know that “Enter password” was displayed, we can now go to the
OllyDBG stack
history window and search for this term. This window is in the bottom
right of the display.
3) A reference to the string was found at 0x00304052A71. Double click
this value and you
be taken to this address in the main thread window.
4) Set a breakpoint (this is as much art as it is science at times)
about ten lines below
which is where it will break right before the password is entered. To
do this simply right
click the line and choose, set break point. It will then turn red.
5) Now, go to the command prompt and enter any old password. I’ll enter
“dummy” and
press enter.
6) Press F7 a few times to step through some instructions. Keep an eye
on the
Examination of registers window in the top right side of the display.
Soon you will see:
EAX 0012FB6D ASCII “j00arenotl33t”
ESI 0012FB8C ASCII “dummy”
Examination of the registers have yielded the password comparison and
shows that the
password to the malcode is j00arenotl33t.
--------------------------------------------------------------------------------
Anyway, that’s how you can easily discover passwords in any kind of
password protected
application. Be aware that malcode writers do not want you to do this
so they will go to
great length to keep you from unpacking their malcode.
I now turn on a free application called install watch pro. This will
trace everything that the
malcode does in my environment. To use this app, install it, open it
and simply start
the “record session” process. It’s a GUI tool and is VERY simple. Once
you turn on the
record feature (which is simply a snapshot of the current system) you
open the malcode
from within the install watch pro interface. I then records everything
and exports it in
several formats for your enjoyment.
I now examine the output from install watch pro. I see several
references in there that
execute netcat shell commands. BINGO.
OK, so what I see is that my malcode is a password protected NetCat
shell that shovels a
terminal back to the attacker. This is a very simple example of a
malcode payload. There
are many out there that obviously do much more complex things. This is
for educational
purposes to get the mechanics down for performing the actual analysis.
Anyway, I hope you found this informative. Again, if feedback is good,
I will do other
forensic tutorials. As always, comments good or bad are always welcome.
Original Tutorial
Submitted by nokia for TheTAZZone-TAZForum
Originally posted on March 5th, 2006 here
Do not use, republish, in whole or in part, without the consent of
the Author. TheTAZZone policy is that Authors retain the rights to the
work they submit and/or post...we do not sell, publish, transmit, or
have the right to give permission for such...TheTAZZone merely retains
the right to use, retain, and publish submitted work within it's
Network.