Forensique memoire avec Volatility 3 : guide de terrain pour defenseurs

Lorsqu'un poste est compromis, les preuves les plus precieuses ne touchent souvent jamais le disque. Cles de dechiffrement, code injecte, malware depackage, connexions reseau, arguments de ligne de commande et identifiants n'existent frequemment qu'en memoire volatile, et disparaissent au moment ou la machine s'eteint. La forensique memoire est la discipline consistant a capturer et analyser cette RAM pour reconstruire ce qu'un systeme faisait, et Volatility 3 est le framework open source vers lequel se tournent la plupart des defenseurs. Ce guide de terrain adopte la perspective d'un analyste blue team repondant a un incident : comment acquerir la memoire proprement, quels plugins repondent a quelles questions, comment reconnaitre les signaux d'injection de code et de rootkits et comment eviter les erreurs menant a de fausses conclusions. Le cadrage est comprendre pour defendre, aussi nous concentrons-nous sur la detection et le tri plutot que sur l'ecriture de malware, et chaque technique est presentee comme quelque chose que vous executez pour trouver un attaquant deja a l'interieur.

Pourquoi la forensique memoire compte#

La forensique disque vous dit ce qui etait stocke ; la forensique memoire vous dit ce qui s'executait. Les intrusions modernes vivent de plus en plus sur le terrain et operent en memoire pour echapper a la detection basee sur les fichiers : le malware sans fichier s'execute depuis PowerShell ou WMI sans binaire persistant, l'injection de processus cache du code dans des processus legitimes, et les charges empaquetees ou chiffrees ne revelent leur vraie forme qu'une fois chargees en RAM. La memoire retient aussi un etat transitoire qu'aucun journal n'enregistre, comme la ligne de commande exacte d'un processus deja termine, des sockets reseau ouverts, des modules noyau charges et des identifiants en cache. Pour un intervenant, une image memoire est un instantane fige de la scene de crime au moment de la capture. Elle permet de repondre a des questions que les journaux seuls ne peuvent pas, et peut confirmer ou refuter une hypothese sur la maniere dont un attaquant a obtenu l'execution, ce qu'il a touche et s'il reste resident.

Acquisition memoire propre#

L'analyse n'est fiable que dans la mesure de l'acquisition. Le principe central est de perturber le systeme le moins possible et de consigner exactement ce que l'on a fait. Sur les hotes Windows en direct, des outils comme WinPmem, FTK Imager ou Magnet RAM Capture produisent une image brute ; sous Linux, AVML ou un module noyau LiME capturent la memoire physique ; les machines virtuelles peuvent etre capturees par snapshot ou leurs fichiers memoire copies, souvent l'option la plus propre car effectivement atomique. Hachez toujours l'image immediatement (par exemple SHA-256) et conservez ce hachage dans vos notes, capturez la memoire avant le disque lorsque c'est possible car c'est la preuve la plus volatile, et documentez l'hote, l'heure, l'outil, la version et l'operateur pour maintenir la chaine de possession. Evitez de lancer l'acquisition depuis les binaires non fiables de l'hote suspect, et sachez qu'un rootkit en cours d'execution peut, en principe, interferer avec l'acquisition, une raison de correler les constatations memoire avec une telemetrie independante.

Fondamentaux de Volatility 3#

Volatility 3 est une reecriture du framework classique avec une approche pilotee par les symboles. Au lieu de selectionner manuellement un "profil" de systeme d'exploitation comme dans Volatility 2, la version 3 identifie automatiquement le systeme d'exploitation et localise les structures noyau via des tables de symboles, obtenues pour Windows depuis les informations PDB et provenant pour Linux et macOS de paquets de symboles apparies par banniere que vous fournissez. On l'invoque avec vol -f memory.img plugins.Name, ou python3 vol.py depuis les sources. Le modele mental est que chaque plugin parcourt des structures de donnees noyau specifiques pour reconstruire un aspect de l'etat du systeme. Obtenir une analyse Linux correcte necessite un paquet de symboles ISF correspondant au noyau exact, un obstacle initial courant. Une fois les symboles resolus, le meme flux d'investigation s'applique sur toutes les plateformes : enumerer les processus, inspecter leurs relations, examiner l'etat reseau, chasser l'injection et extraire les artefacts pour une etude approfondie.

