# AWS - S3 Post Exploitation

{{#include ../../../banners/hacktricks-training.md}}

## S3

Pour plus d'informations, consultez :

{{#ref}}
../aws-services/aws-s3-athena-and-glacier-enum.md
{{#endref}}

### Informations Sensibles

Parfois, vous pourrez trouver des informations sensibles lisibles dans les buckets. Par exemple, des secrets d'état terraform.

### Pivotement

Différentes plateformes pourraient utiliser S3 pour stocker des actifs sensibles.\
Par exemple, **airflow** pourrait y stocker le **code** des **DAGs**, ou des **pages web** pourraient être directement servies depuis S3. Un attaquant avec des permissions d'écriture pourrait **modifier le code** du bucket pour **pivoter** vers d'autres plateformes, ou **prendre le contrôle des comptes** en modifiant des fichiers JS.

### Ransomware S3

Dans ce scénario, l'**attaquant crée une clé KMS (Key Management Service) dans son propre compte AWS** ou un autre compte compromis. Il rend ensuite cette **clé accessible à quiconque dans le monde**, permettant à tout utilisateur, rôle ou compte AWS d'encrypter des objets en utilisant cette clé. Cependant, les objets ne peuvent pas être décryptés.

L'attaquant identifie un **bucket S3 cible et obtient un accès en écriture** à celui-ci en utilisant diverses méthodes. Cela pourrait être dû à une mauvaise configuration du bucket qui l'expose publiquement ou à l'accès de l'attaquant à l'environnement AWS lui-même. L'attaquant cible généralement des buckets contenant des informations sensibles telles que des informations personnellement identifiables (PII), des informations de santé protégées (PHI), des journaux, des sauvegardes, et plus encore.

Pour déterminer si le bucket peut être ciblé pour un ransomware, l'attaquant vérifie sa configuration. Cela inclut la vérification si **S3 Object Versioning** est activé et si **la suppression par authentification multi-facteurs (MFA delete) est activée**. Si la version d'objet n'est pas activée, l'attaquant peut procéder. Si la version d'objet est activée mais que la suppression MFA est désactivée, l'attaquant peut **désactiver la version d'objet**. Si à la fois la version d'objet et la suppression MFA sont activées, il devient plus difficile pour l'attaquant de ransomware ce bucket spécifique.

En utilisant l'API AWS, l'attaquant **remplace chaque objet dans le bucket par une copie chiffrée en utilisant sa clé KMS**. Cela chiffre effectivement les données dans le bucket, les rendant inaccessibles sans la clé.

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 par ransomware.

**Pour plus d'infos** [**consultez la recherche originale**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**

{{#include ../../../banners/hacktricks-training.md}}
