Knight Office ruba le sessioni Microsoft 365 dopo l’MFA: non basta reimpostare la password

Un utente può completare correttamente l’autenticazione a più fattori e subire comunque una compromissione. È il punto centrale emerso nel caso Knight Office: un attacco di phishing adversary-in-the-middle (AiTM) intercetta il materiale di sessione Microsoft 365 generato dopo l’accesso e può essere seguito dalla registrazione non autorizzata di un dispositivo in Microsoft Entra ID. Operativamente, quindi, non è un semplice furto di password: è un incidente di identità. 640

Come funziona la catena d’attacco

L’attività osservata da Huntress è iniziata con un’email di phishing in stile DocuSign. Il collegamento passava da un servizio di tracciamento Monday.com e poi da un sito Joomla compromesso, così da nascondere la destinazione finale ai controlli reputazionali e a un’ispezione superficiale del link. 6

La pagina di destinazione può imitare un flusso di collaborazione o di accesso Microsoft e indurre la vittima a proseguire l’autenticazione, anche mediante un’interazione simile a un codice dispositivo. Lo scopo è ottenere l’approvazione dell’utente in un flusso che appare legittimo.

Nella componente AiTM, l’infrastruttura criminale si interpone come proxy inverso tra la vittima e il vero servizio di accesso Microsoft:

1. la vittima inserisce le credenziali e completa l’MFA;
2. il proxy inoltra in tempo reale le interazioni a Microsoft;
3. dopo l’accesso, l’attaccante cattura il cookie di sessione autenticata o altro materiale token restituito al browser;
4. quel contesto autenticato viene riprodotto dall’infrastruttura dell’attaccante per accedere all’account.

Non si tratta di una violazione della crittografia dell’MFA. Viene rubato lo stato di autorizzazione creato dopo l’MFA. Microsoft definisce il furto di token come la compromissione e la riproduzione di token emessi per un utente che potrebbe aver già soddisfatto l’autenticazione multifattore. 40

Perché il reset della password può non chiudere l’intrusione

Una sessione browser rubata, o un accesso derivato da un refresh token, può consentire all’intruso di restare operativo senza una nuova richiesta di password o MFA, finché i token interessati non vengono revocati. Le indicazioni Microsoft sul furto di token prevedono esplicitamente il blocco degli utenti o dispositivi coinvolti e la revoca dei token correnti. 40

Nel caso Knight Office, l’attività successiva alla compromissione ha incluso la registrazione in Entra ID di un host non autorizzato e la configurazione di credenziali Windows Hello for Business controllate dall’attaccante. 6 Questo può creare un canale di autenticazione separato: anche dopo la revoca della sessione web o il cambio password, il team di difesa deve verificare che non restino dispositivi o metodi di autenticazione non autorizzati.

Un meccanismo di persistenza analogo è stato documentato nelle campagne di phishing con codice dispositivo. Microsoft ha segnalato che un refresh token ottenuto abusando di questo flusso può servire a richiedere accesso alla registrazione dispositivi e a registrare in Entra ID un dispositivo controllato dall’operatore. 28

Phishing con codice dispositivo e AiTM: tecniche vicine, ma diverse

Nel phishing AiTM viene intercettato un accesso live e viene rubata la sessione risultante. Il phishing con codice dispositivo, invece, abusa di un legittimo flusso OAuth di autorizzazione per dispositivi: l’attaccante avvia la richiesta, convince la vittima a inserire il codice e ad autenticarsi, quindi riceve token per il proprio client se la vittima approva. 22

In entrambi i casi l’obiettivo non è più solo la password, ma l’acquisizione di artefatti di autorizzazione utilizzabili. I programmi di rilevamento dovrebbero pertanto coprire entrambe le strade. Elastic evidenzia, per il codice dispositivo, accessi Entra interattivi riusciti con protocollo device code, client Microsoft Authentication Broker e richieste verso risorse Microsoft di prima parte quali Exchange Online, Microsoft Graph o SharePoint. 17

Knight Office nel mercato del phishing-as-a-service

L’indagine Huntress ha stabilito una sequenza concreta: esca a tema documento, reindirizzamenti multipli, acquisizione di token di sessione e registrazione non autorizzata di un dispositivo Entra. Huntress ha inoltre associato ripetuti replay di token nella propria telemetria a un singolo indirizzo IP; l’osservazione, però, non va interpretata come conteggio globale delle vittime. 6

Knight Office si inserisce in un mercato più ampio di kit di phishing-as-a-service (PhaaS) orientati alle sessioni di identità Microsoft 365:

• Mirage2FA usa infrastruttura AiTM per sottrarre credenziali e sessioni autenticate. ANY.RUN ha riportato 9.332 potenziali eventi di compromissione tra il 2024 e il 2026, inclusi 4.561 eventi di furto di cookie. Sono dati telemetrici su eventi potenziali, non il numero di vittime confermate. 4
• Kali365, osservato per la prima volta nell’aprile 2026 e distribuito soprattutto via Telegram, è stato oggetto di un avviso dell’FBI per la capacità di ottenere token OAuth di accesso e refresh di Microsoft 365. 1

