r00tkit Analysis: What Is A Rootkit?

[index] [55,695 page views]

Tagged As: Hacking, Rootkit, and Security

Background

A rootkit is a collection of software binaries or patches that modify an existing piece of code, usually an operating system, allowing a user to operate with administrator privileges.¹ At first glance, viruses and trojans could be mistaken for having the same functionality. A virus will modify a system file to promote its own propagation usually to achieve a special effect at a designated time. Trojans masquerade themselves as another piece of software to infiltrate a computer, after which they typically provide backdoor for hackers to bypass a system’s normal authentication measures. Both of these techniques are still susceptible to detection and can leave traces of their usage.

On the other hand, a rootkit allows a hacker unadulterated access to a system, usually without leaving any trace. They are called "kits" because its software components work collectively to achieve the desired invisibility and access permissions. Additionally, these components often include extra tools for deviant behavior, such as key loggers and packet sniffers, that are part of the overall kit despite not being fundamental in its operation.² For example, the essential rootkit elements might perform some or all of the following:

Alter a system's authentication system for backdoor access or elevated privileges.
Doctor the system logs to ensure that certain activities never get logged for evidence.
Alter the intrusion detection system to ignore key event signatures or report false checksums to an anti-virus client.
Masquerade as normal system utilities so they exhibit normal behavior for regular users or display expected reports to system administrators.

All the while, the rootkit masks the true activities of its spurious, third party users. Rootkits can be simple, but when the target's payoff is worth the effort of using a rootkit, it can be expected that a quality, all encompassing collection of patches and tools will be employed to guarantee success. Rootkits are classified into two categories, user mode and kernel mode. The former involves elementary binary file replacement while the latter embeds itself intricately into the operating system itself.³

Hacker Intrusion

Instant Messengers and P2P

Instant messenger and peer-to-peer networks are becoming increasingly popular targets for transmitting malware. Three prime vectors exist for passing malicious code to users. The first and most blatant technique simply sends the file directly. Here, the rootkit enters the host computer because either the client is set by default to download and open incoming files or the users themselves are tricked into accepting the download. Second, weaknesses in the client software itself can be exploited against libraries to which they are linked. For example, it would be possible to take advantage of Microsoft hosts with a vulnerable GDI when they display an image embedded in a message. Lastly, the client itself can be breached through a buffer overflow in its handling or perhaps through weaknesses in its networking protocol. In the year 2005, attacks against instant messenger users rose by 3,295% according to IMlogic.⁴ An older worm, W32/Sdbot-ADD, was adapted to exploit users of AOL Instant Messenger, embedding the LOCKX.EXE rootkit into a computer in conjunction with a series of spyware applications. Once installed, the rootkit allowed direct system access while providing protection for its symbiotic worm that received updates via an IRC channel.⁵ P2P clients are especially at risk from trojan horses as delivery mechanisms for rootkits. After sharing a trojan horse file on a P2P network, remote network sweeps can scan IP addresses for downloaders with computers exposing the freshly installed backdoor. From there, the hacker accesses the computer and finalizes the rootkit with tailored configurations for the desired target.

Electronic Mail and Web Browsers

The same principles by which instant messenger clients can be undermined are applicable to e-mail and web browsing clients. The inherent danger of shared libraries is that a single exploit will render multiple applications vulnerable. Hackers utilize the shared vulnerability to try attacking different applications linking into the library. For instance, Microsoft's HTML rendering engine is shared between applications that require Internet Explorer. Users of Outlook are subject to the direct approach of having the package delivered in an e-mail or via a link in an e-mail message to their client's preview pane. Both e-mail and browser clients alike present the additional attack vector of rendering malignant HTML messages. Carefully crafted messages may contain exploitation javascripts, activeX code, buffer overruns against GDI rendering, pixel images to download data from across the Internet or draw from any number of client specific bugs. Techniques for exploitation that do not require user interaction are a powerful tool.

Remote Hack

Tricking users into executing malicious code through trojan horses or social engineering is often the simplest approach, but not the only technique at a hacker's disposal.⁶ Most computers, even with vendor patches, are vulnerable to remote exploits without requiring any user intervention.⁷ Hosts are vulnerable as early as the actual installation of an operating system with an average time to compromise of less than twenty minutes.⁸ Vulnerabilities range anywhere from buffer overflows, misconfigured servers, dictionary passwords, lack of security hot fixes or general software errors. After probing the host for an external weakness, the hacker will break into the computer, install the rootkit software, erase the evidence and vanish until it is time to access the host again. Herein lies one of the most compelling reasons for a hacker to employ a rootkit. A remote vulnerability may be caught and patched in time, but a carefully constructed rootkit may lie hidden on the system for long periods of time, which allows persistent host access.

System Subversion

Insertion

Once the hacker has gained administrative privileges on the computer through the use of a local exploit, there are many techniques by which a rootkit can be installed into the running system. User mode rootkits are amongst the easiest to install. Under UNIX, the rootkit is then typically downloaded to the host via FTP and then un-tarred/zipped into the appropriate binary file directory. Windows installations will follow the same approach, although some file transactions may not be possible without a system restart. A more complicated rootkit will actually be compiled on the target host itself to ensure a tighter meld with its operating environment.

Installing a kernel-mode rootkit is not much different. One technique is to install a false device driver to operate in conjunction with the kernel code. The driver would then have access to core system tables whereupon it can begin to redirect function calls to itself instead of the normal kernel routines.⁹ As the complexity of the rootkit grows, so too does the installation procedure. Often, the procedure must become automated with scripts in order to accomplish the numerous tasks in as short a time period as possible. The installation period is the most vulnerable time for the hacker as their actions are completely exposed until the rootkit begins to function.

Hiding Files

A more sophisticated rootkit attack will actually modify elements of the operating system kernel itself to redirect low-level functions to the hacker's choice of functions. A compromise of the kernel will indirectly render all programs that execute system calls susceptible to misinformation. For example, assume that a rootkit has hooked into the Linux kernel and is intercepting system calls for sys_read() and sys_open(). When a system administrator suspects a breach of integrity, an MD5 checksum routine will be run against a select group of system files. The rootkit's hook into sys_open() detects an attempt to read one of the modified files and protects itself against discovery by feeding back the original, unmodified contents through sys_read() calls rather than the actual contents. For any other file operation, the rootkit allows the normal sys_read() function to operate normally. Thus, the MD5 algorithm will process data that does not include the rootkit and report a checksum match, falsely indicating the system is secure.¹⁰

Hiding Processes

Cloaking executable code in memory is more difficult than concealing the physical files on disk. The most elementary solution is to first hook into the operating system's application programming interface (API) regarding process functions. Adjustments to the SystemInformation buffer and hooking NtQuerySystemInformation() allow a rootkit to control the perceived process list within Windows.¹¹ Although such a measure could hide code from cursory utilities, detectors running with Ring Level 0 privileges would identify the disparity between API results and actual data structures. Rather than operate a rootkit as an independent process, a meshed approach will keep the data structures intact. A raw memory scan, for trace signatures, will reveal the rootkit because no kernel function interaction is required. Therefore, a rootkit must falsify the contents of memory from any inspection.

There are two approaches to solve this problem. First, a rootkit may employ polymorphic technologies to alter its physical representation in RAM. Polymorphism involves dynamically changing a program's raw instruction opcodes without losing functionality. Code utilizing polymorphism thwarts signature scanners by greatly reducing the consistency of internal patterns. A second approach to hiding processes in memory involves directly manipulating the memory management units of the operating system.¹² This is possible, by taking advantage of how x86 processors implement virtual memory. By marking memory pages containing rootkit code as "dirty" the hacked page fault handler will intercept access attempts to the memory locations and can make the determination on the origin of the request. A detected scanner will be directed to a RAM address that has been scrubbed to show only clean contents. This concept first emerged with a modified version of the Fu rootkit called Shadow Walker which successfully hid its processes in RAM from detection.

Hiding Events

Invisibility requires that a rootkit properly doctor the system logs to remove evidence of activity. Once a rootkit is installed, log management becomes a relatively trivial task. A rootkit must locate and alter logs for each networking service, modified binary and kernel type. Two approaches for log doctoring are complete deletion and selective modification. Complete deletion will protect the attacker from easy tracing, but will flag the system as having been modified. Selective modification provides the same level of concealment but does not raise suspicions for an invalid system log. Rootkits will often target well known UNIX and Windows transaction logs in locations such as:¹³

/var/log/messages
/var/log/lastlog
/var/log/utmp
/var/log/wtmp
Event Viewer: Application
Event Viewer: Security
Event Viewer: System

Once an attacker has installed a rootkit, the package should provide protection against further logging. Only the evidence of the initial intrusion remain for removal. Such evidence typically consists of:

network activity from the firewall
login records for the access
compiler messages from local rootkit customizations
file operations from the installation itself
remaining activity such as logged keystrokes or terminal use

Under UNIX, the logs must be adjusted by manually seeking the log's text and performing standard file operations on them. Windows includes API function classes EventLog.GetEventLogs(), EventLog.WriteEntry() and EventLog.Delete() to directly manipulate the Windows event logs.¹⁴

Backdoors

