Réponse à incident AWS : de la clé divulguée au minage

Scénario fictif. Tout ce qui figure dans cet article (l'entreprise, les personnes, le compte 111122223333, les clés, le bucket) est inventé. Les adresses IP proviennent des plages réservées à la documentation par la RFC 5737. Ce sont les données qui se cachent derrière le bouton Essayer un exemple de l'analyseur : vous pouvez donc reproduire chaque étape.

En bref. Le 14 septembre 2026 (fictif), la clé d'accès du développeur dev-marco est utilisée depuis un VPS sous Kali Linux. En 48 minutes, l'attaquant valide la clé, énumère le compte, crée un utilisateur administrateur backup-admin doté de sa propre clé et d'un mot de passe console, supprime GuardDuty dans deux régions, télécharge 320 objets depuis acme-customer-exports et lance huit instances GPU dans ap-southeast-1 qui minent pour un pool. Les journaux montrent tout. Le verdict est Signes de compromission, et la liste de remédiation doit couvrir deux clés, un utilisateur, une politique, deux détecteurs, huit instances et une évaluation des obligations de notification.

Les preuves

Le ZIP d'exemple reproduit de vrais exports :

Quatre journées calmes (du 10 au 13 septembre) fournissent la référence : ops-julia se connecte à la console avec MFA depuis l'adresse du bureau 198.51.100.24 ; dev-marco utilise la CLI avec sa clé à long terme depuis la même adresse ; un rôle de tâche ECS est assumé chaque jour.

Chronologie (UTC, 14 septembre 2026)

Le rapport d'identifiants ajoute une détection de configuration : backup-admin possède un mot de passe console et aucune MFA.

Le déroulé de l'investigation

1. Le verdict. Vingt-trois détections, dont plusieurs de sévérité élevée portant des signaux côté attaquant (anomalie d'accès, contournement des défenses, exfiltration, impact) : le verdict est « Signes de compromission ». Les principales raisons listées sont le user agent offensif, la clé utilisée depuis une nouvelle adresse IP, la politique administrateur, la clé créée pour un autre utilisateur et les deux suppressions de GuardDuty.

2. Le point d'entrée. Pivotez sur AKIA3EXAMPLEMARCO123 dans l'onglet « Entités » : quatre jours depuis 198.51.100.24 avec une CLI sous macOS, puis, à partir de 09:02, 203.0.113.77 avec une chaîne de build Kali. Le tout premier appel depuis la nouvelle adresse est GetCallerIdentity : l'ouverture classique d'une clé d'accès divulguée. La manière dont la clé a fuité (le scénario évoque un dépôt public) échappe aux journaux AWS.

3. La seconde clé. Pivotez sur 203.0.113.77 : en plus de la clé de dev-marco, cette adresse a utilisé AKIA3EXAMPLEBKUP4567, la clé émise à 09:09:05 pour backup-admin. À partir de 09:12, l'attaquant n'utilise plus jamais la clé divulguée. Désactiver uniquement la clé de dev-marco n'aurait rien changé. C'est le schéma de persistance IAM dans sa forme la plus simple.

4. Le contournement des défenses. Les deux détecteurs sont supprimés en moins d'une minute, trois minutes après la création de la backdoor. CloudTrail, lui, continue de tourner (aucun StopLogging), et c'est pour cela que la suite de l'histoire est visible. Les détections GuardDuty n'ont survécu que parce qu'elles avaient été exportées ; voir l'article sur le contournement des défenses.

5. Les données. 320 GetObject en 21 minutes, par un seul principal, sur un seul bucket, vus deux fois : dans les événements de données CloudTrail et dans les journaux d'accès au serveur. Les clés d'objets (de exports/2026/customers/customers-0001.csv.gz à -0320) constituent l'inventaire des données divulguées. Notez que les VPC Flow Logs ne montrent rien ici : le téléchargement est allé de S3 à l'hôte de l'attaquant via Internet, sans jamais passer par le VPC. C'est exactement la limite décrite dans les preuves d'exfiltration de données S3.

6. Le coût. Une région sans activité pendant la période de référence, une augmentation de quota, une paire de clés, SSH ouvert au monde entier et huit instances GPU ; à partir de 09:52, leurs interfaces communiquent chaque minute avec une même adresse sur des ports de pools. L'article sur le minage de cryptomonnaie couvre cette phase.

7. La session console. À 09:50, l'attaquant se connecte en tant que backup-admin sans MFA. Tout ce qui serait fait ensuite dans la console apparaîtrait avec sessionCredentialFromConsole ; dans ce jeu de données, la session clôt l'histoire.

La liste de remédiation qui en découle

Le confinement d'abord, avec les valeurs tirées des journaux :

1. Désactivez AKIA3EXAMPLEMARCO123 et AKIA3EXAMPLEBKUP4567 ; remplacez la clé de dev-marco et purgez-la du dépôt.
2. Sauvegardez puis supprimez backup-admin (politique, clé, profil de connexion).
3. Détachez AdministratorAccess de backup-admin et passez en revue les autres détenteurs.
4. Bloquez les appels d'API depuis 203.0.113.77 pendant l'investigation.
5. Faites un snapshot d'une instance, supprimez les huit instances d'ap-southeast-1, vérifiez toutes les autres régions ; supprimez la paire de clés ops-maint et le groupe de sécurité ouvert ; retirez la demande de quota L-417A185B.
6. Réactivez GuardDuty dans us-east-1 et eu-west-1 (idéalement partout).
7. Considérez acme-customer-exports comme exfiltré : listez les 320 objets et évaluez les obligations de notification.
8. Ouvrez un dossier auprès du support AWS au sujet de l'utilisation non autorisée.

Ce que cet exemple ne montre pas

Les incidents réels sont plus désordonnés : rôles de CI bruyants, plusieurs adresses IP côté attaquant, chaînage de rôles, activité étalée sur des semaines, journaux absents précisément là où vous en avez besoin. L'exemple est volontairement propre pour que la méthode soit visible. Lisez les limites d'une investigation fondée uniquement sur les journaux avant d'accorder la même confiance à des données réelles, et suivez le guide d'analyse pas à pas pour la démarche.