EntraGoat Szenario 2: Ausnutzung von App-Only Graph-Berechtigungen in Entra ID

Anmerkung der Redaktion

Dieses Szenario ist Teil einer Reihe von Beispielen, die die Verwendung von EntraGoat, unserer Entra ID Simulationsumgebung, demonstrieren. Einen Überblick über EntraGoat und seinen Wert können Sie hier lesen.

Zeichnen Sie mir die Krone (und Rollen)

EntraGoat Szenario 2 zeigt, wie die zertifikatsbasierte Authentifizierung in Verbindung mit einem bestehenden Dienstprinzipal und überprivilegierten Anwendungsberechtigungen zu einer Kompromittierung des globalen Administrators führen kann.

Der Angreifer beginnt mit dem Zugriff auf ein durchgesickertes Zertifikat, das durch CI/CD-Pipeline-Artefakte offengelegt wurde. Das Zertifikat ist für einen Dienstprinzipal gültig, der über die AppRoleAssignment.ReadWrite.All Antragsgenehmigung.

Indem er sich in einem reinen App-Kontext authentifiziert, missbraucht der Angreifer diese Berechtigung, um eine andere Berechtigung zu vergeben, RoleManagement.ReadWrite.Directorydemselben Dienstprinzipal zu. Auf diese Weise kann der Dienstprinzipal jede beliebige Verzeichnisrolle (einschließlich Global Administrator) selbst einem beliebigen Sicherheitsprinzipal zuweisen. Schließlich setzt der Angreifer das Passwort des Administrators zurück und holt sich das Szenario-Flag.

Dieses Szenario verdeutlicht die Risiken von ausufernden Zertifikaten, überprivilegierten Graph-Bereichen und die Natur von reinen App-Tokens. Es verdeutlicht auch den Unterschied zwischen der Durchsetzung von Berechtigungen über Token-Ansprüche und der Echtzeit-Auswertung von Verzeichnissen, die wir in diesem Walkthrough erklären werden.

Übersicht der Angriffswege

1. Anfänglicher Fußabdruck: Der Angreifer erhält ein base64-kodiertes Zertifikat und das zugehörige Passwort, das angeblich durch die Erkundung der CI/CD-Pipeline aufgedeckt wurde.
2. Identifikation: Das Zertifikat passt zu einem bestehenden Dienstprinzipal namens Corporate Finance Analytics.
3. Missbrauch der Erlaubnis: Der Angreifer authentifiziert sich mit dem Zertifikat und stellt fest, dass der Dienstherr über AppRoleAssignment.ReadWrite.All Antragsgenehmigung.
4. Privilegienerweiterung: Der Angreifer verwendet diese Berechtigung, um RoleManagement.ReadWrite.Directory an denselben Dienstherrn.
5. Rollenübernahme: Mit Zugriff auf die Verzeichnisrollenverwaltung fügt der Angreifer den Dienstprinzipal als Mitglied der Verzeichnisrolle Globaler Administrator hinzu.
6. Kontokompromittierung: Der Angreifer setzt das Passwort des Global Admin-Benutzers zurück und authentifiziert sich, um die Flagge abzurufen.

Angriffsfluss

Abbildung 1 zeigt den Ablauf dieses Angriffs.

Wie umgeht dieser Angriff die normalen Authentifizierungskontrollen?

Dieses Szenario missbraucht das Anwendungsmodell von Microsoft Entra ID, bei dem Anwendungen aus einer globalen Registrierung und einem tenant-lokalen Dienstprinzipal bestehen. App-exklusive Berechtigungen werden auf der Ebene der Anwendungsregistrierung angefordert und auf der Ebene des Service Principals gewährt. Darüber hinaus können sich Service Principals unabhängig von Benutzern mit dem OAuth 2.0 Client Credentials Flow authentifizieren.

Wenn ein gültiges Zertifikat für einen Dienstherrn registriert wird (bei dessen keyCredentials.customKeyIdentifier Eigenschaft), kann es zur Authentifizierung ohne interaktive Eingabe oder Multifaktor-Authentifizierung (MFA) verwendet werden. Dieser reine App-Authentifizierungspfad funktioniert außerhalb des benutzerzentrierten Schutzes und ermöglicht einem kompromittierten Zertifikat den direkten Zugriff auf Graph-APIs mit den dem Dienstprinzipal zugewiesenen Berechtigungen oder Rollen.

