Visión general
En agosto de 2022, el equipo de Vectra identificó una oportunidad de post-explotación que permitía a actores maliciosos con suficiente acceso local o remoto al sistema de archivos robar credenciales de usuario válidas de Microsoft Teams debido a su almacenamiento en texto plano en el disco. Se determinó que esta gestión de credenciales en texto plano afectaba a todos los clientes comerciales y GCC Desktop Teams para Windows, Mac y Linux.
Mientras que la recolección de credenciales de la memoria es un paso común posterior a la explotación, creemos que bajar el listón necesario para cosechar credenciales a un simple acceso de lectura al sistema de archivos amplía las oportunidades para un adversario, simplifica su tarea y es particularmente interesante cuando las credenciales robadas ofrecen la oportunidad de retener el acceso del usuario sin el lastre de los molestos obstáculos de la autenticación multifactor (MFA).
Con estos tokens, los atacantes pueden asumir la identidad del titular del token para cualquier acción posible a través del cliente de Microsoft Teams, incluido el uso de ese token para acceder a las funciones de la API de Microsoft Graph desde el sistema de un atacante. Además, estos tokens son igualmente válidos con cuentas habilitadas para MFA, lo que permite eludir las comprobaciones de MFA durante el uso continuo.
Microsoft es consciente de este problema, pero indicó que no cumplía los requisitos para un servicio inmediato. Hasta que Microsoft actualice la aplicación de escritorio de Teams, creemos que los clientes deben ser conscientes de los riesgos que plantea el almacenamiento de tokens de texto sin formato y mitigar ese riesgo instrumentando la supervisión de accesos inusuales a archivos o la modificación de las ACL del sistema de archivos.
La génesis de la caza
La investigación se inició cuando un cliente de Vectra se quejó de cómo Microsoft Teams gestiona las identidades desactivadas. Los usuarios finales no pueden eliminar las cuentas desactivadas a través de la interfaz de usuario porque la aplicación Teams requiere que se inicie sesión en la cuenta para eliminarla del cliente. Por supuesto, los usuarios no pueden hacer esto cuando su cuenta de usuario está desactivada. Para ayudar a resolver este problema, empezamos a examinar los datos de configuración local dentro del cliente de Teams y a desentrañar cómo funciona.
Electrón - un negativo de seguridad
Microsoft Teams es una aplicación basada en Electron. Electron funciona creando una aplicación web que se ejecuta a través de un navegador personalizado. Esto es muy conveniente y hace que el desarrollo sea rápido y fácil. Sin embargo, ejecutar un navegador web en el contexto de una aplicación requiere datos tradicionales del navegador como cookies, cadenas de sesión y registros.
Aquí es donde radica la raíz de este problema, ya que Electron no admite controles de navegador estándar como el cifrado, y las ubicaciones de archivos protegidas por el sistema no son compatibles con Electron de forma predeterminada, sino que deben gestionarse de forma eficaz para seguir siendo seguras. Por lo tanto, la forma en que Electron funciona por defecto incentiva la creación de aplicaciones excesivamente transparentes. Dado que Electron ofusca las complejidades de la creación de la aplicación, es seguro asumir que algunos desarrolladores pueden no ser conscientes de las ramificaciones de sus decisiones de diseño y es común escuchar a los investigadores de seguridad de aplicaciones lamentar el uso de este marco debido a descuidos críticos de seguridad.
Sumergirse en la estructura
Primero empezamos a explorar métodos para eliminar cualquier referencia a la(s) cuenta(s) conectada(s). Nuestro objetivo era eliminar las cuentas antiguas y obligar a Teams a funcionar como si no estuvieran. Los múltiples intentos de modificar el archivo de configuración y los archivos de primera ejecución no sirvieron de nada. Como una puñalada en la oscuridad, buscamos el nombre de usuario principal conocido, y dos archivos críticos devueltos.
El primer archivo importante era un archivo ldb con tokens de acceso en texto claro. Al revisarlo, se determinó que estos tokens de acceso estaban activos y no eran un volcado accidental de un error anterior. Estos tokens de acceso nos daban acceso a las APIs de Outlook y Skype. Es importante saber que la arquitectura de Microsoft Teams es un conglomerado de una amplia variedad de servicios M365 que depende de Skype, SharePoint y Outlook para funcionar, lo que explica la presencia de estos tokens.

