Device code phishing: l'autenticazione MFA aggirata su Microsoft 365

Proofpoint Threat Research ha tracciato cluster di minaccia che dal settembre 2025 hanno intensificato l'abuso del flusso OAuth 2.0 device authorization grant per compromettere account Microsoft 365 senza rubare password e facendo completare alle vittime l'autenticazione a più fattori su domini ufficiali della piattaforma. L'attacco non sfrutta vulnerabilità: sfrutta una configurazione che la maggior parte delle organizzazioni non sa di dover controllare. Trend Micro, Push Security e ReversingLabs hanno confermato meccanismo e scalata, con l'emergere di kit PhaaS che abbassano la soglia di accesso anche per operatori non specializzati.

Come funziona l'ingegneria dell'autenticazione

L'attacco si appoggia al protocollo definito nell'RFC 8628. L'operatore inizia una richiesta di device code a Microsoft, ottiene un codice utente e un URL di verifica, poi induce la vittima a inserire quel codice su microsoft.com/devicelogin o sui corrispettivi aka.ms short link. ReversingLabs ha confermato l'uso dell'URL legittimo aka.ms/devicelogin, ospitato su infrastruttura Akamai, nelle landing page analizzate.

La vittima vede la pagina di login ufficiale di Microsoft, inserisce le proprie credenziali e completa l'autenticazione a più fattori come farebbe in qualsiasi altro contesto. Il sistema rilascia token di accesso e refresh token all'applicazione registrata dall'attaccante. Proofpoint sottolinea che "nessuna credenziale viene rubata, nessuna pagina di login è contraffatta, e nulla è tecnicamente guasto": l'identità della vittima appare normale alla piattaforma.

Trend Micro ha analizzato casi in cui l'attaccante, dopo l'accesso iniziale, sfrutta il Microsoft Authentication Broker per registrare un dispositivo controllato e ottenere token di refresh a lunga durata, stabilendo persistenza che sopravvive al cambio password della vittima.

La scalata dal settembre 2025 e la commoditazione criminale

Proofpoint ha osservato un incremento significativo di queste campagne a partire dal settembre 2025. Il meccanismo non è nuovo: Microsoft aveva documentato l'uso della tecnica da parte del cluster Storm-2372 già nell'agosto 2024, con escalation al Primary Refresh Token nel febbraio 2025. Ciò che cambia è la democratizzazione dell'attacco.

Push Security ha rilevato un aumento del 37,5 volte delle pagine di phishing device code nel 2026, rispetto a un incremento già di 15 volte rilevato a marzo. La stessa fonte ha identificato oltre 14 kit distinti in circolazione e ha documentato EvilTokens come primo kit PhaaS criminale dedicato al device code phishing, lanciato nel febbraio 2026 e già utilizzato in campagne su larga scala.

The Hacker News, raccogliendo dati Huntress, ha riportato che il solo cluster EvilTokens ha colpito oltre 340 organizzazioni Microsoft 365 in cinque paesi, con l'84% degli eventi osservati attribuito a tre indirizzi IP su infrastruttura Railway.com. Parallelamente, ZeroBEC ha descritto il tooling DEBULL come infrastruttura broker riutilizzabile che incapsula la tradecraft alla Storm-2372, confermando la transizione da tecniche sviluppate da attori avanzati a prodotti off-the-shelf per la criminalità informatica.

Il punto cieco della "configuration hygiene"

L'angolo di lettura suggerito da Proofpoint è che le organizzazioni verificano l'attivazione della MFA come metrica di sicurezza, ma non controllano quali flussi di autenticazione restano abilitati. Il device authorization grant è legittimo per scenari IoT e dispositivi con input limitato; per la maggior parte delle organizzazioni che non lo usano, rappresenta una superficie di attacco invisibile.

Questo crea un paradosso per i team di sicurezza: l'autenticazione appare corretta nei log, la MFA è stata soddisfatta, il dominio è autentico, eppure l'accesso è compromesso. Trend Micro ha evidenziato come i controlli tradizionali basati su rilevamento di pagine di phishing contraffatte o su analisi delle credenziali rubate non intercettino questa catena d'attacco.

"Device code phishing succeeds not because security controls fail, but because they were never configured to stop it" — Reach.Security riportando le conclusioni di Proofpoint

Cosa fare adesso

• Verificare in Microsoft Entra ID Conditional Access se il flusso OAuth device authorization grant è abilitato: bloccarlo dove non serve è la mitigazione più efficace indicata da Proofpoint.
• Controllare le applicazioni registrate nel tenant per rilevare registrazioni sospette che possano essere utilizzate come destinazione di token device code.
• Monitorare i log di autenticazione per sessioni originate da flusso device code con successiva escalation a richieste di token per il servizio di registrazione dispositivi, pattern documentato da Trend Micro.
• Valutare la disponibilità di regole di rilevamento nei sistemi XDR/SIEM: Trend Micro ha pubblicato query di rilevamento specifiche per questo meccanismo.

Perché la commoditazione cambia la soglia di rischio

La transizione da tecnica manuale di attori avanzati a prodotto PhaaS disponibile su scala modifica la geometria della minaccia. Non serve più competenza specifica su Azure AD o sul protocollo OAuth: l'infrastruttura è fornita come servizio, con landing page preconfezionate e pannelli di gestione delle vittime. Push Security e Huntress concordano sul fatto che il 2026 segna il passaggio da fase sperimentale a adozione mainstream della tecnica.

La questione aperta riguarda la sovrapposizione tra cluster: Proofpoint traccia UNK_AcademicFlare e TA2723; Microsoft e ZeroBEC/BEC discutono Storm-2372 e DEBULL; Huntress e Push Security analizzano EvilTokens. Se questi sono attori distinti che condividono tradecraft o segmenti della stessa catena di supply è incerto allo stato attuale. Ciò che le fonti convergentemente documentano è che il meccanismo funziona, che le difese standard non lo intercettano, e che la barriera all'ingresso continua a scendere.

Domande frequenti

Perché la MFA non blocca questo attacco?

Perché la vittima compie autenticazione reale e completa, MFA inclusa, sul dominio legittimo di Microsoft. La MFA verifica l'identità dell'utente, non l'intenzione di autorizzare un'applicazione specifica.

È una vulnerabilità di Microsoft da correggere con patch?

No. Il flusso device authorization grant è una funzionalità standardizzata nell'RFC 8628 e implementata correttamente. L'abuso è configurativo, non implementativo: l'organizzazione non ha disabilitato un flusso che non utilizza.

Qual è il rischio se il device code scade in 15 minuti?

I 15 minuti sono la finestra di validità del codice utente per l'inserimento, documentati da Microsoft per Storm-2372. L'attaccante coordina la vittima in tempo reale; una volta ottenuto il token di accesso e il refresh token, la persistenza può durare mesi attraverso la registrazione di dispositivi rogue.

Fonti

• https://www.reach.security/blog/what-device-code-phishing-reveals-about-security-configuration-gaps
• https://www.trendmicro.com/en_us/research/26/g/device-code-phishing.html
• https://thehackernews.com/2026/07/debull-tooling-abuses-microsoft-device.html
• https://www.reversinglabs.com/blog/device-code-phishing-campaign
• https://pushsecurity.com/blog/device-code-phishing/
• https://www.trendmicro.com/vinfo/us/security/news/cybercrime-and-digital-threats/from-stealers-to-systems-the-new-model-of-credential-theft
• https://thehackernews.com/2026/03/device-code-phishing-hits-340-microsoft.html
• https://thehackernews.com/2025/02/microsoft-russian-linked-hackers-using.html

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti