Microsoft Authenticator Android: robo de tokens sin permisos

Una vulnerabilidad de Microsoft Authenticator para Android permitía que una app instalada en el mismo teléfono, sin ningún permiso y sin interacción del usuario, obtuviera los tokens de acceso de la cuenta de trabajo de Microsoft. La noticia la publicaron el 27 de octubre de 2026 Help Net Security y The Hacker News, y al día siguiente heise Security. El fallo ya está corregido: se identifica como CVE-2026-80097 y afecta a las versiones anteriores a la 6.2606.4246.

Los detalles técnicos disponibles proceden sobre todo del artículo de Help Net Security, el único cuyo texto completo hemos podido leer; de los otros dos medios conocemos el titular, que confirma el punto central: apps sin permisos capaces de robar los tokens de las cuentas de trabajo.

El papel de Authenticator como broker

En Android, Authenticator no se limita a mostrar códigos de un solo uso. Actúa como broker de autenticación: cuando Teams, Outlook u otra app de Microsoft necesita iniciar la sesión del usuario, pide el token a Authenticator, que lo emite en nombre de la cuenta registrada en el dispositivo. Precisamente porque custodia el acceso a toda la cuenta, el broker debería comprobar con rigor qué app le está pidiendo un token.

Según Help Net Security, el investigador Ofek Levin, del programa de fellowship de Enclave, descubrió que esta comprobación no funcionaba:

• un componente de Authenticator podía ser invocado por cualquier app del dispositivo;
• al recibir la petición de un token, Authenticator se fiaba de la identidad declarada por la app que llamaba;
• el control previsto comparaba los datos de la petición con los de la app legítima de Microsoft instalada en el teléfono, pero son datos que cualquier app puede leer y, por tanto, fáciles de imitar;
• Authenticator conocía la identidad real de quien llamaba, pero no la usaba para decidir si fiarse.

En la práctica, una app maliciosa podía presentarse como Teams y recibir los tokens destinados a Teams. Es un patrón conocido en las apps de Android que exponen componentes a otras apps: el sistema operativo permite saber quién está llamando, y la seguridad depende de que el componente use de verdad esa información y no los datos que aporta quien llama.

Qué permitían los tokens

Help Net Security indica que, con una sola cuenta de trabajo registrada en Authenticator, la app de prueba de los investigadores obtuvo tokens que permitían:

• leer y enviar correos desde el buzón de la víctima;
• leer y modificar archivos, calendario y sitios de SharePoint;
• enviar mensajes de Teams en nombre de la víctima;
• haciéndose pasar por el propio Authenticator, cambiar los métodos de inicio de sesión de la cuenta, incluida la creación y eliminación de passkeys.

El último punto es el más delicado: una passkey añadida por el atacante le permite seguir accediendo incluso después de eliminar la app maliciosa del teléfono. Según la misma fuente, el robo era silencioso: ninguna solicitud de confirmación y ningún aviso para el usuario.

El límite del ataque es su punto de partida: hace falta una app maliciosa instalada en el dispositivo, es decir, un usuario engañado para instalarla. Help Net Security no informa de casos de explotación real.

En términos de MITRE ATT&CK (clasificación nuestra, no de las fuentes), la cadena corresponde al robo de tokens de aplicación en móviles (T1635, Steal Application Access Token), a su uso como material de autenticación alternativo (T1550.001) y a la persistencia mediante la modificación de los métodos de inicio de sesión (T1098, Account Manipulation).

Corrección y gravedad

Enclave comunicó el fallo a Microsoft mediante divulgación responsable. Microsoft lo confirmó y publicó la corrección el 8 de septiembre de 2026, con una puntuación CVSS de 8.6. Son vulnerables todas las versiones de Authenticator para Android anteriores a la 6.2606.4246. Las fuentes no señalan consecuencias para Authenticator en iOS.

Impacto para las empresas europeas e italianas

Authenticator está muy extendido como segundo factor y como broker de Microsoft 365, también en teléfonos personales usados para trabajar (BYOD), donde la empresa controla poco lo que se instala. Un token robado de esta forma da acceso a correo, documentos y Teams sin pasar por el inicio de sesión, y la passkey añadida sobrevive a la limpieza del teléfono.

Para las entidades sujetas a NIS2, la autenticación multifactor es una de las medidas exigidas: esta vulnerabilidad recuerda que el segundo factor debe gestionarse como cualquier otro software, con actualizaciones y versiones mínimas obligatorias. Una cuenta comprometida con acceso a correo y documentos puede convertirse en un incidente significativo, con los plazos de notificación que fija la transposición nacional de NIS2 (en Italia, al CSIRT Italia según el D.Lgs. 138/2024).

Qué hacer ahora

• Actualiza Microsoft Authenticator en Android a la versión 6.2606.4246 o posterior y comprueba la versión realmente instalada en los dispositivos de la empresa.
• Si gestionas los dispositivos con un MDM, impón la versión mínima de Authenticator y distribuye la actualización desde Google Play gestionado.
• Bloquea la instalación desde orígenes desconocidos (sideloading), al menos en el perfil de trabajo, y limita las apps que se pueden instalar en los dispositivos gestionados.
• Revisa los métodos de autenticación registrados en las cuentas, sobre todo las passkeys añadidas o eliminadas recientemente: en los registros de auditoría de Microsoft Entra ID, busca registros de nuevos métodos de seguridad que no correspondan al usuario.
• Si tienes dudas sobre una cuenta, elimina los métodos no reconocidos, revoca las sesiones activas y pide al usuario que vuelva a iniciar sesión desde un dispositivo actualizado.
• Recuerda a los usuarios que instalen apps solo desde tiendas de confianza: la vulnerabilidad requería de todos modos una app maliciosa en el teléfono.

Última actualización: 28 de octubre de 2026