Forensic Analysis of Malcode - Step by Step
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::outofrange
Borland C++ - Copyright 19
Evgenii Rudnyi (C) All rig
Chemistry Department, Mosc
119899 Moscow, Russia, htt
[email protected]
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.
Re: Forensic Analysis of Malcode - Step by Step
ollydbg and SoftICE are not hex editors! these are debuggers!
an example of a hex editor is hex workshop or hiew. these can be used to display and edit the raw hexadecimal code of a binary
a debugger is a program that executes a binary and allows dynamic analysis of the code by displaying the disassembly of the code as it executes. debuggers also typically allow 'single-stepping' through the instructions, as well as the setting of breakpoints on parts of the code where execution is stopped and the state of the debugged program is frozen for analysis or manipulation. softice is a kernel-mode or ring 0 debugger which means it can be used to trace low level kernel-mode code such as device drivers. ollydbg is a user-mode or ring 3 debugger, and is limited to user-mode code. it does however enjoy more features of the underlying operating system and hence has a superior windowed user interface. (softice is expensive commerical software from Compuware, ollydbg is free open-source software by a single guy called Oleh Yuschuk!)
typically a disassembler is used in the analysis of a malware binary - this is a lot more powerful than relying on a strings output, although the strings are useful. (to understand the disassembled binary one must of course understand assembly.) the best example of a disassembler is IDA Pro - however this software is also very expensive (but there is a free limited evaluation available from Datarescue)
it is really to enable disassembly and other static analysis than one might bother to unpack a packed binary - not for dynamic analysis! as there really is little point in unpacking an exe and rebuilding the headers & imports just to run it anyway! all the dynamic analysis can be done on the packed sample (since the packer must first unpack 'itself' before the packed code can be run!) and the unpacked code can be traced in a debugger...
...unless the packer (or malware) detects the debugger ... this is known as armour. however with suitable knowledge or armour techniques these can be circumvented to enable tracing/disable detection... alternatively there are programs or plugins for softice and olly that protect the debugger from detection in some cases
it is not really accurate to suggest that malware is even sometimes password-protected so only the "C&C master can run it". it is not in the interests of malware authors to prevent use or even prompt a user for credentials when running their malware (it is usually desired that the code execute in a covert fashion). perhaps this is more applicable to software protection for shareware or evaluation software... however since it is illegal to reverse engineer or 'crack' software protection schemes we best leave that topic alone...
another useful tool in dynamic analysis is a tool which traces API (or system) calls. A lot can be learnt from reading the sequence of API calls with knowledge of what the functions do (the Win32 API is of course documented at MSDN http://msdn.microsoft.com/) there are a few publicly-available such tools on the web, searching for 'strace' or 'apispy' may show up a few
anti-virus vendors are now typically able to pro-actively detect a given malware variant despite it being packed differently or having a differing checksum. even completely new variants can be detected by such 'generic' detection. this detection is usually based on common sequences of API calls or strings in the malware. this is done statically so of course unpacking is required first - modern anti-virus engines are also typically adept at unpacking too.
