What is RootkitRevealer: How it Works, How to Use it, and Signs of Rootkits

Informatec Digital » Security » What is RootkitRevealer: How it Works, How to Use it, and Signs of Rootkits

RootkitRevealer is one of those legendary utilities that every Windows professional should know; it was created by the Sysinternals team with Mark Russinovich at the helm and, although it emerged years ago, it remains a reference for understanding how to detect the discrepancies caused by rootkits between what the system shows and what is actually on the disk.

Unlike other scanners, it doesn't look for signatures or patterns: it compares a high-level view of the Windows API with a raw, low-level read of the disk and Registry. This seemingly simple idea reveals when malware tries to hide files, keys, or values ​​by manipulating system calls.

What is RootkitRevealer and what systems does it work on?

This is an advanced tool for detecting signs of rootkits in both user and kernel modes . It was originally developed for Windows XP and Windows Server 2003 (32-bit) and is commonly listed as free, in English, and approximately 231 KiB in size; many listings also indicated its compatibility with Windows NT/2000/XP/Vista at the time.

Over time, its purely command-line version was eliminated because some malware authors started monitoring the executable's name; to avoid this, the program is launched as a service from a randomly named copy of itself, making detection by name more difficult and complicating the provision of a 100% console interface.

What is a rootkit? Key concepts

The term rootkit refers to techniques and mechanisms that allow malware (viruses, Trojans, spyware, etc.) to hide from the user and security tools . Several families are distinguished: persistent (surviving reboots), memory-resident (disappearing upon reboot), user-mode, and kernel-mode, among other modern variants.

A user-mode rootkit can intercept functions like FindFirstFile/FindNextFile, or the system's native enumerators, to filter entries that would reveal its modified files, processes, or Registry keys . This prevents Explorer, the command prompt, or Registry editors from seeing what actually exists.

Kernel-mode rootkits go further: in addition to intercepting the native API, they can directly manipulate kernel structures, for example by removing their process from the list of active processes so that it does not appear in Task Manager or Process Explorer even though it is running.

There are hybrids (part user-based and part kernel-based), firmware (BIOS/UEFI and other components), boot or bootkit (MBR/UEFI), virtual (which place the actual OS inside a virtual machine), and memory-based (non-persistent) bootloaders. The latter can be particularly elusive, while firmware and bootloaders persist even after a clean operating system reinstallation.

How RootkitRevealer works

RKR contrasts two snapshots: the high-level view of the Windows API and the raw, low-level reading of the volume and Registry subtree files (hives). If a rootkit tampers with high-level calls to hide something, this alteration is revealed because what's on disk and in the Registry doesn't match what the API says is there, generating diagnosable discrepancies.

Theoretically, a rootkit could also attempt to hide from RootkitRevealer by intercepting its raw reads and rewriting the data on the fly. To achieve this, it would need intimate knowledge of NTFS, FAT, and Registry formats, and be able to modify structures without causing inconsistencies or obvious side effects—a highly complex technical feat that has rarely been observed. Even so, there is no infallible "universal detector": even booting from an external environment (for example, using the best Linux distributions ) could be sabotaged by particularly sophisticated and persistent artifacts . In practice, the most robust approach is to combine online analysis with offline verification in trusted environments.

Requirements, good practices and execution

To run this scan, the account needs the "Back up files and directories," "Load drivers," and "Volume maintenance" privileges (these are granted by default to administrators in Windows XP and later). To minimize false positives, it is recommended to run the scan with the system at rest and no applications open.

In manual execution, simply press the scan button. During the process, the program will provide progress updates and list any discrepancies. There are two relevant options: “Hide NTFS metadata files” (enabled by default, to avoid displaying standard metadata hidden by NTFS) and “Scan log” (enabled by default; deselecting it will skip scanning the Windows Registry ).

For automation, it supports parameters that allow you to start, log in, and exit without intervention: rootkitrevealer outputfile]. The option -a starts and ends automatically; -c output the result in CSV; -m displays NTFS metadata; and -r disables registry scanning. The output file must be in a accessible local volume.

Remote execution is possible with PsExec. For example: psexec \\remote -c rootkitrevealer.exe -a c:\windows\system32\rootkit.log. With -c, progress is not displayed and discrepancies are printed in CSV, making it easier to import in databases or scripts.

Interpretation of results and typical discrepancies

"Hidden from Windows API" discrepancies are the most common when a rootkit is hiding entries. If you haven't enabled NTFS metadata display, you'll see differences because NTFS hides its internal files, such as $MFT or $Secure , from the API . Some antivirus programs also store data in alternative streams and hide them, resulting in similar errors.

