Singularity Rootkit: el desafío de Elastic Defend en entornos Linux
- El rootkit Singularity utiliza técnicas avanzadas para saltarse la detección de Elastic Defend en Linux.
- Explota la gestión de procesos confiables en eBPF para suprimir la telemetría de carga de módulos.
- Emplea fragmentación de módulos, codificación XOR y randomización de símbolos para evadir reglas YARA.
- El ataque demuestra que las exclusiones de procesos en el monitoreo del kernel pueden ser vectores críticos.
La seguridad de los sistemas Linux, piedra angular de la infraestructura de nube y de los servidores empresariales, se enfrenta a una nueva sofisticación en el desarrollo de malware. El investigador de seguridad 0xMatheuZ ha revelado el funcionamiento de Singularity, un rootkit diseñado específicamente para neutralizar las capacidades de detección de Elastic Defend, una de las soluciones de protección de endpoints más extendidas en el sector tecnológico.
El núcleo del problema reside en cómo las herramientas de detección modernas utilizan eBPF (Extended Berkeley Packet Filter) para obtener visibilidad profunda del kernel sin comprometer la estabilidad del sistema. Elastic Defend ha implementado desde la versión 8.14 un mecanismo basado en BPF para monitorizar la carga de módulos del kernel. Con la llegada de la versión 9.5, se introdujo el campo taint_flags, permitiendo que las reglas de detección identifiquen módulos no firmados o construidos externamente que pudieran contaminar el kernel en ejecución.
La vulnerabilidad en la confianza de los procesos
El éxito de Singularity no radica en un fallo de código tradicional, sino en la explotación de una característica de diseño: las exclusiones de procesos confiables. El programa eBPF de Elastic Defend, encargado de monitorizar la carga de módulos, verifica si el identificador del proceso actual (PID) se encuentra en un mapa de procesos considerados seguros antes de recolectar la telemetría.
Si el proceso que intenta cargar el rootkit es clasificado como confiable, el programa BPF finaliza su ejecución prematuramente. Esto impide la generación del evento de endpoint que alimentaría la regla de detección de taint-flag. Al suprimir esta telemetría, el rootkit logra entrar en el kernel sin que el sistema de seguridad reciba la información necesaria para evaluar si el módulo cargado es malicioso o si ha comprometido la integridad del sistema.
Un detalle técnico crítico es que el cargador de Singularity no depende de un identificador fijo para localizar el mapa de BPF, ya que estos IDs pueden cambiar cada vez que el agente de Elastic se reinicia. En su lugar, el rootkit localiza dinámicamente el mapa apropiado, asegurando que la evasión sea persistente y adaptable al entorno.
Estrategias de ocultación frente a YARA
Más allá de la manipulación de eBPF, el rootkit debe sobrevivir a los escaneos de archivos en disco. En entornos de prueba con Ubuntu y kernel 6.8, la carga de Singularity sin modificaciones generó hasta 76 alertas, la mayoría disparadas por reglas YARA que detectan patrones comunes de rootkits en el archivo .ko (kernel object).
Para neutralizar estas defensas, el investigador implementó una serie de capas de ofuscación detalladas en su repositorio de MatheuZ Security. Estas técnicas transforman el binario para que sea irreconocible para los motores de firmas tradicionales:
La primera línea de defensa es la randomización inteligente de los nombres de los símbolos. Al cambiar los nombres de las funciones y variables, el rootkit evita que las reglas YARA identifiquen patrones de funciones típicas de malware. A esto se suma la fragmentación del módulo, donde el código no se presenta como un bloque único, sino que se divide y se codifica mediante XOR. Finalmente, el uso de memfd_create permite la carga en memoria, evitando que el archivo malicioso toque el disco de forma persistente y evadiendo así el escrutinio de los escáneres de archivos.
El impacto en la observabilidad del kernel
Este caso de estudio pone de relieve una tensión creciente en la ciberseguridad: la dependencia de eBPF para la observabilidad. Si bien herramientas como Falco, Tracee o Tetragon han revolucionado la telemetría del kernel, el ataque de Singularity demuestra que el propio mecanismo de monitoreo puede ser cegado.
Cuando un rootkit logra suprimir la telemetría, el equipo de seguridad de una empresa puede ver un panel de control en verde mientras el atacante tiene control total sobre el kernel. Esta capacidad de invisibilidad es lo que convierte a los rootkits de nivel de kernel en amenazas críticas para el business continuity, ya que permiten el robo de datos y el movimiento lateral sin dejar rastro en los logs estándar del EDR.
El bypass de Elastic Defend no es solo un fallo de una herramienta, sino una advertencia sobre cómo las exclusiones de procesos en el monitoreo de eBPF pueden convertirse en objetivos primordiales para amenazas avanzadas.
Análisis técnico de la evasión
Para comprender la magnitud de la técnica, es necesario observar el flujo de ejecución que el rootkit sigue para evitar la detección conductual. No se limita a ocultar el archivo, sino que manipula la interacción entre el agente de seguridad y el kernel de Linux.
El proceso de evasión se puede resumir en el siguiente flujo operativo:
- Localización: El cargador busca el mapa de BPF de Elastic para identificar los PIDs confiables.
- Suplantación: El proceso de carga se mimetiza o aprovecha la confianza asignada para evitar la telemetría de carga de módulos.
- Ofuscación: Se aplican técnicas de XOR y fragmentación para que el módulo en memoria no coincida con ninguna firma YARA conocida.
- Ejecución: Se utilizan funciones de ftrace renombradas para evitar la detección de ganchos (hooks) en el kernel.
Este enfoque sistemático, descrito exhaustivamente en la documentación de evasión de Elastic Security, muestra que la seguridad basada en firmas es insuficiente frente a atacantes que comprenden la arquitectura interna del sensor de seguridad.
Implicaciones para la infraestructura empresarial
Para los directores de tecnología (CTO) y responsables de seguridad (CISO), la noticia de Singularity subraya la necesidad de adoptar una estrategia de defensa en profundidad. Confiar exclusivamente en un EDR, por muy avanzado que sea su uso de eBPF, crea un punto único de fallo si el atacante logra operar a nivel de kernel.
La capacidad de Singularity para evadir la detección de módulos no firmados sugiere que las empresas deben reforzar la seguridad del arranque (Secure Boot) y limitar estrictamente la capacidad de cargar módulos en servidores de producción. La monitorización no debe basarse solo en eventos generados por el agente, sino en la correlación de anomalías de rendimiento y comportamiento de red que el rootkit no pueda ocultar tan fácilmente.
La investigación publicada en GBHackers confirma que la carrera armamentista entre los desarrolladores de EDR y los creadores de rootkits se ha trasladado al plano de la telemetría. Ya no se trata de ocultar el malware, sino de manipular la percepción que la herramienta de seguridad tiene de la realidad del sistema.
Significado para las empresas en España
En el contexto español, donde la digitalización de las PYMES y la adopción de infraestructuras en la nube están aceleradas por la Agenda España Digital 2026, este tipo de vulnerabilidades adquieren una relevancia especial. El tejido empresarial español, compuesto mayoritariamente por empresas que externalizan su gestión IT, a menudo confía ciegamente en la instalación de un software de seguridad sin auditorías profundas de configuración.
La implementación del AI Act europeo también introduce un matiz importante. A medida que las empresas españolas integren IA para la detección de amenazas, estas herramientas se basarán en la telemetría proporcionada por agentes como Elastic Defend. Si la telemetría es suprimida en la fuente por un rootkit como Singularity, la IA analizará datos incompletos, generando una falsa sensación de seguridad.
Para las empresas locales, esto significa que la ciberseguridad no puede ser vista como un producto instalado, sino como un proceso de endurecimiento (hardening) del sistema. La dependencia de soluciones estándar sin una configuración ajustada a la realidad del entorno —especialmente en lo que respecta a los procesos confiables y los permisos de root— deja a las organizaciones vulnerables ante ataques dirigidos que utilicen estas técnicas de evasión de eBPF.
Preguntas frecuentes
¿Qué es exactamente el rootkit Singularity?
Es un malware avanzado para Linux diseñado para operar a nivel de kernel, capaz de evadir la detección de herramientas de seguridad como Elastic Defend mediante la manipulación de la telemetría de eBPF.
¿Cómo logra Singularity evitar que Elastic Defend detecte la carga de módulos?
Explota la lista de procesos confiables del agente de Elastic. Al hacer que el proceso de carga sea visto como confiable, el programa eBPF de seguridad deja de enviar telemetría, evitando que se disparen las alertas de módulos no firmados.
¿Qué técnicas usa para evitar que YARA encuentre el malware en el disco?
Utiliza la randomización de nombres de símbolos, la fragmentación del módulo, la codificación XOR y la carga directa en memoria mediante memfd_create para evitar dejar rastros en el sistema de archivos.
¿Están todos los sistemas Linux afectados?
El riesgo existe en sistemas que utilizan Elastic Defend (especialmente versiones 8.14 y 9.5) y donde el atacante haya logrado privilegios suficientes para interactuar con el kernel y los mapas de BPF.
Fuentes: Gbhackers, Matheuzsecurity (2) ·
glacom · Inteligencia artificial para empresas: los modelos corren en tus servidores, los datos no salen →Scrivila qui: Susanna, l assistente AI di glacom, ti risponde via email con un approfondimento gratuito.
Nessuna consulenza personalizzata (finanziaria, legale o medica): solo informazione e fonti. Email usata solo per rispondere.
oppure scrivile su: WhatsApp · Telegram · SimpleX · Delta Chat · Email
