fr

Chasser du malware avec le ShimCache : un workflow pas à pas

4 min de lecture

TL;DR. Parse le hive SYSTEM. Filtre les chemins dans des emplacements accessibles en écriture par l'utilisateur (\AppData\, \Temp\) et des chemins système inattendus. Corrobore les hits avec les hashs AmCache et Prefetch. Pivote sur le SHA-1 quand le fichier est parti. Le ShimCache met des noms sur ta liste de chasse. Il ne boucle pas un dossier à lui seul.

La raison pour laquelle le ShimCache gagne sa place dans un workflow de chasse, c'est qu'il survit. Un attaquant dépose un outil, l'exécute, le supprime, et le chemin reste dans le cache. Ça en fait un pivot à fort signal quand AmCache et Prefetch ont été essuyés ou n'étaient pas activés. Voilà comment je l'utilise vraiment.

Workflow de chasse au malware avec ShimCache en cinq étapes

Le workflow en cinq étapes

  1. Collecte le hive SYSTEM. Récupère C:\Windows\System32\config\SYSTEM et ses voisins .LOG1 et .LOG2, ou utilise Velociraptor pour la collecte live. Le guide d'acquisition couvre les méthodes sûres. Rappelle-toi que le cache vit en mémoire jusqu'à l'arrêt propre, donc vérifie le timing de stockage avant de supposer que le hive sur disque est à jour.
  2. Parse vers une liste plate. Décode le blob binaire en lignes (path, mtime, format). Le Shimcache Parser le fait dans ton navigateur ; AppCompatCacheParser d'Eric Zimmerman ou le Shim Cache Parser de Mandiant le font hors ligne.
  3. Filtre les chemins suspects. C'est là que la chasse se passe vraiment.
  4. Corrobore l'exécution. Une ligne ShimCache seule prouve l'existence, pas l'exécution. Apparie chaque ligne intéressante avec Prefetch, AmCache, ou EVTX / Sysmon. La matrice complète est dans la référence des artefacts d'exécution de programmes.
  5. Pivote sur le hash. Quand le fichier sur disque est parti, le SHA-1 d'AmCache est ta prise pour les lookups VirusTotal et threat intel. Le découpage ShimCache vs AmCache couvre pourquoi tu récupères toujours les deux.

Motifs qui valent le coup d'être filtrés

Voici les motifs de chemin qui scorent systématiquement le plus haut en chasse réelle :

  • Répertoires accessibles en écriture par l'utilisateur. \AppData\Local\Temp\, \AppData\Roaming\, \Users\Public\, \ProgramData\. Utilisateurs et services peuvent déposer des binaires ici sans droits admin, et ils le font.
  • Accessibles en écriture par le système mais ne devraient pas l'être. C:\Windows\Temp\, C:\PerfLogs\, tout ce qui est sous C:\Windows\ et qui n'est pas un chemin Windows connu. Les binaires de service PsExec et le tooling named-pipe atterrissent ici tout le temps.
  • Double extension et lookalikes. svchost.exe hors de \System32\, lsass.exe à un endroit inhabituel, *.pdf.exe, *.docx.exe. L'OriginalFileName d'AmCache brise généralement le déguisement.
  • Partages réseau et supports amovibles. \\?\UNC\, lettres de lecteur autres que C:, \Device\HarddiskVolumeShadowCopy*. Ils montrent le chemin de staging. Croise avec les fichiers LNK pour l'historique shell.
  • Tooling à usage unique. psexec.exe, winrm.cmd, wmiexec.exe, mimikatz*.exe, artefacts Cobalt Strike. Les outils admin légitimes sont détournés ; traite-les comme des findings à clarifier, pas comme du bruit à ignorer.

Ne fais pas le malin avec des regex au premier passage. Trie par mtime et parcours les entrées récentes à l'œil. Ça attrape ce que les filtres heuristiques ratent, y compris les binaires que l'attaquant a renommés pour échapper à ta liste de filtres.

Règles de triage à la louche

Quelques vérifs rapides séparent le signal du bruit :

  • A-t-il un voisin Prefetch ? Quasi-preuve d'exécution.
  • AmCache porte-t-il un SHA-1 ? Cherche-le. Hash signé éditeur propre, c'est dépriorisé. Hash inconnu sur un chemin accessible en écriture par l'utilisateur, c'est à escalader.
  • La mtime est-elle suspectement proche d'un horaire d'incident connu ? Modifiée à quelques minutes d'une alerte, ça mérite un regard plus profond. Souviens-toi que la mtime est une propriété du fichier, pas le moment où Windows l'a vu.
  • Le répertoire parent est le profil utilisateur mais l'utilisateur n'est pas admin ? Raisonnable pour des installateurs ; surveille les indicateurs d'élévation dans Sysmon Event ID 1 et Security 4688 avec tokens élevés.
  • Le journal USN ou la MFT confirme-t-il la création dans la fenêtre d'intérêt ? Forte corroboration quand le fichier est encore sur disque.

Ce que ce workflow ne te dira pas

Le ShimCache seul ne te dira pas qui a lancé le binaire, avec quels arguments, ni quand. Pour ça, tu as besoin de Sysmon, des journaux Security, ou d'une chronologie d'exécution de programmes complète. Le boulot du cache est de mettre des noms sur la liste de chasse, pas de fermer l'enquête.

Lectures complémentaires

Articles liés