Device code phishing aggira l’MFA e conquista gli account Microsoft 365

🛡️ Executive Summary

• La vittima completa login e MFA sul vero portale Microsoft, ma autorizza inconsapevolmente la sessione richiesta dall’infrastruttura dell’attaccante.
• L’abuso del Microsoft Authentication Broker permette di registrare dispositivi, ottenere refresh token durevoli e mantenere l’accesso nel tempo.
• La difesa richiede il blocco selettivo del device code flow, dispositivi gestiti, token protection e monitoraggio degli eventi Entra ID.

Una campagna analizzata da Trend Micro mostra come il device code phishing possa trasformare una funzione legittima di OAuth 2.0 in un meccanismo per aggirare l’autenticazione multifattore. La vittima non inserisce la password in una pagina contraffatta e non comunica il codice temporaneo all’attaccante. Accede al vero sito Microsoft, completa regolarmente l’MFA e approva una richiesta valida. Il problema è che il codice visualizzato appartiene a una sessione avviata dal criminale. I token vengono quindi consegnati alla sua infrastruttura, che può accedere a Microsoft 365, registrare dispositivi abusivi, creare regole nascoste nella posta e utilizzare l’account compromesso per nuove campagne di phishing.

Il device code flow nasce per dispositivi senza tastiera

Il device authorization grant di OAuth 2.0 è stato progettato per apparecchi che non possono mostrare una normale pagina di autenticazione o rendono difficile l’inserimento delle credenziali, come smart TV, console, dispositivi IoT e sistemi installati nelle sale conferenze. Il dispositivo richiede al provider di identità un codice temporaneo e lo mostra all’utente, che apre un indirizzo ufficiale su un telefono o computer, inserisce il codice e completa l’autenticazione. Una volta ricevuta l’approvazione, il servizio restituisce i token al dispositivo che aveva iniziato la procedura. Il modello funziona perché presuppone che la persona e il dispositivo si trovino nello stesso contesto e condividano lo stesso obiettivo. L’attaccante rompe questa relazione: avvia la richiesta sul proprio server e convince un’altra persona ad approvarla. Microsoft vede un utente legittimo, una pagina autentica, credenziali corrette e un secondo fattore valido.

Non esiste quindi una password falsa da individuare o un cookie sottratto attraverso un reverse proxy. Il meccanismo era già apparso nelle campagne di phishing Microsoft 365 basate sul Device Code Flow, ma la nuova ricostruzione mostra quanto la tecnica sia diventata strutturata e capace di produrre persistenza cloud.

La vittima completa personalmente l’autenticazione multifattore

L’operatore criminale richiede a Microsoft un device code valido e lo inserisce in un’esca costruita per sembrare una normale procedura di collaborazione. Il messaggio può invitare a visualizzare un documento condiviso, verificare un account o collegarsi a una riunione. La vittima apre il portale ufficiale Microsoft, digita il codice ricevuto, inserisce le proprie credenziali e approva la notifica MFA. Dal suo punto di vista non compare alcun dominio sospetto durante la fase più sensibile, perché l’autenticazione avviene realmente sull’infrastruttura Microsoft.

L’attaccante interroga nel frattempo l’endpoint OAuth in attesa che il codice venga autorizzato. Quando la procedura si conclude, riceve i token associati all’identità della vittima e può utilizzarli dai propri sistemi. L’MFA non viene tecnicamente violata o disattivata: viene soddisfatta dall’utente per conto dell’avversario. È la stessa inversione di fiducia osservata nelle piattaforme PhaaS che sottraggono token Microsoft 365 senza dover conservare la password, ma il device code phishing elimina anche la necessità di replicare la pagina di accesso e intercettare in tempo reale la sessione.

La campagna costruisce fiducia prima di mostrare il codice

L’incidente osservato da Trend Micro non è iniziato con un collegamento improvviso. L’attaccante si è presentato come il rappresentante di uno studio legale interessato a una collaborazione e ha scambiato diversi messaggi con la vittima prima di inviare l’esca. Questa fase di social engineering trasforma il successivo invito in una conseguenza plausibile della conversazione, riducendo l’efficacia degli avvisi generici sui link inattesi. Il collegamento mostrava un indirizzo aziendale credibile, ma conduceva inizialmente a una pagina ospitata su Google Sites.

La catena proseguiva attraverso un open redirect presente su un sito legittimo compromesso e raggiungeva infine una pagina protetta da un falso controllo umano, utilizzato per ostacolare scanner automatici, sandbox e sistemi di reputazione. Il portale finale imitava un servizio di condivisione documentale e mostrava il codice da inserire nel sito Microsoft. Non scaricava malware, non richiedeva password e non produceva gli indicatori tipici di una pagina di credential harvesting. La campagna combina quindi servizi affidabili, redirect temporanei e una storia costruita nel tempo, confermando l’evoluzione dell’ingegneria sociale che utilizza phishing, vishing e identità aziendali credibili.

Il Microsoft Authentication Broker rende l’accesso persistente

Il rischio aumenta quando il device code viene richiesto attraverso il Microsoft Authentication Broker, componente utilizzato per coordinare l’autenticazione tra account, applicazioni e dispositivi Windows. Una singola approvazione può consentire all’attaccante di registrare nuovi dispositivi nell’ambiente Entra ID e ottenere refresh token capaci di generare ulteriori access token nel tempo. La compromissione smette così di essere una sessione isolata e diventa una presenza durevole nell’identità cloud. Nel caso ricostruito, poche ore dopo l’autorizzazione sono comparsi accessi dall’estero, registrazioni multiple di dispositivi e modifiche alla casella di posta. L’attaccante ha creato una regola nascosta per spostare risposte, notifiche di mancata consegna e messaggi potenzialmente rivelatori in cartelle poco visibili. Ha poi utilizzato l’account compromesso per inviare una nuova ondata di phishing a centinaia di destinatari esterni. Ogni messaggio proveniva da una casella reale, con cronologia, firma e reputazione legittime, aumentando la probabilità che i nuovi bersagli si fidassero. L’operazione ricorda le campagne passwordless contro Entra ID capaci di trasformare token validi in accesso aziendale persistente.

