Analyse forensic d’une collecte KAPE : la méthode pas à pas

Lundi matin, plusieurs serveurs ne redémarrent plus, des partages de fichiers sont vides, et un message de revendication circule sur un forum. L'attaquant est passé par l'Active Directory et a déployé un wiper, un programme conçu pour détruire les données plutôt que pour les chiffrer. Un administrateur a eu le bon réflexe de couper plusieurs machines avant la fin de l'effacement. Vous récupérez une collecte KAPE de l'une d'elles, et il faut répondre vite à trois questions : comment ils sont entrés, jusqu'où ils sont allés, et ce qui a été détruit.

Cet article décrit la méthode que nous suivons sur ce type d'incident, artefact par artefact, avec les outils gratuits qu'on utilise réellement. Elle vaut pour un wiper comme pour un ransomware : seule la dernière étape change.

Avant de commencer : préserver et préparer

Commencez par calculer l'empreinte SHA-256 de l'archive de collecte telle que vous l'avez reçue, et notez-la avec la date, l'heure et le nom de la personne qui vous l'a remise. Travaillez ensuite uniquement sur une copie. Si l'affaire va un jour devant un juge ou un assureur, cette traçabilité fera la différence.

Côté outils, tout ce dont vous avez besoin est gratuit. Les outils d'Eric Zimmerman (MFTECmd, PECmd, EvtxECmd, AmcacheParser, AppCompatCacheParser, RECmd, Timeline Explorer) transforment chaque artefact en fichier CSV lisible. Hayabusa et Chainsaw passent les journaux d'événements au crible de milliers de règles Sigma et font ressortir l'anormal en quelques minutes. Une machine d'analyse Windows dédiée, sans accès au réseau de production, suffit.

Dans les commandes qui suivent, la collecte est extraite dans C:\Triage\C et les résultats vont dans C:\Analyse. On lance tous les traitements d'un coup, puis on analyse :

EvtxECmd.exe -d C:\Triage\C\Windows\System32\winevt\Logs --csv C:\Analyse\evtx
MFTECmd.exe -f "C:\Triage\C\$MFT" --csv C:\Analyse\mft
MFTECmd.exe -f "C:\Triage\C\$Extend\$J" --csv C:\Analyse\usn
PECmd.exe -d C:\Triage\C\Windows\prefetch --csv C:\Analyse\prefetch
AmcacheParser.exe -f C:\Triage\C\Windows\appcompat\Programs\Amcache.hve --csv C:\Analyse\amcache
AppCompatCacheParser.exe -f C:\Triage\C\Windows\System32\config\SYSTEM --csv C:\Analyse\shimcache
RECmd.exe -d C:\Triage\C --bn BatchExamples\Kroll_Batch.reb --csv C:\Analyse\registre
hayabusa.exe csv-timeline -d C:\Triage\C\Windows\System32\winevt\Logs -o C:\Analyse\hayabusa.csv

Commencez toujours par le résultat de Hayabusa. En quelques minutes, il vous donne une liste triée par gravité des événements suspects : effacement de journaux, services étranges, connexions anormales. C'est votre point de départ, pas votre conclusion.

Question 1 : quand et comment l'attaquant est-il arrivé sur cette machine ?

On cherche d'abord les connexions. Dans le journal Sécurité, l'événement 4624 enregistre chaque ouverture de session réussie, et son champ « type de connexion » dit comment : 3 pour une connexion réseau (partage de fichiers, PsExec, WMI), 10 pour le bureau à distance. L'événement 4625 enregistre les échecs, et une rafale d'échecs suivie d'un succès sur le même compte raconte souvent toute l'histoire. L'événement 4672 indique qu'une session a reçu des privilèges d'administrateur.

Pour le bureau à distance, deux journaux spécialisés complètent le tableau : l'événement 1149 du journal TerminalServices-RemoteConnectionManager (authentification réussie, avec l'adresse source), et les événements 21, 24 et 25 du journal TerminalServices-LocalSessionManager (ouverture, déconnexion et reconnexion de session).

Filtrez ces événements dans Timeline Explorer autour des premières anomalies, et notez trois choses : le compte utilisé, l'adresse ou la machine source, et l'heure. Un compte de service qui ouvre une session interactive à 3 heures du matin, ou un compte d'administrateur du domaine qui se connecte depuis un poste utilisateur, sont des pistes sérieuses.

Question 2 : comment s'est-il déplacé dans le réseau ?

Pour passer d'une machine à l'autre, les attaquants utilisent presque toujours les mêmes mécanismes, et chacun laisse des traces bien connues sur la machine de destination.

Le dernier cas est le plus inquiétant. Quand un wiper arrive par une stratégie de groupe, c'est que l'attaquant contrôlait l'Active Directory : la même stratégie s'est appliquée à toutes les machines qu'elle visait. L'analyse d'une seule machine ne suffit plus, il faut récupérer les journaux du contrôleur de domaine pour savoir qui a créé ou modifié cette stratégie, et quand.

Question 3 : qu'est-ce qui a été exécuté ?

Quatre artefacts permettent de retrouver les programmes lancés, même quand l'attaquant a supprimé ses fichiers. Aucun n'est parfait seul, mais ensemble ils se recoupent.

Le Prefetch est le plus précis : pour chaque programme exécuté, il donne le nombre d'exécutions, les huit dernières dates de lancement et les fichiers chargés dans les premières secondes. Attention, il est désactivé par défaut sur Windows Server : sur un serveur, son absence ne prouve rien.

