Phishing con codice dispositivo: approvare un accesso mai avviato
A febbraio 2025 il Microsoft Threat Intelligence Center ha documentato una campagna attiva dell'attore che segue come Storm-2372, che rubava sessioni di accesso a organizzazioni in Europa, Nord America, Africa e Medio Oriente. Ciò che colpisce della tecnica, il phishing con codice dispositivo, è ciò che evita: nessuna falsa pagina di accesso da riconoscere, nessuna password da rubare, nessun malware da individuare. La vittima non digita alcun segreto. Un codice fornito dall'attaccante viene inserito nella vera pagina di accesso di Microsoft, la vittima approva la richiesta dal proprio dispositivo e l'attaccante se ne va con una sessione funzionante.
Una funzione legittima, rovesciata contro l'utente
Il device code flow è una funzione reale di OAuth 2.0, non un falso. Esiste per l'hardware privo di tastiera o browser utilizzabili: stampanti, televisori, schermi di sale riunioni, decoder. Il dispositivo mostra un codice breve, l'utente apre il portale di accesso da un telefono o un laptop, inserisce il codice, accede e approva. Il dispositivo riceve i suoi token. Storm-2372 ha capovolto questa sequenza. Secondo Microsoft, il gruppo ha condotto la campagna da agosto 2024: apriva chat in Microsoft Teams fingendosi dirigenti o funzionari e poi, con il pretesto di condividere documenti, spostava la conversazione su Signal o WhatsApp. Gli inviti alle riunioni inviati via email portavano la stessa esca, travestita da normale traffico Teams. La copertura di BleepingComputer sulla stessa campagna descriveva vittime a cui si chiedeva di autenticare un dispositivo per ricevere un documento importante: seguivano un collegamento verso la vera pagina di accesso di Microsoft, inserivano il codice ricevuto e approvavano l'accesso, compreso il consueto passaggio di autenticazione multifattore. Gli obiettivi documentati da Microsoft includevano enti pubblici, fornitori di servizi IT, difesa, telecomunicazioni, sanità, istruzione superiore e aziende energetiche.Perché aggira completamente l'MFA
È l'ordine delle operazioni a far funzionare l'attacco. L'attaccante avvia prima una richiesta legittima di codice dispositivo e coinvolge la vittima solo dopo. Quando questa inserisce il codice e approva, ogni controllo della pagina passa onestamente: la pagina è reale, il codice è valido e la persona che interagisce completa un accesso autentico, autenticazione multifattore compresa. I token che Microsoft emette, compresi i refresh token di lunga durata, vanno a chi ha avviato la richiesta, cioè all'attaccante. Dal punto di vista della directory, un utente ha semplicemente eseguito l'accesso con successo. Non c'è nulla da segnalare per i filtri della posta o i proxy web, perché l'infrastruttura coinvolta è del tutto legittima. Il rapporto di Microsoft documenta cosa è successo dopo nei tenant compromessi: gli attaccanti cercavano nelle cassette postali con query Graph API termini come credenziali, password e admin, esfiltravano corrispondenza e usavano account interni fidati per inviare phishing ai colleghi, così che una sola approvazione potesse propagarsi a cascata nell'organizzazione. In un aggiornamento pubblicato un giorno dopo il post originale, Microsoft ha documentato anche uno spostamento verso richieste tramite il client Microsoft Authentication Broker, che permettevano di registrare dispositivi controllati dall'attaccante e richiedere primary refresh token. Proofpoint, che ha seguito la tecnica mentre si diffondeva tramite kit di phishing nel 2026, segnala un ulteriore affinamento: codici generati su richiesta nel momento in cui la vittima clicca su un collegamento, aggirando la scadenza di quindici minuti di un codice pregenerato.Il consiglio abituale, osservare da vicino la pagina di accesso prima di digitare qualsiasi cosa, qui non serve. Come nota l'analisi di Proofpoint su campagne successive, controllare l'URL non funziona perché il portale è genuinamente quello di Microsoft; ciò che viene abusato è l'approvazione della vittima, non la barra degli indirizzi.
Segnali d'allarme che vale la pena insegnare
I segnali sono coerenti da una campagna all'altra, e nessuno richiede competenze tecniche per essere notato.- un accesso che non hai avviato: un codice dispositivo esiste solo perché qualcuno lo ha richiesto
- urgenza e pressione ad agire prima che il codice scada o inizi una riunione
- un'email, una chat o un messaggio che chiede di approvare o autenticare qualcosa con un codice mai richiesto
- un contatto che cambia piattaforma, come una chat di Teams che si sposta su Signal o WhatsApp
- un documento o un invito a una riunione che si sblocca solo dopo aver verificato un codice