Unearthing Root Kits

Malicious software (malware), including viruses, Trojan horses, and spyware, has become an epidemic over the past few years. Statistics show that an unpatched Windows XP Service Pack 1 (SP1) machine is infected within minutes of being connected to the Internet, and downloading software or even just visiting certain Web sites can introduce undesirable software onto your system. Fortunately, the defenses against this plague are constantly improving, with a sound security shield consisting of an antivirus tool, an antispyware solution, a firewall, and up-to-date patches. However, a technology called root kits threatens to change the security landscape and make the task of validating that a computer is clean of malware difficult or even impossible.

Root kit is a term loosely applied to cloaking techniques. When malware utilizes a root kit, it can make itself invisible to security systems, including antivirus tools and system-diagnostic tools such as Task Manager. Let's look at common root kit mechanisms, methods, and utilities you can use to try to detect the presence of a root kit and at what you should do if you find a root kit on your system.

Growing Threat
Root kits have been around since the early 1990s but were solely the domain of Unix variants until the late '90s, when the Windows developer community began exploring root kit techniques and several programmers published root kit toolkits that other programmers could modify and extend. Some of the toolkits are so well packaged that all a malware author has to do to take advantage of the root kit's cloaking is to make a few changes to a configuration file and bundle it with the malware.

The Web site http://www.rootkit.com has become the central meeting place for root kit developers, including those who claim to be working to defeat root kits, in some cases in the counterintuitive and somewhat controversial manner of publishing root kits themselves. The root kits published at Rootkit.com include Vanquish, FU, Afx Rootkit 2005, NT Rootkit, and Hacker Defender.

Given that root kits are so easy to access, it's surprising that more hackers haven't used them to cloak the viruses they've unleashed over the last several years. It's even more surprising that spyware and adware developers haven't used root kits to deeply embed their software into a system. Microsoft Customer Service and Support (CSS—a new organization that encompasses Microsoft Product Support Services) and antivirus companies do discover root kits installed on customer systems, but relatively rarely.

However, root kits have recently received a great deal of media attention as researchers have realized that they represent the next battleground in the malware war. That publicity, although alerting end users to the dangers of root kits, has also advertised the power of root kits to the malware community, which will begin to utilize root kits to combat the growing effectiveness of traditional antivirus and antispyware solutions. There will soon be viruses, spyware, and adware that you'll be unable to delete from your computer without reformatting it and reinstalling the OS.

Root Kit Basics
Early root kits took the relatively unsophisticated approach of replacing core system utilities with versions that hide malware files and processes. For instance, the root kit version of the Unix utility to list active processes, ps, omitted the malware process from the list of those obtained from the kernel, and the Unix directory-listing utility, ls, did the same for malware files in directory listings.

As system utilities became more sophisticated and third-party utilities and antivirus solutions proliferated, the simple file-replacement technique for root kits lost its viability. Writing replacements for Task Manager, Tasklist, and all the other process-listing tools commonly used on Windows systems would require a significant amount of work on the part of a root kit author, and all the work would be for nothing if a user ran an uncompromised utility such as a virus scanner or different process-listing tool.

Root kit developers have therefore gotten more sophisticated, attacking not specific applications, but the APIs that these applications use to obtain information. By intercepting the API by which an application retrieves the list of active processes and removing the malware process from the returned list as it's handed back to the application, the root kit hides itself from Task Manager and other process-listing utilities that use the API directly or indirectly. Modern root kits use this technique to hide files, directories, registry keys and values, Windows services and device drivers, TCP/IP ports, user accounts, and processes. Of course, root kits generally exempt malware processes from the modified system view so that the malware can have full control of the system.

Figure 1 shows the popular root kit Hacker Defender in action. Hacker Defender consists of a configuration file and an executable image. When you run hxdef.exe, it cloaks the files, directories, drivers, services, processes, and TCP/IP ports you list in the configuration file. The default configuration file cloaks any of these items that contain the string hxdef in their name. Thus, in the second listing, the directory appears to be empty.

