Qué es un rootkit: tipos, funcionamiento y métodos de detección

Un rootkit es malware diseñado para mantener acceso oculto y privilegiado en un sistema comprometido. La palabra deriva de "root" (la cuenta de administrador en Unix) más "kit" (conjunto de herramientas), y describe lo que hace: un paquete que combina escalada, persistencia y, sobre todo, ocultación, de forma que el atacante conserva control sobre la máquina sin que las herramientas defensivas habituales lo vean.

Esta guía explica qué es un rootkit, los seis tipos por nivel de ejecución (user-mode, kernel-mode, bootkit, firmware, hypervisor, container), técnicas de ocultación, casos públicos, encaje con MITRE ATT&CK y qué medidas de detección, hardening y respuesta DFIR funcionan en entornos corporativos en 2026.

Lo esencial

• Un rootkit es malware cuya función principal es mantenerse oculto en un sistema comprometido mientras conserva acceso privilegiado.
• Se clasifican por el nivel de ejecución: user-mode (ring 3), kernel-mode (ring 0), bootkit (pre-OS), firmware (BIOS, UEFI, periféricos), hypervisor y container.
• Cuanto más bajo opera el rootkit (firmware, hypervisor), menos visibilidad tienen los antivirus y EDR convencionales.
• La detección seria requiere memory forensics, boot-time scanning, integrity checking y atestación de hardware con TPM.
• Cuando se confirma un rootkit en kernel, bootkit o firmware, la respuesta no es desinfectar, es reimaginar (y, en firmware, reflashar o sustituir hardware).

Qué es un rootkit y por qué es la peor categoría de malware

Un rootkit es un conjunto de herramientas maliciosas diseñado para mantener acceso privilegiado sobre un sistema mientras oculta activamente su presencia y la de los artefactos asociados (procesos, ficheros, conexiones de red, claves de registro). El término nació en Unix a principios de los noventa, cuando los atacantes reemplazaban binarios como ls, ps o netstat por versiones modificadas que filtraban su propia actividad.

La razón por la que se considera la peor categoría de malware es estructural. Un ransomware es visible por definición y un troyano toca disco y red de forma observable por un EDR. Un rootkit bien implementado elimina las señales que las herramientas defensivas usan para detectarlo. En kernel-mode, las funciones que un antivirus llama para enumerar procesos devuelven respuestas filtradas por el propio rootkit. En firmware, sobrevive a reinstalación y a cambio de disco. En hypervisor, el sistema operativo cliente vive dentro de una máquina virtual del atacante sin saberlo.

Un rootkit casi siempre incluye un backdoor y mecanismos de persistencia, pero su rasgo definitorio es la ocultación.

Tipos de rootkit por nivel de ejecución

User-mode rootkit (ring 3)

Operan con privilegios de usuario. Modifican bibliotecas dinámicas, hookean funciones de la API de espacio de usuario, sustituyen binarios o utilizan precarga (LD_PRELOAD en Linux, DLL hijacking en Windows) para interceptar llamadas antes de que lleguen al sistema. Son los más antiguos y los más fáciles de detectar con un EDR moderno (telemetría de carga de DLL, hashes firmados, comparación contra catálogo). Su valor es la portabilidad: funcionan sin exploit de kernel ni firma válida de driver. Ejemplos: Azazel, Vlany, Jynx2.

Kernel-mode rootkit (ring 0)

Se cargan como módulo del kernel (LKM en Linux, driver en Windows, kext histórico en macOS). Ejecutan con privilegios totales sobre el sistema operativo y pueden modificar estructuras internas, hookear llamadas al sistema y reescribir tablas de funciones del propio kernel.

La detección desde el propio host es problemática: el rootkit puede mentir al EDR. Si el agente enumera procesos, el rootkit excluye los suyos por hook. Si lee un fichero, filtra el resultado o devuelve un hash falsificado. Windows obliga a firma WHQL y, con HVCI activado, ejecuta los drivers en un contexto protegido por Hyper-V. Linux carga LKMs solo si el kernel lo permite, y con kernel.modules_disabled=1 tras boot, ni eso. Estos controles han elevado el listón pero técnicas como bring-your-own-vulnerable-driver siguen apareciendo en campañas reales.

Bootkit (compromiso de MBR o UEFI)

Persisten en el proceso de arranque: MBR clásico, VBR, o, modernamente, en firmware UEFI antes de que cargue el sistema operativo. El atacante toma control en el primer instante del boot y arranca el sistema desde dentro de su propio entorno, antes de que existan controles defensivos.

