La forensique mémoire (memory forensics) est la discipline qui permet de récupérer des preuves depuis la RAM d'un système — connexions réseau, processus cachés, clés de chiffrement, code malveillant injecté. Avec l'explosion du fileless malware qui ne laisse aucune trace sur disque, l'analyse mémoire est devenue une compétence indispensable pour tout analyste DFIR.

La forensique mémoire s'est imposée comme l'une des compétences les plus critiques en investigation numérique ces dernières années. Avec des stratégies de détection et remédiation adaptées, elle permet de détecter ce que les antivirus et les analyses disque ratent complètement. Cette discipline, qui couvre les memory forensics stratégies détection remédiation, est devenue incontournable face à l'essor du fileless malware — ces menaces qui s'exécutent entièrement en mémoire sans jamais toucher le disque dur. Un ransomware comme Kovter, un RAT comme Poweliks, ou un framework de post-exploitation comme Cobalt Strike Beacon injecté en mémoire ne laisseront aucune trace dans les artefacts disque traditionnels. La RAM est aussi le seul endroit où vous trouverez les clés de chiffrement actives, les connexions réseau établies, les processus dissimulés par un rootkit, le contenu des sessions utilisateur, et parfois même les mots de passe en clair grâce à des outils comme Mimikatz. Ce guide couvre l'ensemble de la chaîne : acquisition mémoire, installation et maîtrise de Volatility 3, plugins essentiels, détection de techniques d'injection avancées, et automatisation de l'analyse pour les environnements à fort volume d'incidents.

À retenir

  • Acquisition en premier : toujours dumper la RAM avant toute autre action — chaque commande modifie la mémoire et détruit des preuves.
  • Volatility 3 : plus de symbol tables à compiler manuellement, la détection automatique de l'OS simplifie le workflow.
  • windows.malfind : plugin clé pour détecter les injections de code (sections MZ en mémoire non-mappée, protections RWX).
  • Fileless malware : invisible sur disque, mais toujours présent en RAM — la forensique mémoire est le seul vecteur de détection fiable.
  • Corrélation disque+mémoire : combiner Volatility avec les artefacts disque (Event Logs, Prefetch) donne une image forensique complète.

Acquisition mémoire : les outils et méthodes selon l'environnement

Sur les investigations que je mène, l'acquisition mémoire est toujours la première action sur un système live. Avant même de lancer quoi que ce soit d'autre. Chaque commande PowerShell, chaque ouverture de Task Manager, chaque accès réseau modifie la RAM et peut écraser des artefacts critiques. La règle d'or : dump mémoire en premier, tout le reste ensuite.

WinPmem — Windows

WinPmem est l'outil d'acquisition mémoire de référence pour Windows. Open source, léger, il installe temporairement un driver noyau pour accéder à la mémoire physique, puis le supprime après l'acquisition.

# Acquisition mémoire basique
winpmem_mini_x64_rc2.exe memdump.raw

# Acquisition avec verbosité pour vérification
winpmem_mini_x64_rc2.exe -v memdump.raw

# Hash immédiat après acquisition (critical pour chain of custody)
certutil -hashfile memdump.raw MD5
certutil -hashfile memdump.raw SHA256

# Copier vers serveur forensique (si réseau disponible)
# Attention: la copie réseau génère du trafic documenté
robocopy C:\temp\ \\forensic-server\cases\CASE-001\ memdump.raw /LOG:C:\temp\copy.log

DumpIt — Alternative Windows

# DumpIt crée automatiquement un fichier nommé [hostname]_[date]_[heure].raw
DumpIt.exe

# DumpIt avec format spécifique
DumpIt.exe /OUTPUT C:\evidence\memdump.raw /FORMAT RAW

# DumpIt silencieux (pour scripts)
DumpIt.exe /Q /OUTPUT C:\evidence\memdump.raw

LiME — Linux Memory Extraction

# Compiler LiME pour le kernel exact du système cible
# (à faire sur machine de compilation avec même version kernel)
apt-get install linux-headers-$(uname -r)
git clone https://github.com/504ensicsLabs/LiME
cd LiME/src && make

