Google Gemini para Gmail: Cross-Domain Prompt Injection Attack (XPIA) para hacer Phishing

El equipo de seguridad de Google Gemini for Gmail (G-Suite) ha corregido un bug de Cross-Domain Prompt Injection Attack (XPIA) que permite a un atacante hacer un ataque de Phishing solo con enviar un mensaje con un Prompt Injection escrito en "blanco sobre blanco". Así de sencillo, y así de funcional.

Figura 1: Google Gemini para Gmail.

Cross-Domain Prompt Injection Attack (XPIA) para hacer Phishing 

El bug ha sido reportado de manera responsable al equipo de Google Gemini for Gmail (G-Suite) que ha podido comprobarlo y corregirlo, y los investigadores han publicado la PoC de cómo funciona este bug, en un articulo titulado: "Phishing For Gemini".

Figura 2: Resumen del expediente de Google Gemini

G-Suite Prompt Injection Vulnerability

El bug consiste en añadir un texto escrito solo para que lo procese Gemini cuando se pida un resumen del correo. Para ello, utilizando una técnica de Prompt Injection Smuggling - como ya vimos que se usaban para saltarse los Guardrails - basada en escribir el Prompt en White on White lo que hacen es meter un comando extra en cualquier mensaje enviado que le pide que añada un texto para hacer un ataque de Phishing a la víctima.

Figura 3: PoC del Prompt Attack que se inyecta en el

mensaje de correo del atacante con style blanco sobre blanco

El mensaje queda como se puede ver en la imagen siguiente, donde no se ve el texto a no ser que se seleccione, pero para Google Gemini los colores de la fuente y del fondo son irrelevantes, así que lo procesa como si fuera parte de un comando para él.

Figura 4: Prompt Attack inyectado al final del mensaje del atacante

A partir de ese momento, solo hay que esperar a que Google Gemini, desde un comando de Google Workspace de  G-Suite reciba el comando de "Sumarize e-mail" y procese este mensaje. El resultado final es que Google Gemini envía un mensaje con el resumen y sigue el Prompt inyectado por el atacante, inyectando el texto de Phishing al final del ataque.

Figura 5: Gemini inyecta el texto de Phishing al final

Este fallo de seguridad de XPIA en Google G-Suite demuestra la necesidad de implementar algunas de las soluciones para eliminar los ataques de Prompt Injection desde el diseño, como las propuestas por los investigadores, y que podéis leer en estos artículos:

• Prompt Injection Protections: Jatmo, StruQ, SecAlign & Instructional Segment Embedding
• Google DeepMind CaMeL: Defeating Prompt Injections by Design in Agentic AI
• LlamaFirewall con PromptGuard 2, LlamaGuard 4, AlignmentCheck, CodeShield + AutoPatchBench & CyberSecEval 4

Además, el ataque es similar a los que recibieron ya Gitlab Duo o Microsoft Office 365 Copilot. En ambos casos un XPIA de libro, tal y como el que el equipo Red Team de IA de Microsoft había descrito en su taxonomía de ataques. Puedes leer sobre estos ataques en estos artículos.

• Hacking Gitlab Duo: Remote Prompt Injection, Malicious Prompt Smuggling, Client-Side Attacks & Private Code Stealing
• EchoLeak: Un Cross Prompt Injection Attack (XPIA) para Microsoft Office 365 Copilot
• Taxonomía de Fallos de Seguridad en Agentic AI: Memory Poisoning Attack con Cross-Domain Prompt Injection Attack (XPIA)

Y no van a ser ni mucho menos los últimos. Estamos comenzando a ver que cada día hay más bugs explotados gracias al uso de la IA en las plataformas, y esto no va a dejar de crecer, así que más vale que nos vayamos preparando porque la IA que nos ayuda en las Apps & Services puede ser el punto débil de toda nuestra seguridad. Veremos qué nos encontramos en el futuro.

PD: Si te interesa la IA y la Ciberseguridad, tienes en este enlace todos los posts, papers y charlas que he escrito, citado o impartido sobre este tema: +300 referencias a papers, posts y talks de Hacking & Security con Inteligencia Artificial 

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

EchoLeak: Un Cross Prompt Injection Attack (XPIA) para Microsoft Office 365 Copilot

El pasado 11 de Junio, el equipo de Microsoft parcheaba y publicaba una vulnerabilidad con un CVSS de 8.1 para su Office365 Copilot, que permitía a un atacante, sin interacción humana y remotamente, robar información confidencial de su cuenta de Office365 a la que tuviera acceso Microsoft Copilot, y ese mismo día, el equipo que la descubrió, publicó un informe más que interesante de la misma, a la que han bautizado como EchoLeak.

