jueves, noviembre 20, 2025

El Benchmark de la ORCA que suspende en cálculo a ChatGPT-5 y Claude Sonnet, y aprueba por los pelos a Gemini, Grok y DeepSeek

Muchas veces he hablado del problema que tiene la "Creatividad" en los LLMs. Esto hace que tengamos Hallucinaciones, Errores, Sesgos y posibilidades de Envenenamiento de las respuestas. Cuando creas un servicio digital que utiliza un LLM tienes que contar con cómo tomar medidas para gestionar estos riesgos - además de los de Jailbreak, Prompt Injection y Desalineamiento -. Es el mundo AI-First que tenemos hoy en día.
En el estudio de hoy, titulado "The ORCA Benchmark: Evaluating Real-World Calculation Accuracy in Large Language Models" tenemos un claro ejemplo de cómo todos los modelos de frontera que tenemos hoy en día aún comenten muchos errores en el cálculo y la resolución de problemas que exigen hacer una correcta aplicación de fórmulas para calcular un resultado exacto a un problema dado.

Lo que han hecho en este experimento es testear bien, con problemas de diferentes ámbitos científicos y técnicos las capacidades de calcular resoluciones exactas de los supuestos, divididas en diferentes áreas de trabajo, para ver si aplican con exactitud los conocimientos.
Con estos problemas se busca conocer algo de lo que ya vimos con el Ratio Potenkim, donde un modelo responde bien a las preguntas que tienen que ver con el concepto de conocimiento, pero fallan en su aplicación. Por ejemplo, en este imagen hay uno de los problemas que son parte del benchmark probado.
Como podéis ver en la imagen anterior, ChatGPT-5, Claude Sonnet4.5 y DeepSeek V3.2 fallan en la precisión del cálculo, generando errores de cálculo, lo que inyectaría errores en cualquier servicio digital que tuviera que resolver un problema similar, especialmente cuanto estamos hablando de Agentic AI en la empresa para manejar finanzas, por ejemplo.
Si miramos la tabla siguiente, podemos ver como del Benchmark de ORCA, la máxima puntuación la saca Gemini 2.5 Flash con un 6.3, un "Bien" bajo, con Grok cerca y DeepSeek V3.2 aprobando con un "Suficiente" 5.2, mientras que ChatGPT-5 se queda a décimas del cinco y Claude Sonnet a medio punto del aprobado.
Si miramos los ejemplos, podemos ver que los problemas están pensados para resolver problemas de ciencia que exigen el conocimiento de las fórmulas, las unidades de medida, las conversiones entre ellas, y hacer cálculos exactos, que es lo que se necesita para utilizar estos modelos de IA en soluciones de robótica, gestión empresarial, medicina, etcétera, donde estos errores por "creatividad" que generan las "hallucinations" pueden tener un gran impacto.
Si miramos los resultados que consiguen los diferentes modelos por cada una de las áreas de estudio. En ellos vemos que DeepSeek no está para hacer medicinas y que como le dejes los componentes químicos a mano lo mismo "la lía parda". ChatGPT-5 es el peor en Health & Sport y en problemas de Estadística y Probabilidad. Sonnet el último en Física, Ingeniería, Finanzas y Matemáticas.

Los resultados no son buenos para sacar una buena nota en Selectividad, y algunos problemas cuentan con errores que son bastante claros a la hora de su resolución. En esta imagen siguiente tenemos un problema de Finanzas y Economía, donde se equivoca a la hora de calcular el interés compuesto.
Este tipo de errores en la resolución de problemas los habíamos visto también con el famoso "Ataque del Gato", donde si no le das los datos de una forma clara y limpia - es decir, haciendo Prompt Engineering a tope - el resultado es que se puede forzar el error.

Se equivoca al hacer los cálculos de finanzas.

Si miramos por tipo de error que comenten los diferentes modelos, vemos que la precisión y el error de cálculo es el error más común que comente todos los modelos. No son buenos haciendo los números finos, está claro.


