• Cloud, Microsoft 365, Sicurezza
• 26 Gennaio 2026

In questo mese (gennaio 2026) lo YouTuber italiano Andrea Galeazzi, noto per le recensioni tech, ha subito il furto del suo account Google e dei suoi canali YouTube a causa di un attacco informatico. Gli hacker sono riusciti a prendere il controllo totale del suo profilo nel giro di pochi secondi, nonostante Galeazzi avesse attiva l’autenticazione a due fattori (2FA). Questo caso clamoroso dimostra come una e-mail di phishing ben congegnata (in questo caso realizzata con l’aiuto dell’intelligenza artificiale) e un falso meccanismo di autorizzazione OAuth possano ingannare anche utenti esperti, aggirando le difese tradizionali come la 2FA.

Cos’è successo e come hanno hackerato Andrea Galeazzi

Il canale YouTube di Galeazzi è stato repentinamente trasformato in una vetrina per truffe su Bitcoin, con nome, immagini e video del canale sostituiti da contenuti fraudolenti. Galeazzi ha rivelato di essere stato ingannato da un’email di phishing estremamente credibile, ricevuta da quello che sembrava un brand di microfoni con cui aveva collaborato in passato. Nel messaggio c’era scritto che volevano inviargli nuovi prodotti da provare, una richiesta che per lui rientra nella routine lavorativa (ogni mese riceve decine di offerte simili). Proprio per questa sua familiarità con mail di collaborazione, Galeazzi ammette di aver abbassato la guardia: in quell’email “sembrava tutto legittimo” e l’ha convinto a cliccare sul link ricevuto senza particolari cautele.

Seguendo le istruzioni comunicate, Galeazzi ha eseguito una serie di passaggi di verifica del canale YouTube richiesti dagli attaccanti. In pratica, gli hacker lo hanno indotto a cliccare su un link di verifica che lo ha portato a una schermata di autenticazione Google. Credendo fosse parte della normale procedura per confermare la sua identità di proprietario del canale, Galeazzi ha inconsapevolmente concesso agli hacker i permessi di accesso al suo account Google. Nel giro di attimi, i criminali informatici hanno sfruttato tali permessi (un “token” di accesso) per modificare le credenziali dell’account, cambiando password ed e-mail di recupero, ed estrometterlo completamente.

Approfondiamo

L’incidente che ha coinvolto Andrea Galeazzi dimostra come flussi di autorizzazione delegata possano aggirare le difese tradizionali. Analoghi meccanismi sono alla base di attacchi agli account Microsoft (Azure AD/Microsoft Entra ID, Microsoft 365, OneDrive, Teams, Outlook, ecc.): l’aggressore induce l’utente a concedere permessi ad un’applicazione malevola, ottenendo un token OAuth che “sostituisce” le credenziali.

Nel flusso OAuth 2.0 standard di Microsoft, dopo che l’utente ha autorizzato un’app (cliccando “Consenti” in un consenso OAuth legittimo), questa riceve un authorization code che scambia con un access token (e, se richiesto, un refresh token).

Questi token permettono di accedere alle API dei servizi cloud di Microsoft con gli scope concessi (ad es. lettura email, file, contatti), fino alla loro scadenza o alla revoca manuale. In particolare, la presenza dello scope offline_access fa sì che venga emesso anche un refresh token, garantendo accesso persistente anche dopo la scadenza dell’access token iniziale.

I servizi Microsoft applicano i permessi delegati dell’utente (ad es. User.Read, Mail.Send, Files.ReadWrite), oppure permessi admin (tramite consenso di tenant; ovvero quando un amministratore di tenant EntraID concede l’autorizzazione ad un’applicazione affinché tutti gli utenti del tenant possano utilizzarla, senza un consenso esplicito ed individuale) per accesso a risorse come Exchange Online o Graph API.

Le app sviluppate da Microsoft (es. Azure CLI, PowerShell) sono preregistrate come first-party e hanno spesso il permesso implicito di base (openid, profile, offline_access) senza mostrare prompt di consenso. Al contrario, app di terze parti richiedono esplicita approvazione dell’utente o di un amministratore, mostrando la lista dei permessi richiesti.

