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

Microsoft Authenticator è finito al centro di una segnalazione tecnica per una vulnerabilità che permetteva a un’app Android di ricevere token fingendosi un’app Microsoft legittima. La falla, corretta da Microsoft, riguardava il meccanismo tramite cui il broker di autenticazione delega richieste alle app basate su Microsoft Identity Platform.
Come funzionava la falla in Microsoft Authenticator
Il problema nasceva dal ruolo di broker che Authenticator può assumere nelle configurazioni aziendali: oltre a generare codici MFA, il programma può gestire Single Sign-On e rilasciare token ad applicazioni che usano la Microsoft Authentication Library (MSAL). Secondo la descrizione pubblicata, in alcuni test un’app priva di permessi speciali riusciva a presentarsi al broker come se fosse un client Microsoft già installato e a ottenere i token associati. Questo scenario sfruttava la possibilità, prevista dal design del broker, che un’app richiedente si identifichi al broker per ottenere il token senza ulteriori autorizzazioni interattive.
Dettagli tecnici confermati e versione interessata
Microsoft ha indicato come vulnerabili le versioni dell’app per Android dalla 6.0.0 fino a quelle precedenti alla 6.2606.4246; la vulnerabilità è stata classificata con un identificativo (CVE-2026-80097) e sanata con aggiornamenti. Fonti che hanno esaminato la segnalazione descrivono il passaggio critico: il broker delega la richiesta dei token e in alcune condizioni non verificava in modo affidabile l’identità dell’app richiedente. Nei test dei ricercatori di Enclave l’app malevola riusciva a presentarsi come client Microsoft, un comportamento che non richiedeva permessi speciali sul dispositivo, elemento che ha aumentato la gravità della scoperta. Microsoft ha rilasciato patch per risolvere il difetto, aggiornando il controllo dell’identità dell’app richiedente.
Implicazioni per account, posta e risorse aziendali
Per le organizzazioni che usano Authenticator come broker, la conseguenza potenziale era l’esposizione di token che consentono l’accesso a risorse come posta, file e calendario. Questo perché i token rilasciati possono essere usati dalle app per operare a nome dell’utente. Le funzionalità aziendali interessate includono SSO, Conditional Access e la registrazione del dispositivo, tutte condizioni che aumentano il valore del token per un eventuale sfruttamento. L’eventuale furto di token in ambienti aziendali potrebbe permettere movimenti laterali all’interno della rete o l’accesso a servizi cloud gestiti dall’organizzazione, rendendo necessarie attività di controllo e revoca tempestiva dei token compromessi.
Azioni pratiche per utenti e amministratori
Per ridurre il rischio gli amministratori devono verificare che i dispositivi aziendali abbiano ricevuto l’aggiornamento e valutare le policy di Conditional Access e di gestione dei broker di autenticazione. Gli utenti Android dovrebbero aggiornare Microsoft Authenticator all’ultima versione disponibile tramite i canali ufficiali. È consigliabile anche rivedere l’elenco delle app autorizzate a interagire con i broker e monitorare l’attività dei token tramite i log del tenant. Per il dettaglio tecnico della segnalazione è disponibile un resoconto pubblico che descrive i test svolti dai ricercatori e l’intervento di correzione da parte di Microsoft: ilSoftware.it. Gli amministratori dovrebbero inoltre considerare la rotazione dei segreti e l’impostazione di criteri che riducano la finestra temporale di validità dei token quando possibile.
Quali aspetti restano da chiarire
Non tutti gli elementi dell’attacco sono pubblici: la porta d’ingresso esatta, la possibilità di sfruttamento su larga scala e le condizioni necessarie per riprodurre il comportamento non sono state tutte rese note nei dettagli pubblici. Alcune informazioni provengono dai test dei ricercatori e dalle note di sicurezza del fornitore; mancano però dati su eventuali abusi osservati in ambiente reale e su strumenti di mitigazione aggiuntivi adottati dai clienti. Rimane da valutare in che misura configurazioni specifiche di device management o policy aziendali possano aver aumentato o diminuito la superficie di attacco nei casi reali.
Impatto pratico per chi studia e lavora con strumenti Microsoft
La notizia sottolinea l’importanza di mantenere aggiornate le app di autenticazione e di monitorare i token con strumenti di sicurezza aziendale. Per chi utilizza SSO e broker di autenticazione in contesti professionali, la gestione centralizzata dei dispositivi e il controllo delle app autorizzate rimangono leve fondamentali per limitare esposizioni. La correzione rilasciata riduce il rischio noto, ma la cautela operativa resta consigliata. È utile anche aggiornare le procedure interne di incident response per includere la verifica di eventuali anomalie nei log di accesso e la pronta revoca dei token in caso di sospetto compromesso.
Azioni consigliate nelle aziende italiane e verifiche da eseguire
Per realtà italiane che dipendono da servizi Microsoft cloud, è opportuno verificare subito lo stato delle versioni di Microsoft Authenticator sui dispositivi Android gestiti e applicare gli aggiornamenti forniti da Microsoft. I team IT dovrebbero avviare controlli sui log di accesso per identificare richieste anomale provenienti da app non riconosciute e valutare la necessità di revocare token emessi nel periodo di esposizione. Inoltre, la revisione delle policy di Conditional Access e la limitazione dei privilegi delle applicazioni possono ridurre l’impatto di vulnerabilità simili in futuro.
Raccomandazioni operative per chi usa Authenticator
Gli utenti individuali e professionisti che usano Microsoft Authenticator devono aggiornare l’applicazione tramite il Play Store e segnalare al proprio reparto IT qualsiasi comportamento sospetto, come richieste di accesso non familiari o notifiche insolite. Gli amministratori dovrebbero considerare strumenti di monitoraggio continuo dei token e procedure di rotazione e revoca rapide. La segnalazione pubblica e la patch dimostrano che il rischio noto è stato mitigato, ma la gestione proattiva rimane la difesa più efficace contro possibili exploit non ancora osservati in natura.

