A rootkit is a collection of software that allows an unauthorized user to gain root access to a system without being detected. Rootkits hide their own presence and often go unnoticed by users and system administrators. Many times, rootkits can hide themselves from antivirus and antimalware software as well. Some rootkits overwrite commonly used commands such as ps, ls, find, netstat, and others, so that they can hide their own presence. These are user level or user space rootkits and are easier to detect and remove. Other rootkits, however, operate at the kernel level or in kernel space. For example, some rootkits are loadable kernel modules. Others inject a rootkit using /dev/kmem/, which is a special device that points to an image of the running kernel's memory. Another method of installing a kernel level rootkit is by using /dev/mem/, which points to an image of physical memory that includes the entire physical memory image, and not just the kernel memory. When rootkits are operating at the same security level as the core OS, they can subvert or intercept operating system operations. These types of rootkits are harder to detect and remove. In the case of user space rootkits, you could potentially detect their presence by looking at signatures with antivirus software or file integrity checkers such as AIDE and Tripwire. You may also be able to spot them due to inconsistent behavior on a system. For example, if the CPU utilization is high, but you can't trace that load back to any running processes displayed on your system, then you can infer that a hidden process is creating that workload. You can also look at network load and network traffic. You could potentially sniff the packets coming into and out of the suspected system and potentially detect undesired data transfers and connections that are being hidden on the system using a rootkit. Since a kernel mode rootkit has to be loaded and running in order to hide itself, you can shut down the suspected system and then analyze its storage by booting from another device such as a DVD-ROM or USB drive, and then performing a scan. chkrootkit is a shell script that is used to detect the presence of rootkits. It's available for download at chkrootkit.org. It looks for the modification of system binaries, checks to see if network interfaces are in promiscuous mode, looks for log deletions such as missing entries in the lastlog and utmp files, and checks for signs of loadable kernel module trojans. You can run Check Rootkit manually or you can schedule it to run via Cron and even email its output to you. Another shell script that attempts to detect rootkits is RK Hunter. It's available at rkhunter.sourceforge.net. When you first install RK Hunter, you'll want to run it with a "--update" option. This updates the rules that RK Hunter uses to check for suspicious behaviors and rootkits. Next, you can set your baseline file properties by running "RK Hunter --propupd." RK Hunter checks the properties of various commands against a previously known state. Running "--propupd" causes the file property database to be updated with the current state. When you run this command, you are telling RK Hunter to trust the current state of your machine. Now you can use RK Hunter to perform a check by running "rkhunter -c" RK Hunter will alert you to any possible issues and ask you to hit enter to continue after each section of checks is performed. If you miss the output, you can consult the log file located at /var/log/rkhunter.log. If you want RK Hunter to only report warnings and not prompt you to hit enter, then run "rkhunter -c --rwo." RWO stands for "Report warnings only." Like chkrootkit, you can schedule this to run via Cron and send you the output. RK Hunter even includes an option specifically for this use case. If you're using it as a Cron job, use the "--cronjob" option to RK Hunter. The configuration file for RK Hunter is typically located at /etc/rkhunter.conf. You can include your email address in the RK Hunter's config file, and it will email you when any warnings are detected. You can use the MAIL-ON-WARNING variable to set your email address if you're planning to run it via Cron, for example. If RK Hunter reports warnings on some hidden files or directories that you know to be normal on your system, then you can update rkhunter.conf and include them. For directories, use ALLOWHIDDENDIR, and for files, use ALLOWHIDDENFILE. You may come across other issues that you want to create exceptions for. Just know that all those exceptions can be placed in the rkhunter.conf file. OSSEC is an open source host intrusion detection system. It performs log analysis and file integrity checking in addition to rootkit detection. The Syscheck module of OSSEC is responsible for detecting user space rootkits through hash comparison of binary files. The rootcheck module of OSSEC is used to detect both user mode and kernel mode rootkits. The rootcheck module looks for file names known to be associated with user mode rootkits. OSSEC also searches files for signatures known to be used by rootkits. Another method used to detect rootkits is by querying the operating system for information from many sources and comparing the results. If the results are inconsistent, that may indicate that a rootkit is installed. For example, rootcheck uses the netstat command to get a list of open ports on the system. Then it proceeds to use the bind system call to attempt to open every TCP and UDP port on the system. If rootcheck is unable to bind to a given port, that means that port is in use. If netstat doesn't list that port as being open or in use, then that's a good sign that a rootkit is altering the output of the netstat command. Rootcheck performs several other checks, including looking for hidden processes, hidden files, network interfaces in promiscuous mode, non-device files that exist in the /dev/ directory, unusual file permissions, among other things. Okay, let's say that you've found a rootkit using RK Hunter, Check Rootkit, or OSSEC. What do you do now? Well, before doing anything, I would attempt to keep or make a copy of the data if at all possible. If the system is on a physical hard drive, replace the hard drive and keep the original. If you can't do that, make an image of the OS using a tool like DD, for example. The reason you want to keep a copy of the OS is so that you can use it to determine how the attacker broke in and installed the rootkit in the first place, this way you can prevent it from happening to other systems or this system when it's placed back into service. You can attempt to manually remove the rootkit by reinstalling the core OS components from trusted sources. For example, you might be able to replace a trojaned version of the ps command with a good ps command and possibly see the rootkit process running. From there, you could work backwards by finding out how it gets started, where it's installed, et cetera. I don't recommend this procedure, though. If you miss a component to the rootkit, then your system could still be compromised. Even in cases where you are able to detect a rootkit, it's probably just best to re-install the operating system using trusted media. Likewise, you could restore the system from a known good backup, but if you're not sure the rootkit is still present in the backup, it's simply safer to just re-install. The only way to prevent rootkits is to use good security practices like we've been talking about throughout this course. Maintain physical security, account security, and network security. Use file integrity monitoring systems such as AIDE, Tripwire or OSSEC. Also keep your system up to date and patched with the latest security fixes for your operating system, as well as any of the software installed on your system.