A rootkit is ultimately a fruitless effort unless it can be remotely accessed. Under a UNIX system, it is common to find remote connection methods such as telnet or SSH available. These shell daemons will often be patched or replaced, a technique employed by the Vihrogon SSH rootkit, allowing any user account to be logged into when provided a special password.¹⁵ Windows computers generally do not feature shell account access. Access is available via SMB file-sharing, a default service open to the network. When compared to workstation editions of Windows, even more services are available for exploitation on Windows Servers. For quick and dirty remote access, these services are more than adequate to carry the network traffic between target host and digital assailant. However, closer inspection of the seemingly harmless and casual network traffic will reveal the transmitted messages or be traceable to their source. More elaborate schemes of control are necessary to overcome this weakness.

The next most subversive technique for feeding data into a backdoor is to embed it within innocuous traffic. Since the original code on the target system has already been replaced or bypassed, it can be designed to seek out bits of information from headers not normally used or to recognize packets with CRC (cyclic redundancy check) errors as valid. A simple application of "port knocking" which is a series of network hits against the target's listening ports in a particular sequential progression, could trigger the server to treat all traffic from a particular host as destined for the rootkit. Embedding the command data into an ICMP stream would even allow the initiator to fake return IP addresses to maintain anonymity, albeit at the sacrifice of interactivity.

Using Internet Relay Chat (IRC) is one of the most common mechanisms for interactive, anonymous control. The rootkit reaches out to an IRC server and joins a heavily populated channel where it has been scripted to respond to conversational commands. Utilizing IRC as a control mechanism allows hackers to launder the connection to protect themselves.

To eliminate outbound network connections, a rootkit can exploit naturally inbound traffic through steganography, a technique for hiding messages within images.¹⁶ After a rootkit replaces a system's graphics library, all applications using imagery become a remote control conduit. Commands and code updates embedded in JPEG, BMP and PNG images are delivered and processed by the rootkit via innocuous junk e-mail. This mechanism provides anonymity through spam remailers and will be delivered through regular e-mail synchronization. The possibilities for implementing remote access to the rootkit from across the Internet are extensive.

Rootkits in Practice

UNIX Rootkits

The rootkits branch of malware originated through an evolution of functionality. For example, in late 1999, Sans Institute traced compromises of Solaris systems to a combination rootkit/smurf package.¹⁷ Smurf attacks were very popular in the late '90s as a simple denial of service attack via forged ICMP (Internet Control Message Protocol) ping packets.¹⁸ The rootkit bundled with the smurfing tools was very simple in nature and designed to hide the smurfing software from cursory inspection. It consisted of a few tools:

cleaning script - to remove traces of the trojan activity
modified inetd.conf - to remove restrictions and wrappers from network protocols
trojan fingerd server - to allow remote control through what appeared as legitimate traffic
trojan telnet server - to allow remote, root login capability
sunsmurf - to actually implement the smurfing attack

Although persistent in design, this package was merely a user mode rootkit, which meant basic tools were capable of revealing its presence. Other early rootkits were similarly unsophisticated and most were intended for obtaining quick administrative access with only the most basic of cleanup routines to hide their presence. This simplistic design emerged because the flavor of hacking was to quickly take over a computer for anonymous use in denial of service attacks. Contemporary hacking has changed in focus and intent. Complete stealth and long term persistence have emerged as important design criteria for modern rootkits to evade increasingly advanced detection tools.

The technology became more sophisticated with the T0rn rootkit, which replaced actual system binaries with the intent to hide information. Replaced programs included critical files such as du, find, ifconfig, login, ls, netstat, ps, sz and top.¹⁹ T0rn is an improvement over previous rootkits because of its increased chances for evading detection. When an administrator looks for anomalies using the swapped binaries, "controlled" outputs are produced that mask and hide the underpinnings of the rootkit from observation. T0rn was still detectable with other UNIX tools because the rootkit did not replace enough system binaries, leaving itself exposed. Likewise, tools that relied on the kernel for information such as MD5 hash summation software were not fooled and could detect the replacement of original binaries.

Windows Rootkits

Rootkits under Windows tend to operate more at the kernel level through function hooking rather than by directly replacing binary applications. Part of this trend is due to Windows operating more as an integrated system of function calls instead of the UNIX collaboration of tools motif. As such, rootkits must become part of the operating system to enable any sort of functionality. Kernel patching under Windows proves to be a relatively easy process, a task once performed with as few as four bytes to provide administrative access to the EVERYONE user group.²⁰ The principle of Windows kernel patching involves injecting code into Ring Level 0 whereupon the Trusted Computing Base is violated. With the majority of Windows users either running as administrators or leaving computers without the latest patches, taking advantage of system weaknesses for this degree of access becomes trivial for hackers. Early rootkits for Windows did little in an attempt to hide their presence as the only code running on the system was the kernel code itself. Despite the possibility of infecting the kernel at Ring Level 0, early threat scanners could not detect the rootkits as they generally conformed to documented security models and did not even have access to these files or memory regions.

