La costante diffusione di strumenti di autenticazione a più fattori (MFA) resistenti alle minacce e l’affermazione progressiva delle passkey stanno trasformando l’architettura della sicurezza informatica aziendale.
Sebbene questi presidi abbiano reso estremamente complesso per i malintenzionati sottrarre credenziali nella fase di accesso, la risposta del crimine informatico non si è fatta attendere.
Si assiste, infatti, a una convergenza verso il phishing dell’autorizzazione, una metodologia che colpisce gli utenti subito dopo che si sono autenticati con successo.
Questo mutamento tattico, le sue implicazioni per le infrastrutture aziendali e le strategie necessarie per contrastarlo sono stati analizzati in un confronto tecnico tra James Wilson, intervistatore di Risky Business, e Luke Jennings, Vicepresidente della ricerca presso Push Security.
Indice degli argomenti
L’evoluzione della minaccia: dal phishing dell’autenticazione all’autorizzazione
L’implementazione delle passkey e dei protocolli di autenticazione avanzati ha ridotto i margini d’azione dei classici attacchi volti all’intercettazione di password e codici temporanei. Questo progresso ha costretto gli attaccanti a modificare il proprio raggio d’azione.
Jennings definisce chiaramente la portata di questa trasformazione: « Il “phishing dell’autorizzazione” è un termine ombrello che sto usando per riferirmi a una classe di attacchi che compromettono un’identità o un account, ma lo fanno dopo la fase di autenticazione ». In questo panorama, le passkey non offrono alcuna barriera difensiva poiché l’azione dannosa si consuma interamente a livello di autorizzazione delle applicazioni.
L’efficacia di questa tecnica risiede nell’asimmetria tra gli investimenti difensivi aziendali e i nuovi comportamenti dei malintenzionati. Jennings sottolinea questo sbilanciamento osservando come « la stragrande maggioranza dei nostri controlli e investimenti è sempre focalizzata sul lato dell’autenticazione, con un numero crescente di requisiti da soddisfare per superarla ». Allo stesso modo, i percorsi di formazione aziendale sulla sicurezza e le relative simulazioni continuano a concentrarsi sull’evitare l’inserimento di credenziali o codici MFA in form sospetti. Gli attaccanti hanno così trovato un’area completamente scoperta dai controlli tradizionali.
Le tre forme del phishing dell’autorizzazione: consent, device code e consent fix
La violazione dei sistemi post-autenticazione fa perno in gran parte sull’abuso dei flussi OAuth. Nell’ambito di questo modello d’attacco si distinguono tre varianti principali.
Il declino del consent phishing tradizionale
La forma originaria di questo vettore è rappresentata dal consent phishing. In questo schema, l’attaccante richiede l’accesso all’account della vittima tramite OAuth impiegando un’applicazione di terze parti appositamente registrata. Qualora l’utente approvi la richiesta, l’applicazione malevola ottiene un’autorizzazione programmatica via API che può risultare permanente.
Tuttavia, l’efficacia di questa specifica variante si è ridotta nel tempo. Come evidenziato da Jennings, « non si vede più il consent phishing così spesso perché sono stati implementati controlli che lo rendono un po’ più costoso da eseguire ». I fornitori di servizi cloud, come Microsoft, hanno infatti introdotto meccanismi di blocco e restrizioni che impediscono agli utenti non amministratori di approvare app esterne non verificate.
L’esplosione del device code phishing
La variante che ha registrato un incremento significativo negli attacchi recenti è il device code phishing. Questo metodo sfrutta il device code flow di OAuth, un meccanismo originariamente concepito per consentire l’accesso da dispositivi privi di tastiera agevole, come smart TV o sistemi per sale conferenze VoIP, ma ormai integrato diffusamente anche negli strumenti per sviluppatori, nelle interfacce a riga di comando come PowerShell o Azure CLI e negli ambienti di sviluppo integrati (IDE).
La caratteristica che rende questa tecnica particolarmente pericolosa risiede nell‘impersonificazione di applicazioni di prima parte (first-party applications). Jennings evidenzia la differenza sostanziale: « La differenza fondamentale, però, è che invece di registrare un’applicazione di terze parti (che potrebbe essere controllata e bloccata), l’attaccante impersona solitamente applicazioni di prima parte ». Trattandosi di applicazioni native di fornitori come Microsoft o GitHub, esse risultano pre-approvate all’interno dei tenant aziendali e i vendor non possono bloccarle senza compromettere l’operatività generale.
La dinamica dell’attacco
L’attacco si sviluppa attraverso passaggi lineare e apparentemente innocui:
- La vittima riceve una comunicazione di phishing contenente l’esca, spesso strutturata come la notifica di un documento protetto o la verifica dell’account necessaria per accedere a una risorsa condivisa.
- Alla vittima viene presentato un codice generato dall’attaccante e un pulsante che apre una finestra pop-up verso l’URL ufficiale di autenticazione (ad esempio login.microsoft.com).
- Trovandosi su un dominio assolutamente legittimo e risultando già autenticata tramite la propria passkey o sistema MFA, la vittima incolla il codice e conferma l’operazione.
Conclusa questa procedura, la compromissione dell’account è completa. Trattandosi di client pubblici che non possono custodire segreti in modo sicuro, l’attaccante ottiene token di accesso e refresh token OAuth a lungo termine. Se l’applicazione emulata è un’app di prima parte come Microsoft Teams, l’attaccante acquisisce il potere di interrogare le API di Microsoft Graph, accedendo a e-mail, messaggi interni e file condivisi attraverso un accesso non interattivo di lunga durata.
La sfida del consent fix
Una variante ancora più sofisticata è rappresentata dal consent fix. Qui, la vittima viene indotta con l’inganno a copiare e incollare una porzione dell’URL contenente il token di concessione OAuth valido.
L’insidia di questo metodo è spiegata da Jennings: « Di fatto si induce la vittima a copiare e incollare un codice OAuth valido e poi lo si utilizza; questo lo rende estremamente difficile da bloccare ». Poiché ogni singolo passaggio del processo corrisponde a un’azione di autenticazione e autorizzazione legittima, le regole tradizionali di protezione faticano a rilevare l’anomalia. Nata come tecnica mirata impiegata in attacchi circoscritti, la vendita dei relativi kit nel mercato nero ne prefigura una diffusione su più ampia scala.
Le criticità gestionali e i limiti dei controlli tradizionali
Di fronte al dilagare del phishing basato su device code, la soluzione immediata potrebbe sembrare la disattivazione totale del relativo flusso di autenticazione all’interno dell’organizzazione. Tuttavia, Wilson e Jennings evidenziano come la gestione di questa misura sia complessa nelle strutture aziendali strutturate.
La funzionalità risulta abilitata di default da molteplici fornitori di servizi. Se da un lato l’accesso da dispositivi secondari come le smart TV potrebbe non essere prioritario in ambito aziendale, dall’altro il device code flow è divenuto parte integrante dei flussi di lavoro tecnici e degli strumenti di amministrazione cloud. Spegnere indistintamente questa opzione senza una mappatura preventiva rischia di interrompere processi operativi essenziali. Inoltre, anche qualora un’azienda riesca a blindare le policy di accesso condizionato sul proprio tenant principale, l’attacco potrebbe essere reindirizzato verso piattaforme terze ma collegate, come GitHub, dove il flusso OAuth viene gestito in modo separato.
Le strategie di difesa per i team di sicurezza aziendali
Il contrasto al phishing dell’autorizzazione richiede un aggiornamento delle metodologie di difesa, superando la dipendenza esclusiva dai controlli statici di autenticazione.
L’efficacia del purple teaming e della simulazione reale
La corretta impostazione della sicurezza aziendale non può prescindere da una verifica sul campo. Jennings sottolinea che « la cosa più importante di fronte a questi attacchi sia iniziare a fare “purple teaming” nei propri ambienti aziendali per provarli concretamente ». Le policy di accesso condizionato possono presentare articolazioni complesse e solo attraverso simulazioni d’attacco controllate è possibile verificare se le regole impostate stiano funzionando come previsto e se i sistemi SIEM ed EDR in uso siano in grado di tracciare la generazione anomala dei token.
Riorientare la formazione aziendale
Anche i programmi di security awareness training devono adattarsi a queste nuove dinamiche. Chiedere continuamente ai dipendenti di prestare attenzione all’inserimento della password genera assuefazione, trattandosi di un’azione che gli utenti compiono quotidianamente per accedere ai propri strumenti di lavoro.
Al contrario, l’interazione con un device code flow o la richiesta di inserimento di codici estranei al classico login costituiscono eventi insoliti per la maggior parte dell’organico aziendale. Se gli utenti vengono addestrati a riconoscere specificamente questi meccanismi autorizzativi anomali durante le simulazioni di phishing, la probabilità che identifichino e segnalino l’attacco reale aumenta in modo significativo.
Il browser come perimetro critico di rilevamento
Poiché l’intero ciclo di vita del phishing dell’autorizzazione si sviluppa all’interno della sessione di navigazione dell’utente, la visibilità a livello di browser rappresenta la frontiera difensiva determinante. I proxy di rete e i firewall tradizionali incontrano limiti strutturali nell’analisi di questo traffico, in quanto non hanno visibilità sul codice JavaScript che viene eseguito e decifrato direttamente nel client.
Un’estensione di sicurezza per il browser (Browser EDR) opera analizzando la telemetria profonda dell’interfaccia utente. Questo permette di monitorare gli eventi a livello di Document Object Model (DOM), rilevando azioni quali l’interazione con campi specifici o il copia-incolla di stringhe e token dalla barra degli indirizzi, come avviene nel consent fix.
Jennings traccia un parallelo storico per spiegare questa necessità tecnologica: « Finora il browser è stato una specie di scatola nera. Un tempo valeva lo stesso per l’endpoint prima dell’avvento degli EDR: l’endpoint era una scatola nera per il rilevamento, poi abbiamo creato gli EDR perché gli attacchi agli endpoint erano diventati comunissimi. Ora sta accadendo la stessa cosa con il browser: gli attaccanti si sono spostati lì, e non possiamo più permetterci di considerarlo una scatola nera; dobbiamo avere una visibilità profonda ». Intercettare la minaccia direttamente nel browser consente di bloccare il sito malevolo prima che l’utente possa completare l’autorizzazione e cedere il controllo delle proprie sessioni applicative.
Partecipa alla community