EntraGoat Szenario 3: Ausnutzung des Gruppenbesitzes 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.

GruppenmitgliedSchiffswrack - In Admin-Gewässer gesegelt

EntraGoat Szenario 3 zeigt, wie legitime administrative Funktionen von Entra ID - Gruppenbesitz, rollenzuweisbare Gruppen und Dienstprinzipalverwaltung - zu einem unbeabsichtigten Pfad der Privilegienerweiterung von einem Benutzer mit niedrigen Privilegien zum globalen Administrator verkettet werden können.

Der Angreifer beginnt mit einem kompromittierten IT-Support-Konto, das mehrere Gruppen besitzt, darunter eine, der die Rolle mit dem Application Administrator Rolle. Indem er sich selbst zu dieser Gruppe hinzufügt, erbt der Angreifer die Rolle und erhält weitreichende Kontrolle über Anwendungen und Dienstprinzipien im gesamten Mandanten.

Von dort aus können Sie einen hochwertigen Dienstprinzipal identifizieren, der Mitglied einer anderen rollenzuweisenden Gruppe ist, die die Privileged Authentication Administrator Rolle, fügt der Angreifer ihr ein Client-Geheimnis hinzu, authentifiziert sich als privilegierter Dienstprinzipal und setzt das Kennwort des globalen Administrators zurück.

Dieses Szenario verdeutlicht, wie einzelne legitime Entra ID-Funktionen in Kombination mit falsch konfiguriertem Gruppenbesitz zu einer Kette der Privilegienerweiterung führen können, die ein Konto auf niedriger Ebene zu einer mieterweiten Bedrohung werden lässt.

Übersicht der Angriffswege

1. Die Geschichte des ersten Fußes: Der Angreifer authentifiziert sich als Michael Chenein kompromittierter IT-Support-Spezialist, der laut der Beschreibung des Szenarios "einige Sicherheitsgruppen verwaltet".
2. Aufzählung: Der Angreifer entdeckt den Besitz von sechs Gruppen, darunter eine rollenzuweisbare Gruppe namens IT Application Managers die die Application Administrator Rolle.
3. Privilegienerweiterung: Der Angreifer fügt sich selbst der Sicherheitsgruppe hinzu, um die privilegierte Rolle zu erben.
4. Der Dienst zielt hauptsächlich auf: Mit dem Application Administrator Verzeichnisrolle, identifiziert der Angreifer die Identity Management Portal Dienstherr als Mitglied einer Gruppe mit dem Privileged Authentication Administrator Rolle und fügt ihr ein Client-Geheimnis hinzu.
5. Pivotieren: Der Angreifer authentifiziert sich über den Client Credential Grant OAuth2 Flow als der kompromittierte Service Principal mit dem neu hinzugefügten Geheimnis.
6. Kontokompromittierung: Der Angreifer nutzt die dem Dienstprinzipal innewohnenden Privilegien und setzt das Passwort des globalen Administrators zurück, authentifiziert sich als GA und holt sich das Szenario-Flag.

Angriffsfluss

Abbildung 1 zeigt den Ablauf dieses Angriffs.

Warum dieser Angriff funktioniert

In diesem Szenario werden mehrere legitime Entra ID-Funktionen miteinander verknüpft, die, wenn sie falsch konfiguriert sind, einen Eskalationspfad schaffen:

