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 rootkits are detected. discrepancies caused by rootkits between what the system displays and what is actually on the disk.

Unlike other scanners, it doesn't look for signatures or patterns: it compares the high-level view of the Windows API with the raw, low-level reading of the disk and registry. This seemingly simple idea uncovers the potential for malware to attempt to exploit the system. hide files, keys or values cheating on the path of system calls.

What is RootkitRevealer and what systems does it work on?

It is an advanced tool to detect signs of rootkits both in user mode as in kernel mode. It was created for Windows XP and Windows Server 2003 (32-bit), and is commonly listed as free, in English, and measuring around 231 KB; many listings also indicated it was compatible with Windows NT/2000/XP/Vista at the time.

Its purely command-line version was eventually removed because some malware authors started monitoring the executable name; to prevent this, the program launches as a service from a randomly named copy of itself, making it difficult to detect by name and making it harder to provide 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.) hide from the user and security tools. There are several families: persistent (survive reboots), memory-resident (disappear 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 leak entries that would reveal your files, processes, or modified registry keys. So Explorer, Command Prompt, or Registry Editors don't see what's actually there.

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 does not appear in Task Manager or Process Explorer even if it is running.

There are hybrid (part user-based and part kernel-based), firmware (BIOS/UEFI and other components), boot or bootkits (MBR/UEFI), virtual (which place the real OS inside a virtual machine), and memory (non-persistent) bootkits. The latter can be particularly elusive, while firmware and bootkits persist even after reinstalling the operating system. operating system from scratch.

How RootkitRevealer works

RKR contrasts two snapshots: the Windows API view (high level) and the raw reading of the volume and Registry hives at a low level. If a rootkit tampers with high-level calls to hide something, that tampering is revealed because what's on the 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 do this, it would need intimate knowledge of NTFS, FAT, and Registry formats, and modify structures without causing inconsistencies or obvious side effects. great technical complexity which has rarely been observed. Even so, there is no foolproof “universal detector”: even a boot from an external environment (for example, using the best Linux distributions) could be sabotaged by specially designed devices sophisticated and persistentIn practice, the most robust approach is to combine online analysis with offline verification in trusted environments.

Requirements, good practices and execution

To run, the account needs the “Back up files and directories”, “Load drivers” and “Volume maintenance” privileges (in Windows XP and higher, administrators have these by default). To minimize false positives, it is recommended to run the scan with the system in standby mode with no applications open.

To run manually, simply press the scan button. During the process, the program reports on the progress and lists any discrepancies. There are two relevant options: "Hide files from NTFS metadata" (active by default, to not display the standard metadata hidden by NTFS) and "Scan log" (active by default; unchecking it skips the scan). Windows' register).

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 most common when a rootkit hides entries. If you haven't enabled NTFS metadata viewing, you'll see discrepancies because NTFS hides its internal files from the API. $MFT or $SecureSome antivirus programs also store data in alternate streams and hide it, causing 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: Windows API, the Master File Table (MFT), and on-disk directory indexes. Combinations such as “Visible in API but not in index or MFT,” “Visible in MFT but not in API,” etc., may appear, especially if a file is created or deleted during the scan and produces a time inconsistency window.

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 you see “Access denied”, something is wrong: RootkitRevealer uses mechanisms to access any file, directory or key, so this message should not appear under normal conditions. normal execution.

In the Registry, there are several discrepancies of interest: “Windows API length is inconsistent with raw data” (possible attempt to hide the real content), “Type mismatch” (e.g. REG_SZ is advertised but it is REG_BINARY), “Key name contains embedded NULL values” (known technique exploiting the difference between NULL-terminated strings and strings with a count). For the latter case, the utility RegDelNull from Sysinternals 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 were not directly scanned by the file system. yes it detected 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 “problem starting”. These messages usually occur during installation, startup or shutdown of the system, or due to conflicts with other applications. resident applications.

The most common causes include missing or corrupted files, invalid registry entries, malware infections, incomplete uninstallations, or conflicts with other software. The source could be a corrupt registry entry, accidental deletion by another tool, a failed download, or a previous infection that alters 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 isn't always trivial. Beyond specific tools, techniques such as signature analysis of known threats, cold-comparison of structures, memory search for hooks and alterations, and reviewing memory dumps after crashes are combined to identify suspicious modulesIt is also common to rely on prevention systems (IPS) to protect the network and reduce infection vectors.

Among the specialized utilities are GMER (hidden processes and kernel alterations), Kaspersky TDSSKiller (especially kernel bootkits and rootkits), Malwarebytes Anti-Rootkit, Microsoft Defender Offline (scanning before Windows starts), and RogueKiller. Run them from a USB flash drive. reliable boot or in Safe Mode reduces the evasion 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 gold: Process Monitor (ProcMon) for process and file activity, Autoruns to check what loads at startup and Rootkit Revealer for high/low level discrepancies. SIEM platforms like Wazuh and telemetry in corporate environments can uncover unexpected network behavior or integrity changes.

If infection is confirmed, the reasonable sequence is: disconnect the machine from the network, scan from external environment, assess boot/firmware integrity and if there are no guarantees, backup data, wipe the disk completely (tools like DBAN) and reinstall from verified media, enabling afterward measures like Secure Boot and TPM.

Prevention: Reasonable protection against rootkits

Prevention is key. Keep your system up-to-date, patch third-party software, avoid executables from dubious sources, and don't use cracks or keygens: they're a favorite vector for bundling. droppers and loaders of rootkits.

Disables USB autorun, scans external drives before opening them, and in business environments, limits or blocks ports and enforces firewalls when it makes sense. It works with unprivileged user accounts, applies the principle of least privilege, and requires administrator credentials for critical changes, reducing the likelihood of silent climbs.

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 if something happens. manages to sneak in.

How rootkits are installed: droppers, loaders, and vectors

Attackers often distribute rootkits as blended 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 email, 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, trigger the attack. dropper automatically.

Attack signs and detection clues

The goal of a rootkit is to make it "unnoticeable." However, configuration changes without user intervention, unusual network interruptions due to hidden traffic, unknown processes, services that cannot be shut down, and security tools can be observed. disabled without explanation.

Another clue is conflicting information between utilities that list files, processes, or registry keys by different paths (API vs. raw read). This is where approaches like RootkitRevealer's shine: the same object that "is" on disk and "isn't" for the API. points to manipulation.

Main types of rootkits

User mode: They 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: HackerDefender.

Kernel mode: They live in the core, with total control and great stealth; they are difficult to eradicate and tend to cause instability if poorly designed. Family examples: TDL/Alureon in its evolution.

Hybrids: They combine user and kernel components to balance stealth and stability, making them popular among attackers due to their practical versatility.

Firmware/Bootkits: They 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 new ones have emerged. UEFI implants modern.

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

Examples and highlighted chronology

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

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

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

In 2012 appeared Flame, a massive modular malware; in 2018 LoJax It became the first UEFI rootkit detected in the wild; and in 2019, SCRAN combined credential theft and hidden revenue generation with browser-based click farms committed en masse.

Resources and recommended readings

Mark Russinovich's research on 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 definitive treatise. deeper into 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 onward) are essential materials for anyone who wants to delve deeper into architecture and serious countermeasures.

RootkitRevealer in the Sysinternals ecosystem

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

It's common to find references to "Download 1.71" in historical repositories, and to "Run Now" via Sysinternals Live. Although the project is old, its mental model—comparing high versus low—remains key to rootkit hunting.

RootkitRevealer is, above all, a lesson in defensive engineering: if something manipulates 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, adequate tools and offline verification when appropriate, it is possible to uncover what is trying to hide where we think it is. no one is going to look.