OAuth Consent Phishing: come le app malevole aggirano il furto di password

OAuth consent phishing è un attacco di identità in cui un utente o un amministratore viene indotto a concedere permessi a un’applicazione OAuth malevola. Dopo l’approvazione del consenso, l’attaccante non ha necessariamente bisogno della password dell’utente. L’applicazione può accedere a Microsoft 365 o ad altre risorse protette in base ai permessi concessi, rendendo questo scenario diverso dal phishing di credenziali, dal password spraying o dalla MFA fatigue.

Il perimetro di questo articolo è Microsoft Entra ID, Microsoft 365 e il consenso applicativo basato su OAuth. Non ogni accesso malevolo è consent phishing. Il focus è il grant di consenso: cosa riceve l’app, come i difensori possono vederlo, come rimuoverlo e come impedire che lo stesso percorso riemerga.

Che cos’è OAuth Consent Phishing?

OAuth consent phishing abusa di un modello di consenso legittimo. Microsoft descrive il consent phishing come un attacco che induce gli utenti a concedere permessi ad applicazioni cloud malevole. La schermata di consenso mostra i permessi che l’applicazione riceve, ma un nome credibile, un logo familiare o un pretesto aziendale plausibile possono comunque portare un utente o un amministratore ad approvare un accesso non previsto.

Nella Microsoft identity platform, OAuth permette a un’applicazione di richiedere accesso a una risorsa protetta. RFC 6749 definisce OAuth 2.0 come un framework che consente a un’applicazione di terze parti di ottenere accesso limitato a un servizio HTTP, per conto del proprietario della risorsa oppure per proprio conto. Microsoft Entra ID implementa questo modello per risorse come Microsoft Graph, Exchange Online, SharePoint Online e altre API integrate con la piattaforma di identità Microsoft.

Limiti di ambito

Il punto difensivo essenziale è che il consent phishing prende di mira l’autorizzazione, non solo l’autenticazione. In un incidente di password phishing, il team di solito verifica se sono state rubate credenziali, se la MFA è stata soddisfatta e se esiste una sessione sospetta. In OAuth consent phishing bisogna anche verificare se un’applicazione ha ricevuto un permission grant durevole che rimane rilevante dopo la sessione interattiva iniziale.

Il rischio è vicino a quello descritto in Azure App Registrations: Over-Privileged Tenant Apps, ma il percorso d’attacco è diverso. Le app legittime con privilegi eccessivi sono spesso un problema di governance interna. OAuth consent phishing è un’app malevola o ingannevole che ottiene accesso tramite una schermata di consenso.

Come funziona OAuth Consent Phishing

La catena d’attacco inizia con una normale richiesta di autorizzazione OAuth. Un utente segue un link o apre un’applicazione che lo invia alla Microsoft identity platform. L’utente si autentica se necessario. Se i permessi richiesti non hanno già ricevuto consenso, Microsoft Entra presenta un prompt di consenso. Il prompt include i permessi richiesti e le informazioni sul publisher.

Stato del consenso, non solo stato di accesso

Se l’utente o l’amministratore approva la richiesta, Microsoft Entra registra un grant per l’applicazione. Per i permessi delegati di Microsoft Graph, il risultato del consenso è rappresentato da OAuth2PermissionGrant. Per i permessi applicativi, il risultato è rappresentato da appRoleAssignment. Questi due oggetti sono importanti perché sono ciò che i difensori devono enumerare, rivedere e rimuovere durante il cleanup.

Un’app malevola non deve chiedere tutti i permessi in una sola volta. Microsoft documenta il consenso dinamico come un caso in cui un’applicazione richiede nuovi permessi durante l’esecuzione. Questo rende la revisione dei consensi più di un controllo iniziale di onboarding. Un tenant può risultare pulito durante una review iniziale e ricevere più tardi una richiesta di accesso più ampia se l’app è progettata per chiedere scope aggiuntivi.

La nuance di offline_access

