Entra App-Registrierung: Gefährliche Graph-API-Berechtigungen erkennen und beheben

Gefährliche Graph-API-Berechtigungen bei Entra-App-Registrierungen machen aus einem einzigen Admin-Consent-Klick ein dauerhaftes, tenant-weites Credential. Directory.ReadWrite.All, Mail.ReadWrite, Files.ReadWrite.All und RoleManagement.ReadWrite.Directory sind Anwendungsberechtigungen (App-Only-Berechtigungen) — Grants, die es einem Service Principal erlauben, ohne angemeldeten Benutzer und ohne Scoping auf einzelne Objekte im gesamten Microsoft-365-Tenant zu agieren. Dieser Leitfaden erklärt, was jede Berechtigung tatsächlich erlaubt, zeigt eine dokumentierte Angriffskette, die sie zu voller Kontrolle als Globaler Administrator verkettet, und beschreibt, wie Sie die Grants erkennen und beheben.

Gefährliche Graph-API-Berechtigungen bei Entra-App-Registrierungen erklärt

Alle vier sind Anwendungsberechtigungen, auch App-Only-Berechtigungen genannt. Microsofts eigene Graph-Dokumentation zieht die Grenze klar: Anwendungsberechtigungen „funktionieren im App-Only-Access-Szenario, ohne dass ein angemeldeter Benutzer vorhanden ist", und die App „kann auf jede Daten zugreifen, die mit der Berechtigung verknüpft sind". Eine delegierte Berechtigung ist durch das begrenzt, was der angemeldete Benutzer bereits sehen kann; eine Anwendungsberechtigung ist durch niemanden begrenzt.

Alle vier Berechtigungen erfordern Admin-Consent, und Microsoft schränkt ein, wer sie erteilen darf: nur Privileged Role Administrator und Globaler Administrator. Genau dieser eine Consent-Klick — oft einmalig erteilt, während des Onboardings, von wem auch immer gerade im Raum war — macht aus einer App-Registrierung einen dauerhaften, tenant-weiten Zugriffs-Grant, den niemand mehr überprüft.

Quelle: Microsoft Graph Permissions Reference.

Wie es funktioniert

Eine Anwendungsberechtigung ist an einen Service Principal gebunden, die tenant-lokale Identität einer App-Registrierung. Nach der Erteilung authentifiziert sich der Service Principal mit einem eigenen Credential — einem Client Secret oder Zertifikat — über den OAuth-2.0-Client-Credentials-Flow. Das resultierende Access Token trägt die Berechtigung im roles-Claim, und Microsoft Graph erzwingt den Zugriff allein anhand dieses Claims. Es gibt keinen Benutzerkontext, auf den man zurückgreifen könnte, und keine Consent-Grenze pro Ressource: Eine App mit Files.ReadWrite.All kann eine Datei anfassen, für die sie nie freigegeben wurde, in einer Site, zu der sie keinerlei andere Beziehung hat.

RoleManagement.ReadWrite.Directory fällt in eine noch kleinere, gefährlichere Kategorie. Microsofts eigene Berechtigungsdokumentation kennzeichnet eine Klasse von „Berechtigungen, die das Erteilen von Autorisierung erlauben" — Berechtigungen, mit denen eine Anwendung sich selbst, anderen Anwendungen oder jedem Benutzer zusätzliche Privilegien zuweisen kann — als besonders vorsichtig zu behandeln (Microsoft Graph Permissions Reference). RoleManagement.ReadWrite.Directory ist für Entra-Verzeichnisrollen genau diese Art von Berechtigung: Eine App mit diesem Recht kann jede integrierte Entra-Rolle, einschließlich Globaler Administrator, an jeden Sicherheitsprinzipal zuweisen — einschließlich sich selbst.

Die Angriffskette: Vom geleakten Credential zum Globalen Administrator

