Forensique Mémoire : Guide Pratique Volatility 3 en 2026

La forensique mémoire volatility 3 guide pratique est devenue indispensable pour tout analyste DFIR en 2026. Face aux malwares fileless qui ne touchent jamais le disque, face aux attaquants qui effacent leurs artefacts à la minute près, l'analyse de la mémoire RAM est souvent le seul moyen de reconstruire fidèlement une attaque. Volatility 3, réécrit de zéro par rapport à Volatility 2 par la Volatility Foundation, apporte une architecture de plugins modulaire, une meilleure gestion des symbol tables avec téléchargement automatique, et un support étendu des systèmes Linux et macOS en plus de Windows. J'utilise Volatility 3 sur pratiquement toutes mes investigations d'incident response sérieuses depuis sa stabilisation en 2021. La courbe d'apprentissage est réelle, mais une fois maîtrisé, c'est un outil qui révèle des artefacts invisibles partout ailleurs : shellcode injecté dans des processus légitimes, connexions réseau depuis des processus orphelins, hooks kernel d'un rootkit, ou historique de commandes effacé mais toujours en mémoire. Ce guide pratique vous donne la méthode terrain, les plugins dans l'ordre, et un cas pratique Cobalt Strike pour ancrer les connaissances.

Volatility 3 vs Volatility 2 : pourquoi migrer en 2026 ?

La question revient souvent lors de mes formations forensiques : faut-il encore apprendre Volatility 2 ? Ma réponse est non. Volatility 3 est la version active, maintenue et qui reçoit les nouveaux plugins. Volatility 2 est en fin de vie, ne supporte plus Python 3, et ses symbol tables (profiles) pour les systèmes modernes (Windows 11, Ubuntu 24.04, macOS Ventura/Sonoma) sont soit inexistantes soit non maintenues par la communauté.

Les différences architecturales sont profondes. Dans Volatility 2, les profiles contenaient à la fois les informations de type (structures internes du noyau) et les informations de virtualisation. Dans Volatility 3, ces deux concepts sont séparés : les symbol tables (fichiers .json.xz) contiennent uniquement les types du noyau, et le framework gère lui-même la traduction d'adresses virtuelles. Résultat : Volatility 3 est plus rapide, ses erreurs sont plus compréhensibles, et l'ajout de support pour un nouveau kernel est plus simple.

• Python 3 natif (Volatility 2 nécessitait Python 2.x)
• Symbol tables téléchargées automatiquement depuis les serveurs de la Volatility Foundation
• Interface CLI simplifiée : vol -f dump.raw windows.pslist
• Architecture plugin modulaire : chaque plugin est un module Python indépendant
• Meilleur support Linux avec ISF (Intermediate Symbol File) généré depuis DWARF

Installation Volatility 3 et configuration des symbol tables

L'installation de Volatility 3 est simple. La méthode recommandée pour les investigations est de cloner le dépôt GitHub plutôt que d'utiliser pip, pour toujours avoir accès aux derniers plugins. Les symbol tables Windows sont la partie qui demande le plus d'attention selon votre contexte (air-gapped ou non).

# Installation depuis GitHub (méthode recommandée pour investigations)
git clone https://github.com/volatilityfoundation/volatility3.git
cd volatility3
pip install -e .

# Vérifier l'installation
vol --version
# Devrait afficher : Volatility 3 Framework x.x.x

# Alternative via pip (plus simple, mais version potentiellement moins récente)
pip install volatility3

# Symbol tables Windows - téléchargement automatique si Internet disponible
# Volatility 3 télécharge le bon symbol table en fonction du kernel du dump
# Elles sont cachées dans : ~/.local/lib/python3.x/site-packages/volatility3/symbols/

# Pour environnements air-gapped : télécharger les symbol tables manuellement
# Depuis https://downloads.volatilityfoundation.org/volatility3/symbols/
# Placer les fichiers windows.zip ou linux.zip dans :
mkdir -p /opt/volatility3/volatility3/symbols/
# Extraire le zip dans ce répertoire - la structure de dossiers doit être respectée

Un point de vigilance : les symbol tables Windows correspondent aux versions exactes du noyau (GUID du PDB). Si vous analysez un dump de Windows 10 21H2 build 19044.1826, Volatility 3 cherchera la symbol table correspondant à ce GUID précis. Si elle n'est pas disponible en ligne et que vous n'avez pas téléchargé le bon fichier, vous obtiendrez une erreur NoSymbolsException. La solution : la commande windows.info affiche le GUID exact dont vous avez besoin pour télécharger la bonne table.

