Malware dissection 101

I’m lucky enough to be sent interesting new malware examples and hacker exploits to examine and figure out. For the most part, senders look to me for clues about how the program works and what it does -- or is capable of doing -- after it has successfully compromised a host.

Free IT resource Virtualization Insights from Top Experts - Learn how virtualization gets real! Sponsored by Dell Free IT resource TechNet: More ways to know it, share it, and keep it running. Sponsored by Microsoft

Because my disassembly skills aren’t what they used to be, I often send the malware examples to my professional friends at anti-virus companies, Dshield, and other submission locations. They are better at it and are better equipped. But occasionally they don’t have the same sense of urgency or interest that I do.

This was recently reinforced twice: I sent two malware examples to my normal analysts, but they didn’t respond quickly enough. Gee, maybe they have real lives and jobs besides being my personal malware analysts?

Even with that in mind, these particular malware examples both begged for quick analysis. One was a new Windows exploit; the other, an interesting worm.

The first was proof-of-concept exploit code that claimed to work remotely against Windows XP Pro. This confused me because the exploit code targeted a known vulnerability that worked against XP and Server 2003, but only locally. Which was it, local or remote, against XP only, or Server 2003 as well? I would have to assemble and try it myself.

The second submission was an Internet worm that could make a man-in-the-middle attack on SSL connections. Specifically, the worm was preprogrammed to install itself on unsuspecting PCs and wait for connection to one of nearly 1,000 different banking Web sites. When the a user browsed to his or her bank’s Web site, the worm intercepted the HTTPS request and replaced it with its own locally loaded page to capture the user’s log-on credentials and PIN. It then sent this information to a remote drop-off location, and left the SSL icon on the browser unchanged during the whole process. How did it do this? I was intrigued.

Now that you have the backstory, get ready for a three-part examination of how I tackled these curiosity-piquing programs. This week, I'll discuss how I disassembled and analyzed the SSL-enabled worm. My next column will cover the SSL worm's internals in detail, followed by a look at how to download, assemble, and test various proof-of-concept exploits.

Disassembling the code

Although malware analysis is more art than science, there are two basic paths to learning: disassembly and analysis in a virtual environment. By reading a program's instruction, an analyst can learn exactly what the program can do -- and even as important, what it cannot do. As I mentioned, my disassembly skills aren’t what they used to be, so I usually do both.

The SSL worm came to me as a Windows compiled .EXE (executable). Although there are many disassembler choices (a nice list can be found here), the commercial IDA Pro  is considered the best among malware analysts.

After disassembling the code, I look for API calls, which often tell you what the program does. IDA Pro automatically creates an excellent source-code jump logic map, merging source code with a graphic summary that must be seen to be believed.

I bow out of code analysis when the code is encrypted, polymorphic, or uses anti-debugging techniques. Then I must rely on my professional friends for their expertise.

Running in a virtual environment

Next, I set an emulated environment using VMware or Microsoft Virtual PC. For many reasons, I personally prefer the former over the latter, although the feature gap is minor.

When I have my virtual environment installed and operating (for example, Windows XP Pro), I install a multitude of other monitoring tools. In a nutshell, I want to monitor any change made to the virtual session after I launch the malware. On a Windows virtual session, I want monitor four things: the registry, file system, application or OS manipulation, and network traffic.

For monitoring registry changes, I like to use Sysinternals’ Regmon ; and for files, Filemon. For taking holistic before-and-after snapshots, I like Tripwire, WinInterrogate, and Winalysis.

When it comes to network traffic analysis, I love Ethereal. I've always been impressed with it. I consider it the best open source utility in existence. For best results, run it on the host system sniffing network traffic headed to and from the virtual machine.

For analyzing HTTP-related traffic, you can’t beat Paros. Paros allows you to capture, send, and receive information, which was especially useful in the SSL worm analysis. Install it and tell Internet Explorer to use it as a browser proxy.

Using both disassembly and virtual machine monitoring, I’m able to sherlock my way to being a half-decent malware analyst -- and so can you. Happy malware debugging, and tune in next week for my findings on the SSL worm.