Los bootkits MBR son una categoría legada (TDL4, Mebroot) sin vector práctico contra Windows moderno con Secure Boot. Los UEFI son la generación actual: LoJax (APT28, 2018), MosaicRegressor (2020), MoonBounce (2022), BlackLotus (2023, capaz de saltar Secure Boot mediante CVE-2022-21894). La detección requiere Measured Boot con TPM. Reinstalar el sistema operativo no basta: el bootkit sigue en firmware.

Firmware rootkit (BIOS, NIC, GPU, controladores de disco)

Implantes en firmware de placas base (BIOS o UEFI), tarjetas de red, controladores de disco o SSD, baseboard management controllers (BMC), e incluso GPU. Superficie pequeña, actores limitados, impacto radical: sobreviven a reinstalación, cambio de disco y ciertos cambios de hardware.

El componente firmware de Stuxnet (2010) sobre PLC Siemens era esencialmente un rootkit industrial. En endpoints, Kaspersky documentó en 2015 implantes del Equation Group (atribuidos a NSA) en firmware de discos duros de varios fabricantes capaces de sobrevivir a borrado de bajo nivel. La detección requiere CHIPSEC y atestación TPM. La remediación pasa por reflashado desde fuente confiable y, en casos sensibles, sustitución física.

Hypervisor rootkit (tipo Blue Pill)

Concepto demostrado por Joanna Rutkowska en 2006 con Blue Pill. El atacante introduce un hypervisor minimalista debajo del sistema operativo en ejecución, de forma que el sistema pasa a ejecutarse como guest dentro de una máquina virtual creada por el atacante, sin saberlo. Desde fuera del guest, el hypervisor tiene visibilidad y control total sobre memoria, ejecución y dispositivos. Las extensiones de virtualización modernas (Intel VT-x, AMD-V) lo hacen técnicamente posible. Su uso en campañas reales documentadas es escaso, pero sigue siendo un vector relevante frente a actores estatales.

Container rootkit (abuso de eBPF)

Categoría emergente en Linux moderno. eBPF permite cargar programas en kernel space con privilegios controlados, y desde 2021 hay atacantes documentados que lo usan para hookear syscalls, filtrar tráfico y ocultar procesos sin cargar un módulo tradicional, manteniendo persistencia en entornos contenedorizados y cloud. Familias documentadas: BPFDoor (atribuido a actores de origen chino), Symbiote, Boopkit. La detección requiere telemetría sobre carga de programas eBPF y restricciones sobre quién puede hacerlo sin privilegios.

Técnicas comunes de ocultación

• Hooking de syscalls. El rootkit reemplaza punteros en la tabla de llamadas al sistema (SSDT en Windows, syscall table en Linux) para que las llamadas pasen primero por su código y filtre cualquier consulta sobre procesos, ficheros, conexiones o claves de registro.
• DKOM (Direct Kernel Object Manipulation). Modificación directa de estructuras del kernel sin pasar por las APIs oficiales. El ejemplo clásico es desenlazar un proceso de la lista EPROCESS en Windows: sigue ejecutándose porque el scheduler usa otra estructura, pero las herramientas oficiales no lo ven.
• Filtrado de /proc en Linux. Los rootkits user-mode interceptan llamadas a /proc para que el PID malicioso no aparezca. Los kernel-mode lo hacen modificando el VFS o hookeando getdents.
• Network filter drivers. Drivers maliciosos (NDIS en Windows, netfilter hooks en Linux) que filtran tráfico antes de que llegue al espacio de usuario, ocultando conexiones a C2 de cualquier herramienta que enumere sockets.
• Inline hooking. Reemplazo de los primeros bytes de funciones críticas con un salto al código del rootkit. Más difícil de detectar que el hooking por tabla.

Rootkits famosos (con contexto, sin glamour)

• Stuxnet (2010). Operación estatal contra Natanz. Incluía componente Windows con rootkit de kernel firmado con certificados robados a Realtek y JMicron, más componente sobre PLC Siemens.
• TDL/TDSS (2008 a 2012). Bootkits que infectaron millones de equipos Windows. TDL4 sobrescribía el MBR y cargaba antes del sistema operativo. Las versiones de Windows con Secure Boot la dejaron sin vector.
• Necurs (2012 a 2019). Botnet sobre rootkit kernel-mode que servía de plataforma para banking trojans, ransomware y spam. Microsoft coordinó su desmantelamiento en 2020.
• Equation Group (2015). Implantes en firmware de discos duros de múltiples fabricantes, capaces de sobrevivir a borrado completo. Atribuidos a NSA en informes de Kaspersky.
• LoJax (2018). Primer rootkit UEFI documentado en campaña real, atribuido a APT28. ESET mostró su persistencia en SPI flash, sobreviviendo a reinstalación y cambio de disco.
• Triangulation (2023). Cadena de exploits sobre iOS divulgada por Kaspersky. Cuatro zero-days, manipulación de memoria fuera de la sandbox y persistencia con propiedades cercanas a rootkit.

