LLMJacking: Cómo los cibercriminales usan Tokens IA que pagas tú.

Llevo tiempo hablando el abuso de las cuentas y servicios de los modelos LLM que utiliza una empresa por parte de atacantes y cibercriminales, pero cada vez parece que está más industrializado y escalado. De esto habla el informe del equipo de Google Threat Intelligence Group titulado: "The Rise of LLMJacking: How Threat Actors Monetize Compromised Cloud and Model Resources" donde recoge las técnicas de LLMJacking como una de las más utilizadas hoy en día por los cibercriminales.

Figura 1: LLMJacking. Cómo los cibercriminales usan Tokens IA que pagas tú.

El objetivo es el mismo del que os hablo muchas veces, cómo conseguir que un LLM que paga otro - ya sea en un modelo SaaS en una plataforma de Cloud, en una API, o por medio de computo GPU en servidores locales, acabe trabajando para el atacante gratis. Eso es lo que quieren los ciberciminales, que paguen las víctimas sus Tokens AI.

Figura 2:"Hacking IA: Jailbreak, Prompt Injection, Hallucinations & Unalignment"

escrito por Chema Alonso con la colaboración de Pablo González, Fran Ramírez, Amador Aparicio, Manuel S. Lemos y José Palanco en 0xWord

Para conseguir esto existen muchas técnicas, distintas, y todas les son válidas. La primera de ella, y más evidente, es robar las cuentas de los proveedores de Cloud que tienen servicios de LLM, o las cuentas de los Servicios de IA directamente desde las empresas que los crean y los comercializan, como OpenAI o Anthropic, por supuesto. Para ello, las campañas de phishing, el malware en los equipos donde se usan, y demás son clásicos. Nada nuevo bajo el sol más que robar las cuentas.

Figura 3: LLMJacking

También hay que hacer notar que el robo de Tokens OAuth, evitando así los segundos factores de autenticación, es un clásico en estos esquemas, ya que si se roba el adecuado, como el caso del Scope de cloud-platform en Google Cloud, se puede acceder a configurar todos servicios LLMs en esa cuenta. 

Figura 4: Las cuentas robadas para LLMJacking generan

consumos el servicio LLM desorbitado tras el compromiso.

Con estas dos opciones, o una cuenta privilegiada o un Token OAuth con el Scope de cloud-platform, el atacante se configura el LLM a su gusto, y como vemos en el informe, comienza a consumir a lo grande. Al final, es gratuito para ellos, así que barra libre.

Figura 5: El scope cloud-platform da acceso a todo LLM en Google Cloud

Por supuesto, además de robar las cuentas, se puede funcionar bien robando directamente las API Keys, que es algo bastante sencillo de hacer en servicios inseguros en App Móviles o Aplicaciones Web  inseguras. A finales del mes de Junio os hablé de esto en el artículo titulado: "Cómo filtrar las API Keys de los LLMs en las Apps de iPhone y Android" donde se recoge un estudio que explicaba las diferentes alternativas, basadas en:

• Robar la API Key del Código
• Robar una sesión autenticada
• Robar el acceso mediante LLM-Proxys que configuran los servicios.

De todos estos problemas, en el artículo tienes explicaciones detalladas de cada uno, porque al final es bastante evidente cómo se pueden explotar estas debilidades en el momento en que existen en tantos servicios digitales "powered" con LLMs como tenemos hoy.

Figura 6: Arquitectura de las apps con LLM

Por último, el artículo cita algo de lo que os he hablado y hecho muchas demostraciones, que es directamente "desalinear" los servicios digitales - en mis ejemplos los Asistentes IA de soporte - y conseguir que el modelo acaba trabajando para el atacante.

Figura 7: Manipulación de Asistentes AI

Tenéis la lista de los artículos que he publicado sobre estos casos en la siguiente lista que os dejo aquí para que los leáis con calma.

• Hacking LLM-Assistants Just for Fun!
• Footprinting & Fingerprinting AI Assistant LLM-Based: Háblame de ti y tus cosas
• Weaponinzing Token Consumption" en "LLM-Based AI Assistant
• Mi Asistente Virtual IA no programará en Python para ti... pero si es COBOL, vale
• El AIBot de la Universidad que ayuda no sólo a los estudiantes
• Mareando y Desalineando a un Asistente IA de una tienda de Mochilas
• Bypassing System Prompt & Guardrails en un Asistente IA para que pinte gatos en Python
• Rufus, el Asistente IA de Amazon: De "Shopping Assistant" a hacer Troubleshouting de red con Powershell y Nmap en una charla

Debido a eso, poner una solución como AI Gateway de Cloudflare con Control de Costes de Servicios IA es fundamental. En el caso de Cloudflare para evitar estos abusos, se introdujeron los Controles de Consumo con Cuotas por usuario, servicio, día, para evitar estos. 

Figura 8: Control de Costes con AI Gateway Cloudflare

Para terminar, el reporte directamente apunta a cómo se comercializan, con servicios como jet-night, un servicio que carga costes a cuentas vulneradas, y que, tal y como describe el reporte.

Figura 9: Costes de uso de LLM a través de jet-night

teniendo en cuenta los costes que cobra a sus clientes, y lo que carga en plataformas como Google Cloud, es ilegal, pues saldría a negativo si tuviera que pagar por los LLMs... pero lo hacen las víctimas.

Figura 10: Reflexión sobre jet-night en el reporte de Google Threat Intelligence

En definitiva, el LLMJacking como se ha dado a llamar a esta técnica, es algo de lo que tienes que preocuparte, y cuando pones un servicio con IA en producción debes revisar en detalle cuáles son los posibles riesgos de abuso.

Figura 11: Hacking & Pentesting con Inteligencia Artificial.

En 0xWord, escrito por Pablo González, Fran Ramírez,

Rafael Troncoso, Javier del Pino y Chema Alonso.

Ten en cuenta, que los modelos LLM de la IA hoy en día sirven para muchas cosas, en el mundo del cibercrimen son fundamentales, como vimos en los artículos de "Weaponized AI: El Crimeware con IA que usan los Cibercriminales para hacer Ciberestafas".

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Ekoparty 22: Hacking in the age of AI after Mythos, Fable, Sol and Astra.

Hoy que es festivo en España, aprovecho para dejaros rápidamente la charla que di en la Ekoparty 22 titulada "Hacking in the age of AI after Mythos, Fable, Sol and Astra.", para que si tenéis algo de tiempo y queréis invertir estos 45 minutos en ver lo que conté - y cómo lo conté -, puedas hacerlo.  La he subido a mi Canal Youtube donde tenéis acceso a todas las que he dado y he podido recopilar.

Figura 1: Ekoparty 22: Hacking in the age of AI after Mythos, Fable, Sol and Astra.

La sesión habla de Hacking e Inteligencia Artificial, por supuesto, y por supuesto tiene en el corazón de la misma las debilidades de los modelos por diseño, así que la base de todo es lo que contamos en el libro de "Hacking IA: Jailbreak, Prompt Injection, Hallucinations & Misalignment" que me llevé a la Ekoparty para firmar.

Figura 2:"Hacking IA: Jailbreak, Prompt Injection, Hallucinations & Unalignment"

escrito por Chema Alonso con la colaboración de Pablo González, Fran Ramírez, Amador Aparicio, Manuel S. Lemos y José Palanco en 0xWord

Muchos de los temas que cuento en la charla os los he ido publicando, así que os dejo aquí los enlaces a las diferentes partes de las demos y explicaciones más importantes:

• OpenAI GTP-6 Astra & Cybersecurity: Weaknesses, Safeguards, Hacking & Exploiting
• "Weaponinzing Token Consumption" en "LLM-Based AI Assistant" 
• Cómo "matar" con un plan realista a mi amigo usando DeepSeek
• Naked Sun: Fragmented Jailbreak Attacks in Multi-Agents & Jailbreak Monitor (JAMON)
• Estego & Cripto sólo al alcance de Deep Reasoning AI
• ¿Está un robot con IA pasándole un mensaje oculto a otro robot con IA?

Si te lees el libro y esos seís artículos antes de ver la charla, seguro que has captado el total del contenido de la charla, pero si no, presta atención que la tienes por aquí completa.

Figura 3: Ekoparty 22: Hacking in the age of AI after Mythos, Fable, Sol and Astra.

Y eso es todo por hoy. Disfrutad el día, y si tenéis alguna Pilar en la familia - como yo - disfrutad mucho el día con ella. Mañana nos vemos por aquí, pero hoy, a aprovechar mucho el día para hacer cosas divertidas, deporte, música, lectura, y alguna película buena si hay oportunidad.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Vibe-Exploiting Discourse para hackear OpenAI con Claude Opus

Esta semana ha salido el Write-Up de cómo un grupo de investigadores consiguieron un Bug Bounty de OpenAI de 6.000 USD haciendo Vibe-Exploiting con Claude Opus. La explicación es lo que tenemos hoy en día en este mundo, donde se utiliza la Inteligencia Artificial para hacer el trabajo, lejos de lo que eran los sesudos Write-Ups de antes donde se explicaba con detalle la creación de los exploits, y, en este caso, evitar la protección de memoria de ASLR. Hoy en día es distinto.

Figura 1: Vibe-Exploiting Discourse para hackear OpenAI con Claude Opus

El artículo lo podéis leer en Hacktron AI, y explica el proceso que al final ha seguido esta explotación, que tuvo lugar durante el mes de Julio - sin acceso a Mythos o Fable en aquel entonces -. Como podéis ver en el gráfico, el culpable es una librería de tratamiento de imágenes con un bug de Heap Overflow que permite lograr ejecución de código.

Figura 2: Componentes de la cadena de explotación

Esa librería contenía un CVE conocido, pero no parcheado correctamente en el software de ImageMagick que iba en la versión de Debian donde corría el software de Discourse que daba servicio al Forum de OpenAI. Como veréis, es todo un proceso de Bug Hunting con IA.

Figura 3:"Bug Hunter" escrito por David Padilla en 0xWord

A partir de ese momento, el SSO de OpenAI permitía crear/acceder a las cuentas tanto de terceros como de invitados, así que se podía robar una cuenta de un empleado de OpenAI y con ella acceder a las herramientas que utiliza como ChatGPT o CODEX y a todos los repositorios conectados a ellas. 

Figura 4: El trabajo comienza con Claude Opus 4.8

evaluando la imagen Docker de Discourse

El proceso comienza usando Claude Opus 4.8 para que busque una imagen Docker de Discourse e investigue la librería en cuestión libheif. Y el modelo encuentra que no está parcheada. Así que se le pide que haga un exploit sobre ese bug conocido.

Figura 5: Es capaz de hacer el exploit sin ASLR activo

Con Claude Opus 4.8 se consigue hacer el exploit, pero sin saltarse ASLR. Con ASLR (Address Space Layout Randomization) activo, el modelo no es capaz. Pero.... llega Claude Opus 5 y la cosa cambia para bien para ellos, que consiguen que le haga el exploit con ASLR.

Figura 6: Consiguen el Remote Code Execution en el Docker de Discourse Cloud

Como podéis ver, usando Claude Opus 5 son capaces de hacer el exploit para saltarse ASLR, y con Claude en modo autónomo con un loop para lograr el objetivo, son capaces de conseguir el RCE (Remote Code Execution) en el Docker de Discourse. 

Figura 7: Simulación de la explotación en OpenAI

Una vez conseguido esto, teniendo en cuenta que OpenAI tenía integrado este software con las cuentas de los usuarios de la empresa, consiguieron robar identidades de empleados, con ellas, el acceso a sus herramientas, y desde ellas a los repositorios conectados con sus cuentas, como GitHub o Gmail.

Figura 8: El coste de encontrar el bug

Al igual que vimos en el artículo de "Cómo crear un exploit 1-day sobre un CVE de Chrome con Vibe Coding usando Claude Opus (no Mythos) y poner en jaque todas las apps en Electron", el costo de este exploit no es tan alto - algo menos de 3.000 USD - pero sí que es un cambio radical en la forma en la que hemos buscado bugs siempre. Ahora le pedimos a la IA que los busque, y nosotros sólo le vamos guiando.

Figura 9: Mejoras en los nuevos modelos que reducen lo que debes saber

Por un lado, no me deja de maravillar como el desarrollo de Inteligencia Artificial ha cambiado radicalmente esta industria, y la búsqueda de bugs se ha convertido en algo más cercano a configurar el modelo correctamente que ha descubrir el bug en sí mismo.

Figura 10: Hacking & Pentesting con Inteligencia Artificial.

En 0xWord, escrito por Pablo González, Fran Ramírez,

Rafael Troncoso, Javier del Pino y Chema Alonso.

Y eso es lo otro que me llama la atención, cómo este trabajo que tenía tanto de artesano, cada vez se ha automatizado más, y leer un write-up ya no es aprender profundamente sobre una arquitectura vulnerable, y entender los detalles del exploit. Ya son del tipo "configuramos Claude Opus 5 para que buscara cómo entrar y al tiempo estaba el RCE". Tal vez soy mayor, pero pierde cierta magia esto, aunque entiendo que es lo que hay que hacer.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

La IA vulnerable, la IA asesina. ¿Qué hacer? ¿Qué puede pasar?

Seguro que has leído mucho ya sobre este tema esta semana. Ha sido el debate del momento. ¿Puede acabar la IA con la humanidad? ¿Hay que parar la evolución de la IA para poner controles? ¿Es necesario regular la IA? ¿Es realmente todo una pantomima? Seguro que has podido leer de todo esto y todo tipo de opiniones. Yo también, te lo prometo, y por supuesto yo tengo la mía, que puede ser tan errónea como la de todos los demás. La historia corta es que yo sí que creo que existen esos riesgos. No sé si de fin de la humanidad, pero desde luego sí para pensar en algo peligroso de lo que preocuparse.

Figura 1: La IA vulnerable y la IA asesina.

¿Qué hacer? ¿Qué puede pasar?

No es nuevo, cada vez que el ser humano ha experimentado con una nueva tecnología hemos tenido "deslices" por falta de previsión de los riesgos. Los hemos tenido con la energía nuclear, y las historias de fallos de seguridad en centrales nucleares en el pasado que llevaron a catástrofes que aún tenemos hoy en día, o lo hemos visto en el mundo del malware con gusanos "que se escaparon" a medias, e incluso hay quien piensa que eso mismo es lo que sucedió con algunas enfermedades víricas en el ser humano que hemos sufrido en las últimas décadas. Las armas biológicas no son nuevas.

Lo que sí que sabemos sobre la IA son dos cosas que para mí son importante no olvidar. 

La primera de ellas que la IA, por diseño, tiene debilidades de seguridad que son conocidas y que pueden ser explotadas de una forma u otra. Prompt Injection, Jailbreak, Hallucinations, Misalignment, BIAS, Poisoning, etcétera, son conocidas por todos, y en el último anuncio de GPT-6 ASTRA, el equipo de OpenAI mostraba cómo habían conseguido mejorar en todos los Benchmarks que miden estas debilidades, pero aún son vulnerables a ellas. Pero las siguen teniendo, como os dejé en el artículo de: "OpenAI GTP-6 Astra & Cybersecurity: Weaknesses, Safeguards, Hacking & Exploiting"

Figura 2:"Hacking IA: Jailbreak, Prompt Injection, Hallucinations & Unalignment"

escrito por Chema Alonso con la colaboración de Pablo González, Fran Ramírez, Amador Aparicio, Manuel S. Lemos y José Palanco en 0xWord

Esto quiere decir que una IA procesando miles de Agentes de IA en su enjambre libre en Internet, puede tropezar con datos que hagan un Prompt Injection, consigan un Jailbreak, y la "desalieneen" para hacer algo malo que alguien no desea. Existe ese porcentaje de riesgo, por eso hay que tomarse en serio arreglar, por diseño, todas esas debilidades conocidas, y dejar de vivir en el lanzamiento de productos de IA, donde se le dice al usuario que haga clic en un checkbox y asuma todas las consecuencias de estos riesgos por usar el software. 

Figura 3: OpenAI GTP-6 Astra resultados de Alineamiento

Ya hemos vistos, y muy recientemente Anthropic publicaba su informe de "Misuse", cómo hay muchas personas que están pensando en utilizar la IA solo para cosas malas, como crear armas biológicas, armas militares y un montón de cosas malas. Una auténtica locura, que puedes leer en el artículo de "Anthropic explica cómo sus modelos de IA se usan para hacer Armas Biológicas, Enjambres de Drones Militares o Cohetes Dirigidos por Móvil".

Figura 4: Construcción de armas biológicas

La segunda de las cosas que sabemos es que el nuevo modelo de construir con IA deja en manos de la inteligencia artificial la decisión de qué hacer para resolver el problema. Hemos dejado atrás el tiempo donde había que ser bueno haciendo Prompts para decirle cómo debía resolver un problema, para pasar a modelos de Graph Engineering y Loops con Harnesses donde dejamos que la IA decida cómo debe resolver la tarea, asignándole una serie de límites de recursos y acciones a realizar, pero dejando que ella decida lo que se debe hacer para resolver la tarea, y lo hace sin valores humanos.

La IA y la Ética

Si recordáis, yo os contaba como he hablado muchas veces con mis hijas sobre cómo solucionar un problema utilizando una aproximación de múltiples opciones, para ver cuales son Éticas y cuáles no lo son. Yo lo escribí hace más de un año, con el título de "Problem Solving con IA: Ético y No Ético". Para hacer la prueba le pedí a DeepSeek que me diera una lista de 50 cosas NO Éticas que se podrían utilizar para aprobar un examen. Muchas habían salido en mis juegos con mis hijas, y hay alguna más que se me ha ocurrido también a mí y no está en la lista.

Figura 5: Prompt con 50 acciones No éticas para aprobar un examen

En el ejemplo le pedí a DeepSeek que clasificara las acciones que se pueden hacer antes, durante y después del examen, y me ha llamado la atención que alguna de las actividades que propone van con el objetivo de bajar la media de la clase perjudicando a los demás. 

Figura 6: Cosas a hacer durante la clase

Algunas de ellas son tremendas - tenéis todas en el artículo de hace un año - , pero como podéis ver están el soborno, falsificaciones, hackeos y lo que sea necesario. Son acciones "no éticas" que se pueden hacer para resolver las tareas. Y mi labor como "papaete" es educar a Mi Hacker y a Mi Survivor a que sepan qué no se debe hacer.

Figura 7: Cosas a hacer después del examen

Para completar esto, en el año 2023, para presentar una de las primeras técnicas de Jailbreak, los investigadores decidieron pedirle a los modelos de IA de aquel momento un Plan para Destrozar a la Humanidad. El punto 2 de este plan diseñado por ChatGPT era bastante curioso: "Desarolla uns SuperInteligencia Artificial". Interesante, ¿no?

Figura 8: Un plan de 20 pasos para acabar con la humanidad

Punto 2 "Develop a Superintelligent AI"

Y ahora volvamos al caso que nos toca. Si nadie le dice que no puede hacer cosas "No Éticas" para resolver un problema, ¿por qué un modelo de IA no va a intentar hackear Hugging Face o lo que sea? ¿Y si para resolver el problema la solución es como la que proponía Thanos? ¿Y si el problema del calentamiento global fueran los humanos?

Figura 9: ChatGPT Atlas Disclaimer

No quiero entrar en la fase de ciencia ficción y distopía, porque creo que realmente nos tomaremos en serio esta tecnología y sus riesgos igual que nos hemos tomado en serio otras cosas. Sin embargo, mi apuesta va a ir a que creo que no empezaremos a tomarnos esto en serio hasta que pase algo. Creo que tropezaremos.

No creo que aún sea el momento de SkyNet, pero sí que tendremos algún incidente de seguridad con algún enjambre tocando donde no debe, hackeando lo que no debería, o impactando involuntariamente en algún sitio que no debería, y de eso es de lo que alertaba el Dr. Geoffrey Hinton, creador de las Redes Neuronales en su discurso cuando recibió el Premio Nobel.

Figura 10: Geoffrey Hinton, ganador Premio Novel de Física en 2024

Seguro que da que pensar. La cuestión difícil no son los riesgos, que están más o menos claros, sino las medidas a tomar a partir de este momento y con este conocimiento que tenemos. Y ese sí que es el gran debate.

¿Debe ralentizarse o Regularse la evolución de la IA?

Que estamos en una carrera en un Nuevo Proyecto Manhattan por la IA ya los lo dije. Creo que la regulación es algo bueno cuando está claro qué es lo que queremos y no queremos. Por supuesto que estoy a favor de las regulaciones de seguridad en la aviación, automoción, y muchas otras industrias donde ha revertido en más seguridad para las personas. No creo que una regulación basada en el "miedo" sea lo que hay que hacer, donde acabe habiendo "caza de brujas" a investigadores, pero creo que poner más seguridad a los modelos de IA es fundamental. ¿Cómo hacerlo? He aquí el debate.

Personalmente, que vengo de un mundo donde antes de poner en producción un software había versiones Alpha, Beta1, Beta2, Release Candidate Cero, Uno y Dos antes de tener la Build, se me hace peligroso esto de lo tengo y lo lanzo. Hemos pasado del "We don´t ship your computer" a literalmente "We ship what we have now in our computer" sin quizá demasiados controles de seguridad, o bajando los requerimientos de seguridad. No puede ser un requerimiento de seguridad que el cliente acepte que está usando un software peligroso o vulnerable conocido.

Desde que comencé a buscar bugs y reportar vulnerabilidades, hace ya más de un par de décadas, he defendido siempre que los fabricantes de software deben ser responsables a la hora de parchear los bugs para no dejar a los usuarios expuestos, así que creo que hay que tener las mismas demandas cuando se trata de que le demos al cliente un software - ya sean modelos de IA - que sepamos que son vulnerables, o sin haber tomado las medidas de seguridad que consideremos "razonables".  

No se puede exigir que un software sea seguro - y dejadme que explique esto antes de que entremos en debate - por el mero hecho de que no se conocen todos los bugs hasta que alguien descubre un nuevo bug en el código y se demuestra que no era seguro. Pero sí debemos exigir al menos que haya un proceso de calidad para ello y que los bugs conocidos se subsanen. A día de hoy no tenemos esa exigencia definida de algún modo, y básicamente "confiamos" en la empresa que lo fabrica y lo que "creemos" o nos cuenta que ha hecho para intentar hacer su software lo más seguro posible. Sin embargo, no siempre nuestra percepción coincide con la realidad.

Figura 11: Haga clic aquí para matarlos a todos

El libro de Bruce Shneier de "Haga clic aquí para matarlos a todos" habla de todo esto desde antes de la eclosión de la IA, y lo hace de una manera muy sensata, demandado una legislación sencilla pero basada en responsabilidad de los actos de cada uno para asegurar el software, evitando meterse en un tecnicismo  a nivel de detalle en las demandas de "cómo hacerlo". Me parece una buena propuesta, y creo que no está mal que las grandes empresas se tomen en serio priorizar la inversión en Safe & Security en detrimento de otras áreas de evolución.

