Qué es RootkitRevealer: cómo funciona, uso e indicios de rootkits

Informatec Digital » Seguridad » Qué es RootkitRevealer: cómo funciona, uso e indicios de rootkits

RootkitRevealer es una de esas utilidades legendarias que todo profesional de Windows debería conocer; fue creada por el equipo de Sysinternals con Mark Russinovich al frente y, aunque surgió hace años, sigue siendo una referencia para entender cómo se detectan las discrepancias que provocan los rootkits entre lo que muestra el sistema y lo que realmente hay en disco.

Frente a otros escáneres, no busca firmas ni patrones: compara la visión de alto nivel de la API de Windows con la lectura cruda a bajo nivel del disco y del Registro. Esa idea, aparentemente sencilla, destapa cuando un malware intenta ocultar archivos, claves o valores haciendo trampas en el camino de las llamadas del sistema.

¿Qué es RootkitRevealer y en qué sistemas funciona?

Se trata de una herramienta avanzada para detectar indicios de rootkits tanto en modo usuario como en modo kernel. Nació para Windows XP y Windows Server 2003 (32 bits), y comúnmente se la encuentra catalogada como gratuita, en inglés y con un tamaño cercano a los 231 KiB; muchos listados la marcaron también como compatible con Windows NT/2000/XP/Vista en su época.

Con el tiempo se eliminó su versión puramente de línea de comandos porque algunos autores de malware empezaron a vigilar el nombre del ejecutable; para evitarlo, el programa se lanza como servicio desde una copia de sí mismo con nombre aleatorio, lo que dificulta esa detección por nombre y complica ofrecer una interfaz 100 % por consola.

¿Qué es un rootkit? Conceptos clave

El término rootkit designa técnicas y mecanismos que permiten a un malware (virus, troyanos, spyware, etc.) ocultarse del usuario y de las herramientas de seguridad. Se distinguen varias familias: persistentes (sobreviven a reinicios), residentes en memoria (desaparecen al reiniciar), de modo usuario y de modo kernel, entre otras variantes modernas.

Un rootkit en modo usuario puede interceptar funciones como FindFirstFile/FindNextFile, o los enumeradores nativos del sistema, para filtrar entradas que revelarían sus archivos, procesos o claves del Registro modificadas. Así, el Explorador, el símbolo del sistema o editores del Registro no ven lo que realmente existe.

Los rootkits en modo kernel van más lejos: además de interceptar la API nativa, pueden manipular directamente estructuras del núcleo, por ejemplo sacando su proceso de la lista de procesos activos para que no aparezca en Task Manager o Process Explorer aunque esté ejecutándose.

Existen híbridos (parte en usuario y parte en kernel), de firmware (BIOS/UEFI y otros componentes), de arranque o bootkits (MBR/UEFI), virtuales (que colocan el SO real dentro de una máquina virtual) y de memoria (no persistentes). Estos últimos pueden resultar particularmente elusivos, mientras que los de firmware y arranque persisten incluso tras reinstalar el sistema operativo desde cero.

Cómo funciona RootkitRevealer

RKR contrasta dos instantáneas: la visión de la API de Windows (alto nivel) y la lectura cruda del volumen y de los archivos de subárbol del Registro (hives) a bajo nivel. Si un rootkit adultera las llamadas de alto nivel para esconder algo, esa alteración se delata porque lo que hay en disco y Registro no coincide con lo que la API dice que hay, generando discrepancias diagnosticables.

Teóricamente, un rootkit podría intentar ocultarse también de RootkitRevealer interceptando sus lecturas crudas y reescribiendo los datos sobre la marcha. Para lograrlo tendría que conocer íntimamente los formatos de NTFS, FAT y del Registro, y modificar estructuras sin provocar incoherencias ni efectos laterales evidentes, algo de gran complejidad técnica que rara vez se ha observado. Aun así, no existe un “detector universal” infalible: incluso un arranque desde entorno externo (por ejemplo, usando las mejores distribuciones Linux) podría verse saboteado por artefactos especialmente sofisticados y persistentes. En la práctica, lo más robusto es combinar análisis en línea con verificación fuera de línea en entornos fiables.

Requisitos, buenas prácticas y ejecución

Para su ejecución, la cuenta necesita privilegios de “Copia de seguridad de archivos y directorios”, “Cargar controladores” y “Mantenimiento de volumen” (en Windows XP y superior los administradores los tienen por defecto). Para minimizar falsos positives se recomienda ejecutar el escaneado con el sistema en reposo y sin aplicaciones abiertas.

En ejecución manual basta con pulsar el botón de análisis. Durante el proceso, el programa va informando del progreso y va listando eventuales discrepancias. Hay dos opciones relevantes: “Ocultar archivos de metadatos NTFS” (activa por defecto, para no mostrar los metadatos estándar ocultos por NTFS) y “Registro de examen” (activa por defecto; al desmarcarla se omite el escaneo del Registro de Windows).

Para automatización, soporta parámetros que permiten arrancar, registrar y salir sin intervención: rootkitrevealer outputfile]. La opción -a inicia y finaliza automáticamente; -c saca el resultado en CSV; -m muestra metadatos NTFS; y -r desactiva el análisis del Registro. El fichero de salida debe estar en un volumen local accesible.

La ejecución remota es posible con PsExec. Por ejemplo: psexec \\remote -c rootkitrevealer.exe -a c:\windows\system32\rootkit.log. Con -c, el progreso no se muestra y las discrepancias se imprimen en CSV, lo que facilita su importación en bases de datos o scripts.

Interpretación de resultados y discrepancias típicas

Las discrepancias “Hidden from Windows API” son las más frecuentes cuando un rootkit oculta entradas. Si no has activado la visualización de metadatos NTFS, verás diferencias porque NTFS oculta a la API sus ficheros internos como $MFT o $Secure. También algunos antivirus almacenan datos en flujos alternativos y los ocultan, provocando entradas similares.

Estos son algunos de los metadatos estándar definidos en 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 correlaciona tres fuentes en el sistema de archivos: API de Windows, la tabla maestra de archivos (MFT) y los índices de directorios en disco. Pueden aparecer combinaciones como “Visible en la API pero no en índice o MFT”, “Visible en MFT pero no en API”, etc., sobre todo si un fichero se crea o borra durante el análisis y produce una ventana de inconsistencia temporal.

Ejemplo de creación durante el escaneo: C:\newfile.txt, tamaño 8 bytes, con mensaje “Visible en la API, pero no en índice ni MFT”. Estos casos no apuntan necesariamente a rootkits, sino a cambios concurrentes mientras se examina.

Si aparece “Access denied”, algo va mal: RootkitRevealer emplea mecanismos para acceder a cualquier archivo, directorio o clave, por lo que ese mensaje no debería producirse en condiciones normales de ejecución.

En el Registro, hay varias discrepancias de interés: “La longitud de la API de Windows no es coherente con los datos crudos” (posible intento de ocultación del contenido real), “Error de coincidencia de tipos” (ej. se anuncia REG_SZ pero es REG_BINARY), “El nombre de clave contiene valores NULL incrustados” (técnica conocida que explota la diferencia entre cadenas terminadas en NULL y cadenas con recuento). Para este último caso, la utilidad RegDelNull de Sysinternals ayuda a limpiar claves con NULLs incrustados.

“Error de coincidencia de datos” puede darse si un valor cambia durante el escaneo (p. ej., tiempos de actividad de SQL Server como HKLM\SOFTWARE\Microsoft\Microsoft SQL Server\RECOVERYMANAGER\MSSQLServer\uptime_time_utc). Hay que validar que el valor pertenezca a componentes legítimos que actualizan datos en tiempo real.

Un caso ilustrativo fue el rootkit HackerDefender: sus servicios y controladores quedaban invisibles para la API de Windows, pero estaban presentes en la lectura cruda del hive del Registro; lo mismo ocurría con sus ficheros, que el análisis directo del sistema de archivos sí detectaba en disco.

Errores y problemas comunes con rootkitrevealer.exe en entornos forenses

En algunos kits forenses (por ejemplo, WinTaylor) se listan errores típicos relacionados con rootkitrevealer.exe, como: “no es una aplicación Win32 válida”, “no encontrado”, “error de aplicación” o “problema al iniciar”. Estos mensajes suelen producirse durante instalación, arranque o apagado del sistema, o por conflictos con otras aplicaciones residentes.

Las causas más frecuentes incluyen archivos dañados o ausentes, entradas de Registro inválidas, infecciones de malware, desinstalaciones incompletas o conflictos con otro software. El origen puede ser una entrada de Registro corrupta, una eliminación accidental por otra herramienta, una descarga fallida o una infección previa que altere el binario.

