Device Code Phishing: la minaccia che non ruba password, ma compromette gli account utente

“Device Code Phishing” è una tecnica di phishing che sfrutta il flusso di autenticazione tramite device code (codice dispositivo) per prendere controllo di un account senza mai chiedere né rubare la password dell’utente.​

Cos’è il Device Code Phishing

• Il device code è un meccanismo legittimo previsto da molti servizi (es. Microsoft 365, servizi cloud, app su smart TV o client CLI) che consente di collegare un nuovo dispositivo facendo login da un altro browser, inserendo un codice breve mostrato a schermo.​
• Gli attaccanti abusano di questo flusso inviando alla vittima un codice dispositivo e un link di verifica legittimo, inducendola a inserirlo e ad autorizzare in buona fede il “nuovo dispositivo”, che in realtà è il client controllato dall’attaccante.​

Perché non ruba la password ma compromette l’account

• Nel flusso device code la password è digitata solo nella sessione del browser che la vittima ritiene legittima; l’attaccante non vede la password ma riceve un token di accesso/OAuth già validato dal provider di identità.​
• Con questo token, il criminale ottiene accesso diretto all’account (email, OneDrive, Teams, applicazioni SaaS, ecc.), spesso con refresh token a lunga durata, aggirando anche controlli aggiuntivi basati su IP o device reputation.​

Vantaggi per l’attaccante

• Bypass MFA “classica”: se il device code flow è considerato trusted dal sistema o se l’utente esegue MFA sul proprio browser, l’attaccante riceve un token già “MFA satisfied” senza intercettare SMS/call/app di autenticazione.​
• Maggiore efficacia rispetto al phishing credenziali tradizionale perché la pagina di inserimento codice e il dominio sono realmente del provider (Microsoft, Google, ecc.), riducendo gli indicatori di falsificazione visibili all’utente.​

Impatti tipici dopo la compromissione

• Esfiltrazione massiva di mail, documenti, chat e contatti, con possibili movimenti laterali (es. uso dell’account compromesso per lanciare nuove campagne interne di phishing o BEC).​
• Impostazione di regole di inoltro email, creazione di app OAuth malevole, persistenza tramite sessioni e refresh token, ed eventuale abuso dell’account per truffe finanziarie o accesso a sistemi interni.​

Difese tecniche e di awareness

• Indurire le policy di accesso condizionale bloccando o limitando il flusso device code dove non strettamente necessario, monitorando in particolare grant OAuth e nuovi dispositivi/app registrati.​
• Formazione utenti mirata su questo scenario:
  • diffidare da codici dispositivo ricevuti via mail/IM/telefonata,
  • verificare sempre la richiesta con il reparto IT,
  • controllare attentamente a quale app e a quale tenant si sta concedendo l’accesso prima di confermare.

Tecnicamente il Device Code Phishing consiste nell’abusare del flusso OAuth “device code” (usato ad esempio da Microsoft per collegare nuovi dispositivi) in modo che sia la vittima, in modo legittimo, ad autenticare il client dell’attaccante sul proprio account.​

1. Il flusso OAuth con device code (legittimo)