# Charger le module et dumper en fichier local
sudo insmod lime.ko "path=/tmp/mem_$(hostname)_$(date +%Y%m%d_%H%M%S).lime format=lime"

# Dumper directement via réseau (préférable pour préserver intégrité)
# Sur le système cible:
sudo insmod lime.ko "path=tcp:4444 format=lime"
# Sur la station d'analyse:
nc [IP_cible] 4444 > memdump.lime

# Vérification d'intégrité
sha256sum /tmp/memdump.lime > /tmp/memdump.lime.sha256

VMware VMEM — Environnements virtualisés

Sur les environnements VMware, la méthode la plus propre est de créer un snapshot de la VM — cela génère un fichier .vmem contenant la mémoire RAM complète au moment du snapshot, sans aucun agent à installer sur la machine cible. Le fichier .vmsn (VMware Snapshot) et le .vmem ensemble constituent un dump mémoire analysable directement par Volatility.

Installation et configuration de Volatility 3

Volatility 3 représente une réécriture complète de Volatility 2 avec une architecture modulaire et une suppression des problèmes chroniques de symbol tables. Je recommande systématiquement Volatility 3 pour les nouvelles investigations — le workflow est nettement plus fluide.

# Installation via pip (Python 3.8+ requis)
pip install volatility3

# Ou depuis les sources pour la dernière version
git clone https://github.com/volatilityfoundation/volatility3.git
cd volatility3
pip install -e .

# Vérification de l'installation
vol --version

# Premier test sur un dump
vol -f memdump.raw windows.info

# Sur Linux, spécifier le chemin complet si nécessaire
python3 vol.py -f memdump.raw windows.info

La détection automatique du profil OS est l'une des grandes améliorations de Volatility 3 : plus besoin de spécifier manuellement le profil Windows ou Linux. windows.info détecte automatiquement la version du système, ce qui simplifie considérablement le workflow en environnement d'urgence.

# Sortie typique de windows.info
# Variable          Value
# Kernel Base       0xf8077a400000
# DTB               0x1aa000
# Symbols           ntkrnlmp.pdb/...
# Is64Bit           True
# IsPAE             False
# layer_name        WindowsIntel32e
# memory_layer      FileLayer
# KdDebuggerDataBlock  0xf8077ca3d120
# NTBuildLab        19041.1.amd64fre.vb_release...
# CSDVersion        0
# KdVersionBlock    0xf8077ca3d128
# Major/Minor       15.19041
# MachineType       34404
# KeNumberProcessors  2

Plugins Volatility 3 essentiels : le workflow complet d'une investigation

Je structure systématiquement mes analyses mémoire en trois phases : reconnaissance (comprendre le système et ses processus), détection (chercher les anomalies), et extraction (sortir les artefacts pour analyse approfondie).

Phase 1 : Reconnaissance

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

# Arbre des processus (détecter les parents suspects)
vol -f memdump.raw windows.pstree

# Arguments de ligne de commande de chaque processus
vol -f memdump.raw windows.cmdline

# Connexions réseau actives et récentes (y compris fermées)
vol -f memdump.raw windows.netscan

# DLLs chargées par chaque processus
vol -f memdump.raw windows.dlllist

# Handles ouverts (fichiers, registre, mutexes)
vol -f memdump.raw windows.handles

Phase 2 : Détection des anomalies

# Détection code injecté (sections MZ en mémoire non-mappée)
vol -f memdump.raw windows.malfind

# Comparer les processus dans EPROCESS vs PspCidTable (rootkits)
vol -f memdump.raw windows.pslist --pid 1234
vol -f memdump.raw windows.psscan  # scan brut de la mémoire physique

# Chercher les DLLs chargées hors du PATH système
vol -f memdump.raw windows.dlllist | grep -v "C:\\\\Windows\\\\"

# Analyser les threads de chaque processus
vol -f memdump.raw windows.threads

# Détecter les hooks dans le SSDT (System Service Descriptor Table)
vol -f memdump.raw windows.ssdt