Microsoft ha introdotto anche la Publisher Verification: dopo che Microsoft verifica l’identità dello sviluppatore, l’app mostra un badge blu di “Verified Publisher” nella schermata di consenso, aumentandone la fiducia.

Debolezze e attacchi basati su OAuth

Gli attacchi basati su OAuth sfruttano diverse debolezze del sistema di autorizzazione. In genere l’utente riceve una mail o un messaggio ingannevole contenente un link verso un modulo o sito apparentemente legittimo; cliccandolo si attiva un normale flusso di consenso OAuth anziché un form di login fasullo. La schermata successiva, proveniente dal trusted identity provider (Microsoft), chiede all’utente di concedere permessi all’app malevola. Poiché l’utente è già autenticato, non viene richiesto alcun fattore aggiuntivo: bastano un click su “Accedi con Microsoft” e quindi su “Consenti” per generare un access token. In sostanza l’utente sta affidando all’app la capacità di agire al suo posto sul suo account (lettura mail, file, gestione contatti, ecc.), senza mai digitare nuovamente la password o inserire un secondo fattore.

Figura 1 – Esempio di attacco

Per maggiori dettagli è possibile consultare la documentazione ufficiale Microsoft Malicious OAuth applications abuse cloud email services to spread spam | Microsoft Security Blog.

In questi attacchi l’aggressore ottiene access token e quasi sempre anche refresh token.

Un refresh token permette di rigenerare nuovi accessi anche dopo che l’access token è scaduto, garantendo accesso persistente finché la delega non viene revocata manualmente.

Questo significa che anche se la vittima si accorge subito dell’intrusione, l’attaccante può continuare a connettersi ai servizi Microsoft in background finché il refresh token non viene invalidato. Inoltre, questi metodi possono aggirare il 2FA: come spiegato nel caso Galeazzi, il token viene emesso dopo un normale login 2FA del legittimo utente; quindi, Google (o Microsoft) considera l’operazione legittima. Allo stesso modo, se la vittima è già passata dal multi-factor, il prompt OAuth non richiede fattori ulteriori.

Le tecniche note includono:

• Phishing del consenso OAuth: si usa un link malevolo che genera il flusso OAuth di MS; l’utente vede una schermata di consenso reale (con il logo Microsoft e la lista di autorizzazioni richieste) e, ritenendola legittima perché non chiede credenziali, clicca “Consenti”. L’app ottiene quindi un authorization code che scambia per token. A titolo di esempio, Microsoft ha documentato campagne in cui migliaia di account M365 sono stati compromessi in questo modo, anche da gruppi criminali organizzati. Se la vittima è un amministratore, l’app può ottenere permessi di tenant e accedere a risorse globali.
  
• Abuso di app First-party: come visto con il malware ConsentFix, gli aggressori possono sfruttare app Microsoft preregistrate (es. Azure CLI) che hanno implicitamente lo scope offline_access e non mostrano un vero prompt. L’utente viene indotto a eseguire un flusso OAuth (ad es. locale redirect) e a copiare/incollare l’URL completo con il codice nell’app malevola; quest’ultima ottiene quindi il codice e lo scambia per token. Poiché l’app è first-party, non c’è chiara indicazione di permessi aggiuntivi, e il flusso avviene in background senza ulteriori check. In pratica, l’attaccante eredita i permessi (delegati) dell’utente vittima senza che questi riceva alcun avviso esplicito.
  
• Phishing tramite codice dispositivo (Device Code Flow): alcuni strumenti (es. SquarePhish, SquarePhish2) sfruttano il flusso OAuth Device Authorization. L’utente riceve un codice (anche tramite secondo messaggio) e viene istruito a inserirlo su un sito ufficiale Microsoft, credendo si tratti di un normale controllo di sicurezza. In realtà, dopo che l’utente ha inserito il codice e autenticato, il token viene concesso all’attaccante. Proofpoint ha documentato campagne in cui un utente, invitato a “reinserire il codice di sicurezza”, concede così il token all’aggressore senza mai digitare password.
  