Dieser Angriffspfad kombiniert:

• Schwache Zertifikatshygiene (weniger relevant für Entra ID)
• Übermäßige und nicht überwachte App-Berechtigungen
• Die bewusste Gestaltung von AppRoleAssignment.ReadWrite.All zur Umgehung* der Admin-Zustimmung in reinen App-Kontexten

Durch die Verkettung dieser Bedingungen können sich Angreifer als Dienstprinzipal authentifizieren und zu sensiblen Graph-Bereichen wie RoleManagement.ReadWrite.Directory sich selbst eine privilegierte Rolle (bis hin zum globalen Administrator) zu gewähren, ohne jemals eine Benutzersitzung zu berühren, nachdem sie die Anmeldedaten des Dienstherrn erhalten haben.

HINWEIS: Weitere Angriffspfade können mit diesem verkettet werden, da jede Identität mit Application Administrator oder Cloud Application Administrator Rollen oder jeden Dienstauftraggeber mit der Application.ReadWrite.All App-Rolle oder Eigentum über den Ziel-Service-Principal - wie in Szenario 1-Angriffsweg ausnutzen, indem sie Anmeldeinformationen für den Backdoor-Zugang zum Dienstprinzipal hinzufügen.

Schließlich ist es wichtig, zwischen verschiedenen Verwendungszwecken der zertifikatsbasierten Authentifizierung (CBA) zu unterscheiden. Wenn die CBA-Konfiguration auf Mandantenebene deaktiviert ist, gilt diese Einschränkung nur für die interaktive Benutzerauthentifizierung - nicht für den OAuth-Client-Assertionsfluss für Anwendungen. Service-Principals können sich immer noch mit Zertifikaten authentifizieren, wenn ein gültiger Berechtigungsnachweis in ihrem Mandant registriert ist. KeyCredentials Eigenschaft. Entra ID behandelt dies als einen separaten Authentifizierungsmechanismus. Diese architektonische Entkopplung kann zu falschen Annahmen über die Durchsetzung von mieterweiten Zertifikatsrichtlinien führen.

*Tatsächlich "umgeht" diese Berechtigung nicht die Zustimmung des Administrators - sie ist eine Zustimmung des Administrators. Die Berechtigung selbst erfordert zunächst die Zustimmung des Administrators und ermöglicht es dem Inhaber (und natürlich auch den Gegnern), anderen Anwendungen im Rahmen der Maschine-zu-Maschine-Interaktion programmatisch die Zustimmung zu erteilen.

Wie Sie den Missbrauch einer reinen App-Authentifizierung erkennen und abwehren können

Die Abwehrhaltung in Entra ID muss sich darauf konzentrieren, die Verwendung breiter App-Berechtigungen einzuschränken und Dienstprinzipale, die sensible Rollen wie AppRoleAssignment.ReadWrite.All und RoleManagement.ReadWrite.Directory.

Sicherheitsteams sollten:

• Prüfen Sie regelmäßig die Dienstprinzipien für Anwendungsrollen mit hohen Rechten
• Verfolgen Sie die Erstellung neuer Berechtigungsnachweise für Service-Principals, insbesondere wenn sie außerhalb der genehmigten Automatisierung erfolgt.
• Erkennen Sie Änderungen an App-Rollenzuweisungen, die eine Eskalation von Privilegien ermöglichen könnten

Semperis Lösungen bieten mehrere Verteidigungsebenen, beginnend mit Indikatoren für die Gefährdung (IOEs) und Indikatoren für die Kompromittierung (IOCs), die riskante Konfigurationen identifizieren und vor gefährlichen Standardeinstellungen warnen, wie z. B. Dienstprinzipale mit sensiblen Berechtigungen, zu freizügige Autorisierungsrichtlinien für die Konfiguration von Anwendungen und fehlende Kontrollen für die Sicherheit von Dienstprinzipalen.

Vertiefung des Szenarios: Schritt für Schritt durch die Lösung gehen

