Cómo pasar del exploit automático de bugs hecho por IA a la detección de malware en nanosegundos con eBPF & Spectral Clustering

Un aviso a las 03:00. Sonaba la alerta en Grafana mientras la mitad del cluster roncaba en modo low-power. Nada extraordinario… hasta que el panel del IDS cambió de verde a rojo en menos de 200 ms. Veintisiete llamadas execve disparadas en ráfaga, seguidas del clásico combo mmap + mprotect que todo shellcode loader necesita para saltar de la página de datos a la de instrucciones.

Figura 1: Cómo pasar del exploit automático de bugs hecho por IA

a la detección de malware en nanosegundos con

eBPF & Spectral Clustering

Al revisar la traza eBPF vimos que los buffers escritos alcanzaban 7.3 bits/byte de entropía — signo inequívoco de ofuscación o compresión agresiva. La fingerprint no coincidía con ninguna firma YARA ni regla Falco. Aquello olía a malware de generación sintética, amasado por un LLM con exceso de temperatura.

Figura 2: Linux Exploiting en 0xWord

A las 03:00:27 el blue-team contuvo la amenaza: un bpf_lsm abortó el execve antes de que la burbuja llegara a task_struct. La incógnita era clara: ¿podemos repetir esa hazaña sin humanos desvelados?

El problema: ofensiva con esteroides de IA

La línea de producción de 0-days ya no es artesanal. Un agente autónomo basado en GPT-4 es capaz de explotar 87 % de vulnerabilidades one-day cuando se le da la descripción CVE, superando por paliza a escáneres clásicos y a modelos menores (0 %). Este mismo paper advierte que, sin descripción, la tasa baja al 7 %, pero la ventana entre la publicación del advisory y el parche sigue siendo mortal.

Figura 3: LLM Agents can Autonomously Exploit One-day Vulnerabilities

En el contexto del examen SLAE32, un experimento técnico publicado en 0xboku demostró cómo el shellcode polimórfico creado manualmente puede alterar hasta un 33 % de su estructura (de 108 a 144 bytes) usando registros MMX y modificaciones de instrucciones, manteniendo su funcionalidad para evadir detección. Este caso, aunque no involucra LLMs, ilustra cómo técnicas clásicas de ofuscación ya desafían firmas SHA 256 y patrones estáticos, obligando a adoptar detección basada en comportamiento o modelos de IA entrenados en entropía y anomalías de ejecución.

1.1 No basta con “parchear rapidito”

Incluso con un SLA de parches de 24 h las organizaciones quedan expuestas durante todo el ciclo virtual —release de exploit, write-up en blog, publicación del PoC—. Necesitamos detección y respuesta en tiempo real, preferiblemente antes de que los bytes maliciosos crucen la frontera usuario-kernel. 

La hipótesis: el kernel susurra en nanosegundos 

El Extended Berkeley Packet Filter (eBPF) es nuestra oreja en ring 0:

• Se carga como byte-code verificado; imposible desbordar el kernel.
• Engancha tracepoints/kprobes a cualquier syscall sin recompilar ni reiniciar.
• Copia eventos a espacio de usuario mediante ring buffer (cero copias).
• Overhead bajo: Alto rendimiento al trazar syscalls execve y mprotect en workloads OLTP.

Figura 4: Arquitectura de eBPF

2.1 Características que sí delatan a un loader

1. n-grams de syscalls (window=5): captura lógicas como open → read → mmap → mprotect → execve.
2. Entropía de payload: indica compresión/cifrado.
3. Δt entre syscalls: ciertos packers insertan “sleep-gaps” para evadir monitoreo.
4. Delta de privilegios: salto uid 1000 → 0 es red-flag.
5. Llamadas ptrace: frecuente en stagers que se inyectan en procesos confiables.

Los cinco valores se normalizan y forman un vector de 256 dimensiones que alimenta el algoritmo de Machine Learning.

Figura 5: Libro de Machine Learning aplicado a Ciberseguridad de
Carmen Torrano, Fran Ramírez, Paloma Recuero, José Torres y Santiago Hernández

El truco de magia: Spectral Clustering sin etiquetas

Mientras los IDS clásicos aprenden con datasets estáticos —y sufren cuando aparecen comportamientos inéditos— el Spectral Clustering trabaja a ciegas:

1. Construye una matriz de similitud S calculando distancia Jensen-Shannon entre histogramas de vectores (researchgate.net).
2. Obtiene el Laplaciano normalizado L = D⁻¹ᐟ² (D − S) D⁻¹ᐟ²
3. Extrae los k autovectores de menor autovalor y proyecta los puntos.
4. Aplica k-means en ese nuevo espacio.

