Waledac Botnet - Deployment & Communication Analysis

Research and Analysis: Kyle Yang
Editor: Derek Manky

0x10 Overview - The Waledac Botnet

Historically, Botnets have used IRC (Internet Relay Chat) for control. This has a critical drawback, which is its server/client architecture. We could find the server/RP (Rendezvous Point) easily since it’s really hard to hide them based on their server/client model. As a result of this architecture, the entire Botnet will be stopped if we take down the server/RP. In recent years, Botnets have moved to use P2P technology. One of the most remarkable examples is the Storm Botnet, which was prevalent in 2007[1]. At the time, it was the world's most active and infamous Botnet, with a sophisticated C&C channel which created a high impact on spam sent worldwide. Waledac enhanced its predecessor[2] by abandoning the server/client model, moving forward to use P2P to control its bots. The P2P architecture performs as a protector/shield of the server/RP in an effort to hide them from being found. This also allows the “controller” to control the Bots completely decentralized. Waledac's main purpose is to send spam, usually by taking advantage of many real-world events - social engineering that tricks users into downloading copies of itself or other malicious executables. Notable Waledac spam campaigns include Valentine's day, Obama presidency, The "Couponizer", 4th of July, and Bomb Scares.

[1] The Storm Botnet was not the first Botnet use P2P mode: Slapper, circa 2002 and prevalent in 2003, was the first profiled one
[2] Enhancements include the addition of authentication when communicating with other Bots (nodes)


0x20 Waledac Binary Characteristics

Like the Storm Botnet, Waledac also spreads itself with a custom packer. The custom packer is more likely modified UPX with lots of jump instruction blocks. The goal of doing this is evident: hindering AV protection by concealing the functionalities of their code under an efficient veil of obfuscation layers. This custom packer has a tremendous amount of jump instructions and anti-debugging tricks, though it does not contain any anti-vm (virtual machine) techniques. If you’re trapped by the anti-debugging tricks, it will lead you to another code routine. The real unpacking routine is entered after 83 jumps, and there is a large loop just before it enters this routine. This is designed to force any emulator to exit, due to time out and/or debug segment thresholds: the loop will generate lots of debug segments, which can make the emulator exit when the maximum segments have been reached. As a result, it can be very difficult for researchers to analyze Waledac samples. Figure 1 shows the graphs of jump flow (on the left) and the final instructions of the custom packer which will call the unpack routine (right image).



Figure 1: Custom packer jumps (left) and final function call graph (right)

0x30 Waledac Installation & Node List (RList) Generation

When Waledac is first executed, it will add an auto-run registry entry so it will run when windows starts:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\PromoReg = [Waledac Executable File Path]
HKCU\Software\Microsoft\Windows\CurrentVersion\Run\PromoReg = [Waledac Executable File Path]

Hardcoded in the binary are node IP addresses (secondary server IPs), and hashes used in the initial communication when retrieving the updated secondary server list, AES key and binary. The downloaded, updated node list is stored in the regisry as well - using the key "RList": HKLM\Software\Microsoft\Windows\CurrentVersion\RList

Whenever a new list is retrieved, this registry entry is updated and used as a reference if the system reboots. The Waledac binary forms the RList key in an XML structure, just like its handshake with a secondary server (see Initial Communication below). This formed XML structure, composed of secondary server nodes, is then BZip compressed and encrypted using a hardcoded AES128-bit key. After this has occurred, the "RList" key is overwritten with the newly formed, encrypted value. Figure 2 shows the XML structure and the RList generation flow:



Figure 2: RList generation flow

0x40 Botnet Architecture

There are 2 kinds of operating modes for the Waledac Botnet:


1) Secondary Server/Proxy Mode

An infected machine may be designated as a server/proxy, which is preferable when the machine has a public/routable IP address. The secondary server’s main functions are to:

  • Verify and update all bots’ secondary server list
  • Serve binary updates
  • Distribute tasks to clients, such as spam and DDoS attacks