Acquisition mémoire : WinPMem, LiME et chaîne de custody

Avant d'analyser, il faut acquérir. L'acquisition mémoire sur un système live est une opération délicate qui modifie inévitablement la RAM par le simple fait de l'écriture du dump. L'ordre de volatilité des preuves numériques (RFC 3227) recommande de capturer la mémoire en tout premier, avant tout autre artefact, car c'est la source la plus volatile.

# Acquisition Windows avec WinPMem (outil libre de la Volatility Foundation)
# Exécuter en tant qu'Administrator
winpmem_mini_x64_rc2.exe memdump.raw

# Hasher immédiatement le dump pour la chaîne de custody
# MD5 + SHA256 : les deux sont requis pour la recevabilité judiciaire
certutil -hashfile memdump.raw MD5
certutil -hashfile memdump.raw SHA256

# Sauvegarder les hashes dans un fichier signé (chaîne de custody)
echo "ACQUISITION: $(hostname) $(date)" > custody_chain.txt
echo "FICHIER: memdump.raw" >> custody_chain.txt
certutil -hashfile memdump.raw MD5 >> custody_chain.txt
certutil -hashfile memdump.raw SHA256 >> custody_chain.txt

# Acquisition Linux avec LiME (Linux Memory Extractor)
# Compiler le module kernel pour la version exacte du kernel cible
git clone https://github.com/504ensicsLabs/LiME
cd LiME/src
make
# Insérer le module pour créer le dump
sudo insmod lime-$(uname -r).ko "path=/tmp/linuxmem.lime format=lime"

# Hasher le dump Linux
md5sum /tmp/linuxmem.lime
sha256sum /tmp/linuxmem.lime

Identifier le système cible avec windows.info

La première commande à exécuter sur tout dump mémoire est windows.info. Elle identifie la version exacte du système d'exploitation, la structure du noyau, et les informations de base nécessaires pour confirmer que Volatility 3 a chargé les bonnes symbol tables.

# Identifier le système d'exploitation du dump
vol -f memdump.raw windows.info

# Output typique :
# Variable                    Value
# Kernel Base                 0xf80000000000
# DTB                         0x1aa000
# Symbols                     file:///opt/volatility3/.../windows/ntkrnlmp.pdb/...
# Is64Bit                     True
# IsPAE                       False
# layer_name                  0 WindowsIntelAMD64
# memory_layer                1 FileLayer
# KdVersionBlock              0xf80003c31398
# Major/Minor                 15.19041
# MachineType                 34404
# KeNumberProcessors          4
# SystemTime                  2026-01-15 14:23:11
# NtSystemRoot                C:\Windows
# NtProductType               NtProductWinNt
# NtMajorVersion              10
# NtMinorVersion              0
# PE MajorOperatingSystemVersion  10
# PE MinorOperatingSystemVersion  0
# PE Machine                  34404
# PE TimeDateStamp            Mon Oct 12 15:22:31 2020

# Pour Linux - informations du kernel
vol -f linuxmem.lime linux.banner.Banner

Analyse des processus : pslist, pstree, psscan et processus masqués

L'analyse des processus est le cœur de toute investigation mémoire. Volatility 3 propose plusieurs plugins complémentaires qui doivent tous être exécutés : les attaquants avancés masquent leurs processus en manipulant les structures internes du kernel, et la comparaison entre plugins révèle ces tentatives de dissimulation.

# Liste des processus via la liste doublement chaînée du kernel (EPROCESS)
vol -f memdump.raw windows.pslist
# Colonnes : PID, PPID, ImageFileName, Offset, Threads, Handles, SessionId, Wow64, CreateTime, ExitTime

# Arbre de processus (visualiser les relations parent/enfant)
# Clé pour détecter les processus orphelins ou avec PPID anormal
vol -f memdump.raw windows.pstree

# Scan par signature (indépendant de la liste chaînée du kernel)
# Détecte les processus masqués par un rootkit qui modifie la liste EPROCESS
vol -f memdump.raw windows.psscan

# Lignes de commande complètes (arguments des processus)
# Révèle les PowerShell avec encodage base64, les arguments suspects
vol -f memdump.raw windows.cmdline

