Analyse des logs CloudTrail : le guide pas à pas

En bref. Collectez les exports, déposez-les tous dans l'analyseur, puis travaillez dans cet ordre : verdict et couverture (ce que l'outil a pu voir et ce qu'il n'a pas pu voir) → détections (confirmez chacune à partir de ses lignes de preuve) → pivots sur les entités (chaque clé, IP et principal touchés par l'attaquant) → chronologie (le récit, dans l'ordre) → remédiation (le confinement d'abord). Comptez 30 à 60 minutes pour un incident typique de clé divulguée. Tout s'exécute localement en WebAssembly ; aucun journal ne quitte votre navigateur.

Ce guide s'appuie sur AWS Forensics parce que c'est ce que propose ce site, mais la méthode reste la même quel que soit votre outil : Athena, CloudTrail Lake, un SIEM ou jq. Les questions ne changent pas ; seule la vitesse à laquelle on y répond change.

Étape 1 — Collecter les exports

Récupérez les fichiers CloudTrail de la fenêtre de l'incident ainsi que deux à trois jours calmes qui la précèdent. Deux détections, « Clé d’accès à long terme utilisée depuis une nouvelle adresse IP » et « Activité dans une région jusque-là inutilisée », se comparent au premier jour d'activité trouvé dans les journaux : sans référence, elles n'ont rien à quoi se comparer. L'outil vous avertit lorsque moins de deux jours de CloudTrail sont chargés.

Ajoutez tout ce dont vous disposez par ailleurs :

• les VPC Flow Logs (exfiltration réseau, trafic de minage) ;
• les journaux d'accès serveur S3 ou les événements de données S3 de CloudTrail (lectures d'objets) ;
• le JSON des détections GuardDuty ;
• le rapport d'identifiants IAM (MFA, clés root, utilisateurs créés pendant l'incident).

Le guide d'export donne les commandes pour chaque source.

Étape 2 — Tout charger d'un coup

Sur la page d'accueil, choisissez des fichiers ou un dossier, ou déposez-les. Sont acceptés tels quels :

Les ZIP (y compris imbriqués) et les fichiers gzip sont décompressés en flux : des exports de plusieurs gigaoctets n'ont pas besoin de tenir en mémoire. Les fichiers digest sont reconnus et ignorés. L'onglet Fichiers liste chaque fichier avec le format détecté, et une section « Fichiers non analysés » explique tout ce qui a été écarté : un journal ALB, un flow log au format Parquet, un gzip tronqué.

Pour vous entraîner d'abord, cliquez sur Essayer un exemple : cela charge un export synthétique d'un incident fictif, clairement présenté comme tel.

Étape 3 — Lire le verdict et les remarques de couverture

Le verdict comporte trois niveaux :

