In my previous post, I covered Waledac’s bootstrap mechanisms, armoring methods, and some parts of its communication protocol. Today, I will continue to discuss its communication protocol and how it implements its main functionalities through command-and-control (C&C) messages. I will describe its various tasks and commands, how it downloads components or updates, how it constructs its spam, and lastly how it acts as an infostealer.
Types of task messages
Types of task messages
As I mentioned last time, W32.Waledac currently uses nine types of task messages. These messages are mainly used by the malware to distribute spam templates or word lists for its spam campaigns, to send reports, and to collect stolen information. Figure 1 (below) shows an illustration of typical transactions that occur between a slave-node and a relay-node. Remember that the relay-node only proxies the response from the master C&C server. So, even though it may look like the transactions are between a slave-node and relay-node, the commands or responses actually came down from the master C&C server.
Moving back to Figure 1, let‘s talk about this example in more detail. In a getkey task operation, a slave-node tries to initiate a handshake with a relay-node by sending a message containing a self-signed certificate. The relay-node then responds back with a session key that is used to encrypt succeeding messages between both nodes. Once a session is established, the slave-node executes a first transaction by reporting its node label and Windows system version. The relay-node simply sends back an acknowledgment receipt. Afterwards, the slave-node performs a notify routine task by sending startup and run times information. In exchange, it receives commands and other configuration data from the relay-node. Next, the slave-node executes a taskreq operation by requesting for a spamming task, and the relay-node responds by sending spam templates related to one or more spamming tasks. The templates sent by the relay-node include an email template and a list of components or word lists available. This will then prompt the slave-node to carry out multiple words transactions by sending one request for each word list. In response, the relay-node transmits back each word list that was requested. After a spamming task is finished, a slave-node performs a taskrep transaction by sending a report that indicates which target email addresses were successfully spammed or not. It receives another acknowledgment receipt as a response.
Meanwhile, the slave-node may also at any time send messages containing email addresses harvested during an emails task routine. Aside from this, it may also send login credentials that it managed to collect during a creds operation. For both cases, the relay-node responds with an acknowledgment receipt.
Figure 1. An illustration of typical exchanges that may occur between a slave-node and relay-node
On the other hand, a relay-node also has the additional task (illustrated in Figure 2) of sending a report to the C&C server about connections that were made to it while acting as a proxy server. The report will contain information such as the file requested, as well as the IP address and user-agent of the requester.
Figure 2. An illustration of the additional "httpstats" transaction performed by a relay-node In the sections that follow, some of the tasks—namely notify, taskreq, words, emails, and creds—will be discussed further.
The notify task message—wherein Waledac acts as a Downloader, among other things
During a notify task message exchange, a Waledac node receives configuration data and commands such as the ones shown in Figure 3 below. One such example of data is the IP address of the SMTP server that a slave-node connects to when performing its spamming task. In addition to the configuration data received by a slave-node, a relay-node may also receive domain names of DNS zones and IP addresses of DNS hosts. There is also indication that a relay-node may receive a list of connection requests to deny or blacklist, although it is unverified at the time of writing.
Figure 3. Snapshot of a sample notify message received by a slave-node
As seen in Figure 4, a Waledac node receives a download-or-update command through the commands attribute of the notify XML message. The command items are delimited with a pipe character and consist of an ID, command type, and the link to download from (format shown in Figure 4).
Figure 4. Basic format of a download-or-update command in the notify message
In addition, when the given command is successfully executed, the hexadecimal equivalent of the command ID will be stored in the LastCommandID registry value that was brought up in the previous blog post. This download-or-update functionality will be discussed in more detail in the following section.
Bundled JPEG Download
One of W32.Waledac‘s download abilities is to download a specially crafted JPEG image file. A binary file is appended after the end of the JPEG image file, but the JPEG image will render as an image in most image browsers. The worm tries to hide the presence of the binary file attached at the bottom of the image file by XOR-encoding it. An example of an XOR-decoded binary is shown in Figure 5 below. The executable is extracted from the end of the JPEG file, the image data is discarded, and the executable is decoded and executed. In the sample shown in Figure 5, the decoded executable is an updated version of W32.Waledac. It is interesting how this executable update is only obfuscated with one layer, using UPX compression. Normally, we see the W32.Waledac samples wrapped with multiple layers of encryption and protection, besides UPX compression. The sample in Figure 5 suggests that Waledac updates downloaded through a command in a notify message are not as heavily protected, compared to bot agent binaries obtained through a download link that came from a propagation campaign spam.
Figure 5. A sample of the JPG bundled executable in its encrypted and decrypted form
One other example of the JPG bundled binaries that are currently downloaded and installed by Waledac is a Nullsoft installer (NSIS) for WinPcap—a Windows packet capture library. WinPcap is not malicious by itself, but the library gives a bot master the ability to view a victim‘s network traffic. Waledac uses it to sniff for FTP, POP3, SMTP, and HTTP traffic so that it can steal login information. The stolen login data is then transmitted to the bot master through the previously mentioned creds task message.
Furthermore, one slave-node may be commanded to download a file different from that of another slave-node. One node might receive a command to download a JPEG file bundled with a Winpcap installer, while another node might be commanded to download a JPEG file bundled with an update of Waledac instead.
Fake antivirus download
Another type of file being downloaded by Waledac is an installer for a fake antivirus application (a.k.a. scareware or rogue antivirus programs). In this case, the file downloaded is a pure executable binary and is not bundled with a JPEG file. However, Waledac attempts to protect the fake antivirus installer from file-based detections using server-side polymorphism.
Rogue antivirus applications try to convince the user to buy a fake security application by showing them false infection warnings like the one shown by System Security 2009 in Figure 6 below. This suggests that the Waledac author may be using an affiliate program where they may get a percentage of the profit. It is either that or the authors may have leased a part of their botnet to distribute these fake applications.
Figure 6. Snapshot of a false infection report used by a rogue antivirus program installed by Waledac.
Just to give you an idea of the tactics that are being used by these fake applications, let me give you some samples. One of the fake antivirus variants currently being installed by Waledac is System Security 2009. Besides the typical method of showing false infection reports or warnings, some samples I have seen were also capable of modifying the user’s desktop into the warning message shown in Figure 7. Not only that, it may also show the user a fake “blue-screen-of-death,” such as the one shown in Figure 8, in order to make users think that their system has crashed. With the unsuspecting user being bombarded with scary warnings like these, they might eventually be convinced to buy the fake antivirus application.
Figure 7. Snapshot of a desktop modified by a fake antivirus application
Figure 8. Snapshot of a fake blue-screen-of-death that may be displayed by a fake antivirus application
More on download-or-update commands
At the moment, Waledac is capable of executing eight different types of download-or-update commands—namely update, updateexe, download, downloadexe, downloadR, downloadrexe, downloadS, and downloadSexe. So far, we have seen three of those being actively carried out. Figure 9 shows some specific samples of the commands that we have observed being sent down to the nodes while monitoring Waledac. It also indicates what kind of file the commands downloaded during that time. Of course, there is a possibility that this may change and that Waledac may choose a different kind of file to distribute in the future.
Figure 9. Specific samples of Waledac download-or-update commands
The taskreq and words task message—wherein Waledac acts as a spammer
Waledac’s spamming functionality mainly involves the taskreq and words tasks. The email template and list of recipient addresses are sent down to the slave-node using a taskreq message similar to the sample shown in Figure 10 below. The email template is base64-encoded inside the body attribute of the XML message, but the rest of the contents of the taskreq message are plaintext. In the meantime, the major components required by the email template to create a spam, are requested by a slave-node through a cluster of words messages that follow right after the taskreq message.
At the time of writing, for each taskreq spam template that gets sent down to a slave-node, it may contain up to 1,000 target email addresses. Think of it this way: every time a node requests for a spamming task, it is instructed to send out spam to 1,000 recipients.
Figure 10. Snapshot of a sample taskreq message received by a slave-node
When a node receives a spam task through the taskreq message, it would be given an email template along with a list of words lists or components that are available upon request. To obtain those components, the node has to carry out a words task. To do this, it has to send a request for each words list. Let us say for example, that there are 20 of those words lists. This means that the node would eventually have to make words requests for a total of 20 times. For instance, if the taskreq message contains a words list component named pharma, the slave-node has to send a request through the relay-node for a words list named pharma. The relay-node then transmits back the pharma list so that the slave-node can use it when constructing the spam email. This transaction is done for each component until all of the words lists have been obtained by the node requester.
A words message actually only contains a list of strings that are used to fill some of the major variables in the email template. The name of the words list is indicated in the word element of the words XML message. Furthermore, a word list can either be classified as a general type or spam-specific type. A general type of words list is mostly used for the contents of the email headers (see Table 1 for examples). Notice that they are mostly just lists of names, domains, or versions that we typically see in email headers. We often see this lists being reused in more than one spam campaign. Except for domains, most of the general words lists are rarely changed or may not even be changed at all.
Table 1. Examples of general words lists
On the other hand, the spam-specific type of word list is typically used only for the specific spam campaign it was designed for. Once a specific spam campaign is over, we usually do not see this list being used by Waledac to construct its spam anymore. Table 2 shows samples of lists that are specific to a spam campaign. For example, the pharma and pharma_links contains strings or links that are found only in W32.Waledac‘s pharmaceutical spam campaign. As a matter of fact, the pharmaceutical spam campaign is Waledac’s longest running campaign, and at present, it is still ongoing too.
Table 2. Examples of spam-specific words lists
To give you an idea of how Waledac constructs a spam email, Figure 11 shows a sample of an email template used in its pharmaceutical spam campaign. An actual email using this template is shown after that in Figure 12. From these illustrations, you can probably figure out that part of the email header entries in a Waledac spam, such as the sender’s name and address, are spoofed or fake.
Figure 11. Email template sample for the pharmaceutical spam campaign.
(NOTE: Variables are shown in red font, and words list names are in bold red.)
Figure 12. Pharmaceutical spam sample with the words list components indicated
If you are wondering what a word component list looks like, Figure 13 below shows the pharma words list that was used by Waledac for the spam email shown in Figure 12 above. As pointed out in the strings enclosed in red boxes, the spam email’s subject line and part of its message body were taken from the words list displayed in Figure 13.
Figure 13. The pharma words list used for the sample spam in Figure 12 (Note: Some parts of the list were cut to make it fit in this blog post.)
Moreover, a specific spam campaign may have more than one email template. Combined with the contents of the email being randomly chosen from word lists, this means that a Waledac spam can have many possible combinations. It is obviously an additional attempt to further evade detection or spam traps.
The emails and creds messages—wherein Waledac acts as an infostealer
In essence, both of the emails and creds tasks simply involve stealing information so that it can be passed on to the bot master. Upon installation, W32.Waledac begins searching the fixed and removable drives for email addresses, except for files with the name extensions shown in Table 3. After executing this task, Waledac transmits the harvested email addresses to the bot master using the emails task message. What does the malware do with the data? It appears that these email addresses eventually get added to the list of spam targets that are distributed to the nodes. However, it is possible that Waledac also have other uses for the data besides this.
Table 3. Skipped filename extensions
In the meantime, a creds message, such as the one shown in Figure 14, is relayed whenever the malware manages to capture login information while monitoring FTP, POP3, SMTP, and HTTP traffic. The information sent contains the username, password, server type, and server IP address. As to what is being done with these stolen login credentials, it is still unclear. There is speculation that the login data is being used by the Waledac authors to gain access to the servers, so that they can hijack them for their own use. Regardless of the actual reason, there still remains the fact that Waledac is stealing confidential information and that it could lead to precarious consequences.
Figure 14. Sample of a message being sent by the creds task
Final Summary and Conclusion
This is the final installment of my series of blog posts about Waledac. To recap, I first gave an overview of Waledac’s functionalities, spam campaigns, possible origins, and connections. In the blog post that followed I talked about Waledac’s bootstrapping and protection mechanisms and part of its communication protocol. Lastly, in this post I provided more details on Waledac’s communication protocol and task messages. I also discussed more on how it functions as a downloader, spammer, and infostealer.
As of now, we can reasonably speculate that the Waledac authors’ main reason for building the botnet is financial motivation. First of all, it continues to send massive amounts of spam that is promoting different kinds of dubious products or services. This suggests that the Waledac botnet is most likely being leased to third parties looking to have their so-called products promoted through spam. Furthermore, the downloading and installation of fake antivirus or rogue applications by Waledac implies that its author may possibly be a member of a pay-per-install affiliate program.
You may have noticed that Waledac launches a new propagation campaign every now and then. It is also capable of updating itself and has been known to use exploits in its malicious websites to increase its chances of successfully compromising a system. Besides that, it is also possible that the incidents of Waledac being downloaded by W32.Downadup and Trojan.Bredolab are just another means of propagation that Waledac is using. All of these instances indicate that Waledac intends to continue adapting and expanding its botnet, and to keep it running for as long as possible.