CVE-2025-55241: Entra ID impersonificazione token attore poteva compromettere qualsiasi amministratore globale

Cos'era CVE-2025-55241: la falla di impersonificazione tramite token Attore in Entra ID

CVE-2025-55241 è una vulnerabilità di elevazione dei privilegi in Microsoft Entra ID basata sull'impersonificazione tramite token Attore di Entra ID, scoperta dal ricercatore di sicurezza indipendente Dirk-jan Mollema e segnalata al Microsoft Security Response Center (MSRC) il 14 luglio 2025. Il punteggio CVE assegnato dallo stesso Microsoft era CVSS 10.0 (Critico); il ricalcolo indipendente di NVD lo ha portato a 9.8 (Critico), con classificazione CWE-287 (autenticazione impropria). Microsoft ha assegnato il CVE il 4 settembre 2025 dichiarando che non era richiesta alcuna azione da parte dei clienti, poiché la correzione era già stata distribuita su tutti i tenant.

La falla combinava due elementi: un tipo di token interno Microsoft, non documentato, chiamato "token Attore", e una lacuna nella convalida del tenant nell'API Azure AD Graph legacy (graph.windows.net). Combinati, permettevano a chi possedeva un token Attore del proprio tenant (controllato dall'attaccante) di autenticarsi come qualsiasi utente — inclusi gli amministratori globali — in qualsiasi altro tenant Entra ID, senza aver bisogno delle credenziali di quell'utente, senza attivare l'MFA e senza generare la traccia di audit su cui i difensori normalmente fanno affidamento. Mollema ha descritto l'esposizione come capace di compromettere "ogni tenant Entra ID al mondo", ad eccezione dei cloud nazionali/sovrani.

🚨 Pericolo: secondo Microsoft e Mollema non ci sono prove di sfruttamento attivo. Questa è una spiegazione retrospettiva di una vulnerabilità che Microsoft ha già corretto a livello globale — non una minaccia attiva che richieda un'azione d'emergenza oggi.

Cronologia della divulgazione

• 14 luglio 2025 — Mollema segnala il problema al MSRC; il MSRC apre un caso lo stesso giorno.
• 17 luglio 2025 — Microsoft distribuisce in produzione una correzione per la lacuna di convalida del tenant nell'API Azure AD Graph.
• 23 luglio 2025 — Il MSRC conferma a Mollema che il problema principale è risolto.
• 6 agosto 2025 — Microsoft distribuisce ulteriori mitigazioni che limitano l'emissione di token Attore per l'API Azure AD Graph ai soli servizi interni Microsoft.
• 4 settembre 2025 — Microsoft assegna formalmente il CVE-2025-55241 e dichiara che non è richiesta alcuna azione da parte dei clienti.
• 17 settembre 2025 — Mollema pubblica l'analisi tecnica completa, comprensiva di indicazioni per il rilevamento.

Come funzionava l'aggiramento tramite token Attore

I token Attore sono emessi dall'Access Control Service (ACS) di Microsoft per la delega servizio-a-servizio — il meccanismo che consente a backend proprietari Microsoft, come Exchange Online, di "agire come" un utente quando chiamano altri servizi Microsoft per conto di tale utente. Secondo l'analisi di Mollema, i token Attore contengono una claim trustedfordelegation e, una volta emessi, consentono di fatto di impersonare qualsiasi utente di un tenant per un massimo di 24 ore. Si tratta di un meccanismo interno legittimo e di lunga data — la vulnerabilità risiedeva nel modo in cui un consumatore legacy di questi token li convalidava, non nell'esistenza del meccanismo stesso.

Due lacune di progettazione rendevano questa falla sfruttabile oltre i confini di un tenant:

Origine del tenant non convalidata

L'API Azure AD Graph legacy non verificava correttamente che l'ID tenant incorporato nelle claim di impersonificazione di un token Attore corrispondesse al tenant effettivamente interrogato. Poiché il payload di impersonificazione era trasportato in un JWT non firmato, un attaccante poteva sostituire l'ID del proprio tenant con quello di un tenant bersaglio senza invalidare la firma del token — perché non ce n'era una da violare. Ciò permetteva di riprodurre un token coniato per il tenant dell'attaccante come se provenisse da qualsiasi altro tenant al mondo.

Identificatori utente prevedibili (netId)

