Timeline Forensics sur Windows : Plaso, Log2Timeline et KAPE en Pratique

Trois heures du matin, un appel d'incident, et tout ce que vous avez est une VDI Windows 11 avec suspicion d'execution de payload a 22h47 la veille. Pas de vrai EDR, pas de SIEM qui agrege les logs, juste la machine vivante et quarante minutes pour livrer une hypothese. C'est le scenario ou le timeline forensics cesse d'etre un exercice academique et devient la difference entre dire 'l'attaquant a utilise rundll32 chargeant une DLL depuis %AppData%\Roaming\winlog a 22:47:13' et hausser les epaules. Le laboratoire que je monte ici reproduit cette pression sur un Windows 11 isole dans VMware Workstation, avec snapshot propre, snapshot post-infection simulee, et un detonateur controle.

La pile que j'utilise est simple et repetable : KAPE d'Eric Zimmerman pour la collecte triee (les Targets type !SANS_Triage prennent moins de trois minutes), Plaso 20240308 tournant dans un conteneur Ubuntu 24.04 avec 16 Go de RAM dedies, plus Timeline Explorer et Timesketch pour naviguer. Le flux par defaut est : snapshot, detoner l'echantillon (j'utilise des variantes inertes generees dans le lab decrit dans Analyse de Malware en Lab Isole: Setup Securise avec FlareVM et REMnux), collecter avec KAPE vers un VHDX, monter en read-only sur l'hote d'analyse, et lancer log2timeline.py contre le point de montage. Sur du materiel modeste, un disque de 80 Go avec 18 Go occupes produit un plaso storage de ~1,2 Go en environ 22 minutes.

L'or n'est pas dans l'execution de l'outil, il est dans le savoir-filtrer. Une super-timeline brute de Plaso renvoie facilement 8 millions d'evenements quand vous activez les parsers winreg, prefetch, mft, usnjrnl, evtx, srum, amcache, shimcache et bam. Je commence toujours par decouper une fenetre de +-30 minutes autour de l'indicateur connu avec psort.py -o l2tcsv --slice '2026-01-14T22:47:13' --slice_size 30. Cette coupe reduit a environ 14 000 lignes, ensuite je filtre par sources MFT, EVTX et Registry et je charge dans Timeline Explorer avec colorisation par type. Les techniques de hunting que je combine viennent directement de Hunting des Living-off-the-Land Binaries sous Windows avec KQL et Threat Hunting avec Sigma et Elastic: De l'Indicateur a la Regle de Detection.

Un exemple concret du dernier lab : le detonateur etait un LNK pointant vers powershell.exe -enc, motif proche de celui etudie dans Initial Access Simule: Macros, LNK et ISO dans un Lab Windows 11 Isole. La premiere piste n'est pas venue de l'EVTX, elle est venue du Prefetch (POWERSHELL.EXE-7644F8E2.pf cree a 22:47:09, quatre secondes avant l'execution journalisee dans Security 4688), et de l'Amcache.hve montrant le hash SHA1 de la DLL satellite arrivee via BITS. UsnJrnl a confirme la creation du fichier sur C:\Users\elias\AppData\Roaming\winlog\runner.dll a 22:46:58, avec timestamp MFT $SI coincidant avec $FN, donc pas de timestomping dans ce cas. Ce croisement de trois artefacts independants est ce qui valide l'hypothese ; un seul ment facilement.

Qui debarque sur KAPE trouve le modele Targets et Modules etrange, mais c'est ce qui rend la collecte defendable en contexte legal. Je garde un .tkape personnalise qui ajoute PowerShell\Operational, WMI-Activity et TaskScheduler au-dessus des targets standard de triage, et un module qui execute deja RECmd avec les batch files de Zimmerman pour extraire UserAssist, ShellBags, TypedPaths et l'ensemble RunMRU. Cela me laisse un repertoire Triage\ pret pour Plaso et un Modules\ avec des CSVs deja parses. Pour un incident sur endpoint segmente derriere un reseau de pivoting (scenario que je couvre dans Pivoting avec Chisel et Ligolo-ng : Reseaux Segmentes en Lab de Pentest), KAPE tourne en local et exporte vers un partage authentifie, evitant le trafic lourd.

Trois pieges qui coutent des heures si vous ne les connaissez pas. Premier : timezone. Plaso normalise par defaut en UTC, mais l'EVTX stocke en UTC et les artefacts Registry stockent parfois en heure locale deguisee en UTC. Je tourne toujours avec --timezone UTC et je documente l'offset de la machine. Deuxieme : VSS. Les Volume Shadow Copies cachent des versions anterieures de NTUSER.DAT et peuvent reveler une persistance qui a ete nettoyee ; KAPE collecte avec --vss et Plaso traite avec --vss-stores all. Troisieme : les parsers EVTX bruyants (Microsoft-Windows-Kernel-General genere des millions de lignes) doivent etre coupes via --parsers '!winevtx_kernel_general' ou vous gaspillez l'analyse. Techniques defensives liees dans Persistance Windows : 10 Techniques Documentees et leurs Contre-mesures.

Pour livrer le constat, j'exporte la tranche pertinente vers Timesketch (docker compose up, ingestion du plaso storage direct), je cree un sketch avec des tags comme execution, persistence, c2_beacon, et je genere un rapport avec la fonctionnalite stories. Cela devient directement l'entree de regles Sigma alimentant la detection future, bouclant le cycle decrit dans Purple Team en Pratique: Construire une Boucle de Feedback Red vs Blue. Takeaway pratique : n'essayez pas de lire 8 millions d'evenements. Ancrez-vous sur un IOC temporel, decoupez une fenetre de 30 minutes, croisez au moins trois artefacts independants, et seulement ensuite ecrivez la narration. Le timeline forensics ne consiste pas a tout collecter, mais a faire temoigner le temps contre la mauvaise hypothese.