Das ist keine theoretische Kombination zweier gefährlicher Berechtigungen — es ist eine dokumentierte Technik. Semperis-Research (veröffentlicht als „EntraGoat Scenario 2") geht diesen Eskalationspfad Schritt für Schritt vollständig durch.

Schritt 1 — Credential-Exposition

Ein Angreifer findet ein base64-kodiertes Zertifikat samt Passwort, das in CI/CD-Pipeline-Artefakten zurückgelassen wurde.

Schritt 2 — Zuordnung

Der Zertifikats-Thumbprint wird mit den keyCredentials.customKeyIdentifier-Metadaten eines Service Principal abgeglichen, um herauszufinden, zu welcher App er gehört.

Schritt 3 — App-Only-Authentifizierung

Der Angreifer authentifiziert sich als Service Principal über den OAuth-2.0-Client-Credentials-Flow — keine MFA-Abfrage, keine Conditional-Access-Anmelderichtlinie zu erfüllen, weil es überhaupt keine interaktive Anmeldung gibt.

Schritt 4 — Aufklärung

Der Angreifer prüft den roles-Claim des Tokens und stellt fest, dass der Service Principal bereits AppRoleAssignment.ReadWrite.All besitzt — eine Berechtigung, mit der er Graph-App-Rollen an jeden Service Principal zuweisen kann, einschließlich sich selbst.

Schritt 5 — Selbst-Eskalation

Mit dieser Berechtigung weist der Angreifer RoleManagement.ReadWrite.Directory demselben Service Principal zu.

Schritt 6 — Rollenzuweisung

Mit einem frischen Token, das die neue Berechtigung trägt, fügt der Angreifer den Service Principal der Verzeichnisrolle Globaler Administrator hinzu — ein Aufruf, so simpel wie New-MgDirectoryRoleMemberByRef gegen die bekannte Rollenvorlagen-ID von Globaler Administrator (62e90394-69f5-4237-9190-012177145e10).

Schritt 7 — Übernahme

Da Entra-Verzeichnisrollen dynamisch zur Laufzeit ausgewertet werden statt fest im Token verankert zu sein, ist der Service Principal bereits beim nächsten Aufruf vollständig privilegierter Globaler Administrator — von diesem Punkt an kann der Angreifer das Passwort jedes Admins zurücksetzen.

AppRoleAssignment.ReadWrite.All (bereits vorhanden)
        |
        v
  RoleManagement.ReadWrite.Directory sich selbst zuweisen
        |
        v
  Service Principal der Rolle Globaler Administrator hinzufügen
        |
        v
  Passwort des Ziel-Admins zurücksetzen -> vollständige Tenant-Übernahme

🚨 Gefahr: Schritt 4 ist der Teil, den Verteidiger am häufigsten übersehen. Das Gefährliche hier ist nicht eine einzelne überprivilegierte Berechtigung — es ist die Kombination. AppRoleAssignment.ReadWrite.All allein erlaubt einer App, Graph-Berechtigungen an Service Principals zu vergeben; RoleManagement.ReadWrite.Directory allein erlaubt einer App, Verzeichnisrollen zu verwalten. Kein Review erkennt das Paar, außer jemand sucht gezielt nach berechtigungsvergebenden Berechtigungen.

Erkennung

Fokussieren Sie die Erkennung auf den Moment, in dem eine gefährliche Berechtigung erteilt wird, und auf den Moment, in dem sie genutzt wird, um Verzeichnisrollen anzufassen — beides wird standardmäßig im Microsoft-Entra-Audit-Log protokolliert, ohne Premium-Add-on.

Das ist Microsofts eigene dokumentierte Anleitung — siehe Microsoft Entra Security Operations for Applications, das auch fertige Microsoft-Sentinel-Detections für genau dieses Muster „App-Rolle mit sensiblem Zugriff" liefert, ebenso für ServicePrincipalAssignedPrivilegedRole.

Bestehende Grants baseline

Um zu ermitteln, was bereits erteilt ist, fragen Sie bestehende App-Rollenzuweisungen direkt ab, statt auf das nächste Audit-Event zu warten:

# Service Principals mit einer der vier gefährlichen Berechtigungen ermitteln
$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 }

