Microsoft Entra ID, il CSIRT Italia avverte sul consent phishing per ottenere permessi OAuth

• Consent phishing contro Microsoft Entra ID e Microsoft 365: l'utente autorizza un'app OAuth dell'attaccante
• Password, MFA e logout delle sessioni non revocano l'accesso: va rimosso il consenso o l'app
• Gravità elevata; a rischio i tenant con consenso utente predefinito e senza monitoraggio degli audit log
• Limitare il consenso, attivare l'Admin Consent Workflow e controllare i log "Consent to application"

L’ACN, tramite il CSIRT Italia, ha pubblicato un avviso su un uso sistematico di tecniche di consent phishing contro le infrastrutture basate su Microsoft Entra ID e Microsoft 365. L’attaccante induce utenti o amministratori ad autorizzare un’applicazione cloud esterna sotto il suo controllo. L’applicazione ottiene così permessi persistenti di lettura e scrittura su posta elettronica, rubriche contatti e archivi documentali.

Come funziona l’attacco

L’avviso richiama i precedenti bollettini BL01/260407/CSIRT-ITA e BL01/260731/CSIRT-ITA, relativi al Device Code Flow. Anche qui si abusano token OAuth 2.0 emessi legittimamente dal provider di identità. Cambia però il meccanismo: la vittima concede i permessi direttamente a un’applicazione dell’attaccante.

L’attore registra prima un’applicazione multi-tenant in Entra ID, configurata per chiedere permessi specifici. Poi invia e-mail mirate oppure inietta codice in portali web compromessi. I link avviano il normale flusso di consenso (/oauth2/v2.0/authorize).

La vittima vede la schermata autentica della Microsoft Identity Platform. Questo la spinge ad accettare senza verificare lo sviluppatore, il dominio o la portata dei privilegi. Nessuna credenziale viene rubata.

Persistenza ed esfiltrazione

Ottenuto il consenso, l’applicazione richiede in autonomia token di accesso e refresh token e li usa contro le API di Microsoft Graph. L’attività resta nel perimetro dei privilegi assegnati:

• con consenso di un utente standard (permessi delegati), l’accesso riguarda solo le risorse di quel profilo, per esempio la lettura silente della posta con lo scope Mail.Read o la modifica di file su OneDrive/SharePoint con Files.ReadWrite;
• con consenso di un amministratore a livello di tenant, l’applicazione può accedere alle risorse dell’intera organizzazione senza compromettere altri account.

Perché la risposta standard non basta

L’accesso dell’utente è regolare, quindi nei Sign-in Logs non compaiono anomalie. La traccia è negli Audit Logs, alla voce Consent to Application. Cambio password, MFA e disconnessione delle sessioni risultano inefficaci, perché l’attaccante usa diritti delegati all’applicazione, registrata come Service Principal. L’accesso cessa solo se un amministratore revoca il consenso o elimina l’applicazione dal tenant. L’ACN valuta la gravità complessiva come elevata.

Sistemi e ambienti a rischio

• Sottoscrizioni con le impostazioni predefinite di consenso autonomo per gli utenti standard.
• Microsoft 365: Exchange Online, SharePoint Online, OneDrive for Business, Teams.
• Tenant in cui app OAuth autorizzate accedono ai dati aziendali via Graph API.
• Ambienti senza audit avanzato o senza monitoraggio automatico dei consensi, e senza policy di Microsoft Defender for Cloud Apps su concessioni anomale.

Cosa fare

In caso di sospetta concessione illecita, l’ACN raccomanda queste misure di contenimento:

• revocare le autorizzazioni OAuth e le assegnazioni di ruolo sui service principal, via Microsoft Graph PowerShell SDK o dall’Entra Admin Center (utente, sezione Applications, rimozione dell’entità malevola);
• impostare temporaneamente Sign-in blocked sull’utente colpito mentre si stima l’ampiezza dell’incidente;
• esportare i consensi dell’intero tenant e verificare i valori AllPrincipals e Principal nella colonna ConsentType. Vanno cercati permessi di tipo Read, Write o All associati ad applicazioni sconosciute o a publisher non affidabili;
• nei casi più gravi, disabilitare le Integrated Apps di terze parti nell’intero tenant, con possibili ricadute sul software non nativo Microsoft.

Per l’hardening, il CSIRT indica di:

• vietare agli utenti standard di autorizzare app di terze parti, consentendo solo app interne o di publisher verificati con permessi a basso rischio;
• attivare l’Admin Consent Workflow;
• analizzare ogni settimana i log di Microsoft Purview Audit cercando Consent to application;
• attivare in Defender for Cloud Apps le policy di anomalia sulle app OAuth;
• configurare Defender for Office 365 per bloccare lo spear phishing e le e-mail con link a richieste di consenso da app sconosciute.

Fonte: ACN