M365: come rubano le credenziali (e come reagire)

Era un lunedì mattina quando Marta, responsabile acquisti, ha chiamato l'helpdesk con quella voce che conosci subito: "ho ricevuto risposte a mail che non ho mai mandato". Fatture in trattativa, fornitori che chiedevano conferme, bonifici da approvare. Non era uno scenario ipotetico — succede ogni settimana, in aziende di ogni dimensione. E ogni volta la catena è la stessa.

Come rubano le credenziali

Il punto di ingresso più comune oggi non è una vulnerabilità tecnica — è una pagina di login Microsoft clonata. Gli attaccanti usano OSINT (LinkedIn, siti aziendali, leak di dati) per personalizzare il phishing: il link contiene nome, ruolo e spesso il tenant Azure dell'azienda. L'utente vede un URL plausibile su un dominio typosquatted — micros0ft-login.com, login.microsoftonIine.com — e la pagina è identica alla reale.

Ma il vero salto di qualità è l'AiTM (Adversary-in-the-Middle). Framework come EvilProxy, Mamba2FA e Tycoon2FA non clonano una pagina statica: agiscono da proxy trasparente verso il vero login Microsoft. L'utente inserisce username, password e codice MFA — tutto autentico, tutto trasmesso al server legittimo. Ma il proxy intercetta il session cookie e il token di autenticazione in tempo reale. A quel punto l'MFA è già stato soddisfatto: il token è valido, autenticato, pronto per essere riutilizzato dall'attaccante.

Il secondo vettore è più brutale: MFA Fatigue. L'attaccante conosce già la password (da un leak, da credential stuffing) e manda 20-30 notifiche push sull'Authenticator in rapida sequenza, spesso di notte o durante una riunione. Conta sulla stanchezza, sulla distrazione, sull'utente che preme "Approva" solo per far smettere il telefono di vibrare. È esattamente quello che è successo a Uber nel 2022.

Il terzo scenario è il token theft. I session token e i refresh token di Entra ID hanno una vita che va da ore a giorni. Un infostealer come Redline o Lumma che gira sul laptop di un utente può estrarre questi token dal browser o dalla cache MSAL. Con il token, non serve né password né MFA — si accede direttamente alle API Microsoft 365. Strumenti come AADInternals automatizzano questo processo in pochi comandi.

Il quarto vettore, esploso nella primavera 2026, è il device code phishing: la piattaforma PhaaS Kali365, segnalata dall'FBI a maggio 2026, abusa del flusso OAuth 2.0 device authorization grant di Microsoft. L'attaccante avvia una richiesta di device code verso una propria app registrata, incolla il codice ottenuto in una pagina phishing che finge una condivisione OneDrive o SharePoint, e la vittima lo inserisce su microsoft.com/devicelogin — un dominio Microsoft legittimo. A quel punto l'app dell'attaccante riceve il token: nessuna password digitata, nessun prompt MFA da approvare. L'MFA non viene nemmeno sfiorata, perché il flusso non la prevede.

Dopo il primo accesso

I primi minuti dopo la compromissione sono di ricognizione silenziosa. L'attaccante accede alla casella mail, legge le bozze, cerca keyword come "bonifico", "IBAN", "fattura", "contratto". Usa la Graph API per enumerare utenti, gruppi, SharePoint e OneDrive. Tutto questo con il token legittimo dell'utente — nessun alert, nessuna anomalia visibile.

La persistenza viene costruita in strati. Prima vengono le regole inbox: un forward automatico verso un indirizzo esterno, o una regola che cancella automaticamente le mail che contengono "password reset", "security alert", "suspicious activity" — così l'utente non vede le notifiche di sicurezza. Poi viene aggiunto un secondo metodo MFA (numero di telefono dell'attaccante) sull'account compromesso. Infine, la persistenza più insidiosa: un'OAuth app con permessi delegati (mail.read, mail.send, files.read) registrata sull'account. Le OAuth app sopravvivono al reset della password — è una backdoor che rimane aperta anche dopo che l'incidente sembra risolto.

