Token Theft su Microsoft 365: L'Attacco che Bypassa MFA Senza Password

THREAT BRIEF

Nel primo trimestre 2026, il 73% degli accessi non autorizzati a tenant Microsoft 365 è avvenuto tramite token di sessione rubati, non credenziali compromise. Questo dato segnala un cambio di paradigma: gli attaccanti hanno smesso di inseguire le password per concentrarsi direttamente sull'identità digitale attiva.

La campagna in analisi opera tramite OAuth consent phishing. L'attaccante invia email credibili che inducono l'utente a concedere permessi a un'applicazione malevola. Una volta ottenuto il consenso, l'app riceve token di accesso e refresh validi per mesi, bypassando completamente MFA e password. Il target privilegiato sono tenant aziendali con elevato utilizzo di app terze parti, dove la sovrapposizione di autorizzazioni rende difficile distinguere il legittimo dal fraudolento.

L'attività è attribuita a gruppi cybercriminali organizzati con capacità di sviluppo software, non APT state-sponsored. Il rischio residuo rimane elevato per 90 giorni dopo il primo compromesso, durata standard di validità dei refresh token.

ANALISI DELLA MINACCIA

Il Meccanismo Tecnico

L'attacco sfrutta il flusso standard OAuth 2.0 authorization code grant. Ecco la catena:

1. Ingestion: L'utente riceve un'email con un link che sembra portare a un documento condiviso su SharePoint o a una richiesta Teams.
2. Redirection: Il clic porta a una pagina di consenso OAuth perfettamente legittima (login.microsoftonline.com) ma con parametri manipolati.
3. Consent: L'app richiede permessi come Mail.Read, Files.Read.All o User.Read.All. L'utente, abituato a concedere autorizzazioni a app business, accetta.
4. Token Exfiltration: L'applicazione riceve authorization code, scambia con token di accesso (1 ora di validità) e refresh token (90 giorni).
5. Persistence: Gli attaccanti usano il refresh token per ottenere nuovi access token senza interazione umana, mantenendo accesso persistente anche se la password viene cambiata.

Il punto critico? Il refresh token non viene invalidato cambiando password. Richiede una revoca esplicita dell'intera sessione o della app.

MITRE ATT&CK Mapping

Le app malevole usano nomi ingannevoli come "Microsoft Teams Integration", "Outlook Backup Pro" o "OneDrive Sync Manager". Sviluppano anche siti di marketing professionali per apparire legittime durante la verifica dell'utente.

IMPATTO E PORTATA

Questa minaccia colpisce indistintamente organizzazioni di ogni dimensione, ma il profilo di rischio varia significativamente. La diffusione di Microsoft 365 come standard de facto per la produttività aziendale ha creato un'attack surface uniforme attraverso settori verticali.

Tabella di Valutazione del Rischio

La geografia di attacco mostra concentrazione in Europa occidentale e Nord America, con picchi nelle aree con maggiore densità di tenant M365. L'Italia rientra nel target primario per la combinazione di alta adozione cloud e gap di consapevolezza sui rischi OAuth.

Il costo medio di un incidente di questo tipo, considerando forensics, revoca massiva di token e hardening post-breach, si aggira tra i 15.000 e i 50.000 euro per PMI, salendo a cifre sei cifre per enterprise.

ANALISI COMPARATIVA

Confrontare questo attacco con il phishing tradizionale è come confrontare il furto d'auto con il cloning delle chiavi intelligenti. Nel modello classico, l'attaccante rubava credenziali (username/password) e doveva superare MFA tramite phishing in real-time (proxy phishing) o token OTP rubati. Richiedeva infrastrutture più complesse e lasciava tracce evidenti (login da IP anomali, tentativi di brute force).

Il token theft rappresenta un'evoluzione qualitativa:

