UGN Security Forums UGN Security: Underground General Regaining access to a system

Understanding Rootkits
by Oktay Altunergil, 12/14/2001

A rootkit is a collection of tools an intruder brings along to a victim computer after gaining initial access. A rootkit generally contains network sniffers, log-cleaning scripts, and trojaned replacements of core system utilities such as ps, netstat, ifconfig, and killall. Although the intruders still need to break into a victim system before they can install their rootkits, the ease-of-use and the amount of destruction they cause make rootkits a big threat for system administrators.


The main purpose of a rootkit is to allow intruders to come back to the compromised system later and access it without being detected. A rootkit makes this very easy by installing a backdoor remote-access daemon, such as a modified version of telnetd or sshd. These will often run on a different port than the one that these daemons listen on by default.

Most rootkits also come with modified system binaries that replace the existing ones on the target system. At a minimum, core binaries such as ps, w, who, netstat, ls, find, and other binaries that can be used in monitoring server activity, are replaced so intruders and the processes they run are invisible to an unsuspecting system administrator.

Because most rootkits will mimic the creation dates and file sizes of the original system binaries while replacing them with infected versions, keeping records of these file statistics is not sufficient. Thus, the best way to make an inventory of system file information that can be used to identify suspicious activities on the server is to calculate the cryptographic checksums of these files and store this information in a safe location, such as on a CD.

Third-party tools such as Tripwire or AIDE make this process much easier and more robust by automating the calculation of these file signatures.

Here's a quick explanation of Tripwire from the organization's web site:

"Tripwire is a tool that checks to see what has changed on your system. The program monitors key attributes of files that should not change, including binary signature, size, expected change of size, etc."

Obviously this process has to be repeated as you introduce more software and other files into your system. You can also use the RPM signatures on RPM-based systems such as Red Hat and SuSE to compare the current MD5 signatures of your files to those in the RPM installation database. Unfortunately, the RPM application itself and the local RPM database cannot be trusted to provide accurate information because intruders can potentially infect them too.

Some rootkits may also contain sniffer or keylogger applications that are used to gather passwords for other systems and listen to traffic for sensitive information. To do this, the rootkits set the PROMISCIOUS mode on the target machine's network interface card (NIC). In normal operation, a network interface card only listens to traffic that is specifically addressed to itself and traffic that is coming through the broadcast address that everyone listens to.

On a "non-promiscuous" network adapter, the packets that are addressed to other network interfaces are silently discarded without even looking at the actual data in them. However, when using directly connected computers or a network that uses basic, non-switching HUBs, your interface actually can listen to all traffic if it's in PROMISCIOUS mode.

If an intruder listens to this traffic on a relatively large network, the results may be catastrophic. To protect the whole network even when one of the machines is broken into, using direct cable connections and basic HUBs should be avoided. Switching-hubs and other more advanced networking equipment do not broadcast traffic to all the machines on the network, but only send it to the machine that is supposed to receive it, effectively protecting all the other machines on the network.

Because the first thing a system administrator does to monitor unusual activity is to check the system log files, it is very common for a rootkit to include a utility to modify the system logs. In some extreme cases, rootkits disable logging all together and discard all existing logs. Usually if the intruders intend to use the server for an extended period of time as a launch base for future intrusion activity, they will only remove those portions of logs that can reveal their presence. Because the absence of log files or stopped logging activity is a sign of suspicious activity itself, only attackers who have adopted the hit-and-run style will choose to blindly discard all logs.

One method administrators can use to maintain logs about an intrusion attempt -- successful or otherwise -- is to devise a system that detects network anomalies and alerts the system administrators by sending them notification email messages and/or log files. Obviously, the network intrusion detection and periodic log-file transfer methods cannot be trusted after the intruder gains access to the machine.


Arguably the most severe threat to system security that can be caused by a rootkit comes from those that deploy LKM (Loadable Kernel Module) trojans. Loadable Kernel Modules are a mechanism for adding functionality to an operating-system kernel on the fly -- without requiring a kernel recompilation. Although the benefits of using LKMs are universally recognized, they are also subject to abuse by intruders who use the kernel module-loading mechanism for malicious purposes. Even if you reboot a system that is infected by an LKM Trojan, the LKM process will reload it during boot-up just like any other kernel module. Loadable Kernel Modules are used by many operating systems including Linux, Solaris, and FreeBSD