TL;DR. Oui. Une entrée du ShimCache persiste dans le registre, que le fichier existe encore sur disque ou non. Supprimer le binaire ne supprime pas son entrée ShimCache. C'est précisément pour ça que l'artefact est si utile pour attraper des outils qu'un attaquant a déposés, utilisés et effacés.
Le cache stocke un chemin et un horodatage dans une valeur de registre. Cette valeur n'a aucun lien retour vers le système de fichiers. Quand NTFS libère l'exécutable, les données registre ne bougent pas. Ce qui est la raison entière pour laquelle l'artefact vaut le coup d'être récupéré, et la raison entière pour laquelle c'est parfois la seule preuve survivante d'une intrusion.
Réponse courte : oui
Le ShimCache stocke un chemin plus la mtime $STANDARD_INFORMATION du fichier dans la valeur à HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache\AppCompatCache. Cet enregistrement n'a aucun lien retour vers le système de fichiers. Quand l'exécutable est supprimé, NTFS libère le fichier. La valeur de registre est intouchée. L'entrée reste jusqu'à ce qu'elle soit soit évincée par des entrées plus récentes (le cache contient jusqu'à ~1 024) soit que la valeur elle-même soit effacée.
Donc un binaire qu'un attaquant a déposé dans C:\Users\Public\, exécuté et supprimé dix minutes plus tard peut quand même laisser une entrée ShimCache propre et lisible montrant le chemin complet qu'il a occupé.
Pourquoi c'est puissant forensiquement
Les entrées de fichiers supprimés sont souvent la seule preuve survivante de l'outillage de l'attaquant :
- Un
mimikatz.exerenommé supprimé après le vol d'identifiants. - Une archive de staging supprimée après exfiltration.
- Un dropper qui s'est auto-supprimé après avoir installé une charge utile.
- Une copie de
7z.exeutilisée pour empaqueter les données avant transfert.
Le fichier est parti. Le chemin du cache te dit qu'il a existé, où, et (via l'horodatage de dernière modification) le rattache à un build. C'est la colonne vertébrale de chasser du malware avec le ShimCache et des enquêtes ransomware, où les attaquants effacent leurs outils en routine.
Croise avec la MFT et le journal USN. Si le journal porte encore la séquence create-then-delete, tu as une ancre chronologique propre. La corbeille n'en contient presque jamais (ils la contournent) mais vérifie quand même.
Combien de temps une entrée de fichier supprimé survit-elle ?
Deux limites s'appliquent :
- Éviction. Le cache est borné à environ 1 024 entrées. Sur un hôte chargé, une forte activité d'exécutables peut pousser les vieilles entrées dehors. Sur un serveur calme, elle peut survivre des mois.
- Timing de flush. Les nouvelles entrées ne persistent dans le hive qu'à l'arrêt propre. Si l'hôte n'a pas été arrêté depuis la suppression, l'entrée survivante peut n'être qu'en mémoire. Récupère-la depuis un dump RAM, voir le guide d'extraction mémoire. Le modèle de stockage et de flush est couvert dans où le ShimCache est stocké.
Ce que ça ne prouve pas
Une entrée de fichier supprimé prouve que le fichier a existé et a été examiné sur cet hôte. Elle ne prouve pas que le fichier a été exécuté, et elle ne te dit pas quand il a été supprimé. L'horodatage est la mtime du fichier, pas un temps de suppression. Traite-le comme un témoin d'existence fort et corrobore l'exécution avec Prefetch ou AmCache. Voir le ShimCache prouve-t-il l'exécution ?.
Pour vérifier quelles entrées sur un hive pointent vers des fichiers qui n'existent plus, parse-le avec le Shimcache Parser et croise les chemins avec le système de fichiers vivant (ou une image forensique). Tout tourne localement dans ton navigateur.
Lectures complémentaires
- Caching Out the Val de Mandiant. le plaidoyer pour le ShimCache comme témoin d'outils supprimés.
- Poster SANS DFIR sur l'exécution de programmes. où le ShimCache s'inscrit parmi les preuves d'exécution.