En el siguiente ejemplo, lo que tenemos es un tipo de error que tiene que ver con una mala elección de la fórmula que tiene que aplicar para resolver un problema. Es decir, el fallo que comete aquí DeepSeek no es de cálculo matemático, sino de mal razonamiento a la hora de elegir la fórmula a aplicar.
En el siguiente problema, a pesar de que tiene todos los datos necesarios, ChatGPT-5 responde que no tiene datos suficientes para resolver el problema, así que es una deficiencia en el razonamiento relativo al problema expuesto.
Y el último de los problemas que os dejo - hay más en el paper académico que os recomiendo leer - tenemos un problema de estadística y probabilidades que ChatGPT no resuelve correctamente.
Todos estos errores pueden ser utilizados por un atacante para conseguir forzar un error en los cálculos que hace un sistema de manera dirigida, es decir, que no sea un error aleatorio sino un error dirigido para conseguir un determinado precio, un determinado comportamiento, o un determinado error que genere un flujo de instrucciones concreto. Un issue de lógica que puede implicar un cambio controlado por un atacante en la lógica de un programa.

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

Si te interesa la IA y la Ciberseguridad, te recomiendo este enlace todos los postspapers 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)  


miércoles, noviembre 19, 2025

"Casi Famoso" es el nuevo libro de Rafa J. Vegas... (ese que toca el bajo)

Hoy no quiero volver a hablar de Inteligencia Artificial o Ciberseguridad. Cuando se publique este artículo no sé si estaré volando o me pillarás aterrizando en Madrid, pero lo escribo desde el otro lado del planeta, aprovechando que nuestro querido Rafa J. Vegas  ha publicado un nuevo libro, llamado "Casi Famoso" y quería hablaros de él.

Figura 1: "Casi Famoso" es el nuevo libro de Rafa J. Vegas
... (ese que toca el bajo)

Ya os he contado muchas cosas de él, y os animo que lo leáis todo en el artículo que publiqué que se llama: "El Rafa al bajo: Entrevista a Rafa J. Vegas." donde le pregunté cosas a este rockero de primera que ha sido parte de la escena del Rock en España, y protagonista de mil aventuras en los camerinos, las giras. Nuestro querido Rafa J. Vegas , 


Rafa tiene la "mala" costumbre de contarnos sus cosas en forma de libros, el último de ellos el que acaba de publicar con el nombre de "Casi Famoso". En él nos cuenta más cosas de las que ha vivido en la carretera, con Rosendo, y más allá de él. Con esos momentos que solo alguien que ha tenido las vivencias de Rafa puede contar con tanto humor.

Para esta ocasión, además yo he tenido la suerte y el honor de poder escribirle uno de los textos del prólogo, donde también ha participado Jorge Martínez de Ilegales. No os publico todo el prólogo por ahora - lo dejo para otro post más adelante, que cuento muchas cosas de mi infancia en él -, pero sí que os dejo un fragmentillo, de cuando me lo "gosaba" con el air-guitar dando gotelé a las paredes de las casas.

"En aquellos años mi tesoro eran unas pocas cintas de música, y un tocadiscos que me había comprado yo con lo que iba ganando en las “chapuzas”. Nos llevábamos un radio casete a las obras, tan manchado de gotas blancas como os podéis imaginar. 
 
Eran finales de los años ochenta, casi los noventa, y yo había descubierto a Rosendo, así que me había copiado de mis amigos “heavies” del barrio del parque de bomberos de Móstoles unas cintas con “Loco por Incordiar”, y “A las lombrices”, así que mientras estaba yo pasando el viernes tarde, el sábado y el domingo entre olores de pintura, lavando los pinceles, las brochas y los rodillos, escuchaba – cuando me tocaba elegir a mí – “Por meter entre mis cosas la nariz”. 
 
Y como pasaba mucho tiempo solo en habitaciones vacías, pues me flipaba yo conmigo mismo haciendo air-guitar usando para tocar el palo extensor que se usa para pintar techos, que bien podría haber sido el palo de uno de esos micrófonos donde ponía “el Rosen” la nariz encima."

No es el primer libro que escribe Rafa, y los otros son tronchantes, ya os lo digo yo,  que además todos tienes unos títulos divertidísimos como son "Mil maneras de llegar a un hotel" y "Córtate el pelo y búscate un trabajo". Yo me los he leído y me he partido la caja de la risa. No sólo por las aventuras, sino por la forma de contarlas. 
De este segundo ya sabéis que también tengo la camiseta, y me gusta llevarla en algunos eventos - incluso en programas de televisión - porque eso que le decían a Rafa sobre el pelo y el trabajo me lo han dicho muchas veces también a mí. La vida...
Así que, si tienes que hacer un regalo a un rockero para estas Navidades, ya tienes material que comprarte. Aprovecha y píllate los libros antes de que se te echen las fechas encima, y además así apoyas a esta leyenda del Rock 'n Roll a que lo siga petando. 

Y si quieres, puedes comprarlo con tus Tempos de MyPublicInbox. Entra en tu cuenta de MyPublicInbox, ve a la sección de Tempos -> Canjear -> Vales de Tiendas, y compra el código de Casi Famoso. Nosotros canjearemos tus Tempos, compraremos tu libro y te lo haremos llegar.

Os dejaré el prólogo completo, como os he dicho, más adelante, ahora sólo lo puedes leer en "Casi Famoso".

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  


martes, noviembre 18, 2025

CoPhish: Malicious CoPilot Agent para robarte tus Tokens OAuth

Hace ya años desde que publicamos el trabajo de Sappo para robar los Tokens OAuth y liarla parda. De hecho, publicamos el paper de RansomCloud O365 creando un Ransomware que robaba tus Tokens OAuth y luego te cifraba todos los datos en la nube. Una nueva forma de ataque que ha sido desarrollada durante estos años por nuevas investigaciones, como la de DoubleDrive de la que también os hablé por aquí. Hoy quería hablaros de CoPhish, publicada por los investigadores de DataDog Security Labs que tenía esta investigación guardada en el RSS hace tiempo y no encontraba tiempo para hablaros de ella. Hoy es el día.
Cuando en el año 2016 nosotros creamos Sappo para robar tokens OAuth de servicios como Google, Office 365 o OneDrive, uno de los escenarios que exploramos fue el de crear un Ransomware que cifrara todo tu contenido en la nube. Que cifrara tus archivos de OneDrive en la nube, que cifrara tus correos electrónicos de Office365, que te dejara sin ningún contenido del que disponías.

La idea es muy sencilla. Robas un Token OAuth de una cuenta de Microsoft Office o de Microsoft One Drive, y con él accedes a todos los correos electrónicos o ficheros en la nube que tenga, y se los cifras. Eliminando los archivos originales, y solo se los devuelves descifrados sin pagan el rescate. Sencillo, y funcional.


Pero claro, Microsoft ha fortificado el entorno OAuth, y ha añadido mejoras de seguridad para el registro de aplicaciones - tanto internas como externas - y para la concesión de tokens por parte de los usuarios a estas aplicaciones, como bien se explica en el artículo.
Las mejoras se incluyeron en el año 2020, y este mismo año se añadió la opción de dejar que Microsoft decidiera quién puede o no puede conceder un Token OAuth, quedando aún algunas excepciones para usuarios administradores, y para ataques internos entre usuarios del mismo Tenant. Esto es algo que Microsoft piensa fortificar también en breve como podéis ver en el anuncio que ya ha hecho.
En cualquier caso, utilizando la plataforma de CoPilot, se puede crear una aplicación registrada tanto externa como internamente que, usando una aplicación en forma de asistente, robe los Tokens OAuth de sus víctimas con una web que ofrece toda la confianza a los usuarios. La web de Copilot para assistentes.
Si este Asistente es una web maliciosa, puede solicitar la autenticación mediante Tokens OAuth que pidan acceso excesivo a los ficheros, mensajes, calendario, etcétera. Esto, como explicamos en los artículos de Sappo, se basa en solicitar el Token OAuth con un Scope excesivo que permita hacer de todo en la identidad del usuario.
El Bot registra un Copilot Agent que pide muchos privilegios en forma de Token OAuth, y luego cuando el usuario se autentica  - en la plataforma de Bots es necesario hacerlo con un 2FA basado en un número -, el sistema generar un Token que el Malicious CoPilot Agent filtra al atacante.
En la imagen de arriba se ve cómo sería la pantalla de origen donde se solicitan los permisos cuando el asistente ha sido registrado en el mismo Tenant por un usuario interno y está atacando a un usuario interno. Y en la imagen siguiente, lo mismo, pero con una asistente registrado en un Tenant externo para atacar a los administradores - que siguen teniendo la opción por defecto de conceder Tokens OAuth -.
Al final, estos dos entornos se deben a las restricciones que por defecto añadió en 2020 y en 2025 Microsoft para reducir la superficie de exposición de los usuarios a este tipo de ataques de robo de Tokens OAuth con app maliciosas, pero como se explica al principio siguen quedando opciones para atacar a los usuarios de estas dos maneras.
En cualquier caso, la URL donde están publicadas las aplicaciones es de confianza, ya que es la URL de un dominio de Copilot de Microsoft. Y una vez que el usuario se autentique con el Bot Framework, con el token numérico, entonces ya tendremos el Token OAuth generado para compartir con el atacante.

El resto es ya lo conocido, el Malicious Copilot Agent es capaz de acceder al Token OAuth que ha sido creado como. parte del proceso de login con una cantidad de permisos que da un poder enorme a la aplicación sobre la identidad del usuario, para hacer las maldades ya conocidas.
La magia es que para hacer este Malicous CoPilot lo puedes hacer con el asistente NoCode/LowCode de Microsoft CoPilot, creando todos los flujos, y con un trigger en el proceso de Login donde se puede añadir un workflow especial para robar el Token OAuth.
Como se puede ver en la imagen siguiente, en el diseño del Workflow tenemos acceso al Token OAuth con el que se hace Sign-in, y este Token OAuth es el que se va a enviar con una petición a servidor HTTP controlado por el atacante.
Aquí se ve cómo se hace el flujo para que se haga la petición a un HTTP Server con una Key que tiene como Value el UserAccessToken. Y la URL del servidor controlado por el atacante. Ahora solo falta configurar los permisos se quieren en ese Token OAuth para permitir el acceso al Malicious CoPilot y la app para poder publicarla.
Una vez creado el asistente con los flujos, hay que registrar la app, como podéis ver en la siguiente pantalla, donde se configura la aplicación en el tenant.

El resto, es hacer las maldades que se quieran con el Token OAuth robado al usuario. Lo curioso de esta técnica es que se ha utilizado la infraestructura de Microsoft CoPilot para saltarse las restricciones contra las apps maliciosas - como las que usamos nosotros en Sappo - para robar Tokens OAuth. Muy chulo.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  


lunes, noviembre 17, 2025

CTC-1002: Antrhopic bloquea un Agentic AI creado sobre Claude hecho por ciberatacantes que hackea organizaciones completamente autónomo

Durante este año hemos ido viendo cómo el mundo de tener Agentic AI para explotación completa de organizaciones era algo que se estaba desarrollando a toda velocidad. Este año he ido siguiendo este proceso poco a poco, por medio de la publicación de un trabajo de investigación tras otro. Al mismo tiempo, los reportes de OpenAI sobre los usos maliciosos de sus productos nos han enseñado cómo iban utilizándose la IA de forma autónoma para campañas de fraude, desinformación, y fases de la intrusión de sistemas. 
Ahora Anthropic, que ya publicó en Agosto cómo los ciber-bad-actors estaban utilizando sus capacidades en forma de Vibe Coding para atacar organizaciones, nos presenta en su último informe de hace apenas unos días llamado "Disrupting the first reported AI-orchestrated cyber espionage campaign" cómo un grupo al que ha llamado CTC-1002 ha hecho el uso de las capacidades de Agentic AI para la explotación a escala de organizaciones con una arquitectura totalmente automatizada.

GTG-1002 represents multiple firsts in AI-enabled threat actor capabilities. The actor achieved what we believe is the first documented case of a cyberattack largely executed without human intervention at scale—the AI autonomously discovered vulnerabilities in targets selected by human operators and successfully exploited them in live operations, then performed a wide range of post-exploitation activities from analysis, lateral movement, privilege escalation, data access, to data exfiltration. Most significantly, this 2 marks the first documented case of agentic AI successfully obtaining access to confirmed high-value targets for intelligence collection, including major technology corporations and government agencies.

Que traducido al español para los que prefieren esta lengua dice:

GTG-1002 representa varios hitos pioneros en las capacidades de actores de amenazas potenciados por inteligencia artificial. El actor logró lo que se considera el primer caso documentado de un ciberataque ejecutado en gran medida sin intervención humana y a escala: la IA descubrió de forma autónoma vulnerabilidades en objetivos seleccionados por operadores humanos y las explotó con éxito en operaciones reales. Posteriormente, realizó una amplia gama de actividades de post-explotación, incluyendo análisis, movimiento lateral, escalado de privilegios, acceso a datos y exfiltración de información. Lo más significativo es que este caso marca la primera instancia documentada de una Agente AI que obtuvo con éxito acceso a objetivos confirmados de alto valor para la recopilación de inteligencia, entre ellos grandes corporaciones tecnológicas y agencias gubernamentales.

No es nada que no nos experabamos tras ver los trabajos de Incalmo, de Cybersecurity AI, de explotación autónoma de Web Sites o creación automática de exploits de escalación de privilegios para Linux, como ejemplo, de los que os he ido contando cosas, y que merece la pena que te los leas para entender mejor dónde estamos hoy.
El informe completo, que lo puedes y lo deberías leer, está en el siguiente enlace donde puedes ver que es apenas de 10 páginas donde resumen cuál es la arquitectura del Agentic AI construido para colarse de manera automática dentro de organizaciones.
En la arquitectura se puede ver cómo hay un Operador Humano que es el que controla al Agentic AI. Este con una arquitectura similar a la descrita por Incalmo o Cybersecurity AI, cuenta con un conjunto de MCPs que le ofrecen herramientas para todas las fases del ataque, desde la fase de reconocimiento, de descubrimiento de vulnerabilidades, de creación de exploits - con una herramienta de validación de exploits externa - de explotación de las vulnerabilidades, de elevación de privilegios, y movimientos laterales dentro de la organización. Vamos, un ataque completo.

Clic en la imagen para verla en grande

Para cada una de esas fases hay diseñado un flujo en el que hay una cierta interacción con un Operador Humano que va validando los resultados, con herramientas vía MCPs, con búsqueda de información en la web, o con la validación mediante otro modelo LLM que revisa que lo que se está haciendo es correcto. En la imagen siguiente tenéis los flujos de las diferentes fases muy bien descritos.

Clic en la imagen para verla en grande

Para entender mejor el flujo de estas fases, en el documento tienes algunos ejemplos de qué es lo que ha ido haciendo el Agentic AI en algunas situaciones. Por ejemplo, en esta tabla se ven las tareas del Agente IA para descubrir una vulnerabilidad de Server-Side Request Forgery en el backend de un Web Server, cómo generar un exploit con un payload personalizado, y solicita la revisión del Operador Humano.
Una vez que el Operador Humano aprueba la explotación, entonces ejecuta el exploit y realiza una serie de tareas de post-explotación para completar el proceso y continuar el proceso sobre los nuevos activos descubiertos.

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

En el siguiente ejemplo se ve el flujo de extracción de información de una base de datos a partir de credenciales recolectadas en el proceso de explotación de la organización. En él se puede ver cómo hace un mapa de la base de datos, extrae los hashes de las cuentas de la base de datos, identifica las más privilegiadas, crea una cuenta para tener persistencia en la base de datos, se descarga los datos, y los analiza para generar un informe final de inteligencia que es exfiltrado cuando el Operador Humano lo aprueba.

El trabajo es técnicamente perfecto, y sí, Anthropic dice que ha trabajado para acabar con las operaciones de este grupo, pero las capacidades de crear estos agentes, esta arquitectura, y estas herramientas ya existen, se conocen, están en el mercado, y han subido el nivel de las capacidades de los atacantes. Será con Claude, con GPT5.1 o con Llama 5, pero tienen estas capacidades a su alcance. Tienen el Railgun disponible, así que más vale que si trabajas como CISO te tomes en serio estas nuevas amenzas.

Como decía ayer, los equipos de Red Team, de Blue Team y los Ciberatacantes han cambiado definitivamente, así que si te interesa la IA y la Ciberseguridad, te recomiendo este enlace todos los postspapers 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)  


domingo, noviembre 16, 2025

Echogram: Bypassing Guardrails con Flip Tokens

Mientras iba en el vuelo de camino a Singapur he disfrutado de la lectura de algunos artículos que tenía marcados en el lector RSS, y uno de ellos me ha gustado mucho por lo sencilla de la idea, y los escenarios de ataque que abre. Se trata del trabajo de Echogram hecho por los investigadores de HiddenLayer.
Como hemos visto y he contado muchas veces, los modelos LLM por defecto no cuentan con muchas herramientas de seguridad por diseño. El System Prompt y la definición del contenido malicioso que hace saltar el Harmful Mode para evitar que le modelo haga algo que se no se desea es la principal media, pero hay Prompts Maliciosos y técnicas - llamadas Jailbreak - para generar esos Prompts de forma que se evite el Harmful Mode. El ejemplo que suelo contar yo de hacer que el modelo me ayude a matar a nuestro querido Brian May (ficticiamente), es un ejemplo de cómo filtrar un Prompt Malicioso saltándose el Harmful Mode haciendo un Jailbreak de las protecciones del modelo LLM.

Posts de Jailbreak
En un entorno donde tengamos una aplicación, un servicio digital o un entorno completo, un atacante va a necesitar meter los Prompts maliciosos enmascarados como datos de entrada. Estos son los casos de Prompt Injection, donde un atacante consigue meter un Prompt malicioso en un comentario, en el texto de una web, en una imagen, en un mensaje de correo electrónico, o un fichero que va a ser procesador por el modelo.

Posts de Prompt Injection
Al no tener el modelo LLM ninguna protección contra Prompt Injection - y diferenciar entre los Prompts de la aplicación o los Prompts en los datos de ejecución del Prompt -, un atacante puede lograr que se ejecute su Prompt malicioso inyectándolo en algún punto de los datos que va a utilizar la aplicación.


A los Prompts de Jailbreak que se saltan el Harmful Mode, y a la no existencia de protecciones contra Prompt Injection cuando un Agentic AI resuelve una tarea con un LLM, hay que no hay protección contra el desalineamiento, y que un modelo que esté resumiendo un correo electrónico puede acabar realizando un borrado de tus ficheros en Google Drive

Explotación de Prompt Injection con Desalineamiento
¿Qué tiene que ver la tarea de resumir correos electrónicos con borrar ficheros en un Google Drive? Nada, pero puede que se haya encontrado un Prompt malicioso en un mensaje de correo que ha pasado el filtro del Harmful Mode y ha logrado desalinear el modelo y redirigir sus tareas hacia otro función totalmente distinta de la original. Los modelos no tienen protección contra desalineamiento por diseño más allá del Harmful Mode.

A todo este escenario de Jailbreaks, Prompt Injection y Desalineamiento hay que añadir la "creatividad" del modelo, que puede llevar a las famosas "Hallucinations", a los famosos "BIAS", o los datos "Erroneos", o simplemente  como hemos visto muchas veces en trabajos como el Ratio Potemkin o el Cat Attack, y en  infinidad de otros ejemplos. 

Posts de Hallucinations, BIAS, Errores y No Determinismo
Es decir, que si generamos un servicio digital utilizando un LLM hay que preocuparse del impacto de estos cuatro grandes problemas:
  • Jailbreaks
  • Prompt Injection
  • Unalligment
  • Creativity: Hallucinations, Errors, BIAS, Indeterminismo.
Y sobre esto, tenemos que construir la tecnología. Eso quiere decir que si ponemos en producción un sistema con un LLM, hay que ponerlo con muchas protecciones. Es por eso que vemos muchos trabajos donde se trabaja en construir sistemas seguros, utilizando muchas protecciones, evaluaciones, ratios de éxito en detección, etcétera, como el caso de BlueCodeAgent hace poco donde intenta detectar generación de código vulnerable o con sesgos para atacar uno de los problemas en usar modelos automáticos para generar software. Todas esas protecciones antes y después son lo que llamamos Guardrails.

Guardrails frente a Prompt Injection, Jailbreak y Desalineamiento
Todas estas protecciones que se ponen son lo que se llaman los Guardrails, es decir, sistemas de seguridad que evalúan los datos de entrada al LLM para ver si estos son seguros y benignos o por el contrario son maliciosos. Pero también evalúan los resultados que genera el modelo e incluso las acciones que realiza, para poder saber si está haciendo lo correcto. Por ejemplo, saber si un modelo está haciendo algo mal, o está siendo atacado, se podría detectar evaluando las respuestas que da por otros modelos de lenguaje, que funcionan como jueces.
Esto es algo muy común que hemos visto en las herramientas de seguridad. Tenemos Prompt Guard o Llama Guard de Meta, o Qwen3Guard que son Clasificadores de Prompts con la única misión de saber si un Prompt puede ser malicioso o no y bloquearlo antes de que se envíe al modelo. Después, cuando el modelo entrega la respuesta, esta también es evaluada, para ver si ha sufrido algún problema y por ejemplo está entregando datos sensibles, o con sesgos, o con código peligroso, o incumpliendo alguna política de seguridad establecida. Para eso se utilizan otros modelos LLM que juzgan el trabajo, al estilo de Minority Report, para poder detectar en la respuesta que ha habido un problema que el modelo LLM que resolvió el Prompt no fue capaz de detectar.

Figura 4: Michael stabbing Elon. Un Guardrail analizaría las imágenes creadas.

