I I I n n n f f f i i i l l l t t t r r r a a a t t t i i i n n n g g g W W W A A A L L L E E E D D D A A A C C C B B B o o o t t t n n n e e e t t t ’ ’ ’ s s s C C C o o o v v v e e r r r t t t O O O p p p e e e r r r a a a t t t i i i o o o n n n s s s Effective Social Engineering, Encrypted HTTP2P Communications, and Fast-Fluxing Networks A Technical Paper by: Jonell Baltazar, Joey Costoya, and Ryan Flores
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
The WALEDAC botnet has been involved in an almost continuous spate of spam runs since researchers discovered it in December 2008. Their creators routinely take advantage of various real-world events and occasions, using them as social engineering ploys to trick users into performing certain actions. They leverage various sophisticated tools and technologies to create a formidable network of spam bots. This botnet has the ability to update details such as the subject line and the message body in the spam they send and even has the capability to update versions and communication proxies. This vast umbrella of compromised computers whose owners are often unaware of the misuse of their system resources for malicious distributed-computing activities, thus continuing to expand the botnet’s reach and improves its ability to penetrate additional systems all over the world.
In the course of conducting research for this paper, we have seen WALEDAC’s secret ways and means. It employs a sophisticated communication method and encrypts network traffic using various known technologies. It operates through a moving, changing, and working network of nodes that perform preprogrammed tasks with surprising efficiency. We found the technical capability and scope of this botnet’s operations both too massive and advanced to leave unexamined.
While research on WALEDAC has already been conducted by sudosecure.net, the Honeynet Project, NNL-labs, and the University of Bonn Institute of Computer Science, this paper provides a comprehensive view of the WALEDAC botnet—its activities, methodology, involved technologies, purpose, and business model—in order to paint a picture of the complex and intricate nature of the threats that we see today. Spam is not a mere inbox annoyance anymore but is the first step toward executing more dangerous kinds of system infiltration. Malware are no longer discrete executables but a motley group of related components and files that work together to surreptitiously get inside systems. The technologies malware crime fighters are using are—in some cases—being used against us. The people behind these cybercrimes are no longer fame-seeking script kiddies, they are now professional criminals who have created robust cybercrime businesses.
To monitor WALEDAC’s activities more closely, we built a malware laboratory that could capture all the spam generated by WALEDAC, along with the botnet’s network traffic status. This monitoring system comprised two virtual machines (VMs) that ran on VMWare Workstation, namely:
» Infect VM: The VM where the WALEDAC bot executes. » Firewall VM: The VM that controls Infect VM’s outgoing traffic, traps spam generated by
WALEDAC, and prevents these from being sent over the Internet. Firewall VM also hosts a Post Office Protocol 3 (POP3) service so we can download and study the spam via an email client.
Packets are being captured inside the host operating system (OS). Figure 1 illustrates how the two VMs’ network connections were set up.
Figure 1. Network connection system used to monitor WALEDAC
We used Thunderbird as the email client to view the spam caught by Firewall VM, which likewise made it easier for us to monitor the messages generated.
Fortunately, WALEDAC does not contain VM-detection codes, making it easier to monitor the botnet without the use of additional hardware.
WALEDAC recently used the Christmas 2008 holidays for its social engineering ploy when we first spotted it. It has changed its social engineering tactic of spamming on holidays and in relation to current economic events seven times. Appendix A chronicles the social engineering techniques we have seen this botnet use throughout its lifetime.
In addition to tricking users to run malware on their computers, WALEDAC also consistently populates inboxes with pharmaceutical (pharma) spam—spam that advertise Viagra, Cialis, and other similar sexual-enhancement drugs. However, there are times when WALEDAC spews out spam that are neither pharmaceutical in nature nor carry other malware. This suggests that it may have been hired by third parties or clients as a spamming service. These regular WALEDAC spam are also documented in detail in Appendix B.
The timeline shown in Figure 2 summarizes the WALEDAC activities seen so far.
» Uses an X-Request-Kind-Code in its HTTP request header
Figure 5. Presence of an X-Request-Kind-Code HTTP header
whose value can either be a server or a node
HTTP-Based P2P Communications
WALEDAC takes a page out of Storm’s book by implementing a sophisticated communication network. It encrypts its network traffic and utilizes a peer-to-peer (P2P) model, much like Storm did. Although Storm was known for using Overnet P2P communication1, WALEDAC improved this tactic by using an HTTP-based P2P communication network coined as HTTP2P traffic2 by security researchers.
WALEDAC HTTP2P uses a complex variation of known technologies, including Rives-Shamir-Adelman (RSA) and Advanced Encryption Standard (AES) encryption using OpenSSL, an eXtensible Markup Language (XML)-based message structure, bzip2 compression, and Base64 encoding.
1 The Overnet P2P network of Storm was described by Joe Stewart in his Blackhat presentation, “Inside the Storm: Protocols and Encryption of the Storm Botnet” (http://www.blackhat.com/presentations/bh-usa-08/Stewart/BH_US_08_ Stewart_Protocols_of_the_Storm.pdf).
2 The term HTTP2P was coined by Shadowserver in a blog entry (http://www.shadowserver.org/wiki/pmwiki.php/Calendar/ 20081231).
WALEDAC uses the following technologies to encrypt communications:
» TiXml: A library used to handle messages using the XML structure. » OpenSSL version 0.9.8e: An open-source library used to encrypt messages sent from a
WALEDAC server to other WALEDAC nodes and vice versa.
» AES: Used to encrypt messages sent to other WALEDAC nodes, along with WALEDAC data stored in an affected system’s registry. WALEDAC specifically uses 128-bit AES encryption.
» RSA: Encryption method other researchers claim WALEDAC is using to encrypt session keys between a server or a node and another node and vice versa (unconfirmed).
» bzip2: Used to compress messages sent to and from WALEDAC nodes, along with data stored in an affected system’s registry.
» Base64: Used to encode messages sent via HTTP (the characters + and / are replaced first before sending the message since they are reserved characters in HTTP).
WALEDAC BINARIES
Since December 2008, WALEDAC has been posting new binaries on its website at an estimated rate of twice a day. In mid-February, however, while the WALEDAC website was donning a Valentine’s theme, the botnet began pushing new binaries even more frequently.
We started monitoring WALEDAC binaries more closely at the beginning of March 2009. A total of 3,568 samples have been collected so far—1,741 in March and 1,827 in April (as of April 24). The highest daily count so far was 120. This was equivalent to one new sample every 12 minutes. The high frequency of sample updates rendered the blacklisting of WALEDAC samples (i.e., antivirus
signatures) less effective in timely blocking all newly published samples.
2. Two 128-bit AES keys are hardcoded inside the WALEDAC binary. These keys are used to encrypt its HTTP2P traffic, along with data stored in the registry. The first key is found just before the self-signed certificate mentioned earlier while the second is found beside the first key.
Figure 7. The 128-bit AES keys and certificate found inside the WALEDAC binary
DECIPHERING WALEDAC MESSAGE ENCRYPTION AND ENCODING
The diagram below shows the general flow of the encryption and encoding of WALEDAC traffic. (Note that some encrypted messages do not follow this flow.)
Figure 8. General WALEDAC encryption and encoding routine
To decrypt and decode the original XML message, reverse the steps described above. The step-by-step decoding and decryption is shown in Figure 9.
Figure 9. General steps in WALEDAC message decoding and decryption
The following is a sample of an encrypted WALEDAC message. This particular transaction shows the first message sent by WALEDAC to another node. The first encrypted message is sent via HTTP POST to a WALEDAC node with the Internet Protocol (IP) address 12.135.152.45.
POST/oumqnpocgw.htm HTTP/1.1 Referer: Mozilla Accept: */* Content-Type: application/x-www-form-urlencoded User-Agent: Mozilla Host: 12.135.152.45 Content-Length: 957 Cache-Control: no-cache a=_wAAArbl9G7IqhWZ_HDKu0aJe7jwCLHjGrH9DDxgcc7B3Xo4Fx7s6P2h8bqEq0Fqnx-ue2vjJ_nlnvV3 YeJD8s9UPt9deldC538CHLPf1g_ZJFM9-zIe-3GaZWkCkUCwsr93p790F-y5jwZFw7HuA9k5oxiqmzhT08 gifxv6PYafAZOrSYrHGJN7hgueRbsfFxAKi6JBQ6OY2iGgyE7A57j8RWXtL-ThOmZdSRdZfGAoWloENz9 vUr5VPU-qNv7f2IFDkNdlmNukXz1_mGqV61QHY5iZpAhY7R1IgNh40bLSE3HLBrOFtHSHwo2Q3iw2uNC-Rp-C0Wm5iKQr7oqhy5bUKqbYdvFo9IFmL524ohc_Yp_VYYpmYzJ6ea2EhZzrht-L2qchP_L-sKqJhV3l5 xCIUE_MA445oHEln_jvSqyCOQsYfYAREGN6shjacro9A4v0NM1zJId8a30if1ZbOTxm7wCNe8KVDJt_JJJ936bb4HDsXZ580Oz_xf_5mD0nw-OyohwrWoXX8-m3qT24-nOj2wzE5XBRrskgWzNQuJq84TdbVc_leMT7 H-1WW-CywquAqMpHfMKju4fHGbqHNFcwgVU3AHvw1TN1B-MOxvxm3758EitkS91KrCOivsNADyAZPUGKk XKVaY61-o5w9swvRYMsDQC-5dJOh1z-BFp5jKqfmJwQCGB6m2m5T16cN21kE0lvobiIEyprItwIqjKufD qfGmIsVXsmfRDtHk-RAjiTe4NxjRSIfSrBXw5qhGMzvyE7r2tffCGyB4MkDMslNciKgizyjoW3UoSvUDl LN6F4s7SKk90c2nO3FCM9m_ShEHX6sS3rauA7hOYztFMy9UAipegY5rHfGaaEfCQK5sISXmny07LcP-6kX lRB50i7fAZZnQT_mT9kY-vW1NR93nxg_N53c_stcp9YNgOwBsFIOw&b=AAAAAA HTTP/1.1 200 OK Server: nginx/0.6.34 Date: Thu, 19 Mar 2009 09:37:05 GMT Content-Type: text/html Transfer-Encoding: chunked Connection: keep-alive X-Powered-By: PHP/5.2.8 187_wAAARJT21iVma3vUq76l5iKofYMtm6dKE6GNTwIkG8utXnNCgmzqrBh33nYaIYIskVk-OadaTe3mplnt 3CXIkErs-TTeARXl-MBi6vvX-hI3QxNAna1dk9hsehqOz6Hxm8VH26Sw4FqCyMihjASc0AMOPhvzW0SE1Ly4 RY2zbVtf9N6Xy3HzvJJe1EtW72uFGO9QhYEi-j_vwL8pXAZ1FlBvYYvNZFzD7SYYsb61r65Qds8pPGgRWuPL vvs4ljNgnlvh_lzsFlF2ObBDT5DhLLlPZiz_ZGpvFQsieUwA5R3vFyYgs78WIT26GE1FGbppi2PZYcAFX0bjM9Sq6lndqaAUhyggyg6bjdJUjhu2P5zQIAdSYEbGZXZs1ffEMH-e9QFyoI0 POST /jint.htm HTTP/1.1 Referrer: Mozilla Accept: */* Content-Type: application/x-www-form-urlencoded
Follow the steps below to decode and decrypt the WALEDAC messages described earlier to get the original XML message from the first encrypted message sent.
1. Replace the characters - and _ to + and /, respectively, found in the a=<string>. Replace the A characters from the &b=<string> to =. There is a difference between the messages sent and received. The message sent comprises two parts—the string between a= and &b= and the string after &b=. The message received, meanwhile, does not have the a= and &b= parts. The following is a sample message sent to other WALEDAC nodes with a= and &b= highlighted.
3. Concatenate the strings found in the a=<string> and in the &b=<string> following Step 1. We now have a Base64-encoded message. The value found in the &b=<string> is used as Base64 padding.
4. Base64 decodes the message, the first 5 bytes of which serves as the message header. The first byte of output refers to the command type. In this case, this is 0xff (i.e., the getkey). The next double word (DWORD) highlighted in yellow indicates the final length of data after decryption and decompression (since the resulting decrypted data will be a compressed bzip2 archive). In this case, this is 0x2b6h, which is equal to 694 bytes. The rest of the decoded message is AES encrypted. Note that some encrypted messages do not have 5-byte headers.
5. Decrypt the message using the AES key. The message that should be decrypted must not include the command type and DWORD values mentioned in Step 3. Since this is the first message sent, the AES key is the first key found in the binary. The output is a bzip2-archived data, which can be identified by the first 5 bytes, \x42\x5a\x68\x39\x31 = BZh91.
6. Uncompress the data using bzip2. The result is an XML message with a length of 694 bytes (as mentioned in Step 3). The XML node <t> shows the command, <v> shows the version, <i> shows the identity of the machine that sent the message, and so on. The certificate found inside the WALEDAC binary is likewise included in the XML message.
The first reply is interesting. The steps in decrypting the first message as shown earlier in Steps 1–5 should be done to decrypt it. Note that the message received does not have the a= and &b= parts as shown below.
The node reply contained a Base64-encoded message that contains the new AES key that will decrypt the next message-related transactions. The decoded Base64 message will be:
The message is encrypted using the RSA public key found in the certificate that is hardcoded in the WALEDAC binary, given that this is the very first transaction of such sort (a new certificate is used in subsequent transactions with other nodes). To get the new AES key in this example, a WALEDAC RSA private key3 should be used to decrypt the message. The private key remained unknown at the time this report was written.
After obtaining the new AES key (from debugging the WALEDAC binary), researchers can now decrypt the next message transactions with other nodes. An example of the second request is shown below.
We also observed that the new AES key used by WALEDAC did not change even after several transactions. The new AES key could still decrypt new message transactions from updated copies of the WALEDAC bot. From our tests, the AES key could also decrypt messages from WALEDAC binary versions 32 and above. We are uncertain if this is true, however, with versions prior to WALEDAC version 32.
3 Discussed by Greg Sinclair of NNL-labs (http://www.nnl-labs.com/cblog/index.php?/archives/7-WALEDACWALEDACs-Communcation-Protocol.html).
WALEDAC also makes other requests that do not have the 5-byte message header after Base64 decoding. They also do not have the a=<string> and the &b=<string> from this particular HTTP request as shown in the sample message below.
The message is quite long (truncated on purpose) but is fairly easy to decrypt. The steps described earlier are still applicable, the only difference being after Base64 decoding, all data should be considered, including its first 5 bytes. AES decryption using the first AES key found in the WALEDAC binary is then performed, after which, the data is uncompressed using bzip2.
The following decoded and decrypted message is the bot or server message reply to the HTTP POST request by the WALEDAC binary from IP 24.21.164.180 as shown above. This message can be an updated list of other WALEDAC nodes:
Another form of encrypted message that does not have a 5-byte header is sent by a server or a node when WALEDAC issues an HTTP GET request to /index.php on one of its domains as shown below.
GET/index.php HTTP/1.1 User-Agent: Mozilla Host: greetingguide.com HTTP/1.1 200 OK Content-Type: text/html Transfer-Encoding: chunked Server: nginx/0.6.33 Date: Tue, 03 Feb 2009 21:09:10 GMT Connection: keep-alive X-Powered-By: PHP/5.2.8 496
The encrypted server reply can also be decoded and be decrypted by following the steps discussed earlier. Note that after the Base64 decoding, however, the second AES key should be used. The result is the original XML message shown below. bzip2 is no longer used in decompressing this part.
Other encrypted data is found in the registry of the affected host machine, specifically in the RList found inside HKCU\Software\Microsoft\Windows\CurrentVersion as shown below.
Figure 10. Data stored in registry
The binary data is encrypted using either of the two AES keys found in the WALEDAC binary. Decrypting the data using AES yields bzip2-compressed data, a section of which is shown below.
Figure 11. bzip2-compressed data from the registry
Uncompressing the bzip2 data above reveals XML data containing a list of WALEDAC nodes, which is used to record the most recent known peer nodes below.
Figure 12. Deciphered data from registry
WALEDAC HTTP2P Communication Protocol
WALEDAC uses several commands to control nodes. A node can be designated as a spamming node or a command proxy node. This paper focuses on a WALEDAC-infected machine designated as a spamming node.
As mentioned earlier, WALEDAC’s commands uses the XML message structure to pass information around. The following is the standard structure of a decrypted HTTP POST, the method used by a WALEDAC node to communicate with a WALEDAC proxy, which then relays the communication to the WALEDAC command and control (C&C) using values4:
The reply from the proxy node slightly differs in structure from a WALEDAC spamming node. The following is the standard structure of a decrypted reply from a WALEDAC C&C:
Omitted in the reply is the node id while the order of the command type and the WALEDAC bot version is transposed.
There are nine known WALEDAC commands identified by type, namely, ff, 01, 02, 03, 04, 05, 06, 07, and None, each of which is used for a specific purpose. Appendix C shows sample POSTs and replies for each command type.
Command Type: FF (GETKEY)
This command serves as an authentication routine for a WALEDAC node. This is the first command commonly issued by the WALEDAC node when communicating with the WALEDAC C&C before requesting for or before issuing other commands.
In our sample, a WALEDAC node sends a certificate and receives a reply with an AES key. This certificate is the same one found in the WALEDAC binary, which changes from file to file, meaning each WALEDAC node has a unique certificate.
Command Type: 01 (FIRST)
This command contains information on what Windows OS version the WALEDAC node runs on as pointed out by the winver attribute (in our sample, the value is 5.1.2600, which refers to Windows XP).
The C&C gives an empty reply, implying that this particular command is stateless and merely serves to inform the WALEDAC group about the Windows OS version the affected system runs on.
Command Type: 02 (NOTIFY)
For this command, the WALEDAC node just POSTs the date and time when it started running (i.e., time_init), the current date and time (i.e., time_now and time_sys), and how long the affected system has been running (i.e., time_ticks). The text string mirabella_site is hardcoded in the WALEDAC binary as well.
Among all the commands, the replies to Command type 02 from the WALEDAC proxy is the most baffling, mainly because some of its content appear to have no relation to WALEDAC activity.
The reply contains the text content wergvan, which appears to be a spoofed domain when communicating with a mail server for spamming purposes.
Figure 13. Text content wergvan
The element <p n=“ip”>203.177.193.xxx</p> in the reply is the external IP of the infected node while the text for the dns_ip and smpt_ip attributes remain unknown since the IP addresses they supply are not consistently seen in network traffic.
http_cache_timeout seems to be a configuration that indicates how long a transaction with a WALEDAC proxy remains valid (in this case, 60 minutes) while the sender_threads and sender_queue seem to be configurations of how many threads and email messages can be generated at any given time, respectively.
The short_logs attribute always has a TRUE text value.
The commands attribute is the most interesting in Command type 02. The text content [CDATA[337|update|http://usabreakingnews.com/mir.jpg340|download|http://usabreakingnews.com/win.jpg] appears to be an instruction to download the files mir.jpg and win.jpg.
Most of the time, these files are plain Joint Pictures Experts Group (.JPEG) files. However, a few instances where WALEDAC updated the spamming node through an embedded and encrypted WALEDAC binary inside the .JPEG files were also seen.
In the three months of WALEDAC monitoring, the spammer node downloaded 11 malware using this method, five of which were updated WALEDAC binaries while the remaining six were rogue antivirus malware.
This technique gives WALEDAC a complicated self-updating method and helps explain the highly homogeneous node variants comprising the WALEDAC botnet.
The images shown below are downloaded from the links found in Command type 02 and were used to carry the WALEDAC binaries. These pictures may have been chosen to humor either the players behind WALEDAC or the security researchers snooping on the botnet’s activities.
Figure 16. Sample images downloaded from links found in Command type 02
Command Type: 03 (TASKREQ)
For Command type 03, the WALEDAC spamming node just sends a short POST message to the WALEDAC proxy node. It appears to be a request by the WALEDAC spamming node for tasks coming from the WALEDAC proxy. A lengthy reply in the following format is then received:
<task id=“(id)”> <body>(b64 encoded string)</body> <a>(target e-mail address)</a> <a>(target e-mail address)</a> … … <w>(name of list - to be used in spam e-mails)</w> … … </task> </tasks> <words> <w name=“(name of list)” time=“(time)”/> … … </words> </lm>
1. Proxy node version: Our sample reply reveals a WALEDAC version 27 proxy, which is a lower version compared with that of the WALEDAC version 34 spamming node. All Command type 03 replies are in version 27, suggesting that the proxy nodes used in the command are probably not being updated.
2. Tasks: Furthermore, the <tasks> element has two child elements, namely, <task id=“4”> and <task id=“3”>. These contain additional child elements that can be used for a particular spam run.
Since the tasks are defined by the group behind WALEDAC, Command type 03 gives WALEDAC controllers the ability to control spam runs—when to begin, what to spam, who to send spam to, what the email body and subject should contain, and what domains and URLs to include.
3. Body: The <body>(b64 encoded string)</body> element contains the email body format of the spam run. Decoding the Base64-encoded string reveals the following:
4. Target email addresses: After defining the email body format, the next elements contain the target email addresses enclosed in <a></a> tags. Each task contains exactly 500 target email addresses.
5. Name of list: The next elements contain words that are on a list of words that is used to construct the email body and email details.
These words are passed on as parameters when requesting for a new list, a dictionary, or a string array using Command type 04.
Command Type: 04 (WORDS)
Command type 04 updates WALEDAC’s words or word lists that are used in a particular spam run.
To explain how Command type 04 works, we used the Command type 03 sample reply, specifically for task id=“4”.
The Base64-decoded email body format looks like the one below.
In the example above, the spammer needs to get the word lists for the cupo_string, the cupo_link, and the cupo_file since they are not included in the task child elements.
Command type 04 provides WALEDAC spamming nodes the ability to request for and to update word lists. It also provides WALEDAC’s handler the ability to update words, phrases, and values to create virtually unique and dynamic emails.
The following is a sample spam advertising free coupons that lead to WALEDAC binaries. WALEDAC randomly chooses which entry from each word list to use. Note the words in the sample coupon spam labeled with the word list from which each they were taken:
WALEDAC spoofs the email From field by supplying a fake name from mynames and by constructing a fake email address by concatenating an entry from name and domain word lists (i.e., <name from names>@<domain from domains>).
In the image below, the values chosen from mynames, names, and domains word lists that serve as spoofed From values are labeled accordingly.
Figure 18. Labeled values from mynames, names, and domains word lists
In the preceding image, WALEDAC emulates a Microsoft Outlook mail user agent. WALEDAC supplies a value for the character set X-Mailer and MimeOLE from the charset and outver word lists.
WALEDAC also changes other parts of the Simple Mail Transfer Protocol (SMTP) header, probably in an attempt to confuse spam filters or mail server restrictions.
The element attribute b64 whose value is TRUE means the succeeding attributes under reports are Based64 encoded. Based64 decoding attributes reveals the following:
The email addresses are the target recipients provided by the WALEDAC C&C in Command type 03 (domains blurred due to privacy concerns), the text content OK and ERR signifies whether the spamming node successfully sent spam to the particular address or not.
Command Type: 07
This command type reports to the WALEDAC C&C a list of email addresses found in the affected system. This is done by searching for plain-text email addresses in files. This command not only gives the group behind WALEDAC the ability to gather new email addresses to spam but also to filter certain email addresses or certain domains that they want to blacklist to prevent them from receiving the WALEDAC spam.
The C&C reply to this particular message seems to be just an acknowledgment that the message was indeed received.
Command Type: NONE
This is not actually a command type since it does not have a command type number or a command name in the communication. This is basically WALEDAC’s method of sharing and updating available nodes to contact. In the sample POST in Appendix C under None, we can see the IP address, port, time, and node ID in the node attributes. Note that both the POST and the reply follow the same message format.
WALEDAC Command Distribution
Of course, not all commands are equal in terms of distribution. The figure on the next page shows more than two months’ worth of WALEDAC commands broken down by type (i.e., per reply or per POST transaction and not per bytes of data).
Figure 21. Percentage distribution of WALEDAC commands
Among the command types, Command type none, which shares peer node IP addresses, occupied the biggest chunk. This means that a lot of the WALEDAC traffic is dedicated to ensuring that the nodes the bot connects to are updated.
The second largest chunk, unsurprisingly, belonged to the getkey or the so-called handshake command, which serves as an authentication routine for WALEDAC nodes.
Updating word lists to generate spam took the third biggest chunk, confirming the fact that WALEDAC spamming nodes are designed to be active spammers. It also makes sense that the taskreq command only came after the words command since WALEDAC nodes report successful and unsuccessful spamming attempts.
Both the notify and taskreq commands are intriguing, especially if we consider that spam targets are defined by taskreq replies. So it is quite surprising on our part to see notify transactions having a bigger chunk than taskreq replies. However, a taskreq reply contains at least two spam formats and at least a thousand target email addresses, lessening the need for frequent updates, resulting in a lower number of taskreq transactions compared with other command types. On the other hand, notify transactions are made at least every hour, implying spammers’ firm effort to keep WALEDAC nodes updated.
Unsurprisingly, the smallest number of transactions belonged to the emails command, which reports discovered email addresses to the WALEDAC C&C.
WALEDAC commands are sent through proxy or through repeater nodes, which then relay these to the WALEDAC C&C. On a daily basis, a spamming node sees around 660 unique WALEDAC proxy IP addresses broadcasted through the use of the none command. These are then used by WALEDAC spamming nodes to proxy command transactions and to conduct other WALEDAC-related activities.
Estimating how many have been affected by the WALEDAC botnet is quite a task since it is dynamic in nature—nodes are constantly being added to (i.e., representing new infections) or being removed from (i.e., upon discovery and upon removal of the infection) it. With this in mind, a rough calculation of the size of the population that has been affected by WALEDAC on any given day can instead be done.
To do this, two assumptions should be kept in mind:
1. The number of clients outnumbers that of servers (in the same way that the number of spamming nodes outnumber that of proxy nodes).
2. The current client-to-server ratio is 10:1.
Since an average of 660 WALEDAC proxies operate on any given day and, considering the aforementioned assumptions, it can be gleaned that there are at least 6,600 spamming botnets sending out spam every day. Note that the visibility of the breadth of WALEDAC nodes has been limited to the botnet segment we monitored.
On an average digital subscriber line (DSL) connection with a 0.2Mbps download and a 0.11Mbps upload speed, WALEDAC generates around 140,000 spam per day. So, assuming that 6,600 WALEDAC spamming nodes operate per day, the WALEDAC botnet is capable of spewing at least 924 million spam per day.
WALEDAC Proxies and Fast-Flux Networks
Another interesting discovery we made while investigating WALEDAC is that some proxy nodes and not only proxy WALEDAC commands are also part of the fast-flux system used by WALEDAC-related domains.
In the image below, the green-colored IP addresses represent proxy nodes while the blue-colored ones represent fast-flux networks. The red-colored IP addresses are used as both WALEDAC proxies and fast-flux networks. Based on our WALEDAC monitoring, around 7 percent of the total number of WALEDAC proxies are also used as parts of fast-flux networks.
Figure 23. WALEDAC proxies and fast-flux networks
Spam and Domain Information
The spam sent by WALEDAC and the domains of the links found therein exhibit characteristics associated with various spam groups, suggesting that it was primarily built as a spamming platform for rent.
From The Spamhaus Project’s top 10 known spammers, at least three groups appear to be renting out WALEDAC-spamming services, including:
» Canadian Pharmacy » Leo Kuvayev/BadCow » Yambo Financials
These groups are responsible for the majority of pharma spam (for Viagra, penis-enlargement, and other related subjects), original equipment manufacturer (OEM), pornographic, and fetishistic spam seen in mailboxes, all of which were seen during our WALEDAC monitoring.
Aside from the spam categories mentioned above, a mule spam targeting a specific language was also seen. This hints at WALEDAC-spamming services being made available not only to the top spam groups but also to smaller such groups with smaller target populations.
The domains used by WALEDAC to host its website were all registered at Ename Corp. Most of the spam domains advertised by WALEDAC were also registered at Ename. See Figure 14 in Appendix A for a sample of the whois output for a domain used in the bombing news campaign.
The said rogue antivirus endlessly disrupts users with warnings about malware infections in their systems. It even interrupts users’ Web-browsing activities.
Figure 25. MS Antispyware 2009 alerts the user of spyware and other malware attacks
Figure 26. MS Antispyware 2009 blocking Web browsing
» WALEDAC’s primary business model is spamming but it is also used as a platform to introduce other malware to affected systems. WALEDAC is in business with at least three of the top 10 spammers identified by The Spamhaus Project. It is also involved with distributing rogue antivirus, which is currently one of the most prevalent security threats.
» The creators of WALEDAC are knowledgeable individuals, exhibiting a certain degree of comprehending computing concepts such as P2P and distributed computing and the acumen to use technologies such as encryption and XML. These people are not run-of-the-mill programmers or hackers. Most concerning of all:
» They seem to be aware of and intend to capitalize on existing underground business opportunities.
» They are knowledgeable about antivirus, antispam, and Web-blocking technologies. In fact, each of WALEDAC’s most important components (e.g., binaries, spam, and domains) are all programmed to be dynamic in nature in order to evade detection.
» WALEDAC is playing a numbers game, which serves as its strength. It maximizes its ability to update various aspects of its operation, thus posing a volume challenge in terms of the sheer number of affected systems and proxies, spam sent, and spam and malware domains it uses.
» WALEDAC embodies the collective knowledge of the cybercrime community of what works and what does not. It has also been said that “WALEDAC is the new Storm,” which is right in that WALEDAC copied and even improved aspects of Storm that made the latter successful. Its use of HTTP for C&C makes a lot of sense as well since HTTP is much more common than Overnet P2P, thus making it harder to identify and to block the C&C traffic that WALEDAC produces. This proves the cybercriminals’ ability to adapt to changes, making them even more dangerous.
» The people behind WALEDAC are doing their best to remain unknown. Their use of infected proxies and the act of registering domains to registrars linked to spam and malicious domains are meant to obscure their identities.
At the time this report was written, WALEDAC was seen to have used eight social engineering attacks in an effort to make would-be victims run the malware. WALEDAC started out with the Christmas Ecard ploy.
As the holiday season progressed into the New Year, so did WALEDAC’s campaign. The spam and their websites continued to use the ecard approach. This time, however, the ecards they sent contained New Year’s greetings.
With the U.S. presidential election flurry coming to a crescendo in January 2009, WALEDAC started sending out spam for its new campaign. The email campaign then carried the bad news that “Obama refused to be the next president.”
Figure 5. WALEDAC email carrying the news that Obama refuses to be the next U.S. president
Figure 6. WALEDAC rips text off from Obama’s website,
bearing false news that he no longer wants to be the president
After taking advantage of Obama’s presidential campaign, WALEDAC then turned its sights to Valentine’s Day.
The Valentine’s ecard website later changed with the addition of some text at the bottom of the image, which seemed to target software developers, to promote Valentine Devkit, which was, of course, a WALEDAC malware.
The displayed images on the Valentine-themed websites later changed using a pool of several images with romantic themes. Several of these pictures are shown in Figure 10.
Figure 10. Pictures simultaneously displayed by Valentine-themed WALEDAC sites
Some time later, the coupons website was updated with a GeoIP component, which enabled it to determine the user’s location. This geographic location feature was used to make localized versions of the coupon website, which made its social engineering ploy even more potent.
Figure 13. Using GeoIP, WALEDAC was able to create localized versions of the coupons website
(Note the inclusion of the user’s city name in the webpage.)
The geographic location feature of the localized websites was heavily used in WALEDAC’s next campaign—the terrorist bombing scare.
Figure 14. Spam carrying dire news of terrorist bombings
The websites were copycats of the Reuters news pages, complete with supposed videos of alleged bombing incidents.
Figure 15. WALEDAC terrorist-bombing website
The fake Reuters webpage used the classic “You need the latest Flash Player” dialog box. Clicking the link leads users not to the Flash Player download page but to one where they can download the WALEDAC malware.
WALEDAC then shifted gears to promote spying on somebody else’s short message service (SMS) messages, notably of one’s partner or lover. The spam was designed to provoke people’s paranoia or fear that their partners may be cheating on them.
Figure 16. WALEDAC’s email campaign to provoke paranoia
with regard to being cheated on by one’s partner
The URLs in the spam point to websites that advertise free-trial downloads, which are capable of spying on the SMS messages in somebody else’s mobile phone without even installing it.
Unfortunately for those who installed the SMS Spy program, all they got was the WALEDAC bot.
Besides pharma spam, WALEDAC also sends out spam enticing users with OEM software at discounted rates.
Figure 7. WALEDAC OEM spam
This OEM spam did not promote any website. Instead, it advertised the email addresses of people who sell the so-called “OEM software.” Some of the email addresses we have seen were:
There are nine known WALEDAC commands identified by type, namely, ff, 01, 02, 03, 04, 05, 06, 07, and None, each of which is used for a specific purpose.
<lm> <v>33</v> <t>words</t> <props></props> <word name=“cupo_string”> <![CDATA[20-95 % off! Best shops! A good way to cut down on costs A good way to save money is to use these coupons A special discount voucher listing … … … Hot deals in your city Hottest coupons for you I discovered a great deal I found a fantastic bargain I found great sales I guess you’ll need it … … … You’ll be glad to see this You’ll thank me You’ll thank me for this!]]> </word> </lm>