Lo scope offline_access cambia anche il modello difensivo. Microsoft documenta offline_access come accesso alle risorse per conto dell’utente per un periodo esteso. Nella pagina di consenso, questo appare come mantenimento dell’accesso ai dati a cui l’app ha ricevuto accesso. Microsoft indica anche che, se viene concesso un qualsiasi permesso delegato, offline_access viene concesso implicitamente, e che i refresh token sono di lunga durata. Questo non significa che l’attaccante abbia accesso permanente. Significa che la risposta all’incidente deve includere rimozione dei grant e pulizia di token o sessioni, non solo reset della password.

Per questo OAuth consent phishing è vicino, ma distinto, da altri attacchi di identità Entra. Device Code Phishing: How OAuth Device Flow Compromises Entra ID Accounts abusa di un flusso OAuth diverso. Entrambi gli attacchi sono centrati su OAuth, ma device code phishing autorizza una sessione tramite device code flow, mentre consent phishing concede permessi a un’applicazione.

Permessi delegati vs permessi applicativi

La distinzione tecnica più importante è tra permessi delegati e permessi applicativi.

Accesso delegato

I permessi delegati vengono usati quando un’applicazione agisce per conto di un utente connesso. Microsoft li descrive come permessi che consentono all’applicazione di agire per conto dell’utente, senza poter accedere a ciò a cui l’utente connesso non potrebbe accedere. Se un utente concede un permesso delegato per leggere la posta, l’accesso dell’app dipende da ciò che quell’utente può leggere. Se un amministratore privilegiato concede permessi delegati mentre è connesso, l’impatto può essere molto maggiore perché i privilegi dell’utente sono maggiori.

Accesso app-only

I permessi applicativi, chiamati anche app roles o permessi app-only, vengono usati quando non è presente un utente connesso. Microsoft descrive l’accesso app-only come l’applicazione che agisce con la propria identità. I permessi applicativi possono consentire ampio accesso ai dati del tenant tramite Microsoft Graph o un’altra API di risorsa. Microsoft indica che, in generale, solo un amministratore o il proprietario del service principal di un’API può fornire consenso ai permessi applicativi esposti da tale API.

Triage per tipo di permesso

La distinzione guida la priorità d’indagine. Un grant delegato sospetto da parte di un utente poco privilegiato può esporre mailbox, file o risorse accessibili a quell’utente. Un permesso applicativo sospetto può avere portata tenant-wide, a seconda del permesso e dell’API di risorsa. Microsoft usa Files.Read.All per illustrare la differenza: Files.Read.All delegato permette all’app di leggere file che l’utente può accedere personalmente, mentre Files.Read.All applicativo può leggere qualsiasi file nel tenant tramite Microsoft Graph una volta concesso.

Non bisogna comprimere entrambi i casi in un rischio generico di app OAuth. Oggetto di cleanup, blast radius, percorso di approvazione e controllo di validazione sono diversi.

Perché la MFA non ferma da sola l’abuso del consenso

La MFA rimane importante. Riduce la probabilità che un attaccante possa accedere come utente, approvare prompt come quell’utente o completare altre azioni interattive. Il problema è più preciso: la MFA non rende automaticamente innocuo un permission grant OAuth già concesso.

Quando un’app malevola ha un grant delegato valido, può richiedere token secondo quel grant e il contesto utente/risorsa. Quando un’app ha permessi applicativi, può operare senza un utente connesso per i dati coperti dal permesso. Conditional Access e policy MFA possono ancora influire sull’emissione dei token in scenari specifici, ma l’esistenza di un consent grant deve essere investigata direttamente.

È la stessa lezione generale trattata in Azure Identity Security: Why MFA Alone Is Not Enough. La MFA è un controllo. Non sostituisce governance del consenso applicativo, review dei permessi, audit log monitoring, valutazione del publisher o revoca dei grant sospetti. Se il team traccia anche social engineering basato su notifiche push, MFA Fatigue: Detection and Prevention for Microsoft Entra ID copre un pattern separato che può verificarsi prima o accanto all’abuso del consenso.