Dal punto di partenza, l'attaccante si sposta lateralmente: invia phishing interno ai colleghi ("controlla questo documento", con link AiTM), accede alle mail di altri utenti tramite permessi delegati preesistenti, e avvia il Business Email Compromise: modifica l'IBAN su una fattura in trattativa, risponde a una catena di mail finanziarie fingendo di essere il CFO, approva pagamenti urgenti.

Incident Response: cosa fare esattamente

Per l'utente: chiama IT subito, non aspettare. Non usare lo stesso account per farlo (usa il telefono, una mail personale, presentati fisicamente). Non cambiare la password da solo prima che IT revochi le sessioni — un cambio password senza revoca token lascia l'attaccante dentro. Elenca tutto ciò che hai cliccato nelle ultime 24-48 ore.

Per l'admin — sequenza operativa:

1. Revoca immediata di tutte le sessioni attive:

# Via PowerShell (AzureAD module)
Revoke-AzureADUserAllRefreshToken -ObjectId <user-object-id>

# Oppure via Entra ID: Users → seleziona utente → Revoke sessions

2. Reset password dall'admin (non da self-service):

Set-AzureADUserPassword -ObjectId <user-object-id> -Password <new-secure-password> -ForceChangePasswordNextLogin 

3. Rimuovi metodi MFA non riconosciuti (Entra ID → Users → Authentication methods). Verifica numero di telefono, app Authenticator, mail di recovery.

4. Ispeziona le regole inbox:

Get-InboxRule -Mailbox utente@azienda.com | Select Name, ForwardTo, DeleteMessage, SubjectContainsWords | Format-List

5. Revoca OAuth app sospette: Entra ID → Enterprise Applications → filtra per "User consent" → cerca app registrate nelle ultime 24-48h → revoca permessi.

6. Analizza i sign-in log: Entra ID → Sign-in logs → filtra per utente, ultime 48h. Cerca IP anomali, user agent insoliti (automazione), paesi non attesi. Nota: i token riutilizzati mostrano lo stesso IP del proxy AiTM, non quello dell'attaccante reale.

7. Verifica mail inviate e cancellate durante la finestra di compromissione. In Exchange Online:

Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-2) -EndDate (Get-Date) -UserIds utente@azienda.com -Operations SendMail,HardDelete,SoftDelete

8. Se è avvenuto phishing outbound o BEC: notifica i destinatari coinvolti, segnala le mail come phishing, avvia il processo di recall se le mail sono ancora non lette.

Strumenti utili: Microsoft Secure Score (baseline), Defender for Office 365 Threat Explorer (timeline attack), Microsoft Defender for Cloud Apps (impossible travel, token replay detection), HAWK o GOOSE per PowerShell-based log forensics.

La difesa vera non è l'MFA

L'MFA classico — push notification, SMS, TOTP — non ferma AiTM. Lo aggirano sistematicamente. La difesa concreta si costruisce su più livelli: Conditional Access con device compliance (solo dispositivi gestiti e conformi possono autenticarsi), FIDO2/passkey che sono phishing-resistant per design (la chiave è legata al dominio originale, non a un proxy), token lifetime policies aggressive (session token brevi, refresh token con IP binding), e monitoraggio continuo dei sign-in anomali.

Contro Kali365 specificamente, l'unica difesa efficace è bloccare il flusso a monte: Conditional Access → Authentication flows, disabilita il device code flow se la tua organizzazione non lo usa (la maggior parte non ne ha bisogno). Agendo prima che l'MFA entri in gioco, nessuna policy di autenticazione forte può fermarlo una volta avviato.

E soprattutto: utenti che chiamano senza vergogna. Marta ha fatto la cosa giusta. Il danno è stato contenuto perché ha alzato il telefono subito, senza aspettare di "essere sicura" che fosse un problema reale. Quella telefonata è costata 10 minuti. Non farlo sarebbe costato settimane.