Permessi Graph API Pericolosi App Registration di Entra: Rilevamento e Remediation

I permessi Graph API pericolosi App Registration di Entra trasformano un singolo clic di consenso amministrativo in una credenziale permanente, valida sull'intero tenant. Directory.ReadWrite.All, Mail.ReadWrite, Files.ReadWrite.All e RoleManagement.ReadWrite.Directory sono permessi applicativi (app-only) — concessioni che permettono a un service principal di agire sull'intero tenant Microsoft 365 senza un utente collegato e senza delimitazione per oggetto. Questa guida illustra cosa consente realmente ciascun permesso, una catena di attacco documentata che li concatena fino al controllo completo di Global Administrator, e come rilevare e correggere queste concessioni.

Permessi Graph API Pericolosi App Registration di Entra Spiegati

Tutti e quattro sono permessi applicativi, chiamati anche permessi app-only. La documentazione Graph di Microsoft stessa traccia la linea con chiarezza: i permessi applicativi «funzionano nello scenario di accesso app-only, senza un utente collegato presente», e l'app «può accedere a qualsiasi dato associato al permesso». Un permesso delegato è limitato da ciò che l'utente collegato può già vedere; un permesso applicativo non è limitato da nessuno.

Tutti e quattro i permessi richiedono il consenso amministrativo, e Microsoft limita chi può concederli ai ruoli Privileged Role Administrator e Global Administrator. Quel singolo clic di consenso — spesso dato una sola volta, durante l'onboarding, da chiunque si trovasse presente — è ciò che trasforma un App Registration in una concessione di accesso permanente, valida sull'intero tenant, che nessuno rivede più.

Fonte: riferimento ai permessi di Microsoft Graph.

Come funziona

Un permesso applicativo si associa a un service principal, l'identità locale al tenant di un App Registration. Una volta concesso, il service principal si autentica con una propria credenziale — un client secret o un certificato — tramite il flusso OAuth 2.0 client credentials. Il token di accesso risultante porta il permesso nella sua claim roles, e Microsoft Graph applica l'accesso basandosi unicamente su quella claim. Non c'è alcun contesto utente a cui ricorrere, e nessun limite di consenso per singola risorsa: un'app con Files.ReadWrite.All può accedere a un file che non le è mai stato condiviso, in un sito con cui non ha nessun'altra relazione.

RoleManagement.ReadWrite.Directory appartiene a una categoria ancora più ristretta e pericolosa. La documentazione dei permessi di Microsoft stessa segnala una classe di «permessi che consentono di concedere autorizzazioni» — permessi che lasciano che un'applicazione distribuisca privilegi aggiuntivi a sé stessa, ad altre applicazioni o a qualsiasi utente — come qualcosa che richiede particolare cautela (riferimento ai permessi di Microsoft Graph). RoleManagement.ReadWrite.Directory è esattamente questo tipo di permesso per i ruoli di directory di Entra: un'app che lo possiede può assegnare qualsiasi ruolo Entra integrato, incluso Global Administrator, a qualsiasi security principal — inclusa sé stessa.

La catena di attacco: da una credenziale trapelata a Global Administrator

Non si tratta di una composizione teorica di due permessi pericolosi — è una tecnica documentata. La ricerca di Semperis (pubblicata come «EntraGoat Scenario 2») ripercorre esattamente questo percorso di escalation dall'inizio alla fine.

Fase 1 — Esposizione della credenziale

Un attaccante recupera un certificato codificato in base64 e una password lasciati negli artefatti di una pipeline CI/CD.

Fase 2 — Attribuzione

L'impronta digitale (thumbprint) del certificato viene confrontata con i metadati keyCredentials.customKeyIdentifier di un service principal, identificando a quale app appartiene.

Fase 3 — Autenticazione app-only

L'attaccante si autentica come il service principal tramite il flusso OAuth 2.0 client credentials — nessuna richiesta MFA, nessuna policy di accesso condizionale da soddisfare, perché non c'è alcun accesso interattivo.

Fase 4 — Ricognizione

L'attaccante ispeziona la claim roles del token e scopre che il service principal possiede già AppRoleAssignment.ReadWrite.All — un permesso che gli consente di assegnare ruoli applicativi Graph a qualsiasi service principal, incluso sé stesso.

Fase 5 — Auto-escalation

Usando quel permesso, l'attaccante assegna RoleManagement.ReadWrite.Directory allo stesso service principal.

Fase 6 — Assegnazione del ruolo

Con un nuovo token che porta il nuovo permesso, l'attaccante aggiunge il service principal al ruolo di directory Global Administrator — una chiamata semplice come New-MgDirectoryRoleMemberByRef contro l'ID del template di ruolo ben noto di Global Administrator (62e90394-69f5-4237-9190-012177145e10).

Fase 7 — Takeover

Poiché i ruoli di directory di Entra vengono valutati dinamicamente a runtime invece di essere incorporati nel token, il service principal diventa un Global Administrator pienamente privilegiato dalla sua chiamata successiva — da quel momento l'attaccante può reimpostare la password di qualsiasi amministratore.

AppRoleAssignment.ReadWrite.All (già posseduta)
        |
        v
  assegnare RoleManagement.ReadWrite.Directory a sé stesso
        |
        v
  aggiungere il service principal al ruolo Global Administrator
        |
        v
  reimpostare la password dell'admin target -> takeover completo del tenant

