Microsoft 365 sotto attacco: BigBear 2.0 aggira MFA e ruba le sessioni

La protezione di un account Microsoft 365 non termina più con l’attivazione dell’autenticazione a più fattori (2FA). Una campagna di phishing analizzata da CloudSEK mostra con particolare chiarezza il problema: BigBear 2.0, un servizio realizzato da un gruppo di criminali informatici ha raccolto migliaia di credenziali e cookie di sessione Microsoft 365, riuscendo nel superamento delle difese 2FA e MFA (Multi-factor authentication) contro almeno 258 organizzazioni.

I ricercatori hanno osservato 5.137 record sottratti, 1.032 password in chiaro, 4.148 cookie di sessione e 474 autenticazioni compromesse; le vittime, individuate attraverso gli indirizzi IP pubblici, appartengono a oltre 40 Paesi.

BigBear 2.0 rappresenta bene l’evoluzione del phishing aziendale: il criminale non prova necessariamente a “indovinare” o neutralizzare il codice MFA. Lascia che sia l’utente a completare correttamente l’autenticazione con Microsoft e si appropria della sessione che ne deriva. È una tecnica nota da tempo come Adversary-in-the-Middle, o AiTM, ma servizi “pronti all’uso” come BigBear riducono significativamente le competenze necessarie per utilizzare queste tattiche malevole su larga scala.

BigBear 2.0, un servizio di phishing costruito per Microsoft 365

CloudSEK ha individuato BigBear 2.0 nel giugno 2026 e, durante l’indagine, è riuscita ad accedere al pannello amministrativo dell’infrastruttura. Da lì emerge un’organizzazione decisamente più articolata rispetto al classico kit contenente qualche pagina HTML contraffatta: il servizio gestiva complessivamente 42 nodi VPS e utilizzava una configurazione Evilginx2 denominata “offy“, progettata specificamente per intercettare l’autenticazione Microsoft 365.

Evilginx2 è un framework open source pensato per creare infrastrutture di phishing basate su reverse proxy.

Fonte dell’immagine: CloudSEK

A differenza dei kit più semplici, che imitano graficamente una pagina di accesso e raccolgono username e password, Evilginx2 si interpone in tempo reale tra il browser della vittima e il servizio legittimo. Inoltra le richieste verso il vero sito di autenticazione, riceve le risposte e le restituisce all’utente, mantenendo però la possibilità di osservare credenziali, token e cookie di sessione che transitano attraverso il proxy.

È proprio questa caratteristica a renderlo adatto agli attacchi AiTM contro piattaforme come Microsoft 365. L’utente può trovarsi davanti al vero flusso di login Microsoft, completare correttamente anche il secondo fattore e ottenere una sessione valida; Evilginx2 cattura gli elementi di sessione generati dopo l’autenticazione. Non “rompe” la 2FA/MFA e non deve conoscere in anticipo il codice temporaneo: sfrutta invece il fatto di trovarsi nel mezzo della comunicazione.

Il cookie diventa più prezioso della password

Una volta ottenuto un token riutilizzabile, conoscere la password può persino diventare secondario. Se il servizio accetta quella sessione e non richiede una nuova autenticazione, l’attaccante può accedere alle risorse con i privilegi già concessi all’utente.

Nel caso di Microsoft 365 le conseguenze possono coinvolgere Exchange Online, Teams, SharePoint, OneDrive e applicazioni collegate tramite single sign-on (SSO).

CloudSEK descrive inoltre un meccanismo automatico di replay dei cookie: BigBear dispone di un’API capace di prendere le informazioni appena sottratte e tentare rapidamente il riutilizzo della sessione.

Una sessione sottratta ha una finestra temporale limitata e può perdere validità a causa di revoche, nuove valutazioni delle policy o altri eventi. Automatizzare il passaggio tra acquisizione e utilizzo aumenta quindi le probabilità che il criminale riesca a entrare prima che qualcosa faccia scattare un controllo.

Microsoft stessa distingue chiaramente access token, refresh token e cookie di sessione. Gli access token Entra hanno normalmente una durata limitata, spesso nell’ordine di un’ora, mentre la durata effettiva delle sessioni Web dipende anche dall’applicazione e dalle policy applicate. Una revoca, inoltre, non implica sempre la scomparsa istantanea di qualunque sessione: è uno dei motivi per cui la risposta a una compromissione non dovrebbe limitarsi al cambio della password.

BigBear prova addirittura a far rinunciare l’utente a FIDO2

La parte più interessante dell’analisi riguarda alcune modifiche JavaScript aggiunte dagli sviluppatori di BigBear rispetto a Evilginx2 standard. Una di esse interferisce con FIDO2/WebAuthn: il codice altera le API WebAuthn disponibili nella pagina, compreso l’oggetto PublicKeyCredential e le chiamate navigator.credentials, così da impedire il normale utilizzo delle credenziali FIDO.

Lo scopo non consiste nel violare FIDO2. Anzi, è esattamente l’opposto: BigBear cerca di renderlo inutilizzabile e spingere la vittima verso un metodo alternativo più facilmente intercettabile, per esempio TOTP, SMS o una conferma push.

La ragione deriva dal funzionamento di WebAuthn. Una credenziale FIDO è legata crittograficamente all’origine Web per la quale è stata registrata. Se l’utente crede di autenticarsi su Microsoft ma il browser si trova realmente su un dominio controllato dal criminale, l’origine non coincide con quella prevista dalla credenziale. Il proxy non può catturare una risposta WebAuthn valida per il dominio Microsoft e riutilizzarla a piacimento.

Da non sottovalutare anche il campanello d’allarme: se un account normalmente configurato per utilizzare una passkey o una chiave di sicurezza improvvisamente sostiene che il metodo non funziona e propone SMS, OTP o altre alternative, non conviene trattare l’evento come un banale inconveniente tecnico.

BigBear mostra perché MFA va considerata soltanto un punto di partenza

L’autenticazione multifattore continua a eliminare una quantità enorme di attacchi basati sul semplice furto della password; BigBear dimostra però che bisogna distinguere i metodi che verificano soltanto il possesso di un secondo fattore da quelli che legano crittograficamente l’autenticazione al sito legittimo.

La differenza diventa ancora più importante quando Microsoft 365 funziona come porta d’ingresso verso posta elettronica, documenti aziendali e numerose applicazioni federate. Un cookie autenticato può valere molto più della password che ha contribuito a generarlo.

L’impostazione più ragionevole consiste nel ridurre progressivamente l’uso dei fattori facilmente intercettabili, imporre modalità phishing-resistant per gli accessi, almeno agli utenti dotati di privilegi ampi, associare l’accesso a dispositivi affidabili e usare Conditional Access per richiedere nuove verifiche quando cambiano rischio o caratteristiche della sessione.

BigBear 2.0 non sfrutta una vulnerabilità segreta in Microsoft 365: fa leva, invece, sulla possibilità di sottrarre e riutilizzare una sessione già autenticata, anche quando l’accesso iniziale è protetto da MFA. Cosa possibile quando browser dell’utente e sito che effettua l’autenticazione non sono legati crittograficamente.