Figura 1: EchoLeak . Un Cross Prompt Injection Attack (XPIA)

para Microsoft Office 365 Copilot

No han publicado los Prompts de ataque, pero sí que han publicado dónde y cómo han construido el ataque completo, y es más que interesante por cómo han ido desgranando y saltándose cada una de las protecciones que tiene la arquitectura RAG que monta MSO365 Copiltot con el Graph de tus datos de tu cuenta de MS Office365.

Figura 2: Expediente de Microsoft sobre EchoLeak

El proceso completo, que como os he dicho lo ha descrito el equipo de investigación en su artículo: "Breaking down ‘EchoLeak’, the First Zero-Click AI Vulnerability Enabling Data Exfiltration from Microsoft 365 Copilot" es el siguiente.

Vector de Ataque

El vector de ataque es tan sencillo como enviar un mensaje de correo electrónico a la víctima y esperar a que sea procesado por MSO365. Para conseguir que este mensaje sea procesado desde el RAG en  peticiones que una víctima haga a su MSO365 Copilot existen dos aproximaciones distintas. La primera es enviar muchos mensajes distintos con el mismo ataque, para maximizar las probabilidades. 

Figura 3: El vector de ataque es un e-mail a la víctima con el que NO

hace falta interactuar de manera directa, sino a través de MSO365 Copilot

La segunda, que es la que ellos utilizaron es enviar un mensaje muy largo que toque muchos temas, para que salga en muchos segmentos de datos. En la imagen anterior, sin dejar los datos del Prompt de Ataque, se puede ver la estructura del mensaje.

Prompt Injection Smuggling

Una vez el mensaje está enviado, hay que saltarse los Guardarraíles de Microsoft Offce 365 Copilot. Estas protecciones son detectores de Prompts Maliciosos, que, al final, son meros clasificadores basados en modelos de Machine Learning, algo parecido a lo que hace Prompt Guard.

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

Todos los mensajes que en correos electrónicos vayan dirigidos a Copiltot directamente son detectados como maliciosos - algo que vimos como en el XPIA de GitLab Duo era usado por el atacante -, así que lo que los investigadores han hecho ha sido enviar el mensaje como si fuera al usuario, por lo que no es fácil detectar por el clasificador que es un Prompt Malicioso.

Además, no solo se envía al usuario el Prompt de Ataque, sino que además, para evitar que sea fácilmente detectado, el Prompt de Ataque indica que nunca se debe referir a este mensaje de correo ni a nada de lo que en él pone por motivos de cumplimiento regulatorio.

Flujo del Ataque

Una vez que el atacante sabe que un simple mensaje de correo malicioso con un Cross Prompt Injection Attack (XPIA) puede ejecutarse, se puede producir un Memory Poisoning, como el que vimos descrito en el artículo de: "Taxonomía de Fallos de Seguridad en Agentic AI: Memory Poisoning Attack con Cross-Domain Prompt Injection Attack (XPIA)", en este caso para conseguir que se cargue una imagen desde una URL en la que el parámetro contiene la información a exfiltrar. 

Figura 5: Flujo del ataque

Es decir, O365 Copilot tiene acceso a información sensible de la víctima en su RAG. Esa información se pone como parámetro en una URL que por GET el Prompt Injection hacer acceder al cliente de la víctima para intentar cargar una imagen. Por el camino, ha enviado al atacante el contenido sensible como parámetro GET.

Pero claro, para eso hay que conseguir en primer lugar construir un enlace que la víctima pueda hacer clic, o que se cargue un Imagen remota en el cliente, y saltarse las Content Security Policies (CSP) de los clientes de MS Office que evitan cargar imágenes desde URLs que no sean de Microsoft. Para ello, los investigadores han utilizado bugs & weaknesses conocidas en plataformas Microsoft SharePoint y Microsoft Teams. Precioso.

Construyendo Links e Imágenes on etiquetas

Para poder exfiltrar la información usando una URL que hace GET a un servidor malicioso, la forma más intuitiva es engañar al usuario para que haga clic en un enlace malicioso. 

Figura 6:  Ejemplos de formato de etiquetas que hacen imprimir el

link malicioso en O365 Cliente que funcionaron en el ataque.

Para construir estos enlaces hay que conseguir que MSO365 Copilot devuelva el enlace malicioso en el formato de etiquetas para links que usa MSO365, que tiene esta estructura.

Figura 7: Ejemplo con enlace malicioso creado por Office365 Copilot

Y esto funciona, como puede verse en la imagen anterior, donde se le pide información sobre un dato sensible, y automáticamente se ve cómo a la siguiente petición MSO365 Copilot genera un enlace que contiene los datos a robar.

Figura 8: Hacking Web Applications: Client-Side Attacks
de Enrique Rando en 0xWord

Si el usuario víctima hace clic en ese enlace, la información será exfiltrada al servidor controlado por el atacante. No es nada más que un Ataque Client-Side clásico que lleva años entre nosotros.

Figura 9: Etiquetas de carga de imágenes en Office365 

Esto mismo vale para las imágenes, donde se tiene un lenguaje de etiquetas también para decirle al cliente de MSOffice 365 que la cargue, tal y como se ve arriba, pero estas están protegidas por las Content-Security-Policies que llevan tantos años ya instauradas como protección para este tipo de ataques.

Figura 10: Dominios autorizados en la CSP para

carga automática de imágenes

En la lista anterior se ve que se puede construir la imagen pero sólo se pintará, es decir, solo se accederá de manera automática a esa URL si el domino está dentro de la lista anterior de dominios, lo que evita que se envíen datos a un dominio malicioso.

SharePoint & Teams Redirect

Para terminar de construir el ataque, y conseguir hacer un CSP Bypass, han utilizado dos URL Redirect de Microsoft SharePoint y de Microsoft Teams. Las URLs que permiten en los dominios autorizados en la CSP que cargan contenido desde otra URL son los siguientees.

Figura 11: URLs que hacen carga automática de URLs

en los dominios autorizados en la CSP

De ellos dos, la URL de SharePoint no es válida, ya que exige que el usuario autorice la carga de ese dominio con un clic, pero la URL de Microsoft Teams hacen un redirect automático, con lo que se consigue el GET con los datos exfiltrados sin que haya ninguna interacción con el usuario. Al final, el ataque gracias a saltarse las CSP y conseguir la carga automática forzada desde el XPIA hace que suba su peligrosidad a un CVSS 8.1. 

Seguridad frente Prompt Injection

Como se puede ver, de nuevo el problema es que el modelo LLM es vulnerable a técnicas de Prompt Injection, por lo que sigue siendo necesario desarrollar estos modelos con seguridad por diseño. Las propuestas de Jatmo, StruQ, SecAlign, Instructional Segment Embedding, o la iniciativa de Google DeepMind de usar CAMEL, siguen siendo más que necesarias, porque si no, esto va a ser como SQL Injeciton en el mundo pero a lo bestia, porque estamos hablando de modelos mucho más complejos y poderosos. Os dejo los artículos que hablan de las protecciones contra Prompt Injection.

• Prompt Guard: Modelo de seguridad para evitar ataques de Prompt Injection & Jailbreak en LLMs
• Llama Guard 3: Un LLM de Seguridad para proteger LLMs
• Llama 4 Security: CyberSecEval, Prompt Guard, Code Shield & Llama Guard
• Prompt Injection Protections: Jatmo, StruQ, SecAlign & Instructional Segment Embedding
• Google DeepMind CaMeL: Defeating Prompt Injections by Design in Agentic AI
• LlamaFirewall con PromptGuard 2, LlamaGuard 4, AlignmentCheck, CodeShield + AutoPatchBench & CyberSecEval 4

PD: Si te interesa la IA y la Ciberseguridad, tienes en este enlace todos los posts, papers y charlas que he escrito, citado o impartido sobre este tema: Inteligencia Artificial (Hacking & Security): Links, Posts, Talks & Papers

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Hacer un "infector" del Master Boot Record (MBR) de un PC usando Windows con ChatGPT & DeepSeek

Tenemos en la pista de salida una cosa nueva que tiene que ver con "Hacking usando IA", y quería hacer yo una prueba de ver cómo se comportan los Guardarrailes de ChatGPT y DeepSeek con un ejemplo muy sencillo, crear un programa en Windows 7 que corriendo como SYSTEM, es decir, después de haber conseguido engañar al Administrador o hacer una Elevación de Privilegios, pudiera infectar el Master Boot Record (MBR) para interceptar el control de ejecución en un nuevo ColdBoot, algo que durante muchos años fue un ataque muy común en el mundo del malware.

Figura 1: Hacer un "infector" del Master Boot Record (MBR)

de un PC usando Windows con ChatGPT & DeepSeek

