TLDR

  • Il device-code phishing usa un flusso OAuth legittimo nato per dispositivi senza tastiera.
  • La vittima vede una pagina vera del provider, inserisce un codice e autorizza una sessione che appartiene all'attaccante.
  • MFA e login legittimo non bastano se l'utente sta approvando il device sbagliato.
  • Log, conditional access, blocco dei client non necessari e formazione mirata sono le difese piu concrete.

Perche conta ora

Il phishing vecchio provava a farti entrare in una pagina falsa.

Il device-code phishing e piu perverso: ti porta su una pagina vera e ti fa fare la cosa sbagliata nel posto giusto.

Questo e il motivo per cui merita attenzione. L'utente vede il dominio corretto, il certificato e valido, la grafica e familiare, la MFA puo scattare davvero. Tutto sembra legittimo. Eppure la sessione che sta autorizzando non e la sua.

Il flusso device code nasce per casi sensati: TV, console, dispositivi senza tastiera comoda. Il dispositivo mostra un codice, l'utente lo inserisce da un browser su un altro device, il provider collega le due cose e completa l'autenticazione.

L'attaccante ribalta il modello: avvia lui il flusso, manda alla vittima il codice e aspetta che la vittima lo autorizzi.

Non ti ruba la password. Ti fa regalare una sessione.

Il falso e nel contesto

Questa e la parte che molti corsi anti-phishing spiegano male.

Non basta dire: "Controlla l'URL".

Nel device-code phishing l'URL puo essere corretto. La pagina puo essere autentica. Il problema e il perche sei li.

Se hai iniziato tu il login su una console o un'app che possiedi, il codice ha senso. Se un messaggio Slack, Teams, email, ticket, finto help desk o falso collega ti dice di inserire un codice per "verificare l'account", sei gia dentro la trappola.

Il browser non puo sapere se il codice ti appartiene. L'identity provider vede una procedura valida. La MFA vede una richiesta coerente. Ma il device che ricevera la sessione e quello dell'attaccante.

Perche piace agli attaccanti

Il device-code phishing e comodo per tre motivi.

Primo: abbassa il bisogno di pagine fake complesse. L'attaccante puo appoggiarsi al provider reale.

Secondo: puo aggirare una parte della diffidenza dell'utente, perche l'esperienza visiva sembra pulita.

Terzo: punta direttamente a token e sessioni, cioe alla parte che oggi conta davvero. In molti ambienti cloud, avere un token valido vale piu di conoscere la password.

Una volta dentro, l'attaccante puo cercare email, file condivisi, app OAuth autorizzate, dati di fatturazione, repository, chat interne e altri segnali utili per muoversi lateralmente o preparare una frode piu credibile.

Segnali nei log

Dal lato difensivo, questa roba va cercata nei log di autenticazione.

Indicatori utili:

  • login device-code da paesi o ASN insoliti;
  • completamento MFA seguito da sessione su client inatteso;
  • user agent o app client non coerente con l'utente;
  • refresh token creati fuori dagli orari normali;
  • accessi a mailbox o file subito dopo il login;
  • consenso ad app OAuth poco note;
  • piu utenti che autorizzano flussi simili dopo la stessa campagna.

Il punto non e trovare una stringa magica. E correlare contesto, device, IP, app e comportamento successivo.

Difese pratiche

Se in azienda non serve il device code flow, valuta di limitarlo. Non tutti i tenant possono spegnere tutto senza impatti, ma molte organizzazioni lo lasciano disponibile per inerzia.

Misure sensate:

  1. Conditional access per bloccare scenari ad alto rischio.
  2. Richiesta di device compliant o managed per app sensibili.
  3. Monitoraggio dei grant OAuth e delle app autorizzate.
  4. Alert su device-code login da location insolite.
  5. Revoca rapida di sessioni e refresh token dopo sospetto.
  6. Training specifico: non inserire codici non richiesti.
  7. Playbook help desk: nessun operatore deve chiedere codici device all'utente.

La formazione generica "non cliccare link strani" qui e troppo debole. Serve una frase piu chiara: se non hai iniziato tu il login su quel dispositivo, quel codice non e tuo.

La lezione

Il phishing moderno non prova sempre a sembrare falso.

A volte usa pezzi veri, flussi veri, domini veri e MFA vera. La truffa e nella regia.

Questa e la cosa da portarsi a casa: l'autenticazione non e solo crittografia e pagine di login. E anche intenzione. Chi ha iniziato il flusso? Quale device sta ricevendo la sessione? Perche proprio ora?

Se non rispondi a queste domande, rischi di proteggere benissimo la porta mentre qualcuno ti convince ad aprirla da dentro.

FAQ

Che cos'e il device-code phishing?

E un attacco che abusa del flusso OAuth device code. L'attaccante avvia una richiesta di login, manda alla vittima il codice e la convince a inserirlo su una pagina autentica del provider.

Perche e difficile da riconoscere?

Perche la pagina di login puo essere quella reale di Microsoft, Google o un altro identity provider. Il falso non e nella pagina, ma nel contesto che ha portato l'utente a inserire il codice.

La MFA protegge dal device-code phishing?

Aiuta, ma non sempre basta. Se la vittima completa la MFA per autorizzare il device dell'attaccante, la sessione puo comunque essere concessa.

Come posso difendermi in Microsoft 365?

Limita o disabilita il device code flow se non serve, monitora sign-in anomali, applica conditional access, richiedi device compliant e controlla refresh token e app consent.

Cosa deve imparare un utente?

Non inserire codici ricevuti via chat, email o ticket se non ha iniziato lui stesso il login sul dispositivo corretto.

Fonti