These are some of the standard metadata defined in NTFS (Windows Server 2003): $AttrDef, $BadClus, $BadClus:$Bad, $BitMap, $Boot, $LogFile, $Mft, $MftMirr, $Secure, $UpCase, $Volume, $Extend, $Extend\$Reparse, $Extend\$ObjId, $Extend\$UsnJrnl, $Extend\$UsnJrnl:$Max, $Extend\$Quota.

RKR correlates three sources in the file system: the Windows API, the Master File Table (MFT), and the directory indexes on disk. Combinations such as "Visible in the API but not in the index or MFT," "Visible in the MFT but not in the API," etc., may appear, especially if a file is created or deleted during the analysis and produces a window of temporary inconsistency.

Example of creation during scanning: C:\newfile.txt, 8 bytes in size, with the message “Visible in the API, but not in the index or MFT”. These cases do not necessarily point to rootkits, but to concurrent changes while being examined.

If "Access denied" appears, something is wrong: RootkitRevealer uses mechanisms to access any file, directory, or key, so that message should not occur under normal running conditions.

In the Registry, there are several discrepancies of interest: “Windows API length is inconsistent with raw data” (possible attempt to hide the actual content), “Type mismatch” (e.g., REG_SZ is advertised but it should be REG_BINARY), “Key name contains embedded NULL values” (a known technique that exploits the difference between NULL-terminated strings and strings with counts). For this last case, Sysinternals' RegDelNull utility helps clean keys with embedded NULLs.

“Data mismatch” can occur if a value changes during the scan (e.g., SQL Server uptimes such as HKLM\SOFTWARE\Microsoft\Microsoft SQL Server\RECOVERYMANAGER\MSSQLServer\uptime_time_utc). You have to validate that the value belongs to legitimate components that update data in real time.

An illustrative case was the HackerDefender rootkit: its services and drivers were invisible to the Windows API, but were present in the raw reading of the Registry hive; the same was true of its files, which the direct analysis of the file system did detect on disk.

Common errors and problems with rootkitrevealer.exe in forensic environments

Some forensic kits (e.g., WinTaylor) list typical errors related to rootkitrevealer.exe , such as: “not a valid Win32 application,” “not found,” “application error,” or “startup problem.” These messages usually occur during system installation, startup, or shutdown, or due to conflicts with other resident applications.

The most frequent causes include corrupted or missing files, invalid Registry entries, malware infections, incomplete uninstallations, or conflicts with other software. The source could be a corrupted Registry entry, accidental deletion by another tool, a failed download, or a previous infection that altered the binary.

As a curiosity of inventory, some listings document the executable with approximate size 334.720 bytes and hashes such as SHA‑1 and MD5 (e.g. SHA‑1 d39e8a3fe92adc7d7fbc5293edf8a7b965484a59, MD5 ee738fe9bcdd605821002cec8c7206db) and CRC32 98b1af0b; they also refer to the version 2.1 in its container app and “Forensic Toolkit/Operating System” category.

Rootkit detection and response methods

Detecting a rootkit is not always trivial. Beyond specific tools, techniques such as signature analysis of known threats, cold comparison of structures, memory searches for hooks and alterations, and review of memory dumps after crashes are combined to identify suspicious modules . It is also common to rely on Intrusion Prevention Systems (IPS) to protect the network and reduce infection vectors.

Specialized utilities include GMER (for detecting hidden processes and kernel alterations), Kaspersky TDSSKiller (especially for detecting bootkits and kernel rootkits), Malwarebytes Anti-Rootkit, Microsoft Defender Offline (for scanning before Windows starts), and RogueKiller. Running these from a trusted bootable USB drive or in Safe Mode reduces the attack surface.

For boot or firmware threats, it is advisable to use rescue media such as Kaspersky Rescue Disk, restore the MBR with bootrec /fixmbr where appropriate and in severe cases, update/flash the BIOS/UEFI to a clean version from the manufacturer to eradicate low-level persistence.

Monitoring with Sysinternals is invaluable: Process Monitor (ProcMon) for process and file activity, Autoruns to check what loads at startup, and RootkitRevealer for high/low-level discrepancies. SIEM platforms like Wazuh and telemetry in enterprise environments can uncover unexpected network behaviors or integrity changes.

If infection is confirmed, the reasonable sequence is: disconnect the machine from the network, scan from an external environment, evaluate boot/firmware integrity and, if there are no guarantees, back up data, completely clean the disk (tools such as DBAN) and reinstall from verified media, then enabling measures such as Secure Boot and TPM.

Prevention: Reasonable protection against rootkits

Prevention is key. Keep your system up to date, apply patches to third-party software, avoid executables from dubious sources, and don't use cracks or keygens: they are a favorite vector for packaging rootkit droppers and loaders .

Disable USB autorun, scan external drives before opening them, and in enterprise environments, limit or block ports and apply firewalls where appropriate. Work with unprivileged user accounts, apply the principle of least privilege, and require administrator credentials for critical changes, reducing the likelihood of silent escalations.

