Construire une chronologie d'exécution de programmes à partir d'un hive SYSTEM

TL;DR. Construis une chronologie fusionnée de ShimCache + AmCache + Prefetch + BAM/DAM + Security/Sysmon. Utilise le ShimCache pour définir le casting (chemins), puis enrichis chaque ligne avec des horodatages issus de sources qui enregistrent réellement des événements. Marque chaque horodatage avec sa sémantique de source. Ne fusionne jamais "mtime de fichier" et "démarrage de processus" dans une seule colonne.

Une chronologie d'exécution de programmes est l'artefact le plus utile que produit un enquêteur IR Windows. Bien faite, elle raconte une histoire chronologique à travers plusieurs sources. Mal faite, elle surinterprète les preuves et se fait démolir par quiconque sait ce qu'est une mtime. Voici le workflow que je fais tourner, avec le ShimCache en colonne vertébrale.

Pourquoi le ShimCache est une bonne colonne vertébrale

Le cache est rarement la source la plus précise pour un champ donné, mais il a des avantages uniques comme ancre chronologique :

• Il porte le chemin du fichier explicitement. Certains artefacts n'ont que des hashs ou des chemins partiels.
• Il capture les exécutables que Windows a juste examinés, donc il inclut des binaires qui ont tourné brièvement et ont été supprimés (que Prefetch et BAM peuvent rater).
• Il survit à de nombreuses tentatives anti-forensiques qui effacent d'autres artefacts, avec des réserves importantes.

Utilise le ShimCache pour définir le casting de la chronologie. Puis enrichis chaque ligne avec des artefacts corroborants pour assigner des temps fiables.

Les sources de données à fusionner

Une chronologie d'exécution complète puise dans au moins ces cinq :

Pour le contexte, voir la référence des artefacts d'exécution de programmes. Sur les gros dossiers, intègre SRUM pour l'usage réseau et ressources, le journal USN pour l'activité fichier, et les fichiers LNK plus jump lists pour l'historique shell.

Un workflow reproductible

1. Collecte les artefacts. Hive SYSTEM avec les journaux de transactions, Amcache.hve avec ses .LOG1 et .LOG2, C:\Windows\Prefetch\*.pf, journal Security exporté, log Sysmon si disponible, NTUSER.DAT par utilisateur. Le guide d'acquisition couvre spécifiquement le hive SYSTEM.
2. Parse chacun en une table normalisée. Utilise la suite Eric Zimmerman (AppCompatCacheParser, AmcacheParser, PECmd) pour du travail hors ligne, ou le Shimcache Parser pour la partie ShimCache dans ton navigateur.
3. Fusionne sur (chemin, SHA-1 optionnel). La clé de join est le chemin du fichier, avec le SHA-1 d'AmCache comme signal secondaire. Surveille les différences de casse et la normalisation des chemins (\??\C:\ vs C:\).
4. Marque chaque horodatage avec sa sémantique de source. Ne mélange pas "AmCache install_date" et "Prefetch run_time" dans une seule colonne. Ils répondent à des questions différentes. Garde-les adjacents mais distincts.
5. Rends dans un outil qui gère l'attribution de source par ligne. Le Timeline Explorer (TLE) d'Eric Zimmerman et Plaso / log2timeline le font tous deux bien. Un CSV dans un tableur fonctionne pour des cas plus petits.

Ce à quoi ça ressemble quand c'est bien

Une ligne défendable dans une chronologie finale :

2026-04-12 09:14:33 UTC  C:\Users\alice\AppData\Local\Temp\setup.exe
  ShimCache mtime: 2026-04-12 09:14:30 UTC
  AmCache       : SHA-1 a3b8c9..., signer "Acme Updates", install 2026-04-12 09:14:33
  Prefetch      : dernier run 2026-04-12 09:15:01 UTC (1 exécution)
  Security 4688 : 2026-04-12 09:15:01 UTC, PID 4521, parent PID 1234 (svchost.exe)

Chaque horodatage est sourcé et la ligne tient la route. L'inverse ("le ShimCache montre que setup.exe a tourné à 09:14:33") confond mtime de fichier et temps d'exécution, et c'est le genre de revendication qui fait rejeter les rapports. Voir preuve d'exécution.

Quand les sources divergent

Les conflits sont des données.

• mtime ShimCache ≠ premier-run Prefetch. Normal. Ils mesurent des choses différentes. Note les deux. Ne choisis pas.
• AmCache dit exécuté, ShimCache est vide pour ce fichier. Raisons possibles : essuyage anti-forensique (motifs de détection), l'entrée a été évincée du plafond de 1 024, le binaire a tourné après le dernier arrêt propre (encore uniquement en mémoire, prends un dump RAM).
• Prefetch absent. Les SKUs serveur et les hôtes SSD-tunés ont souvent Prefetch désactivé. Replie sur AmCache plus BAM.
• EVTX Security 4688 a le nom du programme mais pas la ligne de commande. L'audit de ligne de commande était désactivé. Utile mais limité. Le parser EVTX couvre les prérequis de politique d'audit.

S'arrêter au bon endroit

Une chronologie n'a pas besoin d'être complète pour avoir de la valeur. Une fenêtre focalisée ("qu'a tourné sur l'hôte X entre 14:00 et 18:00 le 2026-04-11 ?") construite rigoureusement bat une fresque tentaculaire à l'attribution faible. Le workflow de chasse au malware t'aide à choisir cette fenêtre.

Lectures complémentaires

• Plaso / log2timeline. moteur de chronologie open source qui consomme ShimCache, AmCache, Prefetch et des dizaines d'autres artefacts Windows.
• Outils Eric Zimmerman. parsers de référence plus Timeline Explorer.
• Velociraptor Windows.Registry.AppCompatCache. collecte à grande échelle.

Articles liés

• ShimCache vs AmCache : quel artefact Windows répond à quelle question
• Prefetch, AmCache, ShimCache : référence rapide
• Chasser du malware avec le ShimCache