Mostrando entradas con la etiqueta Prompt Injection. Mostrar todas las entradas
Mostrando entradas con la etiqueta Prompt Injection. Mostrar todas las entradas

sábado, agosto 23, 2025

PROMISQROUTE para GPT-5: Un ataque de downgrade forzando el Routing para hacer Jailbreak

Hoy no sé si te trata de un bug o de una debilidad que ayuda a explotar los bugs, pero desde luego es un Security Issue en la arquitectura de GPT-5 que ha sido publicado esta semana bajo el nombre de PROMISQROUTE, que ha es el acrónimo elegido con para el ataque, bajo la descripción de "Prompt-based Router Open-Mode Manipulation Induced via SSRF-like Queries, Reconfiguring Operations Using Trust Evasion." Sí, ha quedado un poco forzado, pero yo fui que el que denomino a un proyecto FOCA (Fingerprinting Organizations with Colleted Archives), así que no voy a quejarme para nada del nombre elegido.
Lo que es cierto es PROMISQROUTE, sea vulnerabilidad o debilidad, permite evitar los Guardrails de GPT-5, haciendo que una aplicación conectada a GPT-5 pueda ser degradada a modelos más inseguros con los que se pueda hacer un ataque de Jailbreak. Es decir, a pesar de estar conectado a GPT-5, puedes acabar sufriendo un Jailbreak de GPT-4 porque te han hecho un downgrade con PROMISQROUTE.

La magia de todo esto es que GPT-5 es un modelo muy costoso, que no tiene sentido utilizar en todo tipo de Prompts, por lo que la arquitectura con la que se ha diseñado GPT-5 hace un enrutado, un routing del Prompt hacia el modelo más eficiente en cada casa, lo que permite ahorrar costes y ganar en eficiencia en muchas ocasiones.
El gráfico superior muestra una arquitectura - inferida, así que no tomes como que es 100% fiable - la estructura de modelos que tiene GPT-5 para resolver las Prompts. Esta arquitectura de modelos permite hacer una gestión eficiente de los recursos tanto en costes como en tiempo de repuesta, como en resolución de las peticiones.
Así, cuando llega un Prompt, la arquitectura procesa a tres niveles el Prompt, eligiendo en la Capa 2 el mejor modelo para resolver el Prompt enviado por el usuario, así que se analiza la petición que envía el usuario y se elige uno de los modelos de la Figura 3 para que la resuelva.
No es lo mismo una tarea sencilla y creativa, que una resolución compleja que exija un modelo de Deep Reasoning como GPT-5 Thinking, que seguro que da la mejor respuesta. Esto lo decide el proceso de Routing en la Capa 2 analizando la petición del usuario. La estimación de distribución de cargas de los diferentes modelos, según el uso de los usuarios se estima así.

En el interfaz de ChatGPT esto lo puedes ver con las opciones de GPT-5 que tienes, donde si eliges AUTO dejas que sea el Router el que seleccione el modelo para atenderte, mientas que si pones GPT-5 Thinking estás forzando el modelo concreto de GPT-5 con los Guardrails que trae.
Pero si el Router está en AUTO y te asignan un GPT-4o los Guardrails que funcionan son los de este modelo, y eso implica que si hay un Jailbreak conocido para él, entonces funciona. El truco entonces, si una App o Service está conectado a GPT-5 en modo AUTO, está en forzar que use un modelo anterior del que se conoce una técnica de Jailbreak, y así conseguir saltarse las protecciones.

Un ejemplo practico de PROMISQROUTE

En este primer ejemplo, com podéis ver, se pide un Prompt que implica un análisis, así que aunque está en modo AUTO, la arquitectura de ChatGPT enruta hacia el modelo de Deep Reasoning de GPT-5 Thinking y los Guardrails detectan el Harmful Mode y bloquean el Prompt Malicioso.
Si veis en la Figura 8 anterior, GPT-5 detecta el Harmful Mode porque el Router ha asignado GPT-5 Thinking para resolver ese Prompt bloquea la petición, mientras que en la figura siguiente, en modo AUTO, GPT-5 es afectado por el Jailbreak y ejecuta el Prompt Malicioso saltándose la detección del Harmful Mode sólo porque se ha forzado una respuesta rápida con PROMISQROUTE.
Para forzar el enrutado hacia modelos anteriores, es decir, para hacer el Downgrade de modelos en GPT-5 lo que propone PROMISQROUTE es utilizar peticiones en el Prompt que metan la importancia de velocidad para que el tiempo de respuesta sea relevante, lo que evita los modelos pesados como el modelo de Deep Reasoning GPT-5 Thinking


Si seleccionamos el uso de GPT-5 Thinking vemos que el Prompt de PROMISQROUTE no funciona, por lo que afecta sólo cuando está en modo AUTO. Si esto es así, utilizar Prompts como los siguientes permiten forzar el enrutamiento hacia modelos anteriores y conseguir evitar los Guardrails de GPT-5.
Al final, como podéis ver, no es un método de Jailbreak, y tampoco creo que sea una vulnerabilidad, sino una "Weakness" que, conocida, ayuda a seleccionar el punto menos protegido de una aplicación o un servicio que esté utilizando en su arquitectura GPT-5 con el routing AUTO. Muy curioso.
Si te interesa la IA y la Ciberseguridad, tienes en 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)  


viernes, agosto 22, 2025

Hacking IA: Indirect Prompt Injection en Perplexity Comet

Hace un par de días, el equipo del navegador Brave que está dotando a este de un Asistente AI en modo Agente, publicó una vulnerabilidad de Indirect Prompt Injection en el Asistente AI en modo Agente de Perplexity, llamado Comet, y lo han hecho con una Proof of Concept que puedes leer en la web, y que te explico por aquí.
El ataque se basa en un esquema bastante sencillo, como controlar una página web que la víctima vaya visitar con Perplexity Comet y dejar en ella - ya sea una web maliciosa, o un comentario en una plataforma donde los usuarios puedan dejar posts o comentarios. 
El ataque es un ejemplo de los nuevos tipos de vulnerabilidades a los que nos enfrentamos con las Apps & Services que utilizan IA en sus back-ends o front-ends, donde hemos visto ya varios ejemplos similares a estos.
Una vez que tenemos una web en la que se ha podido publicar el Prompt Injection, basta con que la víctima pida un simple "Summarize this web" en Perplexity Comet, para que se comience a ejecutar el Prompt Malicioso. 
Como podéis ver en este proceso, donde se le pide que entre en las opciones de Perplexity y saque los datos de la cuenta. Y por supuesto, Perplexity Comet se "desalinea" de su tarea principal y comienza a ejecutar estas acciones en modo Agente.

Para la prueba de concepto, con el objeto de robar la cuenta, el ataque busca robar el código de verificación de un cambio de contraseña, o de cualquier otra acción que use un 2FA basado en un token enviado al e-mail.
Por supuesto, se aprovecha de algo que hacemos muchos, que es tener una pestaña siempre abierta con el correo electrónico de Gmail, por lo que se puede pedir a Perplexity Comet que busque el código recibido y lo copie.
Después, el Prompt Malicioso le va a pedir a Perplexity Comet que coja la información a la que ha accedido, es decir, la dirección de correo electrónico de la cuenta de Perplexity, y el token de firma  de acciones y lo publique en un comentario de Reddit.
El resultado de este proceso en modo agente es que al final, el comentario queda publicado justo después del comentario con el Prompt Malicioso, tal y como podéis ver en la imagen siguiente.
El proceso completo lo tenéis en este vídeo que han publicado en el artículo de Indirect Prompt Injection in Perplexity Comet donde al final, como resumen Perplexity Comet publica nada, que es lo que se le ha pedido en el Prompt Malicioso.
Si te interesa la IA y la Ciberseguridad, tienes en 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, julio 16, 2025

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.


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

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.

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.
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:
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.
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)  


martes, junio 24, 2025

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


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


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


domingo, mayo 25, 2025

Hacking Gitlab Duo: Remote Prompt Injection, Malicious Prompt Smuggling, Client-Side Attacks & Private Code Stealing.

Esta misma semana se ha publicado un trabajo de investigación sobre vulnerabilidades del GitLab Duo que es muy interesante por muchos aspectos, y por utilizar muchas de las técnicas de las que cada día hablamos más en el mundo del Hacking de Productos & Servicios hechos con IA. En este caso, los investigadores de Legit han demostrado cómo se podía utilizar GitLab Duo para atacar a otros usuarios con librerías infectadas y construir malware, para inyectar código malicioso en los resultados de GitLab Duo y para robar código privado, muy interesante técnicamente toda la investigación.
El artículo completo lo podéis leer en "Remote Prompt Injection in GitLab Duo Leads to Source Code Theft", y aquí tenéis una explicación del trabajo que os he resumido - y ampliado - para ver si soy capaz de explicarlo con claridad.
GitLab Duo es el asistente con IA de la plataforma GitLab que te ayuda a trabajar con tu repositorio de código, y que está disponible para todos los usuarios. Utiliza, por supuesto, una arquitectura de DeepReasoning, así que permite realizar tareas complejas, escribir código, puede manipular documentación, y para hacer bien el trabajo, cuenta con su Memory.

Para entender el ataque bien, os recomiendo que leáis antes el artículo de "GenAI Apps & Services: Cómo explotar arquitecturas RAG con Plugins Inseguros" porque tiene algunas similitudes en cuanto al ataque. En este artículo teníamos un servicio representado por ChatGPT, y le dábamos capacidades para hacer cosas sobre datos conectados (ficheros en One-Drive), y aplicaciones (enviar correos electrónicos). Si no había un entorno aislado multiusuario, un atacante podría ver los prompts de otro usuario, o los ficheros a los que tuviera acceso el modelo de IA, en ese caso, ChatGPT

Hacking Gitlab Duo:

En el ejemplo de GitLab Duo, el investigador hace un ataque de Prompt Injection que pone en el código fuente de un programa como un comentario, y con un simple "Explain this code" o hacer cualquier acción sobre ese código, se puede ver cómo GitLab Duo lo procesa.
Visto esto, para enviar estos ataques a otro usuario lo que hace es proponer un cambio en el un código de otro usuario, y en los comentarios introducir el Remote Prompt Injection, que en este caso inicial se trata de meter una librería de código maliciosa, por ejemplo, para robar los usuarios y contraseñas de un proceso de Login.
Cuando la víctima dueña del código solicite a GitLab Duo cualquier comando sobre el código que está visualizando del cambio propuesto, el Prompt Injection se ejecutará, y realizará un Memory Poisoning, dejando en la memoria que si en el futuro se solicita, por ejemplo, una página de Login, meta esa librería maliciosa. 
Para hacer este ataque mucho más invisible para la víctima, el atacante hace uso de técnicas de Prompt Smuggling para saltar los posibles guardarraíles del modelo usando trucos como los vistos en el artículo "Cómo saltarse los AI Guardrails con Invisible Characters & Adversarial Prompts para hacer Prompt Injection & Jailbreak Smuggling" , además de para hacer menos visible el Prompt en el código y el panel que pueda ver la víctima.

Como se puede ver en la imagen anterior, en la parte de Changes queda en color blanco (codificado en KaTeX), y además queda en Unicode usando codificación Base16 para meter los Prompts Maliciosos.

En este caso la demo la hace directamente con la petición del Login, así que la infección de la Memory no tiene que esperar a la petición futura.

Ahora, si vemos el proceso completo de GitLab Duo, se puede ver cómo ha inyectado la librería maliciosa, y cada vez que procesa el usuario y la contraseña llama a la función de esta librería que puede robar las cuentas tranquilamente.
Una vez que se ha completado este ataque, es posible imaginar muchos otros ejemplos. Por ejemplo pedirle que en la respuesta GitLab Duo muestre un enlace que la víctima pueda hacer clic para llevarle a una infección. 

Y por supuesto, cuando llegue la ejecución del Prompt en el GitLab Duo de la víctima, se producirá esa respuesta que se ha solicitado, tal y como se ve en la imagen siguiente.
Una vez visto este comportamiento, se pueden reproducir todos los ataques Client-Site en Web Applications, ya que tenemos un servidor - el de GitLab - desde el que enviar código a una víctima - desde Prompt inyectado -.
El siguiente ejemplo fue hacer HTML Injection y realizar ataques de Cross-Site Scripting (XSS), en este ejemplo para "Rickrollear" un poco.
Com se muestra en la imagen siguiente, este ataque también funcionó, por lo que se ha utilizado el modelo LLM como forma de atacar a otros clientes.
La última de las PoCs es para robar el código fuente de un programa de otro usuario que está en PRIVADO. En este caso aprovecha que GitLab Duo puede usar la herramienta merge_request_reader que tiene acceso a todos los códigos - públicos y privados -, así que con este Prompt se le pide que meta el código en un parámetro en Base64 como parte de un enlace.

Figura 16: Prompt para robar código privado

Al final, usando este ataque Remote Prompt Injection se solicita a GitLab Duo que use una herramienta que tiene conectada al modelo -  y que le da permisos para acceder a datos privados - que explique un merge_request privado, y que pinte la salida como parámetro de un enlace. 

Figura 17: Enlace malicioso con el código fuente robado

Para poder hacer este ataque, ha sido necesito meter el Remote Prompt Injection en una petición de cambio enviada a un código de la víctima, utilizando las técnicas de ASCII & Malicious Prompt Smuggling. Después, cuando al víctima ha pedido cualquier comando a GitLab Duo, el Malicious Prompt se ha ejecutado y se ha creado un enlace malicioso con el código fuente del programa a robar como parámetro. Cuando la víctima hace clic en él se envía el GET Request con el código fuente en la URL al servidor controlado por el atacante.


Reflexión final

El mundo de la Inteligencia Artificial a las profesiones de cibeseguridad nos ha abierto tres nuevas disciplinas en las que tenemos que trabajar. La primera es la de utilizar los nuevos modelos de IA para hacer ataques en los procesos de Pentesting, Ethical Hacking o Red Team. La segunda disciplina es utilizar la IA como forma de aumentar las capacidades de los equipos de seguridad, para automatizar tareas en el SOC, procesos de patching por IA, detección de anomalías, forensics, y cualquier proceso del Blue Team y los equipos de CERT & CSIRT
Por último, lo que vemos aquí es un ejemplo de la disciplina de aprender a atacar las nueva arquitecturas basadas en modelos de IA, Agentic AI, etcétera, que es lo que recoge el OWASP Top 10 de Productos & Servicios basados en LLMs. Un campo completo para el que aprender a diseñar nuevos ataques, basados en Prompt Injection, Jailbreak, Memory Poisoning, Malicious Prompt Smuggling, Guardrails Bypass, Data Poisoning, etcetera. Todos los problemas vistos en el artículo de hoy, el equipo de GitLab ya los parcheó, que se hizo un reporte responsable, pero son un ejemplo perfecto del tipo de ataques al que nos vamos a enfrentar hoy en día. Entretenidísimos vamos a estar.

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)  


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