Escapes eBPF: Cuando tu herramienta de monitoreo se convierte en el rootkit definitivo 🕵️

En el panorama de 2026, el kernel de Linux ya no es un simple guardián estático; es un campo de juego dinámico y programable. En el centro de esta transformación está eBPF (extended Berkeley Packet Filter). Antes una herramienta modesta para filtrar paquetes de red, eBPF ha evolucionado hasta convertirse en la “superpotencia” de la observabilidad, redes y seguridad en la nube. Alimenta las mallas de servicios más avanzadas del mundo, firewalls de alto rendimiento y monitores de sistema profundo.

Sin embargo, como dice el viejo adagio de seguridad: con gran poder viene gran explotabilidad. Mientras herramientas legítimas como Cilium, Tetragon y Pixie usan eBPF para proteger clústeres, ha surgido una nueva generación de “Escapes eBPF”. En 2025 y principios de 2026, los investigadores han visto un aumento en rootkits basados en eBPF—programas maliciosos que aprovechan el bytecode “verificado y seguro” del kernel para ocultar archivos, robar credenciales y redirigir tráfico con casi total invisibilidad.

Este artículo explora la mecánica de los rootkits eBPF, las vulnerabilidades en el verificador de eBPF y cómo tu herramienta de monitoreo más confiable podría ser justo lo que te ciega ante una intrusión.

1. La arquitectura del control: por qué eBPF es el arma perfecta

Para entender cómo eBPF se convierte en un rootkit, hay que comprender por qué fue construido. Tradicionalmente, cambiar el comportamiento del kernel requería escribir un Kernel Module (LKM). Esto era peligroso; un solo error podía hacer que todo el sistema se colapsara (un “Kernel Panic”).

eBPF cambió esto al introducir una Máquina Virtual sandbox dentro del kernel. Permite a los desarrolladores:

• Escribir código en un lenguaje restringido similar a C.
• Verificar seguridad mediante un “Verificador eBPF” que asegura que el código no tenga bucles infinitos ni acceda a memoria ilegal.
• Compilar Just-In-Time (JIT) el código en instrucciones nativas para un overhead casi nulo.
• Adjuntar a hooks como syscalls, tracepoints o eventos de red.

La perspectiva del atacante

Para un atacante, eBPF es superior a los rootkits tradicionales por tres razones:

Persistencia sin reinicios: los programas eBPF pueden cargarse y descargarse dinámicamente.

Seguridad ante detección: las herramientas tradicionales EDR (Endpoint Detection and Response) buscan archivos o procesos sospechosos. Los programas eBPF viven en el espacio de memoria del kernel, dejando a menudo ninguna huella en el disco.

Camuflaje legítimo: dado que muchas herramientas de seguridad (como Falco o Datadog) usan eBPF, un programa malicioso puede esconderse fácilmente en el ruido de sondeos legítimos del kernel.

2. Armando el hook: cómo los rootkits eBPF manipulan la realidad

Un rootkit eBPF no rompe el sistema; distorsiona su percepción. Al enganchar funciones críticas del kernel, un atacante puede cambiar lo que el sistema operativo reporta al usuario.

A. Ocultando archivos y procesos (el hook getdents64)

La forma más común de ocultar un rootkit es enganchar la syscall sys_getdents64. Es la función que el kernel usa para listar archivos en un directorio.

El ataque: Cuando ejecutas ls o ps, el kernel llama a getdents64. Un programa eBPF malicioso (adjunto mediante un hook fexit o kretprobe) intercepta la lista de archivos antes de que llegue al espacio de usuario.

El resultado: el programa eBPF escanea la lista, identifica nombres de archivos o PIDs asociados con el malware y los elimina del buffer. El usuario ve un directorio “limpio”, mientras el malware sigue en ejecución a simple vista.

B. Redirección de red (XDP y hooks TC)

eBPF opera en el nivel XDP (eXpress Data Path)—el punto más bajo en la pila de red, antes de que el paquete llegue al firewall de Linux (iptables/nftables).

