Réponse à incident AWS : enquêter sur un compte compromis

En bref. Face à un « notre compte AWS est compromis », menez deux chantiers en parallèle : stopper l'hémorragie (désactiver les identifiants que détient l'attaquant, arrêter ce qu'il a lancé) et préserver puis lire les journaux (CloudTrail d'abord, puis les événements de données ou journaux d'accès S3, les VPC Flow Logs, les détections GuardDuty et le rapport d'identifiants IAM). Délimitez le périmètre avant de nettoyer : chaque utilisateur IAM, clé, relation d'approbation de rôle et instance créés par l'attaquant doit être retrouvé, sinon vous fermerez la porte d'entrée en laissant la porte dérobée ouverte. Le reste de cette série détaille chaque étape.

La plupart des incidents AWS que je traite ne commencent pas par une zero-day. Ils commencent par un identifiant : une clé d'accès commitée dans un dépôt, une clé restée dans des logs de CI, un mot de passe console sans MFA, ou un rôle qui accorde trop largement sa confiance. La suite est remarquablement constante : vérifier que la clé fonctionne, énumérer, se créer un moyen de revenir, aveugler les défenseurs, puis voler des données ou brûler de la puissance de calcul. Cette régularité est une bonne nouvelle pour les équipes de réponse, car chaque étape laisse un appel d'API bien précis dans CloudTrail.

Minute zéro : les signes qu'un compte AWS est compromis

Le déclencheur est généralement l'un des suivants :

AWS documente les types de détections GuardDuty liés à IAM et publie une politique gérée, AWSCompromisedKeyQuarantineV3, qu'il peut attacher à un utilisateur IAM dont il estime la clé exposée. Si vous trouvez cette politique attachée à un utilisateur, la fuite est confirmée : ne la retirez pas, et suivez le dossier de support.

Première heure : contenir sans détruire les preuves

Le confinement et la préservation des preuves ne s'opposent que si l'on travaille sans méthode. L'ordre qui fonctionne :

1. Sécurisez les journaux dont vous dépendez. Téléchargez les objets CloudTrail de la période depuis le bucket du trail, exportez les détections GuardDuty et générez le rapport d'identifiants IAM. Si l'attaquant dispose de droits administrateur, il peut supprimer les trails et les détecteurs ; l'historique des événements ne conserve que 90 jours d'événements de gestion par région. Le guide d'export des journaux donne les commandes exactes.
2. Désactivez les identifiants dont vous savez qu'ils sont compromis. Pour une clé d'utilisateur IAM : aws iam update-access-key --status Inactive. Pour une session de rôle, utilisez l'option « Revoke active sessions » de la console IAM, qui ajoute un refus pour les jetons émis avant l'instant présent (documentation AWS).
3. Ne supprimez pas ce que vous n'avez pas examiné. Supprimer un utilisateur créé par l'attaquant supprime aussi ses politiques inline et ses clés, que vous voulez garder au dossier. Détachez, désactivez, puis supprimez une fois le périmètre établi.
4. Arrêtez l'hémorragie financière. Prenez un snapshot puis arrêtez ou résiliez les instances non autorisées, dans toutes les régions.
5. Ouvrez un dossier de support auprès d'AWS. Les recommandations re:Post sur les activités non autorisées comme le playbook aws-samples sur les identifiants compromis conseillent de prévenir AWS tôt.

Délimiter le périmètre : lire l'attaque dans CloudTrail

Délimiter le périmètre, c'est répondre à quatre questions, chacune avec son pivot dans CloudTrail :

• Quel identifiant est entré en premier ? Pivotez sur userIdentity.accessKeyId et sourceIPAddress. Une clé d'accès à long terme (préfixe AKIA) soudain utilisée depuis une adresse absente de son historique, c'est le schéma classique de la clé divulguée. Commencez par l'investigation d'une clé d'accès divulguée.
• Qu'a-t-il appris ? Un appel GetCallerIdentity suivi en quelques minutes de dizaines d'appels List*, Describe* et Get*, souvent accompagnés d'erreurs AccessDenied, c'est de l'énumération.
• Qu'a-t-il créé ? CreateUser, CreateAccessKey, CreateLoginProfile, AttachUserPolicy, UpdateAssumeRolePolicy, de nouveaux fournisseurs SAML/OIDC, des paires de clés, des fonctions Lambda. L'article sur la persistance IAM les passe tous en revue.
• À quoi a-t-il touché ? Lectures d'objets S3 (visibles uniquement avec les événements de données ou les journaux d'accès serveur), snapshots partagés avec d'autres comptes, secrets lus, instances lancées.

L'article sur les événements CloudTrail que tout intervenant doit connaître donne la liste complète avec les correspondances MITRE ATT&CK. À ce stade, l'objectif est une chronologie : chaque action de l'attaquant, dans l'ordre, avec le principal, la clé, l'IP et la ressource concernés.

