EntraGoat Szenario 1: Missbrauch der Eigentumsrechte des Dienstherrn in Entra ID

Anmerkung der Redaktion

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

Fehlbesetzt und gefährlich: Ein Handbuch für den Besitzer von Global Admin

Wir beginnen unsere EntraGoat Anwendungsbeispiele mit Szenario 1, das wir Misowned and Dangerous nennen : Ein Handbuch für den Besitzer von Global Admin. Diese praktische Übung zeigt, wie der rechtmäßige Besitz von Anwendungen in Microsoft Entra ID ausgenutzt werden kann, um Privilegien zu erweitern und ein globales Administratorkonto zu kompromittieren - und damit eine vollständige Übernahme des Mandanten zu ermöglichen.

Der Angreifer beginnt mit einem kompromittierten Benutzerkonto mit niedrigen Privilegien und erlangt die Kontrolle über eine Unternehmensanwendung (Dienstprinzipal), der eine privilegierte Rolle zugewiesen ist.

Durch das Hinzufügen eines Client-Geheimnisses zum Dienstprinzipal schaltet sich der Angreifer in die Identität der Anwendung ein und nutzt dann seine Rolle, um das Kennwort des Administrators zurückzusetzen und einen temporären Zugangspass (Temporary Access Pass, TAP) auszustellen, um vollen interaktiven Zugriff auf das Azure-Portal zu erhalten.

Dieses Szenario verdeutlicht die realen Folgen von Anwendungsfehlern und illustriert den Unterschied im Verhalten, in den Zugriffsgrenzen und in der Risikoexposition zwischen delegierten und reinen Authentifizierungsabläufen.

Übersicht der Angriffswege

1. Die Geschichte des ersten Fußes: Der Angreifer authentifiziert sich als ein kompromittierter Finanzbenutzer (david.martinez) mit gestohlenen Anmeldedaten.
2. Aufzählung: Mithilfe der nativen PowerShell und Microsoft Graph Cmdlets findet der Angreifer heraus, dass der Benutzer einen Dienstprinzipal namens Finance Analytics Dashboard die den Namen Privileged Authentication Administrator Rolle.
3. Privilegienerweiterung: Der Angreifer fügt dem eigenen Service-Principal ein Client-Geheimnis hinzu und authentifiziert sich mit reinen App-Anmeldeinformationen, wobei er auf eine Service-Principal-Identität ausweicht.
4. Kontoübernahme: Aus dem App-Only-Kontext mit der privilegierten Rolle setzt der Angreifer das Kennwort des globalen Administrators zurück oder fügt einen TAP hinzu, um die Multifaktor-Authentifizierung (MFA) zu umgehen, meldet sich dann interaktiv an und holt sich die Flagge, um die vollständige Kompromittierung des Mandanten zu bestätigen.

Angriffsfluss

Abbildung 1 zeigt den Ablauf dieses Angriffs.

Warum ist es wichtig, die Eigentumsverhältnisse von Anwendungen zu verstehen?

Jede Anwendung in Entra ID hat zwei verschiedene Identitäten:

1. Anwendungsregistrierung, ein globales Definitionsobjekt im Home Tenant, in dem die App ursprünglich erstellt wurde. Dieses Objekt enthält die Blueprint-OAuth2-Berechtigungen (Scopes) der App, die Redirect-URIs für Sign-In-Flows, Branding- und Publisher-Metadaten und mehr anfordern kann. Diese Identität stellt selbst keinen aktiven Sicherheitsprinzipal im Tenant dar.
2. Service Principal, eine lokale Instanz der App im Tenant, die als Sicherheitsidentität fungiert und die Zugriffskontrolle durchsetzt. Ein Service Principal wird automatisch erstellt, wenn ein Benutzer im Tenant eine neue App registriert, einer externen App zustimmt usw. Die Identität des Service Principal wird von Entra ID verwendet, um Rollen zuzuweisen, Richtlinien anzuwenden und Berechtigungen durchzusetzen. Sie ist auch die authentifizierte Identität, wenn die App alleine agiert (reiner App-Kontext).

