Microsoft Authenticator daba tokens de Teams a apps falsas en Android

«It never asked: Is the app making this request actually Teams?» (nunca preguntó si la app que hacía la petición era de verdad Teams). Así resume Ofek Levin, investigador de seguridad de IA en Enclave, por qué Microsoft Authenticator para Android entregó tokens de una cuenta de trabajo de Microsoft 365 a una app de prueba que no tenía ni un solo permiso de Android y que solo decía ser Teams.

El fallo es CVE-2026-80097 y Microsoft lo corrigió el 8 de septiembre de 2026 en la versión 6.2606.4246 de la app. Lo nuevo es el detalle técnico. Enclave publicó el 23 de octubre su informe AuthMask con la cadena completa y el motivo por el que la comprobación de identidad de Authenticator no servía de nada. Con ese informe en la calle, cualquier móvil que siga en una versión anterior pasa a ser un objetivo mucho más fácil de lo que sugería un aviso de septiembre sin apenas descripción.

Un AccountChooserActivity exportado y una firma que se comprueba a sí misma

Enclave lo anunció en X el 25 de octubre con un resumen corto. La app de prueba «It just claimed to be Teams» (simplemente afirmaba ser Teams) y obtuvo acceso delegado al correo, los archivos y el calendario a través de Microsoft Graph.

Para entender el fallo hay que recordar qué hace Authenticator en un Android corporativo. Aparte de mostrar códigos de un solo uso y aprobar notificaciones de MFA, aloja el broker de autenticación de Microsoft. Según la documentación de MSAL para Android, ese broker también viaja dentro de Intune Company Portal y de Enlace Móvil (Link to Windows), y es el que da inicio de sesión único a todo el dispositivo y aplica el acceso condicional. Cuando Outlook o Teams necesitan un token, se lo piden al broker y no al usuario.

El diagrama de Microsoft muestra esa relación. Las apps que integran MSAL delegan en el broker de Authenticator o de Company Portal, y este guarda las cuentas en el AccountManager de Android. Quien controla el broker controla la identidad de trabajo de todo el teléfono, y por eso el broker debería saber siempre qué app le está pidiendo cada token.

Según el informe de Enclave, Authenticator exponía la actividad com.microsoft.identity.client.AccountChooserActivity marcada como exportada (el atributo android:exported con valor true), de modo que cualquier app instalada podía lanzarla. La única barrera era que existiera una actividad llamante, algo que cumple cualquier app que use startActivityForResult. Todo lo demás llegaba en la propia petición y lo escribía el atacante: el UID del llamante en el campo caller.info.uid y el nombre de la app, el paquete, el client ID, la redirect URI y los scopes dentro del JSON broker_request_v2.

Después venía la validación. El método isValidCallingApp tomaba el paquete que decía ser el llamante, buscaba en el dispositivo la firma de ese paquete, construía con ella la redirect URI esperada y la comparaba con la que llegaba en la petición.

La captura del informe de Enclave recoge esas dos líneas. El problema es que Teams sí está instalado en el móvil de la víctima, así que su firma auténtica produce la redirect URI auténtica, y cualquier app puede leer esa firma desde PackageManager sin pedir permisos. La comprobación pasaba siempre. Authenticator conocía el paquete real del llamante, porque la actividad lo leía con getCallingActivity().getPackageName(), pero solo lo usaba para gestionar peticiones paralelas y nunca para decidir si confiaba en él.

Correo, archivos y passkeys con la identidad de Teams

La respuesta del broker volvía a quien había lanzado la actividad, con el código de resultado 2004. El bundle broker_result_v2_compressed contenía el access token, el refresh token, el ID token y el client_info en claro, legibles para la app de prueba. Enclave repitió el engaño con tres identidades distintas y obtuvo tres juegos de permisos.

La lista que publica Enclave es la parte que más debería preocupar a un equipo de identidad. Haciéndose pasar por Teams y pidiendo Microsoft Graph, la app recibió Mail.ReadWrite, Mail.Send, Files.ReadWrite.All, Calendars.ReadWrite, ChatMessage.Send y Sites.ReadWrite.All, entre otros. Con la identidad del backend de chat de Teams (api.spaces.skype.com) consiguió user_impersonation. Y suplantando al propio cliente de Authenticator obtuvo UserAuthenticationMethod.ReadWrite, Passkey.Create y Passkey.Delete.

