Analyzing Malwares Using Microsoft Tools

We have been seeing reverse engineering on malware for a while. Some time ago you needed to have magic tools from some underground hackers, but the situation has changed a lot since then. This is especially true for reverse engineering on the Windows platform, where there are a lot of good Microsoft-made tools. They are not specifically made for reverse engineering purposes, but they can be very helpful for reverse engineering binaries. They are also very stable because they went through a lot of internal quality assurance processes before being released to the public.

It feels like these Microsoft-made tools are underestimated. Many hackers are using ollydbg instead of Windbg. Many people are using some other dumping tools to dump processes instead of userdump. And so on. It's not that ollydbg or other tools aren't good. I just want to show how easily the same thing can be achieved with the tools released by Microsoft. I'll show two things: dumping processes, and finding rootkit components embedded in the process images. Both of these can be achieved with just a few lines of commands.

The situation is as follows. We have a machine infected with a malware, a kind of a Zbot variant. We know the malware is doing code injections to collect and control the data flow on the system. So we decide to dump the process image. How can this be achieved with Microsoft tools? We just need to download and install User Mode Process Dumper Version 8.1on the target system. Here's an example showing the dump of the infected "svchost.exe" process image from the system.

Illustration 1: Using userdump to dump live process images

You just need to call userdump.exe with the target process name and target dump file name. It will go through every process with that specific name and dump the image to a file with the name you designated plus the process ID. In one shot, you can grab all the dump files for each process with same name. Convenient, right? One more benefit of userdump is that it will not kill the process it dumped. So theoretically, the process will not be affected by dumping the images. We can silently duplicate the process images and let the system carry on without intervention.

So now we have the corpse images of the processes and it's time to do some basic autopsy work to see which organs have been tweaked by this infectious botnet client. First, you need a tool called Debugging Tools for Windows (aka Windbg). There are, however, some issues with the Windbg download. The last release date for the standalone download package is March 2009, which is more than a year ago. You need to download and install WDK to use the latest Windbg. But in my case, I was just fine with the March 2009 release. And the examples here will work without any problems with standalone packages.

Just move all the dmp files acquired from userdump to a safe location. Launch Windbg and select File > Open Crash Dump. Then choose the dump file you want to analyze.

If you come from the ollydbg world, the first thing you'll notice is the UI. It doesn't have a fancy GUI like ollydbg. You need to know the debugging commands to achieve anything, even simple things. This can be a big hurdle for the people who are accustomed to full-blown GUI debuggers. But there are still many advantages to this command line approach. You can copy and paste the commands easily. And you can save all the data in a text file for further review. Everything you do inside the debugger is logged, and you can keep those logs as your record. Also Windbg supports a kind of a semi-scripting like the "Debugger Command Program", which makes your life easier if you are performing simple tedious repeating tasks.

We will use this small portion of the Windbg script feature to find the hooks installed on the target process. The following one-line command will reveal every hook (especially if they are inline hooks):

!for_each_module !chkimg @#ModuleName -d

!for_each_module is a kind of extension command. Every command that starts with "!" is an extension. It executes the following command for every module on the target process.

The command to execute for each module is "!chkimg @#ModuleName -d". !chkimg is a command that compares the image on the memory and symbol file or executable file. @#ModuleName will be replaced with the module name that is being executed. The command "!chkimg" will compare the image with the one in the symbol store. In this case, we should use the symbol store from Microsoft. If you don't have your symbol path configured, execute the following command from inside the Windbg command prompt:

.sympath+ SRV*C:\localsymbols*http://msdl.microsoft.com/download/symbols

"C:\localsymbols" can be replaced with any local directory that you want to use for symbol cache files.

Here's the result of that "!for_each_module" command with the  "!chkimg" command. Basically, it will iterate through all the modules loaded in the process and check the executable image against the one stored in the Microsoft symbol store. If anything has been modified, it will report the discrepancies.

Illustration 2: The section inside the red square shows the APIs where the malicious hook is installed

From the above picture, you can see that a lot of APIs from ws2_32.dll (winsock) and wininet.dll have been modified. You can quickly see that this malware is monitoring and modifying the network traffic by hooking network-related APIs.

For example, let's look into WSASend API from the ws2_32.dll file. You can use the "u" command to disassemble any portion of the memory. Here, we disassemble the "WSASend" API. The first instruction of the API is a jmp instruction to the memory location 0x00b7dbbd.

Illustration 3: ws2_32!WSASend inline hook installed

We disassemble that part of the memory using the  "u"(disassemble) command. You can see that it's a kind of hooker function.

Illustration 4: Hooker function

By examining the properties of the memory region containing 0x00b7dbbd using the "!address" extension command, we can see that the protection flag has "Execute" and "ReadWrite" bits set. It's usually "ReadOnly" with the "Execute" bit set for the usual executable modules loaded. This might be a heap region and the hooker module might be injected from another process.

Illustration 5: Memory property of region containing the hooker function.

That's it for today. We have showed how to use one-line commands to dump processes, and how to use Windbg to inspect hooks or rootkits installed on the process. The next step will be analyzing the hooker functions themselves. There will be more on this subject in a future blog posting, and it will involve using IDA and IDAPython and the command line version of Windbg.

Thanks, and have a great reversing