L’errore pratico è chiudere l’incidente dopo il reset della password o dopo aver confermato che la MFA era attiva. In un caso di consent phishing, è incompleto. La risposta deve stabilire se esiste un service principal, quali grant sono collegati, quali utenti hanno consentito, se è stato concesso admin consent e se l’app è stata disabilitata, rimossa o bloccata dal ricevere nuovi grant.

La catena d’attacco

Una catena realistica di OAuth consent phishing ha diverse fasi. Il lure preciso può variare, ma i punti di controllo restano costanti.

1. L’attaccante prepara o controlla un’applicazione che può richiedere permessi Microsoft identity platform.
2. Un utente o admin riceve un URL di autorizzazione che mostra un’esperienza di sign-in e consenso ospitata da Microsoft.
3. Il prompt di consenso elenca permessi e informazioni del publisher. L’utente o admin approva la richiesta.
4. Microsoft Entra registra il grant. I permessi delegati appaiono come OAuth2PermissionGrant; i permessi applicativi appaiono come appRoleAssignment.
5. L’app usa access token e potenzialmente refresh token, quando disponibili, per chiamare API come Microsoft Graph secondo i permessi concessi.
6. L’attaccante mantiene accesso finché i difensori revocano i grant, disabilitano o rimuovono il service principal malevolo quando appropriato, bloccano il re-consent, invalidano sessioni/token rilevanti o Microsoft disabilita un’applicazione che viola i termini di servizio.

Cosa non è

Questa catena non è password spraying, dove l’attaccante prova credenziali contro molti account. Non è Kerberoasting, dove il target è materiale di ticket di servizio Kerberos in Active Directory. Non è nemmeno normale OAuth device code phishing, dove l’attaccante induce l’utente a completare un’autorizzazione tramite device code. Queste distinzioni contano perché telemetria e remediation sono diverse.

Per i difensori, il punto della catena è identificare stato durevole. Un sign-in sospetto si investiga nei sign-in log. Un grant di consenso sospetto si investiga tramite application objects, permission grants, audit logs e controlli di app governance.

Rilevamento

Nessun singolo evento Microsoft Entra prova OAuth consent phishing da solo. Un amministratore legittimo può consentire a un’app legittima. Un utente legittimo può approvare un permesso delegato a basso rischio. Il rilevamento richiede correlazione tra attività di consenso, metadati dell’app, permessi, contesto utente e comportamento API successivo.

Pivot negli audit log

Iniziare dagli audit log Microsoft Entra. Microsoft documenta queste attività di permission application nel servizio Core Directory e nella categoria ApplicationManagement:

Domande di correlazione

Usare questi eventi come pivot, non come verdetti finali. Una pipeline utile chiede:

• L’app è stata appena aggiunta al tenant?
• Il publisher è verificato e coerente con lo scopo aziendale dichiarato?
• Quali permessi sono stati richiesti, e sono a basso rischio o ad alto impatto sui dati?
• L’attore era un utente normale, un admin, un account break-glass o un account fuori dal comportamento normale?
• Il consenso è stato concesso subito dopo un sign-in sospetto, un segnale impossible travel, un risky user o un report di phishing?
• L’applicazione ha iniziato a chiamare Microsoft Graph, Exchange, SharePoint o altre API in modo non coerente con un workflow approvato?
• Più utenti hanno autorizzato la stessa applicazione insolita?

Defender for Cloud Apps può aggiungere un ulteriore livello quando disponibile. Microsoft documenta OAuth app policies che possono generare alert su app con alto livello di permessi, molti utenti autorizzanti, uso uncommon, nomi ingannevoli, nomi publisher ingannevoli o consenso OAuth potenzialmente malevolo. Trattare questi alert come segnali di priorità e ispezionare comunque service principal e grant sottostanti.

Un rilevamento maturo osserva anche la deriva di governance. Se user consent settings vengono allentati, se app consent policies cambiano o se reviewer vengono rimossi dall’admin consent workflow, il tenant diventa più facile da abusare. Questi cambi non provano da soli un’app malevola, ma riducono la forza di controllo sulle richieste future. Abbinare questo monitoraggio a How to Audit Microsoft Entra ID Security per rivedere app consent insieme a Conditional Access, ruoli privilegiati, utenti rischiosi e impostazioni identity tenant-wide.