El ataque: rootkits como LinkPro (descubierto a finales de 2025) usan XDP para escuchar “Paquetes mágicos”. Son paquetes TCP especialmente diseñados (por ejemplo, tamaño de ventana o número de secuencia específicos) que actúan como un “Wake-on-LAN” para el malware.

El resultado: el rootkit puede interceptar tráfico C2 (Comando y Control) y descartar los paquetes para que nunca aparezcan en tcpdump o Wireshark. También puede redirigir tráfico a un proxy oculto, exfiltrando datos sin que la pila de red local se entere de la conexión.

C. Robo de credenciales (Uprobes y PAM)

Los atacantes pueden usar uprobes (Probes a nivel usuario) para enganchar funciones dentro de bibliotecas compartidas como libpam.so (el Módulo de Autenticación Pluggable de Linux).

El ataque: herramientas como Pamspy enganchan la función pam_get_authtok.

El resultado: cada vez que un usuario escribe una contraseña para sudo, ssh o inicio de sesión local, el programa eBPF captura la contraseña en texto claro y la almacena en un eBPF Map (una estructura de datos residente en el kernel) para que el atacante la recupere después.

3. Rompiendo el “Bouncer”: cómo el bypass del verificador eBPF

Lo único que separa a un desarrollador de un error que pueda arruinar el kernel es el Verificador eBPF. Es el “bouncer” del kernel, realizando análisis estático para garantizar la seguridad de la memoria. Sin embargo, el verificador es un software complejo, y como todo software, tiene bugs.

La vulnerabilidad find_equal_scalars

En una auditoría de seguridad importante en 2024 por parte del NCC Group, los investigadores identificaron fallos lógicos en cómo el verificador rastrea los valores “scalar” (enteros).

El exploit: un atacante puede escribir un programa eBPF que use operaciones bitwise complejas (AND, OR, XOR) para engañar al verificador y hacerle pensar que un registro contiene un valor seguro (por ejemplo, de 0 a 64), cuando en realidad contiene un valor grande (por ejemplo, una dirección de memoria).

La escapatoria: una vez engañado el verificador, el compilador JIT produce código que permite al programa eBPF leer y escribir memoria arbitraria del kernel. Esto es el “Santo Grial” para un atacante, convirtiendo un programa sandbox en un exploit completo del kernel.

Fallos lógicos vs. abuso de funciones

No todos los escapes eBPF requieren una “vulnerabilidad”. Muchos aprovechan las propias funciones auxiliares del kernel. Por ejemplo, bpf_probe_write_user es una función legítima usada por depuradores para modificar memoria. Un atacante puede usar esto para inyectar un usuario “root” en el buffer /etc/passwd mientras se lee por el proceso de login, sin tocar realmente el archivo en disco.

4. La brecha de visibilidad: por qué la seguridad tradicional es ciega

¿Por qué tu herramienta EDR de alto costo no puede encontrar estos rootkits? La respuesta está en la Brecha de Visibilidad.

Característica	Malware tradicional	Rootkit eBPF
Huella en disco	Archivos binarios en /usr/bin o /tmp	Solo en memoria del kernel
Logs de syscall	Visible en auditd o syslog	Engancha las funciones de logging
Tráfico de red	Visible en iptables y tcpdump	Interceptado en nivel XDP/controlador
Detección	Firmas/Hashes de archivos	Ejecución de bytecode “sin firma”

En 2026, la mayoría de los EDRs aún se enfocan en el espacio de usuario. Monitorean árboles de procesos y modificaciones en archivos. Sin embargo, un rootkit eBPF es un “fantasma en la máquina”. No crea un proceso nuevo; simplemente cambia cómo se comportan los procesos existentes.

Si preguntas al kernel, “¿Hay un proceso llamado ‘backdoor’?”, el kernel (que ahora está bajo control del rootkit) simplemente dice, “No.”

5. Estudio de caso: La epidemia LinkPro 2025

