A rootkit is a type of malware designed to conceal its own presence and the presence of other malicious components, usually by modifying the operating system, its kernel, the boot process or device firmware. In cybersecurity, a rootkit is defined by stealth and persistence rather than by a specific payload: its job is to keep an attacker’s access hidden and durable.
The name comes from early UNIX attack toolkits that preserved root-level access after a compromise. Modern rootkits exist for Windows, Linux, macOS, hypervisors and firmware, and they typically accompany other malware such as backdoors, credential stealers or botnet clients, which they shield from detection.
How a rootkit hides from the system
Security tools learn about a system by asking the operating system: which processes run, which files exist, which network connections are open. A rootkit works by intercepting and falsifying those answers, so tools receive a filtered view in which the malicious objects do not appear.
Common techniques include hooking system calls or API functions, altering kernel data structures directly, a method known as direct kernel object manipulation, and replacing system binaries with trojanized versions. On Linux, a malicious loadable kernel module can hide itself from the module list and filter directory listings returned by the kernel.
The deeper a rootkit operates, the fewer components remain trustworthy for detecting it. A rootkit in the kernel can deceive every user-mode tool, and one in firmware can survive a complete reinstallation of the operating system.
Types of rootkits by privilege level
Rootkits are classified mainly by where they execute, because the execution level determines both their power and the effort needed to remove them. The table lists the main types.
| Type | Where it runs | Typical technique | Removal difficulty |
|---|---|---|---|
| User-mode rootkit | Application processes | API hooking, library injection, replaced binaries | Moderate |
| Kernel-mode rootkit | Operating system kernel | Malicious drivers or kernel modules | High |
| Bootkit | Boot loader or boot sector | Loads before the operating system | High |
| Firmware rootkit | UEFI, BIOS or device firmware | Implant in flash memory | Very high |
| Hypervisor rootkit | Below the operating system | Runs the OS as a guest | Very high |
In practice, kernel-mode rootkits and bootkits are the most common serious threats, while firmware and hypervisor rootkits are rarer and typically associated with well-resourced attackers. User-mode rootkits are easier to build but also easier to detect from a higher privilege level.
Rootkits compared with other malware
A rootkit is best understood as a concealment layer rather than a complete attack. The comparison below places it among the neighboring Terms of malware and attacks.
| Category | Primary purpose | Visibility to the victim |
|---|---|---|
| Rootkit | Hide and maintain access | Deliberately invisible |
| Trojan | Gain entry by disguise | Appears legitimate |
| Ransomware | Encrypt data for extortion | Openly announces itself |
| Botnet client | Join a remotely controlled network | Usually hidden, often by a rootkit |
| Backdoor | Provide remote access | Hidden, frequently protected by a rootkit |
These categories often combine in one intrusion. An attacker may gain entry through phishing or credential stuffing, deliver a trojan, then install a rootkit that protects a backdoor for months before any visible damage such as ransomware occurs.
Detecting and preventing rootkits
Because a running rootkit controls what the system reports, detection relies on comparing views from different levels or on checking integrity before the rootkit can act. The table summarizes the main approaches.
| Method | Principle | Strength |
|---|---|---|
| Secure Boot | Only signed boot components load | Blocks many bootkits |
| Measured boot with TPM | Records boot component hashes | Enables remote attestation |
| Driver and module signing | Kernel loads only signed code | Raises the bar for kernel rootkits |
| Cross-view analysis | Compares high-level and low-level results | Reveals hidden processes and files |
| Offline scanning | Inspects disk from trusted media | Rootkit is not running |
| Memory forensics | Analyzes a captured memory image | Finds hidden kernel structures |
On Linux, tools such as chkrootkit and rkhunter look for known signatures and suspicious changes, while file integrity monitoring compares system files with trusted hashes. Enabling kernel lockdown and module signature enforcement prevents unsigned modules from loading, which removes the easiest path for kernel rootkits.
Response and common mistakes
Once a rootkit is confirmed, the affected system can no longer be trusted to report its own state. The following points reflect established incident response practice.
- Rebuild rather than clean; removing visible components often leaves hidden ones behind.
- Reflash firmware from a trusted source when a bootkit or firmware rootkit is suspected.
- Rotate all credentials used on the system, because rootkits frequently accompany credential theft.
- Do not rely on tools running inside the compromised system; use offline media or memory images.
- Investigate the entry point, since reinstalling without fixing the original weakness invites reinfection.
A frequent mistake is treating a clean antivirus scan as proof of health. A capable rootkit is designed to produce exactly that clean result, so trustworthy evidence must come from outside the running system.
Put simply
Most harmful programs want to steal or damage something. A rootkit has a different job: it is the invisibility cloak for an intruder. It sneaks into the deepest parts of a computer and changes what the computer reports about itself.
When you ask the computer which programs are running, the rootkit quietly removes the intruder from the list. That is why rootkits are hard to find. Experts usually check the computer from the outside, or simply rebuild it, rather than trusting what it says.
In practice
A web hosting company notices that one Linux server sends unexplained outbound traffic at night, yet ps, netstat and ls on the server show nothing unusual. The administrators suspect that the tools themselves are being deceived.
They capture a memory image and boot the server from trusted rescue media. Comparing the offline file system with package checksums reveals a malicious kernel module and a modified SSH binary, and memory analysis shows a hidden process relaying traffic for a botnet.
The team rebuilds the server from a clean image, enables module signature enforcement, rotates all keys and passwords, and patches the outdated web application that allowed the initial entry. Monitoring confirms that the nightly traffic does not return.