2) Client Mode

Contrary to a server/proxy, a machine may have a private address and be designated as a client node. The client's main function is to execute the tasks which are sent from the secondary server, performing zombie "grunt work".


0x50 Initial Communication

The Waledac binary contains a hardcoded X.509 certificate (Figure 3) used to establish the initial communication with a secondary server. This is a self-signed certificate, as the issuer and subject are the same. Also included is an RSA public key, followed by the signature - computed by taking a SHA1 hash of the first part of the certificate and encrypting it with the RSA private key. Some Waledac binaries are using an MD5 hash on the certificate instead of SHA1. New versions of Waledac will contain different, freshly generated certificates. Figure 3 below shows sample certificate information:



Figure 3: Decoded certificate information

Before newly added bots begin to work, they will send this X.509 certificate to the secondary server, using the command “getkey” (0xFF). The secondary servers in which to communicate with are retrieved from either the hardcoded list in the binary, or the "RList" entry from the registry. Waledac communications are encapsulated in XML format, using the following elements:

  • l – 16 byte hex number
  • lm – Root element of XML
  • t - Commands
  • v – Version number (hardcoded in the Waledac binary)
  • i – Unique identifier of the bot (randomly generated)
  • r – Bot mode: 0 == Client, 1 == Secondary Server
  • props – Properties/state of clients
    • n - Name

When forming the XML structure for initial communication, the following elements are added in sequence:

  1. The l and lm element are formed to mark the root of the structure
  2. The t element is used to form the command "getkey"
  3. The v (version) and i (unique identifier) tags are appended
    • The identifier (i) will be stored in the registry key value "HKCU\Software\Microsoft\Windows\CurrentVersion\MyID"
  4. The r element, bot mode, is then added
  5. Properties are formed
    • The property value n (name) is assigned to "cert", the certificate

The formed XML structure to be sent is shown above. Before sending, the data is first bzip compressed. Then, it is encrypted using AES128 and a key that is hardcoded within the binary (located before the X.509 certificate), followed by the addition of a 5 byte header (0xFF). Finally, the encrypted data is encoded with Base64 - after which, certain characters are replaced: "/,=" replaced to "_", and "+" to "-". This is because "/" and "+" are reserved characters in URL strings when using "application/x-www-form-urlencoded". This finalized sequence is prepended with "a=" as a variable to pass during HTTP Post. Likewise, the variable "b=" is appended using a static string which contains many upper case A characters for use as Base64 padding. Figure 4 shows the flow of this generation, beginning with the formed XML structure:



Figure 4: Packet Data generation flow

This data is then posted to the secondary server, as seen in Figure 5:



Figure 5: HTTP Post using the finalized data

To summarize, the following sequences are formed during initial communication:

  1. Form XML structure
  2. Bzip compress structure
  3. AES128 encrypt compressed data with hardcoded key
  4. Add 5 byte header (0xFF)
  5. Base64 encode encrypted data
    • Substitute certain characters after encoding for proper forming
  6. Add variable tags
  7. HTTP Post data to secondary server

The secondary server will reply to above HTTP Post as follows in Figure 6:



Figure 6: HTTP Post Reply Data

The reply packet is a Base64 encoded, RSA encrypted value for a new AES key which will be used to encrypt following communication. If the bot fails to get the updated secondary server list (RList) after 10 minutes, it will fall back to a fixed location using HTTP Get - ie: "hxxp://cismosis.com/up21.php". After this initial communication has finished, it will create the registry value "74 72 75 65" set to true in "HKCU\Software\Microsoft\Windows\CurrentVersion\FWDone".

As you can see, ensuing communications will be encrypted using a new, dynamic key that is returned after this initial sequence. On top of monitoring and detecting new binaries with antivirus for Waledac (ever changing with its custom packer), FortiGuard IPS also detects traffic from this described initial communication phase as "Waledac.Botnet".