Il device code phishing abusa di un OAuth Device Authorization Flow legittimo per indurre una vittima ad autorizzare una sessione controllata dall’attaccante. In ambienti Microsoft Entra ID, l’utente può inserire un codice breve nella vera pagina Microsoft di accesso per dispositivi, completare l’autenticazione normale, soddisfare l’MFA e comunque consentire al client controllato dall’attaccante di ricevere token.
Questa distinzione è centrale. Il device code phishing non è password spraying, non è OAuth consent phishing, non è MFA fatigue e non è una normale pagina di raccolta credenziali. È un percorso di attacco centrato sui token contro un flusso di autenticazione valido, progettato per dispositivi con input limitato. I defender devono quindi valutarlo con Conditional Access, log di sign-in, investigazione dei token e attività post-autenticazione.
I team che già analizzano MFA fatigue, password spraying, i limiti di MFA da solo o un audit di sicurezza Microsoft Entra ID dovrebbero trattare il device code phishing separatamente. L’interazione iniziale dell’utente e la sessione ottenuta non assomigliano a una classica falsa pagina di login.
Che cos’è il Device Code Phishing?
Il device code phishing è una tecnica di social engineering che abusa dell’OAuth 2.0 Device Authorization Grant. L’attaccante avvia un device code flow da un client che controlla, riceve uno user code e una verification URI, e convince l’utente target a inserire quel codice in un browser. Se l’utente completa l’autenticazione, il client dell’attaccante può ricevere token per la risorsa e gli scope richiesti.
Il flusso legittimo esiste per dispositivi che non possono mostrare facilmente un browser completo o accettare input complesso. Microsoft documenta scenari come smart TV, dispositivi IoT o stampanti. Il dispositivo mostra un codice, l’utente accede da un altro dispositivo e il client con input limitato interroga il token endpoint finché l’autorizzazione riesce o scade.
Il device code phishing capovolge questo modello. Il dispositivo che chiede autorizzazione non è una TV aziendale o una stampante davanti all’utente. È una sessione client controllata dall’attaccante. La vittima inserisce il codice in una pagina Microsoft legittima, rendendo l’esperienza più difficile da distinguere da un accesso normale.
Per questo bisogna usare con cautela il termine MFA bypass. In molti casi, l’MFA non viene rotta crittograficamente. L’utente può completare davvero l’MFA durante il login Microsoft. Il problema è che sta autorizzando la sessione device-code dell’attaccante. Il successo dell’MFA non prova che la sessione appartenga a un dispositivo, posizione o workflow fidato.
Come funziona OAuth Device Code Flow
L’OAuth Device Authorization Grant è definito in RFC 8628. Il client richiede un’autorizzazione dispositivo all’authorization server e riceve valori come device_code, user_code, verification_uri, durata di scadenza e intervallo di polling. L’utente visita la verification URI e inserisce lo user code. Nel frattempo, il client interroga il token endpoint con il device_code.
La Microsoft identity platform implementa questo modello tramite device code flow. Una risposta token riuscita può includere un access token, un ID token se è richiesto openid, e un refresh token quando lo scope originale include offline_access. In uno scenario phishing, questo materiale token è l’obiettivo. L’attaccante non ha bisogno di conoscere la password se la vittima completa il flusso di autorizzazione.
| Proprietà | Significato difensivo |
|---|---|
| L’autenticazione utente avviene in un browser separato | Il browser che approva non è necessariamente lo stesso dispositivo o client che riceverà i token. |
| Il client richiedente esegue polling del token endpoint | Il client dell’attaccante può aspettare che l’utente completi l’autenticazione. |
| I token sono materiale bearer se non vincolati o limitati | La detection deve includere uso dei token e attività workload, non solo il sign-in iniziale. |
RFC 8628 discute esplicitamente il remote phishing. Il flusso può essere avviato su un dispositivo posseduto dall’attaccante e l’attaccante può inviare un messaggio che chiede alla vittima di visitare la verification URL e inserire lo user code. L’RFC raccomanda che l’authorization server informi l’utente che sta autorizzando un dispositivo e confermi che il dispositivo sia in suo possesso.
Differenze rispetto ad attacchi simili
Device code phishing è vicino ad altri attacchi di identità, ma il meccanismo è diverso.
| Attacco | Cosa viene abusato | Differenza |
|---|---|---|
| Password spraying | Password deboli o riutilizzate su molti account | L’attaccante prova password direttamente, spesso a basso volume per account. |
| MFA fatigue | Prompt MFA ripetuti o pressione sociale | L’attaccante spesso ha già credenziali e spinge l’utente ad approvare. |
| OAuth consent phishing | Consenso utente o admin a un’app malevola | Il problema centrale è il consenso e i permessi dell’app. |
| AiTM phishing | Reverse proxy cattura credenziali, cookie o token | L’attaccante proxifica il login; device code phishing può usare la pagina Microsoft reale. |
| Device code phishing | OAuth Device Authorization Grant | La vittima autorizza una sessione dell’attaccante inserendo uno user code. |
Queste differenze cambiano la remediation. Un tenant può avere buoni controlli password e restare esposto se il device code flow è ampiamente consentito. Un tenant può imporre MFA e comunque subire compromissione se gli utenti autorizzano sessioni che non controllano. Bloccare il device code flow non sostituisce la correzione delle lacune di Conditional Access o delle policy di Identity Protection.
Perché funziona contro Entra ID
L’attacco funziona perché la vittima non invia la password a un dominio palesemente malevolo. Può essere inviata a una pagina di verifica ospitata da Microsoft e vedere prompt di autenticazione familiari. La formazione che si concentra solo su domini falsi o pagine password sospette non copre bene questo pattern.
Le ricerche Microsoft del 2025 e 2026 su campagne di device code phishing descrivono lo stesso comportamento centrale: attori di minaccia abusano di un flusso di autenticazione device code legittimo, inducono la vittima ad autenticare la sessione dell’attaccante e ricevono token validi senza rubare direttamente la password. Microsoft ha inoltre osservato nel 2026 automazione e generazione dinamica dei codici per mantenere valido il codice breve quando l’utente interagisce con il lure.
La tecnica è rilevante per Entra ID e Microsoft 365 perché i token ottenuti possono essere usati contro risorse cloud come Exchange Online, Microsoft Graph, SharePoint Online o Teams, in base ad app, risorsa e scope. Questo non significa che ogni sign-in device code sia malevolo. Significa che i defender devono sapere se il flusso è usato legittimamente nel tenant, da quali app, da quali posizioni e sotto quali decisioni di Conditional Access.
Un errore comune è trattare un MFA riuscito come prova finale di legittimità. Nel device code phishing, l’evento MFA può essere reale. La domanda è se l’utente intendeva autorizzare il client che ha ricevuto il token. La revisione del sign-in deve includere protocollo di autenticazione, app, risorsa, IP, dettagli dispositivo, stato Conditional Access, rischi, identificatori di sessione e attività workload successiva.
Catena di attacco
Una catena tipica:
- L’attaccante avvia una richiesta di device authorization da infrastruttura o tooling controllato.
- La piattaforma identità restituisce user code, verification URI, scadenza e intervallo di polling.
- L’attaccante consegna il codice via email, chat, invito collaborativo, documento lure o altro canale sociale.
- La vittima visita la pagina di verifica, inserisce il codice, accede e completa i passaggi di autenticazione.
- Il client dell’attaccante interroga il token endpoint e riceve i token dopo l’autorizzazione.
- L’attaccante usa l’accesso per leggere email, interrogare Microsoft Graph, enumerare dati tenant, creare regole mailbox, accedere a file o tentare azioni consentite da token e privilegi account.
- Il defender può vedere un sign-in device code riuscito, seguito da uso non interattivo dei token e attività workload.
La catena non va ridotta a un indicatore unico. deviceCode nel protocollo di autenticazione è importante, ma indica solo il flusso usato. Non prova da solo l’intento malevolo. L’indagine è più forte quando l’evento è correlato a posizione insolita, app inattesa, dettagli di rischio, accesso anomalo a risorse, creazione di regole email, attività Graph o un utente che normalmente non usa device code flow.
Detection
Baselining dell’uso legittimo
La detection inizia con una baseline di ciò che è legittimo. Molte organizzazioni hanno poco o nessun bisogno reale di device code flow. Altre lo usano per tool legacy, dispositivi di sala, workflow developer o scenari di registrazione dispositivi. La prima domanda è se il flusso fosse atteso.
Nei sign-in logs Microsoft Entra esportati in Log Analytics, la tabella SigninLogs include AuthenticationProtocol. Microsoft documenta deviceCode come possibile valore. Altri campi utili includono OriginalTransferMethod, AppDisplayName, ResourceDisplayName, IPAddress, DeviceDetail, UserAgent, ConditionalAccessStatus, RiskLevelDuringSignIn, RiskEventTypes_V2, SessionId e UniqueTokenIdentifier.
Cercare autenticazione deviceCode
Una query base inventaria usi riusciti e falliti:
SigninLogs
| where TimeGenerated > ago(30d)
| where AuthenticationProtocol == "deviceCode" or OriginalTransferMethod == "deviceCodeFlow"
| project TimeGenerated, UserPrincipalName, AppDisplayName, ResourceDisplayName,
IPAddress, Location, DeviceDetail, UserAgent, ConditionalAccessStatus,
RiskLevelDuringSignIn, RiskEventTypes_V2, ResultType, ResultDescription,
SessionId, UniqueTokenIdentifier
| order by TimeGenerated desc
Usala come punto di partenza, non come detection completa. Verifica se app e risorsa hanno senso per il ruolo dell’utente. Uno sviluppatore che autentica una CLI nota da una rete nota è diverso da un utente finance che autorizza improvvisamente device code flow da un nuovo paese e genera attività Graph o Exchange.
Per una detection più forte, confronta uso recente e storico:
let lookback = 30d;
let recent = 1d;
let knownUsers = SigninLogs
| where TimeGenerated between (ago(lookback) .. ago(recent))
| where AuthenticationProtocol == "deviceCode" or OriginalTransferMethod == "deviceCodeFlow"
| where ResultType == 0
| distinct UserPrincipalName;
SigninLogs
| where TimeGenerated > ago(recent)
| where AuthenticationProtocol == "deviceCode" or OriginalTransferMethod == "deviceCodeFlow"
| where ResultType == 0
| where UserPrincipalName !in (knownUsers)
| project TimeGenerated, UserPrincipalName, AppDisplayName, ResourceDisplayName,
IPAddress, Location, DeviceDetail, UserAgent, ConditionalAccessStatus,
RiskLevelDuringSignIn, RiskEventTypes_V2, SessionId, UniqueTokenIdentifier
Priorità basata sul contesto
Dai priorità a eventi con queste caratteristiche:
- primo device code flow osservato per utente o dipartimento
- app o risorsa insolita per il ruolo
- sign-in da IP, ASN, paese o rete non associati all’utente
RiskEventTypes_V2collegati a IP anonimo o threat intelligence- device code flow riuscito seguito da uso non interattivo di token da infrastruttura inattesa
- nuove regole mailbox, accesso mail sospetto, attività Graph, SharePoint o Teams anomala
- registrazione o join dispositivo vicino nel tempo e non legato a onboarding normale
Gli identificatori correlabili Microsoft Entra rendono più utile la fase post-authentication. Parti da SessionId o UniqueTokenIdentifier e correlali con log Exchange Online, Microsoft Graph, SharePoint Online o Teams. Microsoft documenta questo modello per tracciare attività svolte da una sessione o token specifico.
Microsoft Defender ed Entra ID Protection possono aggiungere segnali di maggiore confidenza, come IP anonimo, Microsoft Entra threat intelligence, anomalous token e suspicious API traffic. Usali per arricchire e priorizzare, non per sostituire la verifica se device code flow dovesse accadere.
Remediation e hardening
Bloccare o limitare device code flow
Il controllo più diretto è limitare o bloccare device code flow con Conditional Access. Microsoft raccomanda di avvicinarsi il più possibile a un blocco unilaterale, auditare prima l’uso esistente e consentire il flusso solo per use case documentati e protetti. Per organizzazioni che non lo usano, Microsoft fornisce un pattern Conditional Access che usa la condizione authentication flows, seleziona device code flow e blocca l’accesso.
Percorso pratico:
- Inventariare l’uso attuale di device code flow nei sign-in logs Entra.
- Identificare utenti, app, risorse, posizioni e dipendenze legittime.
- Creare una policy Conditional Access in report-only per device code flow.
- Escludere account emergency access e use case documentati.
- Rivedere impatto e log.
- Passare la policy a enabled quando l’impatto è chiaro.
- Monitorare tentativi bloccati ed esclusioni inattese.
Verificare compatibilità prima dell’enforcement
Esiste una caveat importante. Microsoft indica che se l’organizzazione usa device code flow verso Device Registration Service e una policy authentication flows punta a tutte le risorse, può essere necessario escludere Device Registration Service. Microsoft documenta il client ID e come filtrare i sign-in logs per risorsa e flow. Non bloccare tutte le risorse senza verificare dipendenze di registrazione dispositivo.
Anche i grant controls Conditional Access richiedono precisione. Microsoft documenta che quando si usa il device-code OAuth flow, i grant controls che richiedono stato dispositivo gestito non sono supportati nello stesso modo, perché il dispositivo che autentica non può fornire il proprio stato al dispositivo che fornisce il codice. Un modello basato solo su compliant device o hybrid-joined device può quindi non comportarsi come previsto. Usa la condizione authentication flows per controllare il flow.
Ridurre il blast radius
Controlli complementari:
- richiedere autenticazione phishing-resistant per ruoli privilegiati dove supportata, senza assumere che blocchi ogni scenario device-code
- usare Conditional Access basato sul rischio e Identity Protection per sfidare o bloccare sessioni rischiose
- ridurre esposizione privilegiata e ruoli permanenti, come nelle review di accesso privilegiato Azure
- rivedere app consent e permessi per ridurre l’impatto dell’abuso di token
- monitorare Exchange, Graph, SharePoint e Teams dopo sign-in sospetti
- usare Safe Links, anti-phishing e workflow di reporting utente per ridurre delivery e tempi di triage
- valutare token protection dove client, piattaforma e workload sono supportati
Risposta a incidente
Preservare prove di sign-in e workload
Quando sospetti device code phishing, la risposta deve concentrarsi su contenimento token e scope workload, non solo reset password.
Acquisisci utente, app, risorsa, IP, posizione, AuthenticationProtocol, OriginalTransferMethod, risultato Conditional Access, dettagli rischio, SessionId e UniqueTokenIdentifier. Conserva il messaggio phishing originale con header e URL, ma non basarti solo sulla reputazione URL: la vittima potrebbe aver usato una pagina Microsoft legittima.
Revocare sessioni
Revoca le sessioni attive. Microsoft Graph revokeSignInSessions invalida refresh token emessi alle applicazioni per un utente e cookie di sessione browser resettando il timestamp di validità sessione. Microsoft segnala possibili ritardi di alcuni minuti e il fatto che utenti esterni accedono tramite home tenant. Se l’identità compromessa è guest, rivedi anche il rischio degli account guest Azure.
Resetta le credenziali solo se l’indagine lo supporta. Device code phishing può compromettere token senza rubare direttamente la password. Reset può servire in caso di credential theft, regole mailbox, modifica metodi MFA, registrazione dispositivo sospetta o altri percorsi. Il punto chiave: password reset non basta se refresh token e sessioni attive restano validi.
Delimitare attività successiva
Usa identificatori correlabili per tracciare Exchange Online, Microsoft Graph, SharePoint Online e Teams associati a sessione o token. Cerca regole mailbox, lettura/esportazione messaggi, download file, modifiche OAuth app, gruppi, metodi di autenticazione, registrazioni dispositivo e azioni amministrative.
Chiudi poi il gap di controllo. Se device code flow non era necessario, bloccalo. Se era necessario per un workflow ristretto, limitalo a utenti, app, posizioni e risorse documentati. Crea alert per uso fuori dal pattern approvato.
Validazione dopo hardening
Validare prevenzione
Conferma che la policy Conditional Access per authentication flows sia abilitata e applichi a utenti e risorse previsti. Testa con un account non privilegiato in un percorso controllato. Un device code flow bloccato deve comparire nei sign-in logs con la decisione Conditional Access. Gli account break-glass restano esclusi, ma la lista va rivista regolarmente.
Per compatibilità, verifica registrazione dispositivi e tool legacy legittimi. Se Device Registration Service usa device code flow, valida l’esclusione documentata e conferma che solo la risorsa prevista è esclusa. Evita eccezioni ampie che ricreano l’esposizione.
Validare monitoring e response
Per detection, conferma che i sign-in device code siano visibili nel portale Entra e in Log Analytics. Verifica che AuthenticationProtocol, OriginalTransferMethod, app, risorsa, IP, dettagli dispositivo, rischio, SessionId e UniqueTokenIdentifier siano disponibili agli analisti. Conferma i pivot verso Exchange, Graph, SharePoint e Teams dove licenza e logging lo consentono.
Per response, esegui un tabletop. Parti da un sign-in deviceCode sospetto e richiedi che l’analista identifichi utente, app, risorsa, session ID, token identifier, attività workload successiva, percorso di revoca sessione e prova finale di containment. Questa è la differenza tra avere un controllo e saperlo usare in un incidente.
Come EtcSec rileva esposizione correlata
EtcSec deve trattare device code phishing come percorso di attacco identity e problema di postura, non solo come problema email. I finding utili sono le condizioni che trasformano un evento di social engineering basato su token in compromissione tenant.
Le esposizioni rilevanti includono policy Conditional Access che non restringono device code flow, policy di rischio assenti o deboli, utenti privilegiati senza isolamento amministrativo forte, ruoli admin permanenti eccessivi, account guest senza controlli forti e app registrations troppo permissive. Per team tecnici, l’output utile è concreto: chi può usare device code flow, quali utenti sono esenti, se i sign-in rischiosi sono bloccati o solo loggati, quali account privilegiati potrebbero autorizzare sessioni cloud da contesti meno fidati, e quali app o delegated permissions renderebbero più dannosa una sessione rubata.
Controlli correlati
| Controllo | Riduce | Evidenza di validazione |
|---|---|---|
| Policy Conditional Access authentication flows | Uso ampio di device code flow | Review report-only, poi deviceCode bloccati fuori dallo scope approvato. |
| Conditional Access basato sul rischio | Abuso token da posizioni o segnali rischiosi | Policy user risk/sign-in risk e review delle detection. |
| Isolamento accesso privilegiato | Blast radius se un utente privilegiato viene phishato | Account privilegiati separati da account quotidiani e con controlli più forti. |
| Governance app consent e permessi | Impatto di abuso OAuth o token | App registrations, delegated permissions e admin consent rivisti. |
| Correlazione audit cross-workload | Tempo per delimitare abuso token | Pivot SessionId e UniqueTokenIdentifier verso Exchange, Graph, SharePoint e Teams. |
| Reporting utente e protezione email | Delivery dei lure e ritardo di triage | Workflow di reporting, Safe Links e prove di message investigation. |
Device code phishing è efficace perché vive nello spazio tra design di autenticazione legittimo e intenzione dell’utente. La correzione duratura non è uno slogan sull’MFA. È una postura tenant in cui i flow rischiosi sono limitati, i sign-in device-code sospetti sono visibili, l’attività token è tracciabile e l’accesso privilegiato non dipende da utenti perfetti sotto pressione sociale.
Riferimenti principali
- RFC 8628: OAuth 2.0 Device Authorization Grant
- Microsoft identity platform and OAuth 2.0 device authorization grant flow
- Authentication flows as a condition in Conditional Access
- Block authentication flows with Conditional Access policy
- How to configure grant controls in Microsoft Entra
- Protecting tokens in Microsoft Entra ID
- Azure Monitor Logs reference: SigninLogs
- Track and investigate identity activities with linkable identifiers
- Microsoft Graph: revokeSignInSessions
- Microsoft Security Blog: Storm-2372 conducts device code phishing campaign
- Microsoft Security Blog: Inside an AI-enabled device code phishing campaign
- MITRE ATT&CK T1566.002 Spearphishing Link
- MITRE ATT&CK T1550.001 Application Access Token