Les pivots qui comptent

Continuez à pivoter tant que cela fait apparaître de nouvelles entités. L'IP de l'attaquant vous mènera à une deuxième clé ; la deuxième clé à un utilisateur ; l'utilisateur à un rôle qu'il a assumé.

Délimiter le périmètre au-delà de CloudTrail

Les événements de gestion CloudTrail vous disent ce qui a été configuré. Ils ne disent pas quels objets ont été lus ni combien d'octets ont quitté un VPC. Pour cela, il vous faut les preuves d'accès aux données S3 et l'analyse des VPC Flow Logs. Si ces sources n'ont jamais été activées, écrivez-le dans le rapport au lieu de conclure que rien n'a été volé : les limites d'une investigation fondée uniquement sur les journaux méritent d'être lues avant de rédiger la moindre conclusion.

Si le point d'entrée n'était pas un identifiant AWS mais une identité fédérée, les preuves commencent chez le fournisseur d'identité : une connexion passée par Okta s'examine plutôt avec oktaforensics.com, et une clé divulguée depuis un dépôt avec githubforensics.com. Pour des workloads EKS compromis, le journal d'audit Kubernetes compte autant que CloudTrail (kubernetesforensics.com).

Éradication : supprimer chaque point d'ancrage

Une fois la chronologie stabilisée, nettoyez dans cet ordre :

1. Désactivez puis supprimez chaque clé d'accès créée pendant l'incident.
2. Supprimez les utilisateurs IAM créés par l'attaquant (après avoir sauvegardé leurs politiques), les profils de connexion et les dispositifs MFA.
3. Détachez les politiques administrateur accordées pendant l'incident ; vérifiez qui d'autre en dispose.
4. Annulez les modifications des politiques d'approbation de rôle et supprimez les fournisseurs d'identité inconnus.
5. Retirez les permissions Lambda publiques, les URL de fonction sans authentification, les paires de clés EC2 et les user data modifiées.
6. Réactivez CloudTrail, GuardDuty, Config et tout service de sécurité désactivé par l'attaquant, dans toutes les régions.
7. Faites tourner chaque secret que l'attaquant a pu lire.

Si vous utilisez AWS Organizations, envisagez une stratégie de contrôle des services qui interdit les régions inutilisées : vous privez l'attaquant de sa cachette préférée.

La place de l'outil

AWS Forensics réalise cette étape de délimitation dans votre navigateur. Déposez les fichiers CloudTrail exportés (ainsi que les flow logs, les journaux d'accès S3, les détections GuardDuty et le rapport d'identifiants si vous les avez) et il rend un verdict (« Aucun signe de compromission dans ces logs », « Activité suspecte — à examiner » ou « Signes de compromission ») avec les détections, les lignes de preuve derrière chacune, une chronologie et une checklist de remédiation qui commence par le confinement. Rien n'est envoyé. Le guide d'analyse pas à pas présente la démarche, et le déroulé d'un incident fictif l'applique de bout en bout sur les données d'exemple.

Le verdict est une aide au triage, pas une conclusion. Il ne vaut que ce que valent les journaux que vous lui fournissez, et chaque détection affiche ses preuves pour que vous puissiez la confirmer ou l'écarter.

FAQ

Comment savoir si mon compte AWS a été compromis ?

Cherchez dans CloudTrail les appels d'API que vous ne pouvez attribuer à personne : une clé d'accès à long terme utilisée depuis une adresse IP inconnue, des utilisateurs IAM ou des clés que personne n'a créés, GuardDuty ou CloudTrail désactivés, des instances dans des régions que vous n'utilisez jamais, ou des téléchargements S3 massifs. Un pic de facturation ou une détection GuardDuty est souvent le premier signe visible.

Faut-il supprimer immédiatement la clé d'accès compromise ?

Désactivez-la d'abord plutôt que de la supprimer. Une clé inactive ne peut plus signer de requêtes, mais elle existe toujours, ce qui simplifie l'investigation. Supprimez-la une fois que vous avez établi ce qu'elle a fait et que vous l'avez remplacée partout où elle était utilisée légitimement.

Dois-je contacter AWS ?

AWS demande à ses clients d'ouvrir un dossier de support lorsqu'ils soupçonnent des identifiants compromis, et c'est la voie à suivre pour toute question sur des frais non autorisés. Le dossier de support ne remplace pas votre propre investigation dans CloudTrail.

Pour aller plus loin

• AWS Security Incident Response Guide : le processus de réponse à incident d'AWS lui-même.
• Remediating potentially compromised AWS credentials : documentation GuardDuty.
• Incident response guide for AWS CloudTrail investigations : AWS Security Blog.
• Matrice IaaS de MITRE ATT&CK : les techniques citées tout au long de cette série.