What Is a Rootkit? Malware That Hides From the OS

A rootkit is a category of malware built around one specific goal: gain privileged access to a system and then hide — its own files, processes, and network connections, and often other malware it’s protecting — from the operating system and the security tools that inspect it. The name comes from “root,” the highest privilege level on Unix-like systems, plus “kit,” reflecting that rootkits were originally distributed as toolkits of pre-built utilities for maintaining hidden access.

What makes a rootkit distinct from ordinary malware isn’t what it does once installed — that could be anything from credential theft to running a botnet node — it’s that it actively works to make itself invisible to the normal tools an administrator would use to notice something is wrong.

How rootkits hide

The specific hiding technique depends on where in the system the rootkit operates:

• User-mode rootkits run with the same privileges as a normal application and typically hook (intercept and modify) API calls that list processes, files, or registry entries, filtering their own artifacts out of the results before the caller sees them. Easier to write, but also easier to detect, since the tampering is visible to anything inspecting memory at a lower level than the hooked API.
• Kernel-mode rootkits run inside the operating system kernel itself, giving them far more control — they can hook system calls directly or use techniques like Direct Kernel Object Manipulation (DKOM) to unlink their own process or driver entries from the kernel’s internal bookkeeping structures, making them invisible even to tools that would catch a user-mode hook.
• Bootkits and firmware rootkits load before the operating system does, from the boot loader or the system firmware itself, which lets them survive an OS reinstall and interfere with the OS as it boots, before any security software has had a chance to start.
• Hypervisor rootkits run below the operating system entirely, in a thin virtualization layer the OS doesn’t know exists, watching and modifying everything above it — a technique demonstrated in research proofs of concept more than seen widely in the wild, given how difficult it is to build reliably.

What they’re used for

A rootkit is rarely the payload itself — it’s the concealment layer around a payload. Common pairings include hiding a buffer overflow exploit’s persistence mechanism, hiding a keylogger’s process and files, hiding a botnet client’s network traffic, or hiding the fact that an attacker who compromised a server is still logged in and moving around. The rootkit’s job ends where the actual malicious activity begins; it just makes sure nobody notices that activity is happening.

Detecting a rootkit

Rootkit detection is fundamentally an arms race, because a sufficiently privileged rootkit can, in principle, lie to any tool that asks the compromised system about its own state. That’s led to a few detection strategies that don’t rely on trusting the running system:

• Offline or out-of-band scanning — boot from trusted external media, or inspect a disk image from a separate, uncompromised machine, so the rootkit never gets a chance to intercept the scan.
• Behavioral and integrity monitoring — watch for discrepancies rather than known signatures: a process using more CPU or network than the process list shows, files reported by different tools that don’t match, unexpected kernel module load events. This is the same category of approach endpoint detection and response tools rely on generally.
• Secure and measured boot — verify each stage of the boot chain cryptographically before letting it run, which is specifically aimed at bootkits and firmware rootkits; see what UEFI is for how modern firmware implements this chain of trust.
• Cross-view diffing — compare what a high-level API reports (say, a process list from the OS) against a lower-level view of the same data (a raw memory scan), and treat any mismatch as suspicious.

Rootkits vs other persistence malware

	Rootkit	Ordinary backdoor/trojan
Primary goal	Hide presence from the OS and tools	Maintain access; hiding is secondary
Privilege level	Often kernel-mode or below	Usually user-mode
Detection difficulty	High — actively evades standard tools	Moderate — visible to normal scans
Survives OS reinstall	Sometimes, if firmware/bootkit-based	Rarely

Why prevention matters more than detection

Because a well-built rootkit is specifically designed to defeat detection from within the system it’s hiding on, the more reliable defense is preventing the initial privilege escalation that lets a rootkit install in the first place: patching promptly, minimizing what runs with elevated privileges, and treating any unexplained kernel-level behavior as worth investigating rather than dismissing. Threat modeling that specifically considers “what happens if an attacker gets root” — rather than assuming detection will catch it after the fact — is the more durable posture.

The takeaway

A rootkit isn’t defined by what malicious action it performs, but by its concealment: gaining privileged access and then hiding its own presence, and often other malware’s, from the operating system and the tools meant to inspect it. The deeper it operates — user-mode, kernel-mode, firmware — the harder it is to detect from inside the compromised system itself, which is why the most reliable detection methods work from an external, trusted vantage point rather than asking the system to report on itself.