Microsoft corrigió una vulnerabilidad en Microsoft Authenticator para Android. La falla permitía que una aplicación maliciosa, sin pedir ningún permiso, se hiciera pasar por una app legítima de la compañía, como Teams, y obtuviera tokens de acceso a la cuenta de trabajo de la víctima. En las pruebas de los investigadores, esos tokens daban acceso completo al correo, los archivos y el calendario.
La falla ya tiene parche y Microsoft asegura que nadie la ha usado en ataques reales. El caso deja de todas formas una lección que va más allá de instalar una actualización: la autenticación multifactor solo protege la cuenta si el dispositivo donde funciona también está protegido.
Qué corrigió Microsoft en Authenticator para Android
Microsoft registró la vulnerabilidad como CVE-2026-80097. Le asignó una puntuación de 8.6 en la escala CVSS, que la compañía clasifica como "Importante". La corrección llegó en la versión 6.2606.4246 de Authenticator para Android y formó parte del paquete de parches de setiembre de 2026.
La investigación es de Ofek Levin, que la realizó dentro de un programa de becas de la firma de seguridad Enclave. Microsoft asignó el identificador el 8 de setiembre y Enclave publicó los detalles técnicos el 23 de octubre, cuando el parche ya estaba disponible.
Cómo una app sin permisos se hacía pasar por Teams
En Android, Authenticator no se limita a mostrar códigos de seis dígitos. También funciona como intermediario de inicio de sesión. Cuando Teams, Outlook u otra app de Microsoft necesita autenticar al usuario, se lo pide a Authenticator, y este le entrega un token: una especie de pase digital que demuestra que la persona ya inició sesión.
Como ese intermediario controla el acceso a toda la cuenta, debería ser muy estricto con las apps a las que entrega tokens. Aquí falló. Authenticator tenía un componente interno que cualquier aplicación del teléfono podía activar. Cuando la app maliciosa lo activaba, Authenticator armaba la solicitud de token con los datos que esa misma app le daba, incluido el nombre de la aplicación que decía ser. La app se presentaba como Teams y Authenticator le creía.
Por qué la verificación de firma no detuvo el engaño
Existía un control pensado justamente para evitar suplantaciones: la verificación de la firma digital de la app solicitante. El problema es que ese control buscaba la firma de la app suplantada, no la de la app que realmente hacía la petición. Si Teams estaba instalado en el equipo, su firma auténtica estaba disponible y la verificación salía bien.
Según Enclave, Authenticator sí podía saber qué aplicación estaba haciendo la solicitud, pero no usaba ese dato para decidir si entregaba el token.
Qué podía obtener el atacante con esos tokens
En las pruebas de Enclave, la app maliciosa se presentó como Teams y pidió tokens para Microsoft Graph, el servicio que conecta las aplicaciones de Microsoft 365. Obtuvo permisos para leer y enviar correos, leer y modificar archivos, y leer y modificar calendarios, entre otros.
Microsoft lo explica en términos más generales: un atacante podía autenticarse como el usuario y acceder a sus recursos. El alcance se limita a la cuenta de trabajo iniciada en Authenticator en ese teléfono, no a otras cuentas. Hay además una duda que el aviso de Microsoft no resuelve: si actualizar la app invalida los tokens que una app maliciosa ya hubiera obtenido.
Un token robado funciona igual que una sesión ya validada, el mismo principio que explica el robo de cookies de sesión en empresas: para la plataforma, quien lo presenta ya demostró ser quien dice ser.
Investigadores y Microsoft no coinciden en el nivel de riesgo
Enclave y Microsoft describen de forma distinta lo que hacía falta para aprovechar la falla. Según los investigadores, su prueba de concepto obtuvo tokens sin intervención del usuario. Bastaba con que hubiera una cuenta iniciada en el equipo.
Microsoft, en cambio, sostiene que el atacante tenía que lograr dos cosas: que la víctima instalara la app maliciosa y que completara un paso de autenticación en Authenticator. La compañía considera que la explotación es "menos probable" y afirma que la falla no se hizo pública antes del parche. Al 26 de octubre, tampoco figuraba en el catálogo de vulnerabilidades explotadas de CISA, la agencia de ciberseguridad de Estados Unidos.
Las dos versiones coinciden en lo esencial: todo empieza con una aplicación maliciosa instalada en el celular.
El celular personal como puerta a la cuenta institucional
En muchas entidades públicas y empresas peruanas, los trabajadores usan su propio celular para revisar el correo institucional y aprobar inicios de sesión. Es práctico, pero ese teléfono suele tener juegos, apps descargadas fuera de la tienda oficial y aplicaciones que nadie del área de TI revisó. Es el mismo terreno en el que opera el malware para Android que llega por SMS falsos.
Esta falla muestra el riesgo con claridad. El segundo factor de autenticación seguía activo y la contraseña nunca se filtró. Aun así, una app instalada en el mismo equipo podía terminar con acceso al buzón del trabajador. Si ese correo contiene datos personales de ciudadanos o clientes, un acceso así puede convertirse en un incidente que la organización deberá atender bajo la Ley 29733 de Protección de Datos Personales.
Medidas para entidades y empresas que usan Microsoft 365
La primera medida es la más simple, y conviene confirmarla en lugar de darla por hecha:
- Actualizar Microsoft Authenticator en todos los equipos Android a la versión 6.2606.4246 o posterior.
- Exigir una versión mínima de la app desde la herramienta de gestión de dispositivos móviles, para que un teléfono desactualizado no pueda acceder a la cuenta institucional.
- Restringir la instalación de aplicaciones de origen desconocido en los equipos que acceden a recursos de trabajo, o separar el perfil laboral del personal.
- Revisar los registros de inicio de sesión de Microsoft 365 y revocar sesiones ante cualquier actividad extraña. No está claro si la actualización invalida los tokens ya emitidos, así que esta revisión es una precaución razonable.
Más allá de este parche, el caso confirma que los celulares que acceden a cuentas de trabajo deben gestionarse y vigilarse igual que una laptop o una estación de trabajo. Una estrategia de protección de endpoints que incluya los dispositivos móviles permite detectar aplicaciones maliciosas antes de que lleguen a interactuar con las apps corporativas, y una plataforma de monitoreo y gestión remota da la visibilidad para saber qué equipos quedaron sin actualizar.
Conclusión
Lo incómodo de este caso no es la falla, que ya está corregida, sino dónde ocurrió: en la aplicación que muchas organizaciones instalaron precisamente para estar más seguras. La contraseña no se filtró y el segundo factor siguió funcionando; lo que falló fue el teléfono donde vivía.
Por eso la tarea no termina al actualizar la app. Vale la pena responder una pregunta sencilla: ¿cuántos celulares acceden hoy al correo de su organización y cuántos de ellos administra realmente el área de TI? Si la segunda cifra es mucho menor que la primera, ahí está el trabajo pendiente.
