Cloud Hacking: Die Azure Cyber Kill Chain - Teil 2

Im ersten Teil dieser Artikelserie haben wir die Cyber Kill Chain im Kontext der Microsoft Cloud betrachtet und die ersten beiden Phasen, Aufklärung (Reconnaissance) und Erstzugang (Initial Access), analysiert.

In dieser Folge steht die Enumerationsphase im Mittelpunkt. Im Szenario gehen wir davon aus, dass die Cyber-Kriminellen bereits einen Initialen Zugriff über ein kompromittiertes Benutzerkonto, z. B. mittels erfolgreichen MFA-Phishings, erlangt haben. Mehr zum Thema MFA-Phishing erfahren Sie in unserem Insight zu dieser Technik.

Ziel der Enumeration ist es, die Berechtigungen des kompromittierten Kontos und die damit erreichbaren Ressourcen zu identifizieren. Dabei sind vor allem Berechtigungen auf Azure Ressourcen, die über Role Based Access Control (RBAC) gesteuert werden, sowie Rechte innerhalb von Microsoft Entra ID relevant.

Bevor wir tiefer in diese beiden Berechtigungswelten eintauchen, ist eine Unterscheidung des Kontotyps wichtig. Meist handelt es sich bei kompromittierten Identitäten um einen von zwei Account Typen.

• Benutzerkonten werden häufig durch Phishing oder Password Spraying kompromittiert. Diese Konten haben oft weitergehende Leserechte im Verzeichnis und können deshalb Informationen zu Nutzern, Gruppen oder registrierten Anwendungen einsehen. Gleichzeitig unterliegen Benutzerkonten in vielen Tenants strengeren Zugangsregeln, etwa durch Conditional Access Richtlinien, und werden intensiver überwacht. Da typische Benutzerkonten zudem oft mit Microsoft 365 Lizenzen ausgestattet sind, ermöglichen sie in der Praxis häufig Zugriff auf besonders sensible Daten wie Dateien, Chats und Kollaborationsinhalte. 
• Service Principals sind Konten, die Anwendungen oder Dienste zur Authentifizierung in der Microsoft Cloud nutzen. Cyber-Kriminelle können an Service Principals gelangen, wenn sie beispielsweise Kontrolle über Cloud Ressourcen wie virtuelle Maschinen oder App Services erlangen und dort Anmeldeinformationen auslesen. Ein Service Principal verfügt in der Regel nur über sehr eingeschränkte Standardberechtigungen und kann ohne explizite Zuweisungen weder Benutzer noch Gruppen im Verzeichnis abfragen. Umfangreichere Abfragen sind erst durch explizit vergebene Rollen oder API Berechtigungen möglich, etwa über Applikations-Berechtigungen oder RBAC Zuweisungen. Aus der Sicht von Cyber-Kriminellen sind Service Principals oft attraktiv, weil sie in vielen Umgebungen weniger restriktiv abgesichert sind. Da Service Principals primär für programmatischen Zugriff gedacht sind bieten sie standardmäßig keinen GUI Zugang.

Nachdem die Grundlagen geklärt sind, geht es im nächsten Schritt darum zu verstehen, dass eine Identität in der Microsoft Cloud in verschiedenen Kontexten Berechtigungen besitzen kann. Besonders relevant sind Berechtigungen innerhalb von Microsoft Entra ID und im Azure Resource Manager (ARM). Diese beiden Berechtigungsebenen sind dabei größtenteils voneinander unabhängig.

Das heißt konkret, dass ein Konto mit der Entra-ID-Rolle Global Reader nicht automatisch Zugriff auf sämtliche Ressourcen in Azure hat. Beginnen wir mit Entra ID und nutzen zur Betrachtung zunächst die grafische Oberfläche.

Die Entra-ID-Oberfläche lässt sich auf mehreren Wegen aufrufen. Beispielsweise über das Entra ID Admin Center unter https://entra.microsoft.com oder über das Azure-Portal unter https://portal.azure.com.

Im ersten Schritt suchen wir unter Benutzer → Alle Benutzer den betreffenden Ausgangsaccount und prüfen anschließend im Reiter Zugewiesene Rollen welche Rollen ihm zugewiesen sind. In unserem Beispiel sind dem kompromittierten Konto keine Rollen zugewiesen. Cyber-Kriminelle würden in dieser Situation nach Möglichkeiten suchen, ihre Berechtigungen zu erweitern. Mögliche Ansatzpunkte sind dynamische Gruppen mit unsicheren Mitgliedschaftsregeln oder App-Registrierungen, bei denen die Benutzerin bzw. der Benutzer über Berechtigungen zum Ändern von Anmeldeeigenschaften verfügt.

