Rustock and All That

The elusive rootkit

In December 2006, rumors began to circulate among rootkit researchers (both blackhat and whitehat) that someone had created and released an ‘absolutely undetectable’ rootkit, Rustock.С, which could not be detected on computers where it was active by any of the existing antivirus or anti-rootkit solutions.

A long search for the ‘mythical rootkit’ yielded no result. As a consequence, any information about Rustock.C was treated as a joke in circles close to rootkit researchers. This continued until May 2008.

‘Doctor’s’ diagnosis

In early May, the Russian company Dr.Web announced to the antivirus community that its experts had detected a new rootkit called Ntldrbot, aka Rustock.С. This piece of news was about as unpleasant as it was sensational.

According to Dr.Web, the rootkit had eluded all antivirus vendors since October 2007. It was suggested that Rustock.C was used to create one of today’s most extensive zombie networks for sending spam. Dr.Web also referred to a study conducted by Secure Works, according to which the botnet created using Rustock was the third-largest zombie network, capable of sending up to 30 billion spam messages every day. However, it is unlikely that the Secure Works estimate had anything to do with the newly-detected rootkit, since it was virtually unknown until May 2008. In all probability, Secure Works experts meant the botnet created using the earlier variants of Rustock – А and B (Trojan-Clicker.Win32.Costrat and SpamTool.Win32.Mailbot, according to Kaspersky Lab’s classification).

Judging by the information published by Dr.Web, the company’s experts obtained a sample of the real Rustock.С in late March 2008 and it took them over a month to analyze the rootkit’s code and create and release tools enabling its detection and treatment. Other antivirus companies were only notified of the finding after this.

The description of the rootkit prepared by Dr.Web left too many questions unanswered. First and foremost, it was completely unclear how and when the rootkit had spread and why nobody had detected it since October 2007.

The sample of the rootkit’s body distributed by Dr.Web was a 244,448-byte Windows driver.

Unfortunately, the so-called dropper, i.e., the file designed to install the rootkit on the system, was missing. If it had been provided, this file could have significantly simplified the work carried out by other antivirus laboratories to analyze the rootkit and develop procedures to detect and treat Rustock.С. It might also have helped to clarify how the rootkit had originally spread.

There was also no reliable information about the existence of the rootkit ‘in the wild’. There remained the possibility that Rustock.С was nothing more than a ‘collector’s item’ and was not widespread, which would explain the length of time that it had taken to find it.

Laboratory analysis

Kaspersky Lab began performing in-depth analysis of the rootkit’s code on May 12. The task faced by our experts was truly difficult, since the rootkit’s entire code was encrypted using an unknown method and could not be analyzed using the usual compressed-code analysis and emulation techniques. Further complicating the problem was the fact that each rootkit file had some kind of hardware binding to the infected computer and could not be executed and analyzed on other computers or virtual machines.

However, it only took our experts two days to overcome these difficulties, crack the key and decrypt most of the rootkit’s body. On the evening of May 14, we were able to view portions of the real code of Rustock.С.

However, it only took our experts two days to overcome these difficulties, crack the key and decrypt most of the rootkit’s body. On the evening of May 14, we were able to view portions of the real code of Rustock.С.

When was the rootkit created?

Thus, we had six hundred files of differing sizes that had been caught in our honeypots at different times. All the files had been collected during the period from September 10, 2007 to May 14, 2008. Leaping ahead of the story, I can say that we never found any samples of Rustock.C created before September 2007. It is possible that some variants developed for testing purposes and other early attempts by the author appeared before this time. However, what Dr.Web calls Ntldrbot definitely dates from September 2007.

So, what about the rumors of Rustock.C that were circulating widely as far back as the end of 2006? We believe that Rustock.C did not exist at that time. It was created after a promotion of sorts in rootkit researcher circles – possibly, in response to the hysteria that accompanied the search for it. Indirectly, this conclusion is supported by the fact that the malicious program’s name included in the rootkit’s code is ‘Rustock.С’. This is different from the names given by the author to the Rustock.A and B variants (‘spambot’ plus version number). The name Rustock was given by Symantec to the first variants of the rootkit dated 2005 and 2006. This was the name used by rootkit researchers, and the ‘elusive’ rootkit was named Rustock.C by analogy with the known variants, Rustock.A and .B. Therefore, the author may have given this name to the new rootkit to confirm the rumors that it in fact existed.

