Important Notice: This document is meant for academic and defensive uses only. Knowledge about how rootkits function is useful in detecting and removing them. However, this knowledge should not be used to attack any system without proper permission.
Now, think about sitting at your computer. You open Task Manager. All seems fine. No unusual processes. You perform an analysis of your machine using your antivirus software. It shows you this result: “No threats detected.”
You heave a sigh of relief.
However, I will shock you by telling you that someone has been monitoring you for months now. All of your activity on your machine was being monitored. Each keystroke, password, and file accessed. All those measures that you have taken to detect it? They have already been tampered with. They are deceiving you.
This is how a rootkit, a type of malware, has been created not only to infect your computer but also to make sure that you don’t detect it works.
Rootkits are not something new. These malware programs were first seen back in the early 1990s. However, from those primitive Unix utilities, they have become much more complicated. Now, they can even reside in your computer’s firmware.
In this guide, we will try to lift up the curtain. We will explore what rootkits are, how rootkits function, what kinds of rootkits there are, and most of all what can be done about them. If you are an administrator, a security fanatic, or anyone curious to learn about these lurking threats below the surface, this is for you.
The Origin Story: Where “Rootkit” Comes From
To begin with, the term itself already contains some valuable information about the functions of this malicious software.
The root means the superuser, the person with unlimited access rights to everything in Unix and Linux operating systems. It is similar to the administrator account in Microsoft Windows. If you are a root, then you can do whatever you want.
The kit in the term “rootkit” indicates that we are talking about a number of tools. In the 1990s, when an intruder compromised a Unix system, he would install a “rootkit” on the system, a number of system utilities patched in such a way that they did not reveal the intruder’s presence. Imagine that somebody breaks into your apartment and installs a rootkit; here it means that your surveillance cameras will record the same images all the time and you will see an empty room while the intruder will be present in the room.
In fact, the first rootkits were quite simple. The commands ps (to display a list of running programs), ls (to list files in a directory), and netstat (to display network connections) were patched in such a way that they simply omitted all the traces of the intruder’s activity.
How Rootkits Actually Work: The Art of Lying
Here’s the basic principle: A rootkit is an outright lie manifested in code. Your OS offers you data about its state via API functions programmed commands that allow you to ask the operating system things like “Which processes are currently running?” or “Which files does this folder contain?” A rootkit manipulates these requests by intercepting and altering their results. Now let’s see a simple example.
When you launch Task Manager in Windows, it cannot somehow know what processes are currently running. Task Manager queries the operating system using a special API, which then calls kernel functions responsible for requesting the list of active processes. The rootkit can interfere with this process, act as a deceptive translator, and simply eliminate certain items from the list before passing the results back to Task Manager. The process is running. The processor is working. But Task Manager sees nothing.
This technology is called hooking; the rootkit hooks into the API function, modifies its result, and passes it further. From the standpoint of all other programs running on your computer, there is no such malicious process at all.
User Mode vs. Kernel Mode: The Privilege Ladder
In order to fully comprehend the notion of rootkits, one must know about the two types of privilege levels in modern operating systems.
User mode (ring 3) is where normal applications such as browsers, word processors, and video games run. The programs that run here have only limited permissions and cannot interact with any hardware nor alter anything about the core of the operating system.
Kernel mode (ring 0) is where the core of the operating system is running. Code that is running here has full, unrestricted access to all system resources.
Rootkits can be implemented on both of these levels; however, rootkits that operate in kernel mode are significantly more dangerous since:
- Conceal process, file, network, and registry key
- Intercept system calls and give false data
- Subvert and disable security applications
- Prevent deletion itself
- Survive reboots, including reinstallations of the operating system (in extreme cases)
Detection and removal of the rootkit in user mode is possible if the security software has enough privileges to do so. The rootkit running in kernel mode is the OS itself then.
Taxonomy of the Rootkit: From Application Level to Firmware Level
Rootkit is not one entity; it is a group, which comprises other groups. We’ll cover all of them, from “annoying” to “frightening.”
Application-Level Rootkits
They work in user mode by hooking or patching application-level binary code. Classic UNIX rootkits of the 1990s were application-level rootkits.
Example: An intruder changes the /bin/ps to show a clean system for anyone who executes it. The modified PS does not display processes of the attacker.
Detection difficulty: Low to medium. Intact file checker is a way to spot modified binaries. Output comparison between different sources will also expose inconsistency.
Level of threat: Low. Such rootkits are mostly considered a historical phenomenon in present days but still may be used in particular situations.
Library-Level Rootkits
They do not involve swapping out an entire application but rather manipulating shared libraries—those pieces of code used by multiple programs.
In Linux, this can involve patching the system call filter in libc.so. In Windows, this can be done by intercepting system calls through ntdll.dll, the library that acts as an interface between user and kernel mode.
Detection difficulty: Moderate. It is more difficult to detect than swapping out binaries because one modification to the library will impact many processes at once.
Threat level: Moderate. More sophisticated than swapping out binaries.
Kernel-Mode Rootkits
This is where it gets serious. Kernel rootkits load as a driver or kernel module and run with the same privileges as the operating system itself.
Once loaded, a kernel rootkit can do the following:
- Intercept calls to the operating system via System Service Descriptor Table (SSDT)
- Hook its own functions to return false information when any of its own functions is called by other kernel functions
- Hide files by filtering their presence at the file system driver level
- Hide any network connections by hooking TCP/IP stack queries
- Defend itself against being deleted by blocking write access to its own files
The Rustock rootkit, which infected about a million PCs at its peak, did all of this. Specifically, it hooked the SSDT and intercepted calls to the functions ZwCreateEvent, ZwCreateKey, and ZwOpenKey related to registry and event management operations and returned failure codes for any call that referenced its own driver names. Any security utility asking “Is this file present?” got an answer: “No, it’s not.”
Detection difficulty: High. A kernel rootkit is capable of bypassing most conventional security applications because it has access to the data used by such security applications.
Threat level: Very severe. A kernel rootkit owns your system. Period.
Bootkits: MBR and VBR Rootkits
A bootkit attacks the code that executes before the operating system loads. In this way, it gains control right from the very first moment your computer boots up.
Master Boot Record (MBR) refers to the first sector of a hard drive. At the time of booting, BIOS/UEFI reads this sector and executes the code present on it. The code usually points out to the location of the operating system.
In the case of an MBR rootkit, this sector gets overwritten with the code of the rootkit. As a result, at the time of booting, the rootkit gets executed first. It can then load the original bootloader after taking control over the whole process of loading the operating system.
Mebroot rootkit (also called Sinowal) was one famous example of such malware. Mebroot used to overwrite the MBR, load its driver at an early stage of the boot process, and use this driver to hide itself and steal banking credentials. Variants released after early 2008 made use of very sophisticated installation techniques to evade anti-virus programs.
Detection difficulty: Very high. Rootkit is operational even before the antivirus starts running.
Threat level: Serious. MBR rootkits can survive a fresh installation of the OS if the MBR remains intact.
Firmware and UEFI Rootkits
This is the deepest end of the pool. Instead of legacy BIOS, modern PCs use UEFI (Unified Extensible Firmware Interface). UEFI is essentially a small operating system that runs before your operating system itself. It initializes your hardware, performs security checks, and finally hands off to your bootloader.
A UEFI rootkit infects the firmware, which is stored in a special chip on your motherboard and can survive:
- Reinstallation of the operating system
- Replacement of the hard drive
- Even wiping of the whole disk!
LoJax and CosmicStrand are just two examples of existing UEFI firmware rootkits that managed to remain unnoticed for years. There also exist proof-of-concept rootkits that can circumvent Intel Boot Guard and Secure Boot protections.
Detection difficulty: Extreme. Modern security tools cannot even detect the existence of UEFI firmware.
Threat level: Catastrophic. The only way to get rid of the infected firmware is to reflash it, and this might not even help if the rootkit manages to infect the recovery utility.
Hypervisor-Level Rootkits
A hypervisor is an application that creates and controls the virtual machines. A rootkit that infects the hypervisor will be able to take complete control of all virtual machines running on that host without being detected by the VMs themselves at all.
It is also known as the virtual machine based rootkit (VMBR). The rootkit takes the operating system in which it is running to become a virtual machine itself and then runs the original OS as the guest. The user is unaware that his “physical” computer is actually a virtual one.
Detection difficulty: Very hard. Detection of an unwanted hypervisor is a research-level task.
Threat level: Catastrophic, especially in cloud and data center environments.
The Hall of Infamy: Notable Rootkits
Understanding specific rootkits helps illustrate how these threats evolve. Here are some of the most significant.
Rustock (2006–2011)
The Rustock was a rootkit-based backdoor that was used mainly for distributing spam. It is estimated that at its peak it controlled about a million compromised machines and had the capacity to generate hundreds of millions of spams daily.
It made use of a rootkit feature in which kernel mode drivers are used to conceal the program’s files, registry keys, and network operations. The Microsoft Digital Crimes Unit took down the rootkit in March 2011.
Lesson: Rootkits can be used not only for espionage but for profit too.
Sinowal / Mebroot (2006–present)
Sinowal was a multi-component malware used to steal credentials related to finance. Sinowal was targeting passwords for FTP, HTTP, email, and online banking sessions.
The Sinowal rootkit was an MBR bootkit that got activated before the boot process was completed. This gave it an opportunity to activate itself even before the operating system became ready to defend itself. It continued to be a threat for several years.
Lesson: Rootkits are often a part of the entire malware scheme and not its end.
TDL-4 / Alureon
One of the most advanced rootkits of the period was TDL-4. This rootkit infected the MBR, had its own encrypted file system, and could disable any security software through the kernel mode. Also, the rootkit had a peer-to-peer command and control system, which made it immune to any shutdown attempts.
Lesson: Rootkits can be equipped with their own infrastructure.
Sony BMG Rootkit (2005)
It is considered the most notorious legitimate rootkit.
Sony BMG used rootkit technology for CDs to make copying impossible. By inserting into a computer running Windows OS, the CD would install a rootkit that could hide files and change the system’s operation. It also created a huge security hole for malicious users to take advantage of.
The purpose was copy protection. The outcome was a huge security problem on many computers.
Lesson: Rootkit technologies are inherently dangerous regardless of their purpose. Even “benign” rootkits can be abused.
CosmicStrand and LoJax (UEFI Rootkits)
They are the current edge. CosmicStrand, developed by a threat actor that speaks Chinese, and LoJax, which was developed by the Russian APT Fancy Bear, both infected the UEFI firmware and established persistence.
They survived disk wiping. They survived reinstallation of the operating system. They were practically undetectable to everything else running on the machine.
Lesson: The rootkit war is now taking place at the firmware level.
The Modern Threat Landscape: Rootkits in the Cloud Era
Rootkits have adapted to the computing environment. With the emergence of cloud infrastructure, containerization, and observability through eBPF technology, new vulnerabilities have been introduced.
eBPF: The Double-Edged Sword
Extended Berkeley Packet Filter (eBPF) is a technology that enables programs to execute directly in the Linux kernel without loading a kernel module. eBPF is commonly utilized for network, observability, and security purposes.
Security solutions such as Falco, Tetragon, and Tracee leverage eBPF capabilities to monitor the system activity through its kernel. The idea sounds simple and elegant: capture the events right where they happen and not let anything get in the way of their monitoring, including malicious programs in user space.
There was a novel method recently developed that consists in hooking bpf_ringbuf_submit, which is the mechanism eBPF uses to send telemetry to the monitoring tool located in user space. By filtering or dropping events right when they enter the bpf_ringbuf_submit, one can prevent them from reaching the tool. This way, the monitoring application will continue working and believing that it observes everything while receiving only carefully filtered data.
The researchers were able to demonstrate the approach using the Singularity rootkit, which was filtering events according to process ID (PID). As a response, the SPiCa project started obfuscating PIDs with random values before feeding them into the telemetry pipeline.
Implications for you: eBPF-enabled security systems are robust, but they can still fall victim to rootkits. You must think defense-in-depth now more than ever.
VoidLink: Cloud-Native Rootkit Behavior
An emerging proof-of-concept known as VoidLink proves how rootkits work within the Kubernetes space.
VoidLink does not create any file on the disk. The tool exists entirely in memory, using hooks into system calls via eBPF technology. The tool remains invisible to the ps command, the netstat command, and also container security tools.
Furthermore, VoidLink learns. Within 24–48 hours, the tool maps the security tools used in the environment, understands how detections occur, and changes its behavior in order to fly under the radar.
What it means to you: The old methods of detecting malware based on files simply do not work anymore. Behavioral analysis is now mandatory.
Detection: How to Find Something That Doesn’t Want to Be Found
This is where it gets tough. Rootkits are designed to elude detection, and kernel-level rootkits are particularly powerful.
But they are not invincible. Here’s how security experts handle detection.
The Core Principle: Trust Nothing on the Suspected System
If there’s a rootkit, it will control the information being reported by the OS. Task Manager will deceive you. PS will deceive you. The listing of files will deceive you. Even many security tools will deceive you if the rootkit is advanced enough.
The fix is to scan from outside the system. Boot the system into an outside environment (such as from a USB drive, via a network boot, or another computer altogether).
Microsoft Defender Offline
For the Windows operating system, there is an offline scanner provided by Microsoft.
This is how you can use it:
- Open Windows Security
- Go to Virus & Threat Protection
- Under Scan options, select Microsoft Defender Offline Scan
- Click Scan now
Your computer will automatically reboot into a minimal environment where the rootkit will not be able to load in order to conduct a comprehensive scan. This is the most user-friendly way to detect rootkits.
Memory Forensics
The running rootkit will have artifacts in memory, even though it tries to conceal itself in terms of its files. Forensic tools like Volatility may help to perform analysis on a memory dump to uncover any hiding process, hooking of system calls, and suspect kernel structures.
It’s a sophisticated technique, but it may be the only one able to find a highly complex kernel rootkit.
Cross-Reference Validation
If you cannot rely on one source, then collect information from several different sources and compare.
- Monitor network traffic at the router or firewall level rather than the host
- Use outside monitoring to identify connections that the host denies
- Compare process list information from different tools using different API paths
This technique was formalized in the SPiCa research project using a “sidecar” observer, which collected telemetry via a separate path not subject to tampering by the rootkit.
Behavioral Indicators
Though rootkits strive to be invisible, there are still actions performed by them. Be aware of:
- Slower performance without an obvious reason (resource usage takes place despite invisibility)
- Crashes or inability of security programs to work (kernel-level rootkits usually disable any alternative security products)
- Update failures for antivirus software (rootkit may prevent the program from accessing update servers)
- Connections to external unidentifiable locations (check your network logs externally rather than locally)
Specialized Anti-Rootkit Tools
Here are several applications developed for the purpose of rootkit detection:
- Kaspersky TDSSKiller: Dedicated to rootkit detection and removal, especially targeted at bootkits.
- UnHackMe: Initially created as an anti-rootkit application, now capable of detecting other types of malware.
- RegRun Reanimator: Dedicated to the detection of rootkits, trojans, and spyware with additional registry protection capabilities.
While these tools have some flaws, they may be considered a useful component of the defense-in-depth approach.
Removal: When Detection Isn’t Enough
And here is the bitter pill to swallow: rootkit elimination from a running computer isn’t reliable.
If the rootkit operates in kernel mode, it can prevent removal. If it is in firmware, it will withstand OS reinstallation. And if it is redundant or backed up, it can recover from removal attempts.
The most reliable method is atomic: wipe out the OS and start over.
However, this may not be sufficient in case of firmware rootkit infection. It may be necessary to:
- Reinstall the UEFI firmware from the original installation disc
- Remove the MBR and all partitions on the disk
- Reinstall the OS from trusted sources
- Set new passwords after clean installation (the rootkit might have copied your credentials)
In corporate environments, the general recommendation is to isolate the machine and start anew.
The Backup Problem
However, before wiping out a system, there must be a backup of your files. But how can you be sure that your backup has not been compromised by the rootkit?
This is a real dilemma. The best thing to do:
- Backup just data files (Word documents, photos, etc.) and not executables or system files
- Scan your backup using an offline scanner
- Accept that you might have to lose some files if they cannot be scanned cleanly
It’s tough but preferable to restore an infection.
Advanced Corner: The Future of Rootkits
Where is this arms race heading?
Firmware Rootkits Will Become More Common
Firmware is where it all ends for persistence. It will be incredibly hard once the code is placed in the UEFI and/or Option ROM of a device. Nation-states have done it before. As defense mechanisms become better at the operating system level, attackers are bound to move further down.
Rootkits Will Learn and Adapt
The VoidLink proof of concept demonstrated that a rootkit could evaluate its environment and adapt its actions in order to remain undetected. This will become standard. It is much more dangerous for a rootkit to monitor your security practices and then adjust accordingly.
eBPF Will Be Both a Defense and an Attack Surface
eBPF grants defenders an unparalleled view of kernel activity. However, as illustrated above, rootkits can attack the eBPF telemetry flow. The same technique that allows for the detection of issues can also be abused.
Hardware-Based Attestation May Help
The TPM (Trusted Platform Module) chips and Secure Boot are intended to ensure the integrity of the system, such that if there were any changes made to the firmware or bootloader, then the Secure Boot should not launch.
However, proof-of-concept rootkits have evaded such protections. Hardware attestation shows promise, but it is not a panacea.
Practical Takeaways: What You Should Do
Let’s bring this down to earth. What can you actually do about rootkits?
For Individual Users
- Ensure Secure Boot is enabled in your UEFI. It is not foolproof but definitely takes it up a notch.
- Keep your firmware updated as motherboard vendors issue patches for vulnerabilities in their firmwares.
- Make use of Microsoft Defender Offline when you are using Windows.
- Exercise paranoia over downloading, as rootkits are not self-installing. Rather, they come in malicious files or from phishing attacks.
- In case you think there might be a rootkit on your computer, ensure your important files are backed up and you start fresh.
For System Administrators
- Take compromise into account. Plan accordingly.
- Plan for defense-in-depth. Nothing will protect against all types of attack.
- Monitor externally. Relying on host-based logging alone is insufficient. Use network monitoring, traffic analysis, and external verification.
- Ensure a rebuild plan. In case of suspected rootkits, the response is typically “reinstall.”
- Be aware of firmware. Maintain a list of your UEFI versions and keep them up to date.
For Security Professionals
- Learn about memory forensics. It is one of the only methods to reliably detect kernel rootkits.
- Keep up with the developments in eBPF. That’s where the interesting stuff is happening.
- Learn about telemetry. Understand how your security tools gather information and where the process can be attacked.
- Engage with the community. Volatility, Falco, and Tetragon are all open-source projects. Contributing to them will help improve them.
The Bottom Line
The rootkits are the worst forms of malware since they exploit the very principle of trust in computing. It’s not that rootkits infect your computer; it’s that rootkits make your computer lie to you. Any software that you could normally run in order to look for the problem will turn into the software that can help the malware to hide and feed you false data. That’s what distinguishes rootkits from other kinds of malware. The virus shows itself with its symptoms. Rootkits are so stealthy that you could never guess that something bad happens.
However, there is no witchcraft in them. There is only the code that functions according to the principles of the computer operation. All hooks, all interceptions of system calls, and all hidden processes can be described and analyzed. To understand the limitations that rootkits have is the key to defending yourself against them. And the more you know about how the malware exploits the trust chain that goes from the hardware, through the firmware and the kernel, up to the application level, the more likely you’ll be to detect the anomalies created by rootkits.
The key lesson that needs to be taken away here is that when you think there may be a rootkit infection, do not attempt to get rid of it. When a rootkit has gotten into the kernel or firmware space, there will always be some uncertainty about whether or not the rootkit infection has been fully eliminated. Rebuilding from scratch is your only choice.
Always stay curious, skeptical, and verifying.
Explore Our Cybersecurity Category. And if you are reading it up to here, leave a sweet comment to motivate us to write blog everyday.