Das Eigentum an Anwendungen ist eine legitime Verwaltungsfunktion. Dieses Design unterstützt die dezentralisierte Verwaltung in großen Unternehmen und ermöglicht es Teams, ihre eigenen Unternehmensanwendungen zu verwalten. Es ermöglicht Entwicklern, Automatisierungsprozessen und Dienstbesitzern, den Lebenszyklus und die Konfiguration ihrer Anwendungen zu verwalten. Diese Funktion wird jedoch zu einer Belastung, wenn:

• Anwendungen werden privilegierte Rollen zugewiesen
• Die Eigentümerschaft wird regulären Benutzern ohne Governance zugewiesen
• Unzureichende oder nicht überwachte Credential-Hygiene

Schlecht verwaltete Dienstprinzipale ermöglichen die Hinzufügung von Anmeldeinformationen und den reinen App-Zugang, wodurch Identitätskontrollen wie MFA und Conditional Access umgangen werden.

Dieser Exkurs zeigt auf, warum Angreifer in modernen Cloud-Umgebungen seitliche Bewegungen mit Hilfe von Service-Prinzipien bevorzugen und warum Verteidiger den Unterschied zwischen delegierten und reinen App-Sicherheitskontexten verstehen müssen.

Wie Sie den Missbrauch der Eigentumsrechte an einem Dienst erkennen und sich dagegen wehren können

Das Verstehen und Überwachen des Eigentums an Anwendungen ist nicht optional, sondern eine grundlegende Sicherheitskontrolle in jeder Entra ID Umgebung. Die Eigentümerschaft einer Anwendung ermöglicht die Verwaltung von Anmeldeinformationen, die Konfiguration von Berechtigungen und die effektive Kontrolle der Identität der Anwendung. Ohne Einblick in die Eigentümerschaft von Anwendungen und die Zuweisung von Berechtigungen bleiben die Wege zur Eskalation von Privilegien sowohl für Verteidiger als auch für Prüfer verborgen.

Verteidiger sollten überwachen und korrelieren:

• Welche Anwendungen gibt es im Mieter?
• Wem gehören sie?
• Welche Berechtigungen oder Verzeichnisrollen sind ihnen zugewiesen?
• Besitzen unprivilegierte Benutzer Dienstprinzipale mit erweitertem Zugriff?
• Welche Anwendungen werden nicht mehr verwendet und können außer Betrieb genommen werden?

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. zu freizügige Autorisierungsrichtlinien für die Konfiguration von Anwendungen, privilegierte Service-Principals für Nicht-Administratoren und schwache Sicherheits-Baselines für Anwendungen, und schlagen Alarm.

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

Lassen Sie uns einen Blick auf die konkreten Schritte werfen, die Sie unternehmen, um den Missbrauch von Anwendungseigentum zu simulieren und zu verstehen, unter welchen Bedingungen dies eine Kompromittierung von Global Admin ermöglicht.

Schritt 1: Erster Fußabdruck

Wir beginnen mit dem Sicherheitskontext eines Finanzanalysten, david.martinez (Abbildung 2), der seine Unternehmensdaten während einer Phishing-Kampagne eingegeben hat.

Die Verwendung der Connect-MgGraph cmdlet, authentifizieren wir uns als der kompromittierte Benutzer (Abbildung 3).

Um unsere derzeitigen Möglichkeiten zu verstehen, beginnen wir mit der Untersuchung des Sicherheitskontextes der authentifizierten Sitzung(Abbildung 4).

Eine alternative und bekannte Methode für die Authentifizierung als Entra ID-Benutzer und den Erhalt eines JWT-Zugriffstokens ist der Einsatz von Automatisierungstools wie ^BARK1. Das folgende PowerShell-Snippet veranschaulicht, wie Sie ein Zugriffstoken über die Authentifizierung per Benutzername/Passwort über die CLI erhalten und verwenden:

      $userToken = Get-MSGraphTokenWithUsernamePassword -Username $UPN -Password $password -TenantID $tenantId
$userAccessToken = $userToken.access_token
$SecureToken = ConvertTo-SecureString $userAccessToken -AsPlainText -Force
Connect-MgGraph -ZugangsToken $SecureToken

BARK enthält auch Funktionen zur Dekodierung des resultierenden JWT, die detaillierte Sitzungs-Metadaten wie delegierte Berechtigungen offenlegen (scp), Verzeichnisrollen (wids), Authentifizierungsmethode (amr), und Kundeninformationen (app_displayname), als Abbildung 5 zeigt.