Bei Dynamischen Gruppen werden Mitglieder automatisch auf Basis von definierten Regeln hinzugefügt. Um dynamische Gruppen zu identifizieren, navigiert man im Entra-ID-Portal zu Gruppen → All Gruppen und filtert nach dem Mitgliedschaftstyp: Dynamisch. Durch Auswahl einer Gruppe lässt sich unter dem Reiter Dynamische Mitgliedschaftsregeln die zugehörige Regel einsehen.

In dem konstruierten Beispiel ist eine Gruppe mit dem Namen KeyVault-Dienstleister zu sehen. Die Beitrittsregel definiert, dass alle Benutzerinnen und Benutzer, deren Benutzerprinzipalname (Anmeldename) die Zeichenkette dienstleister.com enthält, automatisch hinzugefügt werden. Die konkrete Regel lautet user.userPrincipalName -contains „dienstleister.com“. Unter dem Menüpunkt „Azure-Rollenzuweisung“ sehen wir, dass diese Gruppe automatisch die Rolle „Geheimnisbenutzer für Schlüsseltresore“ über einen Key Vault mit dem Namen „KeyVault-Dienstleister“ erhält. 

Das Ziel dieser Gruppe besteht darin, allen Mitarbeiterinnen und Mitarbeiter des externen Dienstleisters automatisch Zugriff auf einen Azure Key Vault zuzuweisen. In diesem speichert der Dienstleister die Systempasswörter für den Kunden. Der Ansatz ist grundsätzlich nachvollziehbar, da die Benutzerkonten des Dienstleisters im Anmeldenamen die Domain des Dienstleisters enthalten und somit eindeutig identifizierbar sind. Da in der Beitrittsregel jedoch nicht der Operator „endet mit“, sondern „enthält“ verwendet wird, besteht ein potenzielles Sicherheitsrisiko. Benutzerkonten, deren Benutzerprinzipalname die Zeichenkette dienstleister.com lediglich irgendwo enthält, würden ebenfalls der Gruppe hinzugefügt. Dadurch könnte die Regel unter Umständen missbraucht oder unbeabsichtigt ausgelöst werden, etwa durch gezielt gewählte Anmeldenamen.

Nach der Analyse der Gruppen werden im nächsten Schritt die App-Registrierungen betrachtet. App-Registrierungen ermöglichen es Anwendungen oder Diensten, sich gegenüber Microsoft Entra ID zu authentifizieren, um auf geschützte Cloudressourcen zuzugreifen. Dabei definiert eine App-Registrierung die Identität einer Anwendung. Auf Basis dieser Registrierung wird im jeweiligen Tenant ein Service Principal erstellt, der die tatsächliche Sicherheitsidentität der Anwendung darstellt. Zur Authentifizierung werden in der App-Registrierung Anmeldeinformationen in Form von Client Secrets oder Zertifikaten hinterlegt. Diese können durch die Eigentümer der Anwendung oder durch Konten mit entsprechenden administrativen Berechtigungen verwaltet werden. Durch das Hinzufügen solcher Anmeldeinformationen ist eine Authentifizierung gegenüber Entra ID im Kontext der Anwendung möglich (z. B. mittels Client-Credentials-Flow).

App-Registrierungen können zwei verschiedene Typen von Berechtigungen haben. Delegierte Berechtigungen bedeuten, dass die effektiven Rechte der Anwendung eine Schnittmenge aus den Rechten des angemeldeten Benutzers und den von der App angeforderten Rechten bilden. Solche Berechtigungen erlauben der App nur in Kombination mit einem Benutzerkonto zu handeln. Anwendungsberechtigungen sind hingegen eigenständige Berechtigungen, die der Anwendung unabhängig von einem Benutzerkonto erteilt werden und der Anwendung damit weitreichende, autonome Operationen erlauben können. Jedoch muss hier ein Administrator des Tenants diese Berechtigungen bestätigen (Admin Consent). Sinnvoll ist es meist nur solche Anwendungen weiterzuverfolgen, die Anwendungsberechtigungen besitzen. 