In any case, the first ‘operational’ samples of Rustock.С appeared in September 2007 and its development obviously started several months before that.

Modifications

The analysis of the 599 available files revealed many interesting details that had previously been unknown.

We identified four modifications of Rustock.С.

Variant C1 is dated September 10, 2007. The rootkit’s ‘pure body’ is 244,440 to 244,512 bytes in size and includes a driver and a DLL. This was the modification studied by Dr.Web experts and presented to other antivirus vendors.

Variant C2 is dated September 26. It is between 158,432 and 158,464 bytes.

Variants C3 and C4 were created on October 9 and 10, 2007. Their size varies from 158,400 to 158,496 bytes.

Although modification C1 is almost 100 KB larger than the ones that followed, there are no essential differences between this and other modifications. The author only optimized the obfuscation algorithm for the rootkit’s body. The DLL code (spambot) differs slightly from variant to variant.

The spambot

It took us five days to analyze the rootkit: it was fully unpacked and executed on virtual machines (in spite of the fact that we did not have a ‘dropper’). This gave us access to the code of the DLL (the spambot) the maintenance and protection of which is the main purpose of Rustock.С.

In the process of its operation, the rootkit extracts the DLL from its body and executes it in the system memory, injecting it into the winlogon.exe process. The DLL only exists in RAM and is never present on the hard drive in the form of a file. Its purpose is to send spam from an infected computer. To perform this task, it connects to a server at 208.66.194.215 and receives message templates from it. The IP address belongs to the US hosting provider MCCOLO, whose resources have long been used for distributing malicious programs and hosting cybercriminal sites.

Detection and treatment

Despite the various methods used by the author to protect the body of Rustock.С (including the protector, encryptor and encryption key), adding the rootkit to Kaspersky Lab antivirus databases was not a problem. It appears that whoever created the rootkit was so confident of its effectiveness that they did not attach much importance to thwarting antivirus protection. The author’s objective was to make analyzing the code as difficult as possible (both for antivirus vendors and for other virus writers) and to increase the time this would take, which is exactly what all the encryption technologies employed in the rootkit were designed to do.

Treating system files infected by the rootkit is somewhat more problematic. The rootkit works by infecting only Windows drivers developed by Microsoft that launch at system start. This is how the rootkit was able to take over the system and conceal its presence at the same time. The original driver that was infected was stored in the last section of the rootkit’s body and was also encrypted.

The algorithm used by the rootkit to encrypt the body of the driver it infected turned out to be fairly simple and was not bound to the infected computer’s hardware in any way. This enabled us to fully implement detection and disinfection.

The rootkit was classified as Virus.Win32.Rustock.a, since Rustock is in fact a fully functional file virus that operates in kernel mode.

Kaspersky Lab released procedures for the detection and treatment of infected files on May 20, 2008 (8 days after research on the rootkit began).

Detection of the rootkit when it is active on an infected system and treatment of infected files is fully implemented in the new version of Kaspersky Lab’s antivirus products – Kaspersky Anti-Virus 2009 and Kaspersky Internet Security 2009. Users of other versions can scan their computers for Rustock using the Rescue Disk for any version of Kaspersky Lab’s antivirus products. They can also detect and disinfect suspicious files provided that the infection is not active on the computer.

Questions and answers

At this point it would seem that the problem has been solved: the rootkit has been defeated and its victims have received a reliable solution for detecting and removing the threat. However, the main questions remain unanswered: how does Rustock spread and does it really exist ‘in the wild’? It was a matter of honor for us to dot all the i’s by finding answers to these questions.

Distribution of Rustock