Dieser Dekodierungsschritt ist besonders nützlich für eine schnelle Privilegienauswertung. Wenn das Token beispielsweise für einen Benutzer mit Verzeichnisrollen ausgestellt wurde, kann der wids Anspruch würde direkt die zugewiesenen Rollen-GUIDs auflisten, z. B. die Rolle Globaler Administrator, die Abbildung 6 zeigt, ohne dass eine zusätzliche Aufzählung der Graph API erforderlich ist.

Diese Anleitung vermeidet es jedoch, sich auf Tools oder Abstraktionen von Drittanbietern zu verlassen. Alle Enumeration- und Exploitation-Schritte werden mit nativer PowerShell und direkten Graph-API-Aufrufen ausgeführt, um sicherzustellen, dass jede Phase des Angriffspfads vollständig transparent und technisch erklärt ist.

HINWEIS: Standardmäßig können alle authentifizierten Benutzer in Entra ID grundlegende Profildaten anderer Benutzer abfragen, sowie Attribute wie extensionAttribute1–15 sind nicht als sensibel eingestuft. Daher kann die im Profil des Administrators gespeicherte Kennzeichnung technisch gesehen mit der folgenden API-Abfrage sofort abgerufen werden:

      $uri = "https://graph.microsoft.com/v1.0/users/EntraGoat-admin-s1@334brf.onmicrosoft.com?`$select=onPremisesExtensionAttributes"
$Antwort = Invoke-MgGraphRequest -Uri $uri -Method GET
$response.onPremisesExtensionAttributes.extensionAttribute1

Dieses Verhalten ist beabsichtigt. Das Ziel von EntraGoat ist es nicht, die Flagge zu verstecken, sondern realistische Techniken der Privilegieneskalation in Entra ID-Umgebungen zu vermitteln. Das Abrufen der Flagge über einen direkten API-Aufruf ist zwar möglich, aber das eigentliche Ziel ist es, die Privilegien zu erweitern, als Administrator auf das Azure-Portal zuzugreifen und die Flagge in der Benutzeroberfläche zu sehen - und damit die volle Kontrolle über eine globale Administratoridentität zu demonstrieren. Die Flagge ist ein spielerisches Artefakt, nicht das eigentliche Ziel.

      Invoke-MgGraphRequest -Uri 'https://graph.microsoft.com/v1.0/me?$select=id,userPrincipalName,onPremisesExtensionAttributes' |
    Select-Object @{n='UPN';e={$_.userPrincipalName}},
                  @{n='Id';e={$_.id}},
                  @{n='Flag';e={$_.onPremisesExtensionAttributes.extensionAttribute1}}

Schritt 2: Aufzählung

Da dies das erste Szenario in der EntraGoat-Serie ist, werden wir den Enumeration-Prozess durchlaufen und die grundlegenden Techniken der Privilegieneskalation erläutern. In unseren anderen Szenarien gehen wir von dieser Ausgangssituation aus und konzentrieren uns direkt auf den Hauptangriffspfad, wobei wir die Aufklärungsschritte im CTF-Stil auslassen.

Mit dem ersten Zugriff auf david.martinezbeginnen wir mit der Suche nach Wegen zur Privilegienerweiterung. Unsere erste Aufgabe besteht darin, herauszufinden, welchen Zugriff die kompromittierte Identität hat.

Zunächst prüfen wir, ob dem Benutzer eine Verzeichnisrolle zugewiesen ist(Abbildung 7).

Die Get-MgRoleManagementDirectoryRoleAssignment cmdlet zeigt keine privilegierten Rollen an, was bestätigt, dass david.martinez hat standardmäßig keinen erweiterten Zugriff. Als nächstes sehen wir uns die Gruppenmitgliedschaften an (Abbildung 8).

Der Benutzer ist nur Teil der Standard-Mietergruppe, die jedem Entra ID-Benutzer für Kollaborationsdienste wie SharePoint oder Teams zugewiesen wird. Auch hier gibt es keinen Pfad zur Privilegieneskalation.

