Executable File Analysis (Windows Forensic Analysis) Part 3

EXPORT Table

As DLLs provide functions that other executable files can import, the DLLs themselves maintain a table of functions available in their (you guessed it) EXPORT table. These are functions that are available for other executable images (DLLs, EXEs, etc.) to import or make use of so that application authors do not need to write their own code for everything they want to do on a system. The DLLs act as libraries or repositories of prewritten code that are available for use on the system.

Pedump.exe will dump the EXPORT table from DLLs. For example, here is a portion of the EXPORT table for ws2_32.dll:

exports table:

Name:

WS2 32.dll

Characteristics:

00000000

TimeDateStamp:

tmp1E1-220_thumb[3]

Version:

0.00


Ordinal base:

00000001

tmp1E1-221_thumb[1]

000001F4

tmp1E1-222_thumb[1]

00000075

Entry

Pt Ordn Name

00011028

1

accept

00003E00

2

bind

00009639

3

closesocket

0 0 0 0 4 0 6A

4

connect

0 0 010B50

5

getpeername

0000951E

6

getsockname

0 0 0 0 4 6C9

7

getsockopt

0 0 0 0 2BC0

8

htonl

00002B66

9

htons

00004519

10

ioctlsocket

0 0 0 0 2BF4

11

inet addr

If you have any experience with UNIX and/or Perl socket programming, you will recognize the exported functions as being the core functionality for network-based communications. For example, the bind( ) and accept( ) functions are used by services or daemons that listen for connections (backdoors, etc.), and the connect() function is used by client utilities that connect to servers, such as Web browsers and IRCbots.

I should point out that DLLs can import functions from other DLLs, in addition to exporting their own functions. For example, using pedump.exe to view the PE information for ws2_32.dll, we see that the executable imports functions from kernel32.dll, ws2help.dll, ntdll.dll, and others. Some DLLs will import functionality from other DLLs to build on the base functionality provided. Tools such as the Dependency Walker will show you these chained or cascading DLL dependencies in a nice GUI format.

Resources

Many times, a PE file will have a section named ".rsrc", and will have a Resource data directory listed, as well. This resource section can contain information about things such as dialogs and icons, and other useful bits of information that may help you identify a file, but perhaps the most useful thing during analysis of an executable file is file versioning information.

The Perl script fvi.pl (located on the accompanying media) uses the Win32::File::VersionInfo module to extract file version information from a PE file, if such information is available. Fvi.pl takes a filename (with the full path) as the sole argument, and returns the information it finds as follows:

tmp1E1-223

Filename

: c:\windows\system32\svchost.exe

Type

: Application

OS

: NT/Win32

Orig Filename

: svchost.exe

File Descriptoin

: Generic Host Process for Win32 Services

File Version

tmp1E1-224

Internal Name

: svchost.exe

Company Name

: Microsoft Corporation

Copyright

tmp1E1-225

Product Name

: Microsoft« Windows« Operating System

Product Version

: 5.1.2600.2180

Trademarks:

You need to keep a couple of things in mind when using tools such as this. First, the Win32::File::VersionInfo module is specific to the Windows platform. Second, neither the module nor the Perl script makes any attempts to verify that the file in question is actually a PE file. This means that if fvi.pl fails to return any information, it does not mean the file in question is malware. In fact, many malware authors make sure that such information is not compiled into their tools, whereas others will include faked file version information to throw off investigators. Some even include file versioning information simply to amuse themselves and others.

Notes from the Underground…

The Russiantopz Bot

