Translated ['', 'src/pentesting-cloud/aws-security/aws-post-exploitation

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation.md

@@ -1,4 +1,4 @@
-# AWS - IAM Post Exploitation
+# AWS - IAM Post-exploitation
 
 {{#include ../../../banners/hacktricks-training.md}}
 
@@ -10,17 +10,17 @@ Pour plus d'informations sur l'accès IAM :
 ../aws-services/aws-iam-enum.md
 {{#endref}}
 
-## Problème du Député Confus
+## Problème du Confused Deputy
 
-Si vous **permettez à un compte externe (A)** d'accéder à un **rôle** dans votre compte, vous aurez probablement **0 visibilité** sur **qui peut exactement accéder à ce compte externe**. C'est un problème, car si un autre compte externe (B) peut accéder au compte externe (A), il est possible que **B puisse également accéder à votre compte**.
+Si vous **autorisez un compte externe (A)** à accéder à un **role** dans votre compte, vous n'aurez probablement **aucune visibilité** sur **qui peut exactement accéder à ce compte externe**. C'est un problème, car si un autre compte externe (B) peut accéder au compte externe (A), il est possible que **B puisse aussi accéder à votre compte**.
 
-Par conséquent, lorsque vous permettez à un compte externe d'accéder à un rôle dans votre compte, il est possible de spécifier un `ExternalId`. C'est une chaîne "secrète" que le compte externe (A) **doit spécifier** pour **assumer le rôle dans votre organisation**. Comme le **compte externe B ne connaîtra pas cette chaîne**, même s'il a accès à A, il **ne pourra pas accéder à votre rôle**.
+Par conséquent, lorsque vous autorisez un compte externe à accéder à un role dans votre compte, il est possible de spécifier un `ExternalId`. C'est une chaîne "secrète" que le compte externe (A) **doit spécifier** afin de **assume the role in your organization**. Comme le **compte externe B ne connaîtra pas cette chaîne**, même s'il a accès à A il **ne pourra pas accéder à votre role**.
 
 <figure><img src="../../../images/image (95).png" alt=""><figcaption></figcaption></figure>
 
-Cependant, notez que ce `ExternalId` "secret" **n'est pas un secret**, quiconque peut **lire la politique d'assumer le rôle IAM pourra le voir**. Mais tant que le compte externe A le connaît, mais que le compte externe **B ne le connaît pas**, cela **empêche B d'abuser de A pour accéder à votre rôle**.
+Cependant, notez que ce `ExternalId` "secret" **n'est pas un secret**, toute personne pouvant **lire la IAM assume role policy pourra le voir**. Mais tant que le compte externe A le connaît, et que le compte externe **B ne le connaît pas**, cela **empêche B d'abuser d'A pour accéder à votre role**.
 
-Exemple :
+Exemple:
 ```json
 {
 "Version": "2012-10-17",
@@ -39,11 +39,11 @@ Exemple :
 }
 ```
 > [!WARNING]
-> 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.
+> Pour qu'un attaquant exploite un confused deputy, il devra d'une manière ou d'une autre déterminer si les principals du compte actuel peuvent usurper des rôles dans d'autres comptes.
 
 ### Confiances inattendues
 
-#### Wildcard comme principal
+#### Wildcard en tant que principal
 ```json
 {
 "Action": "sts:AssumeRole",
@@ -51,7 +51,7 @@ Exemple :
 "Principal": { "AWS": "*" }
 }
 ```
-Cette politique **permet à tous les AWS** d'assumer le rôle.
+Cette stratégie **autorise tous les AWS** à assumer le rôle.
 
 #### Service en tant que principal
 ```json
@@ -62,7 +62,7 @@ Cette politique **permet à tous les AWS** d'assumer le rôle.
 "Resource": "arn:aws:lambda:000000000000:function:foo"
 }
 ```
-Cette politique **permet à tout compte** de configurer son apigateway pour appeler cette Lambda.
+Cette politique **autorise n'importe quel compte** à configurer son apigateway pour appeler cette Lambda.
 
 #### S3 en tant que principal
 ```json
@@ -73,7 +73,7 @@ Cette politique **permet à tout compte** de configurer son apigateway pour appe
 }
 }
 ```
-Si un bucket S3 est donné comme principal, parce que les buckets S3 n'ont pas d'ID de compte, si vous **avez supprimé votre bucket et que l'attaquant l'a créé** dans son propre compte, alors il pourrait en abuser.
+Si un S3 bucket est donné comme principal, parce que les S3 buckets n'ont pas d'Account ID, si vous **avez supprimé votre bucket et que l'attacker l'a recréé** dans son propre compte, alors il pourrait en abuser.
 
 #### Non pris en charge
 ```json
@@ -84,8 +84,81 @@ Si un bucket S3 est donné comme principal, parce que les buckets S3 n'ont pas d
 "Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*"
 }
 ```
-Une méthode courante pour éviter les problèmes de Confused Deputy est l'utilisation d'une condition avec `AWS:SourceArn` pour vérifier l'ARN d'origine. Cependant, **certains services pourraient ne pas le supporter** (comme CloudTrail selon certaines sources).
+Une manière courante d'éviter les problèmes de Confused Deputy est l'utilisation d'une condition avec `AWS:SourceArn` pour vérifier l'ARN d'origine. Cependant, **certains services peuvent ne pas le prendre en charge** (comme CloudTrail selon certaines sources).
 
+### Suppression des identifiants
+Avec l'une quelconque des permissions suivantes — `iam:DeleteAccessKey`, `iam:DeleteLoginProfile`, `iam:DeleteSSHPublicKey`, `iam:DeleteServiceSpecificCredential`, `iam:DeleteInstanceProfile`, `iam:DeleteServerCertificate`, `iam:DeleteCloudFrontPublicKey`, `iam:RemoveRoleFromInstanceProfile` — un acteur peut supprimer access keys, login profiles, SSH keys, service-specific credentials, instance profiles, certificates ou CloudFront public keys, ou dissocier des rôles des instance profiles. De telles actions peuvent immédiatement bloquer des utilisateurs et applications légitimes et provoquer un denial-of-service ou une perte d'accès pour les systèmes qui dépendent de ces credentials, donc ces permissions IAM doivent être strictement restreintes et surveillées.
+```bash
+# Remove Access Key of a user
+aws iam delete-access-key \
+--user-name <Username> \
+--access-key-id AKIAIOSFODNN7EXAMPLE
+
+## Remove ssh key of a user
+aws iam delete-ssh-public-key \
+--user-name <Username> \
+--ssh-public-key-id APKAEIBAERJR2EXAMPLE
+```
+### Suppression d'identités
+Avec des autorisations telles que `iam:DeleteUser`, `iam:DeleteGroup`, `iam:DeleteRole` ou `iam:RemoveUserFromGroup`, un acteur peut supprimer des utilisateurs, des rôles ou des groupes — ou modifier l'appartenance à un groupe — supprimant des identités et les traces associées. Cela peut immédiatement interrompre l'accès des personnes et des services qui dépendent de ces identités, provoquant un déni de service ou une perte d'accès ; ces actions IAM doivent donc être strictement restreintes et surveillées.
+```bash
+# Delete a user
+aws iam delete-user \
+--user-name <Username>
+
+# Delete a group
+aws iam delete-group \
+--group-name <Username>
+
+# Delete a role
+aws iam delete-role \
+--role-name <Role>
+```
+###
+Avec l'une quelconque des permissions suivantes — `iam:DeleteGroupPolicy`, `iam:DeleteRolePolicy`, `iam:DeleteUserPolicy`, `iam:DeletePolicy`, `iam:DeletePolicyVersion`, `iam:DeleteRolePermissionsBoundary`, `iam:DeleteUserPermissionsBoundary`, `iam:DetachGroupPolicy`, `iam:DetachRolePolicy`, `iam:DetachUserPolicy` — un acteur peut supprimer ou détacher des managed/inline policies, supprimer des policy versions ou des permissions boundaries, et désassocier des policies de users, groups ou roles. Cela détruit des autorisations et peut altérer le modèle de permissions, provoquant une perte d'accès immédiate ou un déni de service pour les principals qui dépendaient de ces policies, donc ces actions IAM doivent être strictement restreintes et surveillées.
+```bash
+# Delete a group policy
+aws iam delete-group-policy \
+--group-name <GroupName> \
+--policy-name <PolicyName>
+
+# Delete a role policy
+aws iam delete-role-policy \
+--role-name <RoleName> \
+--policy-name <PolicyName>
+```
+### Suppression d'identité fédérée
+Avec `iam:DeleteOpenIDConnectProvider`, `iam:DeleteSAMLProvider` et `iam:RemoveClientIDFromOpenIDConnectProvider`, un acteur peut supprimer des fournisseurs d'identité OIDC/SAML ou retirer des ID client. Cela interrompt l'authentification fédérée, empêche la validation des tokens et refuse immédiatement l'accès aux utilisateurs et services qui s'appuient sur le SSO, jusqu'à ce que l'IdP ou les configurations soient restaurés.
+```bash
+# Delete OIDCP provider
+aws iam delete-open-id-connect-provider \
+--open-id-connect-provider-arn arn:aws:iam::111122223333:oidc-provider/accounts.google.com
+
+# Delete SAML provider
+aws iam delete-saml-provider \
+--saml-provider-arn arn:aws:iam::111122223333:saml-provider/CorporateADFS
+```
+### Activation illégitime de MFA
+Avec `iam:EnableMFADevice`, un acteur peut enregistrer un MFA device sur l’identité d’un utilisateur, empêchant l’utilisateur légitime de se connecter. Une fois qu’un MFA non autorisé est activé, l’utilisateur peut être bloqué jusqu’à ce que l’appareil soit supprimé ou réinitialisé (remarque : si plusieurs MFA devices sont enregistrés, la connexion n’exige qu’un seul, donc cette attaque n’aura aucun effet pour refuser l’accès).
+```bash
+aws iam enable-mfa-device \
+--user-name <Username> \
+--serial-number arn:aws:iam::111122223333:mfa/alice \
+--authentication-code1 123456 \
+--authentication-code2 789012
+```
+### Altération des métadonnées des certificats/clés
+Avec `iam:UpdateSSHPublicKey`, `iam:UpdateCloudFrontPublicKey`, `iam:UpdateSigningCertificate`, `iam:UpdateServerCertificate`, un acteur peut modifier le statut ou les métadonnées des clés publiques et des certificats. En marquant des clés/certificats comme inactifs ou en altérant des références, il peut casser l'authentification SSH, invalider les validations X.509/TLS et perturber immédiatement les services dépendant de ces identifiants, provoquant une perte d'accès ou de disponibilité.
+```bash
+aws iam update-ssh-public-key \
+--user-name <Username> \
+--ssh-public-key-id APKAEIBAERJR2EXAMPLE \
+--status Inactive
+
+aws iam update-server-certificate \
+--server-certificate-name <Certificate_Name> \
+--new-path /prod/
+```
 ## Références
 
 - [https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation.md

@@ -10,15 +10,15 @@ Pour plus d'informations, consultez :
 ../aws-services/aws-kms-enum.md
 {{#endref}}
 
-### Chiffrer/Déchiffrer des informations
+### Chiffrement/Déchiffrement des informations
 
-`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://` and `file://` are URI schemes used in AWS CLI commands to specify the path to local files:
 
 - `fileb://:` Lit le fichier en mode binaire, couramment utilisé pour les fichiers non textuels.
-- `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.
+- `file://:` Lit le fichier en mode texte, typiquement utilisé pour les fichiers texte simples, scripts ou JSON qui n'ont pas d'exigences d'encodage spéciales.
 
 > [!TIP]
-> Notez que si vous souhaitez déchiffrer des données à l'intérieur d'un fichier, le fichier doit contenir les données binaires, et non des données encodées en base64. (fileb://)
+> Notez que si vous voulez déchiffrer des données contenues dans un fichier, le fichier doit contenir les données binaires, et non des données encodées en base64. (fileb://)
 
 - Utilisation d'une clé **symétrique**
 ```bash
@@ -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 \
@@ -60,14 +60,14 @@ aws kms decrypt \
 ```
 ### KMS Ransomware
 
-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 sur celles-ci**, supprimant l'accès accordé au compte légitime.
+Un attaquant disposant d'un accès privilégié à KMS pourrait modifier la KMS policy des clés et **accorder à son compte l'accès à celles-ci**, supprimant l'accès accordé au compte légitime.
 
-Ensuite, 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 ainsi un ransomware facile mais efficace sur le compte.
+Ensuite, les utilisateurs du compte légitime ne pourront plus accéder à aucune information de tout service ayant été chiffré avec ces clés, créant un ransomware simple 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 que **AWS managed keys ne sont pas affectées** par cette attaque, seulement **Customer managed keys**.
 
-> 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 qu'il est nécessaire d'utiliser le paramètre **`--bypass-policy-lockout-safety-check`** (l'absence de cette option dans la console web rend cette attaque possible uniquement depuis la CLI).
 ```bash
 # Force policy change
 aws kms put-key-policy --key-id mrk-c10357313a644d69b4b28b88523ef20c \
@@ -92,34 +92,91 @@ aws kms put-key-policy --key-id mrk-c10357313a644d69b4b28b88523ef20c \
 }
 ```
 > [!CAUTION]
-> Notez que si vous changez 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 car l'action Put Policy ne peut pas être effectuée d'un compte à l'autre**.
+> Notez que si vous modifiez cette policy et ne donnez l'accès qu'à un compte externe, puis que depuis ce compte externe vous essayez de définir une nouvelle policy pour **rendre l'accès au compte d'origine, vous n'y arriverez pas car l'action Put Polocy ne peut pas être effectuée depuis un cross account**.
 
 <figure><img src="../../../images/image (77).png" alt=""><figcaption></figcaption></figure>
 
-### Ransomware KMS Générique
+### Generic KMS Ransomware
 
-#### Ransomware KMS Global
+Il existe une autre façon d'exécuter un KMS Ransomware global, qui impliquerait les étapes suivantes :
 
-Il existe une autre façon d'effectuer un ransomware KMS global, qui impliquerait les étapes suivantes :
+- Create a new **key with a key material** imported by the attacker
+- **Re-encrypt older data** of the victim encrypted with the previous version with the new one.
+- **Delete the KMS key**
+- Now only the attacker, who has the original key material could be able to decrypt the encrypted data
 
-- 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
+### Delete Keys via kms:DeleteImportedKeyMaterial
 
-### Détruire les clés
+Avec la permission `kms:DeleteImportedKeyMaterial`, un acteur peut supprimer le key material importé des CMKs ayant `Origin=EXTERNAL` (CMKs qui ont importé leur key material), les rendant incapables de déchiffrer des données. Cette action est destructive et irréversible à moins qu'un matériel compatible ne soit ré-importé, permettant à un attaquant de provoquer effectivement une perte de données de type ransomware en rendant les informations chiffrées définitivement inaccessibles.
 ```bash
-# Destoy they key material previously imported making the key useless
-aws kms delete-imported-key-material --key-id 1234abcd-12ab-34cd-56ef-1234567890ab
+aws kms delete-imported-key-material --key-id <Key_ID>
+```
+### Destruction des keys
 
+La destruction des keys peut permettre d'effectuer un DoS.
+```bash
 # Schedule the destoy of a key (min wait time is 7 days)
 aws kms schedule-key-deletion \
 --key-id arn:aws:kms:us-west-2:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab \
 --pending-window-in-days 7
 ```
 > [!CAUTION]
-> Notez qu'AWS **empêche désormais les actions précédentes d'être effectuées depuis un compte croisé :**
+> Notez qu'AWS empêche désormais **que les actions précédentes soient effectuées depuis un compte croisé :**
 
+### Modifier ou supprimer un alias
+Cette attaque supprime ou redirige les alias AWS KMS, rompant la résolution des clés et provoquant des échecs immédiats dans tous les services qui dépendent de ces alias, entraînant un denial-of-service. Avec des permissions comme `kms:DeleteAlias` ou `kms:UpdateAlias` un attaquant peut supprimer ou réorienter des alias et perturber les opérations cryptographiques (e.g., encrypt, describe). Tout service qui référence l'alias au lieu du key ID peut échouer jusqu'à ce que l'alias soit restauré ou correctement remappé.
+```bash
+# Delete Alias
+aws kms delete-alias --alias-name alias/<key_alias>
+
+# Update Alias
+aws kms update-alias \
+--alias-name alias/<key_alias> \
+--target-key-id <new_target_key>
+```
+### Cancel Key Deletion
+Avec des permissions telles que `kms:CancelKeyDeletion` et `kms:EnableKey`, un acteur peut annuler une suppression planifiée d'une AWS KMS customer master key puis la réactiver ultérieurement. Ce faisant, il récupère la clé (initialement en état Disabled) et restaure sa capacité à déchiffrer des données protégées précédemment, permettant l'exfiltration.
+```bash
+# Firts cancel de deletion
+aws kms cancel-key-deletion \
+--key-id <Key_ID>
+
+## Second enable the key
+aws kms enable-key \
+--key-id <Key_ID>
+```
+### Disable Key
+Avec la permission `kms:DisableKey`, un acteur peut désactiver une AWS KMS customer master key, empêchant son utilisation pour l'encryption ou la decryption. Cela interrompt l'accès pour tous les services qui dépendent de ce CMK et peut provoquer des perturbations immédiates ou un denial-of-service jusqu'à ce que la clé soit réactivée.
+```bash
+aws kms disable-key \
+--key-id <key_id>
+```
+### Dériver un secret partagé
+Avec la permission `kms:DeriveSharedSecret`, un acteur peut utiliser une clé privée détenue par KMS ainsi qu'une clé publique fournie par l'utilisateur pour calculer un secret partagé ECDH.
+```bash
+aws kms derive-shared-secret \
+--key-id <key_id> \
+--public-key fileb:///<route_to_public_key> \
+--key-agreement-algorithm <algorithm>
+```
+### Impersonation via kms:Sign
+Avec la permission `kms:Sign`, un acteur peut utiliser une KMS-stored CMK pour signer cryptographiquement des données sans exposer la private key, produisant des signatures valides qui peuvent permettre l'impersonation ou autoriser des actions malveillantes.
+```bash
+aws kms sign \
+--key-id <key-id> \
+--message fileb://<ruta-al-archivo> \
+--signing-algorithm <algoritmo> \
+--message-type RAW
+```
+### DoS avec Custom Key Stores
+Avec des permissions telles que `kms:DeleteCustomKeyStore`, `kms:DisconnectCustomKeyStore` ou `kms:UpdateCustomKeyStore`, un acteur peut modifier, déconnecter ou supprimer un AWS KMS Custom Key Store (CKS), rendant ses clés principales inopérantes. Cela empêche les opérations de chiffrement, de déchiffrement et de signature pour tous les services qui dépendent de ces clés et peut provoquer un denial-of-service immédiat. Il est donc crucial de restreindre et de surveiller ces permissions.
+```bash
+aws kms delete-custom-key-store --custom-key-store-id <CUSTOM_KEY_STORE_ID>
+
+aws kms disconnect-custom-key-store --custom-key-store-id <CUSTOM_KEY_STORE_ID>
+
+aws kms update-custom-key-store --custom-key-store-id <CUSTOM_KEY_STORE_ID> --new-custom-key-store-name <NEW_NAME> --key-store-password <NEW_PASSWORD>
+```
 <figure><img src="../../../images/image (76).png" alt=""><figcaption></figcaption></figure>
 
 {{#include ../../../banners/hacktricks-training.md}}