Nota: investigamos Eigen-updates streaming, técnica que recalcula solo los autovectores afectados por un cambio local en S, logrando refrescar el modelo de 2- 3 ms sin reconstruir toda la matriz.

PoC I — portátil del blue team

Durante las pruebas iniciales quisimos demostrar que la detección basada en eBPF + Spectral Clustering cabe incluso en un laptop de respuesta rápida—el típico “equipo de guerra” que un analista lleva a un incidente.

• Tracepoint raw_syscalls:sys_enter: el programa eBPF cuenta todas las syscalls y las lanza a un ring buffer (overhead ≈ 0.7 % CPU) .

• Extractor en user-space: cada 500 ms levanta el histograma por PID y lo paddea a longitud constante.

• Cálculo de similitud: matriz RBF simetrizada + self-loops mínimos para garantizar conectividad.

• Spectral Clustering: con k = 2 → etiqueta “normal” vs “anómalo”; la decisión llega en ≈ 35 ms.

• Acción: si label == anomalía, lanzamos un hook LSM que cancela execve, e inmediatamente Grafana genera una alerta.

Figura 6: Pipeline de detección de anomalías in-kernel

con eBPF + Spectral Clustering (PoC I)

Qué aprendimos del portátil

• El ring buffer es clave: pasar a perf-event duplicaba la latencia.

• Padding + RBF: permite trabajar con huellas de procesos muy diversos (LibreOffice pesa > 300 syscalls/ventana; un curl apenas 18).

• El “modo laptop” es ideal para ofensiva inversa: llevas la detección in situ y cazas la amenaza antes de subir nada al SIEM.

PoC II — clúster K8s de producción

• DaemonSet carga el colector eBPF.

• Los vectores llegan por gRPC a un side-car que vive en el mismo node pool que OpenSearch, evitando saltos de red.

Figura 7: Arquitectura de telemetría y respuesta

en el clúster Kubernetes (PoC II)

• DaemonSet despliega el sensor en cada nodo (hostPID:true, privileged:true).

• Cilium exporta sus mapas eBPF (cilium/ebpf/v2) y nos evita duplicar sondas.

• Hubble Relay agrega eventos L4, que se fusionan con la matriz‐syscalls vía ID de contenedor.

Todos los dashboards viven en un Grafana-LOKI-Tempo stack; las alertas llegan a PagerDuty.

Correlación Hubble + syscalls — afinando el detector en microservicios ruidosos 

La tesis es sencilla, ya que los False Positives suelen aparecer cuando un microservicio legítimo realiza ráfagas inusuales de syscalls—por ejemplo, un side-car de logging que comprime registros antes de enviarlos.

Figura 8: Ensamblador X86: Teoría y Practica.

de Josué Acebedo Maldonado y Sheila A. Berta.

Si correlacionamos flujos L4/L7 de Hubble (la capa de observabilidad de Cilium) con la secuencia de syscalls del mismo container_id, obtenemos contexto de red que ayuda al modelo espectral a distinguir un backup ruidoso de un loader malicioso.

• Emparejar eventos: cada registro Hubble porta pod_uid y container_id. El extractor agrega esos campos al vector de 256 D.

• Nuevas features: dirección (ingress/egress), proto, bytes_sent y ratio packets/Δt.

• Reentrenar parcial (Eigen-update): cada 10 s para minimizar deriva.

Lecciones aprendidas

Después de estas pruebas, hemos visto como el  análisis no supervisado elimina la esclavitud de etiquetar muestras de malware. Además, el uso de eBPF permite hot-patch del sensor sin tener que reiniciar ni recompilar el kernel. En todo este proceso, el cuello de botella real es el cálculo completo de autovectores y el uso de Eigen-updates reduce la carga a la décima parte.

Figura 9: "Malware moderno: Técnicas avanzadas y su influencia en la industria"

de Sergio de los Santos en  0xWord

Además, correlacionar capa de red (Hubble) con syscalls baja los falsos positivos en escenarios de microservicios ruidosos, lo que es muy beneficioso. Por último, en todo este proceso es muy importante la UX del analista, y tener un panel que combine “Top anomalous pods” con la llamada exacta a mprotect(PROT_EXEC) ahorra 10 min de búsqueda a las 03 : 00.

Como próximos pasos en este aprendizaje, vamos a trabajar en  extender el modelo para cubrir tráfico  de los niveles L4/L7 completos. Proceder a automatizar las acciones de mitigación vía Falco + ArgoCD y explorar distancia de Wasserstein sobre los histogramas, prometedora para diferenciación fina de malware polimórfico. Además, queremos probar despliegue desde el edge en IoT (ARM64) con micro-agentes eBPF.

Autor: José Acevedo Maldonado, autor del libro Ensamblador X86: Teoría y Practica.

Contactar con José Acevedo Maldonado (neomatrix)