Wir prüfen auch, ob david.martinez keine Gruppen besitzt, da Gruppenbesitzer sich selbst als Mitglieder hinzufügen und die Privilegien der Gruppe (wie zugewiesene Rollen) erben können. Auch diese Prüfung ergibt einen leeren Wert (Abbildung 9).

Die Abfrage nach den Besitzverhältnissen des Dienstherrn liefert jedoch nur ein Ergebnis(Abbildung 10).

david.martinez besitzt den Auftraggeber der Dienstleistung Finance Analytics Dashboard. Dies ist von Bedeutung, da die Eigentümer von Dienstprinzipalen die Berechtigungsnachweise verwalten können - einschließlich des Hinzufügens neuer Geheimnisse, um sich als Dienstprinzipal zu authentifizieren.

Lassen Sie uns prüfen, ob die Finance Analytics Dashboard Dienstprinzipal irgendwelche zugewiesenen Berechtigungen hat (Abbildung 11).

Es sind keine konfiguriert. Als Nächstes prüfen wir, ob ihm Verzeichnisrollen zugewiesen sind(Abbildung 12).

Wir sehen eine Rollenzuweisung, aber sie wird nur durch eine GUID dargestellt. Jede integrierte Entra ID Rolle wird durch eine GUID repräsentiert, die global ist und in allen Entra ID Tenants gleich ist. Sie können alle offiziellen eingebauten Rollen und ihre GUIDs hier einsehen.

Um die GUID in einen für Menschen lesbaren Rollennamen aufzulösen, können wir die Ausgabe von Get-MgRoleManagementDirectoryRoleAssignment zu Get-MgRoleManagementDirectoryRoleDefinition (Abbildung 13), die jede zugewiesene Rollen-ID in den entsprechenden Anzeigenamen übersetzt.

Privileged Authentication Administrator ist eine hochsensible Rolle in Entra ID. Sie ermöglicht es dem Inhaber, die Authentifizierungsmethoden für alle Benutzer zu verwalten, einschließlich des Zurücksetzens von MFA-Einstellungen, der Konfiguration von FIDO2- und passwortlosen Anmeldeoptionen und der Änderung von Schlüsselrichtlinien, die bestimmen, wie sich Benutzer authentifizieren. Aus diesem Grund würde ein Angreifer, der als ihr Besitzer agiert, sicherlich ein Client-Geheimnis zu ihr hinzufügen und es verwenden, um das Konto des globalen Administrators zu beeinflussen.

HINWEIS: Wenn Sie die Entra-Phase aufmerksam verfolgt haben, ist Ihnen wahrscheinlich die Ausführlichkeit und der manuelle Aufwand aufgefallen, der bei der Verwendung nativer Microsoft Graph Cmdlets erforderlich ist. (Was wäre, wenn wir 5[0] Entra-Anwendungen statt 1 besäßen?) Dies ist eine der wichtigsten Einschränkungen, wenn Sie sich ausschließlich auf native Tools verlassen. Befehle geben oft Daten auf niedriger Ebene zurück (z. B. GUIDs), die zusätzliche Abfragen erfordern, um sie in sinnvolle Informationen aufzulösen.

Genau aus diesem Grund automatisieren viele Aufzählungs-Frameworks diese Prozesse. Sie abstrahieren die sich wiederholenden Abfragen und rationalisieren die Ausgabe, was eine schnellere Privilegienanalyse und Entscheidungsfindung ermöglicht. Um die Benutzerfreundlichkeit zu verbessern, können wir zum Beispiel einfache Wrapper-Funktionen schreiben wie Find-OwnedServicePrincipals und Get-ServicePrincipalRoles die dazu dienen, die Ermittlung von SP-Eigentümern zu automatisieren und die Zuweisung von Verzeichnisrollen effizienter zu lösen:

      function Find-OwnedServicePrincipals {
    param([string]$UserId)
    
    # Get all service principals in tenant
    $allSPs = Get-MgServicePrincipal -All
    Write-Host "Found $($allSPs.Count) service principals in tenant"
    
    $ownedSPs = @()
    $checkCount = 0
    
    # Check ownership of each service principal
    foreach ($sp in $allSPs) {
        $checkCount++
        if ($checkCount % 50 -eq 0) {
            Write-Host "Checked $checkCount/$($allSPs.Count) service principals..."
        }
        
        try {
            $owners = Get-MgServicePrincipalOwner -ServicePrincipalId $sp.Id -ErrorAction SilentlyContinue
            if ($owners) {
                foreach ($owner in $owners) {
                    if ($owner.Id -eq $UserId) {
                        $ownedSPs += $sp
                        Write-Host "OWNED SERVICE PRINCIPAL FOUND!" -ForegroundColor Red
                        Write-Host "   Name: $($sp.DisplayName)" -ForegroundColor Yellow
                        Write-Host "   SP ID: $($sp.Id)" -ForegroundColor Yellow
                        Write-Host "   App ID: $($sp.AppId)" -ForegroundColor Yellow
                        break
                    }
                }
            }
        } catch {
            continue
        }
    }
    return $ownedSPs
}

