Furto di token Microsoft 365: perché l'MFA da sola non basta contro il token spraying

Un esperimento dimostra che l'MFA non impedisce il furto delle sessioni: oltre 200.000 tentativi di accesso falliti, 497 accessi riusciti e e-mail su stipendi e bonus che spariscono in regole nascoste. Al centro c'è il modo di riconoscere questo tipo di furto di token in Microsoft 365, il motivo per cui la grande diffusione della piattaforma rende l'attacco redditizio e che cosa fare per prima cosa in caso di emergenza.

Che cos'è il token spraying

Token spraying in Microsoft 365 è il nome di una tecnica che il fornitore di sicurezza Huntress ha osservato in una campagna. Gli aggressori non indovinano le password. Rubano i token di sessione dopo che un dipendente ha effettuato correttamente l'accesso con password e autenticazione a più fattori (MFA) e, poco dopo, riutilizzano questi token dalla propria infrastruttura. Il nome richiama il password spraying, in cui una password viene provata su molti account. Qui, invece, le credenziali rubate vengono diffuse ampiamente e riutilizzate.

Le informazioni sulla campagna provengono da Huntress e da un resoconto di The Hacker News. Si basano su osservazioni presso i clienti di un fornitore di sicurezza e non dicono nulla su tutti i tenant.

Furto di token in Microsoft 365: che cosa ha osservato Huntress

Huntress descrive la campagna nel rapporto Token Replay and Spray. La data esatta di pubblicazione del rapporto non è certa; è documentato il periodo di osservazione dal 14 luglio 2026 al 22 settembre 2026. In questo arco di tempo Huntress ha rilevato attacchi a 79 organizzazioni, oltre 200.000 tentativi di accesso falliti e 497 accessi riusciti. Nelle directory Entra sono stati creati almeno 48 dispositivi falsi. In 19 organizzazioni i metodi MFA esistenti sono stati rimossi e sostituiti con uno nuovo.

Per quanto risulta, la cifra di 97 account compromessi è riportata solo da The Hacker News. Non è stato possibile confermarla nel rapporto di Huntress e viene quindi indicata qui come dato di quel resoconto. Inoltre, i numeri delle singole ondate di attacco differiscono leggermente nell'esposizione di Huntress. Per un inquadramento basta l'ordine di grandezza: con 79 organizzazioni colpite, 497 accessi riusciti e diverse ondate di attacco nell'arco di circa dieci settimane non si trattava di un caso isolato, ma di una serie.

Come il token spraying si distingue dal password spraying

Il password spraying produce molti tentativi falliti, perché la maggior parte delle password è sbagliata. Nel token spraying le credenziali sono valide. Secondo Huntress, i tentativi falliti della campagna provenivano da reti degli aggressori, in gran parte da un hosting provider in Germania. Questo non dice nulla sugli altri clienti di quel fornitore. Bloccare singoli indirizzi serve inoltre a poco, perché gli aggressori cambiavano indirizzo a ondate, con una o due settimane di quiete tra un'ondata e l'altra.

Come il token replay aggira l'MFA

La tecnica è chiamata anche token replay, cioè la riproduzione di un token rubato. Il processo si può descrivere in quattro passaggi.

1. Esca: un dipendente riceve un'e-mail di phishing o viene indirizzato a un sito esterno tramite social engineering. Come queste e-mail si guadagnano la fiducia è descritto nell'articolo sull'autenticità dei messaggi elettronici.
2. Intercettazione: un relay adversary-in-the-middle (AiTM) si interpone tra il dipendente e la vera pagina di accesso di Microsoft. Password e richiesta MFA passano attraverso il relay, che poi memorizza il token. Nel device code phishing, invece, la vittima viene indotta a inserire un codice sulla vera pagina Microsoft, con il quale l'aggressore ottiene un token.
3. Replay: da pochi minuti a circa un'ora dopo, l'aggressore usa il token dai propri server. Non servono né la password né una seconda richiesta MFA.
4. Persistenza: l'aggressore registra una propria app di autenticazione, rimuove i metodi MFA esistenti o crea un dispositivo falso. Entrambi sopravvivono a un cambio di password.

Il punto chiave è questo: l'MFA non è stata violata. Il dipendente l'ha completata correttamente. Ciò che viene rubato è il risultato, il token. L'MFA può quindi essere aggirata solo se il token funziona anche al di fuori del dispositivo del dipendente. Codici, SMS e approvazioni push aiutano contro l'indovinare le password, ma non contro questo tipo di furto.