Phase 3 : Extraction d'artefacts

# Extraire un processus suspect pour analyse statique
vol -f memdump.raw windows.dumpfiles --pid 4444 --output-dir ./dumps/

# Extraire la mémoire d'un processus (VAD complet)
vol -f memdump.raw windows.memmap --pid 4444 --dump

# Extraire les fichiers mappés en mémoire
vol -f memdump.raw windows.dumpfiles

# Lister les connexions réseau avec état
vol -f memdump.raw windows.netstat

Détection du fileless malware : techniques et contre-mesures

Le fileless malware est une catégorie de menaces qui s'exécutent entièrement en mémoire, sans créer de fichiers permanents sur le disque. Ces techniques sont devenues la norme pour les groupes APT et les opérateurs de ransomware sophistiqués, précisément parce qu'elles contournent les antivirus traditionnels basés sur les signatures fichiers.

Process Injection (MITRE ATT&CK T1055)

L'injection de code dans un processus légitime est la technique fileless la plus répandue. L'attaquant injecte du code malveillant dans un processus de confiance (svchost.exe, explorer.exe, notepad.exe) pour masquer son activité.

# windows.malfind détecte les régions mémoire avec:
# - Header MZ (exécutable PE)
# - Protections PAGE_EXECUTE_READWRITE (RWX)
# - Code non-mappé depuis un fichier sur disque
vol -f memdump.raw windows.malfind

# Sortie typique d'une injection détectée:
# PID    Process    Start         End           Tag  Protection     Hexdump
# 1234   svchost    0x7ff00000    0x7ff01000    VadS PAGE_EXECUTE_READWRITE
#        4d 5a 90 00 03 00 00 00  MZ......
#        ...
# → MZ header dans une région RWX non-mappée = injection confirmée

# Extraire le code injecté pour analyse IDA/Ghidra
vol -f memdump.raw windows.malfind --dump --output-dir ./injections/

Process Hollowing

Le process hollowing consiste à créer un processus légitime en état suspendu, vider son code de sa mémoire, puis y injecter du code malveillant. Le processus semblent légitime (même nom, même PID visible) mais exécute un payload différent.

Détection : comparer le PEB (Process Environment Block) qui pointe vers l'image légitime sur disque avec le contenu réel en mémoire. Une discordance entre les deux révèle un hollow.

# Comparer PEB path avec contenu mémoire réel
vol -f memdump.raw windows.pslist | grep -i notepad
vol -f memdump.raw windows.dlllist --pid [PID]
# Si notepad.exe charge des DLLs inhabituelles → suspect

# Vérifier le chemin PE en mémoire vs sur disque
vol -f memdump.raw windows.memmap --pid [PID] --dump
# Analyser le dump avec strings ou un décompilateur

Reflective DLL Injection

La Reflective DLL Injection charge une DLL directement depuis mémoire sans passer par le chargeur Windows standard. La DLL ne figure donc pas dans la liste des modules du processus (windows.dlllist ne la voit pas), mais elle est visible dans les régions mémoire VAD avec des headers PE intacts.

# Scanner les VAD pour trouver des PE non-listés dans dlllist
vol -f memdump.raw windows.vadinfo --pid [PID]
# Chercher des régions MEM_PRIVATE avec protections exécutables

# Extraire et analyser
vol -f memdump.raw windows.vadyarascan --pid [PID] --yara-rules "rule PE { strings: $mz = \"MZ\" condition: $mz at 0 }"

Comment détecter un process hollowing avec Volatility 3 ?

Le process hollowing est difficile à détecter car le processus parent légitime reste visible dans la liste des processus. La clé est de comparer les métadonnées du processus avec son contenu mémoire réel.

