Blog

This week I'm going to demonstrate the analysis of a simple Trojan.Downloader.

I'm going to show from start to finish, the unpacking process and static and dynamic analysis phase that I use for categorization of a malicious binary.

For the purpose of demonstration, each time I do an "malcode of the week analysis" I'm going to attempt to use a different set of tools in order to give the readers of this blog some variety in examples of toolsets available for malware analysis.

This week I'm going to use:

• PEiD (http://PEiD.has.it)
• IDA Pro 5 (http://www.datarescue.com)
• Import Reconstructor (http://wave.prohosting.com/mackt/projects.htm)

S C A N N I N G

We use PEiD as well as some other internally-built file scanning tools to scan the file.

PEiD results show that the file is packed with "FSG 1.33 -> dulek/xt". FSG stands for [F]ast [S]mall [G]ood exe packer. It's one of the most widely used packers for malicious binaries, and lucky for us it's normally easy to unpack since most versions of FSG do not contain any anti-debugging tricks to make unpacking more time-consuming.

U N P A C K I N G

Step 1) We open the file up in IDA Pro.

When we open it up in the IDA, We are going to start up with all the default options except one, when the wizard presents us with the "Segment Creation" dialog box we are going to uncheck "Create imports segment", because most packers corrupt the imports segment and build it dynamically at run-time.

Once IDA starts up, we'll get a screen that looks like this:

Step 2) The next step in unpacking is to locate the original entry point (OEP), this is the entry point of the binary before it was packed.

To do this we are going to click our mouse on the code on the start procedure and hit F12. This is the shortcut key for displaying the flow chart of the current function. The reason this is useful is because we can trace the unpacking code routine from start to finish. The finish, or exit function should contain a jump instruction. This jump instruction leads to address of the OEP.

If we take a closer look at the flow chart we can see the exit function labeled loc_41F897. The exit function's last instruction is a jump to 0x0040520B. We have found the OEP!

Step 3) After we locate the OEP, we want to set a break point (BP) at that address and use IDA's debugger to execute the program until it hits the OEP. From the time the program starts to the moment it hits the OEP, the unpacking routine will be running.

If we were to go to the OEP before the instructions were unpacked we'd get code that looked like this (now, this doesn't make any sense!)

One important caveat here is that we must set a hardware breakpoint on execution on the OEP and not a software breakpoint. The reason we can't set a software breakpoint is that the instructions at the OEP haven't been unpacked yet and during the unpacking phase they will be overwritten. Software breakpoints work by replacing the instruction at the address we put a breakpoint on with an int3 instruction. So, if we were to use a software breakpoint the int3 instruction would be unpacked, and the code would be incorrect. Hardware breakpoints don't replace any instructions, they work by setting DR registers.

This is the OEP after we set the break point and execute the program. As you can see we can recognize the start of the common prologue instruction sequence: push ebp.

Step 4) Now that we have located the OEP and unpacked the binary in memory, we will use Import Reconstructor to dump the process to disk. As an optional step, we will also reconstruct the imports table. A complete imports table will help use when we are doing the analysis on the unpacked version of the file.

Open up Import REConstructor and attach to the process we're unpacking.

Then enter in the OEP. We want to enter in the OEP we found in IDA minus the image base. Then hit "IAT AutoSearch".

Now we will use Import REConstructor to reconstruct the imports, so we hit "Get Imports". To make sure we have found all the imports we then hit "Auto Trace".

Then right click on the text box labeled "Imported Functions Found", go to Advanced->Select Code Section(s) and hit "Full Dump" to dump the file to disk. < /FONT>

Once you have the process dumped to disk, hit the "Fix Dump" button and open up the dumped process. This will create another file with some of the addressed fixed to reflect the changing in the imports table.

We can now exit Import REConstructor and IDA Pro. We have successfully unpacked the malware and are ready to analyze the unpacked version of the file...yeah!!!!

A N A L Y S I S

First I'm going to look through IDA's String and Names window to get an idea of what calls are being made, and what interesting strings that could help to build some context to this malcode.

We see that the Strings window contains some URLs, so we can assume that obviously this malcode is connecting to the web. Double clicking on one of the URLS brings us to its address in the binary. Then we cross-reference it to find where it's actually being used. I generally do this numerous times with different strings to get a good idea of what's happening throughout the file.

We then use IDA Pro's graph mode to quickly scan the code, attempting to get an idea of the flow of the program.

The next thing we do is actually set a BP at the OEP and step-by-step debug the program. I find it so much easier to use a combination of static and dynamic analysis than just one or the other.

As we slowly debug the code we carefully step over (F8) any windows functions and step into (F7) any interesting local functions. The first interesting function we see seems to download a binary:

http://down<REMOVED>update.com/traff/piglett.exe is being pushed as an arg to sub_4030A0...this could be interesting.

When we look inside sub_4030AO we see that InternetOpenA/InternetReadFileA/CreateFileA/WriteFileA are being used to copy the file from the Internet to the local drive. I pause analysis in IDA for a moment to verify the file was downloaded. Sure enough, I find it in: C:\Documents and Settings\Administrator\Local Settings\Temporary Internet Files\Content.IE5\4DI9QXQ1\piglett.exe

Debugging a bit further, we find that once the file is downloaded it's executed.

Tracking execution leads is to another file being dropped onto the system, but this time the file isn't downloaded, it's extracted form within the binary itself. The executable image is hidden within the resource section. To extract the executable image the function sequence BegineUpdate/FindResource/LoadResource is used followed by CreateFile and WriteFile.

Once the file is written to disk it is then executed and the main program exits.

E P I L O G U E

This binary was rather simplistic in that it was easy to unpack and reverse, but it's a prime example of the techniques and methods used by a generic Trojan downloader.

Researcher: Stephan Chenette, Websense Security Labs