# Comparer pslist vs psscan pour détecter les processus masqués
# Un processus présent dans psscan mais absent de pslist = rootkit suspect
vol -f memdump.raw windows.pslist > pslist.txt
vol -f memdump.raw windows.psscan > psscan.txt
diff pslist.txt psscan.txt | grep "^>" | awk '{print $2}' > hidden_pids.txt

Les indicateurs de compromission à chercher dans la liste des processus incluent : des processus svchost.exe sans parent services.exe, un explorer.exe avec un PPID inhabituel (il doit être enfant d'userinit.exe), des processus système (lsass.exe, csrss.exe) avec des chemins d'exécution différents de C:\Windows\System32\, et des processus dont le nom imite des processus légitimes (svchost.exe écrit svchosl.exe, lsass.exe imité en Isass.exe avec un I majuscule).

Analyse réseau : netscan et connexions C2

Le plugin windows.netscan est l'un des plus précieux pour la détection de compromission. Il extrait directement de la mémoire les structures de connexions réseau (TCP, UDP) avec leur état, les adresses IP locales et distantes, les ports, et le PID du processus propriétaire. Contrairement à netstat exécuté sur le système live, netscan sur un dump mémoire montre les connexions dans leur état exact au moment de la capture — y compris des connexions déjà fermées (état CLOSED) encore présentes en mémoire.

# Toutes les connexions réseau (actives, fermées, en écoute)
vol -f memdump.raw windows.netscan

# Filtrer uniquement les connexions ESTABLISHED (actives)
vol -f memdump.raw windows.netscan | grep "ESTABLISHED"

# Filtrer par PID suspect (par exemple PID 1234 identifié comme suspect)
vol -f memdump.raw windows.netscan | grep "1234"

# Chercher les connexions depuis des processus système inhabituels
# explorer.exe ne devrait pas avoir de connexions réseau sortantes
vol -f memdump.raw windows.netscan | grep "explorer.exe"

# Connexions Linux
vol -f linuxmem.lime linux.netstat.Netstat

Les connexions suspectes typiques en 2026 : Cobalt Strike utilise souvent HTTPS (port 443) vers des IP sans correspondance DNS valide ou vers des domaines Domain Generation Algorithm (DGA). Meterpreter peut utiliser des ports non-standards ou du reverse HTTP(S). Emotet communique avec de multiples IPs en séquence rapide sur des ports variables. Dans tous les cas, une connexion ESTABLISHED depuis explorer.exe, notepad.exe ou tout processus qui n'a aucune raison légitime d'accéder au réseau est un red flag immédiat.

Détection de code malveillant avec malfind

Le plugin windows.malfind est le premier plugin à lancer sur tout dump suspect. Il scanne toutes les régions mémoire de chaque processus à la recherche de sections présentant des caractéristiques anormales : permissions RWX (Read-Write-Execute) combinées à un header MZ ou à du code assembleur en début de région. Ces caractéristiques correspondent exactement à ce que produit une injection de code classique (DLL injection, process hollowing, shellcode injection).

# Scanner les sections mémoire suspectes (RWX + header MZ ou code)
# Premier plugin à lancer sur tout dump mémoire suspect
vol -f memdump.raw windows.malfind

# Dumper le code injecté sur disque pour analyse approfondie
# Les fichiers sont sauvés dans le répertoire courant avec nommage automatique
vol -f memdump.raw windows.malfind --dump

# Les fichiers dumpés peuvent être analysés avec :
# - YARA (règles de détection signature)
# - VirusTotal (upload des fichiers dumpés)
# - IDA Pro / Ghidra (reverse engineering)
# - strings (extraction des chaînes de caractères)

# Analyser les strings d'un payload dumpé
strings -n 10 pid.1234.0x7ff00000.dmp | grep -E "(http|\\cmd|\\powershell|beacon)"

# Scanner les fichiers dumpés avec YARA
yara /opt/yara-rules/cobaltstrike.yar pid.1234.0x7ff00000.dmp

Interprétation des résultats de malfind : la présence d'un header MZ (4D 5A en hex) en début de région mémoire non-mappée signifie qu'un exécutable complet a été injecté dans ce processus. La présence de code assembleur x86/x64 sans header MZ (shellcode pur) est également suspecte. Volatility 3 affiche les 16 premiers octets en hexadécimal et leur interprétation en assembleur, ce qui permet une première évaluation rapide sans décompiler le payload entier.

Comment analyser un dump mémoire infecté par Cobalt Strike ?

Cobalt Strike est le framework de post-exploitation le plus utilisé par les attaquants avancés en 2026. Son beacon (l'implant) laisse des traces caractéristiques en mémoire que Volatility 3 permet de détecter et d'extraire. Voici la procédure complète que j'applique sur les incidents impliquant Cobalt Strike.

# Étape 1 : identifier le processus hôte du beacon
# Cobalt Strike injecte typiquement dans explorer.exe, svchost.exe, ou un processus métier
vol -f memdump.raw windows.pstree
# Chercher : explorer.exe avec des connexions réseau (anormal)
# OU : processus avec PPID incorrect (processus légitime spawné depuis un parent anormal)

# Étape 2 : confirmer la connexion C2
vol -f memdump.raw windows.netscan | grep "ESTABLISHED"
# Cobalt Strike : souvent HTTPS port 443 vers IP étrangère, DNS peu connu
# Ou port 50050 (default team server, rarement exposé directement)

# Étape 3 : détecter le shellcode via malfind
vol -f memdump.raw windows.malfind --pid 1234
# Chercher les régions RWX contenant du code dans le processus suspecté

# Étape 4 : analyser les DLLs chargées (beacon.dll = Cobalt Strike DLL artifact)
vol -f memdump.raw windows.dlllist --pid 1234
# Chercher des DLLs sans chemin sur disque ou avec chemins inhabituels

# Étape 5 : extraire les arguments de ligne de commande
vol -f memdump.raw windows.cmdline --pid 1234
# Cobalt Strike peut lancer des PowerShell avec des arguments base64 encodés

# Étape 6 : clé de déchiffrement Cobalt Strike en mémoire
# Le beacon Cobalt Strike stocke sa clé RSA en mémoire
# Plugin communautaire : volatility3-plugins/cobaltstrikeconfig.py
vol -f memdump.raw -p /path/to/community/plugins cobaltstrikeconfig
# Révèle : C2 IP, C2 port, user-agent HTTP beacon, sleep interval, jitter

Analyse des handles, registry et DLLs

Au-delà des processus et du réseau, l'analyse des handles ouverts, des clés de registre en mémoire et des DLLs chargées complète le tableau forensique. Ces éléments révèlent la persistance mise en place, les ressources utilisées et les artefacts qui seraient effacés sur disque mais subsistent en mémoire.

# Handles ouverts par un processus (fichiers, clés registre, mutexes, threads...)
vol -f memdump.raw windows.handles --pid 1234
# Chercher : handles sur des fichiers temporaires, des pipes nommés suspects

# DLLs chargées par un processus
vol -f memdump.raw windows.dlllist --pid 1234
# Chercher : DLLs sans Base Address sur disque (reflective DLL injection)

# Lister les hives de registre chargés en mémoire
vol -f memdump.raw windows.registry.hivelist

# Lire la clé Run (mécanismes de persistance communs)
vol -f memdump.raw windows.registry.printkey     --key "SOFTWARE\Microsoft\Windows\CurrentVersion\Run"

# Lire des valeurs spécifiques (par exemple rechercher des payloads en registry)
vol -f memdump.raw windows.registry.printkey     --key "SOFTWARE\Classes\ms-settings\shell\open\command"
# (COM hijacking / UAC bypass technique)

# Analyser les services enregistrés
vol -f memdump.raw windows.svcscan
# Chercher : services avec binpath non-standard ou description vide

Analyse Linux avec Volatility 3

Volatility 3 supporte les dumps mémoire Linux avec un ensemble de plugins dédiés. La particularité Linux est que les symbol tables doivent être générées localement depuis les informations de debug du kernel (DWARF), car il n'existe pas de serveur centralisé équivalent à celui de Microsoft pour les kernels Linux. L'outil dwarf2json fourni par la Volatility Foundation automatise cette génération.

# Générer une symbol table Linux avec dwarf2json
# Sur une machine avec le même kernel que le système analysé :
git clone https://github.com/volatilityfoundation/dwarf2json
cd dwarf2json && go build .
./dwarf2json linux --elf /usr/lib/debug/boot/vmlinux-$(uname -r) > linux_symbols.json
xz linux_symbols.json
# Placer le fichier linux_symbols.json.xz dans :
# /opt/volatility3/volatility3/symbols/linux/

# Analyse Linux - informations du kernel
vol -f linuxmem.lime linux.banner.Banner

# Liste des processus Linux
vol -f linuxmem.lime linux.pslist.PsList

# Modules kernel chargés (détecter des rootkits LKM)
vol -f linuxmem.lime linux.lsmod.Lsmod
# Chercher des modules non présents dans /proc/modules sur le système live
# (écart = module masqué par rootkit)

# Historique bash en mémoire (sessions actives au moment du dump)
vol -f linuxmem.lime linux.bash.Bash

# Connexions réseau Linux
vol -f linuxmem.lime linux.netstat.Netstat

# Malfind Linux (code injecté)
vol -f linuxmem.lime linux.malfind.Malfind

Script Python d'automatisation d'investigation

Pour les investigations récurrentes, automatiser la collecte des résultats des plugins principaux dans un rapport structuré fait gagner un temps précieux. Le script suivant exécute les plugins essentiels et génère un rapport JSON utilisable pour documentation ou intégration dans un ticket d'incident.

#!/usr/bin/env python3
# Script d'automatisation d'analyse Volatility 3
# Génère un rapport JSON avec les résultats des plugins essentiels
# Usage : python3 vol3_auto.py <dumpfile>
import subprocess
import json
import sys
import hashlib
from datetime import datetime

def run_vol_plugin(dumpfile, plugin, extra_args=""):
    # Exécute un plugin Volatility 3 et retourne la sortie brute
    cmd = f"vol -f {dumpfile} {plugin} {extra_args}"
    result = subprocess.run(cmd, shell=True, capture_output=True, text=True, timeout=300)
    if result.returncode != 0 and result.stderr:
        return f"ERREUR: {result.stderr[:500]}"
    return result.stdout

def hash_file(filepath, algo="sha256"):
    # Calcule le hash d'un fichier pour la chaîne de custody
    h = hashlib.new(algo)
    with open(filepath, 'rb') as f:
        for chunk in iter(lambda: f.read(65536), b''):
            h.update(chunk)
    return h.hexdigest()

def analyze_dump(dumpfile):
    # Analyse complète d'un dump mémoire Windows avec les plugins essentiels
    report = {
        "timestamp": datetime.now().isoformat(),
        "analyst": "DFIR Investigation",
        "dumpfile": dumpfile,
        "integrity": {
            "md5": hash_file(dumpfile, "md5"),
            "sha256": hash_file(dumpfile, "sha256")
        },
        "analysis": {}
    }

    # Pipeline d'analyse standard
    plugins = [
        ("sysinfo", "windows.info"),
        ("pslist", "windows.pslist"),
        ("pstree", "windows.pstree"),
        ("cmdline", "windows.cmdline"),
        ("netscan", "windows.netscan"),
        ("malfind", "windows.malfind"),
        ("svcscan", "windows.svcscan"),
        ("hivelist", "windows.registry.hivelist"),
    ]

    for name, plugin in plugins:
        print(f"  [*] Exécution : {plugin}")
        report["analysis"][name] = run_vol_plugin(dumpfile, plugin)

    return report

if __name__ == "__main__":
    if len(sys.argv) < 2:
        print("Usage: python3 vol3_auto.py ")
        sys.exit(1)

    dumpfile = sys.argv[1]
    print(f"[+] Analyse de : {dumpfile}")

    report = analyze_dump(dumpfile)

    # Sauvegarder le rapport JSON horodaté
    report_file = f"vol3_report_{datetime.now().strftime('%Y%m%d_%H%M%S')}.json"
    with open(report_file, 'w', encoding='utf-8') as f:
        json.dump(report, f, indent=2, ensure_ascii=False)
    print(f"[+] Rapport sauvegardé : {report_file}")

Quelle est la différence entre windows.malfind et windows.psscan ?

Ces deux plugins servent des objectifs complémentaires mais distincts dans la détection de compromission mémoire. Comprendre la différence permet de ne pas manquer de vecteur d'attaque lors de l'investigation.

windows.malfind scanne le contenu des régions mémoire de chaque processus pour détecter du code injecté. Il cherche spécifiquement les combinaisons de permissions RWX (exécutable en écriture) avec un début de région contenant un header MZ ou du code assembleur. Il est efficace pour détecter : la DLL injection classique, le process hollowing, le shellcode injection, et les techniques Cobalt Strike. Son angle d'attaque est le contenu mémoire.

windows.psscan, à l'inverse, ne s'intéresse pas au contenu des processus mais à leur existence. Il scanne toute la mémoire physique à la recherche de signatures de structures EPROCESS (le bloc de contrôle de processus Windows), indépendamment de la liste doublement chaînée que windows.pslist parcourt. Cette approche indépendante de la liste permet de détecter les processus masqués par des rootkits qui manipulent la liste EPROCESS en mémoire (DKOM - Direct Kernel Object Manipulation). La comparaison pslist/psscan est une étape obligatoire dans toute investigation avancée.

• Détecté par malfind uniquement : injection de code dans un processus légitime visible
• Détecté par psscan uniquement : processus masqué par rootkit DKOM
• Détecté par les deux : processus malveillant ayant injecté du code ET étant lui-même masqué

Tableau des plugins Volatility 3 essentiels

Ressources et écosystème Volatility 3

La forensique mémoire avec Volatility 3 s'inscrit dans un écosystème plus large. Le site officiel volatilityfoundation.org maintient la documentation, les symbol tables et le dépôt de plugins communautaires. Le dépôt GitHub officiel reçoit les mises à jour régulières et les issues tracker des bugs. Pour les techniques d'injection en mémoire que malfind détecte, la référence MITRE ATT&CK est T1055 — Process Injection. Pour la méthodologie forensique complète incluant la chaîne de custody et les bonnes pratiques, le NIST SP 800-86 (Guide to Integrating Forensic Techniques into Incident Response) est la référence institutionnelle.

Pour compléter votre pratique de la forensique mémoire, notre guide Memory Forensics détection et remédiation couvre les cas d'usage de remédiation post-investigation. Pour les techniques anti-forensics que les attaquants utilisent pour contourner vos investigations mémoire, l'article Anti-Forensics Méthodologie est le complément naturel de ce guide. Les artefacts NTFS que Volatility ne voit pas (timestamps, ADS, MFT) sont couverts dans NTFS Forensics Méthodologie. Et pour le contexte Windows forensics complet, le guide Windows Forensics expert structure l'ensemble des sources de preuves à exploiter.

FAQ Volatility 3

Comment installer les symbol tables Windows pour Volatility 3 ?

Pour un environnement connecté Internet, Volatility 3 télécharge automatiquement la bonne symbol table lors de la première analyse d'un dump Windows. Les tables sont cachées localement dans ~/.local/lib/python3.x/site-packages/volatility3/symbols/. Pour un environnement air-gapped, télécharger manuellement le fichier Windows.zip ou linux.zip depuis downloads.volatilityfoundation.org/volatility3/symbols/ et extraire dans le répertoire symbols de Volatility 3. Si l'erreur NoSymbolsException persiste, exécuter windows.info et noter le GUID affiché pour identifier exactement le fichier .json.xz manquant.

Volatility 3 supporte-t-il les dumps VMware VMEM ?

Oui, Volatility 3 supporte plusieurs formats de dumps mémoire : raw (WinPMem, LiME), LIME, VMware VMEM (snapshot VMware), VMware VMSS, Hyper-V VMRS, EWF (Expert Witness Format), QEMU, et virtualbox VBox. Pour les fichiers VMEM VMware, utiliser directement vol -f snapshot.vmem windows.info. Les fichiers VMSS nécessitent parfois le fichier .vmx associé dans le même répertoire pour que Volatility puisse identifier correctement la structure mémoire.

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

Volatility 3 supporte macOS (Apple Silicon et Intel) avec des plugins dédiés. Les symbol tables macOS sont générées depuis les kernel debug kits (KDK) disponibles chez Apple Developer. Les plugins disponibles incluent mac.pslist, mac.netstat, mac.bash, et mac.malfind. L'acquisition mémoire macOS sur Apple Silicon est plus complexe en raison de Secure Boot et des protections matérielles — des outils comme osxpmem (pour Intel) ou des solutions forensiques commerciales (Magnet Forensics, Cellebrite) sont nécessaires. Sur les Mac modernes avec T2/M1/M2/M3, l'acquisition mémoire live est fortement restreinte par le firmware.

Quelle est la différence entre windows.malfind et windows.psscan ?

windows.malfind détecte du code malveillant injecté dans des processus existants en cherchant des régions mémoire avec des permissions RWX combinées à un header MZ ou du shellcode. windows.psscan, lui, détecte des processus entiers masqués au niveau du kernel via manipulation de la liste EPROCESS (technique DKOM). Malfind répond à "ce processus légitime cache-t-il du code malveillant ?" ; psscan répond à "y a-t-il des processus cachés que pslist ne voit pas ?". Les deux sont complémentaires et doivent être systématiquement exécutés ensemble.