AWS - S3 Post-Exploitation
Tip
Apprenez et pratiquez le hacking AWS :
HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP :HackTricks Training GCP Red Team Expert (GRTE)
Apprenez et pratiquez le hacking Azure :
HackTricks Training Azure Red Team Expert (AzRTE)
Soutenir HackTricks
- Vérifiez les plans d’abonnement !
- Rejoignez le 💬 groupe Discord ou le groupe telegram ou suivez-nous sur Twitter 🐦 @hacktricks_live.
- Partagez des astuces de hacking en soumettant des PR au HackTricks et HackTricks Cloud dépôts github.
S3
Pour plus d’informations, consultez :
AWS - S3, Athena & Glacier Enum
Informations sensibles
Parfois, vous pourrez trouver des informations sensibles lisibles dans les buckets. Par exemple, terraform state secrets.
Pivoting
Différentes plateformes peuvent utiliser S3 pour stocker des ressources sensibles.
Par exemple, airflow pourrait y stocker le DAGs code, ou des web pages pourraient être servies directement depuis S3. Un attaquant disposant d’autorisations d’écriture pourrait modify the code depuis le bucket pour pivot vers d’autres plateformes, ou takeover accounts en modifiant des fichiers JS.
S3 Ransomware
Dans ce scénario, l’attaquant crée une KMS (Key Management Service) key dans son propre compte AWS ou dans un autre compte compromis. Il rend ensuite cette key accessible à n’importe quel utilisateur, rôle ou compte dans le monde, permettant à tout utilisateur, rôle ou compte AWS de chiffrer des objets avec cette key. Cependant, les objets ne peuvent pas être déchiffrés.
L’attaquant identifie un bucket S3 cible et obtient un accès en écriture dessus en utilisant diverses méthodes. Cela peut ê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 PII, PHI, des logs, des backups, etc.
Pour déterminer si le bucket peut être ciblé pour du ransomware, l’attaquant vérifie sa configuration. Cela inclut la vérification si S3 Object Versioning est activé et si multi-factor authentication delete (MFA delete) est activé. Si Object Versioning n’est pas activé, l’attaquant peut continuer. Si Object Versioning est activé mais que MFA delete est désactivé, l’attaquant peut disable Object Versioning. Si Object Versioning et MFA delete sont tous deux activés, il devient plus difficile pour l’attaquant de chiffrer ce bucket spécifique avec un ransomware.
En utilisant l’API AWS, l’attaquant remplace chaque objet dans le bucket par une copie chiffrée utilisant leur KMS key. Cela chiffre effectivement les données du bucket, les rendant inaccessibles sans la key.
Pour mettre davantage de pression, l’attaquant planifie la suppression de la KMS key 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 key soit supprimée et que les données deviennent définitivement perdues.
Enfin, l’attaquant peut téléverser 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éversé sans chiffrement, probablement pour attirer l’attention de la cible et l’informer de l’attaque.
s3:RestoreObject
Un attaquant disposant de la permission s3:RestoreObject peut réactiver des objets archivés dans Glacier ou Deep Archive, les rendant temporairement accessibles. Cela permet la récupération et l’exfiltration de données historiquement archivées (backups, snapshots, logs, certifications, vieux secrets) qui seraient normalement hors de portée. Si l’attaquant combine cette permission avec des permissions de lecture (par exemple, s3:GetObject), il peut obtenir des copies complètes de données sensibles.
aws s3api restore-object \
--bucket <BUCKET_NAME> \
--key <OBJECT_KEY> \
--restore-request '{
"Days": <NUMBER_OF_DAYS>,
"GlacierJobParameters": { "Tier": "Standard" }
}'
s3:Delete*
Un attaquant disposant de la permission s3:Delete* peut supprimer des objets, des versions et des buckets entiers, perturber les sauvegardes et provoquer une perte de données immédiate et irréversible, la destruction de preuves et la compromission des artefacts de sauvegarde ou de récupération.
# Delete an object from a bucket
aws s3api delete-object \
--bucket <BUCKET_NAME> \
--key <OBJECT_KEY>
# Delete a specific version
aws s3api delete-object \
--bucket <BUCKET_NAME> \
--key <OBJECT_KEY> \
--version-id <VERSION_ID>
# Delete a bucket
aws s3api delete-bucket \
--bucket <BUCKET_NAME>
Pour plus d’informations check the original research.
Tip
Apprenez et pratiquez le hacking AWS :
HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP :HackTricks Training GCP Red Team Expert (GRTE)
Apprenez et pratiquez le hacking Azure :
HackTricks Training Azure Red Team Expert (AzRTE)
Soutenir HackTricks
- Vérifiez les plans d’abonnement !
- Rejoignez le 💬 groupe Discord ou le groupe telegram ou suivez-nous sur Twitter 🐦 @hacktricks_live.
- Partagez des astuces de hacking en soumettant des PR au HackTricks et HackTricks Cloud dépôts github.
HackTricks Cloud

