Immagine illustrativa generata con AI
Il servizio di phishing BigBear 2.0 ha dirottato sessioni Microsoft 365 in 258 organizzazioni
BigBear 2.0 ha compromesso Microsoft 365 in 258 organizzazioni con phishing AiTM: rubate sessioni autenticate dopo l'MFA e migliaia di credenziali.
Testo generato da intelligenza artificiale, pubblicato senza revisione umana. Trasparenza IA
Una piattaforma di phishing-as-a-service nota come BigBear 2.0 ha compromesso account Microsoft 365 in 258 organizzazioni, utilizzando tecniche adversary-in-the-middle per sottrarre sessioni autenticate dopo che gli utenti avevano completato l’autenticazione multifattore.
CloudSEK ha pubblicato i risultati il 7 settembre 2026 alle 11:39, dopo aver ottenuto l’accesso amministrativo al pannello di controllo dell’operazione. I ricercatori hanno individuato 42 nodi VPS, ciascuno configurato per colpire l’autenticazione Microsoft 365.
La campagna ha raccolto oltre 5.000 record di credenziali legati a Microsoft 365 e ha interessato migliaia di indirizzi IP in più di 40 Paesi. L’infrastruttura non era progettata per aggirare l’MFA, ma per catturare la sessione creata dopo che Microsoft l’aveva accettata.
È proprio questa distinzione a rendere l’attacco particolarmente pericoloso. Un utente può inserire la password corretta, approvare una richiesta MFA e consegnare comunque all’attaccante una sessione cloud autenticata.
BigBear trasformava gli accessi riusciti in sessioni dell’attaccante
BigBear 2.0 è basato su Evilginx2, un framework di phishing adversary-in-the-middle, o AiTM. Invece di mostrare alle vittime un modulo di accesso completamente contraffatto, il servizio fa da proxy tra il browser della vittima e i sistemi di autenticazione legittimi di Microsoft.
La vittima visualizza un flusso di accesso Microsoft 365 e inserisce nome utente e password. BigBear inoltra questi dati a Microsoft, rimanendo posizionato tra le due parti.
Quando Microsoft richiede un ulteriore fattore di autenticazione, la vittima completa il passaggio attraverso la connessione gestita dal proxy. BigBear può quindi osservare i dati di autenticazione e catturare il cookie di sessione rilasciato al termine dell’accesso.
Un affiliato può inviare il cookie sottratto tramite l’API di BigBear e riutilizzare la sessione autenticata. Poiché Microsoft ha già verificato la password e la richiesta MFA, l’attaccante può accedere all’account senza ripetere l’interazione con il secondo fattore.
Si tratta di un dirottamento della sessione, non della violazione crittografica dell’MFA. Il fattore di autenticazione può funzionare esattamente come previsto, mentre la sessione risultante viene sottratta.
L’ecosistema interessato comprende:
- Microsoft 365
- Exchange Online
- Teams
- SharePoint
- OneDrive
- Autenticazione Entra ID
- Applicazioni collegate tramite single sign-on dell’organizzazione
Le conseguenze dipendono dai permessi della vittima. Un account ordinario potrebbe esporre messaggi email, conversazioni, documenti e file condivisi. Un’identità Entra ID con privilegi elevati potrebbe consentire l’accesso a risorse amministrative o ad altre applicazioni che si fidano della stessa identità cloud.
Nessun identificativo CVE si applica all’attività descritta. Si tratta di un abuso dell’autenticazione gestita tramite proxy e di cookie di sessione sottratti, non di una vulnerabilità software divulgata che interessi un insieme definito di versioni di Microsoft 365.
Il pannello ha registrato compromissioni in oltre 40 Paesi
I dati più ampi sulla targettizzazione di BigBear elencavano 461 organizzazioni. CloudSEK ha valutato che 258 avessero subito almeno una compromissione completata con elusione dell’MFA attraverso il furto della sessione.
Il pannello di controllo ha inoltre registrato 3.331 indirizzi IP univoci delle vittime, distribuiti in più di 40 Paesi. Un indirizzo IP non corrisponde necessariamente a un singolo account individuale; il dato non deve quindi essere interpretato come un conteggio esatto delle vittime.
CloudSEK ha riferito di 5.137 record di credenziali esfiltrati, suddivisi come segue:
- 474 autenticazioni completate con elusione delle protezioni MFA
- 1.032 password in chiaro
- 4.148 cookie di sessione autenticati
Queste tre cifre totalizzano 5.654, non 5.137. Non è noto se le categorie si sovrappongano, se alcune voci siano state deduplicate o se uno dei valori riportati sia errato. La discrepanza rimane irrisolta e non deve essere corretta sulla base di supposizioni.
Il pannello era ancora accessibile quando sono stati pubblicati i risultati. Tuttavia, secondo quanto riferito, l’infrastruttura di phishing collegata era offline da quasi tre settimane. Questo potrebbe aver interrotto la raccolta attiva, ma non invalida cookie, password o token già ottenuti.
Gli accessi sottratti in precedenza potrebbero rimanere utili finché i difensori non revochino le sessioni, facciano scadere i token, modifichino le credenziali o impongano nuovi requisiti di autenticazione.
Gli affiliati ricevevano le credenziali sottratte tramite Telegram
BigBear operava come servizio multiutente, non come strumento riservato a un singolo attore delle minacce. Secondo quanto riferito, il pannello era stato noleggiato ad almeno cinque operatori affiliati, consentendo ai clienti di condurre campagne senza dover sviluppare una propria infrastruttura AiTM.
CloudSEK ha collegato questi operatori a bot di esfiltrazione Telegram attivi. I bot consegnavano le credenziali catturate agli affiliati in tempo reale, riducendo l’intervallo tra l’accesso della vittima e il tentativo dell’attaccante di utilizzare la sessione risultante.
La piattaforma utilizzava una configurazione “offy” per posizionare il proprio proxy nello scambio di autenticazione Microsoft. Operava inoltre tramite 42 nodi VPS, un modello infrastrutturale che indica la volontà di supportare più campagne o clienti.
Non è stato divulgato alcun elenco di indirizzi dei nodi, domini di phishing, hash dei file o altri indicatori direttamente ricercabili. Le organizzazioni non possono quindi affidarsi esclusivamente al blocco dell’infrastruttura BigBear nota.
Il rilevamento deve concentrarsi anche sull’identità e sul comportamento delle sessioni. Tra i segnali rilevanti figurano l’uso insolito di sessioni autenticate, gli accessi da dispositivi non gestiti, attività inattese su caselle di posta o file, modifiche ai privilegi e l’uso dei token in modo non coerente con il normale comportamento dell’utente.
Proxy residenziali e interferenze con WebAuthn riducevano le possibilità di rilevamento
BigBear supportava connessioni tramite proxy residenziali con geolocalizzazione coerente in 69 Paesi. Questi proxy consentivano agli affiliati di generare traffico di autenticazione da indirizzi residenziali vicini alla posizione apparente della vittima.
Questa capacità indebolisce i controlli basati principalmente sulla posizione geografica. Una sessione sottratta utilizzata da un Paese lontano potrebbe attivare un avviso di viaggio impossibile o basato sulla posizione, mentre un proxy residenziale nella regione prevista può far apparire lo stesso accesso meno anomalo.
La posizione rimane un segnale utile, ma da sola non è sufficiente. Anche lo stato di gestione del dispositivo, le proprietà della sessione, l’attività delle applicazioni, il comportamento dei token e i privilegi dell’account dovrebbero influenzare le decisioni di accesso.
CloudSEK ha inoltre individuato JavaScript personalizzato destinato a interferire con il supporto del browser a FIDO2/WebAuthn. L’obiettivo apparente era impedire o ostacolare l’autenticazione resistente al phishing, spingendo le vittime verso metodi che possono essere inoltrati più facilmente tramite un proxy AiTM.
Un’autenticazione FIDO2/WebAuthn applicata correttamente è resistente al phishing tradizionale delle credenziali, perché l’autenticazione è vincolata all’origine web legittima. BigBear non cercava quindi di violare direttamente questa protezione, ma di renderla indisponibile durante il flusso di accesso della vittima.
Le organizzazioni dovrebbero analizzare gli errori WebAuthn imprevisti, soprattutto quando agli utenti viene successivamente proposto un metodo di accesso più debole. Consentire un metodo alternativo può annullare gran parte del vantaggio di sicurezza offerto dall’adozione di credenziali resistenti al phishing.
I difensori devono revocare le sessioni, non limitarsi a cambiare le password
La sola reimpostazione della password potrebbe non rimuovere un attaccante che possiede già un cookie di sessione valido. Chi interviene sugli incidenti dovrebbe trattare una possibile esposizione a BigBear sia come una compromissione delle credenziali sia come un furto di token.
Le azioni consigliate includono:
- Reimpostare le password associate agli account esposti o sospetti.
- Revocare le sessioni Microsoft 365 attive, in modo che i cookie catturati non possano più fornire accesso.
- Invalidare o aggiornare i token pertinenti, compresi quelli utilizzati dalle applicazioni cloud collegate.
- Forzare una nuova autenticazione per le identità con privilegi, gli amministratori e gli altri account ad alto impatto.
- Richiedere metodi FIDO2/WebAuthn resistenti al phishing e limitare, ove operativamente possibile, le opzioni alternative più deboli.
- Utilizzare policy Conditional Access che richiedano dispositivi gestiti o conformi per i servizi sensibili.
- Esaminare le attività su Exchange Online, Teams, SharePoint, OneDrive ed Entra ID alla ricerca di azioni incoerenti con il ruolo dell’utente o con la cronologia del dispositivo.
- Evitare di considerare la coerenza geografica una prova di legittimità, vista la disponibilità di proxy residenziali da parte di BigBear.
CloudSEK ha dichiarato di aver informato le forze dell’ordine e diverse organizzazioni colpite. Le credenziali esposte sono state inoltre incluse in segnalazioni di responsible disclosure.
La difficoltà più ampia è che l’attività malevola diventa più difficile da fermare quando si svolge all’interno di una sessione autenticata valida. Una valutazione Blue Report 2026 citata ha rilevato che solo il 37% delle azioni degli attaccanti eseguite con credenziali valide è stato bloccato su 338 milioni di simulazioni condotte negli ambienti di produzione dei clienti. Il dato non si riferisce nello specifico a BigBear, ma mostra perché il monitoraggio post-autenticazione sia importante.
L’MFA rimane necessario, ma non tutti i metodi MFA offrono lo stesso livello di protezione contro il phishing AiTM. Per le organizzazioni esposte a servizi come BigBear, il modello più efficace combina autenticazione vincolata all’origine, requisiti sui dispositivi gestiti, rapida revoca delle sessioni e monitoraggio comportamentale dopo l’accesso.
Fonti
Questo articolo è una rielaborazione originale basata sulle fonti seguenti.
