Il device code phishing funziona perché la vittima accede su una pagina Microsoft autentica: non c'è nessun login falso da riconoscere e nessun dominio simile da bloccare. La difesa pratica è disattivare il flusso per tutti coloro che non ne hanno bisogno. L'indicazione di Microsoft stessa è avvicinarsi il più possibile a un blocco unilaterale del device code flow, e una singola policy di Conditional Access è sufficiente.
A cosa serve il device code flow
Il flusso esiste per i dispositivi privi di browser o troppo scomodi per digitare. La RFC 8628 cita smart TV, console multimediali, cornici digitali e stampanti. Il dispositivo non mostra alcuna pagina di accesso. Invita l'utente a visitare un URL su un altro dispositivo, per esempio uno smartphone, e a inserire un codice breve.
Il client invia il proprio identificativo all'authorization server e riceve in risposta un device_code, uno user_code, un verification_uri e un valore expires_in. Mentre l'utente effettua l'accesso sul secondo dispositivo, il client interroga periodicamente (polling) il token endpoint con il device_code, finché non riceve un access token, un errore o l'istruzione di continuare ad attendere.
Nella Microsoft identity platform gli endpoint sono /devicecode e /token. La documentazione Microsoft concede all'utente 15 minuti per accedere per impostazione predefinita, e viene emesso un refresh token se lo scope richiesto includeva offline_access.
Perché funziona come phishing
Chi richiede il codice è il client. Chi effettua l'accesso è chiunque possieda il codice. Il protocollo non richiede che siano la stessa persona, e la RFC 8628 elenca il "Remote Phishing" tra le considerazioni di sicurezza (sezione 5.4).
Un attaccante può quindi comportarsi da dispositivo. Richiede un codice con un client_id (e uno scope, che l'endpoint di Microsoft richiede) e invia lo user_code al bersaglio accompagnandolo con un pretesto. Il bersaglio apre la vera pagina di verifica, effettua l'accesso e inserisce il codice. Il client dell'attaccante, che nel frattempo continua il polling, riceve i token.
La password non passa mai da una pagina controllata dall'attaccante. Per questo i controlli basati su domini e URL, come il nostro link checker, qui non hanno nulla da segnalare.
L'attaccante dipende comunque dalla vittima. Il bersaglio deve accedere e inserire il codice prima che scada expires_in (15 minuti per impostazione predefinita), altrimenti il polling fallisce con expired_token. Agli utenti con account personale viene inoltre chiesto di accedere di nuovo e di acconsentire ai permessi richiesti.
C'è un indizio utile per la formazione. Microsoft non supporta verification_uri_complete, il campo opzionale che porta il codice all'interno dell'URL. "Qualcuno mi ha mandato un codice da inserire su una pagina di accesso Microsoft" è lo schema da insegnare a riconoscere.
Rilevare gli accessi con device code
Microsoft raccomanda una policy che verifichi l'uso esistente del flusso, e la modalità report-only offre esattamente questo. Crei la policy descritta di seguito in Report-only e legga i risultati dell'impatto della policy per vedere chi e che cosa sarebbe stato bloccato.
Per un'attività di hunting continuativa, filtri i sign-in logs di Entra per gli accessi con device code e li raggruppi per utente e applicazione. Si tratta di un'indicazione di prassi professionale: le pagine Microsoft citate qui non la documentano. Un accesso da parte di un utente che non possiede alcun dispositivo o strumento che usi il flusso, oppure da un'applicazione che nessuno sa nominare, merita una conversazione. Chieda all'utente quale messaggio ha ricevuto.
Bloccare il flusso con Conditional Access
Il percorso passo per passo è nella guida Microsoft a Conditional Access. Acceda almeno come Conditional Access Administrator, vada in Entra ID > Conditional Access > Policies e crei una nuova policy. Includa tutti gli utenti e All resources. In Conditions > Authentication Flows imposti Configure su Yes e selezioni Device code flow. In Grant selezioni Block access e imposti Enable policy su Report-only. La porti su On dopo aver esaminato i risultati.
La stessa pagina tratta anche il blocco dell'authentication transfer, che permette agli utenti di trasferire un accesso da un PC a un dispositivo mobile. Usa la stessa condizione Authentication Flows, quindi conviene decidere anche su questo nella stessa sessione.
L'indicazione di Microsoft è consentire il flusso solo in casi d'uso ben documentati e protetti, come strumenti legacy che non possono essere aggiornati.
Per ciò che deve restare, costruisca un gruppo di esclusione dedicato con un nome che ne dichiari lo scopo. Registri un responsabile e una motivazione per ogni membro e verifichi l'elenco con regolarità, come consiglia Microsoft. Mantenga escluse anche le utenze di emergenza (break-glass), per evitare un lockout in caso di policy configurata in modo errato.
A parte, Microsoft segnala che le chiamate effettuate da service principal non sono bloccate dalle policy rivolte agli utenti, e suggerisce di sostituire gli account di servizio usati in script o codice con managed identity.
Se un code phishing è già andato a buon fine
Parta dal presupposto che l'attaccante possieda dei token, non soltanto una password. Un refresh token può essere usato per ottenere nuovi access token, quindi revochi prima le sessioni dell'utente e poi reimposti la password. Si tratta di un'indicazione di prassi professionale, non tratta dalle fonti sopra citate.
Successivamente esamini le enterprise application e i consent grant collegati all'account e rimuova quelli che non riconosce. Controlli la casella di posta per cercare regole che non ha creato, in particolare regole di inoltro o di cancellazione.
Estenda la ricerca oltre il singolo utente eseguendo il filtro per device code descritto sopra su altri account e cercando la stessa applicazione. Se più di un account potrebbe essere coinvolto, segua un processo di risposta strutturato: il nostro team di incident response può condurlo insieme a Lei, e il nostro blog offre contenuti su incident response e phishing per la parte di formazione.
Da dove iniziare
- Elenchi ogni dispositivo, script e strumento che potrebbe accedere con un codice: stampanti, TV, dispositivi IoT, strumenti da riga di comando. Chieda a ciascun responsabile se lo fa.
- Crei la policy di Conditional Access con Device code flow selezionato, tutti gli utenti nell'ambito e le utenze break-glass escluse, in modalità Report-only. Decida nello stesso momento sulla condizione di authentication transfer.
- Legga i risultati del report-only e gli accessi con device code nei log. Corregga o dismetta ogni uso legittimo e inserisca ciò che resta in un gruppo di esclusione con nome e responsabile.
- Porti la policy su On e metta in calendario l'audit del gruppo di esclusione.
- Metta per iscritto i passi di risposta (revocare le sessioni, esaminare enterprise application e consent grant, controllare le regole della casella di posta). Comunichi al personale che un codice non richiesto da loro stessi, relativo a un dispositivo che non hanno in mano, è un tentativo di phishing.
