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.

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.

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. 

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.

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.

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.

• 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.

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.

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.