🚨 Pericolo: la fase 4 è quella che i difensori si lasciano sfuggire più spesso. Il risultato pericoloso qui non è un singolo permesso sovrapprivilegiato — è la combinazione. AppRoleAssignment.ReadWrite.All da solo permette a un'app di concedere permessi Graph ai service principal; RoleManagement.ReadWrite.Directory da solo permette a un'app di gestire i ruoli di directory. Nessuna revisione individua la coppia, a meno che qualcuno non cerchi specificamente permessi che consentono di concedere autorizzazioni.

Rilevamento

Concentrate il rilevamento sul momento in cui un permesso pericoloso viene concesso e sul momento in cui viene usato per toccare i ruoli di directory — entrambi vengono registrati di default nel log di audit di Microsoft Entra, senza bisogno di alcun componente aggiuntivo premium.

Questa è la guida ufficiale documentata da Microsoft — vedete Operazioni di sicurezza di Microsoft Entra per le applicazioni, che fornisce anche rilevamenti Microsoft Sentinel già pronti proprio per questo schema «app role with sensitive access» e per ServicePrincipalAssignedPrivilegedRole.

Definire una baseline delle concessioni esistenti

Per definire una baseline di ciò che è già stato concesso, interrogate direttamente le assegnazioni di ruolo applicativo esistenti invece di attendere il prossimo evento di audit:

# Enumerate service principals holding any of the four dangerous permissions
$dangerousRoleIds = @(
    "19dbc75e-c2e2-444c-a770-ec69d8559fc7", # Directory.ReadWrite.All
    "e2a3a72e-5f79-4c64-b1b1-878b674786c9", # Mail.ReadWrite
    "75359482-378d-4052-8f01-80520e7db3cd", # Files.ReadWrite.All
    "9e3f62cf-ca93-4989-b6ce-bf83c28f9fe8"  # RoleManagement.ReadWrite.Directory
)
$graphSp = Get-MgServicePrincipal -Filter "appId eq '00000003-0000-0000-c000-000000000000'"
Get-MgServicePrincipalAppRoleAssignedTo -ServicePrincipalId $graphSp.Id -All |
    Where-Object { $_.AppRoleId -in $dangerousRoleIds }

Tenete d'occhio anche i log di attività di Microsoft Graph per un service principal che improvvisamente inizia a chiamare /roleManagement/directory/roleAssignments o /servicePrincipals/{id}/appRoleAssignedTo — endpoint che un'integrazione normale (sincronizzazione email, file, directory) non ha motivo di toccare.

Remediation

1. Classificate i quattro permessi come ad alto impatto. In Entra ID > Enterprise applications > Consent and permissions > Permission classifications, contrassegnate Directory.ReadWrite.All, Mail.ReadWrite, Files.ReadWrite.All e RoleManagement.ReadWrite.Directory come high impact così che gli utenti ordinari non possano mai darvi consenso, anche se il consenso utente è altrimenti abilitato (Configurare come gli utenti danno il consenso alle applicazioni).
2. Instradate tutto il resto attraverso il flusso di consenso amministrativo. Abilitate il flusso di consenso amministrativo così che un utente bloccato possa richiedere una revisione invece che la richiesta scompaia silenziosamente — ma abbinatelo alla fase 1, perché questo flusso conta solo se gli utenti non possono semplicemente auto-concedersi il consenso aggirandolo.
3. Preferite permessi più ristretti. Mail.ReadWrite e Files.ReadWrite.All sono spesso sovradimensionati rispetto a ciò che l'integrazione fa realmente — una policy di accesso applicativo può limitare Mail.ReadWrite a cassette postali specifiche invece che a tutte quelle del tenant, e il consenso specifico per risorsa può ridurre l'accesso ai file al di sotto di Files.ReadWrite.All.
4. Trattate la credenziale come un segreto Tier 0. Ognuno di questi permessi è sicuro solo quanto il certificato o il client secret che lo protegge — vedete Rotazione dei Segreti App Registration di Entra per capire come appaiono in pratica i segreti «obsoleti» e «sovracondivisi», e non lasciate mai che uno finisca in un artefatto CI/CD come descrive la ricerca di Semperis.
5. Limitate persino da dove il service principal può autenticarsi. L'accesso condizionale per le identità workload applica policy di localizzazione e rischio di accesso alle autenticazioni dei service principal verso Microsoft Graph, e la valutazione continua dell'accesso per le identità workload revoca un token quasi in tempo reale se il segnale di rischio cambia durante la sessione.
6. Rieseguite periodicamente il report dei consensi concessi alle applicazioni, non solo in fase di onboarding — un audit dei consensi concessi fa emergere permessi che nessuno ricorda di aver approvato, e un permesso che era giustificato due riorganizzazioni fa raramente lo è ancora.
7. Integrate le assegnazioni di ruolo dei service principal nella vostra revisione degli accessi privilegiati, insieme alle assegnazioni PIM umane — un service principal in Global Administrator è esattamente pericoloso quanto un Global Admin umano permanente, e CVE-2025-55241 ricorda quanta portata abbia quel singolo ruolo.

Come EtcSec rileva tutto questo

L'audit Entra ID di EtcSec verifica esattamente questa esposizione: APP_DANGEROUS_PERMISSION_DIR, APP_DANGEROUS_PERMISSION_MAIL, APP_DANGEROUS_PERMISSION_FILES e APP_DANGEROUS_PERMISSION_ROLE segnalano ciascuno un service principal che possiede uno dei quattro permessi sopra, e APP_CONSENT_GRANTED_TENANT_WIDE segnala i consensi concessi a livello di tutti gli utenti del tenant invece che a un gruppo delimitato.