Analyse mémoire Windows avec Volatility 3 : guide pratique

Les artefacts disque disent ce qui a été écrit ; la mémoire dit ce qui tournait. Ce guide couvre l'acquisition de la RAM sous Windows, l'exploitation de la mémoire que Windows laisse déjà sur le disque, et le déroulé d'une analyse Volatility 3, de windows.info jusqu'aux fichiers extraits. Vous verrez aussi où l'analyse mémoire peut induire en erreur, et comment intégrer ses résultats au reste de l'enquête.

Pourquoi la mémoire compte

Une part croissante des intrusions laisse peu de traces sur le disque. L'analyse mémoire répond à des questions que le disque ne peut pas trancher :

• Code injecté et fileless : shellcode, DLL chargées de manière réflective et payloads PowerShell vivent dans la mémoire des processus sans jamais toucher le système de fichiers.
• État réseau : sockets et connexions avec leur processus propriétaire, y compris des connexions déjà fermées dont les structures subsistent.
• Lignes de commande et environnement réels : ce avec quoi un processus a vraiment été lancé, avant toute rotation de journal.
• Contenu déchiffré et dépaqueté : un malware packé se décompresse en mémoire ; clés de chiffrement et chaînes déchiffrées sont souvent récupérables.
• État du noyau : pilotes chargés, callbacks et hooks posés par des rootkits.

Selon l'ordre de volatilité, capturez la mémoire en premier sur tout système allumé que vous comptez examiner.

Acquisition

Outils de capture à chaud

Tous les outils de capture à chaud chargent un pilote pour lire la mémoire physique. Lancez-les depuis un support externe, écrivez l'image sur un stockage externe, et notez l'outil, sa version, le hash et l'heure.

• WinPmem (open source, Velocidex) : produit une image brute. Aussi disponible dans Velociraptor pour la capture à distance.
• Magnet RAM Capture : outil graphique gratuit, image brute.
• DumpIt (Magnet/Comae) : capture en un clic ; les versions récentes écrivent au format crash dump Microsoft, que Volatility lit directement.

# WinPmem : écrire une image brute sur le disque externe E:
.\winpmem_mini_x64.exe E:\HOST01_mem.raw

# Hasher l'image immédiatement
Get-FileHash E:\HOST01_mem.raw -Algorithm SHA256

Le nom de l'exécutable change selon les versions ; vérifiez celui que vous téléchargez. Une capture prend plusieurs minutes et la mémoire continue d'évoluer pendant ce temps, ce qui compte plus tard (voir le smear ci-dessous).

Pour les machines distantes, l'artefact Velociraptor Windows.Memory.Acquisition encapsule WinPmem et remonte l'image au serveur, ce qui évite de confier une clé USB à quelqu'un sur site. Prévoyez le transfert : une image de 32 Go sur un VPN lent peut prendre des heures, alors décidez tôt entre une image complète et une collecte ciblée à chaud (liste des processus, connexions réseau, dumps des processus suspects).

Machines virtuelles

Pour une VM, suspendez l'invité ou prenez un snapshot plutôt que de lancer un outil à l'intérieur. Sous VMware, le fichier .vmem contient la mémoire de l'invité et le .vmss (suspension) ou .vmsn (snapshot) correspondant contient les métadonnées ; gardez-les ensemble, Volatility 3 s'appuie sur le fichier de métadonnées pour reconstruire l'agencement. Les états enregistrés Hyper-V (.vmrs / .bin) doivent en général être convertis en crash dump avant analyse. Chez les fournisseurs cloud, les options varient : préparez-le avant l'incident.

Crash dumps

Un MEMORY.DMP complet ou noyau (voir crash dumps) peut être chargé dans Volatility. Les dumps noyau n'ont pas les pages en mode utilisateur, et les minidumps sont trop petits pour une analyse générale, mais les deux peuvent servir.

La mémoire que Windows a déjà écrite sur le disque

Sans capture à chaud, tournez-vous vers le disque. Ces fichiers sont souvent la seule mémoire datant d'avant le confinement de l'incident.

Convertissez hiberfil.sys avant l'analyse. Hibr2Bin gère les formats anciens ; les versions récentes de Volatility 3 incluent une couche hibernation et les plugins windows.hibernation.Info / windows.hibernation.Dump pour les fichiers modernes de Windows 10/11. Le support dépend du build Windows et de la compression utilisée : validez le résultat (windows.info passe-t-il, les listes de processus sont-elles cohérentes) avant de vous y fier. Collectez tous ces fichiers en accès NTFS brut, car ils sont verrouillés sur un système en marche.

Le déroulé Volatility 3

Volatility 3 est un framework Python ; installez-le avec pip install volatility3 ou depuis le dépôt GitHub. Le point d'entrée est vol (ou vol.py depuis les sources). Les plugins portent le préfixe windows., et l'option --profile a disparu.

Tables de symboles