For several days, all available samples of the rootkit were carefully analyzed to identify their ‘hardware settings’. This could give us at least some idea of the scale on which Rustock had spread. All the data was matched against the dates on which each sample was detected.

We found that 590 out of 599 samples were caught by our honeypots from September 10 to November 23, 2007. And only nine were caught during the period from November 23, 2007 to the middle of May 2008.

These statistics were used to narrow down the search and match files to the four modifications of the rootkit known to us.

This analysis produced the following results:

No Rustock appearances were identified between October 17 and November 12, 2007. However, a new surge in its activity was recorded from November 12 to 22 – mostly the C2 modification (dated September 26) with smaller numbers of the C3 and C4 modifications.

November 23, 2007 marked the beginning of a period of several months when Rustock was inactive (or disappeared for good?).

The data collected was very useful, but it remained unclear on what scale Rustock had spread and what methods were used to distribute it. In spite of all the efforts, the rootkit’s ‘dropper’ remained unidentified.

But eventually our luck changed. We found over 500 additional files of the rootkit and they supplied all the missing links in the chain.

The botnet

Our conclusion that active distribution of Rustock had begun on September 10, 2007 was confirmed. Now we know in detail how and from which servers it was downloaded and installed on computers. We also had the answers to such questions as: “Where is the dropper?” and “Were users of antivirus products really unprotected against the elusive rootkit that spread for at least three months?”

Unfortunately, the method and channels used to distribute Rustock will cause concern among many IT security experts. The following names will be familiar to every antivirus expert:

CoolWebSearch / IFrameBiz / Trafficadvance / LoadAdv.

Yes, we are once again facing one of the best-known cybercriminal groups on the Internet and the names above are associated with its websites and malicious programs. The gang has existed since early 2004, or longer, and is still active. The best-known and most widespread of the group’s creations were such Trojans as Harnig, Tibs, Femad, LoadAdv and various modifications of Trojan-Downloader.Agent and Small, as well as the Inject Trojan.

The group has always been in the vanguard of virus innovation: they were the first to use Trojan downloaders in chm files on a large scale; it was on their servers that the first variants of exploits for ANI and ICO file processing vulnerabilities were found. They were the ones to use Trojans written in Java (Trojan-Downloader.Java.ClassLoader) and to start the fashion for script downloaders.

The ‘hallmarks’ of the IFrameBiz group have tended to be domains in the .biz zone and filenames in the loadadv*.exe format.

The group can be traced back to Russia, where most of its members undoubtedly live. In the early stages of its existence the group extensively used hosting resources in St. Petersburg. It is also known to have collaborated with the infamous RBN network (Russia Business Network), which many experts also associate with the city.

In the four years of its existence, the group has created one of today’s most powerful systems of malicious program distribution. Its botnet, which includes millions of computers infected with various Trojan downloaders (primarily Tibs and Femad), can install any new malicious program on infected computers within a very short period of time. This is currently the most viable alternative to sending malicious code by email, a method that the antivirus industry has long since learnt to handle.

The IFrameBiz botnet is actively used to distribute new malicious programs. Customers pay for a time period during which their Trojans will be distributed via the botnet. Then the Trojans are downloaded to victim computers. It is common for the same downloader (e.g., Tibs) to install several Trojans from different customers. The service is in demand, and customers think nothing of their requests being fulfilled at the same time as several other client orders.

The services offered by IFrameBiz have been and are used by the developers of numerous adware programs, as well as those who wish to create their own botnets, spammers, DDoS attack perpetrators, etc. To draw a parallel with RBN, it can be said that the latter constitutes the hardware and technical part of the virus writers’ business, while IFrameBiz is the software part, as well as the starting point for a great many malicious programs.

It was namely IFrameBiz that the authors of Rustock approached in summer 2007 with an order to distribute their rootkit. A completely new module was created to distribute the rootkit via IFrameBiz channels. This may have been because IFrameBiz Trojans were unable to activate Rustock on user systems unnoticed, or perhaps the rootkit authors wanted to keep the code of the rootkit a secret to prevent the contractor from stealing the idea or technology.