Per investigazioni ibride, mantenere chiaro il confine: questo articolo si concentra sull’attività di audit Entra, ma Active Directory Monitoring: Security Event IDs That Matter può aiutare gli incident responder a correlare attività identity on-premises quando lo stesso utente o admin è coinvolto.

Remediation

La remediation ha due tracce: rimuovere l’accesso malevolo confermato e chiudere il percorso di consenso che lo ha permesso.

Rimuovere i grant esistenti

Prima identificare l’oggetto applicazione e il service principal in Enterprise Applications. Rivedere le schede Admin consent e User consent per i permessi concessi. Microsoft documenta che gli amministratori possono revocare permessi organization-wide nella scheda Admin consent, mentre i grant di user consent possono richiedere Microsoft Graph API o PowerShell. Per un cleanup completo, enumerare sia permessi delegati sia permessi applicativi.

Per i permessi delegati, rimuovere oggetti OAuth2PermissionGrant sospetti. Per i permessi applicativi, rimuovere voci appRoleAssignment sospette. La documentazione Microsoft sulla review dei permessi fornisce percorsi Graph e PowerShell per entrambi i casi. Se utenti o gruppi erano assegnati all’applicazione, rivedere e rimuovere queste assegnazioni come parte del containment.

Contenere il service principal

Poi disabilitare o rimuovere il service principal quando l’applicazione è confermata malevola o non autorizzata. Fare attenzione con applicazioni che hanno utilizzo sia sospetto sia legittimo; rimuovere un service principal può interrompere workflow aziendali. Se Microsoft ha disabilitato un’app OAuth per violazione dei termini di servizio, Microsoft documenta che nuove richieste di token e refresh token vengono negate, ma gli access token esistenti restano validi fino alla scadenza. Per questo i responder non devono affidarsi a una sola azione.

Poi trattare token e sessioni. Per abuso delegato, revocare refresh token o invalidare sessioni utente dove appropriato. Per abuso app-only, concentrarsi sulla rimozione degli app role assignment, rimozione delle credenziali dal service principal se tenant-owned, disabilitazione del service principal e validazione che non resti alcun grant app-only. Il reset password può essere rilevante se anche l’utente è stato phishato, ma da solo non rimuove un grant OAuth.

Rafforzare i consensi futuri

Infine rafforzare la governance del consenso:

• Rivedere user consent settings ed evitare consenso utente ampio per applicazioni e permessi che dovrebbero richiedere review admin.
• Usare app consent policies per restringere ciò a cui gli utenti possono consentire in base a criteri come verified publisher e rischio dei permessi.
• Abilitare e configurare admin consent workflow affinché gli utenti possano richiedere accesso ad app che necessitano approvazione, invece di usare canali informali.
• Limitare chi può concedere tenant-wide admin consent. Microsoft raccomanda ruoli least privilege e avverte che Global Administrator è altamente privilegiato.
• Valutare publisher verification come un segnale, non come un’approvazione completa di sicurezza. Microsoft dichiara esplicitamente che il badge verified publisher non implica criteri di qualità, certificazioni, compliance o security best practice.
• Usare OAuth app policies di Defender for Cloud Apps, se disponibili, per alert su app rischiose, uncommon, high-permission o potenzialmente malevole.

Non creare una regola globale che blocchi tutte le app di terze parti senza processo di eccezione. Questo di solito spinge gli utenti verso workaround non gestiti. L’approccio più solido è un percorso di consenso controllato: permessi delegati a basso rischio consentiti, review admin per scope delegati sensibili e permessi applicativi, e revisione periodica delle app già approvate.

Validazione dopo il cleanup

La validazione è dove molte risposte al consent phishing falliscono. Un ticket non dovrebbe chiudersi perché l’app è scomparsa da una pagina visibile del portale. Dovrebbe chiudersi perché i percorsi di autorizzazione durevoli sono stati verificati.