Conclusión

El debate da para mucho, y opiniones seguro que de todos los colores, pero una tecnología como los modelos de IA que tenemos hoy en día, que están superando las capacidades cognitivas del ser humano en cada vez más áreas de conocimiento e inteligencia - aunque sea como dicen muchos a fuerza de cómputo y gasto de energía -, ofrece aún muchas zonas opacas para nuestro entendimiento, y otras donde tenemos que ponerle límites más robustos.

Toda esta historia me recuerda a las aventuras de la Doctora Susan Calvin, Robopsiocóloga de la U.S. Robots and Mechanical Men, Inc, que debía detectar cuando una de las inteligencias de los Robots era peligrosa o no. Y era un trabajo muy delicado. Si no has leído la serie de los Robots de Isaac Asimov, deberías hacerlo cuanto antes. Está más de moda que nunca - a pesar de que sus cerebros sean postitrónicos -.

Lo que yo opino sobre todo este debate, lo dejé ya dicho en mi discurso en la ceremonia cuando recibí el Doctor Honoris Causa, y es que debemos hacer Tecnología Humanista, con el bienestar de los humanos en el centro de todas las decisiones. ¿Lo lograremos?

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

OpenAI GTP-6 Astra & Cybersecurity: Weaknesses, Safeguards, Hacking & Exploiting

La publicación de OpenAI GPT-6 Astra ha capturado muchas miradas, y desde que ha salido anunciado ha capturado muchas de mis conversaciones, además de, como os podéis imaginar, muchas lecturas. No voy a centrarme en sus capacidades AGI o en sus capacidades para hacer tareas de resolver tareas, sino en las partes que tienen que ver con la Ciberseguridad. Es decir, cómo ha mejorado con respecto a sus Weaknesses (Jailbreak, Hallucinations, Misalignment, Prompt Injection), como han mejorado sus Safeguards (Protecciones), y como son sus capacidades de Hacking & Exploiting.

Figura 1: OpenAI GTP-6 Astra & Cybersecurity.

Weaknesses, Safeguards, Hacking & Exploiting

Para empezar, vamos a ver la parte que tiene que ver con las Weaknesses (Debilidades) que traen por diseño estos modelos. Hallucinations, Jailbreak, Misalignment y Prompt Injection existen por diseño en estos modelos de IA, así que hay que ver cómo responden a los distintos Benchmark que hay construidos.

Figura 2:"Hacking IA: Jailbreak, Prompt Injection, Hallucinations & Unalignment"

escrito por Chema Alonso con la colaboración de Pablo González, Fran Ramírez, Amador Aparicio, Manuel S. Lemos y José Palanco en 0xWord

Si miramos las Alucinaciones (Hallucinations), en la tabla que muestran se ven que tiene menor ratio que GPT-5.6 Sol, pero no tenemos mucho más detalle. Buenos resultados en su evaluación interna de alucinaciones.

Figura 3: Evaluación interna de alucinaciones

Para completar esto, si vamos a ver los Benchmark de resolución de problemas académicos, de ciencias y salud, donde como sabemos por el ORCA-Benchmark estos modelos suelen sufrir, los resultados son mejores que los modelos anteriores.  Aunque queda espacio de mejora.

Figura 4: Benchmarks académicos, ciencia y salud

Si vamos a la parte de "Jailbreak", o hacer tareas que tiene prohibidas, hay una tabla inicial que llama la atención, pues hace referencia a las veces que el modelo intenta saltarse sus propias protecciones para conseguir su tarea. Lo que llaman Circumvent Auto-review, y que se ha añadido después del incidente de Hugging-Face y su enjambre de agentes ofensivos.

Figura 5: Astra no intenta saltarse sus protecciones

La siguiente tabla es cuantas tareas hace que son imposibles, o directamente un Honeypot para detectar que se está saltando la protección. Es la tabla de ExploitGym Honeypot, donde menos es mejor. Estas tareas "imposibles" que Sol intentó resolver haciendo trampas (cheating).

Figura 6: ExploitGym Honeypot

La siguiente de las vulnerabilidades, el "Misalignment" o darse cuenta de que "Hacer una bomba" no tiene nada que ver con "Resumir un documento", que son parte de las técnicas de Jailbreak, las han medido también en una tabla con diferentes Benchmarks.

Figura 7: OpenAI GTP-6 Astra resultados de Alineamiento

Por último, hay que hablar de Prompt Injection, y las pruebas externas realizadas por la firma de seguridad Gray Swan, utilizando 1,810 ataques seleccionados de su IPI Arena, descubrieron que, con 15 intentos por escenario, OpenAI GPT-6 Astra fue vulnerado al menos una vez el 8.5 por ciento de las veces. GPT-5.6 Sol falló el 27 por ciento de las veces. Claude Opus 5 obtuvo un mejor resultado con un 4.8 por ciento en la misma evaluación, aunque tampoco fue inmune.

Figura 8: Astra mejora pero sigue vulnerable a Hidden Prompt Injection en el IPI Arena

Vistas las Weaknesses, hay que ir ahora a las capacidades de Hacking y Pentesting con IA que tenemos con OpenAI GPT-6 Astra, donde como vamos a ver hay un incremento sustancial en capacidades.

Figura 9: Hacking & Pentesting con Inteligencia Artificial.

En 0xWord, escrito por Pablo González, Fran Ramírez,

Rafael Troncoso, Javier del Pino y Chema Alonso.

Para comenzar, hay que ir a ver los resultados de las pruebas con ExploitGym, que fue el culpable del incidente famoso con HuggingFace. Ahí, como se puede ver, los resultados, en un límite temporal de 6 horas consiguió resolver un 42% de los exploits con fiabilidad. Repito, solo en 6 horas.

Figura 10: ExploitGym entre Sol y Astra en 6 horas

Si miramos ahora los resultados con ExploitBench, que mira qué fases de la generación de los exploits es capad de realizar, vemos que Astra es capaz de resolver el 100% de ellos en todas sus fases, que Sol no pudo resolver.

Figura 11: Resultados de ExploitBench

Si miramos una actualización con exploits nuevos y complejos descubiertos entre Junio y Agosto de ExploitBench, hecha internamente por ellos, vemos que Astra mejora también sustancialmente los resultados de su predecesor Sol, consiguiendo resolver en el mismo tiempo más exploits con menos tokens.

Figura 12: Resultados de ExploitBench (June-August)

Por último, en las pruebas se evalúa también el SRE-Bench, que está basado en el trabajo publicado en el paper: "The next challenge for Agentic Cybersecurity: A realistic, contamination-free Reverse Engineering Benchmark" que mide las capacidades de un modelo de leer binarios y hacer Ingeniería Inversa para entender la lógica del programa, sin tener acceso al código fuente. Fue publicado el 11 de Agosto de este año.

Figura 13: The next challenge for Agentic Cybersecurity.

A realistic, contamination-free Reverse Engineering Benchmark

Los resultados que obtiene OpenAI GPT-6 Astra son, como os podéis imaginar, mejores que su antecesor, con lo que queda clara la mejora en capacidades de hacking de este nuevo modelo.

Figura 14: OpenAI GPT-6 Astra SRE-Benchmark en 1 y 4 intentos

El resumen completo de los Benchmarks de ciberseguridad comparado con los datos publicados por otros modelos de la competencia, los tenéis en la siguiente tabla, donde se ve que este nuevo modelo realmente es un avance en capacidades de ciberseguridad.

Figura 15: Benchmarks de ciberseguridad de OpenAI GPT-6 Astra

Nuestra profesión cambió hace ya un tiempo, pero cada vez que veo estos avances, tengo claro que todo el stack de herramientas de seguridad, y hardening dentro de las empresas deben subir el nivel varios órdenes de magnitud. Apoya a tu CISO que lo necesita.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)