• Cloud, Guide, Microsoft 365, Sicurezza
• 2 Maggio 2026

Nel corso dei primi mesi del 2026 si è visto un importante aumento di attacchi legati al Device Code Phishing.

Microsoft stessa, nel Digital Defense Report 2025, ne documenta l’ampio sfruttamento da parte di cybercriminali e gruppi organizzati. Si riporta che il 93% degli attacchi di tipo Device Code Phishing osservati da Microsoft nel 2025 sono concentrati nella seconda metà dell’anno.

Con questa guida voglio aiutarti a capirne di più e a mitigare questo insidioso attacco nel modo più semplice ed efficace. Sfrutteremo uno degli strumenti di sicurezza più potenti messi a disposizione dalla suite Microsoft365: Conditional Access.

Che cos’è un attacco di tipo Device Code Phishing?

Il device code phishing è una tecnica di attacco che sfrutta il legittimo flusso di autenticazione device code flow per rubare access token e refresh token senza mai richiedere la password della vittima.

Il Device Code Flow serve per l’autenticazione su dispositivi che non hanno un browser integrato (es. smart TV, dispositivi IoT, CLI e terminali…). Il flusso avviene in due fasi: l’app richiede autenticazione e mostra all’utente un messaggio contenente il codice da usare e l’url di un sito dove inserirla. L’utente visita l’url e inserisce il codice. L’app ottiene da Entra il token di accesso dopo che l’utente si è autenticato sulla pagina.

Il flusso dell’attacco è il seguente:

1. L’attaccante contatta la vittima tramite applicazioni di messaggistica di terze parti, spesso impersonando un amministratore o un referente fidato.
2. Invia un device code legittimo accompagnato da un link a un portale di autenticazione apparentemente autentico.
3. La vittima inserisce il codice nel portale.
4. L’attaccante cattura i token generati e ottiene accesso all’account compromesso.

Figura 1 Flusso dell’attacco Device Code Phishing

Perché è particolarmente pericoloso:

1. Evasione dei sistemi di rilevamento: poiché l’autenticazione utilizza codici e token legittimi, gli strumenti antivirus e anti-phishing tradizionali spesso non lo rilevano. Le comunicazioni fuori dai canali aziendali monitorati possono amplificare questo problema.
2. Persistent access e lateral movement: finché il refresh token rimane valido, l’attaccante mantiene accesso continuativo e può muoversi lateralmente nella rete.
3. Data exfiltration immediata: l’accesso si estende a email, cloud storage e tutti i servizi collegati all’account compromesso.

Evoluzione recente:

Microsoft ha osservato un caso particolarmente insidioso in cui la vittima veniva indotta a inserire il device code all’interno di un invito Microsoft Teams, rendendo ancora più difficile per l’utente riconoscere l’attività fraudolenta.

Dal campo ho avuto evidenze di diversi tentativi di attacco tramite contatto diretto dell’utente tramite Teams o telefono. L’attaccante si spaccia per operatore dell’helpdesk aziendale e convince l’utente che deve seguire le istruzioni per un fantomatico “processo di verifica dei sistemi in uso”.

Perché può colpire anche gli utenti esperti:

Sebbene la tecnica non sia nuova, la maggior parte degli utenti (inclusi alcuni profili tecnici) non è stata formata a riconoscere attacchi che sfruttano il device code flow. La combinazione di social engineering mirato, canali di comunicazione non convenzionali e token legittimi la rende una delle evoluzioni più pericolose del phishing moderno.

Come possiamo proteggere la nostra organizzazione?

Abbiamo visto che l’attacco Device Code Phishing è particolarmente insidioso e difficile da individuare. Come possiamo quindi proteggerci in modo efficace? Il sistema più semplice e sicuro, al momento, è quello di bloccare l’autenticazione Device Code Flow tramite una policy di Conditional Access.

Costruire una policy Conditional Access efficace

Per prima cosa, andiamo sul portale Entra Admin Center (https://entra.microsoft.com) e portiamoci nella sezione Conditional Access. Facciamo click su + Create new policy

Figura 2 Crea una nuova policy di Conditional Access

Poi, diamo un nome alla policy. Sfruttiamo una naming convention, cercando di rendere la policy parlante già a partire dal titolo.

Figura 3 Esempio nome conditional access policy

Assegniamo la policy ad All Users

N.B. potresti aver bisogno di escludere alcuni utenti da questa policy. Sono gli utenti di dispositivi senza un browser per effettuare il sign-in (es. Teams Room, dispositivi embedded, server senza interfaccia grafica…). In questo caso, prepara un gruppo e aggiungilo come oggetto in Exclude

Figura 4 Assegnazione policy a All Users

Come target, impostiamo All resources

Figura 5 Target policy verso tutte le app

Ora il passaggio più importante. Nelle condizioni, selezioniamo Authentication flows e, dopo aver acceso il setting, selezioniamo Device code flow

Figura 6 Selezione di Device code flow come authentication flow da gestire

In ultimo, avremo il Grant che sarà impostato su Block access

Figura 7 Impostazione di blocco come azione della policy

Dato che si tratta di una policy piuttosto restrittiva (BLOCK access…), il consiglio è quello di impostarla inizialmente in Report-only in modo da verificarne l’effettivo impatto in produzione.

N.B. ricordati di non escludere il tuo admin dalla policy come consigliato. Potresti rischiare di avere un utente privilegiato che rimane vulnerabile all’attacco…

Figura 8 Policy in Report-only senza esclusione dell’admin che la sta creando

Dopo un ragionevole periodo di test, sposta l’Enable policy su ON e monitorane regolarmente l’impatto.

Come funziona l’attacco in pratica?

Proviamo a simulare un accesso tramite Device Code con la policy Conditional Access non abilitata.

Per prima cosa, l’utente malevolo effettua una richiesta di autenticazione. Per questo esempio, usiamo Powershell e il modulo Graph per connetterci al tenant:

Figura 9 Richiesta di accesso tramite autenticazione device code flow

Poi, l’utente viene contattato e invitato ad accedere all’url indicata e ad inserire il codice fornito. Accedendo all’url l’utente vedrà comparire una finestra simile a questa (da notare l’invito a non inserire codici da fonti sconosciute)

Figura 10 Richiesta di codice per l’autenticazione

A questo punto, l’utente inserisce il codice richiesto e prosegue. Riceve una seconda richiesta di confermare quello che sta facendo (anche qui, nota i dettagli sulla richiesta in corso)

Figura 11 L’utente conferma di voler accedere

L’utente, inconsapevole, conferma di voler accedere. Dopo aver verificato la sua identità (tramite MFA o Hello for Business, se richiesto) visualizza la richiesta di accettazione dei permessi per l’app (nota l’ennesimo avviso a prestare attenzione)

Figura 12 richiesta permessi per l’app autenticata

L’utente fa click su Accept e conferma l’autenticazione. A questo punto, anche l’attaccante è autenticato e la sua sessione diventa attiva

Figura 13 Conferma di accesso eseguito

La sessione Powershell del nostro attaccante è autenticata!

Figura 14 Sessione Powershell Graph autenticata via device code flow

Con la Conditional Access Policy attiva, cosa cambia?

Con la nostra policy in ON, il flusso di autenticazione tramite device code non è consentito. Di conseguenza, il processo fallisce quando l’utente conferma di voler accedere. Rispetto al flusso visto in precedenza, il blocco del processo avviene subito dopo l’autenticazione (o conferma dell’identità). Invece di proseguire con la richiesta di accettazione dei permessi, l’utente riceve un messaggio simile a questo:

Figura 15 Autenticazione negata dalla conditional access policy

Se analizziamo gli errori mostrati all’utente, questi ci indicano che l’accesso non è possibile a causa di Conditional Access e/o metodo di autenticazione non corretto

Figura 16 Errore 53003: Bloccato da Conditional Access

Figura 17 AADSTS900561: Sign-in fallito per metodo non valido

Lato Entra ID, una verifica sui sign-in logs dell’utente bloccato, ci conferma immediatamente quello che è successo e che la nostra C.A.P. ha funzionato come previsto

Figura 18 Dettagli del sign-in bloccato

Figura 19 Conditional access applicata e risultato atteso: Failure

Per concludere

Come spesso accade, una soluzione pensata per un utilizzo legittimo viene sfruttata da attori malevoli come leva per compromettere identità e organizzazioni.

Bloccare il device code flow tramite Conditional Access non è quindi una misura “estrema”, è una piccola azione con un grande impatto. Coerente con il modo in cui oggi avvengono gli attacchi: silenziosi, legittimi all’apparenza, basati su token e fiducia.

Se l’identità è il nuovo perimetro, allora ogni flusso di autenticazione deve essere governato, non solo quelli più visibili. Ridurre la superficie di attacco non significa togliere funzionalità, significa decidere consapevolmente dove il rischio non è più accettabile e agire di conseguenza.

Se vuoi saperne di più, c’è un caso reale documentato:

Il Microsoft Threat Intelligence Center ha scoperto una campagna di phishing attiva dall’agosto 2024, condotta dal gruppo Storm-2372, ritenuto con buona probabilità allineato agli interessi russi. La tecnica utilizzata (il device code phishing, appunto) sfrutta il flusso di autenticazione tramite codice dispositivo per sottrarre i token di accesso delle vittime, prendendo così il controllo degli account senza bisogno delle credenziali. Gli attaccanti si fingono contatti affidabili su piattaforme come WhatsApp, Signal e Microsoft Teams, per poi inviare falsi inviti a riunioni che inducono le vittime a inserire un codice di autenticazione generato dagli stessi hacker. Nel mirino ci sono governi, ONG, aziende tech, difesa, telecomunicazioni, sanità ed energia in Europa, Nord America, Africa e Medio Oriente. Per i dettagli tecnici, gli indicatori di compromissione e le contromisure adottate, leggi l’analisi completa di Microsoft a questo indirizzo: Storm-2372 conducts device code phishing campaign | Microsoft Security Blog