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)  

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.

Figura 1: EchoLeak . Un Cross Prompt Injection Attack (XPIA)

para Microsoft Office 365 Copilot

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.

Figura 2: Expediente de Microsoft sobre EchoLeak

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. 

Figura 3: El vector de ataque es un e-mail a la víctima con el que NO

hace falta interactuar de manera directa, sino a través de MSO365 Copilot

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 Torrano, Fran 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. 

Figura 5: Flujo del ataque

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. 

Figura 6:  Ejemplos de formato de etiquetas que hacen imprimir el

link malicioso en O365 Cliente que funcionaron en el ataque.

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.

Figura 7: Ejemplo con enlace malicioso creado por Office365 Copilot

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.

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

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.

Figura 9: Etiquetas de carga de imágenes en Office365 

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.

Figura 10: Dominios autorizados en la CSP para

carga automática de imágenes

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.

Figura 11: URLs que hacen carga automática de URLs

en los dominios autorizados en la CSP

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.

• Prompt Guard: Modelo de seguridad para evitar ataques de Prompt Injection & Jailbreak en LLMs
• Llama Guard 3: Un LLM de Seguridad para proteger LLMs
• Llama 4 Security: CyberSecEval, Prompt Guard, Code Shield & Llama Guard
• Prompt Injection Protections: Jatmo, StruQ, SecAlign & Instructional Segment Embedding
• Google DeepMind CaMeL: Defeating Prompt Injections by Design in Agentic AI
• LlamaFirewall con PromptGuard 2, LlamaGuard 4, AlignmentCheck, CodeShield + AutoPatchBench & CyberSecEval 4

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)  

AuthQauke: Un bug en Microsoft MFA que permitía Brute Force de tus TOTP para entrar en tu cuenta de Microsoft

Esta semana se ha publicado la investigación de Oasis Security Research Team sobre el bug y la explotación de AuthQuake, un bug que contenía Microsoft MFA (Multi-Factor Authentication) que permitía explotar el 2FA (Second Factor Authentication) de tus cuentas de Microsoft Office mediante un ataque de fuerza bruta a los valores del TOTP (Time One-Time Passwords) asociados.

Figura 1: AuthQauke: Un bug en Microsoft MFA que permitía Brute Force

de tus TOTP para entrar en tu cuenta de Microsoft

Para que entendáis lo que han hecho, hay que saber cómo funciona la cuenta de Microsoft Office con MFA utilizando TOTP como método de autenticación, echar unos cálculos y ser muy rápidos. El funcionamiento es el siguiente.

Figura 2: Microsoft MFA para TOTP

Primero se pide una sesión a Microsoft Office que se autentica con usuario y contraseña, y Microsoft genera un ID de Sesión sobre el que se pueden hacer 10 intentos de TOTP. Es decir, que por cada autenticación se pueden hacer 10 intentos. 

Pero si no se valida el TOTP en esos 10 intentos, simplemente se cierra el ID de Sesión y hay que volver a autenticar el usuario y la contraseña, pero no se bloquea la cuenta, ya que no queda como intentos de contraseña errónea, sino como que no se ha validado el 2FA.

Figura 3: Tiempo de validez de un TOTP según el RFC 6238

Teniendo en cuenta que los valores de un TOTP deberían valer 30 segundos, pero según el estándar TOTP éste puede ir hasta los 10 minutos, nos podríamos encontrar con un entorno en el que la seguridad se degrada. 

En la práctica, la validez de un TOTP normalmente suele estar entre 1 y 3 minutos, y en el caso de Microsoft, los investigadores descubrieron que el valor que tiene configurado el proceso de login es de 3 minutos, lo que permite muchos intentos.

Figura 4: Microsoft MFA TOTP dura 3 minutos

Teniendo en cuenta que son 6 dígitos, hay que conseguir 1 Millón de intentos para cubrir un ataque de fuerza bruta, pero la estadística está de parte del atacante, ya que en media, el 50% de las veces tendrá éxito con solo la mitad de los intentos, y así sucesivamente.

