Information security professionals are constantly concerned about a wide variety of security-related threats. Some of these threats pose considerably higher levels of risk than others and thus require more resources to counter. Furthermore, risks and their potential impact change over time. Fifteen years ago, for example, risks resulting from the activity of external attackers were one of the most serious. Attackers often launched brute force password guessing attacks, or if they were more sophisticated, password cracking attacks using dictionary-based password cracking tools that are by today's standards rather crude. Fifteen years ago, damage and disruption due to virus and worm infections also comprised one of the most serious types of security risks. Things have changed considerably since then; certain types of malicious code ("malware") other than viruses and worms have moved to the forefront of risks that organizations currently face. Rootkits in particular now represent what might safely be called the ultimate malware threat. This chapter covers the ins and outs of rootkits, the relationship between rootkits and security-related risk, how to prevent rootkits from being installed in the first place, and how to detect and recover when rootkits have been installed in victim systems.
What exactly is a rootkit? The following section defines what rootkits are, describes their characteristics, explains how rootkits and Trojan horse programs differ, and describes how rootkits work.
Definition of Rootkit
The term "rootkit" refers to a type of Trojan horse program that if installed on a victim system changes systems' operating system software such that: 1) evidence of attackers' activities (including any changes to the systems that have been made in installing the rootkit) is hidden and 2) attackers can gain remote backdoor access to the systems at will. Rootkits replace normal programs and system libraries that are part of the operating system on victim machines with versions that superficially appear to be normal, but that in reality subvert the security of the machine and cause malicious functions to be executed.
Characteristics of Rootkits
Rootkits almost without exception run with superuser privileges, the full set of system privileges intended only for system administrators and system programmers so that they can readily perform virtually any task at will. In UNIX and Linux, this translates to root-level privileges; in Windows, this means Administrator- and SYSTEM-level privileges. Without superuser privileges, rootkits would not be very effective in accomplishing the malicious functions they support. It is important to realize, however, that attackers need to gain superuser-level access before installing and running rootkits. Rootkits are not exploit tools that raise the privilege level of those who install them. Attackers must thus first exploit one or more vulnerabilities independently of the functionality of any rootkit to gain superuser privileges on victim systems if they are going be able to install and run a rootkit on these systems.
Additionally, the majority of rootkits are "persistent," whereas others are not. Persistent rootkits stay installed regardless of how many times the systems on which they are installed are booted. Non-persistent rootkits (also called "memory-resident" rootkits) reside only in memory; no file in the compromised system contains their code. They thus remain on a victim system only until the next time the system boots, at which time they are deleted.
How Rootkits Work
Rootkits work using two basic types of mechanisms, mechanisms that enable them to avoid detection and ones that set up backdoors, as explained in this section.
Attackers know that discovery of their unauthorized activity on a victim system almost invariably leads to investigations that result in the system being patched or rebuilt, thereby effectively forcing them to "start from scratch" in their efforts to gain unauthorized access to and control a target system, or in a worst case scenario for attackers, giving investigators clues that can be used in identifying and ultimately convicting the attackers of wrongdoing. It is to the attackers' advantage, therefore, to hide all indications of their presence on victim systems. Most rootkits incorporate one or more hiding mechanisms- as a rule, the more sophisticated the rootkit, the more of these mechanisms are part of the rootkit and the more proficient these mechanisms are.
The most basic type of hiding mechanism is one in which log data pertaining to an attacker's logins and logouts on the victim system are erased so that when system administrators inspect the system's audit logs, they do not see any entries that report the attacker's having logged in or out or having done anything else on the system. Additionally, many rootkits delete any evidence of processes generated by the attacker and the rootkit itself. When system administrators enter commands or use system utilities that display the processes that are running, the names of processes started in connection with all facets of the attack (including the presence of a rootkit) are omitted from the output. Rootkits may also hide files and directories that the attacker has created in a number of ways, including changing commands used to list directory contents to have them exclude files that the attacker has created, or (as explained in more detail shortly) making changes to the kernel of the operating system itself to cause it to provide false information about the presence and function of certain files and executables. To allow backdoor access by attackers, rootkits almost always open one or more network ports on the victim system. To preclude the possibility of discovering rootkits when system administrators examine open ("listening") ports, many rootkits thus also hide information about certain ports' status. Additionally, some rootkits change what happens when certain executables are invoked by legitimate users (e.g., system administrators) such that malicious executables that superficially appear to work like the original executables are run instead.
Rootkits almost without exception also provide attackers with remote backdoor access to compromised systems. One of the most common ways of providing this kind of access is creating encrypted connections such as secure shell (SSH) connections that not only give attackers remote control over compromised systems, but also encrypt information to prevent it from being available for analysis by network-based intrusion detection systems (IDSs) and intrusion prevention systems (IPSs) as well as network monitoring tools. Additionally, SSH implementations used in connection with rootkits require entering a username and password, thereby also helping prevent individuals other than the individual or individuals who installed the rootkit from being able to use the backdoor.
Types of Rootkits
Two fundamental types of rootkits, user-mode rootkits and kernel-mode rootkits, exist. The difference is based on the levels at which they operate and the type of software they change or replace. This section describes both types and explains how each works.
User-mode rootkits replace executables and system libraries that system administrators and users use. The secure shell (SSH) program and the C library in Unix and Linux systems are two of the most common targets. For example, if a rootkit has replaced the SSH program, both the last date of modification and file length will be what they were when SSH was originally installed when system administrators enter commands to query for this information. Additionally, most rootkits target only a few executables and system libraries (often only one); the fewer executables and system libraries targeted, the less likely system administrators and users are to notice that something is wrong.
As their name implies, kernel-mode rootkits change components within the kernel of the operating system on the victim machine or sometimes even completely replace the kernel. The kernel is the heart of an operating system; it provides fundamental services (e.g., input and output control) for every part of the operating system.
How Rootkits and Other Types of Malware Differ
As stated in the definition at the start of this chapter, a rootkit is a type of Trojan horse program. The term "Trojan horse program" actually refers to a wide range of hidden malicious programs; rootkits are thus one kind of Trojan program. Rootkits, however, go farther than conventional Trojans in that the latter are designed to go unnoticed, but do not incorporate active mechanisms that prevent them from being noticed. In general, the primary method of hiding Trojan horse programs is assigning an innocuous name, such as "datafile" or "misc," to them. In contrast, rootkits have mechanisms that actively hide their presence from anti-virus and anti-spyware programs, system management utilities, and system and network administrators. Additionally, Trojan programs are generally created within systems that have been compromised; i.e., they do not replace existing programs and files, but are instead new programs that are installed. As mentioned previously, in contrast rootkits actually replace operating system programs and system libraries.
How Rootkits Are Installed
One of the most common ways that rootkits are installed includes having someone download what appears to be a patch or legitimate freeware or shareware program, but which is instead in reality a rootkit. Software is sometimes modified at the source; programmers can insert malicious lines of code into programs that they write. A recent example of this is the Sony BMG Music Entertainment copy-protection scheme which came with music CDs that secretly installed a rootkit on computers (see sidebar below). Additionally, malicious Web servers often install rootkits into systems by exploiting vulnerabilities in browsers such as Internet Explorer and Mozilla Firefox that allow malicious Web pages to download files of a perpetrator's choice or possibly giving processes on the malicious Web server superuser privileges on the systems that run these browsers.
A relatively new attack vector for installing rootkits is spyware. A recent example of this is a variant of the VX2.Look2Me Spyware Trojan released in November 2005 (see http://www.f-secure.com/sw-desc/look2me.shtml ). Rootkits enable spyware authors to hide configuration settings and program files, enabling the rootkits themselves to be installed in alternate data streams (ADSs-features associated with files and directories in the Windows NT File System that provide compatibility with the Macintosh file system to disguise their presence. Spyware/rootkit combinations are typically installed on victim computers via malicious Web pages or e-mail messages that exploit Web browser vulnerabilities or use "social engineering" tricks to get users to unknowingly install the code.
A final rootkit vector discussed here is viruses and worms. Although most viruses and worms usually do not install rootkits, a few of them do.
|Vendor-installed Rootkits: More Reason to Worry|
The information security community in general and security vendors in particular have been slow to react to rootkit-related risks. More recently, however, a few vendors have installed monitoring software that uses stealthy, rootkit style techniques to hide itself. Long before Mark Russinovich blew the whistle on Sony BMG's use of such software to cloak its digital rights management (DRM) scheme, spyware researchers had seen traces of Sony BMG's controversial technology on PCs without knowing what it was. As Russinovich explained, the detection of the Sony BMG rootkit was not a straightforward task. New techniques and products are emerging to make it easier for technical staff to identify rootkits on compromised machines, but identifying such machines in the first place and then removing the malicious software remains frustratingly difficult. Everyone expects the perpetrator community to write and deploy rootkits--according to McAfee, the use of stealth techniques in malware has increased by over 600 percent since 2004. At the same time, who would expect vendors to write and install rootkits in their products? Vendors such as Sony BMG have thus added another layer of complexity to the already too complex rootkit problem.
Rootkits and Security-related Risk
Rootkits considerably raise the level of security-related risk that organizations face, namely by increasing the cost of incidents, increasing the probability of backdoor access, putting organization's machines at risk of becoming part of botnets, and exposing organizations to the risk of confidentiality infractions because of unauthorized capture, of information, as explained below.
Escalation of Security Breach-related Costs
Although rootkits do not break into systems per se, once they are installed on systems they are (unless they are poorly designed or written) usually extremely difficult to identify. They can reside on compromised systems for months without anyone, the most experienced system administrators included, suspecting that anything is wrong. The cost of security breaches is proportionate to their duration; anything that increases duration escalates incident-related costs.
Increased Likelihood of Backdoor Access
Because rootkits usually include backdoors, they substantially raise the probability that even if effective security measures are in place, attackers will gain unauthorized remote access to systems. Because rootkits are so difficult to discover, whoever gains such access can rummage through the contents of files within the compromised system to glean sensitive and other information. The fact that access of this nature is normally with superuser-level privileges means not only that attackers can remotely access systems any time they wish, but also that they have complete control to do anything that they want with each system that they access in this manner.
Rootkits Often Run in Connection with Botnets
A bot is a malicious executable that is under the control of a master program used by an attacker to achieve a variety of malicious goals. A botnet is comprised of multiple bots that respond to a central source of control. Botnets may be used for numerous sordid purposes; one of the worst is distributed denial of service (DDoS) attacks. Some rootkits function as bots within massive botnets that if not detected can produce deleterious outcomes. If bots are discovered early enough, they can be eradicated without their having had sufficient time to accomplish their goals, but rootkits are normally extremely hard to find, reducing the probability of discovering and deleting bots before they can do their sordid deeds.
Rootkits Often Include Keystroke and Terminal Loggers
Another area of risk that rootkits can introduce is having sensitive information such as credit card numbers and personal identification numbers (PINs) used in banking transactions captured by keystroke and terminal loggers that are part of rootkits. Keystroke loggers capture every character entered on a system, whereas terminal loggers, which pose even greater risk than do keystroke loggers, capture all input and output, not just keystrokes. Keystroke and terminal loggers are often used in connection with identity theft. Additionally, keystroke and terminal loggers are frequently used to steal logon credentials, thereby enabling successful attacks on systems on which the credentials are used. Keystroke and terminal loggers can also glean encryption keys, thereby enabling successful cryptanalysis attacks that result in the ability to decrypt encrypted information.
Prevention is the best cure; adopting measures that prevent rootkits from being installed is far better than having to detect and eradicate them after they are installed. In a way the term "rootkit prevention" does not make sense, however, because rootkit installation is something that occurs after a system is compromised at the superuser level. The one essential element in preventing rootkits from being installed, therefore, is keeping systems from being compromised in the first place. Some measures that accomplish this goal include using prophylactic measures, running software that detects and eradicates rootkits, patch management, configuring systems appropriately, adhering to the least privilege principle, using firewalls, using strong authentication, practicing good security maintenance, and limiting compilers.
Prophylactic measures are measures that prevent rootkits from being installed, even if an attacker has superuser privileges. The challenge of creating prophylactic measures that work reliably despite the fact that an attacker has control of the operating system on a compromised system is great; it should thus come as no surprise that few such measures currently exist. Intrusion prevention is a promising prophylactic measure. Host-based intrusion detection systems (IPSs), IPSs that run on individual systems, can keep rootkits from being installed through policy files that allow and prohibit certain commands from being executed and service requests from being processed if they potentially lead to rootkit installation as well as other undesirable outcomes. Additionally, operating system vendors are starting to incorporate prophylactic measures into their products. Microsoft, for example, has introduced a security feature called "Kernel Patch Protection," or "PatchGuard," in the 64-bit versions of its Windows operating systems. PatchGuard monitors the kernel and detects and stops attempts by code that is not part of the operating system to intercept and modify kernel code. IPSs can keep rootkits from being installed in the first place, provided, of course, that each IPS has an updated policy file that enables the system on which it resides to deny certain kinds of incoming service requests that lead to rootkit installation.
Applying patches that close vulnerabilities is one of the most important measures in preventing rootkits from being installed. As mentioned previously, attackers need to exploit vulnerabilities to install rootkits and run them with superuser-level privileges. If systems and network devices are up-to-date with respect to patches, attackers will be unable to exploit vulnerabilities and thus cannot install rootkits. Patch management tools that automate the patching process generally provide the most efficient way to patch systems. It is also imperative that all patches come from known, trusted sources, and that the hash value for each downloaded patch matches the value provided by the developer.
Configuring Systems Appropriately and Limiting Services that Run on Systems
To prevent attackers from installing user-mode rootkits on your systems, you must harden each system by configuring it in accordance with security configuration guidelines. Vendors such as Microsoft and Sun Microsystems publish such guidelines for each version of operating system that they make, and sites such as the Center for Internet Security offer guidelines as well as automated tools to "grade" your computer to see how well it is secured based on their guidelines. Many types of malware take advantage of services and software running on client or server machines. These services are sometimes turned on by default and running without the user's knowledge, or are left on because of poor security policy or turned on later by the user. Organizations should have a default configuration for their clients and servers that specifies the services and software that are and are not needed, and ensure that these services are not only turned off when they are not needed, but also that the executables for all unneeded services are uninstalled, if at all possible. By ensuring that machines are only running the services and software that are essential for job-related tasks, organizations can reduce the rootkit threat.
Adhering to the Least Privilege Principle
Assigning individuals the minimum level of privileges they need to get their jobs done helps reduce the likelihood that attackers will gain superuser privileges, which in turn reduces the likelihood that attackers will be able to install rootkits. For example, kernel-level rootkits almost always require drivers that run in kernel mode. In Windows operating systems, these drivers can be loaded and unloaded into memory using techniques similar to those necessary to create, enable or terminate services. Only users with Administrator or SYSTEM rights (privileges) are allowed to install programs (including rootkits) that run in connection with drivers or that create services. If an attacker intent on installing a rootkit does not have at least one of these two types of privileges, therefore, the rootkit cannot start and hence cannot hide itself.
Firewalls can also provide some measure of proactive defense against rootkit installation. Rootkits are special applications used by perpetrators. Because firewalls are increasingly performing analysis of network traffic at the application layer (network layer 7) instead of at the network layer (network layer 3), firewalls can improve the ability to identify and intercept malicious traffic in connection with rootkits. Many perimeter-based firewalls now include application layer signatures for known malware and scan traffic as it enters the perimeter from the edge, looking for suspicious files downloaded by users before these files are executed on the user's machines. Many proxy-based firewalls (firewalls that terminate each incoming connection and then create a new outbound connection with the same connection characteristics if the connection meets one or more security criteria) now incorporate scanning engines that increase the likelihood that content associated with rootkit traffic will be intercepted before it is downloaded and executed. At the same time, however, this added firewall functionality has the potentially deleterious affect of harming network performance. Information security professionals must thus balance using real-time network scanning for malicious traffic with network performance considerations.
Using Strong Authentication
The widespread use of static passwords in authentication constitutes a serious vulnerability, one that attackers and malicious code often exploit to install rootkits in systems. Strong authentication means using authentication methods that are considerably more difficult to defeat. Examples of strong authentication methods include using one-time passwords, authentication tokens, and biometric authentication. The strength of authentication in both clients and servers can also be improved by requiring authentication on commonly open services and ports. Using open standards such as the IPSec protocol, which defines an authenticating header for packets sent over the network to guard against spoofing and an encapsulated security payload to help ensure confidentiality of packet contents, also substantially decreases the likelihood of compromise. IPSec is available on Windows, Linux and UNIX platforms; multiple approaches to credential management such as shared key, Kerberos, and Public Key Infrastructure (PKI) can be implemented. A shared key scheme is the simplest, but the most easily compromised. Kerberos, a very strong method of network authentication, is more secure than the shared key scheme, but is challenging to deploy in heterogeneous environments. PKI works the best in heterogeneous environments and is the most secure authentication method, but it also requires the most time and effort. The particular IPSec approach that is best depends on specific needs and business drivers within each organization.
Performing Security Maintenance on Systems
All the measures previously mentioned will do no good unless systems are kept up to date and properly maintained. A large part of system maintenance involves ensuring that system security does not erode over time. Patch management, discussed earlier in this section, is an important part of security maintenance, but security maintenance also requires many activities besides patch management. Organizations should, for example, have a centralized audit policy that mandates that system administrators regularly inspect and analyze the logs of each and every computer in their network .Equally important is regularly inspecting systems to ensure that critical settings that affect security have not been modified without authorization, and also that no new unauthorized accounts (regardless of whether they are privileged as well as unprivileged) have been created. It is also a good practice to regularly perform security audits to see which machines are most vulnerable to attack and compromise. Additionally, for critical systems deploying tools such as Tripwire that regularly check for possible unauthorized changes to file and directory integrity is an important piece of security maintenance. Performing vulnerability assessments, including periodic internal and external penetration testing, is yet another component of security maintenance. Regularly implementing all of these measures will substantially reduce the likelihood that rootkits will be installed.
Limiting the Availability of Compilers
Rootkits have become more complex over time. Although increased complexity has resulted in many advantages for attackers, it has also made installing rootkits considerably more complicated. Many rootkits now consist of many components that need to be compiled and installed, steps that if performed manually require considerable time and also thus increase the likelihood of detection. An increasing number of rootkits thus now contain easy-to-use installation scripts called "makefiles," instructions for compiling and installing programs. Makefiles specify program modules and libraries to be linked in, and also include special directives that allow certain modules to be compiled differently should doing so be necessary. Makefiles require that compilers be installed on systems; the absence of compilers on systems that have been successfully attacked requires that attackers first install compilers, something that increases the time needed to install rootkits. Limiting compilers such that they are installed only on systems in which they are necessary for job-related functions is thus another effective measure against rootkit installation.
Incident Response Considerations
Responding to security-related incidents is often complicated, but the presence of a rootkit makes responding to incidents even more difficult. Incident response includes six stages: preparation, detection, containment, eradication, recovery, and follow-up (SCHU01). Several of these stages, detection, eradication, and recovery, generally become particularly complex when rootkits have been installed in victim systems.
As stated previously, discovering most rootkits is difficult because so much information about the attacks that led to their being installed is deleted or suppressed; considerable time, effort and technical prowess are thus likely to be necessary. There is one comforting thought, however-no attacker or rootkit, no matter how proficient, is capable of hiding all information about an attack, including the presence of a rootkit that has been installed. One or more clues, no matter how small, will be available if proficient investigators and suitable analysis tools are available. Among the clues that are likely to be available are subtle changes in systems, the output of rootkit detection tools, and the output of network monitoring tools.
Unexplained changes in systems are excellent potential indicators of the presence of rootkits. Changes in the number of bytes in files and directories from one point in time to another can, for example, indicate the presence of a rootkit. Almost every rootkit, however, tries to suppress any indication of such changes such that when a command to list directory contents is issued, the size of a file that now contains the rootkit appears to be the same. Suppose that a rootkit has changed the size of an executable in a Unix system, but has also altered the ls -al command (a command used to list all files within a directory, their length, owner, and so on) so that the output of this command falsely shows that the contents of the file containing the executable was unchanged.
The solution for information security professionals is obtaining the output of hashing algorithms such as SHA1 (Secure Hashing Algorithm version 1) from one point in time to another. If there is any change in file contents, the computed hash will change. With a reasonably strong hashing algorithm, there is little chance that someone could make changes in the file without the hash for the changed file being different. If a rootkit somehow masqueraded SHA1 hash value changes that resulted from changing an executable, the change would certainly be detected by comparing the before- and after-change hash values of another hashing algorithm, such as MD5 (the Message Digest Algorithm version 5). It is virtually impossible to deceive multiple hashing algorithms by changing the content of a single file, provided that the algorithms are sufficiently strong against cryptanalytic attacks. Using tools such as Tripwire that compute multiple hash values as well as several crypto checksums and other values to detect changes in files and directories is thus one of the most powerful ways to detect the presence of rootkits.
It is unlikely but not impossible for experienced system administrators and system programmers to spot rootkit-caused changes without using special tools, of which Tripwire is only one. Host-based intrusion detection systems (IDSs) can also spot suspicious changes that could indicate the presence of rootkits, as can system administration tools such as Tivoli and Unicenter TNG. The lsof command in Unix and Linux and fport, a Windows tool, both list open ports and the processes that have opened them, although as mentioned before many rootkits change such commands to suppress information about port activity. Forensics software may also be useful in detecting changes in systems. Finally, it is essential that any detection or forensics tools and outputs from such tools be kept offline (e.g., on a CD) and in a physically secure location until the time that they are used; if left on a system, either could be modified by attackers who have compromised the system on which they reside.
Running Tools Designed to Detect Rootkits
Running tools that are specifically designed to find and eradicate rootkits is another possible approach. Free tools such as chkrootkit (for Linux systems) and Rootkit Revealer (for Windows systems) generally use a variety of detection mechanisms to achieve their goals. These tools constantly need to be updated if they are to have a chance of being effective. It is important, however, for information security professionals to realize that these tools are far from perfect; many rootkits' hiding mechanisms are more advanced than rootkit detector and eradication tools' capabilities.
Unfortunately, anti-virus and anti-spyware tools are currently not up to par in detecting Trojan horses, let alone rootkits, for a variety of reasons. First, rootkit writers are aware that these tools must evade detection by anti-virus and anti-spyware software and thus include mechanisms within the rootkit code that they write that enable them to do so. Additionally, anti-virus and anti-spyware software largely relies on malicious code signatures, binary or character strings that distinguish one piece of malicious code from the others, for detection. Much of today's malicious code, rootkits included, uses a variety of signature detection evasion techniques, however. Additionally, signatures, even if they were to work in detecting rootkits, are invariably post hoc in nature; signatures thus cannot be used to recognize malicious code that is used in zero-day exploits. At the same time, however, a growing number of anti-virus software vendors are incorporating the ability to scan kernel or user-mode memory for known rootkits. The "bottom line" is that at the present time, information security professionals should not rely on anti-virus and anti-spyware software to detect rootkits. If tools designed specifically for rootkit detection are not all that proficient in detecting rootkits (as mentioned previously), it should be little surprise to realize that anti-virus and anti-spyware software do even worse.
Analyzing Output of Network Monitoring Tools
Monitoring network activity is another effective method for detecting rootkits. Finding connections that make little sense, e.g., connections between a billing server of a large corporation and a machine with a domain name that ostensibly belongs to a university, can lead system and network administrators to investigate what has happened to the billing server. If an investigation of a system that has had suspicious connections leads to the discovery that information about other connections but not the suspicious ones is available in audit log data, the presence of a rootkit would be a very possible explanation. Activity on certain ports is another possible rootkit indicator. Although evidence of such activity is likely to be hidden on any machine on which a rootkit has been installed, network-based IDSs, IPSs, and firewalls will nevertheless detect port-related activity that may indicate the presence of a rootkit on such a machine. Both network- and host-based IDSs and IPSs can provide information about attempts to install rootkits as well as the presence of rootkits on systems. Aggregating the output of IDSs, IPSs, firewalls, routers, individual systems, and other sources of log data and then correlating it using event correlation software also increases the probability of detecting rootkits on systems. Effective rootkits do not leave obvious indicators of their existence, so clues (no matter how obscure) about the existence of rootkits from multiple sources are in fact often the best way to discover rootkits.
Eradication involves eliminating the cause of any incident. If a rootkit is discovered on a system, the first impulse on the part of investigators is normally to delete the rootkit as soon as possible. Doing so is usually not the proper course of action, however. In most cases it is far better to make an image backup, a backup of virtually everything on the compromised system's hard drive (including information that is carefully hidden in places other than in files) as soon as possible. Doing this will enable forensics experts to perform a thorough forensics analysis that will enable them to: 1) preserve evidence to potentially be used in subsequent legal action, 2) analyze the mechanisms used by the rootkit and any other malicious tools that were installed, and 3) use the information to identify other machines that may also be compromised on the basis of evidence within the compromised system. Remember-some rootkits are non-persistent, so making an image backup right away is all the more critical if obtaining a copy of a rootkit is necessary.
And now the bad news. Unlike viruses, worms, and most types of Trojan horse programs, rootkits often cannot be surgically deleted. Programs such as chkrootkit and Rootkit Revealer may be able to delete rootkits, but considerations related to eradicating rootkits are different from those for other types of malware. Rootkits almost without exception run with superuser privileges. Any time a system has been compromised at the superuser level, the rootkit and the attacker who installed it could have done almost anything to that system. Discovering all the changes and software replacements is likely to be an almost impossible task, and if forensics experts overlook even one change that has been made, the attacker and the rootkit could regain control of the system shortly afterwards. The best thing to do, therefore, is to take no chances-rebuild the system entirely using original installation media. Failure to do so could result in malicious code or unauthorized changes remaining in the compromised system.
Recovery means returning compromised systems to their normal mission status. As stated previously, if a rootkit has been installed in a compromised system, rebuilding the system is almost always the best course of action. To ensure that rootkits and other malware do not reappear once a recovered system is up and running again, the system must be rebuilt using original installation media, and data and programs must be as they were before the attack occurred. Additionally, any patches need to be installed to help make sure that the system will not succumb to the same attacks that were previously launched against it. Finally, before recovery can be considered complete, a vulnerability scan of the compromised system should be performed to verify that no unpatched vulnerabilities exist.
Rootkits pose a very high level of risk to information and information systems. Information security professionals need to learn about and analyze rootkit-related risk thoroughly and then select, implement and test appropriate security control measures. A successful risk management strategy includes ensuring that multiple system- and network based security control measures such as configuring systems appropriately, ensuring that systems are patched, using strong authentication, and other measures are in place. Because rootkits are so proficient in hiding themselves, extremely strong monitoring and intrusion detection/intrusion prevention efforts also need to be implemented. Furthermore, appropriate, efficient incident response procedures and methods serve as another cornerstone in the battle to minimize the damage and disruption that rootkits generally cause.
In closing, information security professionals need to put the problem of rootkits in proper perspective. Rootkits were first discovered in 1994; even at that time they were remarkably proficient in hiding themselves and creating backdoor access mechanisms. Since that time, rootkits have improved immensely to the point that many of them are now almost impossible to detect. Some of them are in reality "all-in-one" malware-a complete arsenal of weapons for attackers. Additionally, many current rootkits capture sensitive information and are capable of being part of gigantic botnets that can create massive damage and disruption. The "bottom line" is that dealing with rootkit-related risk should be one of the forefront items on the proverbial radar of information security professionals.
From Information Security Management Handbook, Sixth Edition, Volume 2 edited by Harold F. Tipton and Micki Krause. New York: Auerbach Publications, 2008.