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.

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.