Although Ring Level 0 rootkits in Windows are most desirable, user mode rootkits still pose a system threat. A rootkit operating at Ring Level 3 must first merge itself with running applications in an attempt to garner a higher operating privilege. To achieve this, coders choose from options including:

SetWindowsHookEx() to hook into another application's message queue
CreateRemoteThread() to add a thread into another's memory space
debugging features which allow thread contexts to be altered
changing an application's DLL import table
directly overwriting code segments with branching JMP instructions.

This approach only operates within the context of the hijacked application and does not provide the system-wide effects that a rootkit typically offers. However, careful coding and design can allow the rootkit code to hop from application to application until a path is found into the context of a system-wide resource such as the TASKMAN.EXE or EXPLORER.EXE processes. Once injected into these processes is made, the rootkit has global visibility and increased privileges for restricted function calls. The rootkit NTIllusion makes use of these principles to hijack Windows XP privileges from a non-administrative account.²¹ As the rootkit increases its privilege base, the same hooking functions allow it to hook into increasingly more valuable targets including system API calls. Hooking these calls enable the rootkit to return only values that will not disclose its presence. Thus, through a series of function calls and browsing the internal Windows process tables and data structures, even a user-mode rootkit can achieve full administrative access while maintaining complete stealth.

Professional Rootkits

Rootkits themselves are evolving in their public visibility. Borrowing from the economic principle of specialization, malware authors focus their programming efforts on writing the best worm, the best virus, the best exploit and the best rootkit. Outsourcing malware technology allows for faster, better more robust applications which in turn equal profits through the sale of stolen information, personal identities or networks of zombie computers. This paradigm change in malware development allows programmers to consolidate their collective knowledge and expertise. Underground market sales of hijacked computer networks is growing as a lucrative business, leading enterprising hackers to turn their wares into professional products for monetary gain.

The Golden Hacker Defender software package is regarded by software security firm F-Secure as the modern evolution of rootkits, a professional package available for bundling with different types of malware.²² It represents a serious security threat for system administrators.²³ From the GHD website, malware authors can purchase anti-detection packages consisting of the relevant features for hiding their work or even request customized packages and programming.²⁴ One of GHD's most powerful features is rootkit detector detection, a series of algorithms designed to fingerprint detectors and shut them down before they can function.²⁵

In November of 2005, it was discovered that Sony BMG music CDs were utilizing rootkit technology licensed from First 4 Internet Ltd. as a means of digital rights management under the name XCP.²⁶ XCP is designed to thwart music piracy by detecting functions called by CD Ripping software and deny successful execution when protected CDs are present. To perform this feat, XCP must embed itself into the operating system at the kernel level to hook the relevant APIs. Furthermore, XCP includes rootkit-like features to hide its core files, its execution and its removal.²⁷ Files prefixed with $sys$ become hidden and protected from both the administrator and the operating system. Perhaps not the original intent of XCP, its functionality matches that of a rootkit and has been exploited by the Backdoor.IRC.Snyd.A trojan to provide protective services.²⁸ An additional trojan horse, Troj/Stinx-E, also takes advantage of the XPC rootkit's features to open a backdoor for hackers and download viral updates through the network.²⁹

Most rootkits are maintained on the Internet as public, open source projects. As such, malware is able to borrow more and more from the growing pool of knowledge to perpetuate itself. A recent application of such developed rootkit technology is to protect the resident code of spyware programs. The Cool Web spyware package utilizes elements of open source rootkits to embed itself deeply into Windows operating systems, making removal increasingly difficult.³⁰ Borrowed rootkit code finds its way into other applications as well. Seizing heavily upon a rootkit's covert nature, software has evolved to make use of these capabilities. A remote control program called RBot and a virus known as Myfip.H borrow heavily on the Fu rootkit to help them vanish from anti-virus scanners.³¹

Detection

Basic Forensics

Just as rootkits have numerous vectors for infecting a computer host, administrators have a number of methods for detecting the presence of a rootkit.³² One of the simplest techniques for ensuring system integrity is cataloging a calculated hash value for critical system files. This is often performed using the MD5 algorithm to create a digital fingerprint from which future fingerprints can be compared. It is imperative that known clean hashes are saved either externally or in read-only format to prevent their corruption. File systems can also be scanned for "known" and "hidden" files. Although advanced rootkits strive for to mesh with system files, there are still support and helper files littered across a host that betray a rootkit's presence. File permissions rarely change in executable binaries, so a good indicator of a file's compromise is a pattern occurrence of incorrect permissions across files known to be targets of rootkits.

