Un grupo de investigadores ha mostrado un rootkit para Linux llamado Singularity que consigue pasar inadvertido frente a Elastic Security EDR, algo que pone de relieve limitaciones relevantes en la detección a nivel de kernel. Esta prueba de concepto no es mera teoría: combina técnicas de ofuscación y evasión para reducir a cero señales que normalmente delatarían a un módulo malicioso.
El hallazgo preocupa a equipos de seguridad europeos, también en España, porque Elastic suele activar más de 26 alertas ante rootkits convencionales, y en este caso no han saltado. La investigación, publicada con fines educativos por 0xMatheuZ, evidencia que los métodos basados en firmas y patrones quedan cortos ante adversarios que refinan su ingeniería.
Cómo burla a Elastic EDR: técnicas clave de evasión
La primera baza de Singularity es la ofuscación de cadenas en tiempo de compilación. Fragmenta literales sensibles (por ejemplo, «GPL» o «kallsyms_lookup_name») en trozos contiguos que el compilador C recompone automáticamente, evitando que escáneres como YARA encuentren cadenas maliciosas continuas sin sacrificar funcionalidad.
En paralelo aplica aleatorización de nombres de símbolos. En lugar de identificadores predecibles como hook_getdents o hide_module, adopta etiquetas genéricas con prefijos que imitan al propio kernel (sys, kern, dev), difuminando el rastro de funciones sospechosas y desarmando reglas de detección basadas en nombres.
El siguiente movimiento es la fragmentación del módulo en piezas cifradas que se reensamblan solo en memoria. Los fragmentos se codifican con XOR y un cargador usa memfd_create para evitar restos en disco; a la hora de insertarlo, recurre a llamadas al sistema directas (incluida finit_module) mediante ensamblador inline, esquivando envoltorios de libc que muchos EDR vigilan.
También camufla auxiliares de ftrace: funciones típicamente monitorizadas (como fh_install_hook o fh_remove_hook) se renombran de forma determinista con identificadores aleatorios, manteniendo su comportamiento pero rompiendo firmas de Elastic orientadas a rootkits genéricos.
En el plano conductual, los investigadores evitan reglas para shells reversos escribiendo primero el payload a disco y ejecutándolo con líneas de comandos “limpias”. Además, el rootkit oculta de inmediato los procesos en ejecución mediante señales específicas, complicando la correlación entre eventos y actividad real.
Capacidades del rootkit y riesgos para entornos europeos
Más allá de la evasión, Singularity incorpora funciones ofensivas: puede ocultar procesos en /proc, esconder archivos y directorios asociados a patrones como «singularity» o «matheuz», y disimular conexiones TCP (por ejemplo, en el puerto 8081). También habilita escalada de privilegios mediante señales personalizadas o variables de entorno, y ofrece un backdoor por ICMP capaz de activar shells remotas.
El proyecto añade defensas anti-análisis, bloqueando trazas y sanitizando registros para reducir el ruido forense. El cargador se compila de forma estática y puede operar en ubicaciones menos vigiladas, reforzando una cadena de ejecución en la que el módulo completo nunca pisa el disco y, por tanto, el análisis estático se queda sin material.
Para las organizaciones en España y el resto de Europa que dependen de Elastic Defend, el caso obliga a revisar reglas de detección y fortalecer la supervisión a bajo nivel. La combinación de ofuscación, carga en memoria y syscalls directas revela una superficie donde los controles basados solo en comportamiento no capturan el contexto del kernel.
Los equipos SOC deberían priorizar el monitoreo de la integridad del kernel (por ejemplo, validación de LKMs y protecciones contra carga no autorizada), incorporar forense de memoria y correlación de señales eBPF con telemetría del sistema, y aplicar defensa en profundidad que mezcle heurística, listas blancas, hardening y actualización continua de firmas.
En entornos críticos, conviene endurecer políticas para reducir la superficie de ataque: limitar o desactivar la capacidad de cargar módulos, reforzar políticas de capabilities (CAP_SYS_MODULE), vigilar el uso de memfd_create y validar anomalías en nombres de símbolos. Todo ello, sin depender en exclusiva de EDR, sino combinando múltiples capas de control y comprobaciones cruzadas.
El caso Singularity pone de manifiesto que, frente a adversarios que perfeccionan su ofuscación, los defensores deben evolucionar hacia técnicas de análisis más profundas y orquestadas. La detección fiable de amenazas en el kernel pasa por sumar integridad, memoria y correlación avanzada a los EDR para reducir puntos ciegos y elevar el listón de la resistencia.