Windows has several API layers, as Figure 2 shows, and different root kits attack different layers, depending on the root kit's level of sophistication. Higher level APIs are better documented and easier for root kits to intercept, but intercepting lower level APIs provides a more thorough cloak; for example, a root kit that cloaks at the Windows API layer isn't effective against an application that obtains its information directly from the native API.

User-mode root kits can cloak any process that runs in the account in which the malware launches but are most effective when run in an account that has the Debug Programs privilege. The Administrators group has this privilege by default, which enables the root kit to infect any and all processes on the system, including those that might be running in the Local System account, such as antivirus and antispyware processes. Thus, root kits are one more reason to follow the security best practice of running as an unprivileged user whenever possible.

The most powerful root kits are kernel-mode root kits. However, kernel-mode root kits require that the malware run in an account that has the ability to install a device driver and therefore won't work from within an unprivileged user account the way user-mode root kits can. Kernel-mode root kits require a great deal of knowledge to implement and must be carefully coded because a bug will crash the OS. The last thing a root kit author wants to do is to draw attention to the root kit by having it crash an application or computer.

Inside User-Mode Root Kits
The highest API layer is the Windows API layer in user mode. This layer consists of the base OS API that Microsoft documents in its Platform Software Development Kit (SDK). The Windows API for listing files in the directory consists of FindFirstFile and FindNextFile, both of which are implemented in windowssystem32kernel32.dll. An application such as Windows Explorer or the command prompt that wants to use the API imports it from kernel32.dll either statically or dynamically.

A DLL is loaded into a process only when an executable running in the process requires APIs exported by the DLL. When an executable imports an API statically, the executable's image contains references to the DLL and the APIs in a section called an import table that the OS loader evaluates during the process's startup. The loader loads each DLL listed in the import table into the process address space and connects the image's references to the referenced functions, as Figure 3 shows.

A dynamic import occurs when an already running process uses the Windows LoadLibrary function to load a DLL and the GetProcAddress function to ask the OS for the address of a function exported by the DLL. You can use the Dependency Walker tool from http://www.dependencywalker.com to view an image's static imports and exports and even run an executable with profiling to capture its dynamic imports. Figure 4 shows how Notepad imports FindFirstFile.

One method used by many root kits to hide malware is to scan a process's import table and replace the references to key system DLL functions with pointers to root kit functions that it implements in its own DLL or that it has written directly into the address space of the process. After a process has been hooked in this manner, known as DLL import hooking, a call it makes to FindNextFile, for instance, routes to the root kit code. The root kit code invokes the original function in Kernel32 but regains control when the function is completed. The root kit then examines the output and strips out data associated with the files and directories the root kit is hiding. To deal with dynamic linking, the root kit must hook GetProcAddress and return to the caller a pointer to the root kit's hook function instead of to the function the caller wants to use. The Vanquish root kit uses this technique, which Figure 5 shows.

Most file-, memory-, and process-related Windows APIs rely on lower level APIs exported by windowssystem32tdll.dll, which provides interfaces to the user-mode native API that's exposed by the OS kernel. Task Manager uses the NtQuerySystemInformation API implemented in Ntdll to query active processes, so a root kit that wants to hide a process can hook this function and massage its output to remove malware processes.

The Windows file-listing APIs mentioned earlier use Ntdll's NtQueryDirectoryFile, so manipulating the data returned by NtQueryDirectoryFile affects the data returned by FindFirstFile and FindNextFile. Root kits often hook the higher level functions—hooking Ntdll only when necessary—because it's typically easier and many system utilities use only the higher level functions.

Another user-mode root kit technique is to patch Windows API and native API functions in user mode. The popular Hacker Defender root kit takes this approach. Patching involves writing root kit code into a target process and modifying the first few bytes of subverted functions in that process so that they transfer control to the root kit's code. After the root kit code has gained control, it invokes an unmodified version of the function and manipulates the results before returning them to the caller.