Figura 5: Código TOTP (6 dígitos) de Microsoft MFA visto en Latch.

El bug en sí existía porque la cuenta no se bloqueaba a pesar del número de intentos de validación del TOTP que se haga porque el bloqueo lo tienen en el número de intentos de la contraseña y no en el de la validación del TOTP, lo que hace que una vez que se tenga la contraseña el 2FA de TOTP de Microsoft fuera poco útil.

AuthQuake Attack

El atacante podría atacar un TOTP y buscar si la estadística estaba a su favor durante esos tres minutos, generando nuevas autenticaciones correctas sin validación de 2FA, y ver si lo consigue o no. Pero si no lo consigue, no pasa nada, a los 3 minutos hacemos otro ataque al TOTP a ver si ahora la estadística está de nuestra parte y en 5 horas se tiene aproximadamente el 98% de probabilidades de saltar el 2FA.

Figura 6: Probabilidad de éxito a lo largo del tiempo

Ahora está resulto, pero es un aprendizaje sobre cómo se debe establecer un sistema de identidad, con autenticadores seguro para que no haya un ataque como éste que pueda anularlo por no haber hecho los deberes. Aquí la demo del ataque.

Figura 7: AuthQuake Attack con un script en Python

Al final, con ene intentos contra un TOTP cada tres minutos, es posible saltar el 2FA, porque como han explicado los investigadores:

• No había restricción de intentos de validación de TOTP

• El usuario nunca recibía una alerta de inicio de sesión o intento fallido de TOTP

Esto es algo que nos llevó a crear Tu Latch, ya que en este escenario el atacante tiene las credenciales pero nunca se entera el usuario de que se las han robado, mientras que con un Control de Latch, en el primer intento el usuario recibiría una alerta que le indicaría que alguien ha intentado iniciar sesión con su contraseña.

Figura 8: Yaiza Rubio y Chema Alonso presentando Tu Latch

En el vídeo anterior, estamos Yaiza Rubio y yo presentando cómo se puede utilizar Tu Latch para Control de Authorizaciones, tanto en el proceso de Login como 2FA, como con capa de Control de Autorizaciones para, una vez perdido el User/Password y 2FA aún se pueda tener protegida la cuenta del servicio digital con Tu Latch.

Figura 9: Contacta con nosotros para asistir al evento

Si quieres conocer más de Latch o cómo configurar un sistema de Identidades utilizando una capa de control de autorizaciones con Tu Latch y con OpenGateway para reducir el impacto de estos bugs al máximo posible, contacta con nosotros. 

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

(Tu) MetaShield Clean-Up Online: Descubre qué datos exponen tus documentos

Uno de los proyectos que hemos comenzando este años a cuidar desde Tu.com es MetaShield Protector. La familia MetaShield Protector ayuda a las empresas y particulares a evitar las fugas de información de la compañía por medio de la limpieza de los metadatos, la información oculta y los datos perdidos. Mucho he hablado de esto durante años en este blog y en muchas conferencias.

Figura 1: (Tu) MetaShield Clean-Up Online.

Descubre qué datos exponen tus documentos

Para los nuevos - y para los no tan nuevos - quería hacer este artículo para informaros que tenéis el servicio de MetaShield Clean-Up Online disponible en la nueva URL, que es: https://metashieldclean-up.tu.com, donde lo podéis utilizar gratis para saber qué datos filtran tus documentos ofimáticos, tus fotografías, o los archivos que compartes en general con personas a través del correo electrónico, o con todo el mundo a través de la publicación de los mismos en la web.

Figura 2: Tu Metashield Clean-UP Online

Para que veáis cómo funciona este servicio, he buscado un fichero Excel que he recibido recientemente y lo he subido para analizar.

Figura 3: Análisis de Metadatos, Información Ocult y Datos Perdidos

de un documento Excel con MetaShield CleanUP Online

En él podéis ver cómo hay un montón de información, como por ejemplo el nombre del usuario del sistema que creó dicho archivo.

Figura 4: Nombre de usuario y tipo de documento