L'Amcache recense les programmes présents ou exécutés, avec leur chemin et surtout leur empreinte SHA-1. C'est souvent là qu'on récupère l'empreinte du wiper alors que le fichier a disparu, ce qui permet de le rechercher sur VirusTotal et sur les autres machines.

La Shimcache (ou AppCompatCache) liste les exécutables vus par le système. Sur les versions récentes de Windows, elle prouve qu'un fichier était présent, pas forcément qu'il a été lancé. La clé BAM du registre, enfin, donne la dernière exécution d'un programme pour chaque utilisateur.

Cherchez en particulier les exécutables lancés depuis des dossiers inhabituels (C:\Users\Public, C:\ProgramData, C:\Windows\Temp), les outils d'administration détournés (PsExec, vssadmin, wevtutil, bcdedit) et les noms à une lettre ou aléatoires. Si la journalisation PowerShell est active, l'événement 4104 du journal PowerShell/Operational contient le texte exact des scripts exécutés, et le fichier ConsoleHost_history.txt de chaque profil garde l'historique des commandes tapées.

Question 4 : qu'est-ce qui a été détruit, et jusqu'où ?

C'est la question propre au wiper, et la réponse se trouve dans le système de fichiers. Le journal USN ($J) enregistre chaque modification de fichier avec un code de raison. Un wiper laisse une signature très reconnaissable : des milliers d'événements DataOverwrite ou DataTruncation (le contenu est écrasé), suivis de FileDelete, sur quelques minutes, souvent dans l'ordre alphabétique des dossiers.

Triez le résultat de MFTECmd sur le journal USN par date, et repérez le début et la fin de la rafale. Le premier fichier touché donne l'heure de démarrage du wiper, et le dernier montre où il en était quand la machine a été coupée. En comparant avec la $MFT, vous pouvez lister précisément les dossiers détruits et ceux qui sont intacts. C'est exactement ce qu'attendent la direction et l'assureur.

Vérifiez aussi les mesures prises pour empêcher la restauration : exécution de vssadmin, wmic ou bcdedit dans le Prefetch et l'Amcache, et désactivation de Windows Defender (événement 5001 du journal Windows Defender/Operational). Notez enfin une limite importante : si le wiper s'attaque aussi au secteur de démarrage du disque, la collecte triage ne le montre pas. Il faut alors une image complète du disque.

Question 5 : l'attaquant a-t-il effacé ses traces ?

L'effacement d'un journal laisse lui-même une trace : l'événement 1102 dans le journal Sécurité, et l'événement 104 dans le journal Système pour les autres journaux. Un trou inexpliqué dans la chronologie d'un journal, ou un journal Sécurité qui commence quelques minutes avant l'incident, sont aussi des indices. Dans ce cas, appuyez-vous sur les artefacts que l'attaquant pense rarement à nettoyer : $MFT, journal USN, Amcache et Prefetch.

Assembler la chronologie

Chaque réponse précédente donne quelques horodatages. Rassemblez-les dans un seul tableau, avec pour chaque ligne la date et l'heure en UTC, la source (artefact et fichier), ce qui s'est passé, et votre niveau de confiance. Ouvrez-le dans Timeline Explorer à côté des CSV bruts pour vérifier chaque point.

Travaillez toujours en UTC : les outils d'Eric Zimmerman affichent l'UTC, et mélanger heures locales et UTC est l'erreur la plus fréquente dans les rapports d'incident. Une fois la chronologie établie, extrayez les indicateurs de compromission (comptes, adresses IP, noms et empreintes de fichiers, noms de services et de tâches) et recherchez-les immédiatement sur les autres machines du réseau.

Récapitulatif : quel artefact pour quelle question

Questions fréquentes

Faut-il éteindre une machine pendant une attaque par wiper ?
Dans le cas d'un wiper ou d'un ransomware en cours d'exécution, couper l'alimentation stoppe la destruction, et sauver les données passe avant tout. On perd la mémoire vive, mais les traces sur le disque restent exploitables. Si l'attaque n'est pas en train de détruire des données, isolez plutôt la machine du réseau sans l'éteindre.

Une collecte KAPE suffit-elle pour une investigation ?
Elle suffit pour répondre vite aux questions principales sur une machine, ce qui est l'essentiel dans les premières heures. Pour une attaque qui touche l'Active Directory, il faut aussi les journaux des contrôleurs de domaine, et une image complète du disque si le secteur de démarrage a pu être touché.

Combien de temps prend une analyse de collecte KAPE ?
Le traitement automatique prend quelques dizaines de minutes. L'analyse elle-même demande de quelques heures à une journée par machine selon la complexité, d'où l'intérêt de commencer par les machines les plus critiques et de rechercher ensuite les indicateurs trouvés sur tout le parc.

Quelle différence entre un wiper et un ransomware ?
Un ransomware chiffre les données pour réclamer une rançon : avec la clé, elles sont récupérables. Un wiper les détruit sans possibilité de retour, souvent dans un but politique ou de sabotage, parfois en se faisant passer pour un ransomware. Seules les sauvegardes hors ligne permettent de s'en relever.

Pour les premières décisions à prendre pendant l'attaque elle-même, lisez notre guide sur les 5 premières heures d'une attaque par ransomware. Et pour détecter les signes avant-coureurs, avant la destruction, voyez les attaques Active Directory les plus courantes et comment les détecter, ainsi que nos requêtes SPL de détection.