OAuth weaponizzato: governo e PA reindirizzati a malware

OAuth weaponizzato: governo e PA reindirizzati a malware

Un link che punta a login.microsoftonline.com può consegnare il tuo endpoint a un attaccante senza rubare token né credenziali: non è un bug, ma il funzionamento previsto da OAuth 2.0.

Gli attaccanti stanno già usando questo meccanismo per spingere governi e pubbliche amministrazioni verso siti controllati e payload multi-stadio, con attività pre-ransom osservate sul campo.

"The attacker does not obtain the user’s access token, as the sign-in fails with error code 65001, indicating the user has not granted the application permission to access the resource."

Come un errore OAuth diventa un tunnel verso l'attaccante

Il meccanismo si appoggia all'endpoint di autorizzazione OAuth 2.0. L'attaccante registra un'applicazione con un redirect_uri sotto proprio controllo, quindi distribuisce link che sembrano portare a login.microsoftonline.com. All'interno dell'URL, parametri come response_type=code e prompt=none richiedono un'autenticazione silenziosa, mentre uno scope deliberatamente invalido rende l'operazione impossibile.

Per specifica del protocollo, l'identity provider deve comunque redirigere il browser verso l'URI registrato, allegando i parametri di errore e lo stato della sessione. La vittima finisce così su un dominio ostile senza che sia avvenuta una compromissione del token. Da quel punto, il sito controllato dall'attaccante può spingere il download automatico di archivi ZIP contenenti file LNK e loader HTML smuggling, innescando la catena di esecuzione locale.

Il risultato è un attacco che bypassa la prima linea di difesa senza necessità di credenziali rubate, exploit del browser o compromissione preliminare della posta elettronica. Basta che l'utente clicchi un link apparentemente innocuo e gestito da un identity provider affidabile per innescare la catena.

Questa campagna non è un classico attacco consent phishing OAuth, in cui l'utente concede autonomamente permessi a un'app malevola. Qui l'applicazione è già registrata o compromessa dall'attaccante e l'utente viene spinto verso il redirect_uri senza che venga rubato alcun token, poiché la login fallisce con errore 65001.

L'ingegneria sociale dietro le esche: firme digitali e allegati .ics

Microsoft ha osservato che le esche di phishing adottano temi di e-firma, sicurezza sociale, finanza e politica. In alcuni casi, il link dannoso è stato inserito all'interno di documenti PDF o accompagnato da allegati .ics falsi, spedizioni che imitano comunicazioni istituzionali. La scelta dei target non è casuale: le campagne prendono di mira esplicitamente organizzazioni governative e del settore pubblico, sfruttando la familiarità di quegli utenti con procedure amministrative digitali.

La scelta di nascondere il link in PDF o in calendari .ics falsi suggerisce un'attenzione particolare ai flussi di lavoro quotidiani dei dipendenti pubblici, che ricevono costantemente convocazioni, moduli e avvisi istituzionali. Questa familiarità riduce la soglia di attenzione e posticipa la verifica della destinazione reale del link.

Dal link malevolo al DLL side-loading: la catena del payload

Una volta attivato, il download conduce a un archivio ZIP che contiene file LNK e loader HTML smuggling. Il file LNK esegue comandi PowerShell per ricognizione locale, come ipconfig /all e tasklist, raccogliendo informazioni preliminari sul sistema compromesso.

In sequenza, la catena estrae steam_monitor.exe, crashhandler.dll e crashlog.dat, sfruttando un classico DLL side-loading: l'eseguibile legittimo carica la libreria malevola, che decripta crashlog.dat ed esegue il payload in memoria. Da quel momento, i ricercatori hanno osservato attività hands-on-keyboard e segnali pre-ransomware, indicando che la compromissione endpoint è solo il preludio a manovre successive.

Perché i filtri anti-phishing non bastano più

Il problema fondamentale è che l'URL mostrato nella barra degli indirizzi appartiene a un dominio legittimo e altamente fidato, come login.microsoftonline.com. I filtri anti-phishing tradizionali si basano spesso sulla reputazione del dominio e non analizzano il flusso di reindirizzamento interno al protocollo OAuth 2.0. L'utente, abituato ai flussi SSO aziendali, non percepisce anomalie fino al passaggio sul sito controllato dall'attaccante, quando il download del payload è già iniziato.

I Secure Email Gateway e i filtri URL aziendali ispezionano il link ricevuto via mail, ma non eseguono l'inspect del flusso di reindirizzamento OAuth gestito dal browser.

Una volta che l'identity provider emette il redirect verso il redirect_uri malevolo, il controllo è fuori dalla visibilità del gateway.

Per i SOC, indicatore comportamentale chiave è la sequenza in cui un errore OAuth con codice 65001 o interaction_required è immediatamente seguito da download automatico di archivi ZIP contenenti file LNK o coppie eseguibile/DLL come steam_monitor.exe e crashhandler.dll.

Per le difese tradizionali, questo rappresenta un salto di paradigma: il pericolo non arriva più da un dominio compromesso o spoofato, ma da un percorso legittimo dentro un'infrastruttura cloud fidata. La consapevolezza che anche login.microsoftonline.com possa fungere da ponte verso siti ostili deve diventare un pilastro dei nuovi modelli di threat modeling aziendale.

Microsoft Entra ha disabilitato le applicazioni OAuth malevole identificate, ma attività correlate persistono e richiedono monitoraggio continuo.

Cosa fare adesso

• Ispezionare i redirect_uri: verificare le applicazioni OAuth registrate in Microsoft Entra con endpoint di reindirizzamento esterni o anomali, seguendo l'azione di disabilitazione già intrapresa da Microsoft per le app malevole identificate.
• Monitorare gli errori OAuth: analizzare i log di autenticazione alla ricerca di errori 65001 o interaction_required associati a scope invalidi e redirect verso domini non aziendali, che possono tradire il passaggio forzato su infrastrutture ostili.
• Correlare errore e download endpoint: istruire i SOC a segnalare ogni sequenza in cui un flusso di errore OAuth verso redirect_uri sconosciuti precede il download di ZIP con file LNK o coppie come steam_monitor.exe e crashhandler.dll.
• Controllare i download automatici: allertare gli endpoint security team sulla comparsa di archivi ZIP contenenti file LNK o coppie di file come steam_monitor.exe e crashhandler.dll, indicatori noti della catena di infection.
• Ridurre la fiducia implicita nei link Microsoft: aggiornare le procedure di security awareness per segnalare che anche URL con domini OAuth legittimi possono nascondere reindirizzamenti pericolosi, specialmente in mail su e-firma o sicurezza sociale.

L'abuso del reindirizzamento OAuth mostra come i protocolli di autenticazione moderni, nati per semplificare l'accesso, possano essere invertiti in vettori di ingegneria sociale avanzata. Finché la specifica considera legittimo il redirect dell'errore, la linea di difesa non può più affidarsi solo alla reputazione del dominio, ma deve spostarsi sul monitoraggio del flusso e sul comportamento degli endpoint. Per le amministrazioni pubbliche, il messaggio è che la fiducia cieca nei flussi SSO aziendali è diventata un rischio operativo misurabile.

Nota editoriale: analisi basata sul rapporto Microsoft Security Blog; valutare l'orientamento commerciale delle raccomandazioni che citano strumenti proprietari.

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti

• https://www.microsoft.com/en-us/security/blog/2026/03/02/oauth-redirection-abuse-enables-phishing-malware-delivery/
• https://www.goodwinlaw.com/en/insights/publications/2025/10/alerts-practices-dpc-beyond-the-perimeter-securing-oauth-tokens