App-Registrierungen lassen sich im „Entra ID Admin Center“ unter dem entsprechenden Menüpunkt einsehen. In unserem Beispiel sehen wir, dass der kompromittierte Account eine eigene Anwendungen hat. Bei der Enumeration dieser sehen wir unter API-Berechtigungen das die Anwendung die Anwendungsberechtigung RoleManagement.ReadWrite.Directory hat. Da es sich hierbei um eine Anwendungsberechtigung mit erteiltem Admin Consent handelt, erfolgt die Authentifizierung vollständig im Kontext der Anwendung. Die Berechtigung erlaubt es der Anwendung, unabhängig von Benutzerrechten Entra-ID-Rollen für andere Identitäten zu verwalten, etwa Rollen zuzuweisen oder zu entfernen.

Nachdem wir Entra-ID untersucht haben, widmen wir uns nun dem Bereich Azure, diesmal anhand von PowerShell. Ein erster Prüfpunkt ist, ob dem kompromittierten Konto überhaupt Abonnements angezeigt werden. Azure-Abonnements sind logische Verwaltungseinheiten, die den Zugriff auf Azure-Ressourcen regeln, Abrechnungen ermöglichen und als Sicherheits- sowie Berechtigungsgrenze innerhalb einer Azure-Umgebung dienen. Fehlen dem Konto sichtbare Abonnements, sind direkte Angriffe auf Azure-Ressourcen deutlich eingeschränkt oder nicht möglich.

Beim Login mit dem Azure PowerShell Modul (Az) über Connect-AzAccount wird, sofern dem Konto mehrere Abonnements zur Verfügung stehen, automatisch ein Standard-Abonnement ausgewählt. Um in ein anderes Abonement zu wechseln kann der Befehl Get-AzContext alle verfügbaren angezeigt und mittels Set-AzContext -SubscriptionId <ID> in ein anderes gewechselt werden. 

Um nun alle sichtbaren Ressourcen anzeigen zu lassen kann der Befehl Get-AzResource verwendet werden. Die dann ausgegebene Übersicht kann mitunter sehr lang sein. Um einen genaueren Eindruck zu erhalten welche Berechtigungen der Account auf die jeweiligen Ressourcen hat, kann mittels des Befehles Get-AzRoleAssignment -SignInName <Name> alle RBAC Zuweisungen für den Account ausgelesen werden. Sollte die Ausgabe hier auch wieder sehr groß sein, empfielt es sich mittels Pipe und Format-List Scope,RoleDefinitionName die Ausgabe ein wenig aufzuräumen. Die Ausgabe wird dann in etwa so aussehen.

Wir sehen hier, dass wir unter anderem auf einer VM die Rolle Contributor haben. Diese Rolle ermöglicht unter anderem die Ausführung von Befehlen auf der VM. Eine Möglichkeit zur Befehlsausführung stellt der Azure Run Command des Az PowerShell Modules dar. Über diesen können Skripte auf der VM ausgeführt werden. Dabei ist zu beachten, dass keine einzelnen Befehle direkt, sondern ausschließlich Skripte ausgeführt werden können. Im vorliegenden Beispiel wurde ein Skript verwendet, das lediglich aus einer einzelnen Zeile mit dem Befehl whoami besteht.

Es kann hier beobachtet werden das die über den Run Command ausgeführten Befehle in der Regel mit Systemrechten abgearbeitet werden. Das bedeutet auf Windows meist als NT AUTHORITY\SYSTEM und auf Linux typischerweise als root.

Bei weiterer Betrachtung der virtuellen Maschine mittels des Befehles Get-AzVM -ResourceGroupName <GroupName> -Name <VMName> | FL * fällt eine zugeordnete Managed Identity auf. Managed Identities sind Sonderformen von Service Principals und können, ähnlich wie Benutzerkonten, mit RBAC-Zuweisungen und anderen Berechtigungen ausgestattet sein.

In Kombination mit dem Run-Command besteht die Möglichkeit, einen gültigen JWT-Token anzufordern und diesen dann zur Anmeldung zu verwenden. Dadurch ist es möglich, die zugehörige Managed Identity zu nutzen und deren Berechtigungen für weitere Aktionen innerhalb der Umgebung zu missbrauchen. Mehr dazu in der nächsten Ausgabe dieser Serie.

Fazit

In der Enumerationsphase haben wir mehrere Wege identifiziert, wie wir unsere Rechte erweitern und/oder weitere Identitäten kompromittieren können. Im dritten Teil werden wir die darauffolgenden Phasen, Privilege Escalation und Lateral Movement, weiter beleuchten.