Memory Forensics avec Volatility 3 : Analyser des Dumps en Lab Reproductible

La memory forensics est la discipline qui reconstruit la verite volatile d'un systeme compromis a partir d'une image de RAM: processus en cours, sockets ouverts, payloads dechiffres et code injecte qui ne touche jamais le disque. Volatility 3 est le standard open source pour cela, entierement reecrit en Python 3, utilisant des tables de symboles au lieu de profils rigides. Chez Basilisk, on analyse chaque dump dans un labo reproductible pour qu'un resultat tienne au tribunal et en revue par les pairs. Ce guide va de l'acquisition de l'image jusqu'a la detection de l'injection de processus, avec des commandes que vous pouvez suivre directement.

Pourquoi la memoire volatile compte

Presque tout malware moderne n'existe qu'en RAM a un moment donne: loaders sans fichier, beacons injectes dans explorer.exe, volumes LUKS ou BitLocker dont les cles sont en memoire. Qui n'image que le disque perd l'arbre des processus, les connexions reseau vers le C2, le presse-papiers, les chaines dechiffrees et les restes de processus termines. L'ordre de volatilite selon RFC 3227 est clair: registres CPU et cache d'abord, puis RAM, puis swap, et seulement ensuite le disque. C'est pourquoi la premiere action lors d'un incident en direct est souvent une capture memoire propre, avant que quiconque n'eteigne le systeme ou ne lance un nettoyage.

Acquerir l'image memoire

L'acquisition doit preserver l'integrite: empreinte minimale, hachage immediat, chaine de custody documentee. Sous Windows on utilise WinPmem ou Magnet RAM Capture, sous Linux AVML ou LiME en module noyau, et en environnement virtualise le snapshot natif de l'hyperviseur, souvent la voie la plus propre. Juste apres le dump on calcule sha256sum image.raw et on note la valeur dans le journal du cas. Une image sans hash et sans horodatage est forensiquement sans valeur. Pour l'analyse Windows, le pagefile.sys correspondant est aussi precieux, car les pages evacuees apparaissent sinon comme des trous.

Monter un labo reproductible

La reproductibilite est le coeur d'une forensique serieuse. On travaille dans un conteneur Docker ou un venv Python avec une version de Volatility 3 epinglee, des packs de symboles haches et l'image montee en volume en lecture seule. Chaque analyse part du meme requirements.txt pour qu'un collegue produise exactement le meme resultat. L'image originale reste intacte; tout le travail tourne sur une copie verifiee dont le hash correspond a l'original. On journalise chaque commande executee avec horodatage dans un runbook de cas, afin que toute la chaine d'analyse soit ensuite reproductible etape par etape.

Volatility 3 et les tables de symboles

Volatility 3 abandonne les profils rigides de la version 2 et utilise a la place des Intermediate Symbol Files (ISF) generes a partir des symboles de debug du noyau. Pour Windows, le framework charge les symboles automatiquement depuis le serveur de symboles Microsoft via le GUID du noyau; pour Linux et macOS, vous generez l'ISF a partir du System.map correspondant et des en-tetes du noyau avec dwarf2json. La premiere execution est toujours vol -f image.raw windows.info pour confirmer la version de l'OS, la base du noyau et le fuseau horaire. Si le pack de symboles est faux, tout plugin suivant renvoie n'importe quoi, c'est pourquoi cette etape n'est jamais sautee.

Analyser les processus: pslist, psscan, pstree

Le coeur de l'analyse est le contexte de processus. windows.pslist parcourt la liste doublement chainee des processus actifs telle que le noyau la maintient. windows.psscan, en revanche, scanne la memoire a la recherche de signatures _EPROCESS et trouve donc aussi les processus termines ou caches par DKOM qui ont ete delies de la liste. La difference entre les deux sorties est un indicateur classique de rootkit. windows.pstree montre la hierarchie parent-enfant, ou les anomalies sautent aux yeux: un cmd.exe sous winword.exe, un powershell.exe sous outlook.exe ou un lsass.exe au mauvais parent sont autant de signaux d'alarme.

Reseau et handles

Apres les processus viennent les connexions. windows.netscan reconstruit les endpoints TCP et UDP avec IP de destination, port, etat et processus proprietaire, exposant des canaux C2 actifs meme quand la connexion fut breve. windows.handles liste les handles ouverts d'un processus vers fichiers, cles de registre, mutex et named pipes; un mutex suspect est souvent la signature d'une famille de malware connue. windows.dlllist et windows.ldrmodules comparent les modules charges: une DLL presente dans l'image memoire mais absente des trois listes de chargement suggere fortement un chargement reflexif de DLL.

Detecter injection et hollowing

Le plugin le plus important pour les menaces actives est windows.malfind. Il traque les regions memoire combinant la protection PAGE_EXECUTE_READWRITE, l'absence de backing fichier et des octets executables au debut, ce qui est le motif classique de l'injection de shellcode et du process hollowing. La sortie montre un hex dump; un en-tete MZ ou la signature revelatrice 4D 5A dans une region RWX confirme un PE injecte. En complement, windows.hollowprocesses attrape le cas ou un processus legitime a ete demarre et sa memoire remplacee par du code etranger. Chaque decouverte est recoupee avec windows.vadinfo pour nommer precisement la region VAD concernee.

Extraire les artefacts

Une fois un processus suspect confirme, on extrait les preuves. windows.memmap --pid N --dump sauvegarde toute la memoire adressable du processus; windows.dumpfiles --pid N reconstruit les fichiers en cache depuis la memoire. La region injectee issue de malfind peut etre isolee et passee a une sandbox ou a un desassembleur comme Ghidra. On recupere les hives du registre avec windows.registry.hivelist et windows.registry.printkey pour inspecter les cles de persistance sous Run et Services. Chaque fichier extrait est hache immediatement et lie a son PID d'origine dans le runbook du cas.

Pieges frequents

Le premier piege est le mauvais pack de symboles, qui donne des resultats plausibles mais entierement faux. Le deuxieme est d'ignorer la difference entre pslist et psscan, laissant des processus caches non detectes. Le troisieme est de travailler sur l'original plutot que sur une copie hachee, ce qui detruit la chaine de preuve. Le quatrieme est de se fier a un seul indicateur: un segment RWX a lui seul n'est pas forcement malveillant, car les compilateurs JIT creent aussi de telles regions. Le cinquieme est d'oublier le pagefile.sys, ce qui laisse des preuves evacuees manquantes et une analyse pleine de trous.

Checklist

Acquerez l'image avec une empreinte minimale et hachez-la immediatement en SHA-256. Travaillez dans un labo reproductible sur une copie en lecture seule. Confirmez la version de l'OS et le bon pack de symboles avec windows.info. Triez les processus avec pslist, psscan et pstree et notez les differences. Verifiez le reseau avec netscan, les modules avec dlllist et ldrmodules. Chassez l'injection avec malfind et hollowprocesses. Extrayez les regions suspectes avec memmap et dumpfiles, hachez-les et documentez-les dans le runbook. Etayez chaque constat avec au moins deux indicateurs independants.

Timeline et correlation

Un seul plugin donne un instantane; l'histoire de l'incident n'emerge que de la correlation de plusieurs sources le long d'une timeline. windows.pstree avec les horodatages de creation, combine aux temps de connexion de netscan et aux horodatages de windows.registry.userassist, produit une sequence defendable: quand le loader a demarre, quand le canal C2 s'est ouvert, quand la persistance a ete posee. On exporte ces artefacts et on les fusionne dans un outil de super-timeline comme Plaso pour que les evenements disque et memoire tiennent dans une seule vue chronologique. Alors seulement on peut separer la cause de l'effet et nommer le patient zero. L'alignement de fuseau horaire compte: windows.info donne le bias, et chaque horodatage est normalise de facon coherente en UTC, sinon on fabrique une causalite apparente qui n'a jamais existe. Une timeline propre est l'ossature du rapport final et la premiere chose qu'un expert verifie.

Memoire Linux et macOS

Windows domine les exemples, mais Volatility 3 analyse aussi les images Linux et macOS, a condition que l'ISF correspondant existe. Pour Linux, vous le generez avec dwarf2json a partir du System.map specifique au noyau et des symboles de debug du noyau exact en cours d'execution, car meme une difference de patch-level casse la structure. Les noms de plugin refletent la logique Windows: linux.pslist et linux.pstree pour les processus, linux.bash extrait l'historique des commandes directement de la memoire du shell, et linux.check_syscall et linux.check_modules traquent les rootkits noyau qui ont detourne la table des syscalls. Pour les conteneurs, il importe qu'un seul dump de l'hote contienne tous les namespaces; les processus de differents conteneurs apparaissent cote a cote et se separent par leur appartenance cgroup. macOS exige un pack de symboles genere depuis la KDK correspondante. Le principe reste identique: symboles verifies d'abord, puis triage systematique, puis extraction etayee.

FAQ : Puis-je analyser un dump memoire sans profil OS exact ?

Dans Volatility 3, il n'y a plus de profils choisis a la main; le framework derive la structure des tables de symboles. Pour Windows, cela se fait automatiquement via le GUID du noyau et le serveur de symboles Microsoft. Pour Linux, vous devez generer vous-meme l'ISF correspondant a partir du System.map et des symboles de debug du noyau avec dwarf2json, sinon les plugins echouent.

FAQ : Et si malfind ne trouve rien mais que le soupcon demeure ?

malfind est puissant mais pas omniscient: un malware avance peut eviter les regions RWX, mapper la memoire comme une image ou decompresser le code seulement a l'execution. Completez alors l'analyse avec ldrmodules pour les DLL deliees, netscan pour les traces de C2 et un scan YARA sur toute l'image avec windows.vadyarascan pour toucher des signatures connues.

Conclusion

Conclusion pratique: montez aujourd'hui un labo reproductible, acquerez une image d'une VM de test avec un beacon connu, et executez toute la chaine de windows.info a malfind jusqu'a voir vous-meme le code injecte. La memory forensics n'est pas de la magie, c'est un travail methodique: acquisition propre, symboles verifies, triage systematique des processus, indicateurs etayes plusieurs fois et une chaine de preuve ininterrompue. Qui hache et journalise chaque etape livre des resultats qui tiennent aussi bien dans un rapport de reponse a incident que devant un tribunal. Repetez l'exercice avec differentes techniques d'injection jusqu'a ce que le motif dans le hex dump saute aux yeux immediatement.