Sintesi

È stato recentemente documentato l’utilizzo sistematico di tecniche di “ consent phishing ” volto al rilascio di consensi illeciti ( illicit consent grants ) ai danni di infrastrutture basate su Microsoft Entra ID e suite Microsoft 365. La tecnica si concretizza tramite ingegneria sociale e consiste nell’indurre, con l’inganno, utenti o amministratori ad autorizzare applicazioni cloud esterne controllate dall’attaccante, conferendo loro permessi persistenti di lettura e scrittura su dati sensibili quali corrispondenza e-mail, rubriche contatti e repository documentali.

Tipologia

• Information Disclosure
• Authentication Bypass

Descrizione e potenziali impatti

È stato recentemente documentato l’utilizzo sistematico di tecniche di “ consent phishing ” volto al rilascio di consensi illeciti ( illicit consent grants ) ai danni di infrastrutture basate su Microsoft Entra ID e suite Microsoft 365. La tecnica si concretizza tramite ingegneria sociale e consiste nell’indurre, con l’inganno, utenti o amministratori ad autorizzare applicazioni cloud esterne controllate dall’attaccante, conferendo loro permessi persistenti di lettura e scrittura su dati sensibili quali corrispondenza e-mail, rubriche contatti e repository documentali.

Analogamente a quanto osservato nei casi descritti da questo CSIRT nell’ambito del BL01/260407/CSIRT-ITA e del BL01/260731/CSIRT-ITA , l’attacco si fonda sull’utilizzo di token OAuth 2.0 emessi legittimamente dal provider di identità; tuttavia, mentre nei casi precedenti l’accesso veniva ottenuto inducendo la vittima ad autorizzare una sessione associata al Device Code Flow, nel presente scenario l’attaccante persuade l’utente a concedere autorizzazioni OAuth direttamente a un’applicazione sotto il proprio controllo. La gravità complessiva è elevata in quanto, una volta ottenuto il consenso OAuth, l’applicazione controllata dall’attaccante può continuare ad accedere alle risorse autorizzate richiedendo periodicamente nuovi token di accesso a Microsoft Entra ID. Tali token consentono all’applicazione di interagire direttamente con le API cloud di Microsoft, accedendo ai dati autorizzati senza necessità di conoscere le credenziali della vittima né di effettuare accessi interattivi al relativo account. Di conseguenza, le consuete procedure di risposta agli incidenti – quali la rotazione delle password o l’imposizione di autenticazione a più fattori (MFA) – risultano inefficaci nel revocare l’accesso agli attori malevoli, rendendo necessaria la revoca delle autorizzazioni concesse all’applicazione.

Di seguito una descrizione dettagliata delle modalità di sfruttamento rilevate.

Vettore iniziale e manipolazione del flusso OAuth 2.0

L’orchestrazione dell’attacco ha origine con la registrazione preventiva di un’applicazione multi-tenant in Microsoft Entra ID da parte dell’attore malevolo, configurata per richiedere permessi specifici su risorse protette. Il vettore iniziale sfrutta le tipiche tecniche dell’ingegneria sociale e consiste nella trasmissione di comunicazioni e-mail mirate (Figura 1) o nell’iniezione di codice su portali Web compromessi (Figura 2), contenenti collegamenti formattati per avviare il flusso standard di concessione del consenso ( /oauth2/v2.0/authorize ).