Ese último juego cambia la naturaleza del incidente. Un refresh token robado caduca o se revoca, y la sesión se puede cortar desde Entra ID. Una passkey registrada por el atacante en la cuenta de la víctima es un método de autenticación propio, que sigue funcionando aunque se desinstale la app maliciosa y aunque se revoquen todas las sesiones. Es la misma lógica de persistencia que vimos en la campaña de tokens robados de Microsoft 365 que documentó Huntress, donde el operador borraba y añadía métodos de MFA para quedarse dentro.

Enclave no publica en su informe ningún vídeo de la prueba ni el código de una app completa, aunque sí reproduce el fragmento con el que construyó la petición falsa. No lo reproducimos aquí.

CVE-2026-80097 en el aviso de Microsoft y en el informe de Enclave

El aviso de Microsoft clasifica el fallo como elevación de privilegios con gravedad Important. Su ficha en NVD, analizada el 24 de septiembre, recoge la misma puntuación y la misma horquilla de versiones.

Hay una diferencia entre el fabricante y el investigador que conviene leer bien. El vector de Microsoft marca UI:R, es decir, que hace falta interacción del usuario, y su FAQ describe el ataque como instalar y ejecutar una app maliciosa y «convincing the user to complete an authentication flow in Microsoft Authenticator» (convencer al usuario de que complete un flujo de autenticación en Microsoft Authenticator). Enclave sostiene que en sus pruebas no hizo falta nada más, en sus palabras «no user interaction beyond having the broker present» (ninguna interacción más allá de tener el broker presente) con una cuenta de trabajo iniciada. Las dos versiones coinciden en lo esencial. Alguien tiene que instalar antes la app maliciosa, y a partir de ahí el robo no deja aviso en pantalla según el investigador.

El aviso tampoco dice nada sobre los otros dos anfitriones del broker. Microsoft solo lista Authenticator para Android como producto afectado y no menciona Intune Company Portal ni Enlace Móvil, que según su propia documentación incluyen el mismo componente. Ninguna fuente ha publicado que esas apps sean vulnerables, y tampoco que no lo sean. iOS no aparece en el aviso ni en el informe.

Microsoft revisó el aviso el 15 de septiembre para corregir el número de compilación de la versión que arregla el fallo, un cambio que la propia compañía califica de informativo. El coordinador SSVC de CISA registró el 9 de septiembre que no había explotación, que el ataque no es automatizable y que el impacto técnico es total. El fallo no está en el catálogo KEV de CISA a fecha de 27 de octubre de 2026, y Microsoft lo marca como de explotación poco probable.

Revisar versiones de Authenticator, passkeys y sesiones en Entra ID

El parche no exige nada del lado del servidor, pero la versión de la app depende de cada teléfono. Para comprobarla en un móvil concreto desde el puesto de soporte, con depuración USB activada, basta con consultar el gestor de paquetes.

adb shell dumpsys package com.azure.authenticator | grep versionName

A partir de ahí, estos son los pasos por orden de urgencia.

1. Actualiza Microsoft Authenticator en Android a la 6.2606.4246 o posterior desde su ficha en Google Play. En dispositivos gestionados con Android Enterprise, fuerza la actualización desde Google Play gestionado con prioridad alta y comprueba la versión instalada en el informe de aplicaciones detectadas de Intune.
2. Localiza los móviles que siguieron en una versión anterior después del 8 de septiembre y que también tenían instaladas apps de fuera de la tienda corporativa. Son los únicos en los que el ataque era posible.
3. Revisa en esas cuentas los métodos de autenticación registrados, con atención a las passkeys y a los dispositivos FIDO2 que el usuario no reconozca.
4. Revoca las sesiones y los refresh tokens de los usuarios afectados y obliga a un nuevo inicio de sesión.
5. Bloquea la instalación de apps desde orígenes desconocidos en los perfiles de trabajo y mantén Play Protect activo, o una solución de defensa de amenazas móviles si ya la tienes. Un antivirus para Android no corrige el fallo, pero reduce la probabilidad de que llegue la app maliciosa.
6. Si encuentras indicios de abuso, notifícalo a INCIBE-CERT si eres empresa o particular, o al CCN-CERT si eres sector público.

