Deteccion de Rootkits en Memoria: SSDT, IDT, DKOM y Callbacks del Kernel

Por que los rootkits son el adversario mas dificil

Un rootkit de kernel es la forma mas avanzada de persistencia que un atacante puede lograr. Operando con los mismos privilegios que el sistema operativo, un rootkit puede mentir a cualquier herramienta de seguridad que se ejecute en el mismo sistema. El antivirus pregunta al kernel "que procesos hay?" y el kernel, manipulado por el rootkit, omite los procesos maliciosos de la respuesta.

Esta es la razon fundamental por la que el analisis de memoria offline (un volcado analizado en otro sistema) es la tecnica mas fiable para detectar rootkits. El dump de memoria contiene la verdad: las estructuras del kernel tal como estan, sin la capa de mentiras que el rootkit interpone en un sistema vivo.

Arquitectura del kernel de Windows relevante

Para detectar rootkits necesitas entender las estructuras que manipulan.

SSDT (System Service Descriptor Table)

La SSDT es una tabla que mapea numeros de syscall a direcciones de funciones del kernel. Cuando un programa llama a NtCreateFile (para abrir un fichero), el numero de syscall se usa como indice en la SSDT para encontrar la direccion de la funcion KiServiceTable en ntoskrnl.exe que implementa la operacion.

En un sistema limpio, todas las entradas de la SSDT apuntan a direcciones dentro del rango de ntoskrnl.exe o win32k.sys. Si una entrada apunta fuera de estos modulos (a un driver de terceros), esa entrada ha sido hookeada.

IDT (Interrupt Descriptor Table)

La IDT mapea interrupciones y excepciones a sus handlers. Cada entrada describe que funcion se ejecuta cuando ocurre una interrupcion especifica. Un rootkit puede hookearse la IDT para interceptar interrupciones del teclado, temporizadores, o faults de pagina.

Object Manager y DKOM

El kernel de Windows mantiene listas enlazadas de objetos (procesos, threads, drivers, mutexes). DKOM consiste en manipular estas listas directamente en memoria:

• Desenlazar un EPROCESS para ocultar un proceso.
• Desenlazar un entry de la lista de drivers para ocultar un driver cargado.
• Modificar el nombre de un proceso para hacerse pasar por otro.

Callbacks del kernel

Windows permite que los drivers registren callbacks (funciones de notificacion) para eventos del sistema:

• PsSetCreateProcessNotifyRoutine: notificacion cuando se crea/termina un proceso.
• PsSetCreateThreadNotifyRoutine: notificacion cuando se crea un thread.
• PsSetLoadImageNotifyRoutine: notificacion cuando se carga una imagen (DLL/EXE).
• CmRegisterCallbackEx: notificacion de cambios en el registro.
• ObRegisterCallbacks: notificacion de operaciones sobre handles de objetos.

Un rootkit puede registrar callbacks maliciosos para interceptar y modificar el comportamiento del sistema, o puede eliminar callbacks de productos de seguridad para desactivarlos.

Deteccion de hooks en SSDT

vol -f memory.raw windows.ssdt

Este plugin muestra las entradas de la SSDT y el modulo al que pertenece cada funcion:

Index   Address            Module            Function
0x0000  0xfffff80012345678  ntoskrnl.exe      NtAccessCheck
0x0001  0xfffff80012345780  ntoskrnl.exe      NtWorkerFactoryWorkerReady
...
0x0055  0xfffff880aabbccdd  unknown           NtQueryDirectoryFile
...

En un sistema limpio, todas las funciones pertenecen a ntoskrnl.exe o win32k.sys. Una entrada con modulo "unknown" o con el nombre de un driver sospechoso indica un hook.

El hook en NtQueryDirectoryFile del ejemplo permitiria al rootkit filtrar ficheros de los resultados de busqueda: cuando un programa (o el usuario) lista un directorio, el rootkit intercepta la respuesta y elimina sus propios ficheros de la lista.

Hooks comunes de SSDT por rootkits

Funcion hookeada	Efecto del hook
NtQueryDirectoryFile	Ocultar ficheros y carpetas
NtQuerySystemInformation	Ocultar procesos
NtEnumerateValueKey	Ocultar claves de registro
NtReadFile	Modificar contenido de ficheros leidos
NtDeviceIoControlFile	Interceptar comunicaciones con drivers
NtQueryInformationProcess	Ocultar informacion de procesos

