Translated ['src/banners/hacktricks-training.md', 'src/pentesting-ci-cd/

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.

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 \

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
 

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
 
 <figure><img src="../../../images/image (79).png" alt=""><figcaption></figcaption></figure>
 
-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
 

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 '[

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

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",

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

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.
 
 <figure><img src="../../../../images/image (120).png" alt=""><figcaption></figcaption></figure>
 
@@ -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:<acc_id>:function:<func_name>: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}}

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.
 
 <figure><img src="../../../../images/image (267).png" alt=""><figcaption><p><a href="https://www.clearvector.com/blog/content/images/size/w1000/2022/11/2022110801.rapid.mitm.png">https://www.clearvector.com/blog/content/images/size/w1000/2022/11/2022110801.rapid.mitm.png</a></p></figcaption></figure>
 
 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/)

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

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
 

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

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 :
 
 <figure><img src="../../../images/image (226).png" alt=""><figcaption></figcaption></figure>
 
-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}}

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.
 

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
 {

src/pentesting-cloud/aws-security/aws-persistence/aws-ssm-perssitence.md

@@ -1 +1 @@
-# AWS - SSM Perssitence
+# AWS - Persistance SSM

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