Étude de cas $LogFile : une enquête fictive pas à pas
Une intrusion fictive sur FIN-WKS-07 traitée avec le $LogFile NTFS : compte illégitime, binaire antidaté, rclone, note supprimée, puis rédaction du rapport.
TL;DR. Ce cas est fictif. Il s'appuie sur le $LogFile et le $MFT synthétiques fournis avec le parseur de $LogFile dans le navigateur (Essayer un exemple). En 57 minutes de journal, un compte illégitime svc_backup obtient un profil, télécharge tools.zip, en extrait m64.exe, le déplace vers \ProgramData\Intel et l'antidate à 2019, dépose rc.tmp et le renomme rclone.exe, écrit puis supprime creds.txt, et laisse un .lnk vers Payroll_2026.xlsx. Le journal prouve les déplacements, la réécriture et la suppression avec les valeurs avant/après. Il ne prouve ni l'exécution ni l'exfiltration : il faut d'autres artefacts pour cela.
L'histoire prolonge celle racontée sur l'ensemble des sites de parseurs de cette famille : un poste du service financier, un compte d'apparence technique que personne n'aurait dû créer, et un fichier de paie qui a fini sur une clé USB. Tous les noms, heures et octets ci-dessous sont inventés, et le journal a été généré à partir du format publié, pas capturé sous Windows.
La situation (fictive)
- Machine : FIN-WKS-07, Windows 11, service financier.
- Déclencheur : une alerte DLP sur des données de paie copiées sur un support amovible ; un compte
svc_backupque personne n'a créé volontairement. - Question du responsable d'incident : « Qu'a fait
svc_backupsur ce poste ce matin, et qu'a-t-il touché ? » - Collecté (à chaud, avec KAPE, vers un disque externe) :
C:\$LogFile,C:\$MFT,C:\$Extend\$UsnJrnl:$J, Prefetch, ruches du registre, journaux d'événements. Méthode décrite dans Acquérir le $LogFile NTFS.
Premier regard sur le journal
La ligne d'en-tête du parseur :
- LFS 2.0, non démonté proprement → capture à chaud sous Windows 8 ou ultérieur (1.1 et 2.0).
- 1 page tirée de la zone des pages rapides → les enregistrements les plus récents n'existaient que là.
- 100 enregistrements, LSN 115720 → 117880, aucun avertissement.
Un vrai journal de volume système ferait environ 64 Mio pour des centaines de milliers d'enregistrements ; le journal synthétique fait 256 Kio pour que l'histoire reste lisible.
La chronologie reconstruite à partir du journal
Heures en UTC, tirées des données des enregistrements (colonne Heure tirée de). « ≈ » signifie empruntée à l'événement daté le plus proche.
| Heure (UTC) | Événement | Chemin | Heure tirée de |
|---|---|---|---|
| 09:58:12 | Création (dossier) | \Users\svc_backup | création $FN |
| 09:58:12 | Création (dossiers) | …\svc_backup\Desktop, …\Downloads | création $FN |
| 10:04:55 | Création | …\Downloads\tools.zip | création $FN |
| 10:06:52 | Création | …\Downloads\tools\m64.exe, readme.txt | création $FN |
| 10:06:52 ≈ | Données résidentes écrites | …\tools\readme.txt (« m64 - memory utility v2.2 … ») | empruntée |
| 10:07:03 | Création | \Windows\Prefetch\7ZFM.EXE-8A1F2C3D.pf | création $FN |
| 10:09:31 | Création (dossier) | \ProgramData\Intel | création $FN |
| 10:09:40 | Renommage / déplacement | …\tools\m64.exe → \ProgramData\Intel\m64.exe | modification $FN |
| 10:09:40 ≈ | Modification $SI, 4 indices de timestomping | \ProgramData\Intel\m64.exe | empruntée |
| 10:12:18 | Création | \Windows\Prefetch\M64.EXE-1C9E54B7.pf | création $FN |
| 10:31:44 | Création | \Users\Public\rc.tmp | création $FN |
| 10:31:58 | Renommage | rc.tmp → \Users\Public\rclone.exe | modification $FN |
| 10:38:10 | Création + données | …\svc_backup\Desktop\creds.txt | création $FN |
| 10:38:27 | Modification $SI | creds.txt | nouveau $SI |
| 10:47:12 | Création | …\AppData\Roaming\Microsoft\Windows\Recent\Payroll_2026.xlsx.lnk | création $FN |
| ≥ 10:38:27 | Suppression | …\Desktop\creds.txt | dernière date connue |
| 10:55:20 | Modification $SI | …\svc_backup\Desktop | nouveau $SI |
Le bruit de fond a été laissé de côté : mises à jour d'horodatage de la base SRUM à 10:15 et 10:45, un fichier temporaire créé puis supprimé dans \Windows\Temp à 10:20.
Lecture phase par phase
Première ouverture de session (09:58). Les dossiers de profil de svc_backup apparaissent. Le dossier Recent sous AppData ne figure pas dans ce qui reste du journal — ses enregistrements ont été écrasés — mais le $MFT le nomme, d'où le chemin complet du .lnk plus tard. Sans le $MFT, plusieurs chemins commenceraient par [MFT #n].
La boîte à outils (10:04–10:07). tools.zip arrive dans Downloads ; un dossier tools contenant m64.exe et readme.txt suit. Le texte du readme est résident, donc ses premiers octets sont visibles dans le journal : il présente m64.exe comme un « memory utility » à lancer en administrateur — une piste vers un outil de dump mémoire. Un fichier Prefetch pour 7ZFM.EXE est créé à 10:07:03, ce qui concorde avec l'utilisation du gestionnaire de fichiers de 7-Zip autour de l'extraction.
Cacher le binaire (10:09). Un nouveau dossier \ProgramData\Intel est créé, m64.exe y est déplacé, puis ses horodatages $STANDARD_INFORMATION sont réécrits : avant, création 10:06:52.3551871 ; après, les quatre dates à 2019-03-19 07:14:22.0000000. Le parseur liste quatre raisons — création réécrite, valeurs qui reculent, secondes pile, création $SI antérieure à la création $FN. La méthode et ses faux positifs sont dans Détecter le timestomping. Ici, il n'y a ni extraction ni restauration à ce moment-là, la cible est un exécutable dans un dossier au nom d'éditeur, et la modification suit un déplacement délibéré : un constat solide, à corroborer par le BASIC_INFO_CHANGE du journal USN pour l'heure réelle.
Indice d'exécution (10:12). M64.EXE-1C9E54B7.pf est créé. La création d'un fichier Prefetch est un indice fort que m64.exe a été exécuté ; confirmez en analysant le fichier Prefetch lui-même (parseur Prefetch) pour le nombre et les heures d'exécution.
Préparer l'exfiltration (10:31). rc.tmp est déposé dans \Users\Public et renommé rclone.exe quatorze secondes plus tard. Le renommage figure dans le journal avec les deux noms. Savoir si rclone a tourné et où il a envoyé des données relève du Prefetch, de l'Amcache (parseur Amcache), de l'usage réseau SRUM (parseur SRUM) et des journaux du proxy.
La note d'identifiants (10:38). creds.txt est créé sur le Bureau, son contenu est écrit (résident, visible dans le journal : un chemin de partage et le nom du compte, marqués SYNTHETIC), modifié à 10:38:27, puis supprimé. La suppression n'a pas d'heure propre : « à 10:38:27 ou après ». Voir Retrouver les traces de fichiers supprimés.
La paie (10:47). Un raccourci Payroll_2026.xlsx.lnk apparaît dans Recent, c'est-à-dire que l'utilisateur a ouvert un fichier de ce nom. Le chemin cible et le numéro de série du volume sont dans le .lnk lui-même (parseur LNK) ; dans cette histoire, il pointe vers la clé USB E:.
Ce qui va dans le rapport
Écrivez des observations, pas des signalements :
Dans le journal de transactions NTFS du volume C: (enregistrements LSN 116846 et 116951), le fichier
\ProgramData\Intel\m64.exe(entrée MFT 322) a été déplacé depuis\Users\svc_backup\Downloads\tools\et ses horodatages$STANDARD_INFORMATIONont été modifiés de 2026-09-14 10:06:52 UTC (création) à 2019-03-19 07:14:22 UTC pour les quatre valeurs. Le journal n'enregistre pas l'heure de la modification ; elle est intervenue après 10:09:40 UTC (déplacement) et avant l'événement daté suivant.
Citez les LSN, conservez les exports bruts (CSV/JSON des événements filtrés et de leurs enregistrements), et indiquez l'outil et ses limites : le parseur utilisé ici est validé sur des données synthétiques, donc les mêmes enregistrements doivent être confirmés avec un second outil (comparatif des parseurs).
Ce que le journal ne pouvait pas dire
rclone.exea-t-il tourné ? Des données sont-elles sorties ? Ce n'est pas une question de métadonnées du système de fichiers.- Quand exactement
m64.exea-t-il été antidaté,creds.txtsupprimé ? Journal USN. - Que s'est-il passé avant 09:58 ? Hors de la fenêtre du journal ; le journal USN et les clichés instantanés remontent plus loin (les limites du $LogFile).
- Qui était au clavier ? Événements d'ouverture de session, artefacts RDP (parseur EVTX).
La contribution du $LogFile est étroite et solide : un récit précis et ordonné des changements de métadonnées de la dernière heure, y compris des valeurs que les autres artefacts écrasent.