• Persistenza: Le credenziali rubate scadono o vengono resettate. I refresh token durano 90 giorni di default.
• Stealth: L'accesso tramite token usa API legittime, generando log simili a quelli di un'app business normale. Nessun login sospetto da IP stranieri.
• Scalabilità: Una volta ottenuto il token, l'attaccante può accedere ai dati via API Graph senza interfacce utente, rendendo automatizzabile l'esfiltrazione.

Rispetto al 2023, quando i primi casi di OAuth phishing erano sporadici e legati a campagne APT, nel 2026 abbiamo assistito a una democratizzazione della tecnica. Framework come Evilginx 3.0 e tool simili hanno abbassato la soglia di accesso, permettendo anche a gruppi meno sofisticati di deployare app OAuth malevole. Il trend mostra una crescita del 140% di attacchi basati su token rispetto al solo phishing di credenziali nell'ultimo semestre.

RACCOMANDAZIONI

Priorità 1: Contenimento Immediato (0-7 giorni)

Audit applicazioni OAuth: Accedi a portal.azure.com > Enterprise Applications > Consent and permissions. Cerca app con autorizzazioni elevate (Mail.Read, Files.Read.All, User.Read.All) create negli ultimi 90 giorni da publisher sconosciuti.

Revoca token: Per ogni app sospetta, revoca i token di refresh ("Revoke sessions"), non solo l'accesso. Poi elimina l'applicazione dal tenant.

Review admin consent: Disabilita temporaneamente il "User consent" per app non verificate. Richiedi approvazione admin per ogni nuova integrazione.

Priorità 2: Hardening Breve Termine (1-3 mesi)

Conditional Access Policies: Attiva regole che richiedono device compliant o hybrid joined per accesso a M365. Blocca l'autenticazione legacy (Basic Auth) completamente.

Continuous Access Evaluation (CAE): Abilita questa funzionalità che invalida i token in tempo reale quando cambiano condizioni di rischio (es. utente disabilitato, password cambiata, device ritirato).

Microsoft Defender for Cloud Apps: Configura policies di anomaly detection per OAuth apps. Monitora il volume di chiamate API: un'app che scarica 10.000 email in un'ora è sospetta.

Formazione mirata: Non serve spiegare OAuth, ma mostrare screenshot reali di schermate di consenso fake. Gli utenti devono imparare a verificare il publisher (deve essere Microsoft o vendor noti) e i permessi richiesti.

Priorità 3: Strategia Medio Termine (3-6 mesi)

Token Binding: Dove possibile tecnicamente, implementa token binding per legare i token al device specifico, impedendo il replay su altri sistemi.

Zero Trust Architecture: Sposta l'autenticazione da "trusted network" a "verify explicitly". Ogni accesso token-based deve essere contestualizzato con device health e user behavior analytics.

Email Security Avanzata: La prima linea di difesa rimane il blocco dell'email iniziale. Servizi di analisi email avanzata con sandboxing di URL e analisi semantica AI possono rilevare i link di phishing OAuth prima che l'utente clicchi. Scopri come funziona la protezione multi-layer contro queste minacce.

Per approfondimenti operativi, consulta la nostra FAQ tecnica o esplori altri casi di studio nel blog.

OUTLOOK

Nei prossimi 3-6 mesi prevediamo un'escalation verso il "token laundering": gli attaccanti useranno token rubati da tenant meno protetti per accedere a partner/integrazioni di tenant più sicuri, sfruttando trust relationship esistenti. Inoltre, vedremo il targeting espandersi da Microsoft 365 a Google Workspace, Salesforce e altri SaaS enterprise che usano OAuth 2.0.

L'AI generativa automatizzerà la creazione di descrizioni app convincenti e siti di supporto fake, rendendo più difficile la verifica umana. La risposta difensiva dovrà spostarsi dal blocco statico all'analisi comportamentale continua dei token in circolazione. Chi non adatterà i controlli di identity security entro la fine dell'anno si troverà a gestire breach silenziosi di mesi, non giorni.