Schauen wir uns die Schritte an, mit denen die Umgehung der Authentifizierungskontrollen simuliert wird, um zu verstehen, wie Global Admin dadurch kompromittiert werden kann.

Schritt 1: Erste Schritte mit einem kompromittierten Zertifikat

Wir beginnen Szenario 2 mit einem kompromittierten Zertifikat(Abbildung 2), das angeblich bei der Erkundung der CI/CD-Pipeline entwendet wurde. Es ist base64-verschlüsselt, passwortgeschützt und wird zurückgelassen wie eine Ladung, die von einem DevOps-LKW fällt.

Um den Eigentümer des Zertifikats zu identifizieren, dekodieren wir es zunächst in ein brauchbares X509Certificate2-Objekt und untersuchen seine Metadaten:

      $certBase64 = "[BASE64_CERTIFICATE_BLOG]"
$certPassword = "GoatAccess!123"

$certBytes = [System.Convert]::FromBase64String($certBase64)
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2($certBytes, $certPassword, [System.Security.Cryptography.X509Certificates.X509KeyStorageFlags]::Exportable)

$cert | Select-Object Subject, Issuer, Thumbprint, NotBefore, NotAfter | Format-List

Wir können sehen, dass das Zertifikat selbstsigniert ist und für eine App namens Corporate Finance Analytics (Abbildung 3).

Alternativ können wir alle Anwendungsregistrierungen im Mandanten durchlaufen und nach einem passenden Zertifikats-Thumbprint suchen. Jedes Anwendungsobjekt in Entra ID hat eine KeyCredentials Attribut, das Metadaten über Zertifikate oder öffentliche Schlüssel enthält, die mit der App verknüpft sind und für die Authentifizierung in reinen App-Kontexten verwendet werden. Jeder Eintrag enthält eine CustomKeyIdentifierdie den Fingerabdruck des Zertifikats speichert (Abbildung 4) in binärer Form und ermöglicht das Nachschlagen oder den Abgleich mit bekannten Zertifikaten.

Mit der folgenden Funktion können Sie die Suche durchführen:

      function Find-AppRegistrationByThumbprint {
    param([string]$Thumbprint)
    
    # Get all application registrations and check for matching certificate thumbprint
    $allApps = Get-MgApplication -All
    
    foreach ($app in $allApps) {
        if ($app.KeyCredentials) {
            foreach ($keyCred in $app.KeyCredentials) {
                # Compare thumbprints (certificate matching)
                if ($keyCred.CustomKeyIdentifier) {
                    $credThumbprint = [System.Convert]::ToHexString($keyCred.CustomKeyIdentifier)
                    if ($credThumbprint -eq $Thumbprint) {
                        Write-Host "Certificate match found for: $($app.DisplayName)" -ForegroundColor Cyan
                        return $app
                    }
                }
            }
        }
    }
    return $null
}

Microsoft Graph speichert oder liefert niemals den eigentlichen Zertifikatsinhalt oder die privaten Schlüssel. Die Abfrage der KeyCredential Attribut mit Graph API nur die registrierten Zertifikats-Metadaten, niemals das Zertifikat selbst, unabhängig davon, wie hoch die Privilegien der anfordernden Identität sind. Dies unterstreicht die Notwendigkeit einer sicheren Handhabung und Speicherung von privaten Schlüsseln im gesamten Unternehmen.

Um den zugehörigen Dienstprinzipal zu identifizieren, authentifizieren wir uns als Benutzer mit niedrigen Privilegien mit Connect-MgGraph. Sobald wir die AppId hinter Corporate Finance Analytics (Abbildung 5), können wir uns direkt als Auftraggeber des Dienstes mit dem Zertifikat authentifizieren.

HINWEIS: Obwohl CBA im Tenant deaktiviert ist(Abbildung 6), ist die Authentifizierung beim Service Principal mit dem Zertifikat weiterhin erfolgreich. Das liegt daran, dass sich die benutzerbasierte CBA auf eine interaktive, browserbasierte Anmeldung bezieht, während sich die Service Principals auf einen nicht-interaktiven OAuth 2.0-Client-Anmeldedatenfluss mit Zertifikatsbestätigungen verlassen. Die Deaktivierung von CBA wirkt sich nur auf die interaktive Benutzerauthentifizierung mit Zertifikaten aus und hat keine Auswirkungen auf die programmatische Dienstprinzipalauthentifizierung. Es handelt sich um getrennte Authentifizierungspfade in der Entra ID-Plattform.

Schritt 2: Erkennen von App-Berechtigungen und Aufbau unseres Angriffspfads

Nachdem wir uns mit dem Zertifikat als Auftraggeber des Dienstes authentifiziert haben, überprüfen wir dessen roles Anspruch in dem gewährten JWT über die Get-MgContext und entdecken Sie, dass es den Befehl AppRoleAssignment.ReadWrite.All (Abbildung 7). Mit dieser Berechtigung kann der Service-Principal JEDE Anwendungsrolle allen Service-Principals zuweisen - auch sich selbst.

Um zu eskalieren, zählen wir den Microsoft Graph-Dienstprinzipal auf (GraphAggregatorService), die alle zuweisbaren OAuth-Rollen enthält und in jedem Entra-Tenant als Erstanbieteranwendung vorhanden ist. Sie wird aus einer globalen Anwendungsregistrierung instanziiert, die in Microsofts eigenem Tenant gehostet wird, und kann durch die statische AppId von 00000003-0000-0000-c000-000000000000. Wie alle mandantenfähigen Anwendungen erscheint sie in jedem Kundenmieter als eine lokaler Dienstherr-die eigentliche Identität, die zur Durchsetzung der Zugriffskontrolle verwendet wird. (Wir haben das Entra ID-Anwendungsmodell bereits in Szenario 1.)

Die AppId in Abbildung 8 verweist auf die globale Definition von Microsoft Graph, die alle zuweisbaren OAuth-Rollen enthält, die App-only-Berechtigungsbereiche definieren wie Directory.Read.All oder RoleManagement.ReadWrite.Directory. Jeder Mandant verfügt über eine lokale Service-Principal-Instanz der globalen Anwendung und OAuth-Berechtigungen werden auf der Ebene des Dienstherrn zugewiesen über AppRoleAssignment. Dadurch können Anwendungen unabhängig von den Benutzern betrieben werden, wobei die Geltungsbereiche im globalen App-Manifest definiert sind, aber vom lokalen Dienstprinzipal durchgesetzt werden.

Spaßfakt: Es gibt derzeit 576 einzigartige Graph-Berechtigungen!

Jetzt, da wir den Microsoft Graph-Dienstprinzipal gefunden haben und über seine zuweisbaren OAuth-Berechtigungen verfügen, müssen wir im nächsten Schritt auswählen, mit welcher Berechtigung wir eskalieren wollen. Die für unseren Angriffszweck wirkungsvollste ist RoleManagement.ReadWrite.Directorylaut einer Notiz auf der offiziellen Dokumentation (Abbildung 9):

Diese Zugriffsebene ist von vornherein gefährlich. Sie ermöglicht die vollständige programmatische Kontrolle über die APIs zur Rollenverwaltung von Entra ID und unterstützt die direkte Ausweitung von Berechtigungen ohne Benutzerinteraktion.

Schritt 3: Zuweisen von gefährlichen Berechtigungen

Wir können diese Berechtigung unserem kompromittierten Dienstprinzipal mit den folgenden Befehlen zuweisen:

      $roleManagementRole = $graphSP.AppRoles | Where-Object { $_.Value -eq "RoleManagement.ReadWrite.Directory" }

$appRoleAssignmentParams = @{
    PrincipalId = $SP.Id
    ResourceId = $graphSP.Id
    AppRoleId = $roleManagementRole.Id
}

New-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $SP.Id -BodyParameter $appRoleAssignmentParams

Nachdem dieser Befehl ausgeführt wurde - obwohl wir dem Dienstprinzipal erfolgreich die RoleManagement.ReadWrite.Directory Erlaubnis, wie geprüft durch Get-MgContext-Wir beobachten keine Veränderung im aktuellen Sicherheitskontext (Abbildung 10). Dies ist ein erwartetes Verhalten.

