It is no secret that some legitimate products use rootkit technologies.
Various proactive antivirus protection tools are capable of hooking system functions in one way or another. Malicious code also uses algorithms of this type. However, antivirus software differs from malicious code in that it does not attempt to hide the modifications it introduces into the system.
Many are aware of data encryption software, such as TrueCrypt. Such programs can encrypt entire partitions or disks. To be able to encrypt a system partition, the creators of this type of software need to implement a proprietary loading routine and modify the master boot record (MBR). Similar technologies are also used in modern bootkits; however, security software, unlike bootkits, does not attempt to conceal its proprietary loader.
Like encryption software, some third-party boot loaders (LILO, GRUB) also use MBR modification technology.
Rootkit technologies based on system function hooks are also used in various commercial copy protections, especially in games, and many of these copy protections can be particularly aggressive.
Using rootkit technologies in legitimate products can cause just as much harm as good. It’s a fine line between secure and dangerous implementation of a technology, and a poorly-implemented product can easily be exploited by cybercriminals. As a result, extreme caution is required.
The Sony scandal back in 2005, when the company produced new technology to try to prevent its audio CDs being copied, highlighted the risk. Sony’s protection used rootkit technologies which malware could have used to mask malicious components. In other words, the key software component had been written so poorly it could be used in a way unforeseen by its developers.
Is there sufficient justification for using rootkit technologies in legitimate software? When they are used in legitimate programs, how great is the risk that the OS and user data might be compromised? Just how fine is the line between legal and criminal methods?
Before getting down to specifics, I will broadly outline several cases when legitimate rootkits or poorly written drivers could compromise the security system. These cases have been selected to encourage further discussion.
When speaking about potential threats, I will use the concepts of legitimate signatures and signed drivers. Obviously, most companies prefer to sign their own software; in 64-bit operating systems, a kernel-mode driver must be signed in order to run. In antivirus products, checking against a whitelist is one of the factors used when assigning a program to a specific software category. Let us assume a legitimate, digitally-signed driver is being abused by cybercriminals. Such a driver would pass a scan as it is listed as software with a trusted signature, even if it is being used for malicious purposes. Therefore, a legitimate, digitally-signed driver is potentially dangerous if it uses rootkit technologies with inadequate authentication mechanisms.
Imagine a complex protector or crypter with algorithms which call for reading and writing to memory. These functions are executed in kernel mode. For the software to operate, a kernel-mode driver is required. Under Windows x64 this driver must have an officially purchased signature – it must be legal. This driver will almost certainly pass the scan test as it is on the whitelist of software with trusted signatures and won’t flag up any problems.
Let us assume the driver is poorly written and contains no checks that would minimize or eliminate the risk of abuse. Malware writers can then use this driver to unhook the system functions of an antivirus product by using the reading and writing functions provided by the driver. Cybercriminals can disable proactive protection or disrupt the antivirus program’s critical processes from the kernel.
Imagine an application containing a signed driver that allows unsigned drivers to be loaded into memory. The unsigned drivers will be loaded manually: the signed driver has to reproduce the actions of the system loader, create a primary thread etc. Such a driver could completely compromise the Windows x64 signature check mechanism.
As well as searching for anomalies, classic anti-rootkits such as GMER, RKU, RootRepeal etc., can also provide the capability outlined above for reading/writing kernel memory. They also often have functionality for killing processes or threads, unloading dynamic modules, etc. Even though the driver controlling this may have a legitimate signature, if it is poorly written, cybercriminals can easily use it for malicious ends.
Imagine security software that creates file system snapshots, either on demand or according to a schedule. The main aim of such a product is to facilitate a rollback of the system to a point in the past before data was damaged or a malware infection occurred. However, system files can be damaged in such a way that the operating system cannot be loaded. To restore to a specified point, the system can be loaded from an external media, or an MBR modification mechanism can be used. By implementing a customized loader, data can be restored before the operating system is loaded.
To protect against damage to an MBR and/or loader, a kernel-mode driver may be used that hides traces of modifications to the master boot record, returning false contents when reading, and writing new records to a different sector. If this kind of driver is poorly implemented, several unpleasant scenarios are possible. Firstly, a cybercriminal may figure out the algorithm of the driver’s operation and use it as a rootkit component in a malicious program. Secondly, if the MBR has been infected by bypassing the hook, the cybercriminal does not need to hide it from security software installed on the computer.
Unfortunately, in this case, theory has more or less been put into practice.
Kaspersky Lab products implement a powerful anti-rootkit tool that detects hidden objects such as disk sectors, files, registry keys etc., bypassing the hooks implemented in malicious programs. We collect statistics about various anomalies detected on users’ computers via the Kaspersky Security Network (KSN) cloud service.
While analyzing the obtained data we have identified several legitimate programs that use rootkit technologies.
Summary table: legitimate software using rootkit technologies
|Program Name||Vendor||Object||Concealment Method||Presence of signature|
|COMODO Time Machine||Comodo||MBR||Filter driver||+|
|Norton GoBack||Symantec||MBR||Filter driver||–|
|PC Back Pro||Digicore Technologies||MBR||Filter driver||+|
|Rollback Rx||Horizon DataSys||MBR||Filter driver||+|
Let us review each of the programs found to contain rootkit technologies.
Full program name:
COMODO Time Machine v.2.8.155286.178
Link to download page
(product development is suspended)
Distribution of COMODO Time Machine users by country (TOP 10)
(Data obtained from KSN)
A system rollback utility designed to help users quickly restore their computers to an earlier point in time. A Comodo Time Machine snapshot is a complete record of the system and includes system files, the registry and the user’s documents (Wikipedia).
CTMFLT.sys, CTMMOUNT.sys, CTMSHD.sys (the drivers are signed)
CTM allows users to launch a dedicated restoration console prior to loading the operating system. This capability is based on modifying the MBR. The console can be entered by pressing Home on the keyboard while booting.
However, we discovered an anomaly: the MBR had been substituted during reading. The substitution is carried out by the filter driver of the disk stack.
If protected sectors, and in particular the MBR, are read, false information is returned, i.e. the pre-modification MBR content. When writing to MBR, the filter driver redirects the request so that new data is written to another location and the modified MBR stays intact.
Full program name
Norton GoBack Deluxe Edition v.3.21.106
Link to download page
(product maintenance has been discontinued, the product has been replaced with Norton Ghost).
Distribution of Norton GoBack users by country (TOP 10)
(Data obtained from KSN)
Norton GoBack (formerly known as WildFile GoBack, Adaptec GoBack Roxio and GoBack) is a data restoration utility from Symantec’s Norton SystemWorks package for Microsoft Windows. When the file system is idle for several seconds, GoBack creates a restoration point. The utility allows the disk drive to be reverted to any point within the available history (Wikipedia).
Similar to Comodo Time Machine, GoBack implements a restoration console that can be activated by pressing the Space key prior to booting the operating system. This capability was again implemented using an MBR modification method. To restore a file system snapshot before the operating system is loaded, Norton Ghost relies on creating a boot disk.
We also noted that this product substituted MBR during reading. The substitution is carried out by the filter driver of the disk stack.
If MBR is read, false MBR content is returned. Writing to protected sectors is blocked.
Full program names
PC Back Pro v.2694412298, Rollback Rx Professional v9.1
Distribution of PC Back Pro and Rollback Rx users by country (TOP 10)
(Data obtained from KSN)
The programs are designed to create system snapshots that can be used on demand to roll back the system. It allows the system to return to a “safe” point and restore lost data in the event of an infection or an unwanted modification. Files and system settings are restored, including the registry, desktop, security, and user management parameters. System snapshots can be created on demand or automatically according to a schedule.
Shield.sys, Shieldf.sys, Shieldm.sys (the drivers are signed).
First of all, let me explain why we are dealing with two programs at once. These are actually the same program. Digicore probably holds a license for the software from Horizon-Datasys or is its reseller in Latin America. It is sufficient to view the screenshots of both programs’ main windows to see that the two products are identical.
For this reason, I will only provide screenshots of the windows displayed while running RollBack Rx in the subsequent description.
As is the case with all the above products, these two programs implement a restoration console activated by pressing Home while the computer is booting. The method used is once again MBR modification.
As before, we found that the MBR was replaced by the filter driver when we attempted to read MBR.
When the MBR is read, false contents are returned. The product uses the same algorithm as CTM when it is writing: the filter driver redirects the request and data is written to a different location.
Full program name
FarStone RestoreIT v.7.1.3
Link to download page
Distribution of RestoreIT users by country (TOP 10)(Data obtained from KSN)
FarStone RestoreIT 7 is a powerful and simple utility for restoring personal data after crashes. It automatically restores all files on the PC. RestoreIT 7 restores the system to the working condition that existed prior to a crash resulting from malware or hacker attacks, Windows malfunctions, installation errors or inappropriate user activities.
VvBackd5.sys (the driver is signed)
This product also has a restoration console that is entered by pressing F4 while booting. Like the products described above, this capability is based on MBR modification.
Unfortunately, I wasn’t able to start this console on a virtual machine running Windows XP SP3. I had to install it on Windows Vista to make it work.
Similar to all the above products, an attempt to read the MBR produces false contents. Writing is redirected to a different location.
I was surprised to see MBRs being hidden and investigated how the products reviewed in the previous section would behave if the MBR was modified while bypassing the filter driver. I installed one of the above products on a computer and modified the MBR using the following algorithm:
- Write a 512-byte 0xAA sequence to the MBR while bypassing the filter;
- Make a dump of the MBR on the hard drive using the anti-rootkit tool RootRepeal;
- Check that the recorded sequence is in the MBR;
- Read the disk using Hiew (“hiew32 .physicaldrive0”);
- Check that when reading the MBR it still yields false contents.
After the MBR is re-written, all the above products keep returning false contents when the MBR is read, thus deceiving the user. Unsurprisingly, the computer didn’t boot after a restart, because I added junk data to the MBR – so there is no way to call up the restoration console which is supposed to protect the user.
Secondly, if any bootkit (e.g. Winlocker) infects the MBR, bypassing the filter driver on a system where any of the reviewed products is installed, then it would have a free rootkit driver at its disposal: when reading the MBR, the legal kernel-mode driver with a legitimate signature will still return false contents. The restoration console may also stop working.
Thirdly, there is the potential risk of killing the system if partition editing tools are used simultaneously with any of the above products: these tools may receive misleading data as they operate. The best case scenario is that the tools will simply no longer function as required.
As a result, users of this software may find themselves in a situation where:
- They are unable to find out that the MBR has been infected;
- Malware on the computer is hidden with the help of a legitimate utility;
- The system restoration software does not work when serious problems occur;
- Using partition editing tools renders the system inoperable.
Although some of the products reviewed above may have been updated or are no longer being maintained by their vendors, it is very likely that other similar products exist, using similar questionable methods. It is also possible that the kernel-mode drivers reviewed above may be used for illegal purposes, such as hiding an MBR infection; the availability of a digital signature will only exacerbate the situation. Where the required expertise and tools are available, it will not be too difficult to figure out the drivers’ operation algorithm.
All modern security products include a self-protection module for the sole purpose of defending its own critical parts – files, registry keys, processes etc. – from threats posed by malicious programs. Imagine that this self-protection module starts to conceal files, sectors and keys rather than guaranteeing security. Would you feel comfortable using such a product? How do you know it’s not hiding other things? Would any user feel comfortable knowing that certain things could be going on without them being aware of it?
I would like to offer some recommendations to the manufacturers of the products reviewed above, as well as their counterparts:
- It is perfectly legal to modify MBR, but rootkit technologies should not be used in your products. There are other technologies available; there is no need to hide anything from the users.
- The restoration console can be implemented as a startup disk or removable drive.
- If there isn’t one already, there should be a caller authentication algorithm in drivers.
The fine line between legitimate and illegal use of rootkit technologies is easily crossed. What’s more difficult is building a good quality product. In the world of security software, simple solutions are not necessarily the best.