Unearthing Root Kits

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.

End of Article

   Previous  1  2  [3]  Next