Plugins cles et ce qu'ils revelent#

Une poignee de plugins forme l'ossature de la plupart des investigations. windows.pslist parcourt la liste chainee double des processus, tandis que windows.psscan balaie la memoire a la recherche de structures de processus directement et peut reveler des processus caches de la liste ; comparer les deux est une etape de detection classique. windows.pstree montre les relations parent-enfant, ce qui expose des lignees suspectes comme un navigateur engendrant un shell. windows.cmdline recupere les lignes de commande des processus, souvent l'artefact le plus instructif. windows.netscan reconstruit les connexions reseau et les ports en ecoute. windows.dlllist et windows.handles montrent les modules charges et les objets ouverts. Sous Linux les analogues sont linux.pslist, linux.pstree, linux.bash pour l'historique du shell et linux.check_syscall pour l'alteration. Ces plugins transforment un bloc opaque d'octets en un inventaire de ce que la machine faisait, et les desaccords entre plugins censes concorder sont eux-memes des signaux forts.

Detecter l'injection de processus#

L'injection de processus cache le code de l'attaquant dans un processus de confiance, et la forensique memoire est l'un des moyens les plus fiables de l'attraper. Le plugin defensif cle est windows.malfind, qui balaie la memoire des processus a la recherche de regions a la fois executables et inscriptibles et depourvues de fichier de sauvegarde sur disque, une combinaison dont le code legitime a rarement besoin et que le shellcode et les modules charges par reflexion presentent frequemment. Les analystes cherchent des pages de memoire privee marquees PAGE_EXECUTE_READWRITE, l'en-tete revelateur MZ d'une image PE mappee la ou aucun module ne devrait exister, et des regions injectees dans des processus qui n'ont aucune raison de les heberger. Des signaux complementaires incluent un processus dont la liste de modules omet une DLL clairement presente en memoire, des threads dont l'adresse de depart pointe vers une memoire non sauvegardee, et des processus creuses ou l'image sur disque et en memoire divergent. Aucun n'est une preuve a lui seul, mais ensemble ils batissent un dossier convaincant et doivent etre corrobores par la telemetrie EDR et reseau.

Chasser rootkits et artefacts caches#

Les rootkits tentent de se rendre invisibles au systeme d'exploitation en cours d'execution, mais ne peuvent pas facilement se cacher d'une vue externe de la memoire, ce qui est precisement l'avantage de l'analyse forensique. La detection a vue croisee compare deux facons d'enumerer la meme chose et signale les desaccords : un processus visible pour psscan mais absent de pslist peut avoir ete delie de la liste des processus actifs, une technique de dissimulation classique. Sous Linux, linux.check_syscall et les verifications d'integrite de module revelent des tables de syscall accrochees ou des pointeurs de fonction alteres. Les analystes inspectent aussi la SSDT et l'IDT sous Windows, les modules noyau caches et les objets pilote ne correspondant a aucun fichier legitime. Le principe defensif est la triangulation : ne faites jamais confiance a un unique chemin d'enumeration, car tout le but d'un rootkit est de corrompre une vue tout en laissant une autre intacte. La forensique memoire l'emporte ici car elle lit des structures que l'OS compromis tentait de dissimuler.

Extraire et pivoter vers une analyse plus profonde#

Une fois que l'analyse memoire identifie quelque chose de suspect, l'etape suivante est l'extraction pour une etude plus rapprochee. windows.dumpfiles recupere les fichiers mis en cache en memoire, windows.memmap et les plugins de dump de processus extraient l'espace d'adressage d'un processus, et les regions injectees trouvees par malfind peuvent etre decoupees pour une analyse statique ou dynamique en bac a sable. Les lignes de commande et les points de terminaison reseau recuperes deviennent des indicateurs de compromission que vous pouvez balayer sur le reste du parc. Les ruches de registre residentes en memoire peuvent etre analysees pour des cles de persistance et des programmes recemment executes. Le flux est iteratif : une constatation en memoire genere une hypothese, l'artefact extrait la confirme ou l'affine, et les indicateurs resultants alimentent une chasse sur d'autres hotes. Tout du long, gardez l'image originale immuable et travaillez sur des copies, pour que votre analyse reste reproductible et defendable si l'affaire s'aggrave.

