Copilot en la sombra: abusing OAuth & flujo delegado en Power Platform

 El contenido de este blog proviene de la charla que realicé en la RootedCon 2026 en Madrid. Tras realizar toda la investigación y pruebas, me pareció interesante compartir todo el contenido por aquí y así llegar a más gente. La idea de la investigación en septiembre-octubre del 2025 fue clara: ¿Cuánto puede llegar a confiar un usuario final en una solución IA?

Atención: En ningún momento el propósito de este post es de ayudar a nadie a generar casos de uso de phishing, sino de avisar y crear conciencia sobre el poder de la tecnología mal usada. Además, adrede, hay algunos pasos que no se han descrito para que no pueda ser reproducido.

Con el auge de Copilots, IAs generativas y cuando ya podemos ver vídeos en RRSS que nos cuesta distinguir si son reales o no; la misma IA puede usarse "con malas intenciones" para confundir al usuario final, robar credenciales y aprovechar su sobre confianza para infiltrarse en las organizaciones y robar sus datos. Y si en este caso es aprovecharse de la confianza que tenemos en los productos de Microsoft, veréis que aún es mucho más fácil aplicar "ingeniería social" para engañar al usuario.

El caso que os traigo hoy es sencillo: Un usuario cualquiera recibe acceso a una URL confiable de Microsoft con el pretexto que se ha publicado un Copilot que le puede ayudar a [introducir aquí cualquier tarea del estilo finanzas, Recursos Humanos, etc]. El usuario comprueba que está publicado en un entorno confiable e interacciona con el Copilot. Sin saberlo, ha aceptado delegar sus permisos al bot y por detrás, el autor del bot ha sido capaz de descomponer el token generado y utilizar ese permiso para realizar accesos a los datos de la organización en nombre del usuario. Tenemos robo de token, abuso de token y abuso de la cadena de la delegación de permisos.

¿La clave? El desconocimiento del usuario. La principal ciberamenaza del usuario.

Cuando propuse esta charla para la RootedCon no sabía que los investigadores del portal Datadog habían encontrado el mismo "procedimiento" para abusar los tokens. Os dejo la referencia a su investigación; merece la pena echarle un ojo pues explicará muchos conceptos en más detalle que yo misma: CoPhish: Using Microsoft Copilot Studio as a wrapper for OAuth phishing | Datadog Security Labs. Sin embargo, yo logré en mi caso algo que ellos no pudieron: confundir y ocultar los permisos que el usuario estaba aceptando al interaccionar con el Copilot.

Sin embargo, vamos por partes a desgranar cómo funciona este proceso.

¿Cuáles son las 3 entidades e identidades clave en este ejemplo?

Dentro de nuestro PaaS, tenemos 3 entidades y 4 componentes distintos que interaccionan de modos distintos y la identidad de éstos se materializa de manera distinta:

- Nuestro usuario final: el que interacciona con el chat del Copilot publicado. Su identidad se gestiona mediante un usuario en Entra ID de nuestra organización que permite generar tokens delegados y tiene la posibilidad de consentir ciertos permisos. Por supuesto ya podemos sospechar de casos de consent phishing y over-delegation como veremos en este escenario.

- El flow de Power Automate: usaremos este flujo para "enmascarar" las intenciones de nuestro atacante. La identidad usada para su ejecución se captura del contexto del usuario que provoca el lanzamiento del flujo (durante la conversación con el Copilot) y ese token se transmitirá al conector personalizado. El riesgo que tiene Power Automate es la escala accidental de privilegios (al final tenemos los mismo privilegios que el usuario y quizás eso no sería correcto). 

- El conector personalizado: el componente que "robará" el token delegado. En este caso en la organización de origen donde se configura el conector personalizado crearemos un service principal que identifique a la aplicación con todos los permisos delegados de MS Graph que queremos "preguntar por su consentimiento" al usuario final.

