Wei Wang, RAP Team
Jia Wang, RAP Team
Jiaying Su, RAP Team
First discovered in 2007, the botnet malware known as Pushdo quickly became known as one of the most prolific sources of email spam in history. At its peak, it was estimated that Pushdo was singularly responsible for sending up to 10 billion spam messages per day. The Pushdo module itself functions as a mildly complex downloader that allows it to fetch other components and tools from its command-and-control (C&C) server. The actual mechanism for sending spam is contained inside some of those downloaded components such as Cutwail and Webmail.
We have recently detected a new version of Pushdo (which was given the project name magadan21) that contains many changes, which includes changes in protocols, its underlying mechanisms, and encryption. The following sections of this blog post will detail some of these changes.
As with previous versions of Pushdo, the bot begins by determining the language of the Operating System that is being used. If the bot detects that the target’s OS is Russian, it will immediately delete itself and exit.
After the bot has determined that the target’s OS is not Russian, it generates a string based on the target’s System Product ID. This string is always eight characters long and entirely in lower case. The bot then attempts to copy itself into the System folder, using this generated eight-character string as the filename. If it is unable to copy itself into the System folder, it will attempt to copy itself into the User Profile folder. When the bot successfully copies itself, it will then attempt to create a new registry entry to allow the copy to automatically execute upon every Windows startup.
The final action taken by the PreLoader module is to start Pushdo’s Loader module. The Loader module is encrypted and saved within the data section of the PreLoader module.
The PreLoader module retrieves the Loader module and decrypts it with a simple decryption method that uses a four-byte key. The decryption method is as follows:
The PreLoader’s preferred method of loading the Loader module is to start a new instance of svchost.exe in suspended mode. It then injects the decrypted Loader module code into this svchost.exe process and then executes it.
The Loader module’s function is to retrieve and then execute the components that allow it to begin sending spam. These components are retrieved from its C&C server. To do this, the module must first attempt to connect to the C&C server.
The Loader has a hard-coded string that contains a vendor name and a list of server addresses. The vendor name and the server addresses are segmented by the hash (‘#’) character.
The Loader randomly chooses one of the server addresses in the hard-coded list and attempts to connect to it. If the address is found to be unavailable, the Loader tries another server until it finds one that it can connect to.
Sending Encryption/Decryption Keys to C&C Server
Virtually all of the addresses that we have found attempt to connect to port 443. As we know, port 443 is used for HTTPS/SSL connections. But instead of using SSL to encrypt its traffic, Pushdo uses a custom algorithm in order to encrypt its traffic.
Each connection uses two separate keys. The first key is used to encrypt and decrypt the package headers. The second key is used for the actual data of the packages to be transferred. Pushdo sends these keys to the server when a successful connection is first established.
In the previous version of Pushdo, the length of the header key is eight bytes long. This key is hard-coded in the binary and is pre-shared with the C&C server. The data key is four bytes long and is generated randomly.
The previous method of sharing is shown below in the following figure. Because the header key is pre-shared, the bot sends only the data key to the C&C server.
In the new version, both the header key and the data key are eight bytes long and are randomly generated. The figure below shows these two keys being sent to the server.
Sending Windows and Bot Information to the C&C Server
Pushdo collects the following information from the target machine:
- Windows OS version
- Windows System Build Number
- Windows OS Service Pack Version
- System Volume serial number
- System BIOS date
- Video Card BIOS date
- Processor Identifier
- System Product ID
Once it has collected the information, Pushdo then sends it to the C&C server in three packages: winver, info, and END. Below is an example of the data that was sent.
The following table shows the structure of the sent information.
We will now discuss what information is contained in each package.
The winver Package
The first package sent is a winver package, which is 0x2B bytes in length. The Content field of this package contains information related to the Windows version: the OS version, the System Build Number, and the Service Pack version.
The info Package
The second package is named info and has a Content field that is 0x1C bytes in length. There are three types of information contained in the Content field: (1) byte0 through byte7 are used to house the System Volume serial number, the System BIOS date, the Video Card BIOS date, the Processor Identifier, and the System Product ID; (2) the DWORD after that contains the version of the bot; and (3) the last sixteen bytes are used to save the vendor name. The vendor name itself is saved as a string and ends with a 0x00 byte.
The END Package
The last package is an END package. This package only contains the Identifier and the Size fields. The END package is used to notify the C&C server that this is the last package being sent.
The eight-byte header, which includes the Identifier and Size fields, is XORed with the eight-byte header key. The data, which includes the Reserved, Name Length, Content Length, Name, and Content fields, are XORed with the eight-byte data key.
Receiving Responses from the C&C Server
When the C&C server receives the above information from the bot, it will send a response. The response is encrypted using the keys that were shared during the initial communication.
After the bot decrypts the received packages, the following is shown:
The received packages contain the following:
- DATA: This is the main data package. We will go into detail on this later in the section below.
- FILE: This contains the components to be executed. This is typically the Cutwail module.
- END: This notifies the bot that this is the end of the sent packages.
Types of DATA Packages
According to the Name field, there are three types of received DATA packages:
The country Package
This package just contains the country code of the country where the infected host is located.
The proxy Package
The Content field of the proxy package contains information on new server addresses. Each byte of this string is XOR-encrypted using a hard-coded key (in the sample we analyzed, the key used is 0x35). The bot saves this encrypted string in one of two registry locations, shown in Figure 11 below. Pushdo will then use these new server addresses located in the registry the next time it attempts to connect. It will also continue to use the initial set of addresses, but it prefers the newest addresses that have been added to the registry.
The script Package
The Content field of the script package contains several scripts that are to be executed by the bot. The scripts use the following syntax:
- Each script ends with a semi-colon (‘;’, or 0x3B);
- Each script starts with a specific command keyword;
- The command parameters are contained in parentheses; and
- The command parameters contained in the parentheses are always split by a comma (‘,’, or 0x2C).
The received script packages may contain one or more of the following four keywords:
The difference between the run_file and run_mem commands is the method in which the new component is executed. The run_file command saves the component as a Temporary file and then executes it directly. If the command is run_mem, Pushdo injects the code of the new component into a new svchost.exe process that is started in suspended mode.
Sending a CMD Package
If the command received is run_file or run_mem, the bot will need to obtain the new component from the C&C server. It does this by sending a CMD package to the C&C server.
The table below shows the structure of the CMD package.
The CMD package is encrypted then sent to the C&C server. Once the C&C server receives the CMD package, it sends a FILE package back to the bot. When the bot receives the FILE package, it is decrypted. A clear-text version of a FILE package is shown in the figure below.
Based on our analysis above, the newest version of Pushdo contains five major changes in comparison to the previous version.
The first change is the name of the self-backup file. Different from the hard-coded string in the previous version, the file name for the new version is a randomly generated eight-character string. The file name is not actually randomly generated, though: it is created based on an algorithm that uses the target’s System Product ID. Therefore, the ‘random’ name will always be the same on the target machine. When the bot starts, it will check to determine if another Pushdo bot is already located on the target machine. The algorithm also uses this method to avoid some file name detection methods.
The second change is the format that the bot uses to save server addresses. In previous versions, the server address is stored in binary. In the new version, the server addresses are saved in a string, and those addresses are split by the hash (‘#’) character. We are not certain as to the rationale for this change, as it seems that the previous method of storing addresses were harder for analysts to locate. Perhaps this method makes it easier for new server addresses to be added or modified.
The third change is how the bot shares encryption keys. In the previous version, the header key is hard-coded to the bot and pre-shared with the server, meaning the bot only needed to share the data key with the C&C server. Also new is that the data key has increased in length to eight bytes.
The fourth change is the Identifier of the communication packages used by the bot. Instead of PROP, DATA is used as the Identifier in the new version. The CMD package Identifier has also been added.
The last and the most important change can be found in the mechanism with the server.
In the previous version of Pushdo, the C&C server would directly send back new components after receiving the data key and the System & Bot information, with PROP packages if required. These packages may contain the commands proxy, vendor, and reconnect.
In the new version, we can see the addition of the CMD package.
As you can see when comparing the two, the script package has been added in the C&C server response. When the bot receives the script package, it sends a CMD package back to the C&C server. The C&C server then replies with the FILE package, which contains the new component.
The script package contains specific commands, which can be summarized as follows:
- Randomly execute the subsequent commands; and
- Download & execute components.
When looking at the two versions side-by-side, it appears that the new version has no or very little improvement or added functionality compared to the previous version. The added complexity to the downloader is the only significant change to the bot. Perhaps this is the beginning of a new mechanism framework for further improvements and updates to Pushdo. If so, we might be able to see a new version that builds upon these changes in the near future.