Kernel rootkits & detection

When you cannot trust the kernel.

The deepest hiding place is the kernel itself. A kernel rootkit — usually a malicious loadable kernel module — runs with full kernel privileges and can intercept the system calls that every tool ultimately relies on, so it hides files, processes, network connections, and even itself from everything running in userspace. Where LD_PRELOAD fools dynamically-linked programs, a kernel rootkit fools the kernel’s answers to everyone, which is why it is the hardest to detect from the running system and the reason the hardening course was so insistent about controlling module loading.

# indicators a kernel rootkit may be present (all fallible if the kernel is subverted):
$ lsmod                              # an unfamiliar module — but a good rootkit hides itself here too
$ cat /proc/modules                  # cross-check against lsmod for discrepancies
$ dmesg | grep -i taint              # a tainted kernel can indicate an out-of-tree/unsigned module
$ cat /proc/sys/kernel/tainted       # non-zero after loading unsigned modules

Detecting what hides from you

You cannot reliably ask a compromised kernel whether it is compromised, so detection leans on discrepancies and outside views. Compare what the host reports against ground truth gathered elsewhere: a process the host does not show but that is making network connections your firewall or a network sensor sees; files present when you mount the disk from a trusted rescue system but absent to the live host; memory forensics (analyzing a RAM capture offline) that reveals hidden modules and hooks. Tools like chkrootkit and rkhunter check known signatures, but the durable method is comparing the suspect system to an independent source of truth.

Prevention is far easier than detection

Because a kernel rootkit is so hard to find once installed, the leverage is in prevention — which is exactly the module-control hardening from the previous course. Requiring signed modules (kernel lockdown / module signature enforcement) means the kernel refuses to load an unsigned rootkit; disabling module loading after boot (kernel.modules_disabled=1) means nothing new loads at all; and auditing init_module/finit_module records any load attempt. A host where an attacker with root still cannot load a kernel module is a host where the deepest hiding place is closed.