Volatility 3 identifie le build du noyau et a besoin d'une table de symboles correspondante, au format JSON ISF. Avec un accès Internet, il télécharge le PDB du noyau sur le serveur de symboles Microsoft et le convertit automatiquement, puis met le résultat en cache. En analyse hors ligne, il faut le pack de symboles Windows de la Volatility Foundation, ou des fichiers ISF générés sur une machine connectée, placés dans le répertoire symbols. Si l'identification échoue, c'est presque toujours la cause.

Orientation

vol -f HOST01_mem.raw windows.info

windows.info confirme que l'image se parse et donne le numéro de build, l'heure système au moment de la capture et le nombre de processeurs. Notez l'heure de capture : tous les horodatages cités ensuite s'y rapportent.

Processus

vol -f HOST01_mem.raw windows.pslist
vol -f HOST01_mem.raw windows.pstree
vol -f HOST01_mem.raw windows.psscan
vol -f HOST01_mem.raw windows.cmdline

• windows.pslist parcourt la liste des processus actifs, celle qu'utilise l'OS lui-même.
• windows.pstree affiche les relations parent/enfant, là où la plupart des anomalies ressortent.
• windows.psscan scanne la mémoire à la recherche de structures de processus et retrouve des processus terminés ainsi que des processus détachés de la liste par un rootkit. Un processus présent dans psscan mais absent de pslist, sans heure de fin, est un constat.
• windows.cmdline donne la ligne de commande de chaque processus : PowerShell encodé, chemins étranges et détournements de LOLBins y apparaissent.

Réseau

vol -f HOST01_mem.raw windows.netscan

windows.netscan scanne les endpoints et connexions TCP/UDP avec le PID propriétaire, le nom du processus et, quand elle existe, l'heure de création. windows.netstat parcourt au contraire les structures actives ; utilisez les deux, puisque le scan retrouve aussi les connexions fermées.

Code injecté et modules

vol -f HOST01_mem.raw windows.malfind --pid 4312 --dump
vol -f HOST01_mem.raw windows.dlllist --pid 4312
vol -f HOST01_mem.raw windows.ldrmodules --pid 4312

• windows.malfind cherche les régions de mémoire privée exécutables et modifiables contenant ce qui ressemble à du code. Il est bruyant : .NET, les moteurs JIT et certains produits de sécurité génèrent des résultats. Regardez le désassemblage et la présence d'un en-tête MZ, puis confirmez.
• windows.dlllist liste les modules d'après la liste du loader ; windows.ldrmodules compare les listes du loader aux fichiers mappés, ce qui expose les DLL masquées dans l'une d'elles.

Handles, services et registre

Deux ajouts rapides pour les processus suspects : windows.getsids montre sous quel compte et quels groupes tourne un processus, et windows.privileges montre les privilèges activés, comme SeDebugPrivilege, dont les outils de vol d'identifiants ont besoin.

vol -f HOST01_mem.raw windows.handles --pid 4312
vol -f HOST01_mem.raw windows.svcscan
vol -f HOST01_mem.raw windows.registry.hivelist
vol -f HOST01_mem.raw windows.registry.printkey --key "Software\Microsoft\Windows\CurrentVersion\Run"

windows.handles révèle les fichiers, clés de registre, mutex et named pipes ouverts (les frameworks de C2 utilisent souvent des noms de pipe et de mutex caractéristiques). windows.svcscan liste les services connus du Service Control Manager, y compris ceux dont la clé de registre a déjà été supprimée. Les plugins registre lisent les ruches telles qu'elles étaient en mémoire, ce qui peut inclure des modifications pas encore écrites sur le disque (voir la page ruches de registre).

Fichiers

vol -f HOST01_mem.raw windows.filescan > filescan.txt
vol -o ./dump -f HOST01_mem.raw windows.dumpfiles --virtaddr 0xe0012a4b3c80
vol -o ./dump -f HOST01_mem.raw windows.dumpfiles --pid 4312

windows.filescan liste les objets fichier avec leur adresse virtuelle ; windows.dumpfiles extrait le contenu en cache par adresse, ou pour tous les fichiers mappés par un processus. Les fichiers extraits peuvent être incomplets, puisque seules les pages résidentes en mémoire sont récupérables. Traitez les exécutables extraits comme des fichiers PE pour le triage et le hash.

Utilisez -r csv ou -r json pour une sortie exploitable par machine, et -o pour choisir le répertoire de sortie des dumps.

Chasser les anomalies

La plupart des constats mémoire viennent de la connaissance de la normalité.

Au-delà du tableau :

• Incohérences parent/enfant : toujours le moyen le plus rapide d'entrer. Des shells sous WmiPrvSE.exe ou wsmprovhost.exe, ou des binaires inconnus lancés par services.exe, orientent aussi vers du mouvement latéral.
• Processus détachés : comparez pslist et psscan.
• Chemins inhabituels : binaires lancés depuis AppData, ProgramData, C:\Users\Public ou Temp.
• Process hollowing : un chemin d'image d'apparence légitime dont la mémoire ne correspond pas au fichier sur disque. Les versions récentes de Volatility ajoutent des plugins dédiés ; malfind et ldrmodules en attrapent déjà beaucoup.

YARA et strings sur la mémoire

vol -f HOST01_mem.raw windows.vadyarascan --yara-file ./rules/cobaltstrike.yar
vol -f HOST01_mem.raw yarascan.YaraScan --yara-file ./rules/c2_strings.yar
strings -a -el HOST01_mem.raw > strings_utf16.txt

windows.vadyarascan scanne la mémoire des processus et rattache chaque résultat à un PID ; yarascan.YaraScan scanne la couche mémoire dans son ensemble, sans attribution par processus. Un simple strings (ASCII et UTF-16LE) sur l'image, le pagefile et le hiberfil décompressé reste utile pour les IP, URL et fragments de commandes, mais ne peut pas rattacher un résultat à un processus.

MemProcFS comme alternative

MemProcFS monte une image mémoire comme un système de fichiers : les processus deviennent des dossiers, et leurs modules, handles, cartes mémoire et fichiers extraits deviennent des fichiers. Son mode forensic ajoute une timeline, les enregistrements NTFS retrouvés en mémoire, l'accès au registre et un rapport findevil qui signale les schémas d'injection courants.

MemProcFS.exe -device E:\HOST01_mem.raw -forensic 1
# Puis parcourir M:\ (par exemple M:\forensic\ et M:\name\<processus>\)

Il est rapide et pratique pour naviguer et alimenter d'autres outils. Volatility reste la référence pour une sortie de plugins scriptée et reproductible. Utiliser les deux sur la même image est courant.

Intégration à la timeline

Les horodatages mémoire prennent toute leur valeur à côté des preuves disque. timeliner.Timeliner de Volatility 3 collecte les horodatages de tous les plugins qui en exposent et peut écrire un body file pour mactime ou Plaso ; MemProcFS écrit ses propres fichiers de timeline en mode forensic.

vol -f HOST01_mem.raw timeliner.Timeliner --create-bodyfile

Fusionnez ensuite le résultat dans votre super timeline, comme décrit dans construire une super timeline avec Plaso. Une heure de création de processus issue de la mémoire, à côté de son entrée Prefetch et d'un événement 4688, est une corroboration solide ; un processus qui n'existe qu'en mémoire est une piste à creuser (voir preuves d'exécution).

Pièges

• Smear. L'acquisition n'est pas instantanée. Des pages capturées à des moments différents peuvent produire des structures incohérentes : listes tronquées, processus pointant vers de la mémoire libérée, plugins qui plantent. Relancez le plugin, recoupez avec un plugin de scan, et ne surinterprétez pas un résultat isolé.
• Mémoire compressée (Windows 10 et suivants). Les pages évincées vers le magasin de compression mémoire (processus MemCompression) sont compressées. Les plugins standard et les recherches de chaînes peuvent rater ces données. Le support du magasin compressé varie selon l'outil et la version : « introuvable » ne veut pas dire « absent ».
• Données paginées. Tout ce qui a été écrit dans pagefile.sys manque dans l'image RAM, sauf si vous avez aussi collecté le pagefile.
• VBS et Credential Guard. Avec la sécurité basée sur la virtualisation, une partie de la mémoire est isolée de l'OS normal. Les secrets Credential Guard vivent dans LsaIso.exe et ne sont pas récupérables depuis l'image. HVCI et la liste de blocage des pilotes vulnérables peuvent aussi empêcher le chargement de pilotes d'acquisition anciens : testez vos outils sur des builds récents.
• Symboles incorrects. Un ISF faux ou manquant produit des erreurs ou des résultats absurdes. Vérifiez windows.info d'abord.
• Bruit de malfind. Une mémoire privée RWX n'est pas un malware en soi. Confirmez par le contenu, le contexte et un second artefact.
• Anti-forensique. Un malware peut altérer des structures ou détecter les pilotes d'acquisition ; voir détecter l'anti-forensique.

Méthode pas à pas

1. Capturer la RAM en premier sur les systèmes allumés (ou suspendre la VM), hasher l'image, noter l'heure de capture et la version de l'outil.
2. Collecter hiberfil.sys, pagefile.sys, swapfile.sys et les crash dumps avec la collecte de triage du disque.
3. Lancer windows.info et régler les symboles avant toute chose.
4. Établir le tableau des processus : pslist, pstree, psscan, cmdline.
5. Cartographier le réseau : netscan, netstat, puis pivoter vers les processus propriétaires.
6. Chercher l'injection : malfind, dlllist, ldrmodules, puis YARA.
7. Examiner handles, services et clés de registre en mémoire à la recherche de persistance et d'artefacts de C2.
8. Extraire les processus et fichiers suspects, les hasher et les trier.
9. Construire une timeline mémoire et la fusionner avec les artefacts disque.
10. Documenter chaque plugin lancé, sa version et son fichier de sortie pour que l'analyse soit reproductible.