Panorama: al árbitro no se le pregunta si hace trampa#

Un rootkit es malware que se especializa en una sola cosa: ocultar su presencia obteniendo acceso a una capa del sistema igual o más baja que aquella donde corren las herramientas que lo buscarían. La palabra viene del mundo Unix —el conjunto de utilidades («kit») que le daban a un intruso el control de la cuenta root— pero su definición operativa es más precisa y más incómoda: un rootkit no evade la detección, la subvierte desde adentro. Cuando el administrador de tareas pregunta qué procesos corren, es el sistema operativo quien responde; si el rootkit vive en el sistema operativo, controla la respuesta. Se le está preguntando al árbitro si hace trampa, y el árbitro es el tramposo.

Esto vuelve al rootkit un problema categóricamente distinto del resto de P5. Contra un implante en espacio de usuario, el defensor y el atacante compiten en el mismo plano y la telemetría es confiable. Contra un rootkit de kernel, la telemetría es el campo de batalla: la lista de procesos, la tabla de conexiones, el enumerado de módulos —todo lo que un agente de endpoint lee para decidir si hay algo malo— pasa por estructuras que el rootkit puede reescribir. Por eso este capítulo no empieza por «qué reglas escribir» sino por una pregunta previa: ¿desde dónde se observa un sistema que miente sobre sí mismo?

P5 ya respondió esa pregunta dos veces, en dos superficies, y este capítulo se apoya explícitamente en ambas en lugar de repetirlas. El forense de memoria (5.5) mostró la técnica de vista cruzada en Windows: un proceso que un rootkit desenlazó de la lista del kernel sigue apareciendo cuando Volatility escanea la memoria física buscando la firma de las estructuras (psscan frente a pslist), porque el rootkit manipuló la lista pero no pudo borrar el objeto. La detección de persistencia en Linux (5.10) llevó el mismo principio al otro sistema operativo —dos caminos hacia el mismo dato, uno de los cuales el rootkit olvidó cubrir— y estableció la regla de erradicación: un rootkit de kernel confirmado no se limpia, se reinstala desde medio limpio.

Lo que ninguno de los dos alcanza es lo que este capítulo añade, y que justifica un capítulo propio:

  • La escalera de profundidad completa, incluyendo el peldaño que está por debajo del kernel y que 5.5/5.10 no tocan: el firmware. Los bootkits residen en la UEFI, se ejecutan antes que el sistema operativo y sobreviven al formateo del disco y a la reinstalación limpia que 5.10 daba por remedio suficiente.
  • El vector de entrada al anillo 0 que domina hoy: BYOVD (Bring Your Own Vulnerable Driver), cargar un driver legítimo y firmado pero vulnerable para llegar al kernel sin escribir un rootkit nuevo. Es un vector rico en telemetría y con una contramedida concreta.
  • La arquitectura de integridad de kernel de Windows —DSE, PatchGuard, HVCI/VBS, Secure Boot— que es, para las capas más profundas, la única defensa que gana, porque convierte la detección-después-del-hecho en prevención.

El hilo que ordena todo es un principio de punto de observación: contra un rootkit, la detección confiable tiene que venir desde una capa más baja o exterior a la que el rootkit controla —memoria adquirida sin intervención del host, el hipervisor por debajo del kernel, el hardware que mide el arranque— o de una inconsistencia que el rootkit no logró cubrir en todos los caminos a la vez. Y cuanto más profundo vive el rootkit, más se inclina la balanza de la detección hacia la prevención.