Die von Entra ID ausgestellten Zugangstoken sind wie statische Schnappschüsse von Ansprüchen, die zum Zeitpunkt der Ausstellung des Tokens gewährt wurden. Wenn Connect-MgGraph ausgeführt wird, agiert er als OAuth2.0-Client und initiiert einen Authentifizierungsfluss gegen den Token-Endpunkt (https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/token). Dieser Endpunkt validiert die vorgelegten Anmeldeinformationen und gibt ein signiertes JWT-Zugriffstoken mit den Ansprüchen des Anrufers (wie App-Rollen, Bereiche und Tenant-Kontext) auf der Grundlage des aktuellen Autorisierungsstatus zum Zeitpunkt der Anfrage aus.

Da die Zugriffstoken nicht dynamisch aktualisiert werden, wenn sich die Berechtigungen ändern, werden neu zugewiesene App-Rollen (wie die, die wir gerade hinzugefügt haben) erst angezeigt, wenn ein neues Token explizit angefordert wird. Um die aktualisierten Berechtigungen zu erhalten, müssen wir die bestehende Sitzung beenden (Disconnect-MgGraph) und authentifizieren Sie sich erneut bei ihm (Connect-MgGraph), um die Ausgabe eines neuen Zugriffstokens auszulösen, der die neuen Ansprüche enthält (Abbildung 11).

Mit dem RoleManagement.ReadWrite.Directory erteilt wurde, kann der Dienstprinzipal, den wir haben, jetzt die Zuweisung von Verzeichnisrollen für jede Identität im Mandanten ändern - einschließlich des Hinzufügens seiner eigenen Rolle als globaler Administrator:

      $globalAdminRoleId = "62e90394-69f5-4237-9190-012177145e10" # GA role GUID
$globalAdminRole = Get-MgDirectoryRole -Filter "roleTemplateId eq '$globalAdminRoleId'" -ErrorAction SilentlyContinue

$roleMemberParams = @{
    "@odata.id" = "https://graph.microsoft.com/v1.0/servicePrincipals/$($SP.Id)"
}

New-MgDirectoryRoleMemberByRef -DirectoryRoleId $globalAdminRole.Id -BodyParameter $roleMemberParams

Wenn wir nun die zugewiesenen Rollen überprüfen, die der kompromittierte Dienstprinzipal hat, können wir die GUID des Globalen Administrators sehen(Abbildung 12).

Wenn Sie genau hinschauen, fällt Ihnen vielleicht ein wichtiger Unterschied im Verhalten auf:

Warum ist es notwendig, ein neues JWT für die Identität zu erhalten, nachdem eine App-Berechtigung erteilt wurde, aber nicht, nachdem eine Verzeichnisrolle zugewiesen wurde?

Die Antwort liegt darin, wie Entra ID diese beiden Modelle der Autorisierung durchsetzt:

• Berechtigungen für Anwendungen (wie zum Beispiel RoleManagement.ReadWrite.Directory) werden zum Zeitpunkt der Authentifizierung als statische Ansprüche innerhalb des JWT-Zugriffstokens ausgegeben. Diese Berechtigungen werden in der Datei roles Array-Anspruch (oder scp in delegierten Abläufen). Das Token ist eine kryptografisch signierte Bestätigung, die die App-Rollen und -Bereiche des Aufrufers bei der Ausgabe widerspiegelt, und jede Änderung dieser Berechtigungen erfordert normalerweise eine Neuausgabe des Tokens.
• Verzeichnisrollen (wie zum Beispiel Global Administrator) werden ebenfalls als statische Ansprüche innerhalb des Zugriffstokens ausgegeben, folgen aber einem anderen Durchsetzungsmodell. Token können zwar Verzeichnisrollenzuweisungen über die Option wids Anspruch oder die group Anspruch (im Falle der Gruppenmitgliedschaft), die meisten Microsoft APIs in der Regel diese Rollen zur Laufzeit dynamisch auswerten. Wenn eine Anfrage gestellt wird, fragt das Backend die aktuellen Rollenzuweisungen in Entra ID nach der Objekt-ID des Anrufers ab. Durch diese Echtzeitabfrage können neu zugewiesene Rollen sofort wirksam werden, ohne dass eine Token-Erneuerung erforderlich ist.