Beobachten Sie außerdem die Microsoft-Graph-Activity-Logs auf einen Service Principal, der plötzlich beginnt, /roleManagement/directory/roleAssignments oder /servicePrincipals/{id}/appRoleAssignedTo aufzurufen — Endpunkte, die eine normale Integration (Mail-Sync, File-Sync, Directory-Sync) nicht anfassen müsste.

Behebung

1. Stufen Sie die vier Berechtigungen als High Impact ein. Markieren Sie unter Entra ID > Enterprise-Anwendungen > Consent und Berechtigungen > Berechtigungsklassifizierungen Directory.ReadWrite.All, Mail.ReadWrite, Files.ReadWrite.All und RoleManagement.ReadWrite.Directory als High Impact, damit normale Benutzer ihnen niemals zustimmen können — selbst wenn User-Consent ansonsten aktiviert ist (Configure how users consent to applications).
2. Leiten Sie alles andere über den Admin-Consent-Workflow. Aktivieren Sie den Admin-Consent-Workflow, damit ein blockierter Benutzer eine Prüfung anfordern kann, statt dass die Anfrage stillschweigend verschwindet — kombinieren Sie das aber mit Schritt 1, denn der Workflow greift nur, wenn Benutzer sich nicht einfach selbst daran vorbei zustimmen können.
3. Bevorzugen Sie engere Berechtigungen. Mail.ReadWrite und Files.ReadWrite.All sind für das, was die Integration tatsächlich braucht, häufig überprivilegiert — eine Application Access Policy kann Mail.ReadWrite auf bestimmte Postfächer statt auf jedes Postfach im Tenant beschränken, und Resource-Specific Consent kann den Dateizugriff unter Files.ReadWrite.All einschränken.
4. Behandeln Sie das Credential wie ein Tier-0-Secret. Jede dieser Berechtigungen ist nur so sicher wie das Zertifikat oder Client Secret, das sie schützt — siehe Entra App-Registrierung: Credential-Rotation dafür, wie „veraltete" und „zu weit geteilte" Secrets in der Praxis aussehen, und lassen Sie niemals eines so in einem CI/CD-Artefakt liegen, wie es die Semperis-Research beschreibt.
5. Schränken Sie ein, von wo aus sich der Service Principal überhaupt authentifizieren kann. Conditional Access für Workload-Identitäten erzwingt Standort- und Anmelde-Risiko-Richtlinien für Service-Principal-Authentifizierungen gegenüber Microsoft Graph, und Continuous Access Evaluation für Workload-Identitäten widerruft ein Token nahezu in Echtzeit, wenn sich das Risikosignal mitten in der Sitzung ändert.
6. Führen Sie den App-Consent-Grant-Report regelmäßig erneut aus, nicht nur beim Onboarding — ein Consent-Grant-Audit deckt Berechtigungen auf, an deren Genehmigung sich niemand mehr erinnert, und eine Berechtigung, die vor zwei Reorganisationen gerechtfertigt war, ist es selten noch heute.
7. Beziehen Sie Rollenzuweisungen von Service Principals in Ihre Privileged-Access-Review ein, neben menschlichen PIM-Zuweisungen — ein Service Principal als Globaler Administrator ist genauso gefährlich wie ein dauerhaft privilegierter menschlicher Globaler Admin, und CVE-2025-55241 erinnert daran, wie viel Reichweite diese eine Rolle hat.

Wie EtcSec das erkennt

EtcSecs Entra-ID-Audit prüft genau auf diese Exposition: APP_DANGEROUS_PERMISSION_DIR, APP_DANGEROUS_PERMISSION_MAIL, APP_DANGEROUS_PERMISSION_FILES und APP_DANGEROUS_PERMISSION_ROLE kennzeichnen jeweils einen Service Principal, der eine der vier oben genannten Berechtigungen besitzt, und APP_CONSENT_GRANTED_TENANT_WIDE kennzeichnet Consent-Grants, die für jeden Benutzer im Tenant statt für eine begrenzte Gruppe gelten.