El proyecto RVBBIT es un buen ejemplo de esta evolución. Se trata de un módulo de kernel diseñado como prueba de concepto educativa, pero que implementa múltiples técnicas de ocultación y persistencia propias de rootkits reales. Aunque ha sido “neutralizado” en cuanto a funcionalidades destructivas, conserva toda la lógica de stealth, lo que lo convierte en un caso de estudio interesante.
El diseño de RVBBIT se basa en tres pilares fundamentales. Por un lado, el uso de hooking sobre la syscall table, lo que permite interceptar llamadas críticas del sistema. Por otro, la manipulación directa de estructuras internas del kernel mediante DKOM (Direct Kernel Object Manipulation). Finalmente, el uso de resolución dinámica de símbolos mediante kallsyms y kprobes, lo que reduce la dependencia de símbolos exportados.
A esto se suman mecanismos adicionales como la desactivación temporal de protecciones de escritura en el kernel y la limpieza de indicadores de compromiso.
https://github.com/buter-chkalova/project-rvbbit
| Característica | Descripción | Estado |
|---|---|---|
| Ocultación de módulo | Se quita así mismo de /proc/modules y lsmod via DKOM. | ✅ Enabled |
| Ocultación de procesos | Oculta un proceso de minado deps y /proc. | ✅ Enabled |
| Ocultación de ficheros | Oculta ficheros con un prefijo específico del listado de directorios. | ✅ Enabled |
| Ocultación de puerto TCP | Oculta las conexiones al puerto 3333 desde /proc/net/tcp. | ✅ Enabled |
| Bypass de eBPF | Bloquea la carga de programas eBPF no firmados (anti‑detection). | ✅ Enabled |
| Persistencia | Instala un servicio systemd y una entrada modules‑load.d. | ✅ Enabled |
| Minado de criptomonedas | Payload de minado de Monero (XMR)- | ❌ REMOVED (simulated) |
| Propagación de red | Fuerza bruta SSH y gusano auto-propagado. | ❌ REMOVED |
Ocultación del módulo en el kernel
Uno de los primeros mecanismos de stealth que implementa el código es la ocultación del propio módulo cargado. Esto se realiza eliminando su entrada de las estructuras internas del kernel.
Con esto, el módulo deja de aparecer en herramientas como lsmod o en el sistema de archivos virtual /sys. No se trata de un simple filtrado en espacio de usuario, sino de una eliminación directa de las referencias internas que el kernel utiliza para enumerar módulos cargados. El renombrado posterior del módulo actúa como una capa adicional de camuflaje.
Ocultación de procesos mediante DKOM
Uno de los aspectos más relevantes del rootkit es la ocultación de procesos sin depender de hooks en syscalls como getdents. En su lugar, modifica directamente las estructuras del scheduler del kernel.
Al eliminar estas referencias, el proceso deja de formar parte de las listas internas que el kernel utiliza para gestionar y exponer información de procesos. Como resultado, el proceso desaparece no solo de /proc, sino también de herramientas como ps o top.
Este enfoque es significativamente más profundo que el filtrado en espacio de usuario, ya que afecta directamente a la representación interna del sistema operativo.
El código además introduce un mecanismo de control encubierto mediante señales. El envío de la señal 64 a través de kill permite activar dinámicamente la ocultación de un proceso concreto, actuando como canal de control oculto.
Ocultación de ficheros mediante hooking de getdents64
El rootkit también intercepta la syscall getdents64, que es la base de la enumeración de directorios en Linux.
La lógica consiste en recorrer el buffer de resultados y eliminar aquellas entradas que coincidan con un prefijo aleatorio generado en tiempo de ejecución.
Las entradas se eliminan mediante manipulación del buffer devuelto por la syscall, reajustando las estructuras internas para evitar inconsistencias.
Este mecanismo afecta directamente a herramientas como ls o find, pero no elimina los ficheros del sistema, únicamente los oculta en la capa de enumeración.
El uso de un prefijo aleatorio generado con get_random_bytes introduce un componente adicional de evasión, ya que impide la detección basada en firmas estáticas.
Ocultación de conexiones de red
Otra funcionalidad relevante es la ocultación de conexiones TCP. Para ello, el código sustituye la función tcp4_seq_show, utilizada internamente para exponer información de /proc/net/tcp.
De esta forma, cualquier conexión asociada al puerto 3333 desaparece de las herramientas de inspección de red, aunque sigue activa a nivel de kernel.
Este tipo de técnica es habitual en rootkits modernos, ya que la mayoría de herramientas de monitorización dependen de esta interfaz.
Bloqueo de eBPF como mecanismo anti-observabilidad
Uno de los aspectos más interesantes del proyecto es la desactivación de la carga de programas eBPF.
Esto impide el uso de herramientas modernas de observabilidad basadas en eBPF, como sistemas de tracing o monitorización de comportamiento en tiempo real.
Más allá de ser una técnica de evasión clásica, esto refleja una tendencia clara: los rootkits modernos no solo intentan ocultarse del usuario, sino también de los sistemas de detección basados en kernel instrumentation.
Persistencia mediante systemd y módulos del kernel
El mecanismo de persistencia combina dos niveles. Por un lado, se escribe una configuración en /etc/modules-load.d para asegurar la carga del módulo. Por otro, se instala un servicio systemd que fuerza su reinyección en el sistema.
Esto permite que el módulo se cargue automáticamente en cada arranque, incluso si ha sido descargado previamente.
Simulación de minería y comportamiento persistente
Aunque la funcionalidad original de minería ha sido eliminada, el código mantiene una simulación de proceso activo. Este proceso se oculta utilizando el mismo mecanismo de DKOM aplicado a procesos reales y se mantiene vivo mediante una workqueue periódica.
El objetivo no es funcional, sino comportamental: simular la presencia de un proceso persistente típico de cryptominers.
Limpieza de huellas y bypass de protecciones
El módulo incluye mecanismos adicionales que refuerzan su carácter evasivo. Entre ellos destaca la modificación de la variable de taint del kernel, lo que dificulta la detección de modificaciones no estándar del sistema.
También se desactiva temporalmente la protección de escritura del kernel mediante la manipulación del registro CR0, permitiendo la modificación de estructuras críticas como la syscall table.
Hipótesis de implementación: módulo de propagación SSH (worm userland)
Aunque el código de RVBBIT no incluye funcionalidad de propagación, su diseño sugiere claramente una separación entre las capacidades de stealth en kernel space y una posible capa de movimiento lateral en user space. Este patrón es coherente con la arquitectura de muchos rootkits modernos: el kernel se utiliza para ocultación y persistencia, mientras que la propagación se delega a un componente externo más flexible.
En un escenario realista, este módulo de propagación no residiría en el kernel, sino en un proceso auxiliar controlado por el propio rootkit, activado mediante triggers internos (como señales o workqueues). Su objetivo sería realizar descubrimiento de hosts, validación de credenciales SSH y despliegue del payload en sistemas remotos.
A continuación se muestra una implementación simulada y educativa, sin capacidades reales de ataque, que representa la lógica de un gusano SSH típico desde el punto de vista de arquitectura.
#include <stdio.h>#include <string.h>
#define MAX_HOSTS 8#define MAX_CREDS 3
/* Lista simulada de objetivos en red local */static const char *targets[MAX_HOSTS] = { "10.0.0.5", "10.0.0.8", "192.168.1.20", "192.168.1.30"};
/* Credenciales simuladas */static const char *creds[MAX_CREDS][2] = { {"root", "123456"}, {"admin", "admin"}, {"user", "password"}};
/* Simula comprobación de conectividad SSH */static int simulate_reachability(const char *ip) { /* Simulación: todos los hosts son alcanzables */ return ip != NULL;}
/* Simula autenticación SSH */static int simulate_ssh_auth(const char *user, const char *pass) { /* En este modelo educativo, solo una credencial es válida */ if (strcmp(pass, "123456") == 0) return 1; return 0;}
/* Simula despliegue del payload */static void simulate_deploy(const char *ip) { printf("[SSH-WORM] Simulated infection on host: %s\n", ip);}
/* Motor principal del gusano (simulado) */void ssh_worm_simulation(void) { for (int i = 0; i < MAX_HOSTS; i++) {
if (!targets[i]) continue;
if (!simulate_reachability(targets[i])) continue;
for (int j = 0; j < MAX_CREDS; j++) {
const char *user = creds[j][0]; const char *pass = creds[j][1];
if (simulate_ssh_auth(user, pass)) { simulate_deploy(targets[i]); break; } } }}En la arquitectura del rootkit analizado, este módulo no formaría parte del kernel, sino de un componente en espacio de usuario controlado indirectamente. El kernel actuaría únicamente como orquestador, activando la ejecución del gusano mediante triggers internos.
Un ejemplo de integración coherente con el código existente sería el uso del sistema de workqueue ya presente en RVBBIT:
static void demo_work_func(struct work_struct *work) {
/* lógica existente del fake miner */
if (fake_miner_pid > 0) {
struct task_struct *task;
task = pid_task(find_vpid(fake_miner_pid), PIDTYPE_PID);
if (!task)
deploy_fake_miner();
} else {
deploy_fake_miner();
}
/* extensión conceptual: activación del worm SSH */
if (ssh_worm_enabled) {
ssh_worm_simulation();
}
queue_delayed_work(demo_wq, &demo_work, msecs_to_jiffies(60000));
}if (sig == MAGIC_UNHIDE_SIG) {
ssh_worm_enabled = 1;
}RVBBIT no destaca por introducir técnicas nuevas, sino por combinar de forma coherente múltiples mecanismos clásicos de rootkits Linux con algunos elementos más modernos, como el bloqueo de eBPF o el uso de DKOM en estructuras críticas del kernel.
El resultado es un ejemplo claro de cómo un rootkit contemporáneo puede operar en varios niveles del sistema: desde la syscall layer hasta estructuras internas del scheduler, pasando por mecanismos de observabilidad y persistencia.
Más que un malware funcional, este proyecto es útil como herramienta de estudio para entender cómo se construyen las capas de ocultación en sistemas Linux modernos y qué superficies de ataque siguen siendo relevantes para detección y análisis forense.
Comentarios
Publicar un comentario