On compatible hardware, enable Secure Boot and TPM from UEFI to protect the boot chain and key sealing. Maintain regular offline or immutable backups and use snapshots/restore points to shorten recovery time if something goes wrong.

How rootkits are installed: droppers, loaders, and vectors

Attackers typically distribute rootkits as combined threats: a "dropper" that delivers the package and a "loader" that exploits vulnerabilities (such as buffer overflows) to plant the implant where it shouldn't. This is disguised as phishing emails , fake installers, or fraudulent updates.

Classic vectors include hijacking messaging clients to spread malicious links, trojanizing software on download portals, using other malware as carriers, and embedding in rich content documents (e.g., certain PDFs) that, when opened, automatically trigger the dropper.

Attack signs and detection clues

The goal of a rootkit is to remain undetected. Even so, you might observe configuration changes without user intervention, unusual network interruptions due to hidden traffic, unknown processes, services that cannot be closed, and security tools disabled without explanation.

Another clue is the conflicting information between utilities that list files, processes, or Registry keys using different paths (API versus raw reading). This is where approaches like RootkitRevealer shine: the same object that "is" on the disk but "is not" according to the API points to manipulation.

Main types of rootkits

User mode: These operate at the process and library level. They are more stable and relatively easier to detect, although they can hide files, processes, and keys. A classic historical example is HackerDefender.

Kernel mode: These viruses reside in the kernel, with complete control and great stealth; they are difficult to eradicate and tend to cause instabilities if poorly designed. Examples of this family: TDL/Alureon in its evolution.

Hybrids: combine user and kernel components to balance concealment and stability, resulting in popularity among attackers due to their practical versatility.

Firmware/Bootkits: These infect the BIOS/UEFI or the boot sector (MBR/UEFI) to load before the operating system. Technologies like Secure Boot have made many classic bootkits obsolete, but modern UEFI implants have emerged.

Virtual and memory-based: VMBRs load a hypervisor beneath the OS and virtualize it; memory-based ones only reside in RAM and disappear upon reboot, very useful for ephemeral operations.

Examples and highlighted chronology

The first rootkits for SunOS were developed in the 90s; in 1999, Greg Hoglund described NTRootkit (Windows, kernel mode), and in 2003 HackerDefender (Windows 2000/XP, user mode) emerged, which prompted a "tug-of-war" with tools like RootkitRevealer.

In 2004, the so-called "Greek Watergate" used a rootkit to hack more than 100 phones on a GSM network; in 2005 it was discovered that Sony BMG included an anti-piracy rootkit in some CDs, sparking a huge security controversy.

Since 2008, bootkits like TDL (TDL-1 to TDL-4) have evolved; in 2009, “Machiavelli” proved that macOS (then Mac OS X) was not immune either; in 2010, Stuxnet used rootkit components to sabotage Iranian industrial systems.

In 2012, Flame , a massive modular malware, appeared ; in 2018, LoJax became the first UEFI rootkit detected in the wild; and in 2019, Scranos combined credential theft and hidden revenue generation with click farms through mass-compromised browsers.

Resources and recommended readings

Mark Russinovich's investigation into the Sony case and his article "Unearthing Rootkits" in Windows IT Pro help to understand the phenomenon and the technique behind RKR; the book "Rootkits: Subverting the Windows Kernel" by Greg Hoglund and Jamie Butler is the most in-depth treatise on the subject.

The Phrack Archive, Peter Szor's "The Art of Computer Virus Research and Defense", Ed Skoudis and Lenny Zeltser's "Malware: Fighting Malicious Code", and the "Windows Internals" series (4th edition onwards) are essential materials for anyone wanting to delve deeper into architecture and serious countermeasures.

RootkitRevealer in the Sysinternals ecosystem

RKR coexists with other Sysinternals utilities useful in research: AccessChk and AccessEnum (effective permissions), Autoruns (everything that starts with the system), Process Explorer (who opened what and with which DLL), PsExec/PsTools (remote execution and administration), PsLogList and PsLoggedOn (events and sessions), Sigcheck (digital signatures), SDelete (secure deletion), ShareEnum (shared resources) and Sysmon (advanced telemetry in the event log).

It's common to find references to "Download 1.71" in historical repositories, as well as "Run now" via Sysinternals Live. Although the project is veteran, its mindset—comparing high-level versus low-level approaches—remains key for rootkit hunting.

RootkitRevealer is, above all, a lesson in defensive engineering: if something is manipulating what the API returns, you have to look underneath and compare it with what actually exists on disk and in the Registry; with good practices, appropriate tools and offline verification when necessary, it is possible to uncover what is trying to hide where we think no one will look.