• Gruppenbesitz: Das Gruppenbesitzmodell von Entra ID bietet umfassende Kontrolle über die Mitgliedschaft und die Eigenschaften. Es ist zwar dazu gedacht, Verwaltungsaufgaben zu delegieren, wird aber riskant, wenn es auf Gruppen mit Rollenzuweisung angewendet oder ungeeigneten Benutzern gewährt wird, da ein Eigentümer sich selbst (oder ein beliebiges kontrolliertes Konto) direkt zur Gruppe hinzufügen und die zugewiesenen Rollen erben kann.
• Rollenzuweisbare Gruppen: Mit rollenzuweisbaren Sicherheitsgruppen können Administratoren Verzeichnisrollen an Gruppen und nicht an einzelne Benutzer zuweisen. Dies vereinfacht die Rollenverwaltung im großen Maßstab, da jedes Mitglied der Gruppe automatisch die zugewiesenen Rollen erhält. In Kombination mit Gruppenbesitzrechten schafft dies einen Weg der Privilegieneskalation, bei dem Gruppenbesitzer sich selbst die Rollen zuweisen können, die den von ihnen kontrollierten Gruppen zugewiesen sind.
• Mitgliedschaft in der Dienstherrngruppe: Dienstprinzipale können wie Benutzer Mitglieder von Sicherheitsgruppen sein und alle diesen Gruppen zugewiesenen Rollen erben. Dieses Design ermöglicht es Administratoren, Anwendungsberechtigungen über die Gruppenzugehörigkeit und nicht über individuelle Rollenzuweisungen zu verwalten. Allerdings bieten Service Principals einzigartige Angriffsflächen, die normale Entra ID Benutzer nicht haben. Diese zusätzlichen Mechanismen schaffen mehr potenzielle Vektoren, um unbefugten Zugriff auf einen privilegierten Dienstprinzipal zu erlangen, der Mitglied einer privilegierten Gruppe ist.
  • Sie können durch Eigentumsverhältnisse kompromittiert werden (wie in Szenario 1 gesehen).
  • Sie unterliegen der Kontrolle durch die Anwendungsverwaltung - Identitäten mit dem integrierten Application Administrator oder Cloud Application Administrator Rollen, benutzerdefinierte Rollen, die die microsoft.directory/applications/credentials/update oder microsoft.directory/servicePrincipals/credentials/update Handlungen oder Dienstherren mit dem Application.ReadWrite.All Berechtigung, die das Hinzufügen oder Ändern von Anmeldeinformationen für Dienstprinzipale erlaubt.
  • Sie können programmatisch über APIs und Automatisierungsworkflows verwaltet werden.
  • Im Gegensatz zu Benutzeridentitäten können sie nicht als PIM-fähig zugewiesen werden; sie können nur aktive Rollenzuweisungen haben (die zeitgebunden sein können). Wenn ein Service-Principal einer rollenzuweisbaren Gruppe angehört, umgeht sein Zugriff die Just-in-Time-Aktivierungskontrollen von PIM und bietet während des Zuweisungsfensters eine stets aktive Rollenmitgliedschaft.
  • Sie können sich in einem reinen App-Kontext (OAuth2-Client-Credentials) mit einem Client-Geheimnis oder -Zertifikat authentifizieren, wodurch benutzerzentrierte Kontrollen wie interaktive MFA und interaktive Conditional Access-Anforderungen umgangen werden.
• Umfang des Anwendungsadministrators: Die Rolle bietet weitreichende Kontrolle über Anwendungsregistrierungen und Dienstprinzipale, einschließlich der Möglichkeit, Authentifizierungsdaten (Geheimnisse und Zertifikate) zu Anwendungen im Tenant hinzuzufügen, was Angreifern die Möglichkeit bietet, hochwertige Dienstprinzipale, die nicht mit der App-Instance-Sperre konfiguriert sind, zu hintergehen.

Jede dieser Entra ID-Funktionen ist legitim und für die administrative Delegation notwendig, aber in Kombination schaffen sie unbeabsichtigte Pfade der Privilegienerweiterung, die eine niedrig privilegierte Identität bis zum Globalen Administrator aufsteigen lassen können.

Wie Sie den Missbrauch von Gruppenbesitz aufdecken und abwehren können

Die Überwachung von Gruppenbesitz ist eine grundlegende Sicherheitsanforderung in jeder Entra ID Umgebung.

Eigentümer können die Mitgliedschaft verwalten, Gruppeneigenschaften ändern und indirekt alle Verzeichnisrollen kontrollieren, die ihren Gruppen zugewiesen sind. Ohne einen klaren Einblick in die Eigentumsverhältnisse und Rollenzuweisungen können die Wege der Privilegieneskalation durch rollenzuweisende Gruppen sowohl für Verteidiger als auch für Auditoren verborgen bleiben.

Verteidiger sollten überwachen und korrelieren:

• Welche rollenzuweisbaren Gruppen gibt es in dem Mandanten?
• Welche Verzeichnisrollen sind diesen Gruppen zugewiesen?
• Wem gehören sie und welche geschäftliche Rechtfertigung gibt es für diesen Besitz?
• Besitzen unprivilegierte Benutzer Gruppen mit privilegierten Rollenzuweisungen?
• Welche Service-Principals sind Mitglieder von rollenzuweisenden Gruppen?
• Gibt es ungenutzte oder verwaiste Gruppen, die außer Betrieb genommen werden können?

Die Lösungen von Semperis helfen, Lücken im Verständnis dieser Fragen mit mehreren Verteidigungsschichten zu schließen, beginnend mit Indikatoren der Gefährdung (IOEs) und Indikatoren der Kompromittierung (IOCs).

Diese Indikatoren erkennen automatisch gefährliche Standardeinstellungen und Fehlkonfigurationen, wie z.B. rollenzuweisende Gruppen mit ungeeigneten Besitzern, Dienstprinzipale mit gefährlichen Berechtigungen und schwache Gruppen-Governance-Baselines, die eine Eskalation der Privilegien durch Manipulation der Gruppenmitgliedschaft ermöglichen, und schlagen Alarm.

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

Die vollständige Anleitung und die dazugehörigen Befehle finden Sie im EntraGoat GitHub Repository unter solutions/EntraGoat-Scenario3-Solution.ps1.

Schritt 1: Erster Fußabdruck

Wir beginnen mit Szenario 3, als Abbildung 2 zeigt, mit Zugriff auf einen kompromittierten niedrigprivilegierten Benutzer namens Michael Cheneinem IT-Support-Spezialisten. Die Hintergrundgeschichte verrät uns, dass Michael mehrere Sicherheitsgruppen besitzt - eine Fehlkonfiguration, die den Boden für eine Eskalation bereitet.

Wir authentifizieren uns mit seinen Anmeldedaten über Connect-MgGraph und führen Sie dann Get-MgContext um unseren aktuellen Sicherheitskontext zu bestätigen (Abbildung 3).

Schritt 2: Aufzählung

Da uns der Hinweis in diese Richtung führt, zählen wir als nächstes alle Gruppen auf, die dem aktuellen Benutzer gehören(Abbildung 4).

Wir stellen fest, dass er insgesamt sechs Gruppen besitzt. Um das Potenzial der Privilegieneskalation zu beurteilen, prüfen wir, ob einer dieser Gruppen Rollen zugewiesen werden können und ob sie tatsächlich Rollen zugewiesen haben(Abbildung 5).

Eine Gruppe sticht sofort ins Auge: IT Application Managers, die die Application Administrator Rolle.

Diese Rolle ist sehr mächtig, da sie die volle Kontrolle über alle Anwendungsregistrierungen und Service Principals im Tenant gewährt, einschließlich der Möglichkeit, Geheimnisse oder Zertifikate zu Anwendungen von Drittanbietern hinzuzufügen (falls diese nicht mit App-Instance-Lock konfiguriert sind). Dann kann der Angreifer die Identität des Service Principals verwenden, um sich über den OAuth 2.0 Client Credential Grant Flow beim Tenant zu authentifizieren. Dabei arbeitet er in einem reinen Anwendungskontext, der die benutzerzentrierten Schutzmaßnahmen umgeht.

Hinweis: Die obigen Aufzählungsschritte können in spezielle Hilfsfunktionen verpackt werden (z.B., Get-GroupsOwnedBy für Eigentum und Get-GroupRoles für zugewiesene Rollen), um den Prozess interaktiver und ausführlicher zu gestalten, ähnlich wie bei Open-Source-Tools, die Ergebnisse präsentieren.

Abbildung 6 und Abbildung 7 zeigen die Umsetzung.

Abbildung 8 zeigt, wie die auffällige Ausgabe aussieht, wenn wir diese Aufzählungsfunktion mit der ID des aktuellen Benutzers ausführen.

Dies kann zwar in großen Umgebungen hilfreich sein, aber Microsoft Graph bietet auch ein weitaus effizienteres Cmdlet: Get-MgUserOwnedObject (Abbildung 9).

Get-MgUserOwnedObject zählt auf. alle Verzeichnisobjekte, die einem Benutzer gehörenDamit entfällt die Notwendigkeit, jeden Objekttyp (Gruppen, Geräte, Anwendungen und Dienstprinzipale) einzeln abzufragen, im Gegensatz zu unserer beabsichtigten Implementierung. Der Befehl kann mit Sonnet ein wenig optimiert werden, um eine schönere Ausgabe zu erhalten (Abbildung 10).

Der Befehl Get-MgUserOwnedObject macht typischerweise eine API-Anfrage zu https://graph.microsoft.com/v1.0/users/{userId}/ownedObjects (wobei je nach Paginierung möglicherweise ein oder zwei weitere Anfragen hinzugefügt werden). Der Rest wird von der lokalen PowerShell-Logik zur Verarbeitung, Extraktion und Formatierung der Antwort erledigt.

Im Vergleich dazu ist die Get-GroupsOwnedBy Funktion, die wir erstellt haben und die vielleicht interaktiver und benutzerfreundlicher ist, macht 100-1000x API-Anfragenobwohl es nur nach einer Art von eigenem Objekt sucht.

