Rustock

Deployment, Payload, and Backup Control Mechanism

As Rustock evolved, so too did its payload. It was initially designed to send out spam email, and was originally associated with the McColo infrastructure and the Russian Business Network (where installers had been seen being hosted). Typical spam messages that it sent often related to pharmaceutical products or fake pharmacy sites, or linked to pages that occasionally hosted additional malware.

Rustock was also observed directing traffic to rogue security software sites that duped unsuspecting users into purchasing and installing phony antivirus products using social engineering techniques. In addition, Rustock was known to install rogue security software and other malware onto infected computers directly and through drive-by exploits.

The DCU performed an experiment in conjunction with the MMPC in which a closely monitored host was infected with Win32/Harnig (a known Rustock dropper) to determine what additional malware would get installed. Within five interaction-free minutes of infection, a wide variety of additional malware and unwanted software had been downloaded and installed onto the infected computer, as shown in the following figure:

Figure 1 . Threats installed by Win32/Harnig within five minutes of infection

Threats installed by Win32/Harnig

Click on the Image to Enlarge

Many of the threats listed in Figure 1 are themselves designed to download yet more threats at various intervals.

Multiple layers of trojan downloaders form complex chains of relationships between the owners of different malware networks. Botnet access is often cited as being available for rent, but so too is access to downloader locations. This access is evident by the fact that the files pointed to by downloaders constantly change—sometimes they are swapped out for newer versions of the malware or versions that were obscured in different ways, and other times they’re swapped out for something different altogether.

It should be noted that Rustock employs a modular payload architecture: the user-mode bot client known in earlier versions as botdll.dll could easily be replaced with any other payload. Although Rustock spent most of its time sending spam, it could have easily been used for virtually any nefarious purpose with very minor modification.

Backup Control Mechanism

When the C&C servers were unreachable, Rustock had a fallback mechanism it relied on to re-establish communications. The malware includes an algorithm that generates 16 new domain names daily, consisting of nonsense strings of characters such as jvwyqarglgwqvt.info and hy38la8rwpaqlpiy.com. Infected computers then attempt to contact each of these domains. The Rustock operators would use the same algorithm to generate the domain names in advance and use them as command-and-control points. Rustock variants have been identified as using six different algorithms that each generate different domain name lists, for a total of 96 new domain names each day. As explained in the “Rustock Statistics” section later in this report, Microsoft researchers have been able to take advantage of this mechanism to obtain valuable information about the spread and scope of the Rustock botnet.

Top of page Top of Page
Featured Articles

Locations

United States Change All Microsoft Sites

Search

Feedback:

Was the information in this article helpful?