- El Agente o Copilot creado en Copilot Studio: será el "caballo de troya" que interactuará con el usuario final y le pedirá aceptar el uso del conector personalizado para, en la sombra, robar el token con todos los permisos delegados del usuario. Actuará como app-only y su service principal será creado automáticamente por Microsoft(*).

(*) A fecha de hoy, marzo del 2026, sigue funcionado así.

Desde el punto de vista de la ciberseguridad: ¿Qué visibilidad tenemos de lo que sucede en Copilot Studio?

Este blog está siendo escrito en marzo del 2026, por lo que el famoso Agent365 y el Agent identity en el que Microsoft está trabajando NO es la configuración por defecto (incluso el setting que habilita la identidad de agentes en Copilot Studio aún está en public preview). 

Cuando alguien en nuestra organización crea un Copilot en Copilot Studio, automáticamente se crea un service principal de aplicación en nuestro Entra ID. Sin embargo, no podemos inspeccionar ni los permisos que utiliza, ni el flujo de datos ni fuentes que utiliza. Además, tenemos el problema que cada vez que se añade un conector, una fuente de datos, un flujo o cualquier componente a nuestro Copilot Studio, se generan en masa muchísimos service principals. Hecho que dificulta la auditoría, la gestión y la visibilidad de qué hacen en verdad todos estos service principals sin sentido (y sin owner claro, pues la mayoría tienen a Copilot Studio como owner). 

Esto queda un poco a margen de nuestro escenario, pero es necesario para entender la poca trazabilidad que existen a día de hoy de los copilots.

Anatomía de una exfiltración silenciosa

¿Cómo logra el agente malicioso aprovecharse del token del usuario? Usaremos un caballo de troya constituido por un Copilot publicado en un "website" de prueba y publicado bajo un dominio de Microsoft. Esta URL pública se distribuye bajo el pretexto de un agente que utiliza a un perfil de negocio concreto en ciertas tareas. Aquí el componente de ingeniería social y phishing es lo más crítico, pero una vez superado, todo lo demás funciona solo.

El objetivo será robar el token de permisos delegados que se genera cuando el usuario consiente al conector personalizado ciertos permisos que el usuario no es consciente (porque no los muestra). En la práctica, las aplicaciones Power Platform usan bearer tokens: si un token se intercepta, puede permitir replay. Los mecanismos de proof-of-possession no son el comportamiento por defecto en todos los escenarios. Podemos robar ese token generado y utilizarlo en cualquier código malicioso que extraiga datos de la organización a los que el usuario nos ha dado consentimiento sin saberlo.

¿Cómo funciona en flujo a lo largo de la interacción?

La idea es que la víctima interactúa con un Copilot que ha recibido y que aparentemente es confiable. Cuando la víctima interactúa con el agente, de repente este ejecuta un flujo que incluye un conector personalizado. El usuario acepta el uso de conector personalizado (con una descripción y uso falso) sin saber que, lo que está haciendo, es aceptar cientos de permisos delegados. Una vez el token es generado, el atacante lo intercepta mediante un webhook. Ese token es descompuesto mediante JWT (JSON Web token) y la parte del "assertion" es utilizada para requerir un nuevo token para MSGraph con todo los permisos que había consentido el usuario. 

En ese momento tenemos un robo del token, un abuso de éste y hemos comprometido la información y el acceso a la organización sin que el usuario lo supiera.

Vamos paso a paso: ¿Cómo puede un usuario caer en un phishing por parte de un atacante?

Mirad la imagen que acompaño: ¿quién dudaría de un agente publicado en una página web pública con dominio de Microsoft? Ningún usuario sin experiencia técnica dudaría de que ésto no se trata de un entorno confiable.

La siguiente pregunta, y aquí la gran diferencia con lo que lograron los compañeros de Datadog: ¿Cómo un usuario aceptaría delegar muchos permisos una vez el conector personalizado salta? Cuando es el Copilot como service principal el que requiere el login del usuario y en ese momento pide los permisos delegados, éstos siempre se muestran listados. Ahí el usuario puede ser que haga click en "aceptar" sin leerse qué permisos delega, pero ya se complica más el escenario del phishing.