Reconstructing the events

The following example describes what happened in late September 2007 on an infected computer that was part of an IFrameBiz botnet.

A downloader (probably Tibs) installed on the system connects to one of the botnet’s servers in the .hk zone (i.e., Croatia – the group began using domains in this zone in 2007) and attempts to download the file loadadv351.exe.

The file is an improved module for the same botnet – Trojan.Win32.Inject.mt according to the classification used by Kaspersky Lab. The name reflects what the malicious program does: it injects its code into the Explorer.exe process. This enables it to bypass a variety of firewalls and freely download files to the system.

The Trojan reports a successful installation to the IFrameBiz servers and receives orders from them telling it which files should be downloaded and from where. These reports also work as a statistics system of sorts for the botnet, enabling its owners to keep count of successful malicious program downloads and provide reports to customers.

The Trojan downloads several files from different servers – either from customer servers or from customer resources on IFrameBiz servers. In this case, files are loaded from customer resources rented from IFrameBiz (http:// *.biz/progs/*). At the same time, information about the infected computer, including the operating system, hard drive, etc., is collected and sent. This information is needed to determine the botnet’s status, geographic distribution, etc.

As a result, several new files appear on the system. We are interested in two of them: let’s call them ‘1.exe’ and ‘2.exe’. For now, we will concentrate on 1.exe (we will look at 2.exe later).

This file is yet another downloader, although a rather extraordinary one. Its first sample was detected by Kaspersky Lab on September 10, 2007, on the day the first Rustock variants appeared. In view of the facts described above, this is hardly a strange coincidence. From that same day, Kaspersky Lab products detected this downloader as Trojan-Downloader.Win32.Agent.ddl.

The malicious program includes a driver that loads into the operating system’s kernel (in other words, we are dealing with a rootkit here). The driver’s code is encrypted using a sophisticated encryption algorithm, which very much resembles the algorithm used to encrypt Rustock.

After removing all the layers of protection from the driver, we get to the interesting part: this downloader program for Rustock is no less ‘mythical’ than the rootkit itself.

The missing link

While rumors about the rootkit had circulated since December 2006, the first and only time the downloader’s actual existence was mentioned was in late October 2007, almost two months after it was detected and added to our antivirus databases. It is hardly surprising that, since Rustock.C itself eluded antivirus researchers, no one gave its downloader a second thought.

However, even after Rustock.С was detected and the search for its ‘dropper’ should have begun, some antivirus companies thought it was sufficient to simply detect the rootkit. They did not bother spending time determining how the rootkit found its way on to users’ computers and whether users were actually unprotected against the elusive rootkit.

Our research yielded answers to both these questions. As of September 10, 2007, i.e., the first day Rustock.C was distributed via the IFrameBiz botnet, Kaspersky Anti-Virus detected its ‘dropper’ – Trojan-Downloader.Win32.Agent.ddl. Later, a number of antivirus vendors added the Trojan’s signature to their antivirus databases.

For several months, users’ computers could only be protected from being infected by the elusive rootkit by timely detection of its downloader.

Unfortunately, even today (in early June 2008) some antivirus products still do not detect Agent.ddl.

The downloader

As we mentioned before, the Trojan consists of two components: the body and the driver. The driver collects the following information about the system: manufacturer identifiers and device model for the motherboard, and the installation date and exact version of the operating system. This information is then encrypted and sent to the server of Rustock’s author (or customers): 208.66.194.215.

The server to which the data is sent (208.66.194.215) is the same as that used for the rootkit’s DLL (spambot): it is the source of the spam messages that Rustock sends. However, the method used by the downloader driver to interact with the server is different from the method used by the spambot.

The Agent.ddl driver works with the TCP/IP virtual device directly, from Ring 0, making it impossible to detect outgoing traffic using some sniffers and/or firewalls on computers with active infections. Agent.ddl establishes a connection on port 443, attempting to disguise its data as HTTPS packets. As a result, even when researchers intercept traffic at the gateway, they may not realize that they are not actually dealing with HTTPS data but with encrypted data collected on an infected computer.

Below is an example of a packet from an infected machine that was disguised as HTTPS data:

Every time the driver is launched, the encryption key changes. Detection is made more difficult because the external observer does not know the encryption algorithm and key.

It should be noted that the authors of the Trojan downloader tried to make the life of anyone attempting to study the driver’s code as difficult as possible.

The IP address of the central server and the number of the port on which the driver establishes connections are coded in the program’s body in such a way as to hide their explicit function:

The authors have done much to obfuscate their code, as well. For example, the simple operation

after obfuscation becomes:

One instruction has been replaced by seven. So, you can imagine what the rest of the driver is like!

Let’s now return to network communication. The malicious code sent a packet with information about the infected computer to the server. In response to the data received, the server presumably sent a file that was specially encrypted for the specific machine, with a key matching the hardware on the computer from which the packet was received.

This is how the authors solve the problem of outside analysts detecting, studying and launching the dropper, which would eliminate the need for them to find the encryption key in order to study the rootkit’s code.

The rootkit file that has been generated, its ‘pure body’, is downloaded to the victim computer, where Agent.ddl activates it. Rustock.C infects its first system driver, adding one more computer to the new spam botnet.

The server used by Rustock.C is currently blocked. All packets sent to it are filtered by network routers. It would seem that law-enforcement agencies are now taking an interest in this IP address, as well.

Conclusion

This reconstruction of events by our experts demonstrates that the rootkit was actively spreading from September to November 2007. The use of the IFrameBiz network could ensure that it became truly widespread. At the same time, the facts described above show that the rootkit’s elusiveness was due only to the high-level encryption of its code and the use of numerous anti-debugging techniques that hindered its analysis by most experts.

Antivirus vendors have had the rootkit since it appeared ‘in the wild’. Most antivirus products, with very few exceptions, have provided detection of its activity during its installation on the system and of the components responsible for its installation and distribution for almost as long. It could be easily blocked from penetrating a system using unsophisticated tools for monitoring file system changes.

Although this has been done to Rustock dozens of times, its code was not analyzed in detail until May 2008.

Rustock.С indeed exists; it is not a myth. But the rootkit’s elusiveness is mythical: it is not due to any extraordinary masking capabilities, but is based on the rumors which appeared in late 2006 and which only played into the hands of the malicious program’s authors.

Any rootkit created with existing detection capabilities in mind will evade the protective measures provided by such systems. Warfare at kernel level comes down to a question of who takes over first – the rootkit or the anti-rootkit solution.

The objective of Rustock’s author was not to create an undetectable rootkit but to make analyzing the rootkit as difficult as possible once it had been detected. This would ensure that there was a certain time lag between the beginning of the rootkit’s distribution and its detection by antivirus solutions.

Only one question remains: why did the author of Rustock stop improving the rootkit and releasing new variants in the middle of October 2007? Could it mean that a new project was commenced and that there is already a ‘Rustock.D’ somewhere?

We do not have an answer to that question, but whatever it may turn out to be, a single malicious program, even one that remained undetected for several months, does not affect the overall conditions characterized by thousands of other malicious programs appearing every day and being successfully neutralized by the antivirus industry.

While the Internet remains home to IFrameBiz and other similar groups that distribute hundreds of new malicious programs every day, hack numerous websites and organize dozens of epidemics, there is no point in celebrating one localized victory.

P.S. We wrote above that Trojan.Win32.Inject.mt installed two files on the system – 1.exe and 2.exe – but we have not discussed the nature of the second file.

This was a variant of Sinowal, a Trojan spy. The same Sinowal that became a headache for antivirus companies two months after the events described in this article and which became known as the ‘bootkit’.

Both Rustock and Sinowal were distributed at the same time and via the same botnet. New variants of Rustock stopped appearing in mid-October 2007. The first samples of the ‘bootkit’ were detected a month later, in November 2007.

Is this also just a coincidence? We may find out some day.