Microsoft lancia l’allarme: un nuovo attacco sfrutta il reindirizzamento OAuth di Entra ID e Google per diffondere phishing e malware

L’abuso reindirizzamento OAuth consente campagne di phishing e consegna malware senza rubare token di accesso, sfruttando funzionalità legittime di Microsoft Entra ID e Google Workspace. Il 2 marzo 2026 il Microsoft Security Blog descrive come i threat actor manipolano parametri come prompt=none e scope invalidi per forzare errori silenziosi e ottenere redirect automatici verso domini controllati dagli attaccanti. La tecnica aggira difese tradizionali perché utilizza domini fidati dei provider di identità e non richiede furto immediato di credenziali. Le campagne colpiscono enti governativi e organizzazioni del settore pubblico e culminano in framework di phishing come EvilProxy o nel download di ZIP con LNK, HTML smuggling, esecuzione PowerShell e side-loading di DLL.

Meccanismo tecnico dell’abuso reindirizzamento OAuth

Gli attaccanti registrano un’applicazione malevola nel proprio tenant Azure AD o Google Workspace e configurano il redirect URI verso un dominio sotto il loro controllo. Costruiscono quindi URL OAuth artigianali. Nel caso di Entra ID l’endpoint assume la forma https://login.microsoftonline.com/common/oauth2/v2.0/authorize con client_id dell’app malevola, response_type=code, uno scope intenzionalmente invalido e prompt=none. Il parametro prompt=none forza un flusso di autenticazione silenzioso, privo di interfaccia utente. Lo scope invalido garantisce il fallimento dell’autorizzazione. Quando Entra ID rileva una sessione esistente ma non può completare il flusso, restituisce un errore di tipo interaction_required. Il provider reindirizza automaticamente il browser verso il redirect URI registrato, includendo parametri di errore. Lo stesso schema funziona con Google Workspace utilizzando prompt=none, auto_signin=True e redirect_uri malevolo.

In entrambi i casi il reindirizzamento proviene da domini legittimi Microsoft o Google, quindi il browser lo considera affidabile. Questa caratteristica by-design del protocollo OAuth diventa il vettore principale per bypassare filtri URL e protezioni browser.

Catena di attacco dalla mail al comando PowerShell

La catena inizia con email di phishing che contengono direttamente l’URL OAuth oppure lo incorporano in allegati PDF privi di testo. I temi includono richieste di firma elettronica, avvisi social security, reset password, report dipendenti o inviti Teams. Alcuni messaggi contengono falsi allegati .ics per rafforzare la legittimità.

Al clic della vittima parte il flusso OAuth silenzioso. Dopo l’errore, il browser atterra sulla pagina controllata dall’attaccante. A questo punto si aprono due scenari.

Nel primo caso la vittima viene indirizzata a un framework come EvilProxy, che intercetta credenziali e cookie di sessione tramite proxy in-the-middle e CAPTCHA. Nel secondo caso il redirect porta a un percorso di tipo /download/XXXX che avvia automaticamente il download di un file ZIP.

Lo ZIP contiene file LNK che eseguono comandi PowerShell complessi. Lo script avvia una fase di reconnaissance con ipconfig /all e tasklist. Successivamente utilizza tar per estrarre un eseguibile legittimo, ad esempio steam_monitor.exe, insieme a una DLL malevola come crashhandler.dll e un file cifrato crashlog.dat. PowerShell esegue steam_monitor.exe che effettua il side-loading della DLL dalla directory corrente. La DLL decifra crashlog.dat in memoria ed esegue il payload finale, stabilendo connessioni outbound verso server C2. L’intera sequenza sfrutta binari legittimi per ridurre il rilevamento comportamentale.

Targeting su enti governativi e settore pubblico

Microsoft osserva che le campagne prendono di mira principalmente organizzazioni governative e pubbliche. Gli attori utilizzano strumenti di invio massivo gratuiti, script personalizzati in Python o Node.js e servizi email cloud. Spesso i redirect URI includono domini come powerappsportals.com per aumentare la credibilità.

Il parametro state trasporta l’indirizzo email della vittima in plaintext, esadecimale, Base64 o schemi custom, consentendo di precompilare i campi nelle pagine di phishing. Questa personalizzazione incrementa il tasso di successo, soprattutto in ambienti abituati ai flussi di autenticazione di Microsoft 365. L’uso di domini OAuth legittimi combinato con lures a tema governativo riduce la diffidenza degli utenti e rende la catena più difficile da intercettare con semplici blacklist.

Indicatori di compromissione e rilevamento con Defender

Microsoft pubblica un elenco di Client ID malevoli, tra cui 9a36eaa2-cf9d-4e50-ad3e-58c9b5c04255 e 89430f84-6c29-43f8-9b23-62871a314417 insieme ad altri identificatori. I redirect iniziali includono domini come dynamic-entry.powerappsportals.com o westsecure.powerappsportals.com, seguiti da percorsi /download/, /security/ o /auth/entry.php su domini attaccanti. Microsoft Defender XDR fornisce query di advanced hunting per individuare URL con scope invalidi o prompt=none. Sul lato endpoint i segnali includono esecuzione PowerShell con comandi tar, side-loading di crashhandler.dll da directory non di sistema e connessioni outbound immediatamente successive all’estrazione di ZIP. Il rilevamento efficace combina segnali di email, identità ed endpoint, consentendo di intercettare la catena prima della compromissione finale.

Mitigazione e monitoraggio continuo

Microsoft raccomanda di monitorare costantemente le applicazioni OAuth registrate e disabilitare immediatamente quelle sospette. Entra ID consente di revocare permessi e bloccare redirect URI non approvati. Le organizzazioni dovrebbero applicare policy di Conditional Access che limitino i flussi di silent authentication per utenti ad alto rischio. È essenziale educare gli utenti a verificare l’URL finale dopo qualsiasi redirect da domini Microsoft o Google. I team di sicurezza devono implementare query di hunting regolari per intercettare parametri come prompt=none e scope invalidi nei log di URL click. Sugli endpoint si raccomanda di bloccare download automatici da percorsi sospetti e monitorare il side-loading di DLL da directory temporanee. L’uso di Defender for Endpoint con rilevamento comportamentale aiuta a identificare il payload finale anche quando sfrutta binari legittimi.

Un’evoluzione del phishing basata su fiducia implicita

L’abuso reindirizzamento OAuth rappresenta un’evoluzione sofisticata delle tecniche di phishing. Non punta al furto immediato del token ma sfrutta l’errore di autorizzazione silenzioso come meccanismo di consegna verso domini malevoli. La fiducia implicita nei domini Microsoft e Google diventa l’elemento chiave per superare filtri e controlli superficiali. La combinazione di silent probe, error redirect e delivery tramite ZIP con side-loading DLL rende la catena particolarmente insidiosa per organizzazioni governative. Microsoft continua a disabilitare applicazioni malevole, ma gli attori ruotano rapidamente client ID e domini. Le difese moderne devono spostare l’attenzione dall’URL statico all’analisi contestuale dei flussi OAuth, integrando telemetria su identità, email ed endpoint. La consapevolezza degli utenti e il monitoraggio proattivo restano i pilastri per ridurre il rischio di compromissione in uno scenario dove il protocollo stesso, legittimo per design, viene trasformato in vettore di attacco.