Il bersaglio dell'impersonificazione all'interno del tenant di destinazione veniva risolto tramite netId, un identificatore legacy di Microsoft Passport ancora presente in alcuni componenti interni di Entra. A differenza di un ID oggetto Entra (un GUID casuale), i valori netId si incrementano in modo prevedibile. Mollema ha scoperto che potevano essere forzati con un attacco brute-force in "minuti o ore" per un tenant bersaglio, e potevano anche essere raccolti direttamente dagli attributi alternativeSecurityIds degli utenti guest in relazioni di trust B2B, oppure da token trapelati in log, ticket di supporto e screenshot pubblici.

Nel complesso: un attaccante in grado di richiedere un token Attore da qualsiasi tenant sotto il proprio controllo — incluso un tenant gratuito o di prova — poteva riscrivere l'ID del tenant bersaglio e abbinarlo a un netId risolto, e l'API Azure AD Graph legacy accettava l'impersonificazione risultante. Ciò garantiva accesso in lettura e scrittura ai dati della directory, la possibilità di creare service principal, modificare le assegnazioni di ruolo e modificare i criteri di accesso condizionale agendo come qualsiasi utente rivendicato dal token, fino a un amministratore globale incluso.

Perché MFA, accesso condizionale e logging non potevano rilevarlo

Questo è ciò che rendeva la falla critica e non semplicemente grave: l'aggiramento operava al di sotto dei controlli su cui i tenant fanno affidamento per rilevare la compromissione di un account.

• MFA e accesso condizionale non si applicano. I token Attore sono un meccanismo di delega servizio-a-servizio, non un accesso interattivo — non passano affatto attraverso il motore dei criteri di accesso condizionale, quindi l'MFA per utente, il rischio di accesso e i requisiti di conformità dei dispositivi semplicemente non vengono valutati. Un promemoria del fatto che l'MFA da solo non è mai stato un controllo completo — copre solo i percorsi di autenticazione a cui è effettivamente collegato.
• Richiedere il token non genera alcun log. Secondo l'analisi di Mollema, ottenere un token Attore non produce alcuna voce di log visibile al tenant — un attaccante poteva preparare l'attacco senza lasciare alcuna traccia nel tenant bersaglio.
• L'API Graph legacy registra in modo insufficiente. graph.windows.net è precedente alla profondità di logging offerta da Microsoft Graph e dalla moderna pipeline di audit di Entra, quindi anche le azioni compiute con il token di impersonificazione venivano catturate solo parzialmente.
• Il token era di fatto irrevocabile durante la sua validità. Essendo un JWT autonomo e non firmato, valido fino a 24 ore, un token Attore trapelato o falsificato non poteva essere invalidato a metà percorso come invece può accadere con un token di sessione compromesso.

Rilevamento: cosa cercare

Poiché la correzione di Microsoft ha chiuso il percorso di accesso sottostante, il rilevamento qui è retrospettivo — esaminare la cronologia di audit di Entra alla ricerca di segnali che la tecnica sia stata usata contro il proprio tenant prima della correzione — piuttosto che un controllo di monitoraggio in tempo reale. Mollema ha pubblicato una query KQL esattamente per questo: le modifiche guidate da token Attore compaiono comunque in AuditLogs, ma con una discrepanza rivelatrice tra il nome visualizzato del servizio agente e il contesto effettivo che ha avviato l'azione.

AuditLogs
| where not(OperationName has "group")
| where not(OperationName == "Set directory feature on tenant")
| where InitiatedBy has "user"
| where InitiatedBy.user.displayName has_any (
    "Office 365 Exchange Online", "Skype for Business Online", "Dataverse",
    "Office 365 SharePoint Online", "Microsoft Dynamics ERP")

Cosa non rileva questa query

Questa query, adattata dall'analisi pubblicata da Mollema, segnala le modifiche alla directory effettuate tramite impersonificazione con token Attore. Non rileva la ricognizione in sola lettura — enumerazione di utenti o gruppi, raccolta di segreti, revisione dei criteri — che l'API legacy non registrava con dettaglio sufficiente da poter essere ricostruita a posteriori. Considerate un risultato pulito di questa query come prova che non è stata trovata alcuna attività di scrittura attraverso questo percorso, non come prova che il tenant non sia mai stato letto.

Remediation