El ejemplo más sofisticado de una escapatoria eBPF hasta la fecha es LinkPro, un rootkit descubierto en octubre de 2025 dirigido a clústeres Kubernetes alojados en AWS.

Acceso inicial: los atacantes explotaron una vulnerabilidad en un servidor Jenkins (CVE-2024-23897) para obtener acceso inicial.

Despliegue: en lugar de una shell estándar, desplegaron una imagen Docker maliciosa que contenía módulos eBPF.

Hookeo en el kernel: LinkPro cargó dos módulos. Uno engancha sys_bpf—la syscall usada para cargar otros programas eBPF. Esto permitió al rootkit ocultar su presencia de herramientas como bpftool.

C2 sigiloso: el rootkit permaneció inactivo hasta que recibió un paquete “Magic TCP SYN” con un tamaño de ventana específico (54321). Solo entonces abría un shell reverso, haciendo imposible detectarlo mediante escaneo de puertos estándar.

LinkPro demostró que eBPF no es solo una herramienta para persistencia local; también es una herramienta para movimiento lateral en la nube.

6. Cómo defender tu kernel en 2026

Si el verificador puede ser bypassed y los hooks pueden ocultarse, ¿hay esperanza para los defensores? Sí, pero requiere un cambio de “Seguridad Legada” a “Seguridad Consciente del Kernel”.

1. Endurecimiento de la configuración del kernel

La primera línea de defensa es restringir quién puede cargar programas eBPF.

Desactivar BPF no privilegiado: asegúrate de que kernel.unprivileged_bpf_disabled = 1 esté activado. Esto impide que usuarios no root carguen código BPF.

Limitar capacidades: usa las capacidades de Linux para garantizar que solo servicios específicos (como tu agente de monitoreo) tengan CAP_BPF y CAP_PERFMON.

2. Monitoreo de integridad en tiempo de ejecución (Tetragon y Tracee)

Irónicamente, la mejor forma de luchar contra un rootkit eBPF es con mejor eBPF. Herramientas como Tetragon (de Cilium) usan eBPF para monitorear el estado del kernel.

Aplicación de firmas: en 2026, muchas organizaciones han adoptado programas eBPF firmados. El kernel está configurado para cargar solo bytecode BPF que ha sido firmado criptográficamente por una autoridad confiable (como el equipo de seguridad).

Integridad BTF: monitorear los datos BPF Type Format (BTF) puede revelar cuando un rootkit ha modificado estructuras del kernel para ocultar sus mapas.

3. Enumeración forense

Los equipos de seguridad deben realizar “Instantáneas del kernel” regularmente.

bpftool: usa bpftool prog show para listar todos los programas cargados. Si hay programas sin nombre o PID, investiga inmediatamente.

Forense en memoria: en entornos de alta seguridad, análisis de memoria a nivel hipervisor (usando herramientas como Volatility 3) puede identificar programas eBPF que engancharon sys_bpf para ocultarse de bpftool.

4. Vigilancia de “Paquetes mágicos”

Los firewalls modernos deben configurarse para buscar “Valores de encabezado anómalos”. Los rootkits eBPF a menudo usan flags TCP no estándar o tamaños de ventana para activarse. La IA conductual en los firewalls de 2026 ahora está específicamente sintonizada para detectar estos paquetes “de baja frecuencia y alta intención”.

7. Conclusión: La dualidad del kernel moderno

A medida que avanzamos en 2026, la batalla por el kernel de Linux solo se intensificará. eBPF es una tecnología de “dual uso” clásica—un avance para rendimiento y observabilidad que también funciona como la caja de herramientas definitiva para actores sofisticados.

Para las organizaciones, la conclusión es clara: no puedes confiar en lo que no puedes verificar. Si dependes de eBPF para tu monitoreo y seguridad, también debes asegurar el subsistema eBPF. La misma herramienta que te da “visión de rayos X” en tus contenedores puede, si se compromete, convertirse en una venda que oculta un depredador en tu núcleo.

¿Tu kernel es programable? Sí. Pero la pregunta es: ¿quién está haciendo la programación?