Este tipo de técnicas de control de MBR no son sólo utilizadas por el mundo del malware, sino que también se han utilizado para robar las claves de descrifrado de BitLocker o cualquier otro software de cifrado de disco con técnicas de ingeniería social.

Figura 2: Hacking Windows: Ataques a sistemas y redes Microsoft 2ª Edición

escrito por Carlos García, Valentín Martín y Pablo González en 0xWord.

Se trata de conseguir arrancar el equipo, mostrarle un mensaje por pantalla al usuario y luego volver a darle el control de arranque normal al equipo, pero por el camino te llevas las claves de cifrado. Así que puedes robar las claves de BitLocker o cifrar el disco duro tú y hacer un Ransomware.

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

de Sergio de los Santos en  0xWord

En cualquiera de los dos casos, se pueden hacer cosas muy malas si controlas el MBR, porque has roto el Root-of-Trust del arranque de un equipo, así que cuando le pido esto a ChatGPT, como podéis ver en la imagen siguiente no me deja ni de broma

Figura 4: En ChatGPT salta el Harmful Mode

Había que probar no solo pidiéndoselo directamente, sino haciendo un poco de malabares con la petición a ver si se lo tomaba mejor, pero nada de nada, como veis por aquí.

Figura 5: No cuela ni de broma sin Prompt Injection

No me apetecía hacer el ataque de Prompt Injection a ChatGPT, que además, ya sé que si quiero esto se lo puedo pedir a WhiteRabbitNeo, como vimos en el artículo que os publiqué hace unos días, ya que ahí no existe el Harmful Mode.

Figura 6: El Prompt en WhitRabbitNeo

Y aquí está el código en lenguaje Ensamblador (ASM), listo para que lo puedas compilar y tener el programa que necesitas para machacar el Master Boot Record de los Windows 7 corriendo como SYSTEM provisto por WhiteRabbitNeo.

Figura 7: El asm para sobrescribir el MBR

Pero como lo que yo quería era ver cómo se comportaban los modelos de Deep Reasoning ante este problema para ver la calidad del código que generan, me fui a DeepSeek v3 DeepThink R1 y le pedí lo mismo, y como podéis ver tuve sorpresa.

Figura 8: En DeepSeek v3 DeepThink R1 no salta ninguna protección

En la imagen se ve que estuvo de "Thougth Time" algo así como más de cinco minutos y medio, y yo pensaba que al final iba a saltar el Guardarraíl o el Harmful Mode, pero nada, todo perfecto, y me hizo el código para el MBR, tal y como veis a continuación.

Figura 9: El código para el MBR

También añadió el código del "Infector" para ejecutar desde la máquina como SYSTEM en un Windows 7, todo muy bien apañado, por cierto.

Figura 10: El código para infectar el MBR desde Windows 7

Para dejarme al final las instrucciones de uso muy bien apañadas, en una bonita explicación clara de su uso y de las cosas que se podrían hacer para mejorarlo.

Figura 11: Instrucciones y... ¿necesitas más ayudar?

Llama la atención que DeepSeek v3 DeepThink R1 no tenga estas restricciones, la verdad, pero a lo mejor es simplemente que han decidido no ponerle puertas al campo, aunque está claro que estoy hablando de "infectar" en el Prompt. Curioso.

Figura 12: Máxima Seguridad en Windows Gold Edition
de Sergio de los Santos en 0xWord.

Al final, es sólo una curiosidad, pero está claro que la Inteligencia Artificial de hoy en día va a estar al servicio de hacer cosas malas, sí o sí, y que no podemos vivir a espaldas de esta realidad, así que más vale que nos preparemos para un entorno cada vez más virulento de ataques más elaborados.

PD: Si te interesa la IA y la Ciberseguridad, tienes en este enlace todos los posts, papers y charlas que he escrito, citado o impartido sobre este tema: Inteligencia Artificial (Hacking & Security): Links, Posts, Talks & Papers.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

WhiteRabbitNeo un LLM (y un "ChatGPT") para el Red Team

El uso de LLMs en el mundo del hacking y el pentesting es algo habitual, pero tener que lidiar con los Guardarraíles y los detectores de Harmful Mode obligan a tirar de técnicas de Prompt Smuggling, Prompt Injection & Jailbreak para poder conseguir el objetivo, pero también tenemos algunos modelos como WhiteRabbitNeo, que es un LLM para que cargues en tu Ollama, para que lo uses en tu propio software de Pentesting & Hacking, o para que lo uses en su versión web - tipo ChatGPT - para hacer trabajos en el Red Team o en los equipos SecOps sin ninguna censura.

