TL;DR. L'horodatage du ShimCache est la date de dernière modification $STANDARD_INFORMATION de l'exécutable, copiée depuis le système de fichiers — pas l'heure d'exécution, pas l'heure de mise en cache. C'est une propriété du fichier, jamais un événement sur une chronologie.
L'erreur la plus fréquente en analyse ShimCache est de lire la colonne d'horodatage comme « l'heure à laquelle ça a tourné ». Ce n'est pas le cas. Cette confusion a déjà mis de fausses heures dans de vrais rapports d'incident. Ce billet explique précisément ce qu'est cette valeur et comment l'utiliser sans tirer de conclusion erronée.
Ce qu'est réellement l'horodatage
Chaque entrée ShimCache stocke la date de dernière modification (mtime $STANDARD_INFORMATION) de l'exécutable, telle qu'elle était sur le volume NTFS au moment où Windows a enregistré l'entrée. C'est une copie directe d'un attribut du système de fichiers. Elle ne dit rien sur la création du processus, le chargement du module ou l'arrêt.
Trois conséquences immédiates :
- Un binaire compilé l'an dernier et exécuté aujourd'hui affiche la date de l'an dernier.
- Un fichier copié avec un outil qui préserve les horodatages conserve son mtime d'origine, pas l'heure de copie.
- Deux hôtes exécutant le même binaire signé afficheront le même horodatage — car c'est une propriété du fichier, pas de la machine.
Pourquoi ce n'est pas l'heure d'exécution
Windows ajoute une entrée ShimCache quand il examine un fichier pour des raisons de compatibilité applicative — ce qui coïncide souvent, mais pas toujours, avec l'exécution. Même quand cela coïncide, le cache stocke le mtime du fichier, pas l'instant de l'examen. L'horodatage répond donc à « quand ce fichier a-t-il été modifié pour la dernière fois ? » et jamais à « quand a-t-il tourné ? ». La distinction exécution/existence est traitée en détail dans Le ShimCache prouve-t-il qu'un programme a été exécuté ?.
Quand l'horodatage reste utile
Faible comme heure d'événement, il est solide comme ancre d'identité :
- Détection d'altération. Si un binaire système comme
svchost.exeaffiche un mtime incohérent avec le niveau de correctifs de l'hôte, ce fichier a été remplacé. - Corrélation de build. Un malware compilé lors d'une campagne partage souvent un cluster de mtime entre victimes — utile pour regrouper.
- Ordonnancement, avec prudence. Sur un même hôte, les entrées sont stockées dans un ordre d'insertion approximatif. L'ordre est plus fiable que les horodatages absolus pour séquencer l'activité.
Comment les attaquants en abusent
Comme ce n'est qu'un attribut du système de fichiers, il est trivialement falsifiable. Le timestomping (par exemple fixer un mtime au 2009-07-14, la date classique de kernel32.dll) fait fondre un dropper parmi les fichiers système. Le ShimCache enregistre fidèlement la valeur trafiquée — donc un horodatage « propre » de 2009 sur un chemin dans C:\Users\Public\ est en soi un signal d'alerte. Les schémas anti-forensiques sont catalogués dans Les attaquants peuvent-ils effacer le ShimCache ?.
L'utiliser correctement dans une chronologie
Placez le mtime ShimCache dans une colonne distincte des heures d'événement — ne le fusionnez jamais dans la chronologie principale comme s'il s'agissait d'une action. Corroborez le séquencement avec des artefacts qui portent vraiment des heures d'événement : heures d'exécution Prefetch, install/premier lancement AmCache, Security 4688, Sysmon 1. La référence croisée complète est dans Prefetch, AmCache, ShimCache : référence rapide.
Pour inspecter vous-même les valeurs brutes, déposez une ruche SYSTEM dans le Shimcache Parser — il affiche le mtime stocké exact par entrée, dans votre navigateur, sans rien téléverser.
Pour aller plus loin
- Mandiant : leveraging the ShimCache — l'étude d'origine qui a défini l'usage forensique de l'artefact.
- AppCompatCacheParser d'Eric Zimmerman — parseur de référence dont la sortie utilise la même sémantique de mtime.