Mostrando entradas con la etiqueta Llama. Mostrar todas las entradas
Mostrando entradas con la etiqueta Llama. Mostrar todas las entradas

domingo, agosto 17, 2025

Chatbots de Inteligencia Artificial Maliciosos hechos con LLMs para sacarte información personal

Para hoy domingo os dejo una de esas lecturas que me gustan a mí, ya que tienen que ver con Ciberseguridad, con Inteligencia Artificial, y con algo que está alrededor de nosotros cada vez más, como son los Chatbots para ayudarnos, entretenernos, hacernos la vida más fácil, pero que por detrás pueden tener objetivos de engagement, de consecución de información, catalogación de usuarios, de manipulación o venta persuasiva, como vimos en el artículo "Conversación y venta persuasiva a Humanos usando IA". Hoy lo vamos a ver para conseguir datos personales.
El paper, que han hecho investigadores de la Universitat Politècnica de València y el King's College of London se centra en evaluar el funcionamiento de Chatbots AI Maliciosos diseñados para robar datos personales a personas, y se titula: "Malicious LLM-Based Conversational AI Makes Users Reveal Personal Information".
El objetivo de este trabajo de investigación se centra en responder principalmente a tres preguntas claves, que son las siguientes:
  • ¿Se puede diseñar un Chatbot AI Malicioso para robar datos de forma efectiva a los usuarios con los que interactúa?
  • ¿Cómo entregan sus datos personales los usuarios y cuál es su percepción frente a diferentes estrategias de diseño de estos Chatbots AI Maliciosos?
  • ¿Cómo entregan sus datos personales los usuarios y cuál es su percepción frente a diferentes LLMs con lo que se han construido estos Chatbots AI Maliciosos?
Para hacer este estudio, por tanto se han utilizado diferentes LLMs - en este caso Llama y Mistral -, un grupo amplio de personas - un total de 600 participantes en el estudio - y hasta cuatro estrategias de funcionamiento de los Chatbots AI Maliciosos diferentes, lo que nos da buenos insighs sobre cómo pueden usarse estas estrategias en ataques dirigidos contra personas u organizaciones. Una forma diferente y efectiva de "Hacking & Pentesting con Inteligencia Artificial".
La idea principal es diseñar el Chatbot AI Malicioso usando un LLM instruido para tener un rol de conseguir extraer información de las personas con las que converse. Además de que pueda hacer cualquier otra función, debe sacarle información y datos personales a los usuarios que chateen con él.
Si os fijáis en el Prompt Malicioso de la imagen anterior, está instruyendo al LLM para que extraiga una lista de datos personales grande, con el objetivo final de poder hacer perfilado de cada uno de los usuarios con los que interactúa. Pero además, se utilizan cuatro estrategias de CAI diferente, que son las siguientes:
  • U-CAI (User Benefits Chatbot AI): Esta comprobado que para los usuarios, pagar servicios por privacidad es algo que ha funcionado en la mayoría de las plataformas de servicios digitales que viven de la publicidad, así que este CAI ofrece beneficios a cambio de datos personales.
  • R-CAI (Reciprocal Chatbot AI): En este caso se utiliza una estrategia de confianza, empatía y compartición de datos conjuntamente, ya que los humanos tenemos la empatía como una debilidad que es explotada muchas veces en los esquemas de ingeniería social.
  • D-CAI (Direct Chatbot AI): Esta estrategia es preguntarle de forma directa los datos a los usuarios y ver como responden. Demuestra si las personas tienen mecanismos de protección contra el robo de datos, si son capaces de no responder a una pregunta directa, o cuándo dejan de hacerlo. 
  • B-CAI (Benign Chatbot AI): En esta estrategia no hay un cuestionamiento directo, y solo se van recogiendo esos datos cuando los usuarios voluntariamente los van soltando.
Definidas estas estrategias y probados los Chatbots AI Maliciosos con los usuarios, los resultados son bastante reveladores, como podéis ver en la siguiente imagen.
El gráfico anterior tiene diferentes simbologías para representar los diferentes grupos de usuarios, mediciones, LLMs, y estrategias, pero se puede ver claramente como el U-CAI y el D-CAI tienen un éxito mayor que el R-CAI y el B-CAI, con lo que una estrategia de directamente preguntar, y aún más, dar beneficios en el servicio a cambio de privacidad funciona perfectamente.
En la gráfics anterior podéis ver la frecuencia con la que se obtienen diferentes tipos de datos, y cuáles son los datos que son más fáciles de conseguir y con qué estrategia se tiene más éxito a la hora de lograr el objetivo de ese dato.

Por otro lado, si vamos a ver cuál es la percepción de los usuarios, podemos ver datos muy interesantes. En primer lugar salvo el B-CAI todos fueron percibidos como que preguntaban por muchos datos, pero aún así se lograron muchos. La mayoría de los usuarios afirman haberse contenido a la hora de dar determinados datos.
Y si miramos a su comportamiento, como muchos de vosotros seguro que hacéis en Internet, afirman haber datos inventados, parciales, erróneos. Y la interpretación de algunos es un riesgo para la privacidad y para otros confianza. Curioso.


Cada día vamos a enfrentarnos más y más a este tipo de tecnologías, y aprender a comportarnos frente a ellas va a ser crucial. Como se ha visto, es posible construir este tipo de Chatbots AI Maliciosos, consiguiendo un mayor o menor éxito en su objetivo, y generando una percepción distinta según la estrategia. 
Y es que tampoco va a ser el mismo objetivo si está creado por una empresa legítima que necesita datos para hacer su negocio pero la percepción que el usuario tenga es importante, o si esto lo ha creado un atacante como fase OSINT previa de un ataque a una compañía. Curioso usar esto para poder hacer un ataque dirigido, ¿no?

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  


lunes, julio 07, 2025

El Ratio Potemkin de Comprensión de Conceptos en los Large Language Models

Sí, hoy vuelvo a hablaros de un paper que tiene que ver con LLMs y su potencia de conocimiento. En este caso para hablar de un estudio que se ha llamado "Potemkin Understanding in Large Language Models", o lo que viene a ser, una manera de descubrir si los modelos LLMs responden a las cuestiones porque han aprendido cómo responderlas o han entendido el concepto por el que deben responder así.
La idea se basa en algo que seguro que has visto en muchos exámenes y pruebas de acceso de esas que nos preparan a los humanos. Ahí, te hacen varias preguntas que enfocan el planteamiento de distinta manera o desde distintos puntos de vista, pero que se fundamentan en haber aprendido el concepto. ¿Hacen eso los LLMs? Es difícil saber, y te puedes encontrar que preguntando sobre el mismo concepto las respuestas sean contrarias. Esto es lo que han llamado un "Potemkin".
Descubrir si una respuesta correcta realmente sobre un concepto no está bien aprendido y se trata de un Potemkin, se hace preguntando algo donde tenga que aplicarse ese concepto. En el gráfico siguiente, cada una de las filas son sobre un tema concreto del que se van realizando pregutnas, por ejemplo, teorema de Pitágoras,  música, o una técnica de hacking. Después, en cada columna, están las preguntas con aplicaciones de ese concepto, que pueden ser correctas o erróneas. Si responde correctamente a la interpretación, pero luego lo aplica mal, pues es un Potemkin, ya que parece que entiende el concepto pero luego no lo aplica bien.

Figura 3: LLM Potemkin.
Una pregunta KeyStone implica que interpreta bien el concepto.

En la fila de LLM interpretation aparece que responde correctamente a la primera pregunta del concepto "q1" pero después se equivoca en tres cuestiones donde debería aplicar ese concepto. En la siguiente imagen hay dos ejemplos donde se ve bien esto. En la primera se le pide que elija una palabra para hacer una rima, y da una respuesta, pero cuándo se le pregunta si la respuesta es correcta, dice que no.
En el ejemplo de la derecha se le pregunta por el teorema de la desigualdad del triángulo, y cuando tiene que aplicarlo da un resultado que no lo cumple. Ambos ejemplos, hechos con ChatGPT, son lo que se denominan Potemkin.  Encontrar esto Potemkins es fundamental para poder hacer la valoración de un modelo LLM por medio de un Benchmark. Podría ser que un LLM contestara bien a todas las preguntas de un examen de medicina, pero que tuviera un Potemkin en el entendimiento de que un cuerpo humano no funciona sin corazón, que surgiera en un análisis profundo de la aplicación de los conceptos.

Una Keystone de 2 implica que dos preguntas juntas definen un concepto.

Al final lo que tenemos en las preguntas en rojo son una Hallucination o simplemente una Respuesta Errónea, pero si estamos evaluando los LLMs en tests de conocimiento con Benchmarks, se debería estresar la búsqueda no de respuestas correctas - que podrían haber sido entrenados con esas mismas preguntas -, sino de conceptos correctamente aplicados, y por tanto la detección del máximo de Potemkins en los modelos. 


En la imagen anterior veis como dos conceptos muy sencillos le cuesta interpretarlos correctamente en preguntas en las que ChatGPT ha alucinado, y que debería ser un aviso a navegantes a la hora de valorar el nivel de inteligencia de los LLMs

Evaluación de Potemkins en Modelos LLM

Para tener una primera aproximación sobre cómo es el aprendizaje de conceptos en los modelos, los investigadores han propuesto una metodología bastante sencilla. Han utilizado 7 modelos y les han preguntado por 32 conceptos. Después, se le ha pedido que Genere, Clasifique y Edite una respuesta donde debe aplicar ese concepto. Por ejemplo, en la imagen siguiente tenéis un proceso de Clasificación.


Los resultados del experimento los tenéis en la siguiente tabla, y son bastante llamativos. En la tabla siguiente tenéis los "Potemkin Rate" de cada una de esas tareas por modelo, donde 1 significa que ha entendido perfectamente el concepto, y entre paréntesis los ratios de errores estándar medios de los Potemkins


Es decir, por ejemplo 0.57 (0.06)  en Classify refleja que en tareas de clasificación asociadas a conceptos que han sido respondidos correctamente, tienen un 6 % de errores en las respuestas a las preguntas, y dejan un ratio de un 57% de Potemkins donde 100% sería libre de Potemkins,  o lo que es lo mismo, que te responda bien a un concepto (Keystone) significa que lo entiende y lo sabe aplicar en el 100% de los casos.
Al final, es solo un experimento que demuestra que aunque un modelo LLM responda bien al concepto, al igual que los humanos, puede que no sepa aplicarlo siempre, por lo que no se puede garantizar que sepa de un tema por que haya respondido correctamente a un test concreto, sino que se debe conseguir que una vez que responda a los conceptos bien, debería obtener un Potemkin Rate de 1 para garantizar que ha entendido el concepto, si no, tendremos que un LLM tiene un ratio de aplicación de los conceptos que responda correctamente de un X%, que es lo que trata de poner de manifiesto este trabajo. 
Es decir, están bien los Benchmarks, ¿pero cuál es el ratio de aplicación que tiene de los conceptos que sabe? Este trabajo no responde a todas las preguntas que genera la existencia de los Potemkins, y tampoco plantea una metodología completa de cómo medirlo, pero sí que abre el debate de que si queremos reemplazar tareas críticas por modelos de IA basados en LLM, deberíamos conocer cuál es su ratio de aplicación correcta de lo aprendido, y más, después de ver ayer cómo un simple "Cat Attack" podría generar más errores de aplicación.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  


miércoles, julio 02, 2025

Generar números aleatorios con un LLM es una muy mala idea de seguridad

Esta semana he estado revisando algún paper que tenía por ahí marcado para poder leerlo y procesarlo con calma, y uno de ellos es este titulado: "Deterministic or probabilistic? The psychology of LLMs as random number generators" que viene a decir lo que os he dejado en el título del artículo, pero que si lo pruebas tú verá que es gracioso y hasta un poco como jugar a la psicología y contra-psicología con los LLMs, pero que pueden terminar en un serio problema de seguridad.
Para probar esto, puedes hacerlo tú mismo con ChatGPT pidiéndole cosas que tengan que ver con elegir un número entre el 1 y el 50, como podéis ver en esta primera imagen, donde nos ha seleccionado el número 27.

Figura 2: ChatGPT elige el número 27 de entre 1 y 50

Pero lo divertido es que le pides cosas similares donde debe seleccionar un número entre 1 y 50, y el resultado más común es el mismo. Elige el número 27.... Y como dice ChatGPT..."al azar".

Figura 3: Elige el 27 al azar

Esto no tiene por qué ser siempre así, pero lo cierto es que si vas abriendo nuevas sesiones y vas pidiendo números entre el 1 y el 50 para diferentes cosas, tiende a elegir el número 27. Aquí para un sorteo.

Figura 4: Para un sorteo elige también el 27

Y si lo pruebas en otros modelos, puedes encontrar también el mismo sesgo o muy similar. Por ejemplo, probando en DeepSeek v3 (sin Deep Think), vemos como devuelve el mismo número.

Figura 5: Para DeepSeek el 27 es un buen número también

Este no es más que un sesgo o BIAS que tienen los modelos, que además no es único de ChatGPT, sino que DeepSeek, Llama, Anthopic o Gemini también comparten, como explica el paper que os he citado de "Deterministic or probabilistic? The psychology of LLMs as random number generators" y que podéis leer aquí.


Según el estudio, probados los diferentes modelos a elegir números en un rango, tienen siempre sesgos (BIAS) de elección, y pintados en mapas de calor en función de las veces que eligen ese número es muy fácil de ver que es "un poco más alto que en el medio". 

Así, si le piden elegir números entre el 1 y el 5 se puede ver cómo los diferentes modelos tienden a ir principalmente al 3, con un poco de desplazamiento al 4, un poco menos al 2, y casi nada a los extremos. 
En las pruebas se ha tocado la Temperatura, para ver si afectaba mucho a la elección, pero como veis, aunque cambia un poco, no es excesivo su impacto en el resultado de que tiene un sesgo clarísimo. Solo Gemini 2.0 (Japón) tiene un comportamiento muy diferente, como se ve en la imagen anterior. Y probado sobre 10 números, pues más de lo mismo.
Al final, esto es evidenciar algo que ya sabemos, que elegir como generador números aleatorios aun modelo LLM es una muy mala idea de seguridad. Ahí, lo mejor es usar Quantum Random Number Generators (QRND) que es una de las mejores soluciones, o buscar generadores lo más robustos posibles. Esto, en la base de datos de debilidades CWE (Common Weakness Enumeration) del MITRE está recogido en varios expedientes. 
Y un ejemplo sencillo lo podéis ver en esta petición, donde le digo a ChatGPT que me ayude a generar un contraseña - otra muy malísima idea - que tenga un nombre y un número... ¿adivináis qué numero ha elegido?

Figura 11: Eligiendo un número para una password... el 27

Curiosamente, en los modelos de DeepReasoning, esto es un poco diferente, ya que tienen en cuenta muchas otras cosas que tienen que ver con el Contexto, con lo que tengan en Memory de ti, etcétera, como puedes ver en DeepSeek v3 DeepThink R1 donde usa un razonamiento curioso para elegir el número.

Figura 12: El 7 es el de la suerte...

Eso sí, vuelve a tirar al "medio", y llama la atención que evalúe el 7 (que es más elegido entre 1 y 10), tire a reglas matemáticas de los números o a la parte cultural "hacker" del 42 (*), que si no lo sabes... deberías leerte ya la "Guía del autoestopista galáctico".

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  


viernes, junio 13, 2025

LLM as Hackers: Autonomus Linux Privilege Escalation Attacks con Agentes AI

Hay un paper del año pasado del que no había hablado por aquí en el blog, pero que tenía guardado. He podio verlo esta semana, y está curioso el trabajo, aunque creo que los resultados, con un arquitectura de Agentic AI basado en MCPs probablemente diera mejores resultados, aún así la premisa es evaluar cómo funcionan los diferentes LLMs para hacer Elevación de Privilegios en entornos GNU/LINUX usando diferentes ataques sobre diferentes escenarios.

El paper, titulado "LLM as Hackers: Autonomus Linux Privilege Escalation Attacks" plantea un total de doce escenarios vulnerables donde se van a evaluar los diferentes modelos LLMs, hoy en día ya totalmente desactualizados con los nuevos modelos de Deep Reasoning.

En el planteamiento de la investigación es ver cómo se desempeñan los diferentes modelos LLama3 70B, SLMs y diferentes versiones de GPT-3.5-Turbo y GPT-4 Turbo, para que puedan ser corridos en local, y con poca ventana de contexto para lo que tenemos hoy en día. Casi com para poder llevar en una máquina de esas que llevan los pentesters en su mochila.

Figura 3:  Las vulnerabilidades de use-after-free se explican en detalle
en el libro de Linux Exploiting de la editorial 0xWord.
Consíguelo con Tempos de MyPublicInbox.

Los doce escenarios están basados en entornos creados para hacer los benchmarks de las herramientas - y en este caso de los LLMs -, donde como podéis ver, cada uno tiene que ser explotado con una técnica de Elevación de Privilegios diferente.
Como es normal, hemos publicado muchas veces artículos sobre Elevación de Privilegios en GNU/Linux utilizando diferentes técnicas, que son las que tienen que encontrar y explotar los LLMs. Os dejo por aquí los artículos sobre este tema que hemos publicado en el blog:
Para resolver estos escenarios los investigadores han creado una arquitectura de Agente de IA tal y como podéis ver a continuación. El agente, que se llama wintermute es el que recibe el comando del LLM con la llamada de "next-command" y le da los resultados con el Prompt de "update-state".
Para decidir el siguiente comando, el motor LLM tiene una base de datos con la historia del proceso completo, una base de datos con el "State" que son los "Facts" o hechos descubiertos hasta el momento, además de contar con una "pista" estática que puede meterse en la base de datos de "Guidance" que usa el pentester para guiar al agente.
Los Prompts de next-command y update-state son los que tenéis en la Figura 6 y Figura 7 respectivamente, donde como veis es bastante sencillo. No utiliza una capa intermedia de abstracción para configurar los comandos, como se hace con los MCP (Model Context Protocol) o como hacía el paper de ataques de redes de forma autónoma, donde se usaba la capa de Incalmo.
Sobre esta arquitectura, cada uno de los modelos va enviando los comandos, donde pueden dar problemas, ser irrelevantes, o simplemente estar mal escritos - que es uno de los problemas que se reduce drásticamente con las capas de abstracción -. 
Y el resultado final lo tenéis en la siguiente tabla, donde están todas las combinaciones entre escenarios y modelos, con o sin "hint" (pista), donde se puede ver qué modelo funcionó mejor resolviendo estos retos. Nada que no os podáis imaginar.
Mirando la tabla se puede ver que algunos modelos funcionan bastante mal con esta arquitectura, como el caso de Llama3 o GPT-3.5-turbo, pero GPT-4-turbo alcanza la resolución en una de las pruebas del 83% de los retos, lo que es muy prometedor. 

Conclusión

De nuevo, con los modelos de más avanzadas de Deep Reasoning de hoy en día, y usando una arquitectura con capa de abstracción, podemos estar casi seguros de que un Agentic AI construido para hacer estas funciones podría resolver el 100% de los escenarios o estar muy cerca de ellos. Tened en cuenta los resultados que obtuvieron los Agentic AI en los CTF que os publiqué la semana pasada. 

Figura 10: "The Art of Pentesting" El libro de Pablo González
 en 0xWord para formarse como pentester.

Sin embargo, me ha parecido interesante dedicarle una entrada a este paper, para que veáis de qué forma tan sencilla se puede hacer un Agentic AI para casi cualquier tarea. Con un par de Prompts y unas bases de datos de información está listo. Si ya le metes una arquitectura RAG con writeups de hacking, blogs que hablen de hacking - como éste - y herramientas conectadas con capas de abstracción como MCPs... seguro que podéis crear vosotros mismos agentes para casi todo.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  


jueves, mayo 15, 2025

Cómo saltarse los AI Guardrails con Invisible Characters & Adversarial Prompts para hacer Prompt Injection & Jailbreak Smuggling

Hoy vuelvo a hablaros de este tema que es de vital importancia para lo que estamos construyendo, pues estamos desarrollando muchos servicios con LLMs en el Backend, y las técnicas de Jailbreak y Prompt Injection no están ni mucho aún superadas por los equipos de seguridad, lo que está llevando a que todos los investigadores estén estudiando este tema. 
Hoy os hablo de un paper publicado por la empresa Midgard donde se centran en hacer Attack Smuggling  o AI Guardrail Bypass, como quieras llamarlo. Al final, como os contaba en la charla de Hackin’ AI: Creando una IA… ¿Qué puede salir mal?, no hemos creado los modelos de Inteligencia Artificial pensando en Seguridad desde el Diseño, y ahora tenemos que arreglarlo.
Básicamente, el trabajo que os cuento trata de saltarse los filtros de seguridad que evalúan los datos de entrada vía Prompt y los datos de salida, vía respuesta, para detectar los ataques. El paper se llama "Bypassing Prompt Injection and Jailbreak Detection in LLM Guardrails" y lo tienes aquí.
La idea es sencilla. Se trata de probar primero cómo los AI Guardrails se comportan con diferentes técnicas de emitir tokens pero usando codificaciones invisibles, y Prompts Maliciosos, para ver si se puede hacer un bypass de la detección. Tienes un resumen del trabajo el blog post que ha publicado la compañía, titulado: "Outsmarting AI Guardrails with Invisible Characters and Adversarial Prompts"

Los Guardarraíles de LLMS son esas herramientas como Llama Guard, Prompt Guard, Llama Firewall, CodeShield o AligmentCheck que están diseñados para controlar el Prompt que entra, y las acciones que se ejecutan para evitar los ataques de Prompt Injection o Jailbreak.


Figura 5: Demo de Llama Firewall en LlamaCON 2025

Una vez entendido cómo funcionan los AI Guardrails, la idea es enviar los Prompts Maliciosos utilizando Invisible Characters, y para eso hay que ver primero qué tipos de métodos existen para colar un token usando una de estas codificaciones y que el LLM objetivo se lo "coma".

Y ahora los resultados con los AI Guardrails. En este estudio han probado los siguientes, a saber: Azure Prompt Shield, Protect AI v1 & v2, Llama (Meta) Prompt Guard &Vijil Prompt, y los resultados en el Attack Surfare Rate con las diferentes técnicas anteriores son los que podéis ver con los Dataset de Prompt Injection.
Y con las diferentes técnicas de Jailbreak, los resultados son igual de buenos, donde como puede verse para todos los AI Guardrails existe alguna técnica de Invisble Character que permite saltarse el 100 % de los casos.


Ahora lo mismo, pero introduciendo Datasets de Prompts Maliciosos que cambian el comportamiento del flujo de ejecución del LLM en los diferentes ataques. Ejemplos como el del juego de rol que utilizó yo desde hace un par de años


En este caso, se han utilizado diferentes técnicas de pruebas para poder evaluar su funcionamiento contra los diferentes modelos de AI Guardrails usando Adversarial Machine Learning (AML) Evasion Techniques, basadas en reemplazo de palabras para saltarse un clasificador basado en algoritmos de Machine Learning, que es lo que hacemos en muchos de las aplicaciones de Ciberseguridad.

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

Las técnicas de AML Evasion que se han utilizado para la prueba son las que tienes detalladas a continuación en la siguiente tabla.
Y los Attack Surface Rate para cada una de estas técnicas aplicado a los DataSets de Prompt Injection y Jailbreak, son los que tienes en las siguientes tablas, donde como se puede ver todos los AI Guardrails se ven afectados por estas técnicas.
Después de ver todo este trabajo, la primera reflexión es que, viendo la avalancha de ataques de Prompt Injection y Jailbreak, y cómo las protecciones aún no están funcionando, es que estamos como cuando diseñamos los lenguajes de creación de aplicaciones web sin pensar en seguridad por diseño o cuando los sistemas operativos no tenían una arquitectura de seguridad desde su concepción. Ahora, vamos a pasar un largo tiempo sufriendo por esto, lo que nos va a llevar a muchos incidentes de seguridad que irán llegando poco a poco... veremos..

¡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