AWS - S3 Post Exploitation
S3
Pour plus d'informations, consultez :
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 DAG, 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 le versionnage d'objet n'est pas activé, l'attaquant peut procéder. Si le versionnage d'objet est activé mais que la suppression MFA est désactivée, l'attaquant peut désactiver le versionnage d'objet. Si à la fois le versionnage d'objet et la suppression MFA sont activés, 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.
Last updated
