ORIGINALLY POSTED BY NOKIA FOR THETAZZONE/TAZFORUM 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
- Code: Select all
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:
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
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
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:
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
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
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.
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
. 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.
Borland C++ – Copyright 19
Evgenii Rudnyi (C) All rig
Chemistry Department, Mosc
119899 Moscow, Russia, htt
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
where computer_name is opt
sid2user 5 32 544
By default, the search sta
could not allocate SID
Type of SID is
LookupSidName failed – no
Invalid function number
No such file or directory
Path not found
Too many open files
Bad file number
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
And now, here is what a packaged exe looks like: hax0r.exe.
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
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
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.
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.
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
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.
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
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.