Detecting Kernel Rootkits

To get a list of kernel modules, two standard methods can be used:

    bash$ lsmod
    bash$ cat /proc/modules
    

In addition, one can look at the list of symbols exported by modules (/proc/ksyms), where the name of the corresponding module will be listed in square brackets, like the following symbol exported from the snd (sound) module:

    c85029f4 snd_task_name  [snd]
    

Unfortunately, being a kernel module, an LKM rootkit can easily defeat such efforts by a variety of methods. Fortunately, there is a better way to detect an LKM rootkit:

In order to replace kernel syscalls with their own code, LKM rootkits modify the table which holds the addresses of these syscalls, to point to the module's replacement function instead of the original kernel function. Now, whenever a kernel is compiled, a map of kernel symbols and their respective addresses in the kernel is generated. This map is called System.map (sometimes with the kernel version appended), and usually install in the same location as the kernel (e.g. /boot). Thus, a straightforward way to detect hijacked kernel syscalls is to compare this map against the actual addresses of all syscalls, which will show all syscalls whose address is different from the original address listed in the map.

Programs

This is a non-exhaustive list of programs that are useful for the detection of kernel modifications in a running system.

kern_check.c

kern_check.c (PGP signature: kern_check.c.asc) is a small command-line utility (for Linux 2.2.x, 2.4.x) that will compare your System.map against your kernels syscall table and warn about any inconsistencies.

    bash$ gpg --verify kern_check.c.asc kern_check.c
    bash$ gcc -O2 -Wall -o kern_check kern_check.c
    bash$ su
    bash$ kern_check /path/to/System.map
    

NoteNews
 

Jul 15, 2004: updated for kernel 2.6.

Feb 5, 2003: updated version will detect not only rootkits that modify the syscall table directly, but also rootkits that install a 'private' syscall table in the way the SucKIT rootkit does (see the Section called Suitable places in the flow of execution>), as well as the adore-ng rootkit that employs an atypical method to subvert the kernel (see the Section called Atypical methods to subvert the kernel>).

CheckIDT

CheckIDT, published in Phrack issue 59, article 0x04 ("Handling the Interrupt Descriptor Table", by kad) is a utility that can be used to list the Interrupt Descriptor Table (IDT) (see the Section called Suitable places in the flow of execution>) and save the current state to check its integrity later on. Currently there is no published real rootkit that uses the IDT, only proof-of-concept code.

check-ps

check-ps is a utility that can detect hidden processes pretty relieably (including e.g. processes hidden by the new adore-ng rootkit), if the --killscan option is used. While this is useful to detect rootkit activity, of course it will only work if there are indeed processes that are hidden by the rootkit. It will not detect a rootkit that is just 'sitting around', waiting for someone who uses a backdoor provided by the rootkit.

Kstat

Kstat by FuSyS, available from s0ftpr0ject is a tool to analyze the kernel through /dev/kmem. It can detect modified syscalls as well as various other problems.

samhain

samhain is a file integrity checker that can also check for kernel integrity. samhain performs checks for all of the points discussed in the Section called Suitable places in the flow of execution>.