El siguiente archivo es una base de datos de cookies del navegador, como las "cookies" que aceptamos en todos los sitios web (gracias, GDPR). Las cookies almacenan datos como información de sesión, etiquetas de marketing, información de cuenta y, en algunos casos, tokens de acceso. Afortunadamente, la aplicación Teams Desktop también almacena los tokens aquí.

La mejor manera de leer la base de datos de cookies es usar un cliente de base de datos sqlite3. Con este cliente, podemos extraer sólo los valores que necesitamos. La siguiente consulta devuelve el nombre del token y el valor del token.

Evaluamos cada token con el servicio de validación jwt de Microsoft, https://jwt.ms. Todos los tokens que encontramos estaban activos y funcionaban sin requerir autenticación adicional. Empezamos a darnos cuenta de que el problema inicial de tener que reinstalar teams era mucho menor que la oportunidad de abuso de identidad que se avecinaba en el cliente de Microsoft Teams.
Hagamos algo
El equipo se puso manos a la obra con estos conocimientos y comenzó a crear herramientas que aprovecharan estas credenciales desprotegidas. Después de considerar múltiples opciones, se determinó que lo apropiado sería enviar un mensaje a la cuenta del titular de la credencial a través de Teams con un token de acceso. Con este objetivo en mente, lanzamos el cliente de Teams en el navegador para rastrear las llamadas a la API al enviar mensajes y encontramos esta joya:
https://amer.ng.msg.teams.microsoft.com/v1/users/ME/conversations/48:notes/messages
Este punto final de la API nos permite enviarnos mensajes a nosotros mismos y no tenemos que perder el tiempo con la enumeración de cuentas. A continuación, necesitamos el token de acceso. Utilizamos el motor SQLite. SQLite no requiere instalación, así que las herramientas descargan SQLite en una carpeta local y lo ejecutan para leer la base de datos de cookies, donde extraemos el código de acceso a Skype necesario para enviar mensajes.
Con el token en la mano y nuestro destino en mente, la última pieza era encadenar un mensaje. El cuerpo de la petición tardó un poco en funcionar, pero al final lo conseguimos. Configuramos el mensaje para enviarlo con el indicador de alta importancia y el asunto "You've Been PWND". El mensaje en sí es el token de acceso a Skype.

La herramienta envía el mensaje en este punto, y podemos validar que el token de acceso está en nuestro chat personal.