Lo que comparten: actores con tiempo, recursos y objetivos específicos. Los rootkits a este nivel se reservan para operaciones donde la persistencia profunda compensa el riesgo de quemar la capacidad.

Detección de rootkits con EDR y forensics

La detección desde el propio host es estructuralmente débil: el rootkit puede mentir a las herramientas que lo buscan. Lo que funciona combina varias capas:

• Memory forensics. Volcado de memoria física (FTK Imager, WinPmem, LiME) y análisis con Volatility. La memoria expone estructuras reales del kernel, listas de procesos por scheduler y hooks en SSDT.
• Boot-time scanning. Análisis con medios externos (WinPE, live USB) antes de que el rootkit se cargue.
• Integrity checking. Comparación de hashes de binarios, drivers, kernel y firmware contra valores conocidos buenos. WHQL en Windows, validación de paquetes e IMA en Linux.
• Anomaly detection en EDR. Drivers nuevos fuera de ventana de parcheo, modificaciones en tablas del kernel, procesos sin entrada oficial pero con actividad de red, discrepancias entre tasklist y el agente.
• Network analytics fuera del host. NetFlow, Zeek y taps detectan conexiones que el host comprometido niega tener.
• Atestación TPM y Measured Boot. Detecta cambios en bootloader, kernel y drivers tempranos.

Diferencia entre rootkit y backdoor

Un mismo implante combina varias categorías. Un rootkit casi siempre incluye un backdoor (no tiene sentido ocultar acceso sin tener acceso). Un backdoor no necesita ser rootkit: una cuenta administrativa olvidada, una clave SSH residual o un servicio sin documentar son backdoors sin ningún componente de ocultación profunda.

Prevención y hardening

• Secure Boot. Bloquea la carga de bootloaders no firmados y, correctamente configurado, elimina la mayoría de bootkits UEFI conocidos. Mantener listas de revocación actualizadas (Microsoft revocó la versión usada por BlackLotus).
• Driver y kernel signing enforcement. En Windows, firma WHQL obligatoria. En Linux, kernel lockdown con lockdown=integrity o lockdown=confidentiality.
• HVCI en Windows. Hypervisor-protected Code Integrity ejecuta drivers en un contexto protegido por Hyper-V. Combinado con Credential Guard en Device Guard.
• Lockdown Mode en macOS. Modo opcional desde macOS Ventura que reduce superficie para perfiles con riesgo elevado.
• Atestación TPM. Verificación remota de que los componentes del boot coinciden con los esperados.
• Mínimo privilegio. Reducir las cuentas que pueden cargar drivers o módulos de kernel a un grupo auditado.

Encaje con MITRE ATT&CK

Los rootkits aparecen en varias técnicas de MITRE ATT&CK:

• T1014 Rootkit. Técnica explícita bajo la táctica de Defense Evasion. Cubre el uso de rootkits para ocultar artefactos del atacante en el sistema comprometido.
• T1542 Pre-OS Boot. Cubre bootkits y firmware rootkits. Sub-técnicas: System Firmware (T1542.001), Component Firmware (T1542.002), Bootkit (T1542.003), ROMMONkit (T1542.004), TFTP Boot (T1542.005).
• T1601 Modify System Image. Modificación de imágenes de sistema operativo o firmware en dispositivos de red. Sub-técnicas: Patch System Image (T1601.001), Downgrade System Image (T1601.002).

Otras técnicas frecuentemente asociadas: T1547 Boot or Logon Autostart Execution, T1556 Modify Authentication Process, T1112 Modify Registry, T1574 Hijack Execution Flow.

Si encuentras un rootkit: protocolo DFIR

Encontrar un rootkit confirmado cambia las prioridades de respuesta. Regla general: cuanto más bajo opera (firmware, bootkit, kernel), menos confiable es cualquier información obtenida desde el propio host.

