OAuth Consent Phishing:
il bypass MFA su Microsoft 365

Cosa sta succedendo

Il 7 aprile 2026 l’ACN (Agenzia per la Cybersicurezza Nazionale) ha pubblicato tramite il CSIRT Italia il Bollettino BL01/260407, che documenta una campagna mirata di phishing basata sul flusso Device Code Grant di OAuth 2.0 contro tenant Microsoft 365 ed Entra ID italiani. È l’ultima variante di una famiglia di attacchi — l’OAuth Consent Phishing — osservata in incidenti reali anche su PMI del territorio nei mesi precedenti.

Il tratto comune è la capacità di aggirare completamente l’MFA: l’utente autentica regolarmente sulla pagina Microsoft autentica, l’MFA è rispettato, e il token OAuth viene emesso dopo l’autenticazione per un’applicazione controllata dall’attaccante. Da quel momento, password cambiate o sessioni chiuse non fermano più l’accesso: serve una revoca esplicita del grant dal tenant.

Come funziona il Consent Phishing

A differenza del phishing credenziale classico, l’OAuth Consent Phishing non chiede mai la password. Il meccanismo è lineare:

• 1Esca — l’utente riceve un’email che sembra provenire da un servizio familiare (un tool di produttività, un sistema di firma, un gestionale) con un link che presenta un’app dal brand credibile.
• 2Schermata Microsoft autentica — il link reindirizza a login.microsoftonline.com. L’URL è legittimo, il certificato è valido, la pagina è quella vera. L’utente autentica con le proprie credenziali e con l’MFA.
• 3Richiesta di consenso — dopo l’autenticazione appare la schermata di consenso OAuth: l’app chiede scope come Mail.ReadWrite, Files.ReadWrite.All, offline_access. La maggior parte degli utenti non legge i permessi e clicca Accetta.
• 4Emissione del token — Microsoft emette un access token e un refresh token validi. L’attaccante li riceve e accede alla casella, ai file e alle risorse del tenant usando le API Microsoft Graph, senza password e senza MFA.
• 5Persistenza — lo scope offline_access permette di rinnovare automaticamente l’access token. La sessione dell’attaccante sopravvive al cambio password, al logout e alla revoca delle sessioni Entra ID. Serve revocare il grant dell’applicazione.

Device Code Grant: la variante del Bollettino CSIRT

Il Bollettino CSIRT BL01/260407 del 7 aprile 2026 descrive una variante specifica. L’attaccante contatta l’utente (via email, messaggio o telefono), gli chiede di aprire aka.ms/devicelogin e di inserire un codice che cambia ogni pochi minuti. Questo è il flusso Device Code Grant, pensato per dispositivi IoT o terminali senza tastiera completa (smart TV, console, stampanti). Quando l’utente conferma, autorizza di fatto un client dell’attaccante.

È particolarmente efficace perché l’utente non vede alcuna schermata di app di terze parti sospetta: inserisce solo un codice su un dominio Microsoft. La raccomandazione del CSIRT è disabilitare il Device Code Flow per gli utenti che non ne hanno bisogno, tramite una policy di Conditional Access che blocchi il grant type urn:ietf:params:oauth:grant-type:device_code per tutti i client non esplicitamente autorizzati.

Contromisure: cosa configurare su Entra ID

Nessuna contromisura presa singolarmente risolve il problema. Serve un insieme coordinato di configurazioni, quasi tutte a costo zero se il tenant ha già una licenza Microsoft 365 business standard:

• 1Bloccare il consenso utente a terze parti — in Entra ID, Enterprise applications → Consent and permissions → User consent settings, impostare Do not allow user consent. Abbinare l’Admin consent workflow per non bloccare le app legittime.
• 2Conditional Access — richiede Entra ID Premium P1. Policy essenziali: blocco degli accessi da paesi non whitelist, MFA obbligatoria per IP esterni, blocco del Device Code Flow per utenti che non ne hanno bisogno, blocco dei client legacy.
• 3Token Lifetime Policy — ridurre la durata degli access token a 1 ora (default: 60–90 minuti ma rinnovabili senza limite). Così l’attaccante deve ri-autenticarsi continuamente e la finestra di accesso post-compromissione si restringe.
• 4Defender for Office 365 Plan 2 — Safe Links analizza in sandbox i link prima del click, Safe Attachments fa detonation degli allegati. I preset Standard o Strict abilitano decine di protezioni anti-phishing in un click. Email Security Gateway ACN aggiunge un ulteriore livello a monte di Microsoft.
• 5Bloccare il forwarding automatico esterno — nella policy antispam outbound di Exchange Online, impostare Automatic forwarding = Off. Impedisce che un attaccante esfiltri email tramite regole di inoltro verso domini esterni.
• 6Account admin dedicati, senza mailbox — i Global Administrator devono essere account amministrativi separati da quelli di lavoro. Se il Consent Phishing colpisce un account ordinario, il danno non include il controllo del tenant.
• 7Formazione sul riconoscimento del consent screen — la schermata di consenso Microsoft è autentica e indistinguibile da un accesso legittimo. Gli utenti devono sapere che esiste e devono leggere i permessi richiesti prima di cliccare Accetta.

Monitoraggio: cosa cercare nei log

Il Purview Unified Audit Log di Microsoft 365 registra tutti gli eventi rilevanti anche sul piano base, con retention di 90 giorni. Gli eventi da monitorare sono:

• Consent to application — ogni volta che un utente autorizza un’app OAuth. Un consenso dato a un editor sconosciuto, con scope elevati, è il segnale più chiaro.
• New-InboxRule da IP estero — le regole di inoltro o cancellazione con nomi offuscati (sequenze di punti o caratteri non alfabetici) sono una firma tipica degli attacchi BEC post-compromissione.
• UserLoggedIn da paesi inattesi — sessioni attive da IP in paesi dove l’azienda non ha operatività, soprattutto se ripetute ogni poche ore (pattern di script automatizzato).
• SoftDelete e HardDelete — eliminazione massiva di email è tipica della fase di copertura tracce.

Il log da solo non basta: serve un alerting in tempo reale. Anche una regola semplice in Microsoft Sentinel, o una notifica automatica sugli eventi critici, abbassa il tempo medio di rilevamento da settimane a ore.

Supporto operativo

AtWorkStudio gestisce tenant Microsoft 365 per PMI e Pubblica Amministrazione dal 2000, da Piacenza. Siamo certificati ISO/IEC 27001, 27017, 27018 e ISO 9001, con qualificazione ACN QC1 per tre servizi del Catalogo Cloud PA tra cui l’Email Security Gateway e il backup immutabile di Microsoft 365. Siamo membri di Clusit (Associazione Italiana per la Sicurezza Informatica) e associati a Confindustria Piacenza nel cluster RICT.

Se il vostro tenant Microsoft 365 non è stato irrobustito contro l’OAuth Consent Phishing, possiamo eseguire un audit mirato: inventario dei grant OAuth attivi, verifica delle User consent settings, analisi delle policy di Conditional Access, controllo del forwarding outbound, revisione della configurazione Defender for Office 365 e piano di remediation graduale senza interruzioni di servizio.