Por ello, me di cuenta investigando que si es un connector personalizado mediante un flujo de Power Automate el que los pide, éstos no se muestran cuando se pide aceptar al usuario el consentimiento.

Como véis en la captura del chat, el connector personalizado solo le dice al usuario "voy a ejecutar el método GetRecent", pero no avisa de qué permisos delegados damos cuando hago click en "Permitir".

De este modo estamos ocultando los permisos consentidos y eso de por sí, ya es un gran riesgo.

Por detrás, a ese conector personalizado le hemos puesto un webhook.site dentro de su código para que capture los bearer token que se generan una vez el usuario consiente el conector. Con ese token capturado y cazado, el atacante ya puede reutilizar el token. Simplemente tiene que descomponerlo usando JWT (Json Web Token) y extraer el conocido como "User Assertion Token". Eso nos permitirá reutilizar el token OBO (On behalf of) en otra aplicación para realizar llamadas a la API de Graph sin que el usuario tenga que volvernos a dar el consent.

Con este token, ya podemos construir llamadas a la API de Graph para obtener todos los archivos, emails, reuniones, contactos... y todos los permisos consentidos que el usuario nos haya dado de su organización sin que se detecte si no se monitoriza consent grants + anomalías.

Pero... ¿Cuál es la clave aquí y cómo podemos protegernos?

La clave es entender que la mayoría de servicios SaaS, y Microsoft no es distinto, no hacen binding de sus token. La mayoría de OAuth2 y los bearer token que se crean no están "enlazados" a la app que los ha solicitado y la custodia de estos token es extremadamente importante, porque si alguien los intercepta como nosotros hemos hecho, podemos actuar como el usuario fácilmente.

¿Realmente la organización de la víctima no se daría cuenta?

Aquí es donde la prevención y monitorización entra en juego (y porqué los equipos de ciberseguridad somos tan importantes). La organización debería bloquear consents de alto impacto, implementar flujos con intervención administrativa y solo permitir editores certificados. De este modo impedimos que cualquier aplicación (incluso un Copilot externo), solicite tokens de manera masiva.

Los audit logs deben monitorizarse por el SOC (Centro de Operaciones de Ciberseguridad) para detectar que, en caso de que los tokens hayan sido robados, cualquier comportamiento anómalo de lectura de datos o acceso por aplicaciones no autorizadas con los permisos del usuario.

¿Puedo generar P-o-P (Proof of Possesion) tokens en Microsoft Entra ID?

No para el caso del SaaS que estamos mostrando. Automaticamente se generar bearer tokens dentro de organizaciones que trabajan con OAuth2 y como he comentado, por defecto siempre vamos a trabajar con los bearer. Los PoP deberán generarse manualmente en servicios web, APIs y otros servicios que nosotros publiquemos o generemos en nuestra organización.

¿Realmente es tan fácil robar un bearer token?

El problema es que nuestros usuarios son curiosos, les encanta hacer login con sus cuentas de organización y vincular  cuentas entre servicios. Con servicios externos es más difícil pues por defecto, muchas organizaciones evitan mediante policies en Entra ID que usemos nuestro dominio en cualquier plataforma. Sin embargo, si es una plataforma, como un servicio confiable de Microsoft, el usuario se relaja, las policies básicas no funcionan y un simple webhook en la cabecera de la solución es capaz de interceptar el token.

¿Por qué no enseñas paso a paso cómo realizaste el robo?

Porque una cosa es divulgar y la otra, ayudar a otros a reproducir escenarios de riesgo sin motivo. En mi charla en la RootedCon, en una audiencia puramente formada por expertos de ciberseguridad, sí mostré el paso a paso. Me parece que un artículo que quedará colgado en internet, no debería dar más pistas sobre el posible mal uso de cierta tecnología.

Resumen: Protege a tus usuarios, aplica políticas de seguridad con cabeza, haz formaciones de concienciación a tu organización y empleados y ante la duda, bloquear y denunciar siempre.