La vittima viene indirizzata verso gli endpoint legittimi della Microsoft Identity Platform (https://login.microsoftonline.com/) (Figura 3), visualizzando l’interfaccia legittima contenente la richiesta di autorizzazione. Il meccanismo fuorviante fa leva proprio sull’autenticità dell’infrastruttura di hosting del fornitore, spingendo l’operatore ad accettare i termini di utilizzo senza verificare l’identità dello sviluppatore, il dominio di provenienza o la portata dei privilegi richiesti. Tale azione perfeziona il rilascio dei token senza che alcuna credenziale statica venga intercettata o compromessa.

Persistenza operativa ed esfiltrazione via API Graph

Una volta ottenuto il consenso, l’applicazione malevola acquisisce diritti operativi autonomi e disaccoppiati dalla sessione interattiva della vittima. L’attaccante utilizza script automatizzati per richiedere token di accesso e refresh token direttamente ai server di autenticazione Microsoft, impiegandoli contro le API REST di Microsoft Graph (https://graph.microsoft.com).

L’attività malevola si sviluppa interamente nel contesto dei privilegi assegnati all’applicazione: qualora il consenso sia stato rilasciato da un utente standard con permessi delegati, l’esfiltrazione riguarda le sole risorse accessibili dal profilo specifico, come la lettura silente della posta tramite scope Mail.Read o l’alterazione di file su OneDrive/SharePoint mediante Files.ReadWrite .

Qualora la vittima disponga di privilegi amministrativi e conceda il consenso a livello di tenant, l’applicazione malevola può ottenere accesso alle risorse dell’intera organizzazione, senza necessità di compromettere ulteriori account o sistemi.

Tracciamento forense e limitazioni della bonifica standard

A differenza dei vettori di attacco convenzionali, nei quali la compromissione è desumibile dai log di accesso – Sign-in Logs – tramite anomalie di autenticazione o tentativi falliti, in questo scenario l’accesso iniziale dell’utente legittimo risulta del tutto regolare e privo di deviazioni rispetto alle normali abitudini operative. L’evidenza forense dell’intrusione non risiede dunque nella fase di autenticazione, bensì nei registri di verifica e conformità – Audit Logs – di Microsoft, dove l’istante esatto della delega autorizzativa verso l’applicazione malevola viene formalmente registrato sotto la voce Consent to Application .

Le ordinarie procedure di risposta agli incidenti – quali il cambio della password, l’imposizione di un secondo fattore di autenticazione (MFA) o la disconnessione forzata delle sessioni – risultano del tutto inefficaci nello scenario in esame. Di fatto, l’attaccante non opera tramite credenziali sottratte all’utente, ma mediante i diritti formalmente delegati all’applicazione esterna.

L’infrastruttura cloud registra tale autorizzazione – grant OAuth – come un permesso autonomo assegnato all’applicazione esterna – Service Principal .

Di conseguenza, la persistenza della minaccia cessa esclusivamente quando un amministratore revoca in modo esplicito il consenso autorizzato o elimina l’applicazione dal tenant.

Prodotti interessati

Microsoft Entra ID

• tutte le sottoscrizioni in cui sono abilitate le impostazioni predefinite di consenso autonomo per gli utenti standard.

Microsoft 365 (Exchange Online, SharePoint Online, OneDrive for Business, Teams)

• tutte le istanze tenant nei quali applicazioni OAuth autorizzate possono accedere ai dati aziendali tramite Microsoft Graph API in funzione dei permessi concessi.

Fattori di rischio aggiuntivi

Microsoft Defender for Office 365 / Purview Audit

• ambienti privi di audit avanzato attivo o privi di monitoraggio automatico sugli eventi di consenso.

Microsoft Defender for Cloud Apps

• ambienti con assenza di policy di rilevamento su concessioni di permessi applicativi anomali (OAuth apps). [RF1]

Azioni di mitigazione

In caso di sospetta o accertata concessione illecita di permessi, si raccomanda l’adozione tempestiva delle seguenti misure di contenimento:

• Revoca immediata delle autorizzazioni OAuth via PowerShell: eseguire la disconnessione e la revoca atomica delle concessioni di permessi delegati e delle assegnazioni di ruolo sui service principal tramite Microsoft Graph PowerShell SDK:

Remove-MgOauth2PermissionGrant -OAuth2PermissionGrantId “<ID_Permesso_Identificato>”

Remove-MgServicePrincipalAppRoleAssignment -ServicePrincipalId “<ID_Service_Principal>” -AppRoleAssignmentId “<ID_Assegnazione>”

• Bonifica manuale dell’utenza da portale amministrativo : accedere a Microsoft Entra Admin Center (https://entra.microsoft.com), selezionare il percorso Identity > Users > All users , individuare l’account impattato, aprire la sezione Applications , selezionare l’entità malevola rilevata e confermare la rimozione dell’assegnazione tramite l’opzione Remove .
• Blocco transitorio dell’accesso utente : qualora la compromissione sia in corso e si stia procedendo alla determinazione dello scope, impostare lo stato Sign-in blocked sul profilo utente impattato per impedire ulteriori deleghe e interrompere l’emissione di nuovi token.
• Ispezione analitica dei permessi a livello di tenant : eseguire l’estrazione massiva dei consensi applicativi per l’intera organizzazione mediante lo script di enumerazione delle autorizzazioni OAuth Get-AzureADPSPermissions.ps1 ed esportare il report su disco locale:

Connect-MgGraph -Scopes “Directory.Read.All”, “DelegatedPermissionGrant.Read.All”

.\Get-AzureADPSPermissions.ps1 | Export-Csv -Path “.\Permissions.csv” -NoTypeInformation

• Filtraggio e isolamento nel file esportato : ispezionare il file .\Permissions.csv ricercando nella colonna ConsentType i valori AllPrincipals e Principal , verificando la presenza di privilegi di tipo Read , Write o All all’interno della colonna Permission , correlando i record con il valore della colonna ClientDisplayName al fine di identificare applicazioni sconosciute, non autorizzate o riconducibili a publisher non affidabili.
• Interdizione delle Integrated Apps (misura di emergenza) : nei casi di compromissione più gravi, disabilitare globalmente l’integrazione delle applicazioni di terze parti nell’intero tenant per bloccare istantaneamente qualsiasi nuovo consenso da parte del personale, tenendo conto del potenziale impatto operativo su tutti i software non nativi Microsoft.

Best practices e hardening

• Restrizione strutturale del consenso utente : configurare le impostazioni di consenso in Microsoft Entra ID impostando il divieto tassativo per gli utenti standard di autorizzare applicazioni di terze parti; consentire l’autorizzazione esclusivamente per applicazioni sviluppate internamente o provenienti da publisher verificati ( Publisher Verification ), limitando il perimetro a un catalogo ristretto di permessi a basso rischio preventivamente selezionati.
• Implementazione del flusso di approvazione amministrativa (Admin Consent Workflow) : abilitare il flusso formale di richiesta del consenso, imponendo che qualsiasi applicazione non inclusa nella lista consentita debba essere sottoposta a preventiva valutazione e approvazione tecnica da parte di amministratori delegati.
• Ispezione ciclica dei registri di conformità : schedulare con cadenza settimanale l’estrazione e l’analisi dei log di Microsoft Purview Audit, ricercando in modo programmatico le attività Consent to application e gli eventi relativi alla concessione di consensi applicativi per intercettare rilasci non conformi o autorizzazioni privilegiate verso nuove applicazioni OAuth.
• Audit delle identità di carico di lavoro e governance : attivare le policy di rilevamento anomalie per le applicazioni OAuth all’interno di Microsoft Defender for Cloud Apps per identificare pattern operativi non consueti, inclusi picchi improvvisi di volume di download e chiamate API da geolocalizzazioni insolite.
• Politiche di filtraggio mail e anti-impersonificazione : implementare regole restrittive su Microsoft Defender for Office 365 volte a intercettare campagne di spear phishing mirate all’abuso dell’interfaccia di autenticazione aziendale e a inibire il recapito di e-mail contenenti link a richieste di consenso OAuth riconducibili ad applicazioni sconosciute, non autorizzate o potenzialmente malevole.