Voici ma méthode en 4 étapes :

  1. Identifier les processus suspects avec windows.pstree — cherchez des processus système lancés par des parents inhabituels (ex: svchost.exe enfant de explorer.exe au lieu de services.exe)
  2. Vérifier le chemin PEB avec windows.cmdline — le chemin affiché doit correspondre à l'exécutable attendu
  3. Scanner les régions VAD avec windows.vadinfo — des régions PAGE_EXECUTE_READWRITE non-mappées depuis un fichier sont suspectes
  4. Extraire et analyser le dump mémoire du processus avec windows.memmap et chercher les strings caractéristiques du payload

Si un svchost.exe génère des connexions réseau vers des IPs externes inhabituelles (windows.netscan), c'est souvent le signal d'un hollow. Croisez avec les Event Logs Windows — l'Event ID 4688 révèle le processus parent au moment de la création.

YARA scanning en mémoire : détecter des signatures connues

YARA est un langage de règles pour identifier et classifier des malwares à partir de patterns binaires ou de chaînes de caractères. Volatility 3 intègre nativement un module YARA qui peut scanner directement la mémoire vive.

# Scanner toute la mémoire avec une règle YARA
vol -f memdump.raw yarascan.YaraScan --yara-file malware_rules.yar

# Scanner uniquement les processus (plus rapide)
vol -f memdump.raw windows.processghosting
vol -f memdump.raw yarascan.YaraScan --yara-rules "rule Cobalt_Strike { strings: $beacon = {FC 48 83 E4 F0 E8} condition: $beacon }"

# Utiliser les règles YARA de repositories publics
# (Exemple: règles Elastic, Mandiant, etc.)
vol -f memdump.raw yarascan.YaraScan --yara-file elastic_endgame_yara.yar --output-dir ./yara_hits/

# Scanner avec plusieurs fichiers de règles
vol -f memdump.raw yarascan.YaraScan --yara-file rules1.yar --yara-file rules2.yar

Les dépôts de règles YARA à intégrer dans votre workflow : Yara-Rules (Github), Elastic Security YARA, Mandiant Advantage (payant), et les règles générées par des outils comme Capa ou FLOSS pour l'analyse automatique de malware.

Comment analyser un dump mémoire Linux avec Volatility 3 ?

L'analyse de mémoire Linux avec Volatility 3 suit le même principe général mais nécessite des adaptations. Les plugins Linux utilisent le préfixe linux. et requièrent les symbol tables correspondant au kernel exact.

# Identifier le système Linux en mémoire
vol -f memdump.lime banners.Banners

# Lister les processus Linux
vol -f memdump.lime linux.pslist
vol -f memdump.lime linux.pstree

# Bash history depuis la mémoire (sans accès au disque !)
vol -f memdump.lime linux.bash

# Connexions réseau
vol -f memdump.lime linux.netstat

# Modules kernel chargés (rootkits LKM)
vol -f memdump.lime linux.lsmod

# Fichiers ouverts par processus
vol -f memdump.lime linux.lsof

# Environnement des processus
vol -f memdump.lime linux.env --pid [PID]

# Détecter les rootkits (comparaison des listes de processus)
vol -f memdump.lime linux.pslist > pslist_output.txt
vol -f memdump.lime linux.psscan > psscan_output.txt
diff pslist_output.txt psscan_output.txt  # Différences = processus cachés

La génération des symbol tables Linux est le point de friction principal : elles sont spécifiques au kernel exact (version + distribution + configuration de compilation). Le projet Volatility Linux Profile Builder automatise cette génération, et le dépôt officiel de Volatility Foundation propose des symbols pour les distributions courantes.

Script Python d'automatisation de l'analyse mémoire

Pour les environnements à volume élevé d'incidents, l'automatisation est indispensable. Voici un script Python qui orchestre une analyse mémoire de base et génère un rapport JSON structuré.

#!/usr/bin/env python3
# script: auto_memory_analysis.py
# usage: python3 auto_memory_analysis.py --dump memdump.raw --output /cases/CASE-001/

import subprocess, json, os, sys, hashlib, argparse
from datetime import datetime

def run_plugin(vol_path, dump, plugin, extra_args=[]):
    # Exécute un plugin Volatility 3 et retourne la sortie
    cmd = [vol_path, "-f", dump, plugin] + extra_args
    result = subprocess.run(cmd, capture_output=True, text=True, timeout=300)
    return result.stdout