flowchart TB
    A["Herramientas del host en vivo
Task Manager · agente EDR · lsmod"]
    A -->|"confían en"| B["Espacio de usuario · anillo 3
rootkit de userland: hooking de IAT/inline"]
    B -->|"confía en"| C["Kernel · anillo 0
rootkit de kernel: DKOM · SSDT · IRP hook"]
    C -->|"confía en"| D["Firmware · UEFI
bootkit: LoJax · BlackLotus · MoonBounce"]
    D -->|"confía en"| E["Hardware · raíz de confianza · TPM"]
    V1["Vista cruzada
dos caminos al mismo dato"] -.detecta.-> C
    V2["Memoria/disco offline
+ hipervisor · HVCI/VBS"] -.observa desde abajo.-> C
    V3["Arranque medido + TPM
attestation · PCR"] -.mide desde el hardware.-> D
    style C fill:#7f1d1d,color:#fff
    style D fill:#7f1d1d,color:#fff

La escalera de profundidad: dónde vive un rootkit#

Los rootkits se ordenan por la capa que comprometen, y esa capa determina a la vez su poder, su durabilidad y la única vía por la que se los puede ver. La escalera baja del anillo 3 al silicio.

Userland (anillo 3). El rootkit más superficial engancha las funciones de biblioteca o la tabla de importaciones de otros procesos para filtrar lo que estos ven: intercepta la enumeración de archivos para ocultar el suyo, la de procesos para ocultar el propio. En Linux es el patrón LD_PRELOAD / /etc/ld.so.preload que la persistencia en Linux (3.14) desarrolló, y su detección —comparar ls contra una lectura directa del directorio— vive en 5.10. Tiene un límite estructural que lo condena: solo miente a los procesos que cargan la biblioteca enganchada; un binario enlazado estáticamente o una syscall directa lo ven todo, y por eso el rootkit «serio» baja un escalón. Este capítulo no vuelve sobre esta capa salvo para situarla: es el peldaño donde la detección todavía es fácil.

Kernel (anillo 0). Es el rootkit clásico y el que da nombre al problema. Un rootkit de kernel no le miente a un proceso, le miente al kernel entero, y por tanto a todo lo que corre encima. En Windows su arquitectura es casi siempre dual: un componente en modo usuario despliega la carga y le envía órdenes mediante DeviceIoControl, mientras un driver en modo kernel ejecuta las operaciones privilegiadas. Esa dualidad es en sí un rasgo detectable —un proceso de usuario conversando por IOCTL con un driver recién cargado y sin firmar es anómalo— pero exige haber puesto los sensores antes de que el driver se oculte. Las técnicas que ejecuta una vez dentro (DKOM, hooking de la SSDT, filtros de IRP) se tratan más abajo por su valor de detección, no por su mecánica ofensiva.

Firmware / UEFI: el bootkit. Aquí está el peldaño que 5.5 y 5.10 no alcanzan, y el que convierte a los rootkits en el extremo de la escalera de persistencia que la post-explotación en Windows (3.18) y 3.14 recorrieron. Un bootkit compromete la UEFI (Unified Extensible Firmware Interface), el firmware que inicializa el hardware y carga el sistema operativo. Al residir en la memoria flash SPI de la placa —fuera del disco lógico— y ejecutarse antes que el sistema operativo, un bootkit sobrevive al formateo del disco, a la reinstalación del sistema y hasta al reemplazo del disco duro: la reinstalación desde medio limpio que 5.10 daba por erradicación garantizada no lo toca. Los casos reales marcan la progresión: LoJax (2018, atribuido a APT28) fue el primer bootkit UEFI observado en la práctica, reutilizando un módulo antirrobo legítimo; MoonBounce y MosaicRegressor lo refinaron; y BlackLotus (2023) fue el primero en derrotar Secure Boot en sistemas parcheados, explotando CVE-2022-21894 (Baton Drop) para neutralizar la verificación de arranque. El bootkit es, literalmente, un rootkit que se instala por debajo del único árbitro que quedaba.

Hipervisor. El peldaño teórico más bajo: un rootkit que se inserta como hipervisor por debajo del sistema operativo, degradándolo a huésped virtual sin que este lo perciba (las pruebas de concepto Blue Pill y SubVirt de mediados de los 2000). Fuera de la investigación no es una amenaza corriente —el costo y la fragilidad son altos— pero define el fondo conceptual de la escalera: siempre hay una capa más baja, y quien la posee ve a las de arriba sin ser visto.

La entrada al anillo 0: el problema de la firma y BYOVD#

Para que exista un rootkit de kernel, primero tiene que ejecutarse código en el kernel, y Windows moderno lo pone difícil. La DSE (Driver Signature Enforcement, exigencia de firma de controladores) obliga, en las ediciones de 64 bits, a que todo driver que se cargue esté firmado por un certificado de confianza. Esa barrera empujó toda la técnica ofensiva hacia tres formas de rodearla, y las tres tienen firma de detección propia.

flowchart LR
    A["Ejecutar código en el anillo 0"] --> B{"Driver Signature
Enforcement (DSE)"}
    B -->|"certificado robado"| C["Firmar el driver propio
HermeticWiper: cert de Hermetica Digital"]
    B -->|"explotar un bug de kernel"| D["Kernel exploit → 3.21"]
    B -->|"BYOVD"| E["Cargar un driver firmado
pero vulnerable
FudModule: Dell CVE-2021-21551"]
    C --> F["Código ejecutando en el kernel"]
    D --> F
    E --> F
    F --> G["DKOM · SSDT/IRP hook
desactivar el EDR · ocultar artefactos"]

Certificado robado. Si el atacante controla una clave de firma de código válida, firma su propio driver y la DSE lo acepta. El wiper HermeticWiper, desplegado contra objetivos en Ucrania en 2022, ilustra el patrón con un matiz: no firmó un rootkit nuevo, sino que instaló un driver legítimo de gestión de particiones (bpdr.sys, del producto EaseUS) firmado con un certificado robado a la empresa Hermetica Digital Ltd., y luego, mediante el privilegio SeLoadDriverPrivilege, ordenó a ese driver válido sobrescribir directamente los sectores del disco. La lección de detección es que la firma no es una garantía de benignidad: un certificado robado convierte al mecanismo de confianza en cómplice, y la vigilancia tiene que mirar el comportamiento del driver, no solo su firma.

Explotar un bug de kernel. La vía que la explotación de kernel (3.21) desarrolló en detalle: encontrar una vulnerabilidad en un componente que ya corre en el anillo 0 y usarla para ejecutar código propio. Es la más costosa de las tres y la que 3.21 cierra.

BYOVD: el vector dominante. La forma que domina el panorama actual precisamente porque la DSE encareció las otras dos. En vez de escribir y firmar un rootkit, el atacante trae consigo un driver de un fabricante reconocido —firmado, de confianza, y por tanto aceptado por la DSE— que contiene una vulnerabilidad conocida, y lo usa como proxy para leer y escribir la memoria del kernel enviándole comandos por DeviceIoControl. El rootkit FudModule, operado por el grupo Lazarus, cargó un driver de Dell afectado por CVE-2021-21551 y a través de él desactivó los mecanismos defensivos del kernel, abriendo paso a las etapas posteriores. El ransomware BlackByte abusó de un driver de MSI AfterBurner para inhabilitar los agentes de EDR antes de cifrar —el mismo objetivo que la evasión de EDR (5.8) persigue desde el usuario, aquí logrado desde el kernel, que es la posición desde la cual apagar un sensor no tiene defensa por encima—.

BYOVD es el vector con mejor detección y mejor prevención de todo el capítulo, y por eso conviene subrayarlo. Del lado de la detección, la carga de un driver deja rastro: el evento de Sysmon 6 (driver load) y los registros de Microsoft-Windows-Kernel-PnP capturan qué driver se cargó, con qué firma y desde qué ruta —la señal que la telemetría y el SIEM (5.2) enseñó a reenviar—. El proyecto comunitario LOLDrivers (Living Off The Land Drivers, loldrivers.io) mantiene el catálogo de controladores firmados pero vulnerables conocidos, con sus hashes; cotejar cada carga contra esa lista convierte «se cargó un driver» en «se cargó un driver que aparece en el catálogo de abuso». Del lado de la prevención, la respuesta es la lista de bloqueo de drivers vulnerables de Microsoft, que se trata en la sección de arquitectura porque es el ejemplo más claro de que, para esta capa, prevenir vence a detectar.

Cegar al forense: el rootkit contra las herramientas en vivo#

Antes de pasar a la detección conviene entender por qué la inspección en vivo del host comprometido no es de fiar, porque de ahí sale toda la disciplina de adquisición del resto del capítulo. Un rootkit de kernel no se limita a ocultarse: activamente ciega las herramientas que lo buscarían.

El mecanismo canónico en Windows es el hooking de IRP (I/O Request Packet, el paquete con que el sistema encapsula toda petición de entrada/salida a un dispositivo). Toda lectura de un archivo, todo acceso a disco, viaja como un IRP a través de una pila de drivers. Un rootkit registra un filter driver —un módulo interpuesto en esa pila— y reemplaza la función que atiende el código IRP_MJ_CREATE, el que se dispara al abrir un objeto. El espécimen Autochk hizo exactamente esto: alteró la tabla de funciones de FLTMGR.SYS (el gestor de filtros del sistema) e insertó su propio manejador, de modo que cualquier intento de una herramienta forense de leer sus archivos en disco se redirigía a un bucle controlado por el rootkit. La herramienta pide leer el módulo malicioso y el rootkit le contesta «no existe».

La consecuencia es directa y gobierna todo lo que sigue: una herramienta forense que corre sobre el host comprometido le pregunta al rootkit, y el rootkit responde. Ejecutar Autoruns, un antivirus bajo demanda o un enumerador de módulos sobre un sistema con un rootkit de kernel activo produce un resultado limpio que no significa nada. La única inspección confiable es la que no pasa por el sistema operativo comprometido: memoria adquirida sin su intervención, disco leído desde otro sistema, arranque medido desde el hardware. El resto del capítulo es, en el fondo, el catálogo de esos puntos de observación exteriores.

Un barrido «limpio» hecho con herramientas en vivo sobre un host donde se sospecha un rootkit de kernel es el peor resultado posible: no un error, sino un falso negativo con apariencia de análisis completo. Es el mismo patrón que 5.8 advirtió para el sandbox mal endurecido —el sistema produce el resultado que el adversario quiere—, llevado a su forma más aguda, porque aquí quien miente no es la muestra sino el propio sistema operativo que ejecuta el análisis. Ante la sospecha fundada, la primera decisión no es «qué herramienta corro» sino «desde qué punto de observación adquiero».

La detección: desde abajo o desde afuera#

Establecido que al host no se le puede preguntar, la detección se organiza por punto de observación, del menos al más confiable. Los dos primeros peldaños ya los construyó P5 y este capítulo los cita en lugar de rehacerlos; el aporte propio son los dos últimos.

Vista cruzada sobre el host (funciona hasta que el rootkit cubre los dos caminos). El principio que 5.5 y 5.10 desarrollaron: enumerar un mismo hecho por dos rutas —una que el rootkit envenena, otra que olvidó cubrir— y comparar. En Windows es pslist (recorre la lista enlazada del kernel, que el rootkit manipula con DKOM, Direct Kernel Object Manipulation: desenlaza el bloque EPROCESS reescribiendo sus punteros flink/blink) frente a psscan (escanea la memoria física buscando la firma de los objetos EPROCESS, que siguen ahí); la divergencia es el proceso oculto. La detección Windows del hooking de la SSDT (System Service Descriptor Table, la tabla de punteros a las funciones del sistema que un rootkit sobrescribe para desviar llamadas como NtReadFile) también vive en 5.5, con el plugin que compara la tabla contra sus valores esperados. La versión Linux de todo esto —el rootkit LKM que se desenlaza de lsmod, la comparación de caminos— es 5.10. El límite de la vista cruzada es que corre sobre el host vivo: un rootkit que cubre ambas rutas, o que engancha al propio motor de la herramienta, la derrota. Es un buen primer paso, no una garantía.

Memoria y disco adquiridos desde afuera. El punto de observación que sí es confiable, y la razón por la que 5.5 es el capítulo hermano de este. Un volcado de memoria física adquirido sin la cooperación del sistema operativo —desde el hipervisor que hospeda la máquina virtual, con un dispositivo de adquisición por DMA, o tomando una instantánea de la VM— es un objeto estático que el rootkit ya no controla: puede haber mentido mientras corría, pero no puede reescribir un volcado que se está tomando por debajo de él. Sobre ese volcado, el arsenal de Volatility que 5.5 detalló —psscan/psxview para el proceso oculto por DKOM, la verificación de la SSDT, el enumerado de callbacks y de manejadores de IRP para el hooking de filtros, malfind para el código sin archivo de respaldo— produce resultados que el host en vivo no podía dar. La regla práctica: ante un rootkit sospechado, la máquina se apaga de forma controlada tras un volcado adquirido de la manera menos intrusiva posible, no se «revisa» encendida. Y el disco se lee arrancando desde medio externo, precisamente para saltar el hooking de IRP que cegaría una lectura en vivo.

PatchGuard: el vigilante que el propio kernel lleva dentro. Windows de 64 bits incluye KPP (Kernel Patch Protection, comercialmente PatchGuard), un mecanismo que verifica periódicamente la integridad de estructuras críticas del kernel —la SSDT, la GDT/IDT, ciertas rutinas del propio núcleo, la lista de módulos— y, si detecta que fueron modificadas, detiene el sistema con un bugcheck 0x109 (CRITICAL_STRUCTURE_CORRUPTION). Es importante encuadrarlo bien: PatchGuard no previene la modificación, la castiga después de que ocurrió, y de forma probabilística (sus comprobaciones son irregulares para dificultar que el rootkit las esquive). Para el defensor, un bugcheck 0x109 recurrente en un host es un indicador de alta fidelidad de manipulación del kernel —es el sistema delatando su propia corrupción— y merece tratarse como un incidente, no como una caída de driver cualquiera. Los rootkits modernos, por su parte, dedican esfuerzo considerable a operar sin gatillarlo (evitando tocar lo que PatchGuard vigila, o desactivándolo desde una posición de kernel ya conseguida), lo que convierte al 0x109 en una señal valiosa cuando aparece pero no en una red que atrape todo.

Arranque medido: la única forma de ver un bootkit. Contra el peldaño de firmware, ninguna herramienta del sistema operativo sirve —el bootkit ya corrió y se ocultó antes de que el sistema existiera—. La detección tiene que anclarse en el hardware. El arranque medido (Measured Boot) hace que cada componente de la cadena de arranque calcule el hash del siguiente antes de cederle el control y lo registre en los PCR (Platform Configuration Registers) del TPM (Trusted Platform Module, el coprocesador de seguridad de la placa). El resultado es una cadena de mediciones que ningún componente puede falsificar retroactivamente, porque cada uno midió al que vino después. Mediante atestación remota (remote attestation), un servidor de confianza compara esas mediciones contra los valores esperados: si un bootkit se insertó en la cadena, las mediciones divergen y el host se marca como no confiable antes de admitirlo en la red. Es el mismo principio de punto de observación llevado a su conclusión: para ver la capa más baja, la medición tiene que venir del hardware, que es la única capa que el bootkit no controla.

La prevención que gana: mover el árbitro por debajo del kernel#

Para las capas superficiales, detectar alcanza. Para el kernel y el firmware, la conclusión honesta del capítulo es que la prevención vence a la detección, porque un adversario que ya reside en el anillo 0 posee al árbitro que tendría que delatarlo. La estrategia que gana no es cazar mejor dentro del kernel, sino negar la entrada al kernel y mover la verificación de integridad a una capa que el kernel no pueda alcanzar.

HVCI / VBS: el árbitro baja al hipervisor. La pieza central es la VBS (Virtualization-Based Security, seguridad basada en virtualización): Windows usa el hipervisor para crear un dominio de confianza aislado, más privilegiado que el propio kernel, donde ejecuta las funciones de seguridad más sensibles. Sobre esa base, HVCI (Hypervisor-Protected Code Integrity, integridad de código protegida por el hipervisor) hace que la decisión de qué código puede ejecutarse en el kernel la tome el hipervisor, no el kernel. La consecuencia es exactamente el principio de punto de observación hecho arquitectura permanente: el árbitro que verifica la integridad del kernel ya no vive en el kernel, vive por debajo, en una capa que un rootkit de anillo 0 no puede modificar. Un rootkit que consiga ejecutarse ya no puede inyectar código sin firmar ni parchear páginas de código protegidas, porque quien las gobierna está fuera de su alcance. Es la misma VBS que sostiene Credential Guard —el aislamiento de los secretos de LSASS que el volcado de credenciales (4.5) identificó como contramedida—: una vez que se acepta mover una función crítica por debajo del kernel, se la puede usar tanto para proteger credenciales como para proteger la integridad del código.

La lista de bloqueo de drivers vulnerables: la respuesta a BYOVD. HVCI habilita la aplicación de la lista de bloqueo de controladores vulnerables de Microsoft (Microsoft Vulnerable Driver Blocklist), que impide cargar los drivers firmados-pero-vulnerables conocidos —los mismos que cataloga LOLDrivers—. Es la contramedida directa al vector dominante: si el driver que el atacante quiere traer está en la lista, no carga, y todo el ataque BYOVD se cae en el primer paso. Conviene tenerla activada y actualizada (durante años estuvo desactivada por defecto o con una lista congelada, un hueco real), complementada con WDAC (Windows Defender Application Control) para políticas de driver más estrictas en entornos que lo permitan.

Secure Boot + DBX: la respuesta al bootkit. Contra el firmware, Secure Boot verifica la firma de cada componente de la cadena de arranque antes de ejecutarlo, cerrando la puerta por la que entra un bootkit. Su punto débil es que depende de que no haya bootloaders firmados y vulnerables —exactamente el problema que BlackLotus explotó—, y la respuesta es la DBX (la base de datos de revocación de Secure Boot): cuando se descubre un componente de arranque firmado pero abusable, Microsoft publica una actualización de la DBX que lo revoca. La actualización de la DBX que neutralizó a BlackLotus es el caso testigo, y también la advertencia: mantener la DBX al día es parte de la higiene de arranque, no un detalle. Sobre Secure Boot se apoyan el arranque medido y la atestación de la sección anterior.

Controlar quién entra al anillo 0. Por debajo de la arquitectura, la higiene clásica: restringir quién posee SeLoadDriverPrivilege, vigilar la creación de servicios de tipo kernel (los drivers se instalan como servicios de arranque), y mantener la telemetría de carga de drivers —Sysmon 6, Kernel-PnP— reenviada al SIEM para que un driver inesperado, sin firma o presente en el catálogo de abuso dispare una alerta. Para la capa de userland, Sysmon 7 (image loaded) captura la carga de DLL desde rutas anómalas, la señal del hooking de biblioteca.

Postura: negar el punto de observación#

Lo accionable, ordenado de la prevención a la detección, porque ese es el orden en que conviene invertir contra esta amenaza:

  • Activar la integridad de kernel basada en hipervisor. HVCI/VBS convierte al hipervisor en el árbitro de la integridad del kernel: es la defensa estructural contra el rootkit de anillo 0 y la que hace irrelevante buena parte de la caza posterior. Donde el parque de drivers lo tolere, es la primera decisión.
  • Aplicar y actualizar la lista de bloqueo de drivers vulnerables. Es la respuesta directa a BYOVD, el vector dominante; cotejar además las cargas de driver contra el catálogo LOLDrivers. Sin esto, un driver firmado y vulnerable es una puerta abierta al kernel.
  • Anclar el arranque en el hardware. Secure Boot activo con la DBX al día, arranque medido con TPM y atestación remota: la única familia de controles que ve —y frena— un bootkit, contra el que la reinstalación no sirve.
  • Instrumentar la carga de drivers y de servicios de kernel. Sysmon 6 y Kernel-PnP al SIEM, alerta sobre driver sin firma, driver en el catálogo de abuso, o creación de servicio de tipo kernel; restringir SeLoadDriverPrivilege. Es la telemetría que 5.2 dejó disponible, aplicada a esta superficie.
  • Tratar el bugcheck 0x109 como incidente. CRITICAL_STRUCTURE_CORRUPTION recurrente es PatchGuard delatando manipulación del kernel: es un indicador de alta fidelidad, no una caída de driver más.
  • Adquirir desde afuera, siempre. Ante un rootkit sospechado, no inspeccionar el host en vivo: volcar la memoria por la vía menos intrusiva (hipervisor, instantánea de VM, DMA), leer el disco desde medio externo, y aplicar sobre el volcado el forense de memoria de 5.5. El host comprometido no es un testigo confiable de sí mismo.
  • Erradicar según la profundidad. Un rootkit de kernel confirmado se reinstala desde medio limpio, como fijó 5.10; un bootkit exige además reflashear el firmware o reemplazar el hardware, porque el formateo no lo alcanza. La profundidad del rootkit define el costo de la limpieza.

El hilo que une todo es el que abrió el capítulo: a un rootkit no se le pregunta si está, porque posee el árbitro que respondería. La defensa efectiva no es una mejor pregunta sino un mejor punto de observación —por debajo o por afuera de la capa que el rootkit controla— y, para las capas más profundas, un diseño que le niegue esa capa de entrada. Contra el adversario que se instala en el anillo 0 o en el firmware, ganar la partida es no dejarlo entrar; y donde ya entró, verlo solo desde una posición que él no pueda tocar.

Referencias#

  • blue-dfir/evasive-malware/cap-15 — introducción a los rootkits: arquitectura dual (proceso de usuario + driver de kernel vía DeviceIoControl), carga hostil (elusión de la DSE, certificado robado, BYOVD), DKOM sobre EPROCESS (flink/blink), hooking de la SSDT (NtReadFile), interceptación de IRP con filter drivers (IRP_MJ_CREATE, FLTMGR.SYS), bootkits de UEFI, y las defensas de Windows (PatchGuard, Secure Boot). Casos: HermeticWiper (bpdr.sys, certificado de Hermetica Digital), FudModule/Lazarus (Dell CVE-2021-21551), BlackByte (driver de MSI AfterBurner), Autochk (FLTMGR.SYS).
  • 5.5 · Forense de memoria — la vista cruzada en Windows (pslist frente a psscan, verificación de la SSDT, malfind, enumerado de callbacks e IRP) sobre un volcado que el rootkit ya no controla. Es el capítulo hermano: la detección Windows detallada vive allí.
  • 5.10 · Detección de persistencia en Linux — la detección de rootkits de userland y de kernel en Linux (dos caminos al mismo dato, /sys/module, verificación desde fuera) y la regla de erradicación (reinstalar desde medio limpio).
  • 3.14 y 3.18 — el rootkit como el extremo de la escalera de persistencia, del LD_PRELOAD de userland al kernel; la cara ofensiva del mecanismo.
  • 3.21 — el kernel exploit como vía de entrada al anillo 0 alternativa a BYOVD, y el puente que este capítulo cierra.
  • 5.8 — la desactivación del EDR desde el usuario, cuya versión desde el kernel (BYOVD) no tiene defensa por encima; y 5.2, la telemetría de carga de drivers.
  • LOLDrivers (loldrivers.io) — catálogo comunitario de drivers firmados pero vulnerables conocidos, con hashes, para cotejar cargas y alimentar la lista de bloqueo.
  • Documentación de Microsoft — Virtualization-Based Security (VBS) e Hypervisor-Protected Code Integrity (HVCI); Microsoft Vulnerable Driver Blocklist; Secure Boot y actualizaciones de la DBX (incluida la de BlackLotus); Measured Boot y atestación con TPM.
  • MITRE ATT&CK — T1014 (Rootkit); T1547.006 (Boot or Logon Autostart Execution: Kernel Modules and Extensions); T1542 (Pre-OS Boot), .001 (System Firmware) y .003 (Bootkit); T1068 (Exploitation for Privilege Escalation, vía BYOVD/kernel exploit); T1562.001 (Impair Defenses: Disable or Modify Tools, la desactivación de EDR desde el kernel); T1601 (Modify System Image). Mitigaciones M1046 (Boot Integrity), M1051 (Update Software), M1038 (Execution Prevention), M1026 (Privileged Account Management).