function Get-ServicePrincipalRoles {
    param([object]$ServicePrincipal)
    
    Write-Host "Checking roles for: $($ServicePrincipal.DisplayName)"
    
    # Check directory role assignments for the SP
    $roleAssignments = Get-MgRoleManagementDirectoryRoleAssignment -Filter "principalId eq '$($ServicePrincipal.Id)'" -ErrorAction SilentlyContinue
    $roles = @()
    
    if ($roleAssignments) {
        foreach ($assignment in $roleAssignments) {
            $roleDefinition = Get-MgRoleManagementDirectoryRoleDefinition -UnifiedRoleDefinitionId $assignment.RoleDefinitionId
            $roles += $roleDefinition
            Write-Host "   Role: $($roleDefinition.DisplayName)" -ForegroundColor Cyan
        }
    } else {
        Write-Host "   No directory roles assigned"
    }
    
    return $roles
}

Um nun alle Dienstprinzipale zu ermitteln, die dem kompromittierten Benutzer gehören, und die ihnen zugewiesenen Rollen aufzuzählen, können wir einfach Folgendes ausführen Find-OwnedService Principals, als Abbildung 14 zeigt.

Schritt 3: Eintauchen in den Kontext des Dienstherrn

Dieser Schritt verdeutlicht den Hauptgrund, warum wir dieses Szenario erstellt und an den Anfang der Serie gestellt haben: Service Principals prägen die Landschaft der Privilegieneskalation in Entra ID. Das seitliche Eindringen in den Sicherheitskontext eines Service Principals und dessen Ausnutzung zur Durchführung privilegierter Operationen ist eine grundlegende Technik, mit der jeder Verteidiger, Angreifer und Forscher, der mit Entra ID arbeitet, vertraut sein sollte.

Fügen wir ein Client-Geheimnis zur Datei Finance Analytics Dashboard Service Principal, um einen Backdoor-Zugang herzustellen und sich als SP zu authentifizieren:

      $secretDescription = "EntraGoat-Secret-$(Get-Date -Format 'yyyyMMdd-HHmmss')"
$passwordCredential = @{
    DisplayName = $secretDescription
    EndDateTime = (Get-Date).AddYears(1)
}

$newSecret = Add-MgServicePrincipalPassword -ServicePrincipalId $SP.Id -PasswordCredential $passwordCredential

# Speichern Sie die hinzugefügten geheimen Details
$clientSecret = $newSecret.SecretText

Als nächstes trennen Sie die aktuelle Benutzersitzung mit Disconnect-MgGraph, erstellen Sie die Anmeldedaten des Clients und authentifizieren Sie sich mit der Identität des Dienstherrn über Connect-MgGraph:

      $secureSecret = ConvertTo-SecureString -String $clientSecret -AsPlainText -Force
$credential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $SP.AppId, $secureSecret
Connect-MgGraph -TenantId $tenantId -ClientSecretCredential $credential

Und in der Tat, jetzt sind wir authentisch als die Finance Analytics Dashboard Dienstherr (Abbildung 15).

Die Get-MgContext Antwort gibt Aufschluss darüber, wie die aktuelle Microsoft Graph-Sitzung authentifiziert wurde. Dies bestimmt direkt den Sicherheitskontext, die Zugriffsstufe und das Berechtigungsmodell, das angewendet wird. Konzentrieren wir uns auf die Felder AuthType und TokenCredentialType da sie die wichtigsten Identitätssemantiken in Entra ID offenlegen.

Nach der Authentifizierung als david.martinezerschienen diese Werte als:

      AuthType : Delegiert