No está mal para una mañana de trabajo.
Implicaciones de las credenciales no garantizadas
Microsoft almacena estas credenciales para crear una experiencia fluida de inicio de sesión único dentro de la aplicación de escritorio. Sin embargo, la implementación de estas opciones de seguridad baja el listón.
Cualquiera que instale y utilice el cliente de Microsoft Teams en este estado está almacenando las credenciales necesarias para realizar cualquier acción posible a través de la interfaz de usuario de Teams, incluso cuando Teams está apagado. Cuando se roban estos tokens, los atacantes pueden modificar archivos de SharePoint, correo y calendarios de Outlook y archivos de chat de Teams. Los atacantes pueden alterar las comunicaciones legítimas dentro de una organización mediante la destrucción selectiva, la exfiltración o la participación en ataques phishing dirigidos.
The Big Scary -Lo último de Phish
Aquí lo que realmente nos asusta es la proliferación de tokens de usuario post-MFA en todo un entorno: permite que ataques posteriores que no requieren permisos especiales adicionales o malware se salgan con la suya con importantes daños internos. Con suficientes máquinas comprometidas, los atacantes pueden orquestar las comunicaciones dentro de una organización. Asumiendo el control total de los puestos críticos -como el Jefe de Ingeniería, el Director General o el Director Financiero de una empresa-, los atacantes pueden convencer a los usuarios para que realicen tareas perjudiciales para la organización. ¿Cómo se practican las pruebas de phishing para esto?
Recomendaciones
A los administradores
Equipos de línea de base, gestión de configuraciones y supervisión de cambios de ACL
Trate los equipos como una aplicación crítica y base y aplique las ACL que la protegen. La modificación de estas ACL para ampliar el acceso de lectura de archivos fuera del usuario previsto expondrá efectivamente las credenciales de ese usuario a cualquiera de las acciones maliciosas enfatizadas anteriormente.
Una vez que Microsoft haya actualizado las aplicaciones de Electron Teams, sigue siendo fundamental pasar a un modelo de alta restricción para evitar la instalación de Teams Apps, bots, conectores, etc. no autorizados.
Seguimiento del acceso a archivos
Cree una regla de supervisión del sistema para identificar los procesos que acceden a estos archivos sensibles. Hay dos recomendaciones específicas de archivos/carpetas:
- Windows] %AppData%\Microsoft\Teams\Cookies
- Windows] %AppData%\Microsoft\Teams\Local Storage\leveldb
- macOS] ~/Library/Application Support/Microsoft/Equipos/Cookies
- macOS] ~/Library/Application Support/Microsoft/Teams/Local Storage/leveldb
- Linux] ~/.config/Microsoft/Microsoft Teams/Cookies
- Linux] ~/.config/Microsoft/Microsoft Teams/Local Storage/leveldb
Si cualquier proceso que no sea Teams.exe accede a estos archivos, indica que se está accediendo a los datos almacenados fuera del contexto de la aplicación Teams.

Considere la aplicación web como alternativa
Si el baselining y la monitorización no son prácticos, considera usar el cliente web de Teams dentro de Microsoft Edge, que tiene múltiples controles a nivel de sistema operativo para proteger las fugas de tokens. Afortunadamente, la aplicación web de Teams es sólida y compatible con la mayoría de las funciones habilitadas a través del cliente de escritorio, lo que reduce al mínimo el impacto en la productividad de la organización.
Para los usuarios de Linux, este es el camino recomendado y punto, ya que Microsoft ha anunciado el final de la vida de Teams para Linux en diciembre de 2022.
A los promotores
Si debes utilizar Electron para tu aplicación, asegúrate de almacenar de forma segura los tokens OAuth. Uno de estos métodos para almacenar secretos es utilizar el paquete KeyTar, que aprovecha los mecanismos de seguridad del sistema operativo local para la gestión de secretos.
Cómo almacenar de forma segura información sensible en Electron con node-keytar | por Cameron Nokes | Cameron Nokes | Medium
A Microsoft
Si tienes que almacenar los tokens, hazlo de forma encriptada y sube el listón de un simple acceso de lectura en el sistema de archivos a requerir algún acceso continuo a la memoria. Y, por favor, permítenos eliminar las cuentas deshabilitadas de la(s) aplicación(es) de Teams sin tener que hacer una desinstalación/reinstalación completa.
A los equipos de seguridad
Para detener a un atacante que aproveche este tipo de exploit, los equipos deben invertir en soluciones de detección de amenazas y respuesta que puedan ver el tipo de acciones antes y después de que se aproveche el exploit. La plataforma de detección y respuesta a amenazas de Vectra detectaría las tácticas de mando y control de que cabría esperar antes de este exploit y cualquier reconocimiento de red, movimiento lateral o exfiltración que se produjera después del exploit. En la cloud, Vectra alertaría sobre las actividades del atacante utilizando las credenciales comprometidas en Azure AD, incluyendo privilegios en Azure AD, ataques a gran escala contra proveedores de servicios cloud conectados como AWS y ataques contra otras aplicaciones de Microsoft 365, incluyendo Exchange, SharePoint y Power Automate.
Detección de amenazas y respuesta para su Azure AD
Para obtener más información sobre cómo Vectra puede detectar y detener las amenazas, visite: https://www.vectra.ai/products/platform