También aparece información de la compañía que licenció la versión de Excel con la que se creó este documento, lo que es bastante curioso y puede dar más información de la necesaria.

Figura 5: Compañía que ha licenciado el software

Otro de los datos es quién modificó el documento, que es otro usuario de la compañía diferente a quién lo creó, lo que nos da un historial de edición del archivo, y dos nombres de usuarios de dicha compañía, sólo con haber recibido un documento Excel.

Figura 6: Usuario que modificó el Excel

Pero la información que aparece no se queda ahí, y podemos descubrir marcas y modelos de impresoras, así como versiones de software.

Figura 7: Impresora configurada y versión de Excel utilizada.

Ya he hablado mucho de la importancia de esta información que muchas veces las empresas entregan sin ningún cuidado, y cómo una compañía que comparte decanas, o centenares de documentos al día, está filtrando mucha información de la estructura de red y de seguridad de la empresa.

Figura 8: Contacta para conseguir más información

de los productos Metashield Protector.

En Tu Metashield tenemos además soluciones para aplicar en el correo electrónico de Office 365, en la gestión en los servidores web, e incluso para utilizar vía API en tus propias aplicaciones de gestión documental, así que si quieres ver posibilidades de colaboración, o quieres usar nuestros servicios, puedes contactar con nosotros.

Figura 9: Metadatos y Esquema Nacional de Seguridad

Todas estas herramientas, son fundamentales para implementar una Política de Seguridad de Metadatos para cumplir al Esquema Nacional de Seguridad, marcado por el CCN-CERT nacional en España, y para política similares a lo largo del mundo entero.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

DobuleDrive: Cómo OneDrive se puede convertir en un Agente Doble y trabajar para un Ransomware

Me ha gustado mucho el trabajo de DoubleDrive, presentado por el investigador Or Yair (@oryair1999) en la presente BlackHat USA 2023, en el que ha explicado cómo se puede convertir al proceso de OneDrive en tu equipo en un agente doble que trabaje para un Ransomware y cifre todos los archivos de tu equipo. Una idea que ya hemos explorado nosotros en el pasado con RansomCloud, pero que aquí utiliza una aproximación diferente, y me ha encantado.

Figura 1: DobuleDrive. Cómo OneDrive se puede convertir en un Agente Doble

y trabajar para un Ransomware

Antes de contaros un poco sobre la investigación, dejadme hacer una pequeña introducción a lo que nosotros construimos y exploramos en hace ya unos años.

Ransomcloud O365

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: Kevin Mitnick hace una demo de RansomCloud O365

De este ataque,  Kevin Mitnick, que lo utilizó en muchas de sus conferencias, hizo vídeos explicando el proceso donde lo dejaba bastante claro. El objetivo, tan sencillo como cifrar el contenido que hubiera en la nube, y que se sincronice con lo que haya en local. Listo. 

DoubleDrive OneDrive

La idea con el ataque de DoubleDrive, presentado por Or Yamir, es un poco diferente, aunque tiene similitudes con nuestro ataque. En este caso se trata de cómo un Ransomware puede evitar ser detectado por medio de patrones de comportamiento, que es lo que utilizan muchos de los agentes EDR (Endpoint Detection and Response) que protegen al sistema operativo contra procesos maliciosos que generan actividad típica de un ransomware.

Figura 4: "Malware moderno: Técnicas avanzadas y su influencia en la industria"

de Sergio de los Santos en  0xWord

Lo que la investigación predice es que este tipo de técnicas pueden ser utilizadas dentro de poco por Malware Moderno ( y basta con leerse el libro de Sergio de los Santos para tener claro que lo harán), con el objetivo de evitar la detección. En este caso, la idea es utilizar el agente de OneDrive en el sistema operativo para hacer todo este trabajo de cifrar el contenido y eliminar los archivos originales. ¿Por qué?

Figura 5: Un Ransomware que usa OneDrive para cifrar y borrar archivos

Pues tan sencillo como que el agente de OneDrive en el sistema operativo está en las listas blancas de los EDR ya que su función es copiar, cambiar, borrar, archivos y carpetas del sistema operativo masivamente. Así que todos los EDR lo ponen en listas blancas.

Figura 6: Arquitectura del ataque de DoubleDrive.

Explicación a continuación.

Dicho esto, lo que hay que hacer es conseguir configurar OneDrive para que sincronice todos los archivos que se quieren cifrar en una cuenta de OneDrive en la nube. Es decir, configuramos OneDrive para que sincronice los archivos de local con una copia en OneDrive, y hacer que la copia de OneDrive esté cifrada, y machaque la copia local. Esta es la parte que se parece a nuestro ataque, ya que nosotros ciframos los archivos que ya están en OneDrive y en Office365. 

Figura 7: Python para Pentesters & Hacking con Python
de Daniel Echeverry en 0xWord

Lo que la diferencia es que el ataque de DoubleDrive busca hacer la sincronización desde local con la nube de los archivos que quiere cifrar, así que es un ataque que se produce en el sistema operativo por un programa malicioso que corre en local.

Figura 8: Se hace login de OneDrive con una cuenta controlada por el atacante

Para ello, plantea varias estrategias para lograr esa sincronización. La primera, y más sencilla, es configurar la cuenta a la que se conecta el agente de OneDrive en local con una cuenta de OneDrive en la nube controlada por el atacante. Se configuran las carpetas a sincronizar, y según el proceso de OneDrive va subiendo los archivos, se cifran en la nube, y el miso agente de OneDrive en local los va machacando, saltándose cualquier EDR en el sistema operativo.

Figura 9: Se roba el token de acceso de la cuenta de OneDrive que se usa en local

La segunda estrategia consiste en conseguir acceso a la cuenta actual del propio OneDrive que está corriendo en local. Para lo que consigue el token de acceso (autorizado previamente), desde el fichero del log de OneDrive, que son los ficheros .odl, que son unos binarios donde el Token de Acceso está ofuscado, pero que con una herramienta escrita en Python, que ha publicado en GitHub, se puede desofuscar y extraer.

Figura 10: Herramienta para extraer token de acceso desde log .odl de OneDrive

También se puede extraer ese Token de Acceso haciendo un volcado de la memoria del proceso de OneDrive, que es bastante sencillo de ejecutar, tal y como ha explicado en las diapositivas de la presentación que ha utilizado.

Figura 11: Robo de tokens con volcado de memoria

Una vez que se tiene el Token de Acceso, para automatizar el proceso del Ransomware, ha publicado la herramienta OneDrive DoubleDrive que utiliza el Token de Acceso, y la lista de ficheros a cifrar, para realizar el proceso de vincular la copia local con la copia en la nube usando OneDrive y hacer el cifrado de los archivos en el almacén en la nube, que será sincronizado después en local.

Figura 12: OneDrive DoubleDrive en GitHub

Para hacer el cifrado, el atacante necesita el Token de Acceso que debe ser compartido con él. Puedes ver la descripción de la presentación en la web de Blackhat, y en este enlace tienes disponibles las diapositivas de la presentación de DoubleDrive.

Conclusiones

Al final, esta técnica lo que busca es que los archivos en local queden cifrados como un Ransomware, saltándose las protecciones de los EDR utilizando el agente de OneDrive, mientras que en Ransomcloud, lo que buscamos es cifrar el contenido almacenado en la nube, robando un Token OAuth que nos permita controlar todo el servicio en la nube. Esta estrategia de usar agentes como OneDrive, Dropbox y similares, es muy común en los equipos del Red Team.

Figura 13: Libro de "Empire: Hacking Avanzado en el Red Team" 
de Pablo González y Sebastián Castro en 0xWord.

Microsoft ha actualizado el agente de OneDrive, para eliminar el almacenamiento de los tokens en los ficheros log, pero el agente necesita seguir utilizando en memoria dicho token. Eso si, realizar un volcado de memoria de un proceso es una acción que los EDR pueden detectar con más facilidad como un comportamiento negativo.  Eso sí, me gustaría verlo en acción contra nuestro Latch ARW.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Figura 14: Contactar con Chema Alonso