Attacchi OAuth attivi su Entra ID: governo nel mirino
Microsoft segnala campagne di phishing che usano OAuth 2.0 per colpire enti pubblici con malware multi-stadio, eludendo i filtri sulla reputazione.
Contenuto
Il 2 marzo 2026 Microsoft ha reso pubblica una campagna attiva di phishing e malware delivery che sfrutta i meccanismi legittimi di reindirizzamento OAuth 2.0 in Entra ID e Google Workspace per colpire organizzazioni governative e del settore pubblico. Gli attaccanti non rubano token né credenziali: usano domini fidati dei provider di identità per nascondere la prima fase dell'attacco, rendendo il rilevamento quasi invisibile ai filtri email e ai browser. La posta in gioco è immediata perché il flusso di autenticazione, percepito come sicuro, diventa un launcher silenzioso per payload multi-stadio.
- Gli attaccanti creano applicazioni OAuth malevole in tenant controllati e configurano redirect URI verso domini malevoli, sfruttando parametri crafted come
prompt=noneescopeinvalido per forzare il redirect senza interazione visibile. - L'URL iniziale appare benigno perché ospitato su domini legittimi dei provider di identità, bypassando le difese basate sulla reputazione dei domini senza necessità di rubare token OAuth.
- Dopo il redirect, alcune campagne distribuiscono automaticamente archivi ZIP contenenti file LNK che avviano PowerShell per ricognizione di rete ed estraggono
steam_monitor.exe,crashhandler.dllecrashlog.dat. - L'esecuzione prosegue con DLL side-loading: l'eseguibile legittimo carica la DLL malevola, che decifra
crashlog.dated esegue il payload in memoria per stabilire una connessione C2, con attività hands-on-keyboard osservate.
Il trucco del redirect_uri: domini fidati, destinazione malevola
Secondo Microsoft, la campagna si basa sull'esploitation by-design dei reindirizzamenti OAuth 2.0. Gli attaccanti registrano un'applicazione OAuth all'interno di un tenant che controllano e configurano un redirect_uri che punta a un dominio sotto il loro controllo. La fase iniziale del phishing invia alla vittima un link che sembra un'autenticazione standard perché risiede su login.microsoftonline.com o sui domini di Google Workspace.
La richiesta include parametri crafted: prompt=none impedisce il rendering dell'interfaccia utente, mentre uno scope invalido garantisce il fallimento della richiesta. Entra ID o Google restituiscono un errore e redirigono il browser verso l'indirizzo dell'attaccante, trasportando parametri di errore che legittimano il passaggio. Il browser esegue il redirect silenzioso e la vittima finisce su una landing page controllata, con la percezione di aver interagito con un servizio autentico.
Come l'errore OAuth si trasforma in consegna di payload
Una volta atterrati sulla pagina malevola, il follow-on activity può attivarsi senza ulteriori sollecitazioni visibili. Alcune varianti della campagna distribuiscono automaticamente un archivio ZIP che contiene un file con estensione .LNK, progettato per sembrare un documento o un report. L'utente che lo apre innesca una catena eseguita in memoria e sul disco locale.
Il file LNK avvia PowerShell per svolgere ricognizione di rete, eseguendo comandi come ipconfig e tasklist per mappare l'ambiente. Nella stessa sequenza, lo script estrae tre componenti: steam_monitor.exe, crashhandler.dll e crashlog.dat. L'eseguibile è un binario legittimo che, quando lanciato, cerca una DLL con il nome previsto. Gli attaccanti sfruttano questa logica per il side-loading: crashhandler.dll è la versione malevola, che decifra il contenuto di crashlog.dat e porta il payload finale in esecuzione in memoria.
"Extraction of the ZIP archive confirmed PowerShell execution, DLL side-loading, and pre-ransom or hands-on-keyboard activity." — Microsoft Security Blog
Il payload stabilisce quindi una connessione verso un endpoint di comando e controllo esterno. Microsoft segnala che, in alcuni casi, l'attività successiva include manovre hands-on-keyboard, indicando la presenza di operatori umani che interagiscono direttamente con gli endpoint compromessi. La natura multi-stadio dell'infezione rende difficile l'intercettazione da parte degli antivirus basati solo su firme, perché ogni singolo componente può apparire benigno se analizzato isolatamente.
Perché i filtri email e i browser non rilevano il passaggio
La tecnica è efficace perché sfrutta una caratteristica architetturale del protocollo, non una vulnerabilità software correttibile con una patch. Il link inviato per email risiede su un dominio di massima reputazione: non è un typo squatting né un dominio appena registrato. I filtri di sicurezza che si affidano alla reputazione del dominio o a liste di URL malevoli non hanno motivo di bloccare un indirizzo che inizia con https://login.microsoftonline.com.
Il redirect avviene nel flusso di errore, non in un iframe o in un redirect aperto banale. Dal punto di vista dell'utente, il browser ha appena contattato Microsoft o Google; il passaggio successivo a un dominio sconosciuto può passare inosservato o essere percepito come parte del normale workflow di autenticazione. L'assenza di un token rubato semplifica ulteriormente l'operazione: gli attaccanti non devono esfiltrare segreti né mantenere una presenza persistente nel provider di identità, ma devono solo indurre la vittima a seguire il flusso.
Cosa fare adesso
Microsoft Entra ha disabilitato le applicazioni malevole osservate nella campagna, ma segnala che attività correlate persistono e richiedono monitoraggio continuo. Le organizzazioni, in particolare quelle governative e pubbliche, devono agire su più livelli per ridurre la superficie di attacco esposta agli abusi del redirect OAuth.
- Audit dei redirect URI: verificare ogni applicazione OAuth registrata nei tenant Entra ID e Google Workspace per assicurarsi che i redirect_uri puntino esclusivamente a domini corporate noti e non controllati da terze.
- Monitoraggio dei parametri anomali: analizzare i log di autenticazione alla ricerca di richieste con
prompt=noneabbinato a scope invalidi o errati che generino errori di redirect, specialmente verso domini esterni non catalogati. - Ispezione degli endpoint: controllare la presenza di file LNK sospetti, processi PowerShell non autorizzati che eseguono ricognizione di rete, e coppie di file come steam_monitor.exe con crashhandler.dll non firmati o in percorsi insoliti.
- Revisione del consenso alle app: limitare la possibilità per gli utenti standard di concedere il consenso ad applicazioni OAuth non verificate e attivare policy che richiedano l'approvazione amministrativa per ogni nuova registrazione di app con permessi di reindirizzamento.
Queste azioni non eliminano il rischio strutturale, ma restringono gli spazi in cui gli attaccanti possono registrare app malevole e riducono la probabilità che un redirect silenzioso porti a una compromissione hands-on-keyboard.
Perché il settore pubblico è nel mirino e cosa cambia
Le vittime identificate da Microsoft appartengono prevalentemente al settore governativo e pubblico. Questo targeting non è casuale: gli enti statali gestiscono tenant eterogenei, spesso con app legacy e workflow di autenticazione complessi che espongono redirect_uri ampi o poco controllati. La fiducia implicita che gli utenti pubblici ripongono nei link aziendali e governativi amplifica il tasso di successo del phishing.
L'impatto concreto si misura sulla capacità degli attaccanti di passare dal primo click a una sessione interattiva su endpoint sensibili. Il percorso OAuth non è più solo un vettore di furto di credenziali, ma un launcher per l'esecuzione di codice remoto. Questo sposta il perimetro della difesa dal semplice blocco dei link sospetti alla necessità di monitorare l'intera catena di esecuzione post-redirect, compreso il comportamento in memoria dei processi caricati tramite side-loading. Le difese endpoint devono quindi integrare il monitoraggio dei processi figli di PowerShell e delle DLL caricate da eseguibili apparentemente innocui.
La campagna del 2 marzo dimostra che i protocolli di fiducia possono essere riadattati in armi di prima intrusione senza bisogno di compromettere il provider stesso. Finché il reindirizzamento OAuth rimane una funzione legittima e necessaria, la linea di demarcazione tra autenticazione sicura e compromissione dipenderà sempre più dal controllo granulare dei tenant e dalla visibilità sui log di errore. Per le organizzazioni pubbliche, il problema non è più solo educare l'utente a non cliccare, ma garantire che un click anche su un link tecnicamente genuino non finisca per caricare una DLL malevola in memoria.
Domande frequenti
Gli attaccanti rubano token o credenziali con questa tecnica?
No. Secondo il report Microsoft, la campagna non mira al furto di token OAuth né di credenziali. L'abuso è limitato al reindirizzamento verso una landing page malevola sfruttando il flusso di errore del protocollo.
Perché i filtri email non bloccano questi link?
Perché l'URL iniziale è ospitato su domini legittimi e di massima reputazione come quelli di Entra ID o Google Workspace. Il redirect avviene successivamente, nel flusso di errore OAuth, sfuggendo ai controlli basati sulla reputazione del dominio iniziale.
L'utilizzo del nome steam_monitor.exe indica una compromissione di Steam o Valve?
No. Il file è solo un componente usato dagli attaccanti per mascherare il DLL side-loading. Non esiste alcuna evidenza che Valve o la piattaforma Steam siano stati coinvolti o compromessi nella campagna.
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.