While performing analysis of the russiantopz IRCbot, one of the interesting bits of information I discovered about the bot program (which was named statistics.exe) was that it really wasn’t an IRCbot written by anyone from Russia! Looking past the name of the file and delving into the file versioning information, I found that the file was really a copy of the mirc32.exe (www.mirc.com/get.html) IRC client application. The GUI Internet Relay Chat (IRC) client was hidden from the desktop by a file called team-scan.exe, which was really a copy of Adrian Lopez’s hidewndw.exe (http://premium. caribe.net/~adrian2/creations.html) utility.

Although the use of file versioning information is not always a conclusive means of analysis, it does provide additional information that will add to the overall picture of your investigation.

Obfuscation

So far, we’ve used normal, legitimate executable files to illustrate the various structures of PE files. Although you can use these tools and techniques to identify files, malware authors often put forth effort to disguise or "obfuscate" their files, not only to avoid detection by administrators and investigators but also to hide from antivirus and other security software programs. Many times, the malware authors will use packers and even encryption tools to disguise their software, or they will simply create new versions of their programs.

You can use a variety of utilities to obfuscate executable files, such as binders, packers, and cryptors. We’ll take a look at each of these in turn.

Binders

Binders are utilities that allow the user to bind one application to another, in essence creating a Trojan application. The idea is that the carrier application will entice the user to launch it; examples include games and other executables. When the victim launches the carrier application, he sees the application run, and nothing seems amiss. All the while, however, the Trojan application runs, often behind the scenes, unbeknownst to the victim. One of the first binders available was eLiTeWrap (http://homepage.ntlworld.com/chawmp/elitewrap/), but Silk Rope and SaranWrap (http://packetstormsecurity.org/trojans/bo/index3.html) became popular when the Cult of the Dead Cow released its Back Orifice utility. Looking at write-ups and descriptions of malware available at antivirus sites (as well as others), it would appear that binders are no longer "in vogue" among malware authors, and perhaps are no longer considered "cool." This may be largely due to the fact that binders leave behind signatures that have long been detected by antivirus software.

Although many binders are available under many different names, they all perform the same basic function: to bind one executable to another. ELiTeWrap is perhaps unique in that it allows the user to configure a script of commands to be run or responses to be provided, offering some additional functionality in the bound executables.

Warning::

After downloading ELiTeWrap 1.04 to a Windows XP Pro SP2 system, I tried several different times to produce a working, bound package, and failed each time. I tried using ELiTeWrap in interactive mode, as well as using a script. Each time, I ended up with an output file much smaller than any of the input files, and when I attempted to run the output file, I received a dialog that stated "Error #57 reading package".

Packers

"Packers" is another name for programs that allow users to compress their programs, saving space. Another name for such tools is "compressors." Although this is not much of an issue due to expanding storage capacity, compressing the executable file does allow it to transit the network more quickly and potentially allows it to avoid detection by both host- and network-based antivirus and intrusion protection systems. Packers also make analysis of the executable more difficult. Some legitimate companies pack their programs to make them run faster (less to load from disk into RAM) or to protect trade secrets. Although many packers are available, popular packing programs include ASPack (www.aspack.com) and UPX (http://upx.sourceforge.net).

ASPack works by compressing the executable image, writing a small decompression routine at the end of the file. The executable’s entry point is then changed to point to the beginning of the decompression routine, and the original entry point is saved. When the executable is decompressed into memory, the entry point is reset to the original value. One indication that ASPack has been used is the existence of section names such as .adata, .udata, and .aspack (keep in mind, however, that the section names are just that, names, and they can be altered). Tools reportedly are available that will allow you to unpack files packed with ASPack.

UPX is another popular packer, and although you can use it as a packer, you also can use it to decompress files that have been packed with UPX; so, it’s an unpacker for itself, as well. One indication that you have a file compressed with UPX is the existence of the section names UPX0 and UPX1, but you should keep in mind that these names can be changed by simply editing the PE file with a hex editor.

These are just a few examples of compression utilities used by malware authors, and there are many, many more out there. Depending on the compression utility used, you may find an application or plug-in that is meant to decompress that algorithm, reversing the process. You may have to spend some time doing research on the Internet to see whether reversing the compression is an option, and whether there is a utility to assist you.

Tools such as ProcDump32 (www.fortunecity.com/millenium/firemansam/962/html/procdump.html) include the ability to unpack common compression algorithms. Figure 6.10 illustrates the Choose Unpacker dialog for ProcDump32 from which the user can select the algorithm used to pack the executable.

Figure 6.10 Choose Unpacker Dialog from ProcDump32

Choose Unpacker Dialog from ProcDump32

ProcDump32 also includes other functionality, such as allowing the user to dump a running process to disk, unpack or decrypt a PE file using common algorithms, and edit PE headers. You’ve already seen other tools that allow you to do this, but ProcDump32 does provide some fairly useful functionality, and should be included as part of your malware analysis toolkit.

Cryptors

"Cryptors" is a slang term for programs that allow the user to encrypt other programs. Encrypting an executable is another method that malware authors use to attempt to avoid detection by both host- and network-based antivirus and intrusion protection systems. This actually seems to be a pretty popular method for obfuscating malware, and in some cases the encryption algorithm or routine may be known or at least discoverable (based on a signature of some kind), whereas in others it may be completely unknown.

As an example of an obfuscated bit of malware, we’ll look at a file that we know has been obfuscated in some way. The Honeynet Project provided interesting "Scan of the Month" (SotM) challenges (http://old.honeynet.org/scans/index.html) for some time, offering a variety of different data and scenarios for folks to try their hand at deciphering. The interesting thing about the SotM challenges is that after a period of time, the submissions are judged and posted, so you get to see how the challenges were solved in detail. Ed Skoudis provides similar challenges at his site, CounterHack.net.

For example, the Honeynet SotM 32 was designed to analyze a malware binary called rada.exe. Figure 6.11 illustrates the icon for the malware binary.

Figure 6.11 Icon for the rada.exe Malware Binary

Icon for the rada.exe Malware Binary

Using pedump.exe and PEView to look at rada.exe, we see that it has a pretty normal PE header, and that everything seems to translate well. By that I mean the tools can parse the PE header information, and from a parsing perspective it seems to make sense. If it didn’t, pointers would be pointing off to strange sections of the file, or off the end of the executable file altogether.

Perhaps the most interesting thing we see is that the file has three sections: JDR0, JDR1, and .rsrc. Now, .rsrc is a section that we’re familiar with, but the other two we haven’t seen in the PE files we’ve looked at so far. Another thing that we notice is that the IMPORTS table lists only two DLLs, KERNEL32.DLL and MSVBVM60.DLL, as shown here:

tmp1E1-228

This is odd, because we know this is malware, and any malware that actually does anything is going to import more than two DLLs, and definitely more than just three functions from KERNEL32.DLL.

Tip::

This is also a great way to spot obfuscated malware quickly. When the IMPORT table shows just KERNEL32.DLL (or maybe that DLL, and one or two others), and only a few imported functions from that DLL include LoadLibraryA and GetProcAddress, this indicates that the file has been obfuscated in some way.

The other imported module, MSVBVM60.DLL, is a Visual Basic runtime. The output of fvi.pl tells us that the file description from the resource section of that DLL is "Visual Basic Virtual Machine". From this, we can deduce that the malware itself was written using Visual Basic. This deduction is also borne out in the challenge submissions for analyzing this file listed at the Honeynet site.

As rada.exe has a resource section, we can run fvi.pl against it, and in doing so retrieve the following:

Filename

d:\tools\rada.exe

Type

Application

OS

Unknown/Win3 2

Orig Filename

RaDa

File Descriptoin

File Version

1.00

Internal Name

RaDa

Company Name

Malware

Copyright

Product Name

RaDa

Product Version

1.00

Trademarks

Very interesting, and nice to know that the author is letting us know that, yes, this is malware. Don’t expect this to happen often, if at all.

Now that we’ve seen definite signs that this malware is obfuscated (and yes, we cheated a bit by choosing a program we already knew was obfuscated), we’d like to know how it was obfuscated. Was a packer used? Was compression used, or how about encryption? We can use a handy tool called PEiD (http://peid.has.it/) to examine this file and attempt to determine the obfuscation method. Figure 6.12 illustrates rada.exe loaded into PEiD.

Figure 6.12 Rada.exe Loaded into PEiD

Rada.exe Loaded into PEiD

Notice that PEiD detected the obfuscation method as a version of the UPX compression utility. This is interesting, as the section names listed by PEView were JDR0 and JDR1, rather than UPX0 and UPX1. As I mentioned earlier, the UPX0 and UPX1 section names indicate the UPX compression utility. This tells us that if the PEiD information is accurate, the author used an editor to modify those section names.

Tip::

Everything we’ve looked at with respect to executable files so far has given us some idea of different aspects of the files we can investigate to identify the nature of the file itself. This is particularly helpful in understanding what our antivirus products are telling us, or what they’re not telling us when they are unable to identify the latest variant of some malware. This is where tools such as Yara (http://code.google.com/pZyara-project/) may be helpful. The Yara Project provides a framework to assist malware researchers (as well as responders) in identifying and classifying various aspects of malware files. Yara runs on Windows and Linux, and is also available as a Python module. Don Weber extended the Yara Python module (www.cutawaysecurity.com/blog/archives/422) into something he calls Yara-Scout Sniper or yara-ss, adding some useful capabilities, such as accessing remote systems. You can also use the publicly available PEiD signatures (look for userdb.txt at www.peid.info/BobSoft/Downloads.html) as part of your Yara rules. Something such as this can be extremely helpful in quickly identifying and classifying new variants of malware, particularly when it is maintained and extended as part of a community effort.

PEiD detects common packers, cryptors, and compilers by locating the entry point of the application and analyzing the bytes at that location, attempting to identify the obfuscation method used. The authors of PEiD have collected signatures for many different obfuscation tools and included them with PEiD. They’ve also included some nifty tools along with PEiD, among them a task viewer for viewing running processes and the modules they use, a dialog for viewing extra information about the file (illustrated in Figure 6.13), a dialog for viewing the PE header, and even a dialog for viewing the disassembled binary.

Figure 6.13 PEiD Extra Information Dialog with rada.exe Loaded

PEiD Extra Information Dialog with rada.exe Loaded

If you take the opportunity to download both PEiD and the rada.exe file, run the disassembler by clicking the button with the right arrow to the right of the First Bytes text field. If you’re familiar with assembly language programming (I haven’t done it since graduate school when we programmed the Motorola 68000 microprocessor) the things that may grab your immediate attention are the jump instructions and the many, many add instructions that you see listed. If you’re curious about the details of the analysis of this binary, take a look at the submissions at the Honeynet site, particularly the one by Chris Eagle. Chris is a well-known instructor and presenter at BlackHat (www.blackhat.com) conferences, as well as a senior lecturer and associate chair for the Department of Computer Science at the Naval Postgraduate School in Monterey, California.

Mandiant’s Red Curtain tool (www.mandiant.com/software/redcurtain.htm) takes a lot of the functionality you’ve seen so far in this topic, including that of PEiD, one step further. This tool will reportedly look at the contents of the executable file, looking for entropy/ randomness, indications of packing or obfuscation, the presence of digital signatures, as well as other characteristics of the executable file, and generate a threat "score." This is intended to indicate to the analyst whether he should investigate the file a bit further. Figure 6.14 illustrates the rada.exe file open in Mandiant’s Red Curtain tool.

Figure 6.14 Rada.exe Loaded in Mandiant’s Red Curtain

Rada.exe Loaded in Mandiant's Red Curtain

Much of the information presented by Red Curtain is similar to what is available in PEiD. Clicking on the Details button on the far right of the Red Curtain interface opens another dialog that illustrates the PE sections (JDRO, JDR1, .rsrc) and their information, as well as the anomaly identified, which in this case is "checksum_is_zero", indicating possible tampering with the file (see the Red Curtain User Manual, accessible from the Help menu option, for more information about the tool and the information presented).

Tip::

If you’re interested in delving deeper into the inner workings of malware and executable files in general, it is a good idea to read through the submissions for SotM 32 and 33 at the Honeynet Challenge site. Not only will you see commonalities among all of the analyses, but you will also see information about other tools you can use to go further into your analysis.

Next post:

Previous post: