Cómo solucionar tres "Big Problems" del "Agentic AI Coding" usando Neo

El avance de la IA Generativa y Agéntica no es nada menos que espectacular y, casi indudablemente, la mayor y más rápida revolución tecnológica de la historia. Llevamos unos años oyendo la promesa de agentes autónomos y desarrolladores multiplicados por diez, sin embargo, cuando miras a un equipo de desarrollo de software en un entorno corporativo, los atascos aún son los de siempre. La realidad es que aunque las demos presentan unos escenarios idílicos, esta tecnología no está todavía al nivel al que se nos presenta.

Figura 1: Cómo solucionar tres "Big Problems" del "Agentic AI Coding" usando Neo

Neo es el producto que hacemos en Sagittal AI, una empresa que no vende magia, sino que trata de maximizar el partido que se le puede sacar a la IA, aceptando sus limitaciones, y del cual hablé en esta conferencia que os dejo por aquí.

Figura 2: Por qué la IA no ha mejorado el rendimiento de tus Developers ... por ahora

Pero hoy os quiero hablar de tres problemas concretos que, si has trabajado en equipos de desarrollo de software seguro que conoces bien. Vamos a verlos uno a uno.

Problema: La interfaz. De secretario/a del bot a delegar trabajo

El patrón actual te será familiar: abres el chat o el plugin del IDE, te conviertes en “prompt engineer”, le explicas al agente lo que quieres, le pegas medio ticket, añades fragmentos de código, corriges lo que ha entendido mal… y vuelta a empezar. El asistente de IA no está tanto a tu servicio como tú al suyo. 

El problema es que con ese esquema no puedes delegar de verdad. Tienes que estar presente, pendiente del chat, confirmando el plan, cada paso, y desbloqueando al agente cuando se atasca, o reconduciendo cuando se pierde. El cuello de botella sigue siendo tu tiempo. Mientras el humano tenga que estar “en la sala” para que las cosas avancen, la productividad solo sube un poco, nunca un orden de magnitud. Algunos CLIs e IDEs han intentado introducir gestión de tareas en background pero, en la práctica, son difíciles de configurar y usar y casi nadie las adopta.

Figura 3: Neo funciona integrado en tus plataformas de ingeniería del software

Neo resuelve este problema de forma que la interacción entre IA y humano sea exactamente la misma que entre humano y humano. No hace falta una interfaz de usuario nueva. Si se trata de delegar, ya tenemos herramientas colaborativas para delegar y trabajar en equipo: Jira, GitHub, Azure DevOps, Confluence, Figma… 

Figura 4: Tools con las que se integra Neo

A Neo se le asignan tareas como a cualquier miembro del equipo, se encarga de buscar contexto en tus tickets, documentos, código, crear la rama, implementar cambios, escribir pruebas, resolver el CI si falla, y actualizar el estado de las tareas según el "Way of Working" del equipo. 

Figura 5: Pull request diagrams

Tú te vas a otra cosa y vuelves cuando hay PR lista para revisar, y lo haces en herramientas que llevan 15 años perfeccionando la UX para revisar código. ¿Que quieres iterar? Comentarios en la propia PR ¿Que no te gusta el resultado? Descarta la PR, y no has perdido ni el dinero ni el tiempo.

Problema: Seguridad. CVEs críticos y teatro de permisos

La mayoría de los desarrolladores trabajan en portátiles no plataformados y con permisos de administración. Los agentes que ejecutan corren con sus mismos permisos y las mismas credenciales que usan para acceder a repositorios, pipelines y entornos en la nube. Si alguien compromete el Agente IA o uno de sus conectores, no se queda en la máquina local: entra en la organización con la identidad del desarrollador.

Figura 6: Cosas que puede hacer Neo en tus equipos de ingeniería

Los MCPs y “tools” enchufados al Agente AI agravan aún más el tema. De repente el modelo puede hablar con bases de datos internas, paneles de administración o scripts de automatización. Cuando algo falla, lo que aparece publicado son CVEs de impacto alto o crítico, porque no estamos hablando de un pequeño leak, sino de ejecución remota, escaladas de privilegios o acceso directo a datos sensibles. Si no, respasa el libro de "Hacking IA: Jailbreak, Prompt Injection, Hallucinations & Unalignment.

Figura 7:"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

Los fabricantes de estas herramientas tratan de mitigar el problema interrumpiendo al Agente IA para que el usuario confirme el uso de la herramienta o recurso, pero esto deja de hacer al agente independiente y al final se acaban ejecutando en un modo “sí a todo” que invalida la mitigación.

Neo parte de un planteamiento distinto. La configuración es gestionada por los equipos de IT y seguridad, no por cada desarrollador en su portátil. Sus permisos se acotan por integraciones y políticas corporativas, de forma parecida a cuando incorporas a un contractor externo. Además, no es un sistema en el que se considera al LLM inteligente y se le pone en un loop hasta que consiga su objetivo.

Figura 8: Fix vulnerabilities before they happen

En su lugar, Neo tiene una serie de flujos deterministas optimizados para tareas de software, lo cual permite meter validaciones en cada paso del flujo, y dar a cada paso exclusivamente el contexto que necesita. Siguen siendo LLMs y el determinismo nunca está garantizado, pero Neo consigue de esta manera una ejecución mucho más predecible.

Problema: Productividad. acelerar solo al programador no mueve la aguja

Si preguntas a los desarrolladores, la mayoría dice que con IA va más rápido. Pero cuando miras las métricas del equipo, ya sea tiempos de entrega, funcionalidades desplegadas, bugs resueltos, … parece que los datos no concuerdan con la experiencia individual.

Al mirar el ciclo completo de una funcionalidad, queda bastante claro lo que está pasando: alguien pide una funcionalidad, se redacta y refina la especificación, se espera a dependencias (diseño, traducciones, otros equipos), se asigna, se desarrolla, se revisa el código, se diseña el plan de pruebas, se ejecutan los tests, se corrigen fallos y, si todo va bien, se despliega. 

Figura 9: Project Plan de Ingeniería del Software

El tiempo que el desarrollador pasa escribiendo código es sólo un tramo de esa cadena. Aunque reduzcas a la mitad este tiempo, las dependencias, revisiones, validaciones y esperas siguen igual. El lead time de la funcionalidad casi no se mueve.

Figura 10: Code and test plans in Azure DevOps

Neo está diseñado para este escenario. A Neo no le das un prompt de dos líneas y por el otro lado sale un producto terminado, porque a un miembro del equipo tampoco le pides algo así. Neo ayuda a todos los miembros del equipo en todas las fases del ciclo de vida, aportando un poco a cada uno, acortando cada espera, y automatizando cada tarea monótona.

Como todo esto ocurre en las mismas herramientas colaborativas que ya usas para medir, el impacto se ve en lead time, throughput y calidad, no solo en la sensación subjetiva.

Cómo probar Neo en tu empresa.

Neo no es una herramienta para un proyecto individual ni para un equipo pequeño. Para eso, hay otras herramientas mejores. Neo no es tan potente como el último agente del que hayas oído hablar esta semana trabajando en un problema de forma autónoma todo un fin de semana. Ninguna demo de Neo te va a dejar boquiabierto.

Neo está específicamente diseñado para un entorno corporativo con equipos de entre 5 y 15 personas que siguen un proceso, ya sea ligero o pesado, coordinado en herramientas colaborativas y donde la especificación suele estar dispersa en varias herramientas y cambia constantemente.

Figura 11: Comienza a probar Neo desde hoy mismo

Puedes ver varias demos de Neo en acción para hacerte una mejor idea del concepto, y contactar con Sagittal AI para un piloto en tu empresa.

Un saludo,

Autor: José Palazón, CEO de Sagital.ai

 Contactar con José Palazón

Reprompt Attack en Microsoft Copilot con Spear Phishing