L’endpoint della vittima può restare completamente intatto

Una delle caratteristiche più pericolose del device code phishing è l’assenza di attività malevole sul computer della vittima. Nessun eseguibile viene scaricato, nessuna persistenza viene installata nel sistema operativo e nessun browser deve essere controllato attraverso un’estensione. Dopo l’approvazione, le operazioni avvengono tra infrastruttura dell’attaccante, Microsoft Entra ID, Exchange Online e gli altri servizi cloud autorizzati. Un EDR può quindi non rilevare nulla perché il dispositivo non è mai stato compromesso.

Anche il cambio della password potrebbe non essere sufficiente se l’organizzazione non revoca refresh token, sessioni esistenti e dispositivi registrati abusivamente. Il centro dell’indagine deve spostarsi dal computer all’identità: protocolli utilizzati durante il login, applicazioni autorizzate, provenienza degli accessi, registrazioni di device, modifiche alle regole della posta e attività sulle API Microsoft Graph. Il caso dimostra perché la sicurezza Microsoft 365 non possa essere ridotta alla protezione dell’endpoint. Un account compromesso può esfiltrare email, file e contatti utilizzando esclusivamente servizi autorizzati, senza generare traffico verso infrastrutture malware riconoscibili.

I log Entra ID mostrano segnali precisi

Le organizzazioni dovrebbero considerare anomala ogni autenticazione riuscita attraverso il protocollo deviceCode quando non esiste una necessità operativa documentata. Negli ambienti aziendali tradizionali, queste richieste dovrebbero essere rare e associate a dispositivi o applicazioni conosciute. Un secondo segnale riguarda l’accesso al Microsoft Authentication Broker da Paesi, reti o device non gestiti. Le registrazioni multiple effettuate in un intervallo ristretto, soprattutto dopo un’autenticazione device code, possono indicare il tentativo di trasformare il token iniziale in persistenza. Occorre correlare questi eventi con accessi geograficamente incompatibili, creazione di regole nella casella, lettura massiva dei messaggi e invii improvvisi verso destinatari esterni.

Le regole che spostano email in cartelle archivio, le marcano come lette o le eliminano devono ricevere particolare attenzione, perché permettono all’attaccante di nascondere risposte e avvisi di sicurezza. La telemetria deve ricostruire la sequenza completa: generazione del token, autenticazione, accesso al Device Registration Service, creazione del dispositivo, utilizzo di Outlook e modifica della mailbox. Osservare ogni evento separatamente produrrebbe numerosi falsi positivi; la correlazione temporale trasforma invece attività apparentemente legittime in una catena riconoscibile.

Conditional Access può chiudere il percorso di attacco

La misura più efficace consiste nel bloccare il device code flow attraverso Microsoft Entra Conditional Access dove non risulta indispensabile. La maggior parte delle organizzazioni può applicare una policy generale di negazione e creare eccezioni ristrette per specifici utenti, dispositivi o applicazioni che necessitano realmente di questa modalità. Gli account privilegiati, amministrativi e finanziari non dovrebbero poter utilizzare il protocollo senza una motivazione eccezionale. La registrazione dei dispositivi deve essere limitata a soggetti autorizzati, con un numero massimo contenuto per utente e l’obbligo di utilizzare endpoint gestiti e conformi per accedere a posta e documenti. Continuous Access Evaluation permette di interrompere più rapidamente le sessioni quando cambia il livello di rischio, mentre la token protection lega il token al dispositivo previsto e ne riduce la riutilizzabilità da infrastrutture esterne.

La sola autenticazione multifattore push non risolve il problema, perché è proprio la vittima a completarla. Servono metodi resistenti al phishing, come passkey e chiavi FIDO2, accompagnati da policy che verifichino il contesto del dispositivo e dell’applicazione. Le campagne VENOM contro dirigenti e account Microsoft 365 hanno già mostrato che l’MFA tradizionale perde efficacia quando l’attaccante controlla la procedura invece di limitarsi a indovinare le credenziali.

La formazione deve spiegare il significato del codice

Gli utenti sono stati abituati a controllare dominio, certificato e aspetto della pagina di login. Nel device code phishing questi elementi possono essere perfettamente legittimi. La formazione deve quindi introdurre una regola più specifica: un codice dispositivo deve essere inserito soltanto quando l’utente ha personalmente iniziato il collegamento di un apparecchio che possiede e sta utilizzando. Un documento condiviso, una riunione, un collega o un partner esterno non dovrebbero mai richiedere l’inserimento di un device code ricevuto via email o chat. La schermata Microsoft mostra inoltre l’applicazione e i permessi richiesti, ma molti utenti completano il processo rapidamente perché riconoscono il marchio e si aspettano un secondo passaggio di autenticazione. Le interfacce dovrebbero rendere più evidente che il codice autorizza un altro dispositivo e indicare posizione, app e conseguenze dell’approvazione. Le aziende devono offrire un canale semplice per segnalare richieste sospette prima di procedere. Nel caso di un’autorizzazione già concessa, la risposta deve comprendere revoca delle sessioni e dei refresh token, eliminazione dei device sconosciuti, analisi delle regole della posta, controllo degli accessi alle applicazioni e verifica dei messaggi inviati dall’account. Il device code phishing non supera l’MFA attraverso una falla software: sfrutta una funzione autentica e persuade l’utente a consegnare volontariamente all’attaccante una sessione già verificata.