Allerdings weist Microsoft in seiner Referenzdokumentation zu den Access Token Claims ausdrücklich darauf hin, dass:

Die roles, groups, scp, und wids Ansprüche sind keine vollständige Liste der Art und Weise, wie eine Ressource einen Benutzer oder eine Anwendung autorisieren kann, und sie sind auch keine vollständige Liste der dem Aufrufer gewährten Berechtigungen. Die Zielressource kann eine andere Methode verwenden, um den Zugriff auf ihre geschützten Ressourcen zu autorisieren.

Schritt 4: Wechseln zu einer Admin-Sitzung

Mit der GA-Rolle, die unserem Dienstprinzipal zugewiesen wurde, verfügen wir nun über volle Rechte auf Verzeichnisebene. Dadurch können wir das Passwort des Zieladministrators zurücksetzen und seine Identität übernehmen(Abbildung 13).

Um den letzten Schritt zu rekapitulieren, werden wir weder TAP noch das Azure-Portal verwenden, wie wir es in Szenario 1 getan haben.

Stattdessen nutzen wir BARKs¹ Get-MSGraphTokenWithUsernamePassword Funktion, um sich bei Microsoft Graph mit den neuen Admin-Zugangsdaten zu authentifizieren und das Flag aus dem /me Endpunkt (Abbildung 14)- und bleiben damit dem Titel dieses Szenarios treu: Zeichnen Sie mir die Krone (und Rollen).

Sobald das Szenario abgeschlossen ist, führen wir das Bereinigungsskript(Abbildung 15) aus, um den ursprünglichen Zustand des Mandanten wiederherzustellen.

Finden Sie Ihre blinden Flecken

Dieses Szenario veranschaulicht, wie App-only Graph-Berechtigungen in Kombination mit zertifikatsbasierter Authentifizierung blinde Flecken in der traditionellen Identitätsverwaltung schaffen können.

Es sind keine Kompromisse zwischen den Benutzern erforderlich. Es ist kein interaktiver Ablauf erforderlich. Durch die Verkettung von zwei Graph-Berechtigungen-AppRoleAssignment.ReadWrite.All und RoleManagement.ReadWrite.Directory-der Angreifer eskaliert stillschweigend einen Dienstprinzipal zu einem globalen Administrator.

Sicherheitsteams müssen Anwendungsberechtigungen und Anmeldeinformationen für Dienstprinzipale als kritische Assets behandeln, nicht als sekundäre Identitäten. Eine strenge Kontrolle über die Verwendung von Zertifikaten und die Zuweisung von Graph-Berechtigungen ist unerlässlich, um eine kopflose Privilegieneskalation zu verhindern, wie sie hier in Szenario 2 dargestellt wurde.

Nehmen Sie Ihre nächste EntraGoat-Herausforderung an

• GitHub - Semperis/EntraGoat
• Was ist EntraGoat? Eine absichtlich verwundbare Entra ID-Simulationsumgebung
• Erste Schritte mit EntraGoat: Entra ID auf die intelligente Art einführen
• Szenario 1: Missbrauch der Eigentumsrechte des Dienstherrn in Entra ID
• Szenario 6: Ausnutzung der zertifikatsbasierten Authentifizierung, um sich als Global Admin in Entra ID auszugeben

Endnote

1. https://github.com/BloodHoundAD/BARK

Haftungsausschluss

Dieser Inhalt wird ausschließlich zu Bildungs- und Informationszwecken bereitgestellt. Er soll das Bewusstsein und die verantwortungsvolle Behebung von Sicherheitslücken fördern, die auf Systemen bestehen können, die Sie besitzen oder zu deren Prüfung Sie berechtigt sind. Die unbefugte Nutzung dieser Informationen zu böswilligen Zwecken, zur Ausbeutung oder zum unrechtmäßigen Zugriff ist strengstens untersagt. Semperis befürwortet oder duldet keine illegalen Aktivitäten und lehnt jede Haftung ab, die aus dem Missbrauch des Materials entsteht. Darüber hinaus übernimmt Semperis keine Garantie für die Richtigkeit oder Vollständigkeit der Inhalte und haftet nicht für Schäden, die sich aus der Verwendung der Inhalte ergeben.