Pieges courants#

Plusieurs erreurs reviennent. La plus dommageable est une mauvaise acquisition : une image floue capturee sur un systeme en direct charge peut contenir des structures incoherentes qui font echouer ou mentir les plugins, alors preferez les snapshots atomiques quand c'est possible et notez les conditions d'acquisition. Utiliser de mauvais symboles ou des symboles absents dans Volatility 3, surtout sous Linux, produit une sortie vide ou absurde que les analystes interpretent parfois a tort comme "rien trouve" plutot que "outil mal configure". Traiter la sortie d'un unique plugin comme verite absolue ignore que les rootkits ciblent des vues specifiques ; verifiez toujours de facon croisee. Les analystes surinterpretent aussi les resultats de malfind, qui ont des causes legitimes comme les compilateurs JIT, donc le contexte compte. Enfin, ne pas preserver la chaine de possession et les hachages peut rendre inutiles des constatations techniques solides dans une procedure formelle. Chacune est evitable avec de la discipline : acquerir proprement, verifier les symboles, corroborer entre plugins et telemetrie, et documenter sans relache.

Checklist d'investigation#

Utilisez cette checklist pour structurer une investigation memoire. 1) Acquerez la memoire avec un outil documente et hachez l'image immediatement. 2) Confirmez que Volatility 3 resout les bons symboles avant de faire confiance a la sortie. 3) Enumerez les processus avec pslist, psscan et pstree et comparez les listes. 4) Recuperez les lignes de commande avec cmdline et signalez les lignees suspectes. 5) Reconstruisez l'etat reseau avec netscan et comparez aux journaux du pare-feu. 6) Executez malfind et triez les regions executables-inscriptibles non sauvegardees. 7) Effectuez des verifications a vue croisee pour les processus, modules et hooks de syscall caches. 8) Extrayez les processus suspects et les regions injectees pour une analyse plus profonde. 9) Extrayez les IOC et balayez le parc plus large. 10) Corroborez chaque constatation memoire avec des preuves EDR, reseau et disque, et documentez la chaine de possession tout du long.

Questions frequentes#

La forensique memoire peut-elle detecter un malware sans fichier qui n'ecrit jamais sur disque ? Oui, et c'est l'une de ses plus grandes forces. Comme les techniques sans fichier s'executent en RAM, une image memoire capture souvent le code injecte, les scripts charges de l'interpreteur et les connexions reseau qui ne laissent aucun fichier, ce que la forensique disque manquerait entierement. Volatility 3 est-il fiable face a un rootkit actif qui tente de se cacher ? Il est bien plus fiable que d'interroger l'OS compromis, car il lit des structures noyau brutes de l'exterieur plutot que de faire confiance aux API du systeme d'exploitation. Cependant, un rootkit sophistique peut tenter de corrompre aussi ces structures, donc la bonne pratique est l'analyse a vue croisee et la corroboration avec une telemetrie independante plutot que de faire confiance a un unique resultat.

Conclusion#

La forensique memoire donne aux defenseurs une visibilite sur la partie d'une intrusion qui ne laisse aucune trace sur disque, et Volatility 3 rend cette visibilite accessible avec un flux coherent pilote par plugins a travers Windows, Linux et macOS. La methode est simple en principe : acquerir la memoire proprement, resoudre les bons symboles, enumerer ce que le systeme faisait, chasser les desaccords et les regions executables non sauvegardees qui trahissent l'injection et les rootkits, extraire les artefacts et tout corroborer avec des preuves independantes. La discipline qui separe une investigation fiable d'une trompeuse est le scepticisme envers toute vue unique et la rigueur dans l'acquisition et la documentation. Bien pratiquee, la forensique memoire transforme un instantane fugace de RAM en une reconstruction defendable d'une attaque, et fournit frequemment la preuve decisive que les journaux et le disque seuls ne peuvent apporter.