• Il servizio (es. Microsoft 365) espone un endpoint “device authorization” a cui un client senza browser (smart TV, CLI, app embedded) chiede di iniziare il login; il server restituisce una coppia device_code e user_code più un URL di verifica (es. https://microsoft.com/devicelogin) e un tempo di scadenza.​
• L’utente, su un altro dispositivo dotato di browser, visita l’URL di verifica, inserisce lo user_code e fa login normalmente (password + eventuale MFA); se l’utente conferma, l’Authorization Server lega il device_code a quell’account e il client può scambiare il device_code con un access token e spesso un refresh token.​

2. Come l’attaccante entra nel flusso

• L’attaccante avvia lui stesso il flusso device code verso il provider (es. tramite script o tool “red team”), ottenendo device_code, user_code e URL di verifica per un’applicazione OAuth (a volte legittima, a volte registrata ad hoc).​
• Questi dati vengono confezionati in una campagna di ingegneria sociale: email/QR/IM che parlano di “verifica di sicurezza”, “ri-autorizzazione Teams/Office”, “OTP” ecc., con un pulsante o codice QR che porta alla pagina di destinazione dove compare il codice dispositivo e l’istruzione di inserirlo nel portale ufficiale di verifica.​

3. Interazione della vittima con il portale legittimo

• La vittima vede:
  • un URL autentico del provider (es. dominio Microsoft)
  • una pagina di inserimento user_code legittima
    e quindi tende a fidarsi perché non è una fake login page ma un vero flusso del vendor.​
• Dopo avere inserito il codice e fatto login (con tutte le sue credenziali e MFA normali), il server mostra una schermata di consenso che indica quale applicazione sta chiedendo l’accesso e a quali permessi (lettura mail, accesso file, offline_access, ecc.); se l’utente accetta, l’autorizzazione viene concessa al client controllato dall’attaccante.​

4. Scambio del device_code con token

• In parallelo, il client dell’attaccante effettua il polling all’endpoint token del provider, inviando il device_code a intervalli regolari finché l’utente non completa il login.​
• Non appena l’Authorization Server marca il device_code come “authorized”, la successiva richiesta dell’attaccante viene soddisfatta con:
  • un access token OAuth (per accedere alle API del provider a nome della vittima)
  • spesso un refresh token che permette di rigenerare nuovi access token senza ulteriori interventi dell’utente.​

5. Perché bypassa password e MFA “percepiti”

• Password e MFA avvengono nella sessione browser dell’utente, direttamente verso il provider, quindi non transitano mai su siti dell’attaccante né vengono intercettati in chiaro.​
• Dal punto di vista del sistema, l’utente ha appena autorizzato un’applicazione a nome suo: l’access token è pienamente valido e spesso già marcato come “MFA satisfied”, quindi l’attaccante può usare API Graph/Exchange/SharePoint ecc. come se fosse l’utente stesso, senza dover superare ulteriori prompt MFA.​

6. Fase di sfruttamento tecnica dell’account

• Con il token, l’attaccante automatizza chiamate API per:
  • leggere/inoltrare email
  • accedere a OneDrive/SharePoint
  • leggere chat Teams
  • creare regole di inbox e nuove app OAuth per persistenza.​
• Se dispone di refresh token, può mantenere l’accesso per giorni o settimane, anche dopo cambio password, finché non vengono revocati i grant OAuth o invalidati i token a livello di tenant.​

7. Elementi tecnici chiave per la difesa

• A livello di configurazione:
  • limitare o disabilitare il flusso device code dove non necessario
  • controllare i permessi concessi alle app OAuth e monitorare nuovi grant, soprattutto quelli con offline_access e accesso alle API di posta/file.​
• A livello di logging:
  • tracciare eventi di “device code flow”, nuovi consent, e accessi da applicazioni non comuni
  • correlare l’uso di token da IP/paesi/dispositivi differenti rispetto all’utente, per individuare abusi post-consenso.

Ci sono alcuni metodi pratici e abbastanza affidabili per distinguere, prima del click, un link legittimo da uno potenzialmente malevolo.​

Controlli immediati sull’URL

• Leggere bene il dominio: focalizzarsi sulla parte centrale (es. nome-sito.com), facendo attenzione a omografi e sostituzioni tipo paypa1.com al posto di paypal.com.​
• Verificare il TLD: piccoli cambi come .com → .co, .it → .info sono spesso usati per clonare siti noti con domini economici.​

Tecniche di “preview” senza clic

• Su desktop, passare il mouse sopra il link e guardare l’anteprima dell’URL (barra di stato del browser o tooltip) per controllare dove porta davvero, senza aprirlo.​
• Su mobile, tenere premuto sul link per vedere l’URL completo o la preview, annullando l’azione se l’indirizzo non è quello atteso.​

Indicatori contestuali (phishing/social engineering)

• Valutare il mittente e il contesto: se il link arriva da indirizzo/mail/social “strano”, sconosciuto o non coerente con il contenuto (es. banca da Gmail), va trattato come sospetto.​
• Attenzione a urgenza artificiale e toni allarmistici (“clicca subito”, “ultimo avviso”, “conto bloccato”) associati a richieste di login, pagamenti o inserimento dati sensibili.​

Link accorciati e reindirizzamenti

• Diffidare di URL accorciati (bit.ly, tinyurl, ecc.) in contesti non verificati; quando servono davvero, usare servizi che “espandono” l’URL per vedere la destinazione reale prima di aprirlo.​
• Se dopo il click compaiono reindirizzamenti multipli o domini che cambiano velocemente nella barra degli indirizzi, chiudere subito la pagina.​

Uso di strumenti di verifica

• Analizzare l’URL con servizi di controllo link (es. Google Safe Browsing, VirusTotal, o link-checker dei vendor di sicurezza) che confrontano il sito con blacklist e motori antiphishing.​
• Installare estensioni di browser che evidenziano domini pericolosi o aggiungono un pulsante “scansiona link”, utile soprattutto per utenti meno esperti.​

＼ Get the latest news ／