The file system is not the only source for seeking out rootkit behavior. Many rootkits are able to stop events from being logged once they begin, but there may be evidence of the rootkit's installation that was not wiped. UNIX maintains scores of event logs from console, system, kernel and application records. Log entries that may be present from a rootkit include blatant remote logins, unusual application activity, database accesses or file permission errors. Furthermore, a rootkit installed in default fashion by a script is unlikely to detect non-standard logs. Event cleansing is a cardinal feature of rootkits, but that does not always mean no trace will be found in the logs.

The analysis of network activity is also critical in identifying a potential rootkit. Since the entire point of a rootkit is to allow stealthy, administrative, remote logins, there will be network activity between the compromised host and the malignant user. Utilities can list which network ports are bound to various binaries resident in memory and with which remote network addresses a host is in contact. Depending on their configurations, firewall logs and intrusion detection systems will record failed accesses or mischievous behavior. Even traffic counters can assist by revealing unusual amounts of network activity.

However, almost every technique listed relies on trusting system integrity. If the API or drivers for the file system are redirected to a rootkit, the utilities will report fake feedback to hide the rootkit or disguise its presence amongst normal files. Likewise, event logs can be doctored and the tools covering system networking can be infected to falsify reported statistics. Few methods exist that can completely ferret a rootkit into the open that do not rely on the system itself for trust.

Advanced Sleuthing

A more advanced technique for rootkit detection involves using a software debugger to expose alterations in the running system. Digital forensics require an intimate understanding of the operating system's code, system programming and microprocessor architecture. Kernel mode rootkits will alter system tables and function calls. Under Linux, a kernel function is executed with the following steps:

A program loads function's parameters into processor registers and then executes a software interrupt.
The processor then consults the IDT (Interrupt Descriptor Table), identifies the vector associated with interrupt 0x80 (Linux's system call vector) and begins execution at that vector.
A routine interprets the parameters passed in the registers, consults a system call table for a function pointer and then begins executing the appropriate function.³³

With this knowledge, an administrator can browse the system tables, a process made easy using GDB (Gnu Debugger), to look for the signature traits of rootkits. First, an analysis of the kernel must be made. In Linux, the system call addresses are fixed permanently in the kernel during compilation and linking. The System.map and vmlinux files can be analyzed with GDB to determine the unaltered values of the system call table.³⁴ Next, GDB can be used to dump the system call table from a running system. A side-by-side comparison of the system call vectors will reveal changes to the kernel that are indicative of a rootkit.

The overriding graphical nature of Windows alters the nature of its rootkits. There are not as many single tool binaries within Windows for direct file replacement as there are in UNIX but programmers can still use debuggers for rootkit detection. Kernel debuggers for Windows include the Microsoft Kernel Debugger and LiveKD from SysInternals.^35,36 Kernel symbols are installed into the Windows system (to maintain programmer sanity while performing a kernel debug) that will reveal the modules being analyzed by name and function within the debugger. Following this step, a programmer can begin browsing code for anomalies. A DLL (dynamic link library) can be inspected to detect the presence of DLL injections and the SST (System Service Table) can be inspected for pointers that lie outside of the kernel space.³⁷ Although the ability to perform kernel debugging is available under Windows, the task is not as "easy" as it is for UNIX. Because a Windows executable allows system referencing pointers to be adjusted at load time, it is not possible to do a function call comparison between a file binary and a binary in memory. Additionally, the manner in which Windows drivers integrate into the system blurs which pointers are legitimate and which are errantly redirected. Oftentimes, the only chance an administrator has to discover a rootkit with a kernel debugger in Windows is by accident. Since the rootkit alters basic system calls, errant behavior in regular applications may result as incompatibilities arise which may be the only clues for an administrator as to which modules to debug.³⁸ The complexity of Windows lends itself to automated rootkit discovery tools in recognizing system anomalies.

Tools of the Trade

The Windows operating systems present a drastically different environment from UNIX but still must target the same fundamental indicators: file system, process listing, log removal, and hiding both memory and network usage. Ironically, the enormous Windows API is simultaneously both boon and bane for rootkit programmers. The number of API functions enlarges the pool of attack vectors a programmer can take against Windows computers, but also presents too many "loose ends," that enable detection. The utility RootkitRevealer by Mark Russinovich takes advantage of multiple ways to achieve the same result to ferret out rootkit behavior.³⁹ Internally, RootkitRevealer accesses multiple functions from both the Win32 API and the NT Native API to compare resultant outputs for discrepancies. The tool automates the comparison process against executables, registry keys and memory listings. Microsoft research labs produced a tool called Strider that operates on the same premise, comparing a sampling of likely attack points through multiple function calls to test for related output.⁴⁰ Strider takes the process one step further using a WinPE system from a CDROM to analyze the contents of a drive and compare them to running results.⁴¹ Microsoft calls this technique "cross-view diff" as opposed to the traditional "cross-time diff" because the data is not being compared to older information.⁴² Any resulting differences in hashes of critical system files and registry hives will reveal a rootkit installation.

There are tools to assist in automating the rootkit detection process.

chkrootkit⁴³ - The chkrootkit auditing scripts have been in development since 1997 and are capable of detecting rootkit signatures in binaries, log anomalies, errant network behavior and loadable kernel modules.
KLister⁴⁴ - KLister is a collection of several tools designed to interface with the deepest internal kernel structures in order to expose rootkit code.
Malicious Software Removal Tool⁴⁵ - This self updating tool operates in conjunction with the operating system at all levels for detecting anomalous behavior and rootkit signature hits. As a product of Microsoft, the Malicious Software Removal Tool has the advantage of utilizing unpublished, internal, hidden APIs that may not have been publicly disclosed to other tool creators.
PatchFinder2⁴⁶ - PatchFinder2 utilizes a technique called Execution Path Analysis to detect kernel and DLL rootkits. EPA puts the processor into a single-stepping debugger mode to count processor operations per function. This generates empirical evidence to compare against a known "clean" value.⁴⁷
Rootkit Hunter⁴⁸ - Booting from a Gentoo Linux CDROM, Rootkit Hunter objectively analyzes a host system in an inert state against downloadable signatures to detect rootkits while they are dormant.
RootkitRevealer⁴⁹ - RootkitRevealer compares the outputs of multiple APIs (such as Win32 and NativeNT) in the Windows operating system to detect discrepancies.
Tripwire⁵⁰ - As rootkits alter the nature of original files, Tripwire is able to detect malware through the principle of Change Auditing where comparisons are made between different aspects of a known system state and the present running system.
VICE⁵¹ - VICE browses call tables to detect anomalous hooks that redirect function calls to a rootkit.

Interestingly, the same techniques for implementing a rootkit are often required to design a tool for detecting one. Much like the race between virus and anti-virus coders, rootkits and their detectors each seek deeper access into the operating system in order to maintain or evade complete system visibility.

Prevention

Reliance upon rootkit detection software alone cannot counter the growing threat. Hackers working mutually on projects such as the Golden Hacker Defender are able to modify implementations to defeat detectors faster than corporations can offer a change. Threat detectors may be able to update signatures and definitions, but the fight against rootkits require fundamental changes to how detection engines integrate with the operating system. A layered, defense-in-depth approach is the best method of preventing a host from receiving an unwanted rootkit installation.⁵² The following are examples of such defensive measures:

Employ network firewalls.
Control physical access to network and hosts.
Properly install and configure the host operating system.
Keep current on operating system patches.
Activate and properly configure host based firewalls.
Install software only from "clean" sources.
Use Anti-Virus software and keep viral definitions up to date.
Enable malware detectors for additional software protection.
Utilize strong authentication procedures for system access.
Operate with minimal privileges; do not run daily tasks as an administrator.
Generate read-only checksums of critical system files.
Use multiple malware detectors to protect against different attack vectors.

Protecting against rootkits requires planning a strategy in advance and administrative diligence in adhering to its tenants. First and foremost, the system must be properly installed and configured to establish a "known clean" baseline. Metrics must be taken at each change to confirm a benchmark of data for anomaly detection in later system iterations. The right tools, appropriate for the type of system, must be mustered, installed and maintained. Once a host is on-line and operational, its integrity must be monitored through comparative analysis to known records, scheduled system scans and behavioral observation. Often, the observations of system behavior are the most telling of system infection. Indicators are found in system logs, network activity, errant CPU usage or other seemingly minor minutiae. Keeping up with the latest security bulletins will keep an administrator aware of which behavioral deviances indicate a threat.⁵³

Summary

Rootkits are a different breed of security threat than viruses, worms or Trojans; properly written, they allow a hacker to re-access a computer system with full privileges, perform tasks in secret and depart the system without leaving a trace of the access. A rootkits' stealth and the privileges with which their exploiters operate present one of the greatest security threats to system and network. The mere detection of a rootkit indicates deeper security breaches. Only perseverance, attention to detail and meticulous monitoring can protect a network from this hidden threat.

Footnotes

RootKit, LinuxQuestions.org, accessed September 2005 from http://wiki.linuxquestions.org/wiki/Rootkit
Berg, Al. The Root Of The Rootkit, SearchSecurity.com, July 2005, accessed November 2005 from http://searchsecurity.techtarget.com/tip/1,289483,sid14_gci1103744,00.html
Dillard, Kurt. What Are User-Mode vs. Kernel-Mode Rootkits, SearchWindowsSecurity.com, May 2005, accessed November 2005 from http://searchwindowssecurity.techtarget.com/originalContent/0,289142,sid45_gci1086469,00.html
Evers, Joris. AIM Worm Plays Nasty Trick, News.com, October 2005, accessed November 2005 from http://news.com.com/AIM+worm+plays+nasty+new+trick/2100-7349_3-5920403.html?tag=nefd.top
Tech Support Center News, University of San Diego Portal, November 2005, accessed November 2005 from http://unet.sandiego.edu/tsc.html
Dillard, Kurt. How Does An Attacker Install A Rootkit, SearchWindowsSecurity.com, May 2005, accessed November 2005 from http://searchwindowssecurity.techtarget.com/originalContent/0,289142,sid45_gci1086466,00.html
Vea, Matthew. Default Exploits In Box, OmniNerd, August 2004, accessed November 2005 from http://www.omninerd.com/2004/08/30/articles/11
Acohido, Bryon. Unprotected PCs Can Be Hijacked In Minutes, USA Today, November 2004, accessed November 2005 from http://www.usatoday.com/money/industries/technology/2004-11-29-honeypot_x.htm
halflife@infonexus.com, Abuse Of The Linux Kernel For Fun And Profit, Phrack, Volume 7, Issue 50, File 5 of 16, April 1997, accessed November 2005 from http://www.l0t3k.net/biblio/rootkit/en/P50-05.txt
Burdach, Mariusz. Detecting Rootkits And Kernel-level Compromises In Linux, SecurityFocus, November 2004, accessed November 2005 from http://www.securityfocus.com/infocus/1811
Holy Father, Invisibility On NT Boxes, The Hacker Defender Project - Board, August 2003, accessed November 2005 from http://hxdef.czweb.org/knowhow/hidingen.txt
Sparks, Sherri. Raising The Bar For Windows Rootkit Detection, Phrack, Volume 0×0b, Issue 0×3d, Phile #0×08 of 0×14, August 2005, accessed November 2005 from http://www.phrack.org/phrack/63/p63-0×08_Raising_The_Bar_For_Windows_Rootkit_Detection.txt
nebunu. Ninja - The Art of Being Invisible, NewOrder, August 2002, accessed November 2005 http://neworder.box.sk/newsread.php?newsid=5543
Joshi, Bipin. Manipulating Windows Event Log, DotNetBips, January 2005, accessed November 2005 from http://www.dotnetbips.com/CB52C020-36ED-4383-8C92-F2A2C27E67FB.aspx?articleid=200
Solar Eclipse. Vihrogon: Advanced SSH RootKit, NewOrder, August 2002, accessed November 2005 from http://neworder.box.sk/newsread.php?newsid=5798
Steganography, Webopedia.com, accessed November 2005 from http://www.webopedia.com/TERM/S/steganography.html
Sans Institute. Analysis Of Rootkit/Smurf Payload Toolkit v1.1, SANS Institute, January 2000, accessed November 2005 from http://www.sans.org/y2k/TFN_toolkit.htm
Smurf Attack, Wikipedia, accessed November 2005 from http://en.wikipedia.org/wiki/Smurf_attack
Miller, Toby. Analysis Of The T0rn Rootkit, SANS Institute, accessed November 2005 from http://www.sans.org/y2k/t0rn.htm
Hoglund, Greg. A REAL NT Rootkit, Patching The NT Kernel, L0T3K - Women Reclaim The Globe, September 1999, accessed November 2005 from http://www.l0t3k.net/biblio/rootkit/en/P55-05.txt
Kodmaker@sysshell.org. NTIllusion: A Portable Win32 Userland Rootkit, Phrack Volume 0×0b, Issue 0×3e, Phile #0×0c of 0×10, accessed September 2005 from http://www.l0t3k.net/biblio/magazine/en/phrack/0062/p62-0×0c_Win32_Portable_Userland_Rootkit.txt
Sanders, Tom. Rootkit Creators Turn Professional, VNUnet.com, October 2005, accessed November 2005 from http://www.vnunet.com/2144149
Holy Father, Golden Hacker Defender, The Hacker Defender Project - Board, accessed November 2005 from http://hxdef.czweb.org
The Hacker Defender Project - Antidetection Service, The Hacker Defender Project - Board, accessed November 2005 from http://hxdef.czweb.org/antidetection.php
Golden Hacker Defender, Cool Blog, October 2005, accessed November 2005 from http://www.cool-blog.org/post/Cool_Blog/40/Golden-Hacker-Defender
First 4 Internet Ltd. accessed November 2005 from http://www.first4internet.com/
Russinovich, Mark. Sony, Rootkits and Digital Rights Management Gone Too Far, SysInternals, October 2005, accessed November 2005 from http://www.sysinternals.com/blog/2005/10/sony-rootkits-and-digital-rights.html
Backdoor.IRC.Snyd.A, BitDefender, accessed November 2005 from http://www.bitdefender.com/VIRUS-1000058-en—Backdoor.IRC.Snyd.A.html
Troj/Stinx-E Virus, AntiVirusProgram.se, accessed November 2005 from http://www.antivirusprogram.se/virusinfo/Troj/Stinx-E_7159.html
Roberts, Paul. Spyware Meets Rootkit Stealth, eWEEK.com, June 2005, accessed November 2005 from http://www.eweek.com/article2/0,1759,1829744,00.asp
Roberts, Paul. Rootkits Spawn New Malware, eWEEK.com, May 2005, accessed November 2005 from http://www.eweek.com/article2/0,1895,1818369,00.asp
Scanning Techniques, Rootkit.nl - Protect Your Machine, accessed November 2005 from http://www.rootkit.nl/articles/rootkit_scanning_techniques.html
Beck, Michael. Linux Kernel Internals, Addison-Wesley Professional: 1997.
Burdach, Mariusz. Detecting Rootkits And Kernel-level Compromises In Linux, SecurityFocus, November 2004, accessed November 2005 from http://www.securityfocus.com/infocus/1811
Debugging Tools for Windows - Overview, Microsoft, accessed November 2005 from http://www.microsoft.com/whdc/devtools/debugging/default.mspx
Russinovich, Mark, SysInternals Freeware - LiveKD, SysInternals, accessed November 2005 from http://www.sysinternals.com/utilities/livekd.html
Rutkowska, Joanna, Rootkits Detection On Windows Systems, InvisibleThings.org, October 2004, accessed November 2005 from http://www.invisiblethings.org/papers/ITUnderground2004_Win_rtks_detection.ppt
JeremyK's [MSFT] WebLog. Don't Believe Everything The Debugger Is Telling You, Microsoft Developer Network, July 2004, accessed November 2005 from http://blogs.msdn.com/jeremyk/archive/2004/07/19/187696.aspx
Russinovich, Mark. Rootkit Revealer, SysInternals, October 2005, accessed November 2005 from http://www.sysinternals.com/utilities/rootkitrevealer.html
Strider, Microsoft, accessed November 2005 from http://research.microsoft.com/rootkit/
Roberts, Paul. RSA: Microsoft On ‘Rootkits': Be Afraid, Be Very Afraid, Computer World, February 2005, accessed November 2005 from http://www.computerworld.com/securitytopics/security/holes/story/0,10801,99843,00.html
Strider GhostBuster: Why It’s A Bad Idea For Stealth Software To Hide Files, Microsoft, July 2004, accessed November 2005 ftp://ftp.research.microsoft.com/pub/tr/TR-2004-71.doc
Murilo, Nelson, chkrootkit, chkrootkit.org, October 2005, accessed November 2005 from http://www.chkrootkit.org/
Joanna. KLister, Rootkit, accessed November 2005 from http://www.rootkit.com/project.php?id=14
Microsoft Windows Malicious Software Removal Tool, Microsoft, accessed November 2005 from http://support.microsoft.com/?kbid=890830
Joanna. PatchFinder2, Rootkit, accessed November 2005 from http://www.rootkit.com/project.php?id=15
Rutkowski, Jan K. Execution Path Analysis: Fnding Kernel Based Rootkits, Phrack Volume 0×0B, Issue 0×3b, Phile #0×0a of 0×12, July 2002, accessed November 2005 from http://www.phrack.org/phrack/59/p59-0×0a.txt
Boelen, Michael. Rootkit Hunter, Rootkit.nl - Protect Your Machine, May 2005, accessed November 2005 from http://www.rootkit.nl/projects/rootkit_hunter.html
Russinovich, Mark. RootkitRevealer, SysInternals, October 2005, accessed November 2005 from http://www.sysinternals.com/utilities/rootkitrevealer.html
Tripwire, Change Auditing Solutions, accessed November 2005 from http://www.tripwire.com
Fuzen_Op. VICE, Rootkit, accessed November 2005 from http://www.rootkit.com/project.php?id=20
Dillard, Kurt. How Can I Detect And Remove Rootkits From Windows?, SearchWindowsSecurity.com, May 2005, accessed November 2005 from http://searchwindowssecurity.techtarget.com/originalContent/0,289142,sid45_gci1086474,00.html
Wotring, Brian. Host Integrity Monitoring, SecurityFocus, March 2004, accessed November 2005 from http://www.securityfocus.com/infocus/1771