Checklist di chiusura

Usare questa sequenza di validazione:

1. Confermare che il service principal sospetto sia disabilitato o rimosso quando l’app è confermata malevola.
2. Confermare che non resti alcun OAuth2PermissionGrant delegato sospetto per il client service principal.
3. Confermare che non resti alcun appRoleAssignment sospetto per permessi app-only.
4. Confermare che assegnazioni utente e gruppo all’applicazione siano state rimosse se contribuivano all’accesso.
5. Confermare che gli audit log mostrino gli eventi di rimozione attesi, come removal di delegated permission grants o app role assignments.
6. Confermare che user consent settings, app consent policies e admin consent workflow corrispondano al modello di controllo previsto.
7. Confermare che utenti rilevanti abbiano avuto sessioni/tokens revocati quando era coinvolto accesso delegato.
8. Confermare che Defender for Cloud Apps o app governance, se distribuiti, non mostrino più l’app come autorizzata o attiva.
9. Confermare che nuovi tentativi di concedere lo stesso percorso di permessi richiedano il workflow admin atteso o siano bloccati da policy.

Per investigazioni tenant-wide, abbinarlo a Azure Identity Protection: Blocking Leaked Credentials. Consent phishing non è la stessa cosa di credenziali leakate, ma segnali risky user e risky sign-in possono aiutare a capire se l’utente che ha concesso il consenso era anch’esso compromesso.

Come EtcSec rileva l’esposizione correlata

EtcSec dovrebbe trattare OAuth consent phishing come un pattern di esposizione tra inventario applicativo, identity governance e readiness di monitoring. Il check utile non è solo se esiste un’app malevola. Il check utile è se il tenant renderebbe il consenso malevolo facile da ottenere, difficile da rilevare o lento da revocare.

Segnali di esposizione

I controlli rilevanti includono:

• Enterprise Applications con ampi permessi delegati o app-only Microsoft Graph.
• Applicazioni autorizzate da molti utenti senza owner chiaro o giustificazione aziendale.
• Applicazioni senza verified publisher, soprattutto quando richiedono permessi sensibili.
• User consent settings che consentono agli utenti di approvare più di permessi delegati a basso rischio.
• Admin consent workflow mancante o debole.
• Mancanza di review ricorrente per admin consent e user consent grants.
• Permessi applicativi incoerenti con lo scopo dichiarato dell’app.
• Utenti privilegiati che hanno consentito app di terze parti da dispositivi o contesti meno trusted.
• Gap di monitoring su Consent to application, Add delegated permission grant e Add app role assignment to service principal.

Questo tema è adiacente a Azure Conditional Access: MFA Bypass With Stolen Passwords, ma la remediation è diversa. Conditional Access resta parte della difesa identity, ma il rafforzamento OAuth consent richiede app governance, permission review, consent policies e cleanup dei service principal.

Controlli correlati

OAuth consent phishing si gestisce meglio come un insieme di controlli, non come un singolo toggle.

Questi controlli riducono anche l’esposizione da app legittime sovra-permissionate. La governance del consenso diventa parte normale delle operazioni di sicurezza Entra, non solo risposta dopo una segnalazione di phishing.

Riferimenti primari

Le affermazioni tecniche in questo articolo si basano su documentazione primaria e standard:

• Microsoft Learn: Protect against consent phishing
• Microsoft Learn: Permissions and consent overview
• Microsoft Learn: Scopes and permissions in the Microsoft identity platform
• Microsoft Learn: Configure the admin consent workflow
• Microsoft Learn: Manage app consent policies
• Microsoft Learn: Review permissions granted to enterprise applications
• Microsoft Learn: View activity logs of application permissions
• Microsoft Learn: Microsoft Entra audit log activity reference
• Microsoft Learn: Publisher verification
• Microsoft Defender for Cloud Apps: Create policies to control OAuth apps
• RFC 6749: The OAuth 2.0 Authorization Framework
• RFC 6819: OAuth 2.0 Threat Model and Security Considerations