AWS - S3 Post Exploitation

Tip

Apprenez & pratiquez AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Apprenez & pratiquez GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Apprenez & pratiquez Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Soutenez HackTricks

S3

For more information check:

AWS - S3, Athena & Glacier Enum

Sensitive Information

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

Pivoting

Different platforms could be using S3 to store sensitive assets.
For example, airflow could be storing DAGs code in there, or web pages could be directly served from S3. Un attaquant disposant de permissions d’écriture pourrait modifier le 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 clé KMS (Key Management Service) dans son propre compte AWS ou dans un autre compte compromis. Il rend ensuite cette clé accessible à n’importe qui dans le monde, permettant à tout utilisateur, rôle ou compte AWS de chiffrer des objets avec cette clé. Cependant, les objets ne peuvent pas être déchiffrés.

L’attaquant identifie un S3 bucket cible et obtient un accès en écriture dessus en utilisant diverses méthodes. Cela peut être dû à une mauvaise configuration du bucket l’exposant publiquement ou à l’accès de l’attaquant à l’environnement AWS lui-même. L’attaquant cible généralement les buckets contenant des informations sensibles telles que PII, PHI, les logs, les backups, et plus encore.

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 la multi-factor authentication delete (MFA delete) est activée. Si Object Versioning n’est pas activé, l’attaquant peut procéder. Si Object Versioning est activé mais que MFA delete est désactivé, l’attaquant peut désactiver Object Versioning. Si à la fois Object Versioning et MFA delete sont activés, il devient plus difficile pour l’attaquant d’exécuter un ransomware sur ce bucket spécifique.

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

Pour exercer 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é soit supprimée et que les données deviennent irrémédiablement perdues.

Enfin, l’attaquant peut uploader un fichier final, généralement nommé “ransom-note.txt”, qui contient des instructions pour la cible sur la manière de récupérer ses fichiers. Ce fichier est uploadé sans chiffrement, probablement pour attirer l’attention de la cible et l’informer de l’attaque de ransomware.

SSE-C (Customer-Provided Key) Ransomware (Codefinger-like)

Une autre variante abuse de SSE-C (S3 server-side encryption with customer-provided keys). Avec SSE-C, le client fournit la clé de chiffrement à chaque requête et AWS ne stocke pas la clé. Cela signifie que si un attaquant réécrit des objets en utilisant sa propre clé SSE-C, les données de la victime deviennent illisibles à moins que la victime puisse fournir cette clé contrôlée par l’attaquant.

  • Preconditions: Compromised AWS credentials (or any principal with the right permissions) and the ability to rewrite objects (e.g., s3:PutObject on the target keys/prefixes). This is often paired with the ability to set destructive lifecycle policies (see below), e.g. s3:PutLifecycleConfiguration.
  • Attack chain:
  1. Attacker generates a random 256-bit key (AES-256) and keeps it.
  2. Attacker rewrites existing objects (same object keys) using SSE-C headers so the stored object is now encrypted with the attacker key.
  3. Victim cannot download/decrypt without providing the SSE-C key (even if IAM permissions are fine).
  4. Attacker can delete the key (or simply never provide it) to make data unrecoverable.

Example (conceptual) CLI usage:

# Upload/overwrite an object encrypted with attacker-provided SSE-C key
aws s3 cp ./file s3://<BUCKET>/<KEY> \
--sse-c AES256 \
--sse-c-key <BASE64_32_BYTES>

# Download requires providing the same key again
aws s3 cp s3://<BUCKET>/<KEY> ./file \
--sse-c AES256 \
--sse-c-key <BASE64_32_BYTES>
Ajouter de la pression : abus du “timer” de cycle de vie

Pour supprimer les options de récupération (comme les anciennes versions), un attaquant peut associer des réécritures SSE-C à des règles de cycle de vie qui expirent les objets et/ou suppriment les versions non actuelles après une courte période :

  • s3:PutLifecycleConfiguration sur le bucket permet à un attaquant de programmer des suppressions sans émettre d’opérations delete explicites pour chaque objet/version.
  • Ceci est particulièrement impactant lorsque la gestion des versions est activée, car cela peut supprimer l’ancienne version valide qui permettrait autrement la récupération.
Détection & atténuations
  • Préférez SSE-KMS (ou SSE-S3) à SSE-C sauf si vous avez une raison opérationnelle solide d’autoriser SSE-C.
  • Surveillez/alertez les requêtes PutObject utilisant des en-têtes SSE-C (CloudTrail data events pour S3).
  • Surveillez/alertez les PutBucketLifecycleConfiguration inattendus (changements de lifecycle).
  • Surveillez/alertez les pics soudains d’activité d’écrasement (mêmes clés mises à jour rapidement) et les suppressions de delete-marker/version.
  • Restreindre les permissions à haut risque : limitez s3:PutObject aux préfixes nécessaires ; restreignez fortement s3:PutLifecycleConfiguration et s3:PutBucketVersioning ; envisagez d’exiger MFA pour les actions d’administration sensibles (lorsque applicable) et utilisez des rôles admin séparés avec approbations.
  • Posture de récupération : utilisez versioning, backups, et des copies immuables/hors ligne (S3 replication vers un compte protégé, backup vaults, etc.) ; protégez les versions non actuelles contre les suppressions agressives et protégez les changements de lifecycle avec des SCPs / guardrails.

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 archivées historiquement (sauvegardes, snapshots, logs, certifications, anciens secrets) qui seraient normalement hors de portée. Si l’attaquant combine cette permission avec des permissions de lecture (par ex., 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 d’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 & pratiquez AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Apprenez & pratiquez GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Apprenez & pratiquez Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Soutenez HackTricks