Inside Kernel-Mode Root Kits
More sophisticated root kits intercept APIs in kernel mode at their entry to the OS by using system-call hooking. Ntdll's functions execute a system-call instruction to transition into kernel mode, in which the OS's system-call dispatcher executes. System-call APIs are internally identified by number, so the native API function in user mode indicates to the system-call dispatcher the number of the kernel-mode equivalent function. The dispatcher uses the number as an index to a table in which it stores pointers to system-call functions. In a manner similar to the way in which DLL import hooking works, root kits can replace a pointer in the table with a pointer to the root kit's function, located in a device driver, which behaves like a user-mode hook, manipulating data as it's returned to an application. NT Rootkit relies on system-call hooking. The function-patching method used by Hacker Defender is also possible in kernel mode, though none of the published root kits use patching.

A kernel-mode root kit technology that has become popular in the root kit community is direct kernel object manipulation. This method attacks the kernel's data structures themselves, rather than the APIs that return information about the data structures. To hide a process, for instance, the root kit takes the process off the kernel's list of active processes. Then NtQuerySystemInformation won't report the process because NtQuerySystemInformation relies on the active process list for its information, but the kernel will still schedule threads running within the process. This type of hiding has also been applied to device driver structures but isn't applicable to registry key, registry value, file, or directory cloaking because these objects aren't maintained with simple static structures. The FU root kit cloaks by using direct kernel object manipulation.

A final approach taken by kernel-mode root kits is to implement cloaking in a file-system-filter driver. File-system-filter drivers layer on top of file-system drivers, such as NTFS, and below the system-call API layer so that they can see all file-system activity. All "on-access" virus scanners use file-system filtering to intercept file-open operations and scan files for viruses before they allow the operations to proceed.

NT Rootkit uses a file-system-filter driver to intercept directory queries and remove references to malware files from the output returned by the file-system driver. Thus, anything that performs a directory listing operation, whether it's an application such as Windows Explorer in user mode or even another driver in kernel mode, is subject to NT Rootkit's cloaking.

Hiding in a Process
Perhaps the most advanced form of cloaking is to hijack the memory of an already running process. Malware that does this, such as the Code Red worm that infected Microsoft IIS, doesn't need to actively hide from tools such as Task Manager. However, unless the malware stores itself on disk before a shutdown, it won't survive a reboot. Some malware authors are sure to decide that avoiding detection is worth the risk of losing control of a system at a reboot.

Preventing and Detecting Root Kits
Preventing a root kit from entering your system is preferable to trying to detect a root kit that's installed itself on your system and get rid of it. Prevention means adopting a security perimeter that includes antivirus and antispyware solutions, firewalls, and using accounts that don't have administrator-group membership. If you do suspect root kit infection, you should examine your system with as many tools as you have available. Current antispyware and antivirus solutions are ineffective at dealing with root kits, but root kit detectors, kernel debuggers, and process diagnostic utilities can find many root kits.

All currently published root kits exhibit holes in their cloaking that detectors use to discover their presence. For example, a root kit that cloaks files at the Windows API layer is susceptible to detection by an application that uses the native API to scan file systems. Although NT Rootkit is one of the more advanced root kits published, it doesn't directly manipulate kernel objects. Thus, you can use a kernel debugger such as the Microsoft Debugging Tools for Windows WinDbg tool (available for free download from http://www.microsoft.com/whdc/ddk/debugging) to examine the list of processes in the kernel and see any malware processes that NT Rootkit cloaks, including NT Rootkit's device driver object.

General root kit detection requires that you examine the state of the system from as many angles as possible and compare the results; discrepancies can indicate the presence of a root kit. Thus, to detect the presence of cloaked malware processes, you should gather the output of process diagnostic utilities as well as that of a kernel debugger and compare their outputs. A relatively easy way to detect cloaked files and directories is to enumerate the contents of a running Windows system's volumes and compare the contents with those of a clean installation's volumes. The Windows Preinstallation Environment (Windows PE), which Microsoft makes available to Software Assurance (SA) customers, is a clean environment that SA users can use for comparison purposes.