Estos modelos son los que se incluyen en los LLM Firewalls por los que pasan las APIs que piden Prompts a modelos para poder implementar soluciones de Data Loss Prevention, para evitar la Exfiltración de Datos o cualquier tarea maliciosa a la que se haya convencido al modelo que tiene que hacer. Por ejemplo, en el Jailbreak de Knowledge Returning Oriented Prompt donde se conseguía hacer al modelo crear imágenes violentas, un Guardrail sería un modelo con una descripción de las imágenes generadas para ver si alguna tiene violencia, o incumple la política.


En una empresa que tiene un aplicación Web o un API expuesta que recibe datos de usuario que se van a convertir en un Prompt que se ejecuta en un modelo en el backend, cuando va a ser desplegada, debe hacerlo con Guardrails. Si lo hace en Cloudflare, la suite de AI Security clasifica los Prompts que entran en la empresa para detectar los ataques de Jailbreak en Prompt que hayan podido ser Inyectados, pero también se evalúan los datos de salida para evitar incumplimientos de políticas de seguridad, como sesgos, fugas de datos o lenguaje inapropiado. Es decir, se aplican Guardrails para la protección del modelo en el WAF (Web Application Firewall) y en el API Gateway.
Pero si por el contrario es la empresa la que utiliza un modelo externo como servicio, con una arquitectura tipo SaaS, al que sus empleados están enviando los datos, entonces en los servicios de CASB (Cloud Application Security Broker) se evalúa que ningún Prompt enviado desde los empleados está enviando datos confidenciales, ya que la fuga de información puede estar en la respuesta generada por el modelo o en los datos enviados por el cliente como contexto.
Contada toda esta larga introducción, los Guardrails son la siguiente línea que hay que proteger, y por tanto que hay que evaluar su seguridad. 

Ya vimos que saltarse los clasificadores de Prompt podría ser tan sencillo como utilizar lenguaje L33T o caracteres invisibles, por ejemplo, o codificar otras formas de texto que cambiara la clasificación del prompt, como podéis ver en la imagen anterior. Que es el objetivo de Echogram también.

Echogram: Bypassing Guardrails con Flip Tokens

Ahora los investigadores de HiddenLayer proponen con Echogram una automatización del ataque a esos clasificadores en los Guardrails basada en Tokens que cambian su evaluación, es decir, que por el entrenamiento del Clasificador en modo caja negra, se puede comprobar empíricamente que cambian la clasificación de un Prompt. Como podéis ver, en el ejemplo de la imagen, con añadir =coffee, el modelo ha ignorado el System Prompt y ha dicho algo que no diría el modelo. 
Con Echogram se ataca la protección del Guardrail que está evaluando la clasificación del Prompt, pero luego el atacante tendría que conseguir que el Prompt hiciera un Jailbreak en la detección del Harmful Mode del modelo. Esta es solo una pieza más de la cadena de defensas de un servicio digital basado en IA.
A los tokens que cambian la clasificación del Prompt les han llamado Flip Tokens, y no son los mismos para todos los Guardrails ni para todos los Prompts. Además, la adición de tokens, pueden cambiar el comportamiento del modelo con el Token, así que estos Flip Tokens deben no cambiar el comportamiento del modelo ante el Prompt modificado.
Como podéis ver, tanto con Guardrails comerciales, como con un modelo como Qwen3Guard que es OpenSource, se puede conseguir que estos Flip Tokens cambien el veredicto a positivo y el Prompt malicioso acabe pasando las protecciones.
Estas técnicas de pasar las herramientas de protección que filtran los ataques antes de llegar al modelo se suelen llamar "Técnicas de Contrabando" o "Smuggling" porque al final está pasando por la frontera de seguridad escondiendo un contenido prohibido.

Con todo este trabajo, queda también la última parte, que es hacer lo contrario. Un Prompt Benigno pasarlo a malicioso, lo que podría llevar a un ataque de Denegación de Servicio (DoS) usando un ataque de Prompt Injection para envenenar la Memory o directamente la Conversación de una víctima, y haciendo que sus comandos no pasaran por el Guardrail.

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

Los equipos de Red Team y de Blue Team han cambiado definitivamente, así que si te interesa la IA y la Ciberseguridad, te recomiendo este enlace todos los postspapers 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)  


Entrada destacada

+300 referencias a papers, posts y talks de Hacking & Security con Inteligencia Artificial

Hace un mes comencé a recuperar en un post mi interés en los últimos años, donde he publicado muchos artículos en este blog , y he dejado mu...

Entradas populares