Los investigadores de Varonis han hecho pública su investigación sobre Reprompt en Microsoft Copilot que permitía ejecutar comandos con un solo click en un correo electrónico, generar acciones y exfiltrar datos. El reporte se hizo de forma responsable, y Microsoft ha configurado Safeguards para evitar este tipo de ataque, pero merece la pena ver su funcionamiento.

Figura 1: Reprompt Attack en Microsoft Copilot con Spear Phishing

El ataque se aprovecha del parámetro "http://copilot.microsoft.com/?q=" que permite inyectar un Prompt en una URL de Microsoft Copilot, lo que permite hacer Spear Phishing sin necesidad siquiera de que la víctima invoque un Prompt de Copilot, y una vez que se ha hecho clic, el resto es todo automático.

Figura 2: Repromt Attack

Es decir, que un solo clic, y se acabó. Esto puede hacerse también en otro tipo de Client-Side Attacks que hagan al usuario navegar con sus credenciales a la URL que desea el atacante, así que navegar con la sesión de Microsoft Copilot, y se acabó.

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

Una vez encontrado el punto de inyección de Prompts en Copilot - mediante un Spear Phishing, por ejemplo, el truco de Repromt se basa en pedirle a Microsoft Copilot que haga lo que haga, lo haga dos veces porque la primera vez, el modelo se niega a navegar a una URL remota, pero pidiéndoselo que lo haga dos veces lo hace.

Figura 4: Spear Phishing con Link a Copilot para hacer un Reprompt Attack

Este comportamiento puede ser por motivos de rendimiento, por asistir al usuario, y por resolver correctamente el Prompt que se le pide, pero lo cierto es que en las PoC publicadas es como lo hacen.

Figura 5: Ataque de Exfiltración de Memory con Reprompt

En la primera PoC, que es una exfiltración de un dato secreto en la Memory de Copilot, se le pide que construya una URL como si fuera un juego, pero dentro de ella debe incluir la información secreta de la memoria del usuario, así como el nombre de la víctima.

Figura 6: Valor a exfilrar de la Memory

El proceso completo comienza con el clic en el correo de Spear Phishing que lleva a la ejecución del Prompt en Microsoft Copilot y la exfiltración de los datos en el Log del servidor web controlado por el atacante que se usa para sacar la información privada.

Figura 7: Valor exfilrado en el log del servidor del atacante

En el vídeo que tenéis aquí podéis ver el ataque completo en menos de un minuto, que es lo que se tarda en hacer un clic y que tus datos privados se haya exfiltrado.

Figura 8: PoC 1 de Reprompt Attack en MS Copilot

Este ataque se puede complejizar mucho más, y en cada petición, encadenar un nuevo Prompt para exfiltrar datos usando técnicas de Prompt Injection camuflando los nuevos Prompts dentro de formatos de imágenes JPG que son entregadas como texto, de tal manera que cada vez que se pide una imagen, se le da un nuevo Prompt.

Figura. 9: Encadenado de Prompt Injection

Usando esta técnica, la PoC 2 realiza la exfiltración del nombre del usuario, la localización, el último Prompt, la fecha, etcétera, encadenando una petición con otra usando fases de explotación diferente. 

Figura 10: Exfiltración encadenada 

Las salidas de todas esas exfiltraciones acaban quedando en el log del servidor controlado por el atacante, como podéis ver en las imágenes, y en el vídeo siguiente.

Figura 11: PoC 2 de Reprompt Attack en MS Copilot

Microsoft ya ha puesto salvaguardas para evitar que este ataque se pueda reproducir, pero abre una nueva vía de ataques que hay que tener presente en la implementación de servicios digitales que puedan ser explotados con Prompts en parámetros, además del truco de "hazlo dos veces".

Figura 12: Hacking & Pentesting con Inteligencia Artificial.

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

Rafael Troncoso, Javier del Pino y Chema Alonso, 

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)  

Adulteración del Knowledge Graph de una arquitectura RAG para proteger los datos de un servicio de Inteligencia Artificial

Las arquitecturas RAG (Retrieval Augmented Generation) son hoy en día una de las formas más sencillas de conectar el conocimiento de una organización con un modelo LLM para explotar los datos de una organización utilizando servicios digitales basados en IA. En el caso de las plataformas Microsoft, se utilizan los Knowledge Graph (KG) que llevan tantos años desarrollando, así que a los servicios que usan una arquitectura RAG con un KG se le llama GraphRAG, y están conectados al conocimiento de una persona o una empresa.

Figura 1: Adulteración del Knowledge Graph de una arquitectura

RAG para proteger los datos de un servicio de Inteligencia Artificial

Este conocimiento almacenado en los Knowledge Graphs le dan el contexto necesario a los LLM para que puedan resolver los Prompts que se les solicita de manera efectiva, y es como funciona, por ejemplo, la arquitectura de Microsoft 365 Copilot.

Figura 2: Arquitectura con Knowledge Graph de Microsoft 365 Copilot

Por supuesto, si ese Knowledge Graph no son los datos de un usuario, sino los datos de una compañía completa, estaríamos hablando de información muy sensible de las empresas, por lo que hay que tener mucho cuidado de que alguien robe esos datos, pero aún más. Una forma de atacarlos es lo que explicamos en el artículo de "GenAI Apps & Services: Cómo explotar arquitecturas RAG con Plugins Inseguros" del que también hablé en esta conferencia:

Figura 3: Hacker & Developer in the Age of GenAIpor Chema Alonso en la dotNET 2024

Pero, suponiendo que alguien se lleva directamente una copia completa, ¿podríamos hacer que si un atacante tuviera acceso al Knoledge Graph de una arquitectura RAG como la anterior sólo recibiera información errónea en las respuetsas? De eso trata el artículo: "Making Theft Useless: Adulteration-Based Protection of Proprietary Knowledge Graphs in GraphRAG Systems"

Figura 4:Making Theft Useless: Adulteration-Based Protection

of Proprietary Knowledge Graphs in GraphRAG Systems

Hay que tener en cuenta que si un atacante se llevara el Knowledge Graph (KG) de una empresa, necesitaría muy poco para replicar el funcionamiento del servicio digital basado en la arquitectura GraphRAG robada, ya que casi todos se basan en piezas comunes, donde lo diferencial son los datos contenidos en el Knowledge Graph de la compañía, que además lleva tiempo generar.

Figura 5: Si un atacante roba el Knowledge Graph (K)

puede replicar el servicio y usar los datos del KG

Una vez clonada la arquitectura, se podría acceder al conocimiento y la información que el Knowledge Graph contenga, haciéndole las preguntas correctas, así que los investigadores lo que han estado pensando es en cómo hacer que esa base de conocimiento esté adulterada y solo los que lo han adulterado sepan entender las respuestas, mientras que para los demás será respuestas llenas de alucinaciones.

Figura 6: La propuesta es Adulterar el Knowledge Graph.

Como se puede ver en la imagen anterior, la propuesta del trabajo es Adulterar el Knowledge Graph de forma que sólo los usuarios legítimos saben cómo está adulterado, y por tanto, "desadulterar" la información proveniente del KG antes de que esta sea enviada por el servicio RAG (GraphRAG) al LLM.

Hay que tener en cuenta que el motivo por el que se crean las arquitecturas RAG es para que los LLM trabajen sobre el conocimiento privado de unos datos. Si esos datos están adulterados, trabajaran sobre información errónea. Así, los usuarios no autorizados, si no saben quitar los nodos adulteraros en el KG, lo que conseguirán es que el Prompt que se genere para el LLM del servicio no funcione y retorne información errónea, o directamente el LLM no sepa como responder.

Para ello, el proceso de adulteración busca cuáles son los nodos más clave del Knowledge Graph (Key Nodes), para conseguir que esos nodos estén presentes en el mayor número de respuestas de enriquecimiento de Prompts provenientes del KG y que tengan información adulterada para que sirvan ellos de adulterantes de todas las repuestas.

Figura 7: Prompt for Generating Nodos Adulterantes

Esos Key Nodes serán analizados y adulterados, por ejemplo, con valores que sean de la misma entidad, pero con valores diferentes semánticamente, como se ve en el Prompt de generación de nodos adulterantes de la imagen anterior. Este proceso podrá hacerse con diferentes nodos, y los cambios deben ser conocidos por los usuarios legítimos.

Figura 8: Proceso de Adulteración de Key Nodes

El framework se llama AURA

Como se ve en la imagen anterior, se buscan los módulos más relevantes, intentando que se consiga que corrompan el máximo posible de las respuestas. Eso implicará que haya que generar adulteraciones para cada uno de esos nodos adulterantes, pero el GraphRAG envíe el Prompt original enriquecido con datos que contiene alguno de los nodos adulterantes, entonces se conseguirán respuestas parciales, con alucinaciones o directamente no se obtendrá respuesta.

Figura 9: Resultados experimentales

En la tabla anterior tienes el HS "Harmfulness Score", que es el porcentaje de Prompts que antes de la adulteración eran contestados correctamente y después del adulterado de los nodos se contestan mal o no se contestan. Como se puede ver, con diferentes Datasets de prueba usando diferentes LLMs, los resultados son todos superiores al 94%.

El segundo indicador es el ARR "Adulterant Retrieval Rate", o lo que es lo mismo, en qué porcentaje de los Prompts se han incluido los nodos adulterantes. En este caso, en el 100% de los casos, ya que el algoritmo de selección de Key Nodes ha cubierto la totalidad de las rutas de respuestas.

Figura 10: Tipos de error inyectados con la adulteracíon

En el paper tenéis más tablas y mediciones, pero yo me he querido centrar solo en las que he considerado más relevantes para entender el estudio, y éste último gráfico representa los porcentajes de respuestas erróneas parcialmente, completamente, o que directamente el modelo LLM se ha negado a contestar.

El truco, para que el servicio digital legítimo sepa cuáles son los nodos adulterantes que debe eliminar antes de enviar el Prompt enriquecido con Nodos del Knoledge Graph, es que en el proceso de adulteración se marcan todos los nodos con metadatos cifrados, de tal manera que, como se ve en el apartado 4 de la Figura 8, si el metadato cifrado - con la clave de descifrado que solo tiene el servicio legítimo - dice que es un nodo adulterante, se retira y listo.

Figura 11: Marcado de nodos con metadatos cifrados

De esta forma, se evita tener que cifrar todo el Knowledge Graph - que lo haría computacionalmente inviable a día de hoy, y solo se cifran las marcas de aduletración -. Un tema muy interesante, sin duda, y si te gusta este mundo, te recomiendo que te compres el libro de "Hacking & Pentesting con Inteligencia Artificial" que te va a encantar.

Figura 12: Hacking & Pentesting con Inteligencia Artificial.

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

Rafael Troncoso, Javier del Pino y Chema Alonso,

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)  

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.

Figura 1: CoPhish: Malicious CoPilot Agent para robarte tus Tokens OAuth

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.

Figura 2: RamsonCloud O365: Paga por tus mensajes de correo de Office 365

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.

Figura 3: Demo de Sappo en Office hecha por Chema Alonso

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.

Figura 4: Restricciones para el registro de Apps y concesión de tokens OAuth

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.

Figura 5: Nuevas restricciones de seguridad anunciadas

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.

Figura 6: WebApp para un Asistente de CoPilot

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.

Figura 7: Malicious Copilot Agent

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.

Figura 8: Solicitando permisos a usuarios internos del mismo Tenant

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

Figura 9: Cuando se usa una App registrada externamente para atacar al administrador

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.

Figura 10: URL De Copilot para las apps de Phishing

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.

Figura 11: Autenticación en el Bot Token Service

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.

Figura 12: Token OAuth autorizado en petición HTTP al host del atacante

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.

Figura 13: Creando un Asistente en Copilot

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.

Figura 14: Workflow en el trigger de Login

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.

Figura 15: Flujo de envío de Token OAuth a servidor controlado por el atacante.

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.

Figura 16: Configuración de la aplicación del Malicious CoPilot

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)