TokenCredentialType : InteractiveBrowser

Dies zeigt eine delegierte Sitzung an, bei der das ausgegebene Token eine Benutzeridentität darstellt. Der Zugriff wird durch die dem Benutzer zugewiesenen Rollen und delegierten Berechtigungen geregelt, und alle Vorgänge werden im Namen des Benutzers ausgeführt. Der Sitzungskontext ist auf das beschränkt, worauf die Benutzeridentität Zugriff hat, da er die Richtlinien für den bedingten Zugriff, die MFA-Durchsetzung und die PIM-Einschränkungen übernimmt.

Im Gegensatz dazu ist ein reiner Anwendungskontext, der beispielsweise von einem Dienstprinzipal unter Verwendung von Client-Anmeldeinformationen (AppId + Secret + TenantId) fungiert als eine nicht-menschliche Identität. Jeder Client (Skript, Hintergrundjob, Daemon), der diese Anmeldeinformationen verwendet, kann sich als die Anwendung authentifizieren und Microsoft Graph APIs auf der Grundlage seiner Anwendungsberechtigungen aufrufen, unabhängig vom Benutzerkontext. Richtlinien für bedingten Zugriff, MFA und PIM sind in diesem Ablauf nicht anwendbar oder werden nicht durchgesetzt.

Diese Unterscheidung ist grundlegend für das Design der Identitätssicherheit und erklärt, warum sich das API-Verhalten, die Zugriffsbereiche und die Token-Berechtigungen unter denselben Cmdlets je nach Sitzungskontext unterscheiden.

Und wie zu erwarten, hat diese Unterscheidung große Auswirkungen auf die Angriffsfläche und das Missbrauchspotenzial. Delegierte Ströme sind durch den Benutzerkontext eingeschränkt, während reine App-Ströme mit Vertrauen auf Dienstebene und oft mit breiteren und weniger kontrollierten Berechtigungsgrenzen arbeiten. Für Angreifer führt die Kompromittierung eines App-Geheimnisses oder -Zertifikats häufig zu einem dauerhaften Zugriff mit hohen Privilegien, der identitätszentrierte Durchsetzungsmechanismen umgeht.

Schritt 4: Kontoübernahme - Anmeldung als globaler Administrator

Jetzt, wo wir uns als Identität mit der Privileged Authentication Administrator Rolle haben wir die Möglichkeit, Passwörter zurückzusetzen (Abbildung 16) für jeden Benutzer im Mandanten, einschließlich des globalen Administrators.

Mit dieser Zugriffsstufe können wir auch eine TAP(Abbildung 17) als Authentifizierungsmethode zuweisen, mit der wir die MFA umgehen und uns direkt beim Azure-Portal anmelden können:

Als nächstes melden wir uns mit der TAP an(Abbildung 18).

Dann rufen wir das Szenario-Flag ab(Abbildung 19).

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

Kennen Sie Ihr schwächstes Glied

Dieses Szenario zeigt, wie scheinbar legitime und gängige Konfigurationen, wie z.B. die Zuweisung von Anwendungseigentum an einen Standardbenutzer, die Tür zu einer vollständigen Kompromittierung des Mandanten öffnen können, wenn sie mit privilegierten Rollen gepaart werden.

Durch die Ausnutzung des Eigentums an einem Dienstprinzipal können Angreifer ihre Privilegien ausweiten, benutzerzentrierte Verteidigungsmaßnahmen wie MFA und Conditional Access umgehen und schließlich über einen reinen App-Flow Zugriff auf den globalen Administrator erhalten.

Diese Übung unterstreicht die entscheidende Bedeutung einer starken Governance in Bezug auf Anwendungsberechtigungen, Service Principal Ownership und Rollenzuweisungen. In modernen Cloud-Umgebungen sind Service-Principals oft das schwächste Glied. Das Verständnis ihres dualen Identitätsmodells, ihrer Zugriffsgrenzen und ihres Missbrauchspotenzials ist sowohl für Angreifer als auch für Verteidiger von entscheidender Bedeutung.

Das Szenario 1 von EntraGoat legt den Grundstein für weitere Erkundungen - und unsere nächsten Szenarien. Also hacken Sie weiter!

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 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.