En Microsoft Sentinel o en cualquier SIEM que reciba los logs de Entra ID, esta consulta lista los registros y borrados de métodos de autenticación desde finales de agosto. Es un punto de partida, y conviene cruzarla con la lista de usuarios que tenían una versión vulnerable.

AuditLogs
| where TimeGenerated > ago(60d)
| where LoggedByService == "Authentication Methods"
| where OperationName has_any ("security info", "Passkey", "FIDO2")
| project TimeGenerated, OperationName, Result,
          Actor = tostring(InitiatedBy.user.userPrincipalName),
          Target = tostring(TargetResources[0].userPrincipalName)
| order by TimeGenerated desc

Si la revisión confirma un método que el usuario no registró, el orden importa. Primero se elimina la passkey o el método ajeno y después se revocan las sesiones, porque al revés el atacante puede volver a entrar con su propia credencial. Con el módulo de Microsoft Graph para PowerShell se hace así.

Get-MgUserAuthenticationFido2Method -UserId usuario@empresa.es |
  Select-Object Id, DisplayName, CreatedDateTime, Model
Remove-MgUserAuthenticationFido2Method -UserId usuario@empresa.es -Fido2AuthenticationMethodId <Id>
Revoke-MgUserSignInSession -UserId usuario@empresa.es

Dudas habituales sobre Microsoft Authenticator

¿Qué es Microsoft Authenticator y para qué sirve?

Es la app de Microsoft para la MFA de cuentas personales y de trabajo, con códigos temporales, notificaciones de aprobación y passkeys. En Android corporativo hace algo menos visible, que es actuar como broker para que el resto de apps de Microsoft inicien sesión sin pedir otra vez la contraseña. Si en el móvil hay varios brokers, como Authenticator y Company Portal, MSAL elige por sí mismo cuál está activo.

¿Cómo desactivar Microsoft Authenticator?

Se puede desinstalar o quitar la cuenta de trabajo desde la app. Microsoft documenta que, si Authenticator es el único broker del teléfono y se desinstala, la cuenta y sus tokens desaparecen del dispositivo y el usuario tendrá que iniciar sesión de nuevo. Eso limpia el móvil, pero no invalida en Entra ID los tokens que ya se hubieran robado. Para eso hace falta revocar las sesiones.

Tres fallos de Authenticator para Android en siete meses

CVE-2026-80097 es el tercer fallo de Authenticator para Android que Microsoft corrige en 2026. Antes llegaron el fallo CVE-2026-26123, una revelación de información local, y el fallo CVE-2026-41615, una exposición de información por red que Microsoft puntuó con 9,6 y NVD rebajó a 7,4, y que también afectaba a iOS hasta la 6.8.47.

Los tres requieren que el usuario haga algo antes, y los tres acaban en el mismo sitio, credenciales o tokens de una cuenta que abre el correo y los archivos de la empresa.

Nuestra lectura es que el teléfono ha pasado a ser el punto débil de identidades que en el portátil están bien protegidas, y que cualquier plan de gestión de identidades en la nube tiene que incluir la versión de las apps que hacen de broker. Una organización puede tener acceso condicional, dispositivos conformes y un modelo Zero Trust bien desplegado, y aun así un broker que confía en lo que le cuentan anula todas esas capas desde dentro del móvil. Los tokens salen con el client ID de Teams y desde el broker del propio usuario, así que su emisión no se distingue de un inicio de sesión legítimo, y la única señal útil está en dónde y cómo se usan después.

No hay explotación conocida y el parche tiene siete semanas. El riesgo real está en el parque de móviles personales con perfil de trabajo, donde nadie controla si las actualizaciones automáticas de Google Play están activas, y en los dispositivos que el usuario dejó de usar sin borrar la cuenta. Ahí la versión 6.2606.4246 puede no haber llegado nunca, y desde el 23 de octubre cualquiera tiene la descripción exacta de lo que hay que hacer para aprovecharlo.