Bootkit: the challenge of 2008

The term MalWare 2.0 is often used in our reports to denote a model for the complex malicious programs which appeared at the end of 2006. The most striking examples, and the initial members of MalWare 2.0 are the Bagle, Warezov and Zhelatin worms.

The Malware 2.0 model is characterised as follows:

• the absence of a single command and control centre for networks of infected computers
• the active use of methods to combat the analysis of malicious code and attempts to gain control over a botnet
• short-lived mass mailings of malicious code
• effective use of social engineering
• the use of a range of methods to spread malicious programs and a gradual move away from the use of methods (e.g. email) which attract attention
• using a range of modules (rather than a single one) in order to deliver a range of malicious payloads

The evolution of MalWare 2.0 causes a range of problems for the antivirus industry. The most important, in our opinion, is the fact that traditional antivirus solutions, which are based exclusively on the use of signature or heuristic analysis of files, are unable to reliably combat virus attacks (and this even without addressing the problem of curing infected systems).

We think that among the incidents of 2008 which demonstrate the threat posed by MalWare 2.0, the history of the Rustock rootkit should be highlighted. (Rustock is addressed in detail here: https://securelist.com/rustock-and-all-that/36217/). A number of new technologies, methods and approaches were implemented in Rustock which may have a significant impact on the future evolution of MalWare 2.0.

The most recent incident, coveredin this report, clearly demonstrates the modern art of warfare as conducted by virus writers and antivirus companies, and also demonstrates the importance of new protection technologies.

The curious incident of the rebooting computers

In the middle of August, complaints started to appear on Internet forums from users who said their computers were rebooting themselves after a range of sites had been visited. What caused the reboot was unclear. There were no common factors found in the hardware and software used. Only a single possible explanation remained: the cause of the reboot had to be on the sites themselves.

An initial inspection of the suspicious sites revealed nothing – the sites appeared to be innocuous. In the majority of cases, malicious users who want to infect victim machines hack legitimate sites and place links to their resources which contain exploits on these sites. This technique is known as a “drive-by download‘; when a user views the infected site, malicious code will be installed to the victim machine without the user’s knowledge or consent. However, nothing was detected on this site – no suspicious iframes, no suspicious scripts.

The problem could have been ascribed to Windows automatically rebooting following the installation of updates; this was particularly likely as the time frame coincided with the latest patch releases from Microsoft. However, the situation turned out to be far more serious than this.

During the subsequent investigation, we used a number of virtual machines to visit the suspicious sites. We didn’t only visit the sites, but actively moved from one part of the site to another and clicked on links. And after a while, the test computer rebooted!

An analysis of the system showed changes to the boot sector. Such changes could indicate the presence of a bootkit in the system. We covered bootkits and the problems such technologies can cause in our report for the first quarter of 2008 (viruslist.com). However, no new variants of the bootkit have been detected since March 2008. Could it be the bootkit had returned?

Substitute links

Once we had determined which sites and which links caused users’ computers to reboot, we were able to conduct a more detailed analysis.

As it turned out, the malicious users had taken a relatively original (although not new) approach to injecting links. They didn’t add their own iframe or scripts to hacked sites, as such modifications are very easy to detect. Instead, “malicious” links were substituted for “legitimate” links on hacked sites.

A legitimate link looks like this:
<a href="http://atm.n****.com“>atm.n****.com

And this is what the link looks like once the site has been hacked:
<a href="http://***.com/cgi-bin/index.cgi?dx“> atm.n****.com

In order for a computer to become infected, the user had to not only open a page on the hacked site but also to click on the substitute link. This reduces the number of potential victims but not significantly – particularly if the links are substituted manually and carefully chosen by the malicious users.

The first mention of sites such as ***.com/cgi-bin/index.cgi?dx started appearing on the Internet around the beginning of June 2008 in the form of complaints from site owners and users of legitimate sites. The complaints were about strange links which had appeared on trusted resources. It became clear that there were quite a number of these “infection centres” on the Internet; however, in spite of the abundance of domain names, they were all hosted on common servers.

The diagram below shows a small number of the sites which we detected:

 


Location of servers which infected users with the bootkit
(Left to right: domain name; server IP address; subnetwork where server is located; autonomous system

Personalised exploits

So what happens when a user clicks on a substitute link? The server processes the incoming request and gets information about which site the user has come from, the user’s IP address, browser, and which browser plug-ins are installed. The server uses this information to assign the user a unique ID which is then saved to the server.

An example of such an ID assigned to a visitor to the malicious server is index.cgi@ac6d4ac70100f060011e964552060000000002e4f11c2e000300190000000006

The last figures of this ID show that the user has version six of Acrobat Reader installed.

An exploit is then created for each specific user. If the user has a vulnerable version of Acrobat installed then a PDF exploit will be downloaded to his/ her machine. If Real Player is installed, then an exploit for this program will be downloaded, and so on. Depending on the ID assigned to the user, the server will generate an obfuscation key which will be used to encrypt the appropriate exploit.

 


Example of an obfuscated exploit

Exploits for vulnerabilities in the processing of PDF, SWF, and QuickTIme files were downloaded in the majority of cases. The list of vulnerabilities exploited by the malicious users are relatively long, and is constantly being added to. The most commonly used vulnerabilities are listed below:

• CVE-2007-5659
• CVE-2006-0003
• CVE-2006-5820
• CVE-2007-5779
• CVE-2008-1472
• CVE-2007-0018
• CVE-2006-4777
• CVE-2006-3730
• CVE-2007-5779
• CVE-2008-0624
• CVE-2007-2222
• CVE-2006-0005
• CVE-2007-0015

Once an exploit has been created for a specific user, it starts to run on the victim machine by way of the vulnerable application. While it is running on the computer, a Trojan Dropper program is downloaded to the victim machine. This program uses the unique user ID and server key which are stored in the server’s database.

From the outside, all this looks completely harmless, and doesn’t arouse any suspicion: once the exploit has been run, the server returns the real address of the page that the user wanted to view, and the page which the substituted link that the user clicked on leads to. The victim gets access to the resource he wanted without noticing that the computer has been connected to a different server and become infected.

Additionally, if the user clicks again on the substitute link, there will be no repeat running of the exploit, nor a repeat attempt at infection – the user will be immediately redirected to the legitimate page. The malicious server keeps a database of visitors, and no single ID is used again.

The return of Neosploit

What was used to generate the “personal” exploits for users? To our great surprise, this was where we encountered something we had thought dead and buried: the Neosploit administrative panel.

The Neosploit bundle of exploits has been known about since the middle of 2007, when it was being sold on the black market for a few thousand dollars (between $1,000 and $3,000) . It was serious competition for other malware kits such as MPack and IcePack.

At the end of 2008, messages appeared (http://ddanchev.blogspot.com/2008/07/neosploit-team-leaving-it-underground.html) (http://blogs.zdnet.com/security/?p=1598) saying that the known group of cyber criminals who were behind the creation, distribution and support of Neosploit had ceased to exist.

The announcement made by representatives of the group stated:

Such a sudden closedown happens, as a rule, either because the group is being investigated by law enforcement bodies, or bears witness to the fact that the criminals are about to do something “significant” and are preparing an alibi for themselves.

The last version of Neosploit created and sold prior to the dissolution of the group was version 2.0.17. However, on the server responsible for generating exploits, we saw version 2.0.23 of the Neosploit administration panel!

 


Main window of the administration panel

In spite of its seemingly low-key nature, the Neosploit administration interface has a wide range of functions.

 

Dialogue box to add new user to the system

The Neosploit administration panel which was used to generate exploits, create and manage databases of infected users etc. is an executable file written in C++ and compiled to run on Linux and FreeBSD.

 


The Neosploit administration panel from within

 


Disassembled code of the server responsible for obfuscating exploits

Neosploit is designed to be placed on hosting sites and configured for maximally quick installation and launch. However, there is a serious problem connected with using Neosploit i.e. that it is a “commercial” product. The problem centres around the fact that a purchased edition of Neosploit can only be used for a limited number of connections – similar to shareware products which can only be used up to a certain point in time.

Every attempt to infect a user and generate an exploit results in the Neosploit server connecting to a server which probably logs the number of connections (at the time of the analysis, this server was located in Ukraine). The authors of Neosploit may monitor the use of their creations and/ or payment for their services on the basis of the number of infected users. It’s likely that if a connection can’t be made to the server, an exploit won’t be generated and the user will remain uninfected.

Bootkit

Once it has been loaded to the system, the Trojan dropper program launches via the vulnerable application, extracts the bootkit installation program from itself and transmits the unique user ID to it.

The installer then modifies the boot sector and places the main body of the malicious program on hard disk sectors.

Example of record in the boot area of the disk

 


Example of infected master boot record

If all these actions are successfully executed on the system, then the dropper transmits the command to reboot to the computer. And it’s this – the unexpected reboot of the system while the user is on the Internet – that caused suspicion among users, leading them to write about the experience on forums in an attempt to understand what had taken place.

Once the machine has rebooted, the bootkit hooks a range of system functions and starts to run fully in the system – hiding its own presence and functioning as a bot within a zombie network.

 

User infection sequence

The migrating command and control center

All the technologies which we discovered when analysing the penetration mechanism are interesting; some are original (for instance, link substitution, obfuscating exploits on the fly for a specific system) but not, overall, unique. Such technologies have been encountered previously, although prior to August 2008 they had not all been used in the framework of a single attack.

A real surprise was waiting for us when we analyzed the work of the bot: the botnet’s command and control centre (C&C) was constantly moving from one domain to another!

According to our observations, the command and control centre would sometimes move up to 2 – 3 times in a single day. For instance, in the morning it might be running on aykjfgves.com, then by lunchtime have moved to dmiafgves.com, while occupying gfdpves.com in the evening. Effectively, infected computers which formed part of the botnet were forced to repeatedly search for the active command and control centre in order to connect.

Such botnets are very difficult to detect, and, once detected, very difficult to bring down. The malicious user can at any moment move the command and control centre to any of a dozen, or even a hundred, specially prepared domains, leaving researchers powerless to combat them. Even if the botnet’s command and control centre has been identified, within a couple of hours it will be moved to a different domain. It will then only be possible to find it by analysing network packets sent by the bots which will be searching for their new home.

There is no doubt that this method is designed both to combat competitors who may attempt to steal the botnet and to hinder the efforts of antivirus companies and law enforcement bodies.

 


Example of location of servers used to manage the botnet (left to right: domain name; server IP address; subnetwork where servers are located; autonomous system)

Generating domain names according to a special algorithm and registering the resulting domains makes it possible for the malicious user to keep moving the command and control centre for a long time. A range of domain name registrars are used to register domains: American, African, Asian and European. There are clear Russian traces in the registration data used by the owner, although the data itself is undoubtedly false.

The command and control centre uses the most varied hosting services possible around the world, The command and control centre is able to move to new hosting within a matter of minutes, which prevents it from being closed down, but does not adversely affect its functionality.

 


Example of location of servers used to match domain names with the IP address of the command and control centre (left to right: domain; server IP address; subnetwork where servers are located; autonomous system)

This method is similar to the Fast-Flux technology which is actively used by worms from the Zhelatin (Storm Worm) family. However, Fast-Flux only makes it possible to constantly change the IP addresses of malicious domains, whereas the technology implemented in the bootkit make it possible to change the domains themselves as well as the IP addresses.

The command and control centre contains a database of registered domains which can be used to host the command and control centre.

Example of registered domains

During the initial infection process, when the exploit is being run, the victim machine downloads a bootkit which is designed to work with the command and control centre which is active at that time. Once the system has rebooted and the bootkit is running at full force, the bot attempts to connect to the command and control centre. The malicious program creates a specially crafted network packet using the ID of the infected computer and attempts to send it to the command and control server which already has information about infected computers.

 


Example of packet sent

If it’s not possible to connect to the command and control centre, the bot will use a dedicated algorithm to consecutively generate .com, .net and .biz domain names. The number of domain names generated depends on the current date and time. The backdoor attempts to connect to each of these domains and transmit the specially crafted packet as an authorization key.

 


Example of domain search

As soon as one of the domains appears to be “correct” (e.g. it accepts the packet and answers by sending its own unique packet) the bot will connect to it as a botnet client and starts encrypting communication with the command and control centre. As a rule, this communication results in an additional module (a DLL) being downloaded to the victim machine.

 

Partial scheme of bot functions

The spy module

Since the beginning of 2008, the botnet has been examined by a lot of industry experts, but this research was limited to an investigation of the rootkit part and attempts by analysts to investigate how the botnet functioned, and management commands.

However, all of this research – the results of which we know – did not answer what to us was the main questions: “Why?” Or, to put it differently, “Where’s the money?”

Our main task was to dot all the i’s and cross all the t’s when writing the history of the bootkit. In order to do this, we had to understand exactly what such a sophisticated bootkit was hiding in the system.

Once the victim machine has connected to the botnet command and control centre, it gets an encrypted packet larger than 200KB in size. The bootkit then decrypts this packet, and inside there is a DLL file which the bootkit loads to memory and which does not exist as a file on disk!

By doing this, the bootkit is able to ensure that the loaded DLL is invisible when the system is analysed using traditional methods. It’s also invisible to the majority of antivirus programs. Do you remember what Rustock did? It also loaded a DLL to memory, but it was also present on the disk of the victim machine. This bootkit is far more sophisticated.

Of course, loading the code only to memory means that when the system is rebooted, the code disappears, it ceases to exist, and the system becomes clean (with the exception of the presence of the bootkit on the system). However, these “unpleasant thing” has its pluses: an antivirus program which scans memory when the operating system starts won’t detect anything suspicious – simply because there is nothing suspicious to detect. However, as soon as the computer connects to the Internet, the bootkit establishes a connection with the command and control centre and loads the DLL to the victim machine again.

And what does the DLL do?

Let’s take a look at the history of Sinowal (which is how we classify the bootkit). At the end of 2007, when the bootkit appeared, this name was already being used: a large number of Trojan spy programs designed to steal data (mainly access data for online banking accounts) came under the name of Trojan-Spy.Win32. Sinowal.

When analysing the bootkit we noticed that the obfuscation algorithm of the body of the bootkit was identical to the obfuscation algorithm used in Trojan-Spy.Win32.Sinowal. We came to the conclusion that the authors of the bootkit and the Trojan spy program were one and the same. Prior to making a detailed analysis of the DLL, the similarity between the obfuscation algorithms used was the only confirmation that these two malicious programs stemmed from the same source.

Once we had extracted the hidden DLL from the computer’s memory and studied how it worked, we had a firm verdict: the DLL is identical to Trojan-Spy.Win32.Sinowal and performs the same function as the Trojan spy program.

So once the botnet has been authorized on the network, the DLL module which is designed to steal passwords and intercept network traffic is downloaded to the victim machine.

Sinowal could be called a universal thief. Once it’s in the system, it immediately starts to scan for all accessible passwords to a wide range of applications.

 


Disassembled code of the password stealing module

List of applications targeted

The majority of applications targeted by the module designed to steal confidential data are designed for web site administration. This is critical for malicious users, as it is these sites which can be used either to host the botnet command and control centre, or to host exploits.

However, it’s the bank accounts which are of most valuable to these cyber criminals.

 


Partial list of banking sites to which the spy module steals passwords. The entire list contains approximately 300 sites.

Intercepting all network connections from the victim machine, the DLL scans traffic for contact with banking sites. All data entered by the user on such sites will be sent to the malicious user’s server.

The spy module is capable of launching a man-in-the-middle attack by using the bootkit as a platform which has full access to the resources of the operating system. This enables the spy module to intercept confidential information entered via the browser.

The module has almost all functions of a spy program, ranging from the banal interception of data entered via the keyboard to sub-domains of protected SSL connections. When contacting an https site, the spy program can open additional windows in the browser for authorization, and the user may mistakenly enter his account details in such a window because it appears to be part of the bank’s site.

The spy program can redirect user requests to phishing sites.
All harvested data is encrypted and sent to a dedicated server.

 


Example of location of servers which support SSL connections and which are used to redirect users to phishing sites (Left to right: domain name; server IP address; subnetwork where server is located; autonomous system)

 


Example of location of server which stolen application passwords are sent to (Left to right: domain name; server IP address; subnetwork where server is located; autonomous system)

The malicious network

When looking at the overall scheme of the attack, it should be borne in mind that all components of the bootkit network are in constant movement. By controlling the domain servers, malicious users are able to quickly and easily change the location of exploits, the command and control administrative panel, the place where modules are loaded, and the harvesting of confidential data. This effectively makes the system extremely stable, as reconfiguring network components can be done without making any modifications to the configuration of the bootkit or its modules.

 

How the bootkit interacts with servers

The scale of infection

Both the first bootkit, which appeared at the end of last year, and Rustock were spread using the resources of the IframeBiz group. However, the appearance of this bootkit took places in a totally different way: the scenario was much more technical and owed a great deal to the epidemics caused by Rustock and Sinowal.

Measuring the scale of the epidemic by counting the number of users complaining about their computers rebooting would be the wrong thing to do. A categorical answer could be provided by statistics from the botnet’s command and control centre; however, we did not have full access to the administration panel. Nonetheless, it is possible to establish a few figures.

While looking into the incident, we identified five main servers which were used to download exploits. To give an idea of the scale of the issue, over 200,000 users from the U.S.A. visited these servers over a 24 hour period.

 

Number of unique visitors from the USA to two sites hosting exploits

As already stated, the administration panel used to control the botnet is constantly relocated in accordance with a specific algorithm. However, not all bots connect to it while it is “on the move”.

The graphs below show several centres under relocation, the “tail” created as bots connect to them and data about the number of infected systems. It’s clear that the size of the botnet reached almost 100,000 bots, which is a relatively high figure. It should be noted that this case only covers American users.

 

Number of unique visits from the USA to the administration panel when moved to the next domain

 

Number of unique visitors from the USA to the administration panel which remained on old domains

Protection methods

The authors of the bootkit made maximum efforts to create a well-protected, highly mobile and non-vulnerable package, and carefully planned how each stage would work, from infecting the user to managing the botnet itself. They were eager not to make any errors, even in small matters such as injecting the iframe into a page’s code.

In spite of the sophisticated technologies used by the authors of the bootkit, modern antivirus products should be able to prevent the malicious code from penetrating a computer.

So what could put a spoke in the cyber criminals’ wheel at each stage of the infection process?

The approach taken by the cyber criminals (i.e. inciting users to visit malicious sites and generating unique exploits) was designed not only to infect the maximum number of users, but also to combat a range of technologies used by today’s antivirus products.

So substituting links rather than adding an iframe is designed to combat the traditional scanning of web-traffic; such scanning either results in the suspicious iframe being more rigorously checked, or completely blocked.

Taking into account the dozens, and sometimes hundreds of legitimate sites which are hacked in order to add malicious code to their pages, the best way of protecting from such threats is to implement technology which blocks known malicious sites.

 


Access denied: a user of KIS 2009 attempts to view an infected site

Exploits are automatically generated for each new user, but although the code of the exploit changes each time, the obfuscating mechanism does not. This means that an antivirus is able to detect the obfuscated script by using either signature or heuristic detection.

 

Detecting an obfuscated exploit

If the exploit has nevertheless been downloaded to the victim machine, it won’t be able to run if the user has regularly patched his/ her operating system and software applications. A vulnerability scanner is able to identify vulnerable applications.

 


Detecting a Flash Player component with an unpatched vulnerability

 


Description of the vulnerability on Viruslist.com

Let’s imagine that the user has a vulnerable application installed, and that the exploit has started running. The bootkit dropper will then be downloaded to the victim machine: as this executable file is created on the server for each user, this makes signature detection more difficult.

At this stage, the most effective method used by an antivirus product will be proactive protection which is capable of analysing as yet unknown files, determine their functions and conduct heuristic analysis of the code and behaviour of the malicious program.

 


When an executable file is launched, KIS 2009 analyses it…

 


…and if the analysis shows a potential threat, the file will be prevented from launching

 

The file has a high threat rating, having been heuristically detected as Heur.Backdoor.Generic

If at the time of infection the user does not have a sufficiently effective antivirus solution installated, then the bootkit which has penetrated the system will start running prior to the operating system and the antivirus solution being launched. This enables the bootkit to control important system functions and hide its presence on the infected machine.

Detecting and neutralizing the malicious code can be done using an antivirus program which includes a powerful antirootkit module, starting by scanning system memory…

 


Detecting the rootkit in memory

and then the boot sector…

 


Curing the MBR

The result – the system is disinfected.

 


Report on full disinfection using KIS 2009

Conclusion

In its time, the bootkit was a technological breakthrough for virus writers. Now, this bootkit is equipped with a powerful propagation routine and functions as part of a botnet.

Technologies implemented in the Rustock rootkit made this malicious program very able to slip past antivirus companies, as well as hindering analysis. The bootkit also uses a range of methods to prevent the program from being detected during the early stages of infection, attempts to infect as many users as possible, and also prevents the botnet from being taken down.

Examples of these methods are the highly organized approach and the technologies used; the exploitation of dozens of vulnerabilities in other applications; the shift from the OS boot mode to the zero, third ring and back again; the creation of applications in C++ for *nix operating systems; the cryptographic protocols; the methods used to authorize bots in the system etc.

There’s no doubt the developing such a system took several months and ensuring its smooth running constant debugging and expenditure on acquiring or creating new exploits, domains, hosting etc.

It’s highly unlikely that the system could have been created, planned, implemented and supported by one or two people. This is the creation of not just one, but several groups of cyber criminals who are working closely together, each taking responsibility for separate areas of the project.

The history of the bootkit reflects just how broadly information security issues affect the rank and file user. All the technologies examined above are currently actively being used in the vast majority of malicious programs.

The browser as an infection vector; rootkit technologies; botnets; theft of user data; cryptography; obfuscation; anti-antivirus solution technologies – we encountered all of these individually during the third quarter of 2008. And in the bootkit they all came together.

The only way to effectively combat such complex threats is to use a broad range of defense technologies: a web antivirus, traffic filtration, a behaviour analyzer, a sandbox, network traffic analysis and a firewall. A modern antivirus solution should be able not only to combat rootkits, but also to neutralize “subspecies’ such as bootkits.