Microsoft Research has developed Strider Ghostbuster, a tool that automates this online-versus-offline comparison. At the time of this writing, the Strider Web site (http://www.research.microsoft.com/rootkit) says the tool will be made available as a research prototype or as part of Microsoft products. Until it's available, you can follow the manual steps listed on the Web site to check your system for root kits.

Also at the time of this writing, at least one antivirus company, F-Secure, had released a beta version of a tool aimed at detecting root kits: F-Secure Blacklight Rootkit Elimination Technology. Other companies are sure to follow suit.

RootkitRevealer
Another root kit detection utility, Sysinternals' RootkitRevealer, is available for free at http://www.sysinternals.com/ntw2k/freeware/rootkitreveal.shtml. RootkitRevealer works by comparing two online scans of the system. One of the scans is at the highest layer in Figure 2, the Windows API; the other is at the lowest layer, raw file system and registry data. RootkitRevealer reports all discrepancies between the scans, so if a file or registry value appears in the low-level scan but not in the high-level scan, RootkitRevealer reports that. RootkitRevealer doesn't scan memory, so it won't detect processes cloaked by direct kernel object manipulation. Instead, RootkitRevealer's solution targets root kits that want to survive a reboot (when memory is reset). Figure 6 shows the RootkitRevealer output for a scan of a system on which Hacker Defender is active.

When you run RootkitRevealer on your system, it might report discrepancies that don't relate to root kits. Any change made to the registry or file system, such as the creation, deletion, or modification of a file or registry value, that occurs after the high-level scan and before the low-level scan might result in RootkitRevealer reporting a discrepancy. The Microsoft SQL Server service, for example, periodically updates a timestamp that it stores in the registry that can result in a RootktRevealer-reported discrepancy.

Another commonly seen discrepancy results from registry keys that have a string-termination character (i.e., a character with a value of 0) embedded in their names. Such names aren't fully visible to the Windows API and therefore the keys aren't accessible to tools such as regedit. Because the key names are visible to the native API, some applications use them to hide licensing or other types of sensitive data. RootkitRevealer doesn't filter discrepancies because a root kit can cloak its malware in even the smallest piece of data.

Hiding root kit and malware processes from RootkitRevealer requires that a root kit cloak the file system and registry data structures that betray the processes' presence. Many of the data structures are undocumented, and manipulating them so that RootkitRevealer doesn't detect inconsistencies is a very delicate process. At press time, no root kits had yet achieved this level of sophistication.

That's not to say, however, that root kits can't attack RootkitRevealer. In fact, CSS has already seen one attack in instances of Hacker Defender discovered on the systems of at least one customer: A malware author added RootkitRevealer to the root process section of Hacker Defender's configuration file. Hacker Defender doesn't hide objects from such processes, so RootkitRevealer's high-level scan of the system matched its low-level scan and it didn't report any discrepancies related to Hacker Defender. Immediately after learning about this attack, Sysinternals released an updated version of RootkitRevealer that performs scans from a process with a randomly generated name.

It's a matter of time before root kit developers find other ways to detect RootkitRevealer's scan and disable cloaking in response, causing Sysinternals to respond with updates that defeat their detection. All root kit detectors are vulnerable to the same types of targeted attacks, and the more popular a detector becomes, the more likely root kit developers will focus on exploiting its weaknesses. Ironically, root kit detectors will evolve root kit mechanisms to hide from being targeted by root kits.

Root Kit Response
What should you do if you believe your system has become infected with root kit–assisted malware? Unless you've obtained removal steps from a reliable source such as an antivirus vendor or CSS, the only safe thing to do is to reformat your disk and reinstall Windows. Don't fall into the trap of thinking that a particular removal tool's rename feature, for example, will uninstall a root kit. The tool might have detected a root kit that's developed anti-rename technology, in which case the rename feature won't work, or worse, the tool might not detect all of the root kit's components and so won't fully clean the system.

Root kit technologies take the fight with malware to a level with much higher stakes. Root kit developers might implement techniques about which the security community is ignorant, allowing malware to go undetected for long periods of time, perhaps until it's too late to stop a catastrophic virus from causing major damage to the Internet or your company's data from falling into the wrong hands. It's crucial for all of us to enforce rigorous security policies and for antivirus companies to continue to develop a thorough understanding of the Windows OS from the point of view of root kit developers—researching ways that root kits might cloak to try to stay one step ahead of these malware developers.