Huntress ha trovato due famiglie di strumenti. Una è uno script che si presenta con lo user agent «node» e richiede token tramite le applicazioni Office e Authentication Broker. L'altra riproduce sessioni del browser. Gli accessi del secondo tipo sembrano normali accessi da browser e sono di conseguenza meno appariscenti.

Monocultura Microsoft: perché Microsoft 365 è il bersaglio più redditizio

Microsoft 365 è usato in un numero incalcolabile di aziende, in Germania e nel mondo. Dal punto di vista degli aggressori è un argomento economico: un attacco costruito una volta può essere ripetuto contro moltissimi tenant. Le pagine di accesso sono uguali ovunque, gli ID delle applicazioni sono gli stessi, così come i codici di errore. Ciò che funziona in un'azienda funziona, con piccoli adattamenti, in molte altre.

La campagna mostra questa scalabilità. I token rubati sono stati usati in modo automatico e nel giro di pochi minuti, distribuiti su 79 organizzazioni. Secondo Huntress, gli aggressori non davano priorità in base al numero di tentativi falliti, ma a dove esistevano credenziali valide. È il modo di lavorare di un'attività di massa, non di un'operazione mirata contro una singola azienda.

La diffusione è l'amplificatore, non l'unica causa

Non si tratta di una condanna generalizzata. Microsoft fornisce da sé le contromisure: Conditional Access, Security Defaults e Token Protection. Il rischio nasce quando questi strumenti non vengono usati, o solo in parte. Gli aggressori adattano la loro automazione alle impostazioni predefinite, perché valgono per la maggior parte dei tenant. Ogni deviazione, come un accesso legato al dispositivo o un device code flow bloccato, costa fatica agli aggressori e toglie la base allo sfruttamento di massa.

Anche la diffusione di Copilot e di altri servizi dietro gli stessi account aumenta la leva di un account compromesso. Una valutazione critica è fornita dall'articolo Copilot sotto la lente. In Microsoft 365 un singolo account apre contemporaneamente posta, file, calendario e chat.

Frode sugli stipendi come obiettivo: che cosa succede dopo la compromissione

Dopo la compromissione, gli aggressori della campagna hanno creato regole nascoste nella posta in arrivo. Queste spostavano o eliminavano e-mail con termini legati ai pagamenti, come stipendio, accrediti o bonus. Le cartelle di destinazione avevano nomi poco appariscenti come «RSS Feeds» o «Conversation History». In un caso un'e-mail sullo stipendio è stata inviata a un commercialista esterno. Le risposte venivano contrassegnate come lette e spostate, affinché la vittima non le notasse.

Dietro c'è la business email compromise (BEC): l'obiettivo è deviare bonifici o far modificare i conti per gli stipendi. In un altro caso una casella è stata usata in modo abusivo per inviare spam a centinaia di destinatari esterni, finché Entra ID Protection non ha classificato l'account come ad alto rischio.

Per le piccole imprese questo è particolarmente delicato. In contabilità e nell'ufficio del personale lavorano spesso poche persone. Un account modificato viene notato tardi e l'elaborazione delle buste paga è spesso affidata a terzi. La direzione decide quindi sul richiamo dei pagamenti e sull'informazione di banca, commercialista e consulente del lavoro. Questo rientra nel piano di emergenza, non solo nella crisi.

Tracce tipiche: nuova app di autenticazione, dispositivi Entra sconosciuti, regole della posta in arrivo

La campagna lascia tracce in Microsoft Entra ID, la gestione utenti dietro Microsoft 365, che si possono verificare senza strumenti specialistici. La tabella seguente riassume le più importanti. I modelli di denominazione provengono dal rapporto di Huntress e possono cambiare.

Il codice di errore 53003 merita attenzione. Un blocco da parte di Conditional Access viene di solito considerato un successo della policy. Ma indica anche che qualcuno all'esterno dell'azienda possiede credenziali valide o un token valido. Una voce di questo tipo è un motivo per controllare l'account. Le regole della posta in arrivo create tramite un'API non compaiono sempre nell'interfaccia. Diventano visibili tramite l'Exchange admin center o PowerShell.

Le piccole imprese senza monitoraggio dei log spesso se ne accorgono solo a posteriori. Per quanto tempo i log di accesso vengono conservati dipende dalla licenza e va chiarito in anticipo, perché senza log la portata di un incidente resta sconosciuta.

Conditional Access: bloccare il device code flow e richiedere l'MFA per tutti i tipi di client