1. Aislar sin apagar. Desconectar de la red para detener exfiltración y movimiento lateral, pero no apagar. La memoria es la fuente forense más valiosa.
2. Imagen forense completa. Volcado de memoria (FTK Imager, WinPmem), imagen bit-a-bit con write blocker, captura de tráfico de red reciente desde infraestructura no comprometida.
3. No confiar en herramientas del host. El análisis se hace sobre la imagen forense desde un sistema limpio. Las herramientas ejecutadas en el host comprometido pueden estar filtradas por el rootkit.
4. Reimage desde firmware si el alcance es bootkit o firmware. Reinstalar el sistema operativo no basta. El proceso correcto incluye reflasheo del firmware desde fuente confiable y, en casos sensibles, sustitución física del componente.
5. Rotación masiva de credenciales y secretos. Cualquier credencial, certificado o secreto al alcance del host se considera comprometido. Rotación completa, no parcial.
6. Threat hunting lateral. Búsqueda activa de los mismos TTPs en el resto de la flota: drivers nuevos, modificaciones de firmware, cuentas creadas, persistencia, beaconing.
7. Validación de erradicación. Telemetría reforzada durante meses, retesting, atestación TPM si está disponible y revisión de logs de red para confirmar que el patrón ha cesado.

Preguntas frecuentes

El antivirus detecta rootkits

Los antivirus modernos integran motores antirootkit y detectan familias conocidas, pero su capacidad cae cuando el rootkit opera por debajo de su nivel de ejecución. Ningún antivirus convencional cubre rootkits de firmware. La detección seria combina antivirus, EDR, memory forensics y atestación TPM.

Reimagen del sistema operativo es suficiente para eliminar un rootkit

Depende del tipo. Para user-mode y kernel-mode sin componente firmware, una reinstalación limpia desde medio confiable elimina el implante. Para bootkits UEFI, firmware y BMC hay que reflashear desde fuente verificada y, en casos serios, considerar sustitución física.

Cómo se elimina un firmware rootkit

Identificar el componente (BIOS, UEFI, NIC, controlador de disco, BMC) y reflashear con la imagen oficial del fabricante desde un equipo limpio. Validar con CHIPSEC y comparación de hashes. Si la confianza es crítica, la sustitución física aporta más certeza.

Linux es más seguro frente a rootkits que Windows

No por defecto. Linux ha tenido familias significativas (LKMs maliciosos, rootkits sobre eBPF, Symbiote, BPFDoor). La diferencia real depende de hardening: kernel lockdown, restricción de carga de módulos tras boot, IMA, AppArmor o SELinux. Un Linux endurecido es muy resistente; uno con root accesible no aporta ventaja frente a un Windows con HVCI activo.

Existen rootkits en macOS

Sí, aunque la superficie es estrecha. Las kext están en proceso de retirada, sustituidas por extensiones de sistema en espacio de usuario. System Integrity Protection y, en Apple Silicon, el sealed system volume dificultan instalar rootkits clásicos. Aun así, campañas como XCSSET o Operation Triangulation sobre iOS confirman que actores con recursos llegan a la plataforma.

Hay que notificar al regulador si encontramos un rootkit

Depende del régimen aplicable. NIS2 obliga a entidades esenciales e importantes a notificar incidentes significativos (alerta temprana en 24 horas, notificación en 72). El RGPD obliga a notificar brechas de datos personales en 72 horas si hay riesgo para los interesados. Un rootkit en sistemas con datos personales o servicios esenciales suele presumir comunicación al regulador, sujeto a análisis legal.

Recursos relacionados

• Qué es un backdoor: tipos y métodos de detección
• Qué es el kernel en ciberseguridad
• Tipos de malware: clasificación y ejemplos reales
• Qué es MITRE ATT&CK: tácticas y técnicas
• Qué es EDR: detección y respuesta en endpoint
• Qué es threat hunting: metodología y ejemplos
• Qué es Mimikatz: credential dumping y defensa

Respuesta DFIR ante rootkits con Secra

En Secra trabajamos con equipos defensivos que sospechan compromiso profundo y necesitan validar si quedan implantes a nivel kernel, bootkit o firmware. Los servicios incluyen threat hunting kernel-level sobre telemetría disponible (EDR, SIEM, atestación TPM si existe), análisis forense de memoria con Volatility, revisión de integridad de firmware con CHIPSEC y hardening post-incidente sobre Secure Boot, HVCI, kernel lockdown y atestación remota.

Si tu organización ha tenido alertas de drivers no firmados, comportamiento anómalo de bajo nivel o necesita validar que un compromiso reciente no ha dejado un rootkit residual, contacta con nosotros para una primera evaluación.