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 22:47 la veille. Pas d EDR serieux, pas de SIEM agregeant 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 que l attaquant a utilise rundll32 pour charger une DLL depuis %AppData%\Roaming\winlog a 22:47:13, et hausser les epaules. Ce billet construit le lab qui replique exactement cette pression sur un Windows 11 isole dans VMware Workstation, et pilote Plaso, log2timeline et KAPE de la collecte a un recit defendable.

Pourquoi le timeline forensics decide du cas

Un seul artefact ment facilement. Une entree EVTX peut etre effacee, un timestamp peut subir un timestomping, un log peut tourner. Le timeline forensics gagne parce qu il fusionne des sources independantes sur une seule ligne de temps: metadonnees du filesystem depuis la MFT, traces d execution depuis Prefetch et Amcache, persistance Registry, evenements EVTX, usage reseau SRUM. La ou trois artefacts independants attestent le meme instant, la conjecture devient preuve. Cette mentalite est le revers defensif de ce qu on decrit comme chasse proactive dans 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. La timeline n est pas collecter tout, c est faire temoigner le temps contre la mauvaise hypothese.

Le stack: KAPE, Plaso, Timesketch

Le stack que j utilise est simple et repetable: KAPE d Eric Zimmerman pour la collecte de triage (les Targets comme !SANS_Triage prennent moins de trois minutes), Plaso 20240308 dans un conteneur Ubuntu 24.04 avec 16 GB de RAM dediee, plus Timeline Explorer pour la vue rapide et Timesketch pour la navigation collaborative. KAPE collecte sans casser la chaine de custody car il tire des copies forensiquement propres avec des hashes. Plaso normalise ensuite des dizaines de types d artefacts en une seule super-timeline interrogeable. Timeline Explorer vous donne grille, filtres et colorisation; Timesketch vous donne tags, stories et vues partagees pour l equipe. Chaque outil a sa place, et la combinaison est plus puissante que chacun seul.

Le montage du lab

Je construis le lab sur un Windows 11 isole dans VMware Workstation, avec snapshot propre, snapshot post-infection simulee et un detonateur controle, entierement host-only sans internet. Le flux standard 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 GB avec 18 GB utilises produit un storage plaso d environ 1,2 GB en une vingtaine de minutes. Le montage isole est obligatoire: un detonateur sans blocage reseau contacte un vrai C2 et vous rend partie du probleme.

Collecte avec KAPE: Targets et Modules

Le debutant sur KAPE trouve le modele Targets et Modules etrange, mais c est justement ce qui rend la collecte defendable en contexte legal. Les Targets copient les artefacts bruts, les Modules les parsent avec des outils externes. Je tiens un .tkape maison qui ajoute PowerShell\Operational, WMI-Activity et TaskScheduler au-dessus des targets de triage standard, plus un module qui lance RECmd avec les batch de Zimmerman pour extraire UserAssist, ShellBags, TypedPaths et le set RunMRU. Cela me laisse un repertoire Triage\ pret pour Plaso et un Modules\ avec des CSV deja parses. Pour un incident sur un endpoint segmente derriere un reseau de pivoting (scenario couvert dans Pivoting avec Chisel et Ligolo-ng : Reseaux Segmentes en Lab de Pentest), KAPE tourne en local et exporte vers un share authentifie, evitant du trafic lourd.

Construire la super-timeline avec log2timeline

Contre le montage read-only je lance log2timeline.py --storage-file case.plaso /mnt/evidence. Plaso auto-detecte les artefacts, mais en triage j active deliberement les parsers winreg, prefetch, mft, usnjrnl, winevtx, srum, amcache, shimcache et bam au lieu de tout lancer, ce qui multiplie le runtime. Pour VSS j ajoute --vss-stores all pour remonter la persistance effacee des shadow copies. Le storage grossit vite: une super-timeline brute renvoie facilement huit millions d evenements. Ce n est pas un bug, c est de la matiere premiere. La valeur n apparait qu a l etape suivante, le filtrage. La clef est de generer le storage une fois proprement puis de ne faire que decouper dedans avec psort.py au lieu de relancer log2timeline plusieurs fois.

Filtrer et decouper avec psort