Como curiosidad de inventario, algunos listados documentan el ejecutable con tamaño aproximado 334.720 bytes y hashes como SHA‑1 y MD5 (por ejemplo, SHA‑1 d39e8a3fe92adc7d7fbc5293edf8a7b965484a59, MD5 ee738fe9bcdd605821002cec8c7206db) y CRC32 98b1af0b; además refieren la versión 2.1 en su app contenedora y categoría “Forensic Toolkit/Operating System”.

Métodos de detección y respuesta ante rootkits

Detectar un rootkit no siempre es trivial. Más allá de herramientas específicas, se combinan técnicas como análisis por firmas de amenazas conocidas, comparación en frío de estructuras, búsqueda en memoria de ganchos y alteraciones, y revisión de volcados de memoria tras bloqueos para identificar módulos sospechosos. También es habitual apoyarse en sistemas de prevención (IPS) para proteger la red y reducir vectores de infección.

Entre las utilidades especializadas destacan GMER (procesos ocultos y alteraciones en kernel), Kaspersky TDSSKiller (especialmente bootkits y rootkits de kernel), Malwarebytes Anti-Rootkit, Microsoft Defender Offline (escaneo antes de iniciar Windows) y RogueKiller. Ejecutarlas desde un USB de arranque confiable o en Modo Seguro reduce la superficie de evasión.

Para amenazas de arranque o firmware, conviene usar medios de rescate como Kaspersky Rescue Disk, restaurar el MBR con bootrec /fixmbr cuando proceda y, en casos severos, actualizar/“flashear” el BIOS/UEFI a una versión limpia del fabricante para erradicar persistencias de bajo nivel.

El monitoreo con Sysinternals es oro: Process Monitor (ProcMon) para actividad de procesos y archivos, Autoruns para revisar qué se carga al inicio y RootkitRevealer para discrepancias alto/bajo nivel. Plataformas SIEM como Wazuh y telemetría en entornos corporativos pueden destapar comportamientos de red o cambios de integridad no esperados.

Si se confirma infección, la secuencia razonable es: desconectar la máquina de la red, escanear desde entorno externo, evaluar integridad de arranque/firmware y, si no hay garantías, respaldar datos, limpiar el disco por completo (herramientas como DBAN) y reinstalar desde medios verificados, habilitando después medidas como Secure Boot y TPM.

Prevención: blindaje razonable contra rootkits

La prevención manda. Mantén el sistema al día, aplica parches a software de terceros, evita ejecutables de orígenes dudosos y no uses cracks o keygens: son uno de los vectores favoritos para empaquetar droppers y loaders de rootkits.

Desactiva el autorun de USB, analiza unidades externas antes de abrirlas y, en entornos empresariales, limita o bloquea puertos y aplica firewalls cuando tenga sentido. Trabaja con cuentas de usuario sin privilegios, aplica el principio de mínimo privilegio y exige credenciales de administrador para cambios críticos, reduciendo la probabilidad de escaladas silenciosas.

En hardware compatible, activa Secure Boot y TPM desde UEFI para proteger la cadena de arranque y el sellado de claves. Mantén copias de seguridad periódicas offline o inmutables y utiliza snapshots/puntos de restauración para acortar la recuperación si algo consigue colarse.

Cómo se instalan los rootkits: droppers, loaders y vectores

Los atacantes suelen distribuir rootkits como amenazas combinadas: un “dropper” que entrega el paquete y un “loader” que aprovecha vulnerabilidades (como desbordamientos de búfer) para plantar el implante donde no debería. Esto se disfraza en correo de phishing, instaladores falsos o actualizaciones fraudulentas.

Entre los vectores clásicos están el secuestro de clientes de mensajería para propagar enlaces maliciosos, la troyanización de software en portales de descarga, el uso de otros malware como transportistas y la incrustación en documentos de contenido enriquecido (p. ej., ciertos PDFs) que, al abrirse, disparan el dropper automáticamente.

Señales de ataque y pistas de detección

Que un rootkit “no se note” es su objetivo. Aun así, pueden observarse cambios de configuración sin intervención del usuario, intermitencias de red inusuales por tráfico oculto, procesos desconocidos, servicios que no admiten cierre y herramientas de seguridad desactivadas sin explicación.