Inline hooks

Ademas de modificar la SSDT, un rootkit puede hookearse a funciones del kernel mediante inline hooking: sobrescribir los primeros bytes de una funcion con un salto (JMP) a su propio codigo. Este hook no modifica la SSDT, por lo que el plugin ssdt no lo detecta.

Para detectar inline hooks, hay que verificar que los primeros bytes de las funciones del kernel son los esperados. Algunos plugins de comunidad comparan el contenido de ntoskrnl.exe en memoria con el fichero en disco para detectar modificaciones.

Deteccion de DKOM

Comparacion pslist vs psscan

La tecnica fundamental de deteccion de DKOM:

vol -f memory.raw windows.pslist
vol -f memory.raw windows.psscan

Un proceso que aparece en psscan pero no en pslist fue desenlazado de la lista ActiveProcessLinks. Este es el indicador clasico de un rootkit que oculta un proceso via DKOM.

Verificacion de la lista de drivers

vol -f memory.raw windows.driverscan

driverscan busca estructuras de driver (DRIVER_OBJECT) por pool tag, de forma analoga a como psscan busca procesos. Comparar con la lista de drivers de modules:

vol -f memory.raw windows.modules

Un driver que aparece en driverscan pero no en modules fue desenlazado de la lista de modulos cargados. Es un driver oculto, posiblemente un rootkit.

Verificacion de integridad de listas

Volatility puede verificar que las listas doblemente enlazadas del kernel son coherentes:

• Cada elemento apunta al siguiente y al anterior.
• El anterior del siguiente apunta de vuelta al elemento original.

Si un rootkit desenlaza un elemento de forma descuidada, puede dejar punteros rotos que delatan la manipulacion.

Analisis de callbacks del kernel

vol -f memory.raw windows.callbacks

Este plugin enumera los callbacks registrados y el driver que los registro:

Type                              Callback            Module           Details
PsSetCreateProcessNotifyRoutine   0xfffff88001234000   suspicious.sys   -
PsSetCreateThreadNotifyRoutine    0xfffff88001234100   suspicious.sys   -
CmRegisterCallbackEx              0xfffff88001234200   suspicious.sys   -
PsSetCreateProcessNotifyRoutine   0xfffff80012345000   ntoskrnl.exe     -
PsSetLoadImageNotifyRoutine       0xfffff80012345100   WdFilter.sys     -

Interpretacion:

• Callbacks registrados por ntoskrnl.exe, WdFilter.sys (Windows Defender), o drivers de seguridad conocidos: normales.
• Callbacks registrados por un driver desconocido (suspicious.sys): investigar.
• Ausencia de callbacks de productos de seguridad que deberian estar presentes: el rootkit los elimino.

La eliminacion de callbacks de seguridad es una tecnica documentada en herramientas como EDRSilencer y BlackoutSEC. Si Windows Defender (WdFilter.sys) deberia tener callbacks registrados pero no los tiene, alguien los desregistro.

Analisis de drivers cargados

vol -f memory.raw windows.modules

Lista todos los modulos (drivers) cargados en el kernel:

Offset           Base             Size     Name             Path
0xfa8001234000   0xfffff80012000  0x800000  ntoskrnl.exe     \SystemRoot\system32\ntoskrnl.exe
0xfa8001234100   0xfffff88001200  0x50000   suspicious.sys   \SystemRoot\system32\drivers\suspicious.sys
0xfa8001234200   0xfffff88002000  0x10000   unknown          -

Busca:

• Drivers sin ruta o con ruta inusual.
• Drivers con nombres genericos: helper.sys, update.sys, service.sys.
• Drivers no firmados (verificar la firma del fichero extraido).
• Drivers con tamanos inusuales (muy pequenos pueden ser rootkits minimalistas).

Para extraer un driver sospechoso:

vol -f memory.raw windows.moddump --base 0xfffff88001200 --dump

El driver extraido puede analizarse con Ghidra/IDA y verificarse en bases de datos de malware.

Tecnica BYOVD (Bring Your Own Vulnerable Driver)

Una tecnica moderna que elude Secure Boot y HVCI: el atacante carga un driver legitimo y firmado que tiene una vulnerabilidad conocida, y la explota para ejecutar codigo arbitrario en modo kernel.

Drivers vulnerables frecuentemente abusados:

• RTCore64.sys (MSI Afterburner): CVE-2019-16098. Permite lectura/escritura arbitraria de memoria del kernel.
• DBUtil_2_3.sys (Dell): CVE-2021-21551. Acceso arbitrario a memoria fisica.
• gdrv.sys (GIGABYTE): multiples CVEs. Lectura/escritura de memoria.
• capcom.sys: permite ejecutar codigo en ring 0 directamente.

Para detectar BYOVD en memoria:

1. Listar drivers con windows.modules.
2. Buscar los nombres de drivers vulnerables conocidos (hay listas publicas como LOLDrivers).
3. Verificar si un driver vulnerable esta cargado pero no tiene razon de estar en el sistema.
4. Buscar procesos de usuario que tienen handles al dispositivo del driver vulnerable.

vol -f memory.raw windows.handles --object-type Device | grep -i "rtcore\|dbutil\|gdrv\|capcom"

Rootkits de firmware y bootkits

Los rootkits mas avanzados operan a nivel de firmware UEFI, antes de que el sistema operativo cargue. Ejemplos documentados:

• CosmicStrand: rootkit UEFI atribuido a un actor chino. Modifica el firmware de la placa base.
• BlackLotus: bootkit que evade Secure Boot explotando CVE-2022-21894.
• MosaicRegressor: rootkit UEFI descubierto por Kaspersky en 2020.

Estos rootkits son dificiles de detectar en un volcado de memoria del OS porque operan a un nivel inferior. Sin embargo, dejan artefactos:

• Drivers cargados en fases muy tempranas del arranque.
• Hooks en funciones criticas del kernel que se establecen antes de que los drivers normales carguen.
• Modificaciones en las estructuras del gestor de arranque en memoria.

El plugin windows.modules puede mostrar drivers que se cargaron durante el arranque temprano. El orden de carga y los timestamps pueden revelar modulos inyectados por un bootkit.

Tecnicas anti-forenses de rootkits

Eliminacion del pool tag

psscan busca estructuras por su pool tag ('Proc' para procesos). Un rootkit puede sobrescribir este tag despues de crear la estructura, haciendo que psscan no la encuentre. Contramedida: buscar estructuras EPROCESS por sus campos internos (heuristica) en lugar de por pool tag.

Manipulacion de timestamps

Un rootkit puede modificar los timestamps de sus procesos y drivers para que parezcan del arranque del sistema. Contramedida: correlacionar timestamps con logs de otros origenes (SIEM, firewall).

Cifrado de codigo en memoria

Algunos rootkits cifran su payload en memoria cuando no lo estan ejecutando activamente, descifrandolo solo para ejecutar funciones especificas. Esto dificulta la extraccion y analisis del codigo. Contramedida: multiples captures de memoria en diferentes momentos pueden capturar el codigo descifrado.

Ocultacion en regiones del kernel no escaneadas

Regiones de memoria del kernel que las herramientas estandar no escanean (como el espacio de paginas del kernel no paginadas, regiones de drivers descargados, o el espacio entre modulos) pueden albergar codigo malicioso. Contramedida: escaneo completo de la memoria fisica con YARA.

Flujo de deteccion de rootkits

1. Comparar pslist con psscan. Buscar procesos ocultos (DKOM).
2. Ejecutar ssdt. Buscar hooks en la tabla de syscalls.
3. Ejecutar callbacks. Verificar que los productos de seguridad tienen sus callbacks intactos.
4. Ejecutar modules vs driverscan. Buscar drivers ocultos.
5. Verificar drivers cargados. Buscar nombres sospechosos, drivers vulnerables (BYOVD), drivers sin ruta.
6. Ejecutar malfind en procesos del kernel. Buscar codigo inyectado en el espacio del kernel.
7. Escanear con YARA. Reglas especificas de rootkits conocidos contra toda la memoria.
8. Verificar integridad de ntoskrnl.exe en memoria vs disco. Buscar inline hooks.

Proximo paso

El siguiente articulo cambia de sistema operativo: analisis forense de memoria en Linux con Volatility 3, incluyendo perfiles, analisis de procesos, bash history, red y modulos del kernel.