Figura 1: WhiteRabbitNeo un LLM (y un "ChatGPT") para el Red Team

Tienes diferentes modelos de WhiteRabbitNeo directamente disponibles en Hugging Face, así que te lo descargas, lo instalas en tu Ollama - por ejemplo - y listo, ya puedes usarlo a tu gusto para hacer lo que quieras.

Figura 2: WhiteRabbitNeo en Hugging Face

Como puedes ver tienes diferentes modelos, con diferentes versiones y con diferentes tamaños, así que puedes elegir el que mejor se adapte a tu equipo, a tu software, o a tus necesidades para el Red Team. Sabiendo que cuando lo descargues no habrá censura en lo que le pidas.

Figura 3: El Red Team de la empresa
de Eduardo Arriols en 0xWord.
Cómpralo con Tempos de MyPublicInbox.

Para probarlo, veamos un ejemplo muy sencillo, donde le voy a pedir a ChatGPT que me ayude a hacer un programa para reemplazar el MBR de un PC desde un Windows 7 donde tengo permisos de System, para hacer un ataque de ColdBoot, meter un Ransomware, o lo que me plazca, pero lo que obtengo es que los Guardarraíles, analizando el código de salida, han bloqueado la petición.

Figura 4: Los Guardarraíles de ChatGPT bloquean el código

En este caso no se ha tratado del Harmful Mode, porque como se observa es un error al analizar los datos de salida - tampoco ha saltado el Guardarraíl de detección del Prompt, pero el caso es que no me ha dado la respuesta que quería.

Figura 5: Versión web de WhiteRabbitNeo

Si se lo pedimos ahora la versión web de WhiteRabbitNeo el mismo Prompt, vamos a encontrar que no hay ningún control de Harmful Mode ni ningún Guardarraíl que bloquee ni el Prompt ni la respuesta que vamos a recibir.

Figura 6: El Prompt en WhitRabbitNeo

Y aquí está el código en lenguaje Ensamblador (ASM), listo para que lo puedas compilar y tener el programa que necesitas para machacar el Master Boot Record de los Windows 7 corriendo como SYSTEM.

Figura 7: El asm para sobrescribir el MBR

Podemos hacer un ejemplo ahora con un mensaje de Spear Phishing para atacar a Chema Alonso, y me generar un mensaje muy interesante para invitarme a una convención de Marvel Comics, así que voy a caer seguro. Eso sí, veis que le ha dado una Hallucination y me ha mandado a 2023... tengo que afinar el Prompt.

Figura 8: Automatizar campañas de Spear Phishing

Si le pedimos ahora que nos haga la web para robar las credenciales simulando ser la CON de cómics, vemos que también nos lo genera, y podemos probarlo en nuestro sitio. Como podéis ver en el Prompt no hay problemas por dejar claro que es un Spear Phishing, o un malware, o lo que quieras.

Figura 9: Haciendo la web de Phishing

Aquí le tenemos robándome las credenciales, aunque hay que hacerle un poco más de Vibe Coding a esta web para que quede más chula - eso os lo dejo a vosotros- que para escribir este artículo ya me vale con este ejemplo tan sencillo.

Figura 10: Web de Phishing creada por WhiteRabbitNeo

Lo que sí que no tiene es un entrenamiento con exploits. Si recordáis, hace tiempo os hable de 0Dai, una iniciativa de Luis Javier Navarrete Lozano, que por desgracia fue discontinuada, donde se podían pedir directamente exploits - como el de EternalBlue -, pero es porque ellos habían hecho una arquitectura más compleja para tener los exploits.

Figura 11: El Agente de Exploits de 0Dai generaba exploits

En el caso de WhiteRabbitNeo no tenemos los exploits, pero tú puedes descargarte la base de datos de exploits que quieras, y hacerte una arquitectura RAG con ellos para que cuando le pidas una exploit concreto, te lo pueda hacer.

Figura 12: El exploit lo pones tú. Necesitamos una RAG

Mi consejo es que te lo bajes, lo pruebes, y vayas viendo cómo le puedes sacar partido, porque los Red Team Copilots son y van a ser herramienta fundamental en el trabajo del día a día. ¿Usas tú otro modelo diferente? compártenoslo en los comentarios o en el chat público de El lado del mal en MyPublicInbox.

PD: Si te interesa la IA y la Ciberseguridad, tienes en este enlace todos los posts, papers y charlas que he escrito, citado o impartido sobre este tema: Inteligencia Artificial (Hacking & Security): Links, Posts, Talks & Papers.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

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)