A few weeks ago, a fellow analyst sent me a link to a write-up of a new peer-to-peer botnet called Necurs. The write-up included a link to a SANS blog entry. The blog entry included a pcap containing traffic captured from an infected host as well as a sample of the malware. Since I’m pretty interested in malware that communicates via peer-to-peer mechanisms, I decided to take a look at this sample. Hopefully, the notes I take during the analysis will be helpful to anybody else that is new to reverse engineering.
A little background about myself (as a reverse engineer): I took the SANS GREM course a number of years ago and learned quite a bit about reverse engineering. But, even though I made it through the course, it was very difficult to get started analyzing malware samples because of the different types of obfuscation and evasion techniques that I encountered. The SANS course mentioned a number of tools that could be used to make analysis easier, but I decided to start limiting myself to four tools: IDA Pro (a disassembler), WinDbg (a debugger), Process Explorer (a Windows Sysinternals tool for inspecting running processes on a Windows System), and tcpdump (for capturing/analyzing network traffic).
I also make use of a pretty standard virtual machine setup to aid with the analysis. I use two virtual machines with the following IP address configuration:
- WindowsXP With IP Address 192.168.1.2, subnet mask 255.255.255.0, default gateway 192.168.1.1, DNS server 192.168.1.1
- Ubuntu with IP address 192.168.1.1, subnet mask 255.255.255.0
The network cards on each of the machines is configured as on the “Host-only” network so that network traffic does not escape the virtual environment that has been created. The Ubuntu VM will run tcpdump and capture traffic sent by the infected Windows XP VM after it has been infected with the malware. The virtual environment is very important because you can create snapshots of the Windows XP virtual machine at various stages of the infection. So, if you accidentally step too far in the debugger, you can return to a previous state in very little time.
A final note. Many malware samples employ defenses to evade analysis. Some will not run when executed in a debugger. Some will not run while executing in a virtual environment. So, there are a couple of preliminary checks that I make to verify that the malware will run in the virtual environment before I start the lengthy task of stepping through the executable. First, we’d like to verify that the malware will run in a virtual machine, then we would like to verify that the malware will run when executed in a debugger. If we don’t do this, we may spend a lot of time in the debugger stepping through instructions that are used by the malware to evade analysis. The steps that follow will not guarantee that you will not run into some other type of evasion technique, but they will hopefully verify that you can start stepping through the executable in a virtual environment.
First Run: execute the malware within VM
First, I need to be able to observe something that tells me that I have successfully infected the Windows XP VM. Since this malware sample will try to send network traffic to other infected hosts within the botnet, we can use tcpdump to monitor the network traffic generated by the Windows XP VM. I run tcpdump twice on the Ubuntu VM. I use one tcpdump instance to write to a file for later analysis, and one tcpdump instance that outputs to the console. Note that the Windows VM does generate some Netbios traffic that is unrelated to the malware. You should see this traffic before executing the malware on the Windows XP VM. The tcpdump commands used on the Ubuntu were as follows:
- tcpdump -nnSX -i eth0
- tcpdump -nS -i eth0 -w necurs.pcap
When I executed the Necurs sample on the Windows XP VM, the tcpdump instance displayed UDP traffic with a source port of 14820 with a payload size of 29 bytes. This looks kind of strange, so hopefully we have verified that the malware will run within a virtual environment.
Second Run: Execute From Within WinDbg
Next, I executed the sample from within WinDbg while monitoring network traffic on the Ubuntu VM using tcpdump. The following steps were taken after starting Windbg:
- File -> Open Executable …
- Selected the Necurs sample in the file dialog
- Type g in the command window
Once again, UDP packets from an odd port on the infected Windows VM were displayed in the tcpdump output. This shows that the malware will run even if it is being executed in a debugger. However, this time, the source port of the packets was 5255.
This suggests that the malware chooses a random port upon infection as opposed to having a port hard-coded into the binary.Another odd thing happened. The UDP packets were being sent even after the malware had finished executing in the WinDbg command window. This indicates that another process was spawned and that the newly spawned process was responsible for generating the network traffic. I used Process Explorer to display information about the processes that were running in the infected VM. A process called syshost.exe was running with PID of 576. The process properties showed that this process was listening on port 5255 for both TCP and UDP traffic, so this is probably the process that the malware spawned.
Third Step: Break At Program Entry Point
Now that we have verified that the malware sample will run on a debugger in a virtual machine, we need to start stepping through the instructions in the executable. This is a little bit difficult when using WinDbg because we’ll need to set a breakpoint on the entry point of the executable. The following steps can be used to accomplish this:
- Open the malware in WinDbg as described above.
- Type the command lmf into the command window. This command will display modules loaded by WinDbg. Ordinarily, I would hope to see a module with a name that matches the malware executable, but for some reason, this name was not displayed. Instead, a module named xl4n6aq.exe with a base address of 0x400000 was included.
- Next, I used the command !dh 0x400000 to determine the entry point of the program. The entry point is shown at offset 0x60D4, so the breakpoint should be set at 0x4060D4 (base address + entry point offset).
- We can now set a breakpoint using the command bp 0x4060D4.
- We can type g into the console, and the malware will execute until we reach the breakpoint.
At this point, I took a snapshot of the VM so I can easily get back to this point. I also opened an IDA Pro session so I could compare the disassembly produced by IDA Pro with the instructions shown in a disassembly window in WinDbg. The first two disassembly lines in WinDbg matched the disassembly shown in IDA Pro, so we’ve reached a good starting point for debugging the malware.