def calculate_hash(filepath):
    # Calcule SHA256 d'un fichier
    h = hashlib.sha256()
    with open(filepath, 'rb') as f:
        for chunk in iter(lambda: f.read(65536), b''):
            h.update(chunk)
    return h.hexdigest()

def main():
    parser = argparse.ArgumentParser()
    parser.add_argument('--dump', required=True)
    parser.add_argument('--output', required=True)
    parser.add_argument('--vol', default='vol')
    args = parser.parse_args()

    os.makedirs(args.output, exist_ok=True)

    report = {
        "case_id": os.path.basename(args.output),
        "analysis_date": datetime.utcnow().isoformat(),
        "dump_file": args.dump,
        "dump_sha256": calculate_hash(args.dump),
        "findings": {}
    }

    # 1. Informations système
    print("[*] Collecting system info...")
    report["findings"]["system_info"] = run_plugin(args.vol, args.dump, "windows.info")

    # 2. Processus
    print("[*] Listing processes...")
    report["findings"]["pslist"] = run_plugin(args.vol, args.dump, "windows.pslist")
    report["findings"]["pstree"] = run_plugin(args.vol, args.dump, "windows.pstree")
    report["findings"]["cmdline"] = run_plugin(args.vol, args.dump, "windows.cmdline")

    # 3. Réseau
    print("[*] Network connections...")
    report["findings"]["netscan"] = run_plugin(args.vol, args.dump, "windows.netscan")

    # 4. Détection malware
    print("[*] Running malfind...")
    report["findings"]["malfind"] = run_plugin(args.vol, args.dump, "windows.malfind")

    # Sauvegarder le rapport
    report_path = os.path.join(args.output, "memory_analysis_report.json")
    with open(report_path, 'w') as f:
        json.dump(report, f, indent=2, ensure_ascii=False)

    print(f"[+] Report saved: {report_path}")

if __name__ == "__main__":
    main()

Tableau des plugins Volatility 3 essentiels

Plugin Objectif Sortie suspecte typique Contre-mesure forensique
windows.pslist Liste les processus depuis EPROCESS Processus système avec parent inhabituel Comparer avec windows.psscan
windows.psscan Scan brut de la mémoire physique Processus présents dans psscan mais pas pslist = rootkit Différentiel entre les deux listes
windows.malfind Régions mémoire avec PE + protections RWX MZ header dans région non-mappée Dump + analyse statique du PE
windows.netscan Connexions TCP/UDP actives et fermées Connexion depuis svchost vers IP externe port 443/80/8080 Blacklist IP + corrélation DNS
windows.cmdline Arguments de ligne de commande PowerShell -enc [base64] ou cmd /c wscript Décoder base64, analyser payload
windows.dlllist DLLs chargées par processus DLL hors C:\Windows, DLL sans chemin sur disque Vérifier existence et hash de la DLL
windows.handles Handles ouverts (fichiers, mutex, registre) Handle sur Named Pipe inhabituel Identifier le Named Pipe du C2
yarascan Scan YARA en mémoire Signature Cobalt Strike Beacon, Metasploit shellcode Dump région + analyse IOC

Pour approfondir les techniques d'analyse sur Windows Server, consultez notre article sur la forensique Windows Server 2025 qui couvre les spécificités des environnements serveur. Pour les outils DFIR et les comparatifs, voir aussi notre comparatif des outils DFIR.

Intégration avec l'analyse disque : une approche DFIR complète

La forensique mémoire ne doit jamais être menée en isolation. Son vrai pouvoir émerge quand on la corrèle avec les artefacts disque. Un processus détecté comme suspect par windows.malfind doit être corrélé avec :

  • Son entrée dans l'AmCache ou le ShimCache — pour confirmer depuis quand le binaire est présent sur le système
  • Les Event Logs 4688 — pour identifier le processus parent et les arguments de création
  • Le Prefetch — pour connaître le nombre d'exécutions et les fichiers accédés
  • Le $UsnJrnl — pour retrouver la date de création du fichier malveillant et le confirmer même s'il a été supprimé

