Rootkit

Every security tool asks the operating system questions: list the processes, list the files, list the connections. A rootkit interferes with the answering. In user space it hooks the library functions an application calls, so a specific process is filtered out of the list before the application ever sees it. In kernel space it hooks system call handlers, manipulates kernel objects directly so that a process is unlinked from the list the system enumerates while continuing to be scheduled, or loads a driver that filters at a lower layer.

Two distinctions are worth getting right because they are commonly muddled. A rootkit hides more than itself: the point is concealing the operator’s processes, files, network connections and accounts. And a rootkit runs within the operating system. Code that runs below it, in the boot chain or in firmware, is a bootkit, which is a different mechanism with a different defence.

The defensive assumption that breaks is that a tool running on the host can be trusted to describe the host. Once the kernel is subverted, the answers are the attacker’s answers, and an endpoint agent querying that kernel is being lied to by the thing it depends on.

Modern platforms have made the kernel case considerably harder rather than impossible: driver signing, kernel patch protection, virtualisation-based integrity and Secure Boot all raise the cost, so a common route is now abusing a legitimately signed but vulnerable driver to obtain kernel access rather than loading a hostile one. User-space rootkits remain entirely practical and need no kernel access at all, which is why the claim that detection always requires offline forensics is wrong: it is true for kernel-level implants, and not for the rest.

Detection therefore comes from outside the deception. Comparing what the host reports with what the network and the hypervisor observed, examining a memory image acquired externally, and booting from separate media are the approaches that work, alongside EDR telemetry captured before the subversion took effect.

We do not install one on a client engagement. Where it matters is forensics and eradication advice: if there is any reason to suspect kernel-level subversion, the affected system is rebuilt rather than cleaned, and evidence is collected in a way that does not rely on the system’s own answers. In a red team exercise the equivalent question is simpler and more useful, namely whether the client can see what a process actually did when the process is telling the truth.