Otra pista es la información contradictoria entre utilidades que enumeran archivos, procesos o claves del Registro por rutas distintas (API frente a lectura cruda). Ahí es donde enfoques como el de RootkitRevealer brillan: un mismo objeto que “está” en el disco y “no está” para la API apunta a manipulación.

Tipos principales de rootkits

Modo usuario: operan a nivel de procesos y bibliotecas. Son más estables y relativamente más fáciles de detectar, aunque pueden ocultar archivos, procesos y claves. Ejemplo clásico histórico: HackerDefender.

Modo kernel: viven en el núcleo, con control total y gran sigilo; son difíciles de erradicar y tienden a provocar inestabilidades si están mal diseñados. Ejemplos de familia: TDL/Alureon en su evolución.

Híbridos: combinan componentes en usuario y kernel para equilibrar ocultación y estabilidad, resultando populares entre atacantes por su versatilidad práctica.

Firmware/Bootkits: infectan BIOS/UEFI o el sector de arranque (MBR/UEFI) para cargarse antes del sistema operativo. Tecnologías como Secure Boot han dejado obsoletos muchos bootkits clásicos, pero han aparecido implantes UEFI modernos.

Virtuales y de memoria: los VMBR cargan un hipervisor por debajo del SO y lo virtualizan; los de memoria sólo residen en RAM y se evaporan al reiniciar, muy útiles para operaciones efímeras.

Ejemplos y cronología destacada

En los 90 se desarrollaron los primeros rootkits para SunOS; en 1999, Greg Hoglund describió NTRootkit (Windows, modo kernel), y en 2003 surgió HackerDefender (Windows 2000/XP, modo usuario), que impulsó un “tira y afloja” con herramientas como RootkitRevealer.

En 2004, el llamado “Watergate griego” empleó un rootkit para intervenir más de 100 teléfonos de una red GSM; en 2005 se descubrió que Sony BMG incluía un rootkit antipiratería en algunos CD, desatando una enorme controversia de seguridad.

Desde 2008 evolucionaron bootkits como TDL (TDL-1 hasta TDL-4); en 2009 “Machiavelli” demostró que macOS (entonces Mac OS X) tampoco era inmune; en 2010, Stuxnet usó componentes de rootkit para sabotear sistemas industriales iraníes.

En 2012 apareció Flame, un malware modular masivo; en 2018 LoJax se convirtió en el primer rootkit UEFI detectado en la naturaleza; y en 2019, Scranos combinó robo de credenciales y generación oculta de ingresos con granjas de clics a través de navegadores comprometidos en masa.

Recursos y lecturas recomendadas

La investigación de Mark Russinovich sobre el caso Sony y su artículo “Desenterrar rootkits” en Windows IT Pro ayudan a comprender el fenómeno y la técnica detrás de RKR; el libro “Rootkits: Subverting the Windows Kernel”, de Greg Hoglund y Jamie Butler, es el tratado más profundo del tema.

El archivo de Phrack, “The Art of Computer Virus Research and Defense” de Peter Szor, “Malware: Fighting Malicious Code” de Ed Skoudis y Lenny Zeltser, y la serie “Windows Internals” (4ª edición en adelante) son materiales imprescindibles para quien quiera profundizar en arquitectura y contramedidas serias.

RootkitRevealer en el ecosistema Sysinternals

RKR convive con otras utilidades de Sysinternals útiles en investigación: AccessChk y AccessEnum (permisos efectivos), Autoruns (todo lo que arranca con el sistema), Process Explorer (quién abrió qué y con qué DLL), PsExec/PsTools (ejecución y administración remota), PsLogList y PsLoggedOn (eventos y sesiones), Sigcheck (firmas digitales), SDelete (borrado seguro), ShareEnum (recursos compartidos) y Sysmon (telemetría avanzada en el registro de eventos).

Es habitual encontrar referencias a “Download 1.71” en repositorios históricos, y a “Ejecutar ahora” vía Sysinternals Live. Aunque el proyecto es veterano, su modelo mental —comparar alto frente a bajo nivel— sigue siendo clave para caza de rootkits.

RootkitRevealer es, ante todo, una lección de ingeniería defensiva: si algo manipula lo que la API te devuelve, hay que mirar por debajo y cotejar con lo que realmente existe en disco y en el Registro; con buenas prácticas, herramientas adecuadas y verificación fuera de línea cuando proceda, es posible destapar aquello que intenta esconderse donde creemos que nadie va a mirar.