Bei der Auswahl von Enumerationstools ist es immer eine gute Idee, der Effizienz den Vorrang zu geben. Weniger API-Aufrufe bedeuten weniger Protokolle und einen geringeren Erkennungsaufwand. Es gibt viele großartige (und einige weniger großartige) Open-Source-Tools für die Aufzählung von Entra ID-Umgebungen. Der wichtigste Punkt ist, dass Tools zwar nützliche Abkürzungen sein können, aber niemals als Blackboxen verwendet werden sollten. Wenn Sie den Quellcode lesen können, tun Sie es. Nehmen Sie sich die Zeit, um zu verstehen, wie die Abfragen aufgebaut sind, auf welche API-Endpunkte zugegriffen wird und welche Daten tatsächlich zurückgegeben werden. Tools sind nur so effektiv wie das Verständnis des Anwenders für ihre Methoden und Grenzen.

Schritt 3: Aufbau der Angriffskette

Der Besitz einer Gruppe mit Application Administrator Rechte birgt ein erhebliches Potenzial zur Eskalation von Privilegien, denn sobald wir uns selbst als Mitglied hinzufügen, können wir ein Client-Geheimnis verwalten (== hinzufügen) jede Service Principal im Mandanten, der mehrere Wege zur Kompromittierung des Mandanten eröffnet.

Aber wenn wir uns selbst hinzufügen, wäre das aus OPSEC-Sicht unangenehm und unnötig. Zunächst sollten wir uns vergewissern, dass es einen privilegierten Dienstprinzipal gibt, den wir nutzen können, um die nächste Kette des Angriffs zu erreichen - die GA-Rolle.

Es ist Zeit, sich auf die Jagd nach hochwertigen Service-Principals zu machen.

Hinweis: In dieser Schritt-für-Schritt-Anleitung konzentrieren wir uns auf die Aufzählung von Dienstprinzipalen mit privilegierten Rollen, die das Kennwort der GA in wenigen Schritten zurücksetzen können:

• Administrator mit privilegierter Rolle (PRA)
• Privilegierter Authentifizierungs-Administrator (PAA)
• Globaler Administrator (GA)

In einem echten Mandanten sollten Sie es damit jedoch nicht bewenden lassen. Es ist genauso wichtig, Dienstprinzipale mit anderen Rollen und mit mächtigen App-Berechtigungen aufzuzählen, da diese ebenso gefährliche Eskalationspfade eröffnen können, wie in Szenario 2 gezeigt.

Wir beginnen mit der Funktion Get-MgRoleManagementDirectoryRoleAssignment um zu überprüfen, ob Dienstprinzipalen direkt privilegierte Rollen zugewiesen sind (Abbildung 11).

Das Ergebnis? Nichts. Kein einziger Dienstherr hält direkt GA, PRA oder PAA in meinem Mieter.

Das ist jedoch nicht der gesamte Satz von Service-Principals, denen privilegierte Rollen zugewiesen werden können. Entra ID erlaubt rollenzuweisende Gruppen, und genau wie Benutzer können auch Serviceprinzipale Mitglieder dieser Gruppen sein. Wenn eine Gruppe GA, PRA oder PAA hat, erbt jeder Service-Principal innerhalb dieser Gruppe diese Privilegien. Dies ist ein oft übersehener Eskalationsvektor.

Als Nächstes zählen wir also alle Gruppen auf, denen Rollen zugewiesen werden können, und prüfen, welchen Gruppen die Rollen zugewiesen sind(Abbildung 12).

Da wir nun eine Liste der privilegierten Gruppen haben, müssen wir deren Mitglieder überprüfen. Da die Funktion Get-MgGroupMember auf v1.0 funktioniert, zeigt es keine Mitgliedschaften von Dienstprinzipalen an. Um das zu lösen, verpacken wir einen direkten Aufruf der /beta Endpunkt in einer Hilfsfunktion (Abbildung 13).

Jetzt können wir sie verwenden, um nach der Mitgliedschaft des Dienstchefs in den privilegierten Gruppen zu filtern(Abbildung 14).

Jetzt wird es interessant - wir haben potenzielle Dienstprinzipale mit privilegierten Rollen entdeckt. Je nach Ihrer Umgebung haben Sie vielleicht noch viel mehr.

Wir können einfach den ersten auswählen ($targetSPs[0]), aber aus Gründen der Konsistenz (und damit jeder Spieler den gleichen Weg hat, ohne die Stabilität des Mieters zu riskieren), werden wir uns auf die Identity Management Portal, als Abbildung 15 zeigt. Diese ist Teil des Einrichtungsskripts und wird im Falle einer Änderung der Funktionalität nichts kaputt machen (drücken Sie die Daumen).

In diesem Stadium haben wir die gesamte Angriffskette skizziert. Hier sehen Sie, wie wir uns vom derzeit niedrig privilegierten Benutzer bis zum Global Admin vorarbeiten:

1. Wir fügen uns in die IT Application Managers Gruppe zu erben. Application Administrator Rolle.
2. Verwenden Sie diese Rolle, um ein Client-Geheimnis zum Identity Management Portal Dienstherr.
3. Authentifizieren Sie sich als dieser Dienstprinzipal.
4. Verwenden Sie die geerbten PAA-Rechte, um das Passwort des Global Admin zurückzusetzen.
5. Melden Sie sich als Global Admin mit dem neuen Passwort an.
6. Holen Sie die Flagge zurück, um die Kompromittierung zu beweisen.

Schritt 4: Ausführen des Angriffspfads

Zunächst fügen wir uns selbst als Mitglieder der IT Application Managers Gruppe, als Abbildung 16 zeigt.

Da die Token nicht automatisch aktualisiert werden, können wir die Verbindung trennen und uns neu authentifizieren, um ein neues Zugriffstoken mit der neu zugewiesenen Rolle zu erhalten. Wie in Szenario 2 beschrieben, ist dieser Schritt nicht zwingend erforderlich, da die meisten Entra ID-Endpunkte die Rollenzuweisungen in der Regel dynamisch bewerten.

Wir können die parse-JWTToken Cmdlet von BARK, um die hinzugefügte App-Administratorrolle zu sehen (die wids Feld innerhalb des JWT-Tokens, das Abbildung 17 zeigt) dem Benutzer zugewiesen.

Mit Application Administrator Rechte in unseren Händen haben, können wir den Zugriff auf die Backdoor Identity Management Portal (Abbildung 18), wie wir es in Szenario 1.

Dadurch erhalten wir dauerhaften Zugriff auf den Dienstprinzipal, unabhängig von einem Benutzerkonto. Damit können wir uns als Dienstprinzipal bei Entra ID authentifizieren, wie Abbildung 19 zeigt.

Der nächste Schritt besteht darin, den GA-Zielbenutzer zu finden und sein Passwort zurückzusetzen(Abbildung 20).

Schließlich können wir uns als GA authentifizieren und das Flag abrufen (Abbildung 21). Wir verwenden Get-MSGraphTokenWithUsernamePassword um sich über die CLI zu authentifizieren (genau wie in Szenario 2), aber Sie können auch einen TAP setzen (wie in Szenario 1) und melden Sie sich interaktiv über das Azure-Portal oder das Entra ID Admin Center an.

Szenario 3 abgeschlossen!

Schritt 5: Aufräumen

Vergessen Sie nicht, das Bereinigungsskript(Abbildung 22) auszuführen, um die Tenant-Umgebung in ihren ursprünglichen Zustand zurückzuversetzen.

Gelernte Lektionen

Szenario 3 zeigt, wie scheinbar unbedeutende Fehlkonfigurationen bei der Gruppenzugehörigkeit zu einer vollständigen Kompromittierung des Mandanten führen können. Die Angriffskette (vom niedrig privilegierten Benutzer bis zum globalen Administrator) erforderte keine ausgefeilten Techniken, sondern lediglich ein Verständnis des Delegationsmodells von Entra ID, der Funktionsweise der Rollenvererbung und der Kontrollebene der Identitäten von Dienstprinzipalen.

Das Wichtigste zum Mitnehmen: Gruppenbesitz ist eine getarnte administrative Delegation. Wenn Benutzer rollenzuweisende Gruppen besitzen, kontrollieren sie effektiv alle Rollen, die diesen Gruppen zugewiesen sind. Service Principals verstärken dieses Risiko, da sie über mehrere Wege kompromittiert werden können, die über den herkömmlichen Diebstahl von Anmeldedaten hinausgehen - Eigentumsverhältnisse, Rollen in der Anwendungsverwaltung und programmatischer Zugriff.

Das Szenario zeigt, dass in modernen Cloud-Identitätsumgebungen die Pfade der Privilegieneskalation selten linear sind. Sie verflechten sich mit Eigentumsverhältnissen, Gruppenmitgliedschaften und Identitäten von Serviceprinzipalen auf eine Art und Weise, die es den Verteidigern abverlangt, systematisch über Identitätsbeziehungen und nicht über einzelne Berechtigungen nachzudenken.

Der IT-Supportspezialist mit geringen Privilegien brauchte nichts zu verändern - der Eskalationspfad war von Anfang an in die Konfiguration des Mandanten integriert.

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 intelligente Weise brechen
Szenario 1: Missbrauch von Service Principal Ownership in Entra ID
Szenario 2: Ausnutzung von App-Only Graph-Berechtigungen 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.