La correzione di Microsoft stessa non richiedeva alcuna azione da parte dei clienti: il MSRC ha confermato che il problema di convalida del tenant era risolto entro il 23 luglio 2025, e entro il 6 agosto 2025 ha ulteriormente limitato l'emissione di token Attore per l'API Azure AD Graph ai soli servizi interni Microsoft. Ciò chiude questa catena specifica. La remediation duratura per i tenant consiste nel ridurre la dipendenza dalla superficie legacy e dagli schemi di privilegio sfruttati da questa falla:

1. Eliminate le dipendenze da Azure AD Graph. Verificate le registrazioni app e i service principal alla ricerca di quelli che chiamano ancora Azure AD Graph e migrateli a Microsoft Graph; ogni dipendenza eliminata è una superficie in meno esposta al prossimo bug di convalida di un'API legacy.
2. Eliminate le assegnazioni permanenti di amministratore globale. Lo scenario peggiore di questa falla era l'impersonificazione completa di un amministratore globale. Spostare i ruoli amministrativi verso un'attivazione just-in-time tramite Privileged Identity Management (PIM) riduce il numero di account che un'impersonificazione riuscita potrebbe effettivamente sfruttare in modo significativo.
3. Richiedete MFA resistente al phishing su ogni ruolo privilegiato, non solo sull'accesso interattivo in generale — questo non ferma un aggiramento tramite token servizio-a-servizio come i token Attore, ma chiude il percorso molto più comune che gli attaccanti usano realmente per raggiungere gli account amministrativi.
4. Bloccate l'autenticazione legacy a livello di tenant tramite l'accesso condizionale. L'autenticazione legacy non supporta la convalida moderna dei token né l'applicazione dell'accesso condizionale, e i tenant che ancora consentono l'autenticazione legacy o lasciano aperte lacune nell'accesso condizionale ampliano la stessa categoria di esposizione che ha reso questa vulnerabilità così grave: percorsi di autenticazione che il piano di controllo moderno non può vedere.
5. Rivedete la conservazione e gli avvisi di AuditLogs di Entra per lo schema di iniziatore anomalo descritto sopra, in modo che qualsiasi futuro aggiramento tramite impersonificazione di un servizio proprietario generi un avviso anziché il silenzio. Un audit di sicurezza Entra ID più ampio copre questo aspetto insieme al resto della postura del proprio tenant, incluse le impostazioni predefinite con cui vengono forniti i nuovi tenant.

Perché l'API legacy contava oltre questo CVE

Microsoft ritira graph.windows.net a fasi dall'annuncio di deprecazione del 2019: le nuove applicazioni sono state bloccate dal primo utilizzo a partire dal 31 agosto 2024, e dal 1° febbraio 2025 è richiesta a livello di tenant un'attivazione opt-in per l'accesso esteso, con le app che non aderiscono che perdono del tutto l'accesso. Microsoft ha dichiarato chiaramente di non investire ulteriormente in Azure AD Graph oltre alle correzioni di sicurezza, e che ogni nuova funzionalità va a Microsoft Graph. CVE-2025-55241 è un'illustrazione concreta del perché questa migrazione conti oltre la semplice casella di conformità da spuntare: una superficie API deprecata, sotto-registrata e sotto-mantenuta è esattamente il luogo dove una lacuna di convalida come questa passa inosservata più a lungo.

Come EtcSec rileva questo

L'audit Entra ID di EtcSec non ha visibilità sull'infrastruttura interna dei token Attore di Microsoft — quel piano di controllo si trova interamente all'interno dell'infrastruttura Microsoft e non è mai stato qualcosa che un audit lato tenant potesse osservare o correggere direttamente. Ciò che EtcSec verifica, in modo continuo, è l'insieme delle condizioni lato tenant che determinano quanto danno può fare qualsiasi aggiramento di tipo impersonificazione (questo o il prossimo): assegnazioni permanenti di amministratore globale (PA_TOO_MANY_GLOBAL_ADMINS, PA_PERMANENT_ADMIN_ASSIGNMENTS), account amministrativi privi di MFA forte (PA_GLOBAL_ADMIN_NOT_MFA), e tenant che consentono ancora percorsi di autenticazione legacy al di fuori dell'applicazione dell'accesso condizionale (CA_NO_LEGACY_AUTH_BLOCK).