L or n est pas dans le lancement de l outil, il est dans le filtrage. Je commence toujours par decouper une fenetre de plus/moins trente minutes autour de l indicateur connu avec psort.py -o l2tcsv --slice '2026-01-14T22:47:13' --slice_size 30 case.plaso. Cette coupe reduit de huit millions a environ quatorze mille lignes. Ensuite je filtre par sources MFT, EVTX et Registry et je charge Timeline Explorer avec colorisation par type. On peut resserrer encore avec un fichier de filtre psort qui n admet que les sources pertinentes et une plage de temps. Le reflexe de vouloir lire toute la super-timeline est l erreur de debutant la plus courante; le metier consiste a s ancrer sur un IOC temporel et a rayonner de la.

Croiser les artefacts: Prefetch, Amcache, MFT, UsnJrnl, EVTX

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

Trois pieges qui coutent des heures

Premier: timezone. Plaso normalise en UTC par defaut, mais EVTX stocke en UTC et certains artefacts Registry stockent l heure locale deguisee en UTC. Je tourne toujours avec --timezone UTC et je documente l offset de la machine explicitement dans le rapport. Deuxieme: VSS. Les Volume Shadow Copies cachent des versions anterieures de NTUSER.DAT et peuvent reveler une persistance effacee; 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 elagues sinon vous gaspillez du temps d analyse. Des techniques defensives liees vivent dans Persistance Windows : 10 Techniques Documentees et leurs Contre-mesures.

Timesketch et la remise

Pour livrer le constat, j exporte le slice pertinent vers Timesketch (docker compose up, ingerer le storage plaso directement), je cree un sketch avec des tags comme execution, persistence, c2_beacon, et je genere un rapport avec la fonction stories. Cela devient un input direct pour des regles Sigma alimentant la detection future, fermant la boucle decrite dans Purple Team en Pratique: Construire une Boucle de Feedback Red vs Blue. Chaque evenement tague devient une affirmation tracable, chaque story une these avec preuves. Ainsi un triage nocturne produit non seulement un rapport mais un artefact de detection qui fait apparaitre le prochain incident plus tot.

Checklist pratique

Un: snapshot avant detonation, tout en host-only. Deux: triage KAPE avec un .tkape etendu (PowerShell, WMI, TaskScheduler). Trois: montage read-only de la preuve sur l hote d analyse. Quatre: log2timeline avec seulement les parsers pertinents plus --vss-stores all. Cinq: decouper une fenetre de trente minutes autour de l IOC avec psort --slice. Six: filtrer par MFT, EVTX, Registry, Prefetch et Amcache et coloriser dans Timeline Explorer. Sept: croiser au moins trois artefacts independants avant d affirmer quoi que ce soit. Huit: documenter la timezone, inclure VSS, elaguer les parsers bruyants. Neuf: slice vers Timesketch, taguer, ecrire une story, deriver une regle Sigma. Suivez ces neuf etapes avec discipline et vous livrez une hypothese defendable en quarante minutes.

FAQ

Pourquoi ne pas simplement prendre l alerte EDR ? Parce que dans un vrai incident il n y a souvent pas d EDR actif, l alerte a des trous, ou l attaquant a efface les logs. Le timeline forensics reconstruit la sequence a partir d artefacts du filesystem et du Registry plus durs a effacer entierement, et les croise pour qu une seule manipulation ressorte.

KAPE suffit-il ou faut-il Plaso ? KAPE collecte et parse de facon selective, mais la correlation temporelle a travers des dizaines de types d artefacts est ce que Plaso livre avec la super-timeline. En pratique vous utilisez les deux: KAPE pour la collecte rapide et propre, Plaso pour la ligne de temps unifiee, Timesketch pour la remise et la detection.

Conclusion

Le timeline forensics n est pas de l accumulation, c est de la discipline: ancrez-vous sur un IOC temporel, decoupez une fenetre etroite, croisez au moins trois artefacts independants, et seulement alors ecrivez le recit. Le stack KAPE, Plaso et Timesketch rend cela reproductible et defendable legalement. Takeaway pratique: n essayez pas de lire huit millions d evenements. Ancrez-vous sur l IOC, decoupez trente minutes, croisez Prefetch, Amcache, MFT et EVTX, et faites temoigner le temps contre la mauvaise hypothese. C est exactement ce qui separe un recit defendable d un haussement d epaules a trois heures du matin.