Rootkit

Todas las herramientas de seguridad le hacen preguntas al sistema operativo: enumera los procesos, enumera los ficheros, enumera las conexiones. Un rootkit interfiere en la respuesta. En espacio de usuario engancha las funciones de librería que llama una aplicación, de forma que un proceso concreto se filtra de la lista antes de que la aplicación llegue a verlo. En espacio de kernel engancha los manejadores de llamadas al sistema, manipula directamente objetos del kernel para que un proceso quede desenlazado de la lista que enumera el sistema mientras se sigue planificando, o carga un controlador que filtra en una capa más baja.

Hay dos distinciones que conviene tener bien porque se mezclan a menudo. Un rootkit esconde más que a sí mismo: de lo que va es de ocultar los procesos, ficheros, conexiones de red y cuentas del operador. Y un rootkit corre dentro del sistema operativo. El código que corre por debajo, en la cadena de arranque o en el firmware, es un bootkit, que es otro mecanismo con otra defensa.

La suposición defensiva que se rompe es que se puede confiar en que una herramienta que corre en el equipo describa ese equipo. Una vez subvertido el kernel, las respuestas son las respuestas del atacante, y un agente de endpoint que le pregunta a ese kernel está recibiendo mentiras de aquello de lo que depende.

Las plataformas modernas han hecho el caso del kernel bastante más difícil, no imposible: la firma de controladores, la protección de parches del kernel, la integridad basada en virtualización y el arranque seguro suben el coste, así que hoy una ruta común es abusar de un controlador legítimamente firmado pero vulnerable para conseguir acceso al kernel, en vez de cargar uno hostil. Los rootkits de espacio de usuario siguen siendo perfectamente practicables y no necesitan acceso al kernel, y por eso es falso decir que la detección siempre exige forense fuera de línea: es cierto para los implantes de nivel kernel y no para el resto.

La detección, por tanto, viene de fuera del engaño. Comparar lo que informa el equipo con lo que observaron la red y el hipervisor, examinar una imagen de memoria adquirida desde fuera y arrancar desde un medio aparte son los enfoques que funcionan, junto con la telemetría de EDR capturada antes de que la subversión hiciera efecto.

No instalamos ninguno en un encargo de cliente. Donde importa es en el análisis forense y en el consejo de erradicación: si hay algún motivo para sospechar subversión a nivel de kernel, el sistema afectado se reinstala en vez de limpiarse, y la evidencia se recoge de una forma que no dependa de las respuestas del propio sistema. En un ejercicio de red team la pregunta equivalente es más sencilla y más útil, y es si el cliente puede ver lo que hizo de verdad un proceso cuando ese proceso dice la verdad.