Microsoft Authenticator: un'app Android poteva rubare i token fingendosi Teams

Un’app come Microsoft Authenticator su Android non serve soltanto a generare codici temporanei o approvare richieste MFA. Nelle configurazioni aziendali può assumere un ruolo molto più delicato: agisce come broker di autenticazione per le applicazioni che usano Microsoft Identity Platform, centralizzando l’accesso agli account e consentendo il Single Sign-On (SSO) tra app come Teams e altri client Microsoft. Proprio questa funzione ha trasformato una vulnerabilità apparentemente circoscritta in un problema capace di esporre token con accesso a posta, file, calendari e altre risorse.

La falla, catalogata come CVE-2026-80097 e corretta da Microsoft nelle scorse settimane, è importante perché mette in evidenza una vulnerabilità sorprendente: nei test svolti dai ricercatori di Enclave, un’app Android priva di permessi speciali riusciva a presentarsi ad Authenticator come un’app Microsoft legittima già installata sul dispositivo, ricevendo – indisturbata – i relativi token. Microsoft indica come vulnerabili le versioni di Authenticator per Android dalla 6.0.0 fino a quelle precedenti alla 6.2606.4246.

Perché Authenticator può consegnare token ad altre applicazioni

MSAL, la Microsoft Authentication Library, può delegare la richiesta dei token a un broker installato sul dispositivo: Microsoft Authenticator, Intune Company Portal e Collegamento a Windows possono svolgere questa funzione.

L’utente effettua l’accesso una volta sola, mentre il broker gestisce successivamente le richieste delle applicazioni autorizzate. Il meccanismo supporta anche funzionalità aziendali come Conditional Access, registrazione del dispositivo e gestione centralizzata degli account.

Una struttura del genere presuppone però una condizione fondamentale: il broker deve sapere con certezza quale applicazione gli sta chiedendo un token. Se un programma può dichiarare autonomamente la propria identità, senza che tale dichiarazione sia collegata alla reale identità Android del chiamante, l’intero modello di fiducia si indebolisce. Ed è precisamente ciò che Enclave ha trovato.

Il punto di ingresso analizzato dai ricercatori è com.microsoft.identity.client.AccountChooserActivity, un’Activity Android eseguita nel processo :auth di Authenticator: nel manifest Android risultava contrassegnata con android:exported="true". In pratica, altre applicazioni presenti sul dispositivo potevano avviarla.

Il controllo della firma sembrava robusto, ma l’identità del richiedente poteva essere manomessa

Authenticator effettuava una verifica che, letta superficialmente, sembra corretta. Il broker ricostruiva il redirect URI associato al pacchetto dichiarato, usando la firma dell’applicazione installata, e confrontava il risultato con il redirect URI fornito nella richiesta. La firma dell’app dovrebbe servire proprio a impedire a un’applicazione differente di appropriarsi del flusso di autenticazione.

Il fatto è che Authenticator controllava la coerenza tra due informazioni riconducibili al pacchetto che il richiedente sosteneva di rappresentare; non verificava invece che quel package corrispondesse davvero all’app che aveva aperto l’Activity.

Un’app malevola poteva individuare, tramite PackageManager, un’app Microsoft installata come Teams, recuperarne le informazioni pubblicamente accessibili necessarie a ricostruire il redirect URI e inserirle nella richiesta.

Il controllo esercitato da Authenticator si limitava a verificare che il redirect URI fosse corretto ma non accertava che il mittente della richiesta fosse, ad esempio, proprio l’app Teams legittima.

AuthMask: fingersi Teams senza possedere permessi Android

Nel suo proof of concept, Enclave ha usato come identità dichiarata il package com.microsoft.teams e il client ID associato a Teams. L’app di test recuperava anche l’UID dell’app installata e costruiva il relativo redirect URI.

Non serviva ottenere il controllo di Teams, modificarne i file o violarne la sandbox Android: l’applicazione malevola poteva restare separata e senza permessi Android dichiarati. Sfruttava semplicemente il fatto che Authenticator accettava come attendibile un’identità fornita nella richiesta.

La vulnerabilità evidenziata non è una minuzia: non parliamo della sottrazione di una password, ma di credenziali già utilizzabili per accedere alle API autorizzate per l’utente. Un token OAuth valido consente infatti di operare con i privilegi dell’utente senza dover ripetere autenticazione e MFA per ogni singola chiamata.

Posta, OneDrive, calendari e persino metodi di autenticazione

I test descritti da Enclave mostrano quanto potesse cambiare l’impatto a seconda dell’applicazione impersonata e della risorsa richiesta. Fingendosi Teams e interrogando Microsoft Graph con lo scope .default, i ricercatori hanno ottenuto autorizzazioni comprendenti Mail.ReadWrite, Mail.Send, Files.ReadWrite.All, Calendars.ReadWrite, ChatMessage.Send e Sites.ReadWrite.All.

A seconda dei permessi effettivamente concessi all’account, significa che un’app Android di terze parti avrebbe avuto strada libera per poter leggere o modificare messaggi, inviare posta, intervenire sui file accessibili all’utente, manipolare calendari e interagire con contenuti Microsoft 365.

Enclave ha poi verificato se l’attacco permettesse di impersonare non soltanto l’app Teams visibile all’utente, ma anche altri client Microsoft registrati nei servizi di autenticazione. In uno dei test, i ricercatori hanno usato l’identità applicativa associata al componente che gestisce le funzioni di chat di Teams e hanno ottenuto un token con lo scope user_impersonation: il token consentiva al client di agire verso quel servizio per conto dell’utente autenticato, entro i permessi previsti dall’applicazione.

Il test più delicato ha riguardato però Microsoft Authenticator stesso. Facendo apparire l’app malevola come Authenticator, i ricercatori hanno ricevuto token che includevano addirittura autorizzazioni quali UserAuthenticationMethod.ReadWrite, Passkey.Create e Passkey.Delete! Non si tratta di semplici permessi per leggere posta o file: riguardano direttamente la gestione dei metodi con cui l’account dimostra la propria identità, comprese le passkey. In uno scenario favorevole all’attaccante, quindi, la vulnerabilità poteva aprire la strada non solo all’accesso ai dati, ma anche a operazioni sui meccanismi di autenticazione associati all’utente.

Serve un’app sul dispositivo: non è un attacco remoto dal Web

La falla CVE-2026-80097 richiede che il codice malevolo riesca a insediarsi in qualche modo sul dispositivo Android dove Authenticator è installato e dove risulta configurato un account aziendale. Microsoft classifica infatti l’attacco come locale, con complessità bassa e senza privilegi iniziali.

AuthMask non è perciò sfruttabile da remoto visitando un sito Web: il rischio diventa concreto soprattutto quando un dispositivo aziendale consente l’installazione di software non fidato, APK distribuiti fuori dallo store o applicazioni apparentemente innocue che contengono codice ostile.

Chi usa Authenticator dovrebbe quindi verificare di disporre della versione 6.2606.4246 o di una successiva, preferibilmente mantenendo attivi gli aggiornamenti automatici tramite Google Play o il sistema di distribuzione aziendale.