Vulnerabilidade CVE-2026-80097 permitia que aplicativos Android maliciosos obtivessem tokens de autenticação de contas corporativas sem permissões especiais. O caso levanta questões sobre confiança entre aplicações, segurança mobile e os limites da autenticação multifator.
Uma investigação conduzida pela empresa de segurança Enclave revelou uma vulnerabilidade no Microsoft Authenticator para Android capaz de transformar um dos principais componentes de proteção de identidades corporativas em um ponto de exposição de credenciais digitais.
Identificada como CVE-2026-80097, a falha permitia que um aplicativo Android malicioso, mesmo sem solicitar permissões especiais ao sistema operacional, se passasse por aplicações legítimas da Microsoft e obtivesse tokens associados a contas corporativas autenticadas.
A vulnerabilidade foi corrigida pela Microsoft em setembro de 2026, mas os detalhes técnicos divulgados pela Enclave em 23 de outubro, seguidos de nova cobertura especializada em 27 de outubro, trouxeram à discussão um problema estrutural: o que acontece quando o componente responsável por intermediar a autenticação deixa de validar corretamente a identidade da aplicação que solicita acesso?
AuthMask: quando o aplicativo malicioso se apresenta como Microsoft Teams
A técnica demonstrada pelos pesquisadores recebeu o nome de AuthMask.
O ataque explorava uma atividade exportada do Microsoft Authenticator chamada AccountChooserActivity, utilizada no processo de comunicação entre aplicações Android e o broker de autenticação da Microsoft.
No Android, uma atividade exportada pode ser iniciada por outros aplicativos. Isso não representa necessariamente uma vulnerabilidade, desde que existam mecanismos adequados de autenticação e autorização para validar quem está realizando a chamada.
O problema identificado estava justamente nessa validação.
Segundo a investigação, o Authenticator aceitava informações fornecidas pela própria aplicação solicitante, incluindo a identidade do aplicativo, o identificador do cliente e parâmetros associados à autenticação.
Em vez de estabelecer a confiança com base na identidade efetiva do processo Android responsável pela chamada, a implementação vulnerável utilizava informações que podiam ser manipuladas.
Na demonstração, os pesquisadores conseguiram fazer um aplicativo sem permissões especiais se apresentar como Microsoft Teams.
O Authenticator processou a solicitação e devolveu tokens de autenticação à aplicação que havia iniciado a operação.
O ponto crítico não era uma quebra criptográfica, mas uma falha na validação da identidade do solicitante.
Tokens corporativos expostos: o alcance potencial do problema
A pesquisa demonstrou a obtenção de diferentes tipos de tokens, incluindo:
- Access tokens: utilizados para acessar APIs e recursos protegidos em nome de uma identidade autenticada.
- Refresh tokens: empregados para solicitar novos tokens de acesso, conforme as políticas e condições aplicáveis.
- ID tokens: utilizados para representar informações de autenticação da identidade.
Nos testes publicados, a personificação de aplicações Microsoft permitiu obter permissões delegadas relacionadas a serviços como Microsoft Graph, correio eletrônico, arquivos, calendários e funcionalidades de colaboração.
Entre os escopos demonstrados estavam Mail.ReadWrite, Mail.Send, Files.ReadWrite.All, Calendars.ReadWrite e Sites.ReadWrite.All.
Os pesquisadores também demonstraram solicitações relacionadas à gestão de métodos de autenticação e passkeys.
Isso não significa que qualquer aplicativo malicioso pudesse obter acesso irrestrito a todos os recursos de uma organização. O alcance efetivo dependeria dos tokens obtidos, das permissões previamente concedidas, das políticas de acesso e de outras proteções existentes.
Entretanto, a demonstração comprova um risco importante: uma aplicação não confiável poderia receber tokens que deveriam estar disponíveis exclusivamente para aplicações legitimamente autorizadas.
Por que o MFA não era suficiente para impedir o ataque?
A autenticação multifator continua sendo um dos mecanismos mais importantes de proteção contra comprometimento de contas.
Entretanto, o caso AuthMask evidencia uma distinção frequentemente negligenciada nos programas corporativos de IAM: autenticar corretamente um usuário não equivale a garantir que todas as aplicações que utilizam sua sessão sejam confiáveis.
No cenário demonstrado, o usuário já possuía uma conta corporativa autenticada no Microsoft Authenticator.
A exploração não dependia de convencer a vítima a aprovar uma nova solicitação de MFA ou fornecer sua senha. O aplicativo malicioso explorava a relação de confiança entre o broker e as aplicações instaladas no dispositivo.
Isso desloca a discussão da segurança do processo inicial de autenticação para a segurança da utilização posterior dos tokens.
Em arquiteturas modernas baseadas em OAuth 2.0 e OpenID Connect, os tokens representam autorizações e informações de identidade que podem ser utilizadas por aplicações e serviços.
Quando um token do tipo bearer é obtido indevidamente, sua posse pode permitir o acesso aos recursos autorizados, respeitadas as restrições e os controles adicionais aplicáveis.
Portanto, a proteção da identidade precisa abranger não apenas o login, mas também a emissão, o armazenamento, a entrega e a utilização desses tokens.
Microsoft Entra ID e Conditional Access: quais são as implicações?
Para organizações que utilizam Microsoft Entra ID, o caso merece atenção especial.
O Conditional Access permite estabelecer políticas considerando fatores como identidade, risco, localização, aplicação e condições do dispositivo.
Esses mecanismos são fundamentais para reduzir a superfície de ataque, mas não devem ser confundidos com uma garantia absoluta de segurança em todas as etapas do ciclo de vida dos tokens.
A vulnerabilidade AuthMask estava localizada no comportamento do aplicativo Authenticator para Android, especificamente na validação de chamadas ao broker.
Isso significa que o problema não deve ser interpretado automaticamente como uma falha no mecanismo central de Conditional Access do Entra ID.
Ainda assim, a investigação demonstra por que as organizações precisam considerar cenários nos quais um token pode ser exposto depois de uma autenticação legítima.
Algumas capacidades merecem avaliação nesse contexto:
1. Controles de conformidade dos dispositivos
Políticas que exigem dispositivos gerenciados ou conformes podem reduzir determinados riscos associados a endpoints não confiáveis. Contudo, um dispositivo considerado conforme não elimina automaticamente vulnerabilidades presentes em aplicativos instalados.
2. Proteção de aplicações e gestão mobile
Soluções de Mobile Device Management (MDM) e Mobile Application Management (MAM), incluindo recursos do Microsoft Intune, podem ajudar a controlar o ambiente corporativo e a distribuição de aplicativos.
A eficácia depende das políticas implementadas e do modelo de gestão adotado.
3. Proteção e vinculação de tokens
Mecanismos de proteção que vinculam tokens a dispositivos ou sessões específicas podem reduzir determinadas formas de reutilização indevida. Entretanto, sua cobertura varia conforme o aplicativo, o recurso e o cenário de autenticação.
Esses mecanismos não devem ser considerados uma correção substituta para a vulnerabilidade identificada.
4. Monitoramento de atividades suspeitas
O monitoramento de acessos ao Microsoft Graph, alterações em métodos de autenticação, atividades de aplicações e sinais de comprometimento de dispositivos pode contribuir para a investigação de incidentes relacionados a identidades.
Nenhum desses controles, isoladamente, garante a detecção de toda exploração possível.
A confiança entre aplicações torna-se uma questão de IAM
Tradicionalmente, programas de Identity and Access Management concentram seus esforços em responder a perguntas como:
- Quem é o usuário?
- Como sua identidade foi autenticada?
- Quais aplicações e recursos ele pode acessar?
- Quais permissões foram concedidas?
O caso AuthMask acrescenta uma dimensão fundamental:
Como garantir que a aplicação que solicita um token é realmente aquela que afirma ser?
Essa pergunta conecta IAM, segurança de aplicações, proteção de endpoints e arquitetura Zero Trust.
Em ambientes corporativos, os brokers de autenticação exercem um papel privilegiado. Eles intermediam operações de autenticação e acesso entre identidades, aplicações e serviços.
Por essa razão, sua implementação precisa estabelecer limites de confiança rigorosos, especialmente quando recebe solicitações de processos externos.
A identidade declarada por uma aplicação não pode substituir a verificação independente de sua identidade real.
Esse princípio é particularmente relevante em ecossistemas mobile, nos quais diferentes aplicações compartilham um dispositivo e utilizam mecanismos de comunicação fornecidos pelo sistema operacional.
O que as organizações devem fazer agora?
A Microsoft corrigiu a vulnerabilidade em setembro de 2026. De acordo com a pesquisa da Enclave, versões do Microsoft Authenticator para Android anteriores à 6.2606.4246 são afetadas.
O registro CVE-2026-80097 recebeu classificação de severidade alta, com pontuação CVSS de 8,6.
Para as equipes de IAM, segurança corporativa e gestão de endpoints, algumas ações são recomendadas:
- Verificar as versões instaladas do Microsoft Authenticator para Android, garantindo a atualização para a versão corrigida ou posterior.
- Avaliar a exposição dos dispositivos corporativos e dos dispositivos pessoais utilizados para trabalho, especialmente em ambientes BYOD.
- Revisar as políticas de gestão e conformidade mobile, incluindo os mecanismos de atualização e distribuição de aplicativos.
- Reavaliar a proteção de tokens e sessões, considerando os controles efetivamente suportados pelos aplicativos e serviços utilizados.
- Aprimorar a capacidade de investigação de incidentes de identidade, incluindo eventos relacionados ao Microsoft Graph e à alteração de métodos de autenticação.
A publicação da vulnerabilidade não comprova, por si só, exploração ativa em organizações específicas. Eventuais decisões de revogação de sessões, investigação forense ou resposta a incidentes devem considerar evidências concretas e o nível de exposição identificado.
A perspectiva OWLK: identidade confiável exige aplicações confiáveis
O AuthMask representa um exemplo de como vulnerabilidades de identidade podem surgir em componentes que, tradicionalmente, são considerados parte da infraestrutura de proteção.
A lição vai além do Microsoft Authenticator.
À medida que organizações ampliam o uso de autenticação sem senha, brokers de identidade, aplicações mobile e mecanismos de Single Sign-On, a confiança entre os diferentes componentes torna-se tão importante quanto a autenticação do usuário.
Uma arquitetura Zero Trust não deve presumir que uma aplicação é legítima apenas porque está instalada em um dispositivo ou porque apresenta identificadores compatíveis com os de um software confiável.
É necessário verificar a identidade real do solicitante, proteger os tokens durante todo o seu ciclo de vida e estabelecer mecanismos consistentes de autorização.
O MFA protege o processo de autenticação. A segurança da identidade precisa proteger também tudo o que acontece depois dele.
O caso CVE-2026-80097 reforça uma realidade cada vez mais relevante para o mercado de Identity Security: a segurança corporativa não depende apenas de saber quem está autenticado, mas também de garantir quem está solicitando acesso em nome dessa identidade.
Fontes e referências
- Enclave Research — AuthMask: We Made Microsoft Authenticator Hand Over Tokens to an App With Zero Permissions. Publicado em 23 de outubro de 2026.
https://enclave.ai/blog/authmask-we-made-microsoft-authenticator-hand-over-tokens - Microsoft Security Response Center — CVE-2026-80097. Registro oficial da vulnerabilidade.
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-80097 - Help Net Security — Microsoft Authenticator vulnerability patched (CVE-2026-80097). Cobertura de 27 de outubro de 2026.
https://www.helpnetsecurity.com/2026/10/27/microsoft-authenticator-vulnerability-patchedcve-2026-80097/