• Signes de compromission : au moins une détection critique, ou deux détections de sévérité élevée dont au moins un signal côté attaquant (anomalie d'accès, reconnaissance, contournement des défenses, exfiltration, impact ou détection GuardDuty).
• Activité suspecte — à examiner : toute détection élevée ou moyenne, ou plusieurs détections faibles.
• Aucun signe de compromission dans ces logs : aucune détection ne s'est déclenchée.

Les détections de configuration issues du rapport d'identifiants (clés root, utilisateurs sans MFA) sont affichées mais exclues du verdict : elles décrivent une posture, pas une activité.

Lisez ensuite le bloc Couverture. « Aucun événement de données S3 ni journal d’accès S3 » signifie que le vol de données dans les buckets ne peut pas être évalué, pas qu'il n'a pas eu lieu. Un verdict « Aucun signe de compromission » accompagné de trois avertissements de couverture est une affirmation fragile ; notez-le. L'article sur les limites va plus loin.

Étape 4 — Confirmer chaque détection à partir de ses preuves

Chaque détection affiche sa sévérité, les techniques MITRE ATT&CK, les paramètres extraits (clé, principal, IP, bucket, région…), la période concernée et les événements de preuve. Ouvrez l'enregistrement d'origine au moins du premier et du dernier événement de preuve.

Les questions à se poser pour chaque détection :

1. Qui ? userIdentity.arn et userIdentity.accessKeyId. S'agit-il d'un humain, d'un rôle de CI, d'un service AWS ?
2. D'où ? sourceIPAddress et userAgent. L'IP de sortie de l'entreprise, un runner de CI, un VPS ?
3. Est-ce que ça a réussi ? L'absence d'errorCode signifie un succès ; AccessDenied signifie que la tentative a échoué.
4. Existe-t-il un ticket de changement ? Le travail d'administration ressemble à celui d'un attaquant. Interrogez la personne nommée dans l'événement.

Les détections orientent ; elles ne prouvent pas. Une détection « Instances GPU lancées » dans le compte d'une équipe de machine learning, c'est un mardi ordinaire. La même détection sur une clé qui se trouvait hier sur un portable à Lyon et aujourd'hui sur un VPS, c'est un incident.

Étape 5 — Pivoter sur les entités pour délimiter le périmètre

L'onglet Entités liste chaque principal, clé d'accès, adresse IP, région, ressource et user agent présents dans les journaux, avec le nombre d'événements, les erreurs, les première et dernière occurrences et ce avec quoi chacun a été vu. Les entités qui apparaissent dans des détections sont signalées.

La boucle de délimitation :

1. Pivotez sur la clé divulguée → notez chaque IP depuis laquelle elle a été utilisée.
2. Pivotez sur chaque IP de l'attaquant → notez toutes les autres clés ou tous les autres principaux utilisés depuis celle-ci.
3. Pivotez sur chaque nouveau principal (un utilisateur créé par l'attaquant, un rôle qu'il a assumé) → notez ce qu'il a fait.
4. Recommencez jusqu'à ce qu'aucune nouvelle entité n'apparaisse.

C'est ainsi que vous trouvez la deuxième clé d'accès que l'attaquant a générée pour son utilisateur de porte dérobée, et que l'activité de la première clé à elle seule ne vous montrerait pas. L'investigation d'une clé d'accès divulguée applique cette boucle en détail.

Étape 6 — Construire la chronologie

L'onglet Chronologie ordonne les événements de preuve de chaque détection (jusqu'à six par détection). L'onglet Événements contient l'ensemble complet des enregistrements, avec des filtres (source, « Dans les détections uniquement », « Erreurs uniquement », « Écritures uniquement ») et une bascule entre UTC et heure locale. Cliquez sur n'importe quelle ligne pour afficher l'enregistrement d'origine.

Pour le dossier d'investigation :

• l'export CSV des événements filtrés (les cellules qui pourraient être interprétées comme des formules de tableur sont neutralisées) ;
• le Rapport JSON, avec le verdict, les détections, les preuves et les statistiques.

Rédigez le récit en UTC et conservez les exports d'origine à côté.

Étape 7 — Dérouler la checklist de remédiation

L'onglet Remédiation fusionne les étapes de remédiation de toutes les détections, confinement en premier, avec les valeurs réelles renseignées : la clé à désactiver, l'utilisateur à supprimer, la région où GuardDuty doit être réactivé. Cochez les éléments au fur et à mesure (l'état n'est conservé que dans la page).

Avant de supprimer quoi que ce soit, assurez-vous d'avoir sauvegardé ce dont vous avez besoin comme preuves : les politiques inline des utilisateurs de porte dérobée, les user data des instances modifiées, un snapshot des instances de l'attaquant. Suivez ensuite le Security Incident Response Guide d'AWS pour le reste du processus.

Pièges courants

• Une seule région d'historique des événements. L'historique des événements est régional ; les attaquants affectionnent les régions que vous n'ouvrez jamais.
• Pas de référence. Ne charger que le jour de l'incident rend aveugles les détections « nouvelle IP » et « nouvelle région ».
• Se fier au sourceIPAddress des services AWS. Quand un service agit pour votre compte, le champ contient un nom de service comme ec2.amazonaws.com, pas une IP.
• S'arrêter à la première clé. La première clé, c'est la porte par laquelle ils sont entrés, pas tout ce qu'ils détiennent.

À lire aussi

• Les événements CloudTrail que tout intervenant doit connaître
• Déroulé d'un incident fictif : de la clé divulguée au minage de cryptomonnaie
• Réponse à incident AWS : enquêter sur un compte compromis