• Token Replay e impersonificazione: una volta in possesso del token OAuth, l’attaccante può usarlo da remoto e mantenere l’accesso indipendentemente dalla posizione o dal device dell’utente. Questo rende inefficaci molte policy basate su posizione o compliance del device. Azure AD può rilevare un accesso anomalo (ad es. IP insolito) come rischioso e generare alert, ma l’attaccante può anche nascondersi dietro servizi cloud trustati. In generale, senza una protezione specifica, il ladro rimane “dentro” finché non viene revocato il token.
  

In tutti questi scenari, l’elemento abilitante è l’ingegneria sociale. Gli attaccanti confezionano email estremamente credibili (oggi spesso con l’ausilio di AI generativa) simulando comunicazioni interne o di fornitori familiari. Galeazzi stesso spiega che gli aggressori hanno usato l’IA per analizzare i suoi interessi e creare un messaggio «con confidenza e accuratezza» tale da fargli abbassare la guardia. I dati sparsi sui social o sul web vengono raccolti da modelli AI per generare phishing mirato. Ad esempio, si crea una storia credibile dicendo «ti ricordi? Abbiamo lavorato insieme e i tuoi utenti lamentavano la qualità audio dei video», spingendo l’utente a cliccare. Il prompt di consenso OAuth, ormai ben noto e accettato come routine, è diventato un vettore fatale: molti utenti cliccano “Continua” senza esaminare i permessi. In sintesi, l’IA sta riducendo la soglia di attenzione delle vittime, rendendo le email di inganno OAuth ancora più efficaci.

Strumenti e configurazioni di sicurezza Microsoft

Per mitigare questi rischi Microsoft offre vari controlli specifici:

• App consent policies (Microsoft Entra): configurando le policy di consenso app in Azure AD, si limita quali applicazioni gli utenti possono autorizzare. Si possono permettere solo app interne o di editori verificati, o addirittura bloccare tutte le app di terze parti (da luglio 2025 Microsoft ha abilitato di default una policy gestita che proibisce il consenso di massa ad app non approvate). È possibile personalizzare le policy per specifici editori o permessi. Inoltre, le step-up consent basate su rischio bloccano automaticamente le richieste sospette (ad es. app multi-tenant senza verified publisher) forzando l’approvazione amministrativa. In pratica, agli utenti verranno mostrate avvertenze e in molti casi sarà richiesto l’intervento dell’amministratore.
  
• Conditional Access (CA): le policy CA permettono di imporre requisiti di accesso più stringenti. Ad esempio, si può bloccare ovunque (eccetto scenari specifici) il flusso device code, che, come visto, è un vettore di phishing particolarmente rischioso. Microsoft raccomanda infatti di bloccare il device code flow ove possibile. Inoltre, si possono richiedere dispositivi conformi, limitare l’accesso da reti sconosciute o datacenter pubblici, e imporre il requisito di MFA in situazioni rischiose (es. fuori sede). È possibile anche definire Authentication Context: per operazioni sensibili (ad es. cambio password, attivazione di ruoli) le regole di CA possono forzare sempre un secondo fattore o il passaggio su un dispositivo specifico. Nel caso di uso di continuous access evaluation, se viene rilevato un alto rischio (per esempio token riutilizzato su IP anomalo), Azure AD può chiedere all’utente di riautenticarsi. Infine, le CA supportano anche il “Token Protection”: una session control che lega il token rilasciato al device/sessione dell’utente, impedendo che lo stesso token venga usato da un altro computer. L’attivazione di Token Protection (licenza P1/P2) in una policy CA può quindi neutralizzare attacchi in cui l’authorization code ottenuto viene scambiato su un altro dispositivo.
  
• MFA phishing-resistant: anche se il phishing OAuth ignora la classica 2FA, è importante comunque usare metodi MFA forti. Microsoft consiglia di utilizzare soluzioni phishing-resistant (chiavi FIDO2, Windows Hello, passkey su smartphone) soprattutto per gli account amministrativi. Con le nuove authentication strengths di Entra ID, è possibile creare policy CA che richiedano specificamente un fattore hardware. Ad esempio, per i ruoli privilegiati (Global Admin, Security Admin, ecc.) si può applicare una CA che obblighi un’autenticazione phishing-resistant. Queste policy si integrano con Privileged Identity Management (PIM), che richiede MFA ogni volta che si attiva un ruolo amministrativo. In pratica, anche se l’attaccante ottenesse un token, non potrebbe usarlo per operazioni critiche senza avere la chiave fisica dell’utente.
  
• Microsoft Defender for Cloud Apps (MCAS): ex Cloud App Security, questo strumento offre funzioni di app governance. Visualizza tutte le applicazioni OAuth installate dagli utenti (inclusi permessi e deleghe concesse). Da qui l’amministratore può approvare, bloccare o limitare app sospette. Si possono creare policy per rilevare comportamenti anomali delle app (es. accesso massivo a dati sensibili), bloccarle o revocarne i token in automatico. Inoltre, Defender for Cloud Apps genera allarmi in caso di uso insolito delle sessioni (ad es. cookie riutilizzato da posizione differente) integrando log di Office 365 e Azure. In sintesi, MCAS dà visibilità “panoramica” su quali app hanno accesso ai dati aziendali e consente di interrompere tempestivamente quelle malevole.
  
• Microsoft Defender for Office 365 – Anti-Phishing: per prevenire gli attacchi via email, Defender for O365 filtra e blocca le mail di phishing OAuth prima che raggiungano gli utenti. Utilizza machine learning, reputazione URL e altre tecniche avanzate per riconoscere i messaggi sospetti (anche quelli che sembrano provenire da mittenti interni). In questo modo si riduce l’esposizione iniziale: molti tentativi di trappola OAuth sono bloccati dall’anti-phishing standard di Office 365.
  
• Entra ID Identity Protection: questo servizio valuta in tempo reale il rischio di ogni accesso o utente. Ad esempio, se viene notato un comportamento anomalo (token in replay, IP sospetto, cambio di posizione geografica impossibile), Identity Protection può marcare l’utente come high risk. A fronte di rischio elevato, è possibile applicare CA che richiedano una nuova autenticazione interattiva (ad es. richiedere il fattore aggiuntivo sempre). Si possono anche impostare remediation automatiche: blocco dell’accesso, reset password o revoca dei token se l’utente risulta compromesso. Microsoft ha rilevato che nella campagna del 2022, l’86% dei tenant compromessi aveva amministratori con score di rischio alto su Identity Protection, e nessuno di questi aveva MFA abilitato. Questo evidenzia l’importanza di monitorare i risky sign-ins e gli risky users tramite Azure AD.
  
• Privileged Identity Management (PIM): PIM abilita il least privilege rendendo temporanei i privilegi. Con PIM si definiscono periodi di assegnazione di ruoli e si richiede l’approvazione per l’attivazione. Integrazione chiave: ogni volta che si attiva un ruolo privilegiato PIM può far scattare una sfida MFA aggiuntiva. Così anche se un token OAuth ottiene i privilegi di un admin, senza attivazione esplicita del ruolo non potrà usarli. PIM consente anche di definire età massime per assegnazioni e verifica periodica, riducendo il rischio di privilegi persistenti.
  

Raccomandazioni pratiche

Per gli amministratori:

• Configurare politiche App consent che richiedano l’approvazione degli amministratori per qualsiasi nuova applicazione OAuth o che permettano solo app interne/verified. Disabilitare il consenso libero degli utenti nelle impostazioni di Entra ID, se non necessario.
  
• Implementare Conditional Access stringenti: es. bloccare il device code flow globale, richiedere MFA (preferibilmente hardware) sempre che possibile, e legare i token ai dispositivi con Token Protection. Non limitarsi alla sola password e OTP, ma usare chiavi di sicurezza fisiche (FIDO2, passkey) e richiedere questi metodi con auth strength phishing-resistant.
  
• Abilitare Defender for Cloud Apps e Office 365 Defender: impostare rilevazioni custom di app sospette, usi anomali delle API Graph, e policy anti-phishing aggressive.
  
• Monitorare i log di Entra ID e le segnalazioni di Identity Protection: agire immediatamente su segnalazioni di user risk alto (es. forzare il reset password o disabilitare l’account).
  
• Usare PIM per i ruoli, con approvazioni e MFA on-demand. Aggiungere account break-glass di emergenza per evitare lockout.
  
• Sensibilizzare gli utenti (phishing training): simulare attacchi OAuth per insegnare a leggere le schermate di consenso e a non cliccare impulsivamente.
  
• Segregazione degli account e dei doveri: consigliare agli utenti di non usare lo stesso indirizzo email per tutti i servizi. Con il principio della segregation of duty, fare lo stesso anche per specifici task. Ad esempio, usare un indirizzo “esposto” per iscrizioni e newsletter e un indirizzo “master” riservato alle autenticazioni critiche, come suggerito nel caso Galeazzi. Oppure, altro esempio, creare due account differenti: uno privilegiato da utilizzare per azioni specifiche ed uno non privilegiato da utilizzare normalmente.
  

Per gli utenti finali:

• Prestare attenzione ai messaggi di posta: diffidare di link sospetti, anche se sembrano provenire da contatti conosciuti. Non fare click su inviti OAuth inattesi.
  
• Controllare sempre l’URL della schermata di login/consenso: deve essere login.microsoftonline.com (o domini Microsoft ufficiali).
  
• Leggere i permessi richiesti dalle app prima di autorizzarle. Se uno scope appare strano rispetto al servizio (ad es. “leggi calendario” per un’app di newsletter), non procedere.
  
• Usare sempre MFA robusto: preferire chiavi hardware (FIDO2, Windows Hello) a SMS o app di autenticazione.
  
• Separare gli account: se possibile, avere account diversi per uso personale e lavorativo, e non usare l’account aziendale per servizi pubblici. In caso di dubbio, contattare il reparto IT prima di autorizzare un’app.
  
• Attiva le protezioni avanzate offerte dai provider: ad esempio Google mette a disposizione il Programma di Protezione Avanzata (Advanced Protection) per gli account più a rischio. Questo programma gratuito blocca a monte le app non verificate, impedendo la generazione di token OAuth malevoli, e richiede obbligatoriamente una chiave di sicurezza hardware per ogni nuovo accesso. In pratica, anche se un utente dovesse accidentalmente cliccare su un link di phishing, queste misure aggiuntive impedirebbero all’attaccante di completare l’attacco. Adottare strumenti come l’Advanced Protection (o analoghi per altri servizi) aggiunge un livello di sicurezza “anti-inganno” superiore rispetto alla 2FA tradizionale, spostando il controllo dall’utente (che può essere ingannato) al sistema (che applica regole ferree).
  

Su ICTPower abbiamo affrontato molte volte questi argomenti. Potete approfondire i vari temi come, ad esempio, la passwordless authentication, Windows Hello for Business, MFA, FIDO2, ecc.

Conclusioni

In conclusione, benché i flussi OAuth rappresentino un modo comodo per integrare servizi, essi possono costituire un anello debole se non adeguatamente protetti. Microsoft fornisce varie tecnologie (App consent policies, CA, Entra ID Protection, Defender, PIM, FIDO2) che, usate in combinazione e applicate correttamente, permettono di mitigare questi rischi. Tuttavia, la componente umana resta critica: l’utente deve essere consapevole dei rischi del clic distratto sulla schermata di consenso. Solo un approccio multilayer (tecnologie avanzate supportate da formazione) potrà preservare la sicurezza degli account anche davanti a sofisticate campagne di phishing OAuth.

Stay tuned.