Helios
Helios (www.mielesecurity.com/) is described as an "advanced malware detection system" that uses behavioral analysis and does not employ signatures as a detection mechanism. Although it is described as a malware detection system, Helios is also capable of detecting rootkits. Helios is not open source, but it is free, and (according to the Web site, www.anti-rootkit.com/software/Helios.htm) it does have an API that provides access to the product’s core functionality. Helios will not only detect rootkits but also inoculate against rootkit installation. The Helios GUI is illustrated in Figure 7.4.
Tip::
If you are going to download and use Helios, make sure that you install the .NET Framework 2.0. A link to the necessary file is available on the Helios download page.
Figure 7.4 Helios GUI
The Helios Web site includes several videos (downloadable or watchable via streaming) that demonstrate the application’s use and capabilities.
Tip::
Many of the freely available rootkit detection applications that are presented in this topic are easily downloaded and run from a single directory. Deploying these tools during incident-response activities can be as easy as copying them to a USB thumb drive, then enabling the write-protect switch (if your thumb drive has one) and plugging the thumb drive into the system you want to scan. However, you do need to keep in mind any dependencies and requirements, such as Helios requiring the Microsoft .NET Framework 2.0.
MS Strider GhostBuster
The Microsoft Research Center has devoted significant resources to the study of the detection of rootkits on Windows systems, the result of which is the Strider GhostBuster project (http://research.microsoft.com/rootkit/), a tool that is designed to detect rootkits that hook or subvert Window API functions. GhostBuster uses a technique that is referred to as "cross-view diff" (which amounts to a technique similar to behavioral or differential analysis). By performing one query on an "infected" system and then booting to "clean" media (a bootable Windows CD that is uninfected) and running the same query, you can then perform a "diff" between the two outputs and determine what is hidden. This is particularly useful with regard to files, but because an exact copy of the entire system (including all applications and patches) must be maintained on the bootable CD/DVD, this technique might not be particularly useful with regard to processes. To locate "hidden" processes using this technique (such as booting the system to separate, "clean" media), the administrator would be required to maintain a complete set of all applications as well as operating system and application patches and configuration settings on the clean media. Any change, even the slightest, would need to be replicated on separate media. This is perhaps too cumbersome for most infrastructures and investigations.
Although the GhostBuster site does contain links to information and papers regarding various aspects of rootkit technologies, as of this writing an actual GhostBuster tool is not available for download and use. However, some of the papers at the site are extremely useful and make for some very good professional reading. For example, a paper presented at Usenix LISA 2004, "Gatekeeper: Monitoring Auto-Start Extensibility Points (ASEPs) for Spyware Management," provides some excellent insight into Registry autostart locations.
ProDiscover
ProDiscover Incident Response (IR) edition, from Technology Pathways (www.techpath-ways.com), includes functionality to assist the investigator in examining systems for rootkits during incident response activities. Installing the ProDiscover server applet (PDServer.exe) on a system (by either running it from a CD or thumb drive or installing it remotely over the network), the investigator can then connect to the server and perform a variety of actions, some of which are illustrated in Figure 7.5.
Figure 7.5 ProDiscover Functionality for Rootkit Detection
As shown in Figure 7.5, the investigator can attempt to locate unseen processes and files as well as collect some information with regard to the active process list and system state via the menu system in ProDiscover IR. The ProScript API allows a bit more granularity and flexibility in the information that can be collected as well as how it is managed. Attempting to locate unseen processes and files can assist the investigator in locating rootkits on the system.
F-Secure BlackLight
F-Secure is a Finnish company that produces antivirus software (according to the company’s blog, its antivirus product was recently incorporated into the VirusTotal.com scanning site), as well as a rootkit elimination product called BlackLight (www.f-secure.com/blacklight). BlackLight detects objects hidden by rootkit technologies and provides the user with an opportunity to eliminate or remove the offending software.
BlackLight, freely available on a trial basis, comes with both GUI and CLI versions that are available for download from the F-Secure Web site. Figure 7.6 illustrates the BlackLight GUI.
Figure 7.6 BlackLight GUI
Like many of the other rootkit detection applications, BlackLight ships as an executable and does not include an installation program (i.e., .msi file); once you download the executable for whichever version you choose, you can run the application immediately.
Warning::
When using tools that can detect rootkits, or any other malware, for that fact, you want to be sure to avoid using tools that will automatically take action for you, such as deleting files or other artifacts. The whole purpose of doing this sort of examination is to locate those artifacts so that you can develop a profile of the rootkit’s activity and characteristics, and possibly detect it on other systems. Automatically deleting the files once they’re detected will make your job that much tougher because now you have to determine what other actions were automatically taken and what other artifacts may have been deleted.
Sophos Anti-Rootkit
Sophos is another antivirus vendor that also provides antirootkit software. The Sophos Anti-Rootkit (www.sophos.com/support/knowledgebase/article/17004.html) product is freely available for download and use, and like the F-Secure BlackLight product, it comes in both GUI (illustrated in Figure 7.7) and CLI versions. The Sophos product can be used to scan the infrastructure, in addition to single hosts, for rootkits, as well as remove them. Anti-Rootkit scans the system for hidden processes, Registry keys, and files on the local hard drives.
Figure 7.7 Sophos Anti-Rootkit GUI
Tip::
The third article in a three-article series by Jamie Butler and Sherri Sparks, "Windows Rootkits of 2005," was published on SecurityFocus.com on January 5, 2006. This article (www.securityfocus.com/infocus/1854), which discusses five rootkit detection techniques and highlights a total of nine rootkits, is well worth reading.
AntiRootkit.com
F-Secure and Sophos aren’t the only antivirus companies that provide rootkit detection and/or elimination products. Other vendors include the capability to detect rootkits, either as separate products or as integrated components, in their antivirus products. The McAfee Rootkit Detective product searches for hidden files, processes, and Registry keys or values on a potentially infected system, as does Trend Micro’s RootkitBuster product.
Perhaps the best site available for information on rootkit detection techniques and products is AntiRootkit.com. The site provides a blog as well as a list of free and commercial rootkit detection/elimination products (products are listed predominantly for Windows, but there are Linux, BSD, and even a Mac OS X product listed) as well as a list of rootkit prevention products that can be used to prevent or inhibit rootkits from installing in the first place. News and articles referenced on this Web site provide access to even more information.
Additional resources for tools can be found at other Web sites and blogs, such as the following:
■ RaDaJo blog Anti-rootkit Windows Tools (http://radajo.blogspot.com/2007/11/ anti-rootkit-windows-tools-searching.html)
■ GrandStreamDreams blog post Anti-Rootkit Tools Revisited (http://grandstream-dreams.blogspot.com/2008/01/anti-rootkit-tools-roundup-revisited.html)
Postmortem Detection
Postmortem detection of a rootkit poses its own set of challenges. You’re probably thinking, how difficult can this be? After all, you’re looking at an image, not a live system … what would you be looking for? Given various techniques available to malware authors, including antiforensics techniques that are discussed and made publicly available (the MetaSploit Project has an entire section of its Web site dedicated to antiforensics techniques), locating the offending malware, even on an image, can be difficult. However, if you understand what you’re looking for and where to look for it, you are more likely to be successful in your examination.
One method of postmortem detection of rootkits is to mount the image as a virtual file system on your analysis system using a tool such as SmartMount (www.asrdata.com/ SmartMount/) or Mount Image Pro (www.mountimage.com), allowing the files to be read as a file system without engaging the operating system from the image to do so. Both tools can mount the image as read-only so that no changes can be made to the files. From here, you can run any number of antivirus tools against the files in the image. The files within the image appear as just that—files. None of the processes and services from the image are running, so the rootkit will not be engaged, and the kernel of the analysis system is not subverted.
Warning::
Using SmartMount to access an acquired image as a file directory structure is great if you want to scan it with antivirus and spyware detection tools, but the available rootkit detection tools will not be of much use to you. The reason is that these tools search for things being hidden—files, Registry keys, processes, and the like—and when an acquired image is mounted as a drive letter, none of the information is hidden.
Another option available to you is to boot the image into VMware using LiveView (http://liveview.sourceforge.net) and examine the live system for a possible rootkit using any of the tools intended for live systems. This assumes, of course, that you have a username and password so that you can log into the image once it has booted. In next topic, I mentioned that some malware uses software to detect the presence of a virtual environment, and if it does detect that it is running in an environment such as VMware, it can change its behavior to avoid detection. Of course, some rootkits might do this as well, and that secondary behavior could cause issues (i.e., prevent components of the operating system from running correctly or simply cause a BSoD) on the system. You can also scan the virtual system with a port scanner such as Nmap and then compare the results of the scan to the output of netstat.exe or openports.exe. If you find ports that are open using Nmap but you don’t see those ports in the output of netstat.exe, you might have a live rootkit on the system.
A method that I use to quickly check for the presence of a rootkit in an acquired image is to access the Registry Viewer within ProDiscover and navigate to the Services key in each available ControlSet, as illustrated in Figure 7.8.
Figure 7.8 Excerpt from ProDiscover Registry View
Tip::
To determine the ControlSet that is marked as "current" or loaded as the CurrentControlSet when the system is booted, locate the Current value in the System\Select key. The data is a DWORD Registry type and tells you which of the available ControlSets is marked as "current".
Once I’ve located the key, I then sort the entries in the right-hand pane based on the LastWrite time of each key. Most of the entries in this list will correspond to when the system was originally installed. In some cases, several keys might all have the same LastWrite time as a result of a software update that affected all of them, often on the same day. However, when a kernel-mode rootkit driver is installed, it will usually stand out with only one or two entries made on one day. This LastWrite time doesn’t always correspond to the dates provided in an incident report, but in most cases they will stand out like a sore thumb. In addition, they will provide you with a date on which to orient your timeline analysis of activity on the system. Because there does not seem to be any publicly available Windows API for modifying Registry key LastWrite times from user-mode applications, you can be sure that the key’s LastWrite time corresponds to when the rootkit and its driver were installed.
Tools & Traps …
Using RegRipper to Look for Rootkits
Another means for performing this same analysis without loading the image file into a project or case file within your favorite forensic analysis application is to use RegRipper or its associated CLI tool, rip.exe (along with the appropriate plugin) to parse through the Services key within a System hive file, and sort the subkeys by LastWrite time. You can do this quite easily by mounting the image with SmartMount and using a batch file to launch the appropriate command line. However, if you don’t have an image and are instead forced to work with a live system, another option that is available to you is to run RegRipper via F-Response (www.f-response.com). A blogger with the nom de plume of "Hogfly" posted a video on YouTube demonstrating how he used F-Response and RegRipper (http://forensicir. blogspot.com/2008/04/ripping-registry-live.html) to extract data from the Registry of a live system.
An additional means of rootkit detection that hangs someplace between live and postmortem was discussed in next topic. If the investigator dumps the contents of physical memory and quickly analyzes it, the system might still be running, but the analysis will actually occur on a snapshot of RAM. As Jesse pointed out in his "Paradox" paper, a "smart" rootkit will not interfere with the memory dump process because doing so could reveal the presence of the rootkit. After all, a rootkit that causes the operating system to crash dump (resulting in the dreaded BSoD) renders the system unusable to both the administrator/user and the intruder.
If the rootkit were to cause the system to crash dump, the resulting crash dump file could be analyzed to reveal the existence of the rootkit. By collecting the contents of RAM and searching for EPROCESS blocks, you can compare the processes that have not exited with those visible in the active process list to determine which, if any, were hidden by a rootkit.
Prevention
We’ve talked quite a bit about rootkit detection but not about actually preventing rootkits from being installed on Windows systems. The first step to rootkit detection is prevention, performed through system configuration and hardening, vulnerability testing, and so on, all of which is beyond the scope of this topic. However, suffice it to say that taking a minimalist approach to system configuration (e.g., not providing a user with Administrator-level access unless he requires it, and then for those instances in which he does require that level of access) can go a long way toward preventing or inhibiting the installation of rootkits. If a rootkit installation is inhibited, the rootkit won’t function normally and you’ll be able to tell that it’s there; in fact, it might be glaringly obvious that a system has been the victim of an attempted rootkit installation due to error messages or simply extremely unusual behavior.
Warning::
Some folks opt not to take a minimalist approach to system configuration. The major issue is users having Administrator-level access to their systems and being allowed to install any software they can find. I once worked on a case in which I found a system that had a total of four remote desktop services running, and I determined that the intruder had used one of them to gain access to the system. At first, I thought that the intruder had installed some of the remote access software, but the system administrator later told me that all four of the applications were legitimate and had been installed by the IT department; each of the remote access applications was a backup for the others. None of the system administrators had the time or skills to manage all the remote access applications, and the intruder was able to use one of them to gain access to the system.
Summary
Although rootkits have been around for quite a while in both the Linux and Windows worlds, interest in rootkits exploded in February 2005 when the word was mentioned by Microsoft employees at the RSA Conference. Topics (Hoglund’s Rootkits: Training courses (Hoglund has taught rootkit techniques during training sessions at BlackHat conferences) covering rootkit development are available, as are samples of working (albeit in some cases proof-of-concept) rootkits.
Rootkits pose a significant threat to systems and infrastructures, the most serious of which is a lack of education and knowledge on the part of administrators and investigators as to exactly what a rootkit is, what a rootkit is capable of, and how it works. With a stronger understanding of these areas, investigators will be better equipped to address issues of rootkits during both live-response and postmortem investigations.
Solutions Fast Track
Rootkits
- Rootkits are capable of hiding files, Registry keys, processes, network connections, and other objects from the administrator as well as the operating system.
- The use of rootkits and rootkit technologies in malware and cybercrime is increasing.
- A better understanding of rootkit function and capabilities will prepare investigators to address the issues of rootkits.
Rootkit Detection
- Detecting rootkits on live systems requires the use of differential analysis.
- Detecting rootkits on an acquired image of a system can be as straightforward as scanning a mounted image (via Mount Image Pro) with antivirus software or even sorting the Services Registry keys based on their LastWrite times.
- Rootkits might be detected on live systems by capturing and parsing the contents of physical memory to locate processes that are active but not part of the active process list.
Frequently Asked Questions
Q: I found some unusual traffic logged in my firewall, with a time stamp from four hours ago. It seems that a system on my network attempted to make a connection out to the Internet on an odd port. I went to the system in question and didn’t find any active network connections that would account for that traffic. Do I have a rootkit?
A: The short answer is maybe not. Everything that originates from a system, especially network traffic, must have a process or thread that is responsible for generating it. Services will generally run for as long as the system is running, but processes can be short lived. If you do not continue to see similar firewall log entries, it is likely that the process completed and exited, which is why you do not see it on the system.
Q: How do I prevent rootkits from getting on a system in the first place?
A: Configuration management can go a long way toward preventing or inhibiting rootkit infections. If you take a minimalist approach, such as providing only the minimum services and access necessary for the function of the system, you greatly reduce the attack surface. For example, if users cannot install arbitrary software, they are prevented from installing spyware, rootkits, and the like. Reducing the number of services running on a system reduces the options an attacker has available for gaining access and installing his tools and rootkit.
Q: I found a rootkit on one of my servers; now what? I’m told that there’s no way of telling what happened and that I should just wipe the hard drive and completely reinstall the operating system from "clean" media and then load the data back on from uninfected backups.
A: This is very often the route that most administrators take when they’ve encountered a rootkit. However, there are several problems with this approach. First, you should conduct a thorough investigation of the system (or hire professionals to do it) since you might be able to tell what occurred (such as theft of data). Next, you need to determine, as much as possible, how the rootkit got on the system in the first place; perform a root-cause analysis. Without this sort of investigation, you’re going to put a system right back on the network that might be compromised or infected all over again. Finally, if you’re subject to any regulatory oversight (Visa PCI, HIPAA, FISMA, or similar), you might be required (either implicitly or explicitly) to investigate the issue and provide a report, and you need to provide as much information as possible.