La lezione difensiva è chiara: token e sessioni devono essere protetti, rilevati e gestiti con la stessa urgenza riservata alla compromissione delle password.

Priorità di rilevamento per Entra ID e Microsoft 365

È preferibile correlare più segnali anziché basarsi su un singolo allarme.

Cercare replay sospetti di sessione

Indagare gli accessi in cui lo stesso account o la stessa sessione appare, a breve distanza, da indirizzi IP, reti, aree geografiche, browser o caratteristiche del dispositivo sensibilmente diversi, soprattutto subito dopo un MFA riuscito. Microsoft segnala rilevamenti per uso anomalo dei token e proprietà di accesso non familiari associate ai cookie di sessione. 38

Analizzare l’uso anomalo del codice dispositivo

Esaminare le autenticazioni riuscite con codice dispositivo e verificare che client, IP sorgente, risorsa richiesta e comportamento dell’utente siano coerenti con il contesto. Nei log di accesso Entra, l’attività può essere identificata da campi quali authenticationProtocol: deviceCode e originalTransferMethod: deviceCodeFlow. 26

Sorvegliare le modifiche che creano persistenza

Dare priorità agli eventi di audit Entra relativi a:

• nuove registrazioni o join di dispositivi, cambi di proprietà o identificativi insoliti;
• nuovi metodi Windows Hello for Business, FIDO2/passkey, MFA o recupero account;
• consensi applicativi, modifiche a enterprise application, service principal o assegnazioni di ruoli privilegiati;
• cambiamenti a Conditional Access, posizioni denominate, federazione, inoltro della posta e regole della posta in arrivo.

La registrazione di un dispositivo non autorizzato poco dopo un’autenticazione sospetta è un forte segnale di persistenza sull’identità. 2628

Correlare evidenze email e identità

Un messaggio a tema DocuSign può essere semplice spam; un nuovo dispositivo Entra può essere legittimo. Ma la combinazione di messaggio sospetto, catena di redirect, MFA riuscito, riuso anomalo della sessione e modifica a dispositivo o metodo di autenticazione merita intervento immediato.

Risposta all’incidente: contenere l’identità, non solo la password

In presenza di un sospetto furto di token tramite AiTM o codice dispositivo, adottare un flusso di contenimento dell’identità:

1. Bloccare o disabilitare l’identità coinvolta quando necessario. Disabilitare utenti e dispositivi interessati mentre viene definita l’estensione dell’incidente. 40
2. Revocare sessioni correnti e refresh token. Usare la procedura Entra di revoca delle sessioni di accesso e imporre una nuova autenticazione. Per il phishing con codice dispositivo, Microsoft raccomanda esplicitamente revokeSignInSessions. 27
3. Reimpostare le credenziali, ma non fermarsi lì. Il reset della password è una misura aggiuntiva, non la prova che l’accesso dell’attaccante sia terminato. 4042
4. Rimuovere la persistenza. Identificare ed eliminare i dispositivi Entra non autorizzati; verificare la proprietà dei dispositivi; rimuovere metodi Windows Hello for Business, FIDO2, MFA, recupero e credenziali applicative aggiunti di recente; controllare i consensi. 628
5. Effettuare hunting nell’intero tenant. Cercare URL delle esche, infrastrutture di redirect, IP sospetti, eventi device code, anomalie di accesso dopo MFA e nuove registrazioni di dispositivi per tutti gli utenti.
6. Valutare l’impatto sul business. Esaminare attività in Exchange, SharePoint, OneDrive, Teams, Microsoft Graph, OAuth e audit amministrativi: accesso ai dati, regole e inoltri di posta, condivisioni esterne, abuso dei consensi, modifiche dei privilegi e accesso ad applicazioni connesse tramite SSO.
7. Preservare le prove prima della bonifica. Conservare messaggi e intestazioni di phishing, mail trace, catene di redirect, log di accesso e audit Entra, record dei dispositivi, record dei consensi OAuth e telemetria browser o endpoint.

Ridurre l’esposizione prima della prossima esca

L’autenticazione resistente al phishing è un controllo importante per gli utenti ad alto rischio, ma deve far parte di una difesa a più livelli. Microsoft raccomanda metodi come chiavi di sicurezza FIDO2, Windows Hello for Business e autenticazione basata su certificati, insieme a controlli che riducano la durata utile delle sessioni su dispositivi non gestiti. 39

Le organizzazioni dovrebbero inoltre valutare se il flusso con codice dispositivo sia davvero necessario, limitare la registrazione non autorizzata di dispositivi, applicare Conditional Access in base a conformità del dispositivo e rischio, e assicurarsi che il team operativo possa revocare rapidamente le sessioni e indagare le modifiche agli oggetti di identità.

La lezione di Knight Office non è che l’MFA abbia fallito. È che un evento MFA riuscito può essere l’inizio della compromissione quando l’attaccante ruba la sessione che ne consegue. La risposta è completa solo dopo aver verificato e contenuto sessioni, dispositivi, metodi di autenticazione e accessi delegati dell’intero tenant.