Phishing governativo: abusano OAuth per consegnare malware
Microsoft ha rilevato campagne attive che sfruttano il reindirizzamento OAuth per colpire governo e PA con malware multi-stadio, senza rubare token
Contenuto
In un recente rapporto tecnico, Microsoft ha analizzato campagne di phishing attive che abusano dei meccanismi legittimi di reindirizzamento OAuth per colpire organizzazioni governative e del settore pubblico.
Gli attaccanti non rubano token di accesso: secondo quanto osservato da Microsoft, sfruttano il flusso di errore by-design di Entra ID e Google Workspace per reindirizzare la vittima verso pagine malevole. Da lì inizia la consegna di un payload multi-stadio che porta al compromesso dell'endpoint.
Il paradosso, già nella fase iniziale, è che il link appare ospitato su domini autentici e affidabili: il reindirizzamento by-design del protocollo trasforma un endpoint legittimo in un ponte verso l’infrastruttura malevola, rendendo inefficaci i tradizionali filtri anti-phishing basati sulla reputazione del dominio.
- Le campagne osservate da Microsoft prendono di mira il settore pubblico e governativo, sfruttando il reindirizzamento OAuth su domini trusted: il codice 65001 di Entra ID conferma che il token di accesso non viene sottratto.
- Gli attaccanti registrano un'applicazione OAuth in un tenant controllato e usano la combinazione di prompt=none e scope non valido per forzare un redirect silenzioso verso infrastrutture malevole.
- Dopo il redirect, il payload può includere file ZIP con shortcut LNK malevoli, ricognizione PowerShell, DLL side-loading tramite steam_monitor.exe e connessione a un server C2.
- Microsoft ha disabilitato le applicazioni osservate, ma segnala che attività correlate persistono: la difesa richiede ora il monitoraggio del comportamento dei redirect e non solo della reputazione del dominio.
Il meccanismo del flusso di errore: come si trasforma OAuth in un ponte per il malware
Microsoft ha osservato attacchi che registrano un'applicazione OAuth all'interno di un tenant controllato dall'attaccante, configurando un redirect URI che punta a un dominio malevolo. I link di phishing distribuiti via email adottano temi istituzionali come richieste di firma elettronica, sicurezza sociale, finanza e politica, aumentando la probabilità di interazione da parte dei dipendenti pubblici.
Secondo l’analisi di Microsoft, il nucleo dell’abuso risiede nella manipolazione dei parametri dell’endpoint di autorizzazione OAuth 2.0. Nei campioni osservati, gli attaccanti inseriscono prompt=none e uno scope intenzionalmente non valido per obbligare l’identity provider a valutare lo stato della sessione utente senza mostrare alcuna interfaccia grafica. Se la sessione non è valida o lo scope è errato, il provider restituisce un errore silenzioso, ma esegue comunque il reindirizzamento verso l’URI controllato dall’aggressore. L’autenticazione legittima diventa così un tunnel invisibile verso l’infrastruttura malevola.
Microsoft segnala che, in questo scenario, il codice di errore 65001 di Entra ID conferma che il consenso non è stato concesso e che il token di accesso non viene rilasciato né rubato. Tuttavia, il redirect avviene ugualmente, permettendo all’attaccante di ricevere la richiesta e proseguire con la compromissione. Sempre secondo quanto rilevato, il parametro state viene riutilizzato per trasportare l’indirizzo email della vittima, tramite tecniche di encoding, fino alla landing page malevola, dove il server dell’aggressore può profilare il bersaglio prima di servire il payload.
L’abuso osservato non è circoscritto a Microsoft Entra ID. Nel rapporto, Microsoft segnala che il flusso di errore analizzato rientra nello standard OAuth 2.0 e risulta applicabile anche a Google Workspace, amplificando la superficie di rischio oltre il solo ecosistema Azure.
Dal click al C2: la catena multi-stadio del payload osservato
Una volta reindirizzato, l'utente finisce su una landing page che avvia il download automatico di un archivio ZIP. L'estrazione del file conferma la presenza di shortcut LNK malevoli e di un loader basato su HTML smuggling, tecniche entrambe orientate a eludere i controlli di sicurezza perimetrali e a eseguire codice iniziale sulla workstation. La scelta del formato compresso e dello shortcut sfrutta la familiarità dell’utente con gli allegati documentali, mascherando l’esecuzione di comandi malevoli.
L'esecuzione dello shortcut innesca uno script PowerShell dedicato alla ricognizione del sistema locale. Successivamente, il payload lancia steam_monitor.exe, un eseguibile legittimo utilizzato per il side-loading di crashhandler.dll, una libreria di sistema alterata che funge da veicolo per il codice finale.
La DLL side-loaded decodifica il contenuto di crashlog.dat, un file dati che nasconde il vero payload, e stabilisce una connessione verso un server di comando e controllo esterno. Durante questa fase, i ricercatori hanno rilevato attività pre-ransom o hands-on-keyboard, indicando che l'obiettivo finale includeva la preparazione del terreno per successive azioni intrusive. La natura modulare della catena suggerisce che gli attaccanti possano adattare il payload finale in base al profilo della vittima e alla sua posizione all’interno della rete istituzionale.
"The activity targets government and public-sector organizations and uses silent OAuth authentication flows and intentionally invalid scopes to redirect victims to attacker-controlled infrastructure without stealing tokens." — Microsoft Security Blog
Perché i filtri email e browser non bastano più
I tradizionali sistemi di difesa si affidano in larga parte alla reputazione del dominio per bloccare il phishing. Quando il link originale risiede su login.microsoftonline.com o su un endpoint analogo di Google, i filtri aziendali, i browser e gli utenti tendono a considerarlo intrinsecamente sicuro, aprendo una breccia logica difficile da colmare con le blacklist.
Il problema è ulteriormente accentuato dal fatto che l'attacco non comporta il furto del token di accesso. Di conseguenza, i sistemi di rilevamento delle anomalie di autenticazione non registrano accessi illeciti né modifiche sospette alle sessioni utente, lasciando il follow-on compromise privo di quegli indicatori di compromissione che solitamente aiutano i team di sicurezza a reagire tempestivamente. L’assenza di un token rubato rende inoltre vano ogni controllo post-autenticazione basato su geolocalizzazione o velocità dell’accesso.
Alcuni actor hanno inoltre utilizzato strumenti preconfezionati gratuiti e soluzioni custom sviluppate in Python o Node.js per l'invio massivo delle email, sfruttando una commoditizzazione dell'infrastruttura offensiva che riduce il tempo tra la registrazione dell'app OAuth e il primo click della vittima.
Dal punto di vista della threat intelligence, la singolarità del report Microsoft risiede nel dimostrare che un protocollo standard può essere convertito in canale di distribuzione malware senza alcuna vulnerabilità zero-day, spostando l’onere della difesa dalla reputazione del dominio all’ispezione del flusso.
Cosa fare adesso
La risposta difensiva non può limitarsi all'aggiornamento di firme antimalware o alla consapevolezza utente sui link sospetti, perché il dominio di partenza è autentico e il flusso apparentemente conforme. Le organizzazioni devono spostare il controllo dal dominio al flusso, monitorando parametri comportamentali specifici e adottando una lettura più granulare degli eventi di autenticazione.
Monitorare i redirect URI nelle applicazioni OAuth registrate nei tenant aziendali e governativi, verificando che puntino esclusivamente a domini di proprietà dell'organizzazione e revocando immediatamente le configurazioni anomale.
Ispezionare i log di autenticazione alla ricerca di richieste che combinino prompt=none con scope non validi o non riconosciuti, poiché questa coppia di parametri rappresenta l'indicatore più affidabile del tentativo di forzare il redirect silenzioso.
Implementare controlli comportamentali sul browser e sul proxy aziendale per bloccare o allertare i download automatici di archivi ZIP attivati subito dopo l'accesso a pagine di autenticazione, indipendentemente dalla reputazione del dominio di primo livello.
Segmentare la rete interna e limitare i privilegi delle workstation del settore pubblico che gestiscono dati istituzionali, in modo da ridurre l'impatto del follow-on compromise qualora il payload multi-stadio riesca a eseguire ricognizione PowerShell o stabilire una connessione C2.
Il messaggio è che la fiducia cieca nei grandi provider di identità non può più sostituire la verifica del flusso completo. Quando l’infrastruttura legittima diventa un ponte invisibile per il malware, la sicurezza si sposta dal dominio al comportamento: ogni redirect meriterebbe uno scrutinio che oggi pochi sistemi sono in grado di garantire. E nel settore pubblico, dove la superficie di attacco è vasta e le risorse difensive limitate, questa scoperta suona come un campanello d’allarme difficile da ignorare.
Domande frequenti
Se il link parte da Microsoft o Google, come riconoscere il pericolo? Non è possibile affidarsi esclusivamente al dominio. L’indicatore più concreto è la presenza di parametri come prompt=none abbinato a scope non validi, oltre al redirect finale verso un indirizzo estraneo al provider di identità.
L’errore 65001 di Entra ID indica che l’attacco è fallito? No. Il codice 65001 conferma che il consenso non è stato concesso e che il token di accesso non viene rubato, ma il reindirizzamento verso l’URI controllato dall’attaccante avviene comunque: l’obiettivo del redirect è raggiunto.
Il payload confermato è ransomware? Microsoft lo descrive come attività pre-ransom o hands-on-keyboard, ovvero fasi preparatorie successive al primo compromesso. Non risulta confermata la distribuzione di ransomware vero e proprio durante le campagne osservate.
Le informazioni sono state verificate sulle fonti citate nel report tecnico di Microsoft e aggiornate al momento della pubblicazione.
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.