Abuso redirect OAuth in Entra ID: phishing e malware

Introduzione: perché è importante

I link OAuth verso identity provider (IdP) noti come Microsoft Entra ID sono spesso considerati affidabili dagli utenti e, in alcuni casi, trattati con maggiore tolleranza dai controlli di sicurezza. Le più recenti ricerche di Microsoft evidenziano un comportamento di reindirizzamento OAuth “by design” sfruttato per inviare gli utenti da domini di login legittimi verso infrastrutture controllate dagli attaccanti—abilitando phishing e distribuzione di malware pur apparendo come un normale flusso di accesso.

Questo è particolarmente rilevante per gli amministratori IT in organizzazioni governative e del settore pubblico, che sono state specificamente prese di mira nell’attività osservata.

Novità / risultati chiave

Il Microsoft Defender Security Research Team ha osservato uno sfruttamento guidato dal phishing delle meccaniche di reindirizzamento OAuth su segnali di posta elettronica, identità ed endpoint:

• Abuso di flussi OAuth silenziosi: gli attaccanti creano URL di autorizzazione OAuth usando parametri come prompt=none per tentare un controllo di autenticazione silenzioso (senza UI).
• Scope intenzionalmente non validi per forzare un percorso di errore: le richieste includono scope=<invalid_scope> (o altri trigger di fallimento) per generare in modo affidabile un errore OAuth.
• Redirect guidato dall’errore verso un URI controllato dall’attaccante: quando l’IdP restituisce un errore (ad esempio, interaction_required), il browser viene reindirizzato al redirect URI registrato dell’app, che l’attaccante configura per puntare a pagine di phishing o siti di download di malware.
• Nessun furto di token necessario per il redirect: l’attaccante non sta necessariamente cercando di completare OAuth con successo; l’obiettivo principale è il reindirizzamento.
• Abuso del parametro state per la personalizzazione: il parametro state—pensato per correlare richiesta/risposta—è stato riutilizzato per passare l’indirizzo email della vittima (in chiaro, hex, Base64 o con codifica personalizzata) così che le pagine di phishing possano precompilare automaticamente gli identificativi.
• Pattern di distribuzione della campagna: gli adescamenti di phishing includevano richieste di e-signature, temi finanziari/di previdenza sociale, condivisione documenti, contenuti Teams/riunioni e prompt di reimpostazione password. Alcuni usavano allegati PDF con link incorporati e persino inviti calendario .ics.
• Strumenti downstream: le pagine post-redirect usavano frequentemente framework di phishing come EvilProxy (attacker-in-the-middle) progettati per catturare credenziali e cookie di sessione, talvolta aggiungendo passaggi CAPTCHA/interstiziali.

Impatto su amministratori IT e utenti finali

• Maggiore rischio di click-through: i link iniziano su domini IdP affidabili (ad esempio, login.microsoftonline.com), aumentando la fiducia dell’utente.
• Pressione per l’aggiramento delle difese: i controlli tradizionali basati sulla reputazione degli URL possono concentrarsi sul dominio iniziale e non vedere la destinazione finale.
• Necessità di visibilità su più livelli: Microsoft osserva che Defender ha correlato segnali su email, identità ed endpoint, sottolineando che il rilevamento tramite un singolo controllo potrebbe non essere sufficiente.
• Minaccia continua: Microsoft Entra ha disabilitato le applicazioni OAuth malevole osservate, ma attività correlate persistono—è ancora necessario monitorare.

Azioni / prossimi passi

1. Eseguire hunting per pattern sospetti di OAuth authorize nei log e nella telemetria dei proxy, in particolare:
   • prompt=none combinato con valori scope insoliti/non validi
   • Fallimenti OAuth frequenti seguiti da redirect verso domini non aziendali
   • Uso di /common/ in contesti di phishing ad alto volume non attesi
2. Rivedere e limitare il consenso alle app e le registrazioni delle app:
   • Effettuare audit delle app create di recente e dei redirect URI verso domini non attendibili
   • Restringere chi può registrare applicazioni/modificare redirect URI in Entra ID
3. Rafforzare le protezioni anti-phishing oltre i controlli “trusted domain”:
   • Assicurarsi che gli strumenti di detonation/safe-link seguano i redirect
   • Educare gli utenti che “parte dal sign-in Microsoft” non garantisce sicurezza
4. Verificare Conditional Access e i controlli di sessione:
   • Monitorare telemetria di sign-in ed errori OAuth per anomalie e gruppi di utenti mirati
5. Usare la correlazione di Defender:
   • Sfruttare Microsoft Defender for Office 365 + Defender for Identity/Endpoint per correlare l’esca email, il comportamento di sign-in e l’attività di payload sugli endpoint.