Cette approche croisée est documentée dans les référentiels de forensique de la Volatility Foundation et dans le cadre MITRE ATT&CK pour la technique T1055 Process Injection. La méthodologie NIST SP 800-86 disponible sur csrc.nist.gov formalise ce processus d'intégration.

Pour la forensique complète sur système Windows, consultez notre guide expert Windows Forensics et pour l'analyse des processus d'évasion, notre article sur l'anti-forensique et l'évasion.

FAQ forensique mémoire

Quelle différence entre Volatility 2 et Volatility 3 ?

Volatility 2 repose sur des profiles — des fichiers Python qui définissent les structures de données du kernel pour chaque version de Windows ou Linux. Ces profiles doivent être générés ou téléchargés séparément, et leur gestion est fastidieuse. Volatility 3 abandonne ce concept au profit des symbol tables ISF (Intermediate Symbol Format) générées automatiquement depuis les fichiers PDB Microsoft, téléchargées à la demande. En pratique : Volatility 3 démarre une analyse en 30 secondes là où Volatility 2 nécessitait parfois plusieurs heures de configuration. L'API Python de Volatility 3 est aussi nettement plus propre pour l'automatisation. Le seul cas d'usage de Volatility 2 restant : des systèmes anciens (XP, Server 2003) pour lesquels les symbol tables Volatility 3 ne sont pas encore disponibles.

Comment acquérir la mémoire RAM d'un serveur Windows en production sans redémarrage ?

WinPmem ou DumpIt sont les outils recommandés car ils minimisent l'impact sur le système en production. L'acquisition prend environ 1 minute par gigaoctet de RAM. Points critiques : (1) planifier pendant une fenêtre de faible charge pour minimiser l'impact sur les performances — l'acquisition monopolise le bus mémoire ; (2) vérifier l'espace disque disponible en avance (fichier dump = taille de la RAM) ; (3) ne JAMAIS utiliser la commande NotMyFault ou forcer un crash dump Windows en production — cela provoque un redémarrage non planifié. Pour les hyperviseurs VMware, préférez le snapshot VM qui est non-intrusif et ne nécessite pas d'agent sur le guest.

Qu'est-ce que le fileless malware et comment le détecter en mémoire ?

Le fileless malware est un malware qui ne crée pas de fichiers persistants sur le disque pour éviter la détection par les antivirus. Les techniques courantes incluent : exécution via PowerShell (payload encodé en base64), injection dans des processus existants (svchost, explorer), utilisation de WMI pour la persistance, exécution depuis des macros Office en mémoire. La détection passe exclusivement par l'analyse mémoire : windows.malfind pour les injections, windows.cmdline pour les commandes PowerShell suspectes, windows.netscan pour les connexions réseau depuis des processus inhabituels. Aucune analyse disque seule ne peut détecter un fileless malware qui n'a jamais touché le disque.

Quand utiliser YARA dans une investigation mémoire ?

YARA en mémoire est particulièrement efficace dans trois scénarios : (1) vous disposez d'un IOC (indicateur de compromission) spécifique — hash, chaîne de code, pattern réseau — et voulez confirmer sa présence sur d'autres systèmes rapidement ; (2) vous analysez une famille de malware connue pour laquelle des règles YARA existent déjà dans des dépôts publics ; (3) vous voulez scanner plusieurs dizaines de dumps mémoire de façon automatisée sans analyser chaque dump manuellement. Pour les investigations sur des malwares inconnus, commencez par windows.malfind et l'analyse manuelle avant de développer des règles YARA spécifiques.

Investigation mémoire urgente ou formation de vos équipes DFIR ?

Ayi NEDJIMI intervient sur les incidents nécessitant une analyse mémoire avancée — fileless malware, APT, ransomware à double extorsion. Nous proposons également des formations pratiques Volatility 3 et forensique mémoire pour les équipes SOC et DFIR.

Contacter pour une investigation