Il device code flow è un metodo di accesso per dispositivi senza tastiera o browser. Gli aggressori ne abusano nel device code phishing, inducendo gli utenti a inserire un codice su un altro dispositivo. Nella sua documentazione sul blocco dei flussi di autenticazione, Microsoft raccomanda di avvicinarsi il più possibile a un blocco completo e di consentire il flusso solo in eccezioni ben documentate, come strumenti legacy che non possono essere aggiornati.

La policy viene creata nell'Entra admin center sotto Entra ID, Conditional Access, Policy. La condizione è «Flussi di autenticazione» con la selezione «Device code flow», il controllo di accesso è «Blocca accesso». Microsoft raccomanda di far girare prima la policy in modalità «Solo report» e di attivarla solo dopo. Vengono esclusi due account di emergenza, il cui elenco va verificato regolarmente.

Licenza: Conditional Access o Security Defaults

Secondo Microsoft Learn, Conditional Access richiede almeno Microsoft Entra ID P1 (requisito secondo la documentazione sui livelli di autenticazione). Le aziende senza questa licenza dispongono dei Security Defaults, che secondo Microsoft non richiedono alcuna licenza. Tra le misure di protezione elencate vi sono la registrazione MFA per tutti gli utenti, il blocco dei protocolli legacy e il blocco del device code flow. Microsoft precisa inoltre che dal 1° luglio 2026 tutti i nuovi tenant Entra bloccano il device code flow nell'ambito dei Security Defaults. Secondo Microsoft, i Security Defaults non si possono personalizzare, ma solo attivare o disattivare. Chi ha bisogno di eccezioni o di regole più granulari ha bisogno di Conditional Access.

MFA per tutti, senza eccezioni per app o client

Una policy di base dovrebbe richiedere l'MFA per tutti gli utenti, tutte le risorse e tutti i tipi di client, oppure bloccare l'accesso. È esattamente ciò che chiede il rapporto di Huntress, e le lacune nascono spesso da eccezioni fatte con le migliori intenzioni, come «solo portali di amministrazione» o «solo browser». I protocolli legacy come IMAP, POP3 e l'autenticazione SMTP non supportano l'MFA e vanno bloccati.

I metodi resistenti al phishing, come le chiavi di sicurezza FIDO2 o Windows Hello for Business, proteggono molto meglio dall'intercettazione AiTM rispetto a codici, SMS o approvazioni push. Microsoft indica come caratteristica del livello «MFA resistente al phishing» un'interazione tra il metodo di autenticazione e la superficie di accesso (livelli di autenticazione). Questa pagina non contiene un'affermazione esplicita sull'AiTM, quindi questa valutazione è una conclusione dell'autore. Come creare una policy di base con livello di autenticazione è descritto nella pagina MFA per tutti gli utenti. Ha senso iniziare dagli amministratori.

Token Protection e i suoi limiti

Token Protection è un controllo di sessione in Conditional Access. Accetta solo token di accesso legati crittograficamente a un dispositivo registrato. Un token rubato non funziona quindi su un altro dispositivo. Secondo Microsoft Learn (pagina aggiornata ad agosto 2026), la funzione è generalmente disponibile per le applicazioni native su Windows, iOS, iPadOS e macOS e vale per Exchange Online, SharePoint Online e Teams. Su Windows si aggiungono Windows 365 e Azure Virtual Desktop. La pagina non contiene informazioni di licenza specifiche, quindi il requisito di licenza va chiarito separatamente. Come funzione di Conditional Access, Token Protection richiede almeno Entra ID P1, secondo una deduzione dell'autore. Non è una citazione di Microsoft.

I limiti sono indicati chiaramente. Le applicazioni basate su browser sono supportate solo in anteprima e solo per app web selezionate che usano Azure Resource Manager. Outlook sul web non è quindi coperto. Inoltre, i dispositivi devono essere registrati, aggiunti o aggiunti in modalità ibrida a Entra. I dispositivi Apple devono essere dispositivi gestiti con l'estensione per il single sign-on. Per le aziende con dispositivi personali, questo è un ostacolo reale.

Token Protection riduce il token replay, ma non elimina il rischio. Microsoft raccomanda un gruppo pilota, la modalità «Solo report» e la valutazione dei log di accesso prima di un'estensione generalizzata. Aiutano anche un dispositivo conforme come condizione di accesso, la limitazione del consenso alle nuove app e la verifica periodica delle nuove applicazioni aziendali. L'MFA resistente al phishing e gli accessi basati sul dispositivo riducono il rischio; il monitoraggio individua ciò che passa comunque.

Procedura di emergenza: revocare le sessioni, ripulire dispositivi e metodi MFA

La sequenza seguente è una raccomandazione dell'autore, derivata dalla documentazione Microsoft sulla revoca degli accessi e dal rapporto di Huntress. Non è un requisito ufficiale. La procedura generale dopo un attacco riuscito è descritta nell'articolo Ransomware: piano d'azione per i primi 60 minuti e in parte può essere applicata anche qui.

1. Bloccare l'account e revocare le sessioni: nell'Entra admin center, sotto Utenti, si deseleziona «Account abilitato» e si sceglie «Revoca sessioni», oppure tramite PowerShell con Revoke-MgUserSignInSession. In questo modo si impediscono nuovi token.
2. Reimpostare la password: negli ambienti ibridi Microsoft raccomanda di reimpostare la password due volte nell'Active Directory locale. Poi le sessioni vengono nuovamente revocate.
3. Controllare i metodi MFA: i metodi sconosciuti, in particolare una nuova app di autenticazione, vengono rimossi. L'utente reale configura i propri metodi solo dopo, idealmente con una conferma tramite richiamata telefonica.
4. Controllare i dispositivi: i dispositivi registrati sconosciuti vengono disattivati ed eliminati. Sono un segno di persistenza.
5. Ripulire la casella di posta: regole, inoltri, deleghe e regole di trasporto vengono controllati e rimossi. Gli elementi inviati ed eliminati vengono esaminati alla ricerca di anomalie.
6. Controllare le app: le applicazioni aziendali e i consensi delle app sconosciuti vengono rimossi.
7. Stabilire la portata: si analizzano i log di accesso a partire dal primo momento sospetto. Vanno considerati anche altri account dello stesso reparto, poiché la campagna ha spesso colpito più account per organizzazione.
8. Valutare le conseguenze per l'azienda: sono stati modificati coordinate bancarie, dati sugli stipendi o fatture? Banca, commercialista e consulente del lavoro vengono informati, i pagamenti sospesi e le richieste di modifica confermate per telefono. La decisione spetta alla direzione.
9. Valutare l'obbligo di notifica: la necessità di una notifica all'autorità di controllo dipende dal rischio. Il termine è di 72 ore dalla presa di conoscenza (articolo 33 GDPR). Non è una consulenza legale.

Perché la revoca non ha effetto immediato

Secondo Microsoft, i token di accesso sono validi per impostazione predefinita per un'ora. La revoca blocca i nuovi token e invalida i refresh token, ma i token di accesso già emessi restano validi fino alla scadenza. Per le applicazioni con cookie di sessione propri, deve essere l'applicazione stessa a terminare l'accesso. La Continuous Access Evaluation (CAE) riduce questo tempo a pochi minuti per Exchange Online, SharePoint Online e Teams, secondo Microsoft con un ritardo fino a 15 minuti. Huntress riferisce che i token di accesso sono rimasti validi fino a circa 90 minuti e che un reset della password da solo non rimuove né i dispositivi falsi né i metodi MFA. Le due cose vanno insieme: fare clic su «Revoca sessioni» è un inizio, non la fine.

Che cosa possono verificare questa settimana amministratori e direttori

• Il device code flow è bloccato, oppure i Security Defaults sono attivi?
• Una policy richiede l'MFA per tutti gli utenti, le risorse e i tipi di client senza eccezioni per le app?
• I protocolli legacy come IMAP, POP3 e l'autenticazione SMTP sono bloccati?
• Esistono due account di emergenza esclusi dalle policy e protetti separatamente?
• Sono stati controllati metodi di autenticazione, dispositivi e regole della posta in arrivo in contabilità e nell'ufficio del personale?
• È chiaro chi decide in caso di sospetto e quale fornitore di servizi è raggiungibile anche fuori orario?

Per il fornitore di servizi IT contano tempi di risposta, accesso ai log, conoscenza delle policy e documentazione scritta delle eccezioni. Uno sguardo esterno alla configurazione può essere utile, ad esempio con i security check. Anche il sito web e il dominio di posta dell'azienda fanno parte della superficie di attacco. Il controllo del sito web osserva il sito dall'esterno, ma non verifica le impostazioni di Entra.

La grande diffusione rende Microsoft 365 il bersaglio predefinito. Chi inasprisce le impostazioni predefinite, tiene d'occhio dispositivi e metodi e discute l'emergenza in anticipo toglie all'automazione la sua base. Visto con lucidità, è meno una questione di panico che di configurazione e routine.