Volatility Framework : analyse de la mémoire vive en investigation numérique

📍 Article de référence : Réponse aux incidents et analyse forensique numérique (DFIR) : guide complet 2025
Cet article est le tutoriel pratique d’analyse de la mémoire vive avec Volatility 3. Consultez le guide de référence pour la vue d’ensemble DFIR.

Les malwares modernes évitent autant que possible d’écrire sur le disque — une technique appelée fileless malware ou attaque living off the land. Les payloads sont injectés directement dans la mémoire de processus légitimes (explorer.exe, svchost.exe, lsass.exe), les shellcodes s’exécutent dans des régions mémoire allouées dynamiquement, les clés de chiffrement résident en RAM pendant l’exécution du ransomware. Ces artefacts n’existent que dans la mémoire vive et disparaissent définitivement à l’extinction du système.

Volatility 3, maintenu par la Volatility Foundation sur GitHub, est le framework open-source de référence mondiale pour l’analyse de dumps mémoire RAM. Il décode la mémoire brute capturée — des gigaoctets de données apparemment inintelligibles — pour en extraire une image précise de l’état du système au moment de la capture : processus actifs, connexions réseau établies, modules chargés, injections de code, clés de chiffrement, activité utilisateur récente. Ce tutoriel vous guide de l’acquisition du dump mémoire jusqu’à l’identification d’un malware injecté en mémoire.

Prérequis

• OS de l’analyste : Linux (Ubuntu 20.04+) ou Windows 10/11, ou SIFT Workstation (Volatility 3 préinstallé)
• Python : 3.8 ou supérieur requis
• Mémoire analyste : 8 Go minimum (Volatility charge des structures volumineuses en RAM)
• Outils requis : WinPmem (Windows) ou LiME (Linux) pour l’acquisition ; pip3 pour l’installation
• Niveau : intermédiaire à avancé (connaissance des structures Windows OS recommandée)
• Temps estimé : 2 à 4 heures selon la complexité de l’investigation

Étape 1 — Installer Volatility 3

Volatility 3 s’installe en quelques commandes. Deux méthodes sont disponibles : via pip (plus simple, recommandée pour une utilisation régulière) ou en clonant le dépôt GitHub (pour les dernières fonctionnalités et contributions de la communauté). Sur la SIFT Workstation SANS, Volatility 3 est préinstallé et à jour.

# Méthode 1 : Installation via pip3 (recommandée)
pip3 install volatility3

# Vérifier l'installation
python3 -m volatility3 --version
# Sortie attendue : Volatility 3 Framework x.x.x

# Méthode 2 : Cloner depuis GitHub (version de développement)
git clone https://github.com/volatilityfoundation/volatility3.git
cd volatility3
pip3 install -r requirements.txt

# Vérifier depuis le répertoire cloné
python3 vol.py --version

La commande python3 -m volatility3 --version (méthode pip) ou python3 vol.py --version (méthode GitHub) confirme l’installation. Si une erreur ModuleNotFoundError: No module named 'volatility3' apparaît avec la méthode pip, vérifier que pip3 pointe bien vers Python 3.8+ avec pip3 --version et que l’environnement PATH est correct. Sur certaines distributions Linux, utiliser pip install volatility3 sans le 3 si Python 3 est le défaut.

Étape 2 — Acquérir un dump mémoire RAM

Un dump mémoire est une copie brute du contenu de la RAM au moment de l’acquisition. Son exactitude dépend de la vitesse d’acquisition (une capture de 16 Go de RAM prend 2 à 5 minutes sur un système actif — le contenu évolue pendant ce temps) et de l’absence d’activité de l’attaquant pendant la capture. C’est pourquoi la capture mémoire doit être la première action lors d’une live forensics, avant toute autre intervention.

Sur Windows — WinPmem (Velocidex) :

# Télécharger WinPmem depuis GitHub (Velocidex/WinPmem)
# Exécuter en tant qu'Administrateur (PowerShell élevé)

# Capturer la RAM vers un fichier raw
.\winpmem_mini_x64.exe memory_capture.raw

# Calculer le hash SHA-256 immédiatement après acquisition
Get-FileHash -Algorithm SHA256 memory_capture.raw | Tee-Object -FilePath memory_capture.sha256.txt

WinPmem s’exécute en tant qu’administrateur et charge un pilote kernel temporaire pour accéder directement à la mémoire physique. Le fichier memory_capture.raw produit est une image brute (format RAW) de toute la RAM. Le hash SHA-256 doit être calculé immédiatement et consigné dans le journal de chaîne de custody. Certains EDR peuvent bloquer le chargement du pilote WinPmem — dans ce cas, l’exclure temporairement ou utiliser un outil certifié par l’éditeur de l’EDR.

Sur Linux — LiME (Linux Memory Extractor) :

# LiME s'installe en compilant un module kernel sur la machine CIBLE
# (nécessite les headers kernel : apt install linux-headers-$(uname -r))
git clone https://github.com/504ensicsLabs/LiME.git
cd LiME/src
make

# Charger le module et capturer vers un fichier local
sudo insmod lime-$(uname -r).ko "path=/tmp/linux_memory.lime format=lime"

# Après capture, retirer le module
sudo rmmod lime

# Hash SHA-256 de la capture
sha256sum /tmp/linux_memory.lime | tee /tmp/linux_memory.sha256

LiME compile un module kernel spécifique à la version de kernel cible (uname -r). L’option format=lime produit le format LiME natif que Volatility 3 reconnaît. Le format raw est aussi supporté (format=raw). Si la compilation sur la machine cible est impossible (production critique), LiME peut être précompilé sur une machine identique (même version kernel) et transféré. L’option path=tcp:4444 permet une capture directe via réseau vers un serveur forensique distant si l’écriture sur disque local est à éviter.

Étape 3 — Reconnaissance du système analysé

Avant de lancer des plugins spécialisés, la première commande à exécuter sur tout dump mémoire est windows.info (ou linux.info pour Linux). Elle extrait les métadonnées fondamentales du système : version OS, architecture, nombre de processeurs, date/heure du boot, et confirme que Volatility 3 a correctement identifié le profil depuis les structures kernel.

# Informations système depuis le dump mémoire
python3 vol.py -f /evidence/memory_capture.raw windows.info

# Sortie attendue (exemple Windows 10) :
# Variable            Value
# Kernel Base         0xf80002a74000
# DTB                 0x1aa000
# Symbols             file:///opt/volatility3/symbols/windows/ntkrnlmp.pdb/...
# Is64Bit             True
# IsPAE               False
# layer_name          0 WindowsIntel32e
# memory_layer        1 FileLayer
# KdVersionBlock      0xf80002e17400
# Major/Minor         10.0
# NtBuildNumber      19041    # Windows 10 version 2004
# MachineType         34404
# KeNumberProcessors  4
# SystemTime          2026-05-13 03:22:41
# NtSystemRoot        C:\Windows
# NtProductType       NtProductWinNt

La valeur Major/Minor 15.19041 correspond à Windows 10 version 2004 (build 19041). Le champ SystemTime indique l’heure système au moment de l’acquisition — à comparer avec votre propre horodatage de capture pour détecter toute manipulation de l’horloge système par un malware. Si Volatility 3 retourne une erreur de type « No valid layer found », le dump est probablement corrompu ou dans un format non supporté.

Étape 4 — Analyse des processus

La liste des processus en cours au moment de la capture est la première source d’artefacts malveillants. Un attaquant utilisant des techniques living off the land se dissimule souvent derrière des noms de processus légitimes légèrement modifiés (svchost.exe lancé depuis un répertoire inhabituel, lsass.exe dupliqué, explore.exe au lieu de explorer.exe) ou injecte du code dans des processus légitimes.

# Lister tous les processus (vue plate)
python3 vol.py -f memory_capture.raw windows.pslist

# Vue arborescente (relations parent-enfant)
python3 vol.py -f memory_capture.raw windows.pstree

# Lignes de commande de chaque processus (révèle les arguments suspects)
python3 vol.py -f memory_capture.raw windows.cmdline

# Exemple de sortie windows.cmdline :
# PID     Process             Args
# 4       System
# 372     smss.exe            SystemRootSystem32smss.exe
# 648     csrss.exe           %SystemRoot%system32csrss.exe ...
# 4892    powershell.exe      powershell.exe -enc JABjAGwAaQBlAG4AdAA...
# 5120    svchost.exe         C:\Users\Temp\svchost.exe -k netsvcs

Dans cet exemple fictif mais représentatif, deux signaux d’alerte ressortent immédiatement : le processus powershell.exe avec l’argument -enc (commande PowerShell encodée en Base64 — technique classique d’obfuscation de malware), et svchost.exe lancé depuis C:\Users\Temp au lieu de C:\Windows\System32 (signe d’un exécutable malveillant imitant le nom d’un processus système). Ces deux processus sont des candidats prioritaires pour une investigation approfondie.

# Décoder la commande PowerShell encodée (sur la machine analyste)
echo "JABjAGwAaQBlAG4AdAA..." | base64 -d | iconv -f UTF-16LE -t UTF-8

# Lister les DLLs chargées par un processus spécifique (PID 4892)
python3 vol.py -f memory_capture.raw windows.dlllist --pid 4892

Le décodage Base64 révèle le script PowerShell réel qui s’exécutait — souvent un stager de malware qui télécharge le payload principal, établit une connexion reverse shell, ou exfiltre des données. windows.dlllist avec l’option --pid liste toutes les DLLs chargées par ce processus : une DLL chargée depuis un chemin inhabituel (AppData\Roaming, dossiers temporaires) est un indicateur fort de compromission.

Étape 5 — Analyse des connexions réseau

Le plugin windows.netscan extrait depuis la mémoire les structures des connexions réseau TCP/UDP actives et récemment fermées au moment de la capture. C’est l’un des artefacts les plus précieux car il peut révéler une connexion vers un serveur C2 (Command and Control) qui n’apparaîtrait plus dans les logs réseau si l’attaquant a pris soin de la fermer après exploitation.

# Connexions réseau (TCP/UDP actives et récentes)
python3 vol.py -f memory_capture.raw windows.netscan

# Sortie (colonnes principales) :
# Offset   Proto  LocalAddr    LocalPort  ForeignAddr   ForeignPort  State   PID  Owner
# 0x...    TCPv4  10.0.0.5     49821      185.220.101.5 443          ESTABLISHED 4892 powershell.exe
# 0x...    TCPv4  10.0.0.5     49822      192.168.1.1   80           CLOSE_WAIT  3241 chrome.exe

# Filtrer sur les connexions ESTABLISHED vers des IPs publiques
python3 vol.py -f memory_capture.raw windows.netscan | grep ESTABLISHED | grep -v "127.0.0.1" | grep -v "::1"

Dans l’exemple, powershell.exe (PID 4892 — déjà identifié comme suspect) maintient une connexion ESTABLISHED vers l’IP 185.220.101.5 sur le port 443. Bien que le port 443 soit normalement HTTPS légitime, une connexion PowerShell vers une IP publique en ESTABLISHED est un signal critique. L’IP doit être vérifiée sur VirusTotal, Shodan, et les flux MISP pour confirmer s’il s’agit d’une infrastructure C2 connue.

Étape 6 — Détection d’injections de code avec malfind

Le plugin windows.malfind est l’arme principale contre les malwares sans fichier (fileless). Il parcourt les VAD (Virtual Address Descriptors — les structures kernel Windows qui décrivent les régions de mémoire virtuelle de chaque processus) à la recherche de régions présentant deux caractéristiques suspectes simultanées : des permissions d’exécution (PAGE_EXECUTE_READWRITE ou PAGE_EXECUTE_READ) sur une région privée, et la présence possible d’un en-tête PE (MZ header — 4D 5A en hexadécimal) — signature d’un exécutable Windows chargé en mémoire sans correspondance sur le disque.

# Scanner les processus pour des injections de code
python3 vol.py -f memory_capture.raw windows.malfind

# Sortie (extrait) :
# PID     Process       Start VPN    End VPN     Tag  Protection  CommitCharge  PrivateMemory  File output  Hexdump
# 4892    powershell.exe 0x1d0000    0x1f0000    VadS PAGE_EXECUTE_READWRITE 32  1              Disabled
# 4d 5a 90 00 03 00 00 00  04 00 00 00 ff ff 00 00   MZ..............

# Dumper la région mémoire suspecte pour analyse
python3 vol.py -f memory_capture.raw windows.dumpfiles --pid 4892 --dump-dir /evidence/dumps/

# Analyser le dump avec file et strings
file /evidence/dumps/*.dat
strings /evidence/dumps/*.dat | grep -i "http|cmd|powershell|exec"

La présence de l’en-tête 4d 5a (MZ) dans une région PAGE_EXECUTE_READWRITE d’un processus confirme une injection de code PE. La commande windows.dumpfiles extrait le contenu de cette région vers des fichiers analysables. La commande strings sur les dumps révèle souvent des URLs de C2, des noms de fonctions Windows API utilisées par le malware, des messages de debug laissés par les développeurs du malware, ou des chaînes de configuration. Ces artefacts sont ensuite soumis à VirusTotal, une sandbox (Any.run, Cuckoo), ou analysés avec un décompilateur (Ghidra, IDA Pro).

Étape 7 — Extraction des artefacts de registre et utilisateurs

Le registre Windows est partiellement chargé en mémoire pendant l’exécution. Volatility 3 peut en extraire des clés sans accéder au disque — particulièrement utile pour retrouver des clés de persistance malveillante (Run, RunOnce, Services) que l’attaquant aurait tentées de dissimuler.

# Lister les hives de registre en mémoire
python3 vol.py -f memory_capture.raw windows.registry.hivelist

# Afficher le contenu d'une clé de persistance couramment utilisée par les malwares
python3 vol.py -f memory_capture.raw windows.registry.printkey   --key "SOFTWARE\Microsoft\Windows\CurrentVersion\Run"

# Lister les comptes utilisateurs (depuis la hive SAM en mémoire)
python3 vol.py -f memory_capture.raw windows.hashdump

La clé SOFTWARE\Microsoft\Windows\CurrentVersion\Run est l’une des clés de persistance les plus utilisées par les malwares pour se relancer au démarrage. windows.hashdump extrait les hashes NTLM des mots de passe utilisateurs depuis les structures SAM en mémoire — artefacts précieux pour identifier quels comptes l’attaquant a pu compromettre ou créer. Ces hashes peuvent ensuite être soumis à Hashcat ou consultés dans des bases de hashes connus (CrackStation, Hashes.org) pour identifier les mots de passe.

Erreurs fréquentes avec Volatility 3

Tutoriels complémentaires

• Les phases de la réponse à l’incident — Le contexte procédural dans lequel s’inscrit l’analyse mémoire
• Analyse forensique avec Autopsy et Sleuth Kit — Complémentaire à l’analyse mémoire : investigation du disque du même système
• TheHive et MISP — Documenter les IoCs extraits (IPs C2, hashes malware) et les partager via MISP

FAQ

Q : Quelle est la différence entre windows.pslist et windows.psscan ?
R : windows.pslist parcourt la liste doublement chaînée des processus dans le kernel Windows (EPROCESS list). Un rootkit peut se dissimuler en déliant son processus de cette liste (DKOM — Direct Kernel Object Manipulation). windows.psscan effectue un scan brut de la mémoire à la recherche de structures EPROCESS, indépendamment des listes du kernel — il détecte les processus cachés par DKOM. Utiliser les deux en parallèle et comparer les résultats : tout processus dans psscan mais absent de pslist est un signe fort de rootkit.

Q : Peut-on analyser des dumps mémoire de machines virtuelles (VMware, VirtualBox) ?
R : Oui. VMware crée des fichiers .vmem (mémoire brute) et .vmsn (snapshot) accessibles directement. VirtualBox produit des .sav files. Volatility 3 supporte ces formats nativement. Les snapshots de VM sont particulièrement précieux pour la forensique car ils capturent l’état complet du système à un instant précis sans nécessiter un outil d’acquisition séparé.

Q : Volatility 3 peut-il analyser la mémoire d’un Mac Apple Silicon (M1/M2/M3) ?
R : Le support macOS arm64 (Apple Silicon) est en cours de développement dans Volatility 3 (vérifier l’état actuel sur GitHub). Pour l’architecture Intel x86_64, le support macOS est disponible avec les symboles appropriés. Les Macs Apple Silicon nécessitent des symboles spécifiques arm64 qui ne sont pas encore tous disponibles.

Références officielles

• Volatility 3 GitHub — github.com/volatilityfoundation/volatility3
• Volatility 3 Readthedocs — volatility3.readthedocs.io
• WinPmem (Velocidex) — github.com/Velocidex/WinPmem
• LiME — Linux Memory Extractor — github.com/504ensicsLabs/LiME
• SIFT Workstation SANS — sans.org/tools/sift-workstation/
• Volatility Foundation — volatilityfoundation.org
• 🔝 Retour au guide DFIR complet — Réponse aux incidents et analyse forensique numérique (DFIR)