Cyberpsychosis (Easy)

admin@synacklabs.github.io (SynAckLabs) — Thu, 15 Jan 2026 00:00:00 +0000

Contexto y objetivo

Cyberpsychosis es un challenge de reversing y análisis de rootkits que simula un escenario de respuesta a incidentes. Según el briefing, actores maliciosos han comprometido un sistema e implantado un rootkit personalizado. El objetivo es analizar el módulo, desactivarlo y recuperar la información oculta.

El challenge proporciona un archivo comprimido que contiene un módulo de kernel de Linux (LKM), tipo de malware utilizado para mantener persistencia con máximos privilegios y evasión de detección.

Reconocimiento inicial

Al descomprimir el archivo proporcionado, encontramos un fichero con extensión .ko: diamorphine.ko

Identificamos el tipo de archivo:

file diamorphine.ko

Se trata de un Kernel Object, es decir, un módulo de kernel cargable (LKM) para sistemas Linux. Estos módulos operan en ring 0 con privilegios absolutos sobre el sistema.

Una búsqueda inicial revela que Diamorphine es un rootkit LKM público y bien documentado, diseñado para:

Ocultar procesos del sistema
Elevar privilegios de usuarios arbitrarios
Ocultarse a sí mismo de herramientas de monitorización
Persistir en el kernel

Análisis estático

Carga en Ghidra

Cargamos el módulo diamorphine.ko en Ghidra para realizar ingeniería inversa del código. Como primer paso, inspeccionamos las strings presentes en el binario para identificar indicadores de comportamiento.

Las strings confirman la presencia de Diamorphine, mostrando referencias al proyecto original. Esto valida nuestra hipótesis inicial sobre la naturaleza del rootkit.

Documentación del comportamiento estándar

Consultamos el repositorio oficial del proyecto (https://github.com/m0nad/Diamorphine) para comprender el comportamiento esperado:

Según la documentación, el módulo responde a señales de Unix (kill) para activar funcionalidades:

Señal 31: Ocultar o mostrar un proceso específico
Señal 63: Alternar visibilidad del módulo en lsmod
Señal 64: Otorgar privilegios de root al proceso que envía la señal

El procedimiento estándar de desinstalación es:

kill -63 0 # Hacer visible el módulo
rmmod diamorphine # Eliminar el módulo (como root)

Análisis dinámico

Primer intento de desactivación

Nos conectamos al servicio remoto proporcionado:

nc <IP> <Puerto>

Aplicamos el procedimiento documentado para hacer visible el módulo y eliminarlo:

El sistema entra en kernel panic inmediatamente. Esto indica que el rootkit ha sido modificado intencionalmente y no sigue el comportamiento del Diamorphine original. La señal 63 no es la correcta en esta versión.

Identificación de la modificación

Retornamos al análisis estático. Navegamos a la función hacked_kill(), responsable de procesar las señales enviadas al módulo.

Observamos que la condición que controla la visibilidad del módulo compara contra un valor en hexadecimal. Convertimos el valor a decimal mediante clic derecho en Ghidra:

El número mágico modificado es 46, no 63 como en la versión original.

Solución: Desactivación del rootkit modificado

Con la señal correcta identificada, procedemos a desactivar el rootkit:

Hacer visible el módulo con la señal modificada:

kill -46 0

Obtener privilegios de root con la señal documentada:

kill -64 0

El rootkit ahora es visible y tenemos privilegios de root sin causar kernel panic.

Recuperación de la flag

Búsqueda en el sistema de archivos

Sabiendo que HackTheBox almacena sus flags típicamente en archivos .txt, realizamos una búsqueda recursiva en todo el sistema:

find / -name "*.txt" 2>/dev/null

La búsqueda revela la ubicación del archivo que contiene la información oculta.

Verificación final

Leemos el contenido de la flag:

cat /ruta/al/archivo.txt

Obtenemos la flag y completamos el challenge.

Conclusión

Este challenge ilustra varios conceptos críticos en análisis de malware y respuesta a incidentes:

Aprendizajes técnicos:

Los rootkits LKM operan en ring 0 y pueden interceptar syscalls arbitrarias
La función kill() puede ser hookeada para implementar backdoors mediante señales personalizadas
El análisis estático es imprescindible cuando la documentación pública no coincide con el comportamiento observado
Los rootkits modificados requieren ingeniería inversa completa, sin asumir comportamiento estándar

Técnicas aplicadas:

Análisis estático con Ghidra para identificar modificaciones en código conocido
Correlación entre comportamiento documentado y comportamiento real
Escalado de privilegios mediante funcionalidades maliciosas del rootkit

Implicaciones defensivas:

Los LKM son extremadamente difíciles de detectar una vez cargados
La verificación de integridad de módulos del kernel (module signing, Secure Boot) es crítica
Herramientas como LKRG (Linux Kernel Runtime Guard) pueden detectar hooks en syscalls
La respuesta a incidentes con rootkits requiere arranque desde medios externos confiables

RootKit on