Volatility 3 : Framework Forensics Mémoire Open Source 2026

Volatility est le framework open source de référence mondiale pour l'analyse forensique de mémoire vive (RAM forensics), maintenu depuis 2007 par la Volatility Foundation, organisation à but non lucratif basée aux États-Unis. Écrit en Python 3, Volatility 3 (sortie initiale en 2020, version stable 2.7.0 publiée en avril 2026) succède à Volatility 2.x après une réécriture totale du moteur, abandonnant le système de profils statiques au profit d'une architecture modulaire fondée sur les symbol tables (ISF — Intermediate Symbol File) et le mécanisme automagic de détection automatique du système d'exploitation analysé. Le framework prend en charge l'extraction de processus, threads, modules kernel, connexions réseau, registres Windows, hooks SSDT, injections de code, artefacts utilisateur (historique bash, command line, clipboard) et credentials hachés, à partir de captures mémoire au format raw, crash dump Microsoft, hibernation file, ELF core, LiME ou VMware snapshot. Utilisé par les équipes DFIR, les laboratoires d'expertise judiciaire numérique, les analystes malware (CERT, SOC niveau 3) et les enseignants en cybersécurité (SANS FOR508, FOR526, FOR610), Volatility 3 est devenu le standard de facto pour l'investigation post-mortem de la mémoire volatile sur Windows 7-11, Linux noyaux 2.6 à 6.x, et macOS 10.5-14. Ce guide entity-first présente exhaustivement l'architecture, les plugins majeurs, les workflows DFIR, les limites opérationnelles et les alternatives concurrentes (Rekall, MemProcFS) du framework Volatility en 2026.

Définition : qu'est-ce que Volatility ?

Volatility est un framework Python d'analyse forensique de mémoire vive (memory forensics framework) permettant l'examen post-mortem du contenu de la RAM d'un système d'exploitation Windows, Linux ou macOS. Conçu pour les enquêteurs forensiques numériques, les analystes en réponse à incident (DFIR) et les chercheurs en sécurité, il extrait des dumps mémoire des informations volatiles autrement inaccessibles : processus actifs au moment de la capture, sockets réseau ouverts, clés de registre Windows en mémoire, modules kernel chargés, payloads malveillants injectés dans des processus légitimes, hooks de fonctions système, et fragments de données utilisateur (saisies clavier, copies-collés, fichiers récents).

Le framework est maintenu par la Volatility Foundation, organisation 501(c)(3) cofondée par AAron Walters et Nick Petroni en 2007 à la suite des travaux de recherche initiaux publiés à la conférence DFRWS 2005. Volatility est distribué sous licence Volatility Software License (VSL), dérivée de la GPLv2, et son code source est hébergé sur GitHub.

Histoire de Volatility : de FATKit à Volatility 3

L'histoire de Volatility commence en 2005 avec FATKit, un prototype académique présenté par AAron Walters et Nick Petroni au Digital Forensic Research Workshop (DFRWS). En 2007, le projet devient officiellement Volatility 1.0, écrit en Python 2 et limité aux dumps Windows XP/2003.

De 2008 à 2013, la branche Volatility 2.x ajoute progressivement le support de Windows Vista/7/8, des architectures x64, des dumps Linux (via la branche LinuxMemoryForensics), puis macOS. La version 2.6 (2016) consolide la compatibilité Windows 10 1607, et la version 2.6.1 (2018) marque la dernière itération majeure de cette branche.

En 2020, la Volatility Foundation publie Volatility 3.0.0, fruit d'une réécriture totale en Python 3 lancée dès 2018. Cette refonte majeure abandonne :

• Le système de profils statiques (un profil par version d'OS, codé en dur).
• L'API monolithique de Volatility 2.
• La compatibilité Python 2 (EOL en janvier 2020).

Volatility 3 introduit l'automagic, un mécanisme d'autodétection du noyau analysé, et les ISF (Intermediate Symbol Files), fichiers JSON (anciennement zip) contenant les symboles de débogage extraits des PDB Microsoft, des modules Linux ou des dSYM macOS. La version 2.7.0 (avril 2026) ajoute le support natif de Windows 11 24H2, des noyaux Linux 6.8 et de macOS Sonoma.

Volatility 2 vs Volatility 3 : différences majeures

Bien que Volatility 2 reste fonctionnel pour les dumps anciens, son utilisation est déconseillée pour toute nouvelle investigation. Voici les différences structurelles entre les deux branches :

Architecture interne de Volatility 3

L'architecture de Volatility 3 repose sur cinq couches conceptuelles bien séparées, ce qui rend le framework extensible et testable. Comprendre cette architecture est essentiel pour développer des plugins personnalisés ou diagnostiquer des erreurs d'analyse.

Cores : couches d'abstraction mémoire

Le core (volatility3.framework) gère les abstractions de bas niveau : layers (couches de traduction d'adresses, comme la pagination x86/x64), contexts (état d'analyse), configuration (paramètres CLI), et renderers (sortie texte, JSON, CSV, sqlite).

Plugins : modules d'analyse

Chaque plugin est une classe Python héritant de PluginInterface. Les plugins sont organisés par OS dans des namespaces : windows.*, linux.*, mac.*. Un plugin déclare ses dépendances (autres plugins, requirements) et expose une méthode run().

Symbol tables : tables de symboles ISF

Les ISF (Intermediate Symbol File) sont des fichiers JSON contenant les structures C du noyau (EPROCESS, ETHREAD, task_struct, etc.) extraites depuis les PDB Microsoft (via pdbconv.py) ou les modules Linux compilés avec dwarf. Le dépôt officiel volatility3 embarque les ISF des principales versions Windows ; les ISF Linux/macOS doivent être générés sur la machine source.

Automagic : détection automatique

L'automagic est une chaîne de modules qui détectent automatiquement, à partir d'un dump brut : (1) le type d'OS, (2) la version exacte du noyau, (3) la base de la table de pages (DTB), (4) les ISF correspondants. L'utilisateur n'a plus à spécifier --profile comme en Volatility 2.

Renderers : formats de sortie

Volatility 3 supporte plusieurs formats d'export : quick (texte par défaut), pretty (texte aligné), json, jsonl, csv, et sqlite. Le format SQLite est particulièrement utile pour corréler plusieurs plugins via SQL.

Acquisition de la mémoire vive : prérequis avant Volatility

Volatility analyse des captures mémoire (memory dumps) ; il ne réalise pas l'acquisition lui-même. La qualité de l'analyse dépend directement de la fiabilité de l'acquisition. Voici les outils standards par système :

Acquisition Windows

• WinPMEM (open source, Velocidex) — driver kernel signé, mode raw ou ELF, recommandé.
• Magnet RAM Capture (gratuit, Magnet Forensics) — interface graphique, utilisé en DFIR.
• FTK Imager (gratuit, Exterro) — historiquement la référence, sortie .mem.
• DumpIt (Comae/Magnet) — exécutable portable, sortie .raw ou .dmp.
• Hibernation file (hiberfil.sys) — extractible à froid.
• Crash dump (MEMORY.DMP) — généré par BSOD ou NotMyFault.

Acquisition Linux

• LiME (Linux Memory Extractor) — module kernel, format .lime ou raw.
• AVML (Microsoft) — outil userland, sans recompilation kernel.
• fmem — module kernel exposant /dev/fmem.
• /proc/kcore — accès direct si SecureBoot/Lockdown désactivé.

Acquisition macOS

• OSXPmem (Volatility Foundation) — driver kext, déprécié post-Catalina.
• MacQuisition (BlackBag/Cellebrite) — solution commerciale.
• ARTHIR et Recon ITR — alternatives forensiques modernes.

Pour une investigation approfondie de la chaîne d'acquisition mémoire et son intégration dans un workflow DFIR, consultez notre guide complet d'analyse mémoire forensique avec Volatility.

Plugins Windows : pslist, malfind, hollowfind

Les plugins Windows constituent le cœur historique de Volatility. Ils sont préfixés windows. dans Volatility 3.

Énumération des processus

• windows.pslist — liste les processus en parcourant la liste doublement chaînée EPROCESS.ActiveProcessLinks.
• windows.pstree — affichage hiérarchique parent-enfant des processus.
• windows.psscan — scan exhaustif du pool kernel pour détecter les processus cachés (rootkits DKOM).
• windows.psxview — comparaison croisée de 7 sources d'énumération de processus.

Modules et bibliothèques chargés

• windows.dlllist — DLL chargées par chaque processus.
• windows.ldrmodules — détecte les DLL injectées via comparaison InLoadOrder/InMemoryOrder/InInitializationOrder.
• windows.modules — modules kernel chargés.
• windows.modscan — scan pool pour modules cachés.

Handles et objets

• windows.handles — handles ouverts par processus (fichiers, registres, mutex, processus).
• windows.filescan — scan des objets FILE_OBJECT.
• windows.mutantscan — mutex souvent utilisés par malware comme marqueurs uniques.

Réseau

• windows.netscan — scan exhaustif des sockets TCP/UDP, IPv4/IPv6.
• windows.netstat — équivalent moderne, plus rapide sur Windows 10/11.

Détection malware

• windows.malfind — détecte les pages mémoire suspectes (PAGE_EXECUTE_READWRITE, MZ headers en VAD privé).
• windows.hollowfind — détecte le process hollowing via comparaison VAD/PEB.
• windows.svcscan — services Windows enregistrés et leur état.
• windows.cmdline — ligne de commande exacte de chaque processus.

Pour un panorama complet des techniques d'investigation Windows, consultez notre guide expert forensics Windows.

Plugins Linux : pslist, bash, lsmod, netstat

Les plugins Linux requièrent un ISF généré spécifiquement pour le noyau analysé (dwarf2json + System.map + vmlinux).

• linux.pslist — liste des processus via task_struct.
• linux.pstree — arborescence parent-enfant.
• linux.psaux — équivalent ps aux avec arguments.
• linux.bash — historique bash extrait de la mémoire des shells actifs (très précieux en DFIR).
• linux.lsmod — modules kernel chargés.
• linux.check_modules — détecte modules cachés (rootkits LKM).
• linux.netstat — connexions réseau actives.
• linux.malfind — pages mémoire suspectes (équivalent Windows).
• linux.tty_check — détection de keyloggers TTY.
• linux.check_syscall — vérification de l'intégrité de la table d'appels système.

Plugins macOS : pslist, bash, malfind

Le support macOS est historiquement le moins développé des trois. Les plugins requièrent un ISF généré depuis kernel.dSYM.

• mac.pslist — processus actifs via proc.
• mac.pstree — arborescence des processus.
• mac.bash — historique bash/zsh.
• mac.malfind — pages exécutables anonymes suspectes.
• mac.lsmod — kexts chargés.
• mac.netstat — sockets réseau.
• mac.check_syscall — intégrité table d'appels système Darwin.
• mac.dmesg — buffer du message kernel.

Détection malware : injection, hollowing, hooks

Volatility excelle dans la détection des techniques d'évasion utilisées par les malwares modernes. Voici les techniques couvertes :

Process injection

Le plugin windows.malfind identifie les régions mémoire allouées avec les protections suspectes PAGE_EXECUTE_READWRITE (RWX) ou PAGE_EXECUTE_WRITECOPY sans backing file. Les techniques détectées incluent CreateRemoteThread, QueueUserAPC, SetWindowsHookEx, NtMapViewOfSection.

Process hollowing

Le plugin windows.hollowfind compare le contenu du VAD (Virtual Address Descriptor) avec le PEB (Process Environment Block). Une divergence — par exemple svchost.exe dont le code en mémoire ne correspond pas au binaire sur disque — signale un hollowing.

Hooks et injections de code

• windows.ssdt — vérifie les pointeurs de la System Service Descriptor Table.
• windows.callbacks — callbacks kernel suspects (PsSetCreateProcessNotifyRoutine).
• windows.driverirp — vérifie les IRP Major Functions des drivers.

Pour un cas concret d'analyse comportementale couplant Volatility et sandbox, voir notre dossier analyse dynamique de malware en sandbox.

Détection de rootkits kernel

Les rootkits kernel cherchent à dissimuler processus, connexions et fichiers en altérant les structures de données du noyau (DKOM — Direct Kernel Object Manipulation) ou en redirigeant les appels système.

• SSDT hooks (windows.ssdt) — détection de pointeurs hors du module ntoskrnl.exe.
• IDT hooks (windows.idt) — détection des entrées Interrupt Descriptor Table redirigées.
• DKOM — comparaison pslist vs psscan ; un processus présent dans psscan mais absent de pslist est suspect.
• LKM Linux rootkits (linux.check_modules, linux.check_syscall) — détection de modules masqués.
• Kexts macOS — comparaison mac.lsmod vs scan brut.

Extraction de credentials : lsadump, hashdump, cachedump

Volatility permet l'extraction des hachés de credentials depuis les ruches Windows (SAM, SYSTEM, SECURITY) reconstruites à partir de la mémoire :

• windows.hashdump — extrait les hachés NT/LM des comptes locaux (SAM).
• windows.lsadump — extrait les LSA secrets (mots de passe en clair de services, comptes machines AD).
• windows.cachedump — extrait les hachés MSCACHE v1/v2 (10 derniers logons cachés).

Ces plugins reconstituent les clés SYSKEY et BootKey à partir de la mémoire. Les hachés extraits peuvent ensuite être cassés avec hashcat ou utilisés en Pass-the-Hash. C'est un workflow classique en réponse à une kill chain ransomware.

Workflow forensics standard avec Volatility

Le workflow DFIR standard, recommandé par le SANS Institute (FOR508 et FOR526), suit quatre phases :

1. Acquisition

Capture du dump RAM avec WinPMEM/LiME/OSXPmem, hash SHA-256 immédiat, chain of custody (PV de saisie). Idéalement, l'acquisition est doublée d'une capture disque (Velociraptor ou KAPE).

2. Triage rapide

Plugins rapides pour une vue d'ensemble :

• windows.info — version OS, build, uptime.
• windows.pslist + pstree — processus et hiérarchie.
• windows.netscan — connexions externes suspectes.
• windows.cmdline — arguments de lancement.

3. Analyse approfondie

• windows.malfind + hollowfind — détection injection.
• windows.dlllist, handles — DLL et ressources.
• windows.registry.printkey — clés de registre persistance (Run, Services).
• windows.dumpfiles, memmap — extraction de payloads.

4. Reporting

Export JSON/CSV, intégration dans le rapport DFIR (Markdown, DOCX), corrélation avec les indicators of compromise (IOC) et les artefacts disque (MFT, registry hives, journaux Windows). Pour un cadrage complet du processus, consultez notre guide de réponse à incident.

Volatility vs Rekall vs MemProcFS

Volatility n'est pas seul sur le marché du memory forensics. Voici son positionnement face aux deux principales alternatives en 2026 :

Verdict 2026 : Volatility 3 reste le standard pour l'investigation post-mortem cross-platform. MemProcFS est préféré pour les analyses live (PCILeech, agents in-memory) et les très gros dumps ({'>'}64 Go). Rekall n'est plus recommandé.

Symbol tables et profils : générer ses ISF

Le passage des profils statiques aux ISF est l'innovation majeure de Volatility 3. Voici comment générer des ISF pour les systèmes non couverts par les ISF embarqués.

ISF Windows

Les ISF Windows sont générés à partir des PDB (Program Database) Microsoft téléchargés depuis le symbol server officiel :

python3 banners.py mem.raw  # extrait le GUID kernel
python3 pdbconv.py -p ntkrnlmp.pdb -g GUID -o symbols/windows/

ISF Linux

Pour Linux, l'outil officiel est dwarf2json (Go), qui ingère :

• Le binaire vmlinux (avec symboles DWARF non strippés).
• Le fichier System.map du noyau.

dwarf2json linux --elf /boot/vmlinux-6.8.0 --system-map /boot/System.map-6.8.0 > ubuntu-6.8.json

ISF macOS

Pour macOS, on utilise dwarf2json mac avec le kernel.dSYM du DTK Apple ou les symboles publics du kernel.

Limites et inconvénients

Malgré ses qualités, Volatility présente plusieurs limites opérationnelles à connaître :

• Pas d'analyse live memory — Volatility nécessite un dump statique. Pour live memory, utiliser MemProcFS ou WinDbg LiveKD.
• Performance sur très gros dumps — au-delà de 32 Go, certains plugins (filescan, handles) deviennent très lents. Solution : MemProcFS.
• Dépendance ISF — un kernel Linux personnalisé (entreprise, embarqué) sans symboles DWARF est inanalysable sans recompilation source.
• Crash dumps Windows compressés (DMP/HDMP) — partiellement supportés ; convertir avec dmpconv si nécessaire.
• Hibernation file Windows 10/11 — chiffrement BitLocker/SecureBoot peut bloquer l'analyse.
• macOS récent (Sonoma, Sequoia) — support partiel, ralenti par la fermeture progressive du kernel par Apple.
• Anti-forensique — certains malwares (rootkits eBPF, injection via Process Doppelgänging, Heaven's Gate) échappent aux plugins standards.
• Courbe d'apprentissage — comprendre les structures EPROCESS/task_struct exige des connaissances OS internals.

Outils complémentaires : KAPE, Velociraptor, MemProcFS

Volatility s'inscrit dans un écosystème DFIR plus large. Les outils complémentaires les plus utilisés sont :

• KAPE (Eric Zimmerman, Kroll) — collecte triage disque + RAM, intégration native Volatility.
• Velociraptor (Velocidex/Rapid7) — agent EDR open source, capture mémoire à distance + WinPMEM.
• MemProcFS (Ulf Frisk) — pour live memory et performance ; expose la mémoire comme un système de fichiers virtuel.
• YARA — pattern matching en mémoire via windows.vadyarascan ou linux.bash.
• Capa (Mandiant) — détection de capacités malveillantes dans des binaires extraits.
• Bulk Extractor — extraction d'artefacts (URL, emails, IP) depuis le dump brut.
• Strings + grep — exploration ASCII/Unicode pour pivoter rapidement.
• Timeline Explorer + plaso/log2timeline — corrélation temporelle.

Use cases : DFIR, malware, expertise judiciaire

Volatility est utilisé dans des contextes professionnels variés, allant de la réponse à incident en entreprise jusqu'à l'expertise judiciaire mandatée par un magistrat. Voici les principaux scénarios d'emploi observés en 2026 dans les SOC européens, les CSIRT nationaux et les laboratoires forensiques :

Réponse à incident (DFIR)

Lors d'un incident ransomware ou APT, l'analyste capture la RAM des machines compromises avant extinction — sans quoi les artefacts volatiles disparaissent : credentials en mémoire (LSASS, NTLM, Kerberos tickets), processus malveillants en cours d'exécution, connexions C2 actives, payloads chargés en mémoire et jamais écrits sur disque (fileless malware), clés AES de chiffrement ransomware encore en RAM. Volatility permet ensuite d'identifier le vecteur initial (phishing, exploit, supply chain), le mouvement latéral (Pass-the-Hash, RDP, WMI), et les techniques de persistance (services, scheduled tasks, run keys, WMI subscriptions). Sur un incident Conti ou LockBit, l'extraction de la clé AES en mémoire peut permettre le déchiffrement gratuit des fichiers — c'est arrivé plusieurs fois dans des cas documentés par CERT-FR.

Investigation malware

Pour un échantillon malware analysé en sandbox, capturer la RAM de la VM permet d'extraire les payloads dépackés (les packers UPX, Themida, VMProtect ne résistent pas à un dump mémoire post-exécution), les configurations C2 chiffrées (souvent en clair en mémoire), les fichiers temporaires effacés, les chaînes Unicode déchiffrées dynamiquement. Workflow couplé recommandé : Cuckoo/CAPE ou any.run → exécution contrôlée → snapshot RAM en fin d'exécution → Volatility 3 → règles YARA + capa pour caractériser. Cette approche complète l'analyse statique IDA/Ghidra et l'analyse dynamique x64dbg.

Expertise judiciaire

Les laboratoires judiciaires français (IRCGN, gendarmerie scientifique, sous-direction de la lutte contre la cybercriminalité, police technique et scientifique) et européens (BKA en Allemagne, NCA en Royaume-Uni) utilisent Volatility pour exploiter des saisies à chaud (ordinateur allumé) dans des affaires de terrorisme, fraude financière, pédopornographie, où la mémoire vive contient des preuves volatiles : sessions de messageries chiffrées (Signal, Telegram, WhatsApp Desktop) déchiffrées en RAM, mots de passe maîtres de gestionnaires (KeePass, Bitwarden), portefeuilles crypto déverrouillés (Electrum, Metamask), volumes VeraCrypt/BitLocker montés. Les rapports d'expertise s'appuient sur des hash SHA-256 du dump et la traçabilité des plugins exécutés.

Threat hunting et CTI

Les équipes threat hunting peuvent baser des règles YARA mémoire ciblant des familles malware connues (Cobalt Strike beacons avec leurs sleep masks, Sliver C2, Brute Ratel C4, Mythic agents) via windows.vadyarascan ou linux.malfind. La détection en mémoire échappe aux mécanismes classiques d'évasion sur disque (signatures AV, AMSI bypass) car le code dépacké est toujours en clair en RAM.

Formation

Volatility est central dans les cursus SANS FOR526 Advanced Memory Forensics & Threat Detection, FOR508 Advanced Incident Response, et dans les formations universitaires françaises (M2 SSI Limoges, M2 SSI UTT, MBA cybersécurité ESIEA, MS cybersécurité Télécom Paris). Le SANS Forensics blog publie régulièrement des cheat sheets Volatility, et le challenge BelkaCTF intègre des épreuves de memory forensics. La chaîne YouTube 13Cubed (Richard Davis) propose une série gratuite de référence en français et anglais.

Recherche académique

Volatility est utilisé en recherche académique pour étudier de nouvelles techniques d'évasion (memory anti-forensics), développer des plugins de détection (eBPF rootkits, Hyper-V container escapes), et construire des datasets publics (DFRWS Memory Forensics Challenges). Les conférences DFRWS, BlackHat, OSDFCon publient chaque année plusieurs papiers liés à Volatility.

FAQ Volatility 3

Faut-il encore utiliser Volatility 2 en 2026 ?

Non, sauf cas très spécifique : analyse d'un dump Windows XP/2003 ou d'un kernel Linux 2.6 pour lequel aucun ISF Volatility 3 n'est disponible. Pour toute investigation moderne (Windows 7+, Linux 3.x+, macOS 10.10+), Volatility 3 est le choix par défaut. Volatility 2.6.1 n'est plus mis à jour fonctionnellement depuis 2018.

Quelle formation suivre pour maîtriser Volatility ?

La référence est le SANS FOR526 Advanced Memory Forensics & Threat Detection (6 jours, certification GIME). Pour une approche plus accessible et gratuite, le tutoriel officiel github.com/volatilityfoundation/volatility3 et le livre The Art of Memory Forensics (Ligh, Case, Levy, Walters — 2014) restent les références. La formation 13Cubed (Memory Forensics with Volatility 3) sur YouTube est aussi excellente.

Volatility 3 supporte-t-il Windows 11 23H2 et 24H2 ?

Oui. La version 2.5.0 (mai 2024) a ajouté le support de Windows 11 23H2 (build 22631) et la version 2.7.0 (avril 2026) couvre Windows 11 24H2 (build 26100). Les ISF Windows sont mis à jour automatiquement via le symbol cache téléchargé depuis le dépôt officiel. Pour les builds Insider très récents, il peut être nécessaire de générer manuellement les ISF avec pdbconv.py.

Volatility est-il vraiment gratuit ? Existe-t-il une version commerciale ?

Volatility est entièrement gratuit et open source sous Volatility Software License (VSL), dérivée GPLv2. Il n'existe pas de version commerciale officielle. La Volatility Foundation propose des formations payantes (Volatility Cyber Triage Training) et accepte des dons. Les outils commerciaux concurrents incluent Magnet AXIOM Memory Analysis, Cellebrite UFED, X-Ways Forensics, mais aucun ne remplace Volatility en termes de profondeur d'analyse mémoire.

Existe-t-il une interface graphique pour Volatility ?

Volatility 3 est nativement CLI. Plusieurs front-ends graphiques tiers existent : VolGUI, Volatility Workbench (PassMark, gratuit, Windows uniquement), Evolve (web GUI). Pour une expérience graphique moderne, MemProcFS propose un montage filesystem qui s'explore avec n'importe quel gestionnaire de fichiers, et Velociraptor intègre Volatility dans son interface web.

Volatility peut-il analyser la mémoire d'un téléphone Android ou iOS ?

Pas directement. Pour Android, des projets dérivés comme Volatility Android existent mais ne sont pas mainstream ; Frida + MemFetch sont préférés pour l'analyse mobile. Pour iOS, l'analyse mémoire est extrêmement difficile (chiffrement matériel, sandbox) et passe par des outils commerciaux (Cellebrite Premium, GrayKey).

Pour aller plus loin

• Analyse mémoire forensique avec Volatility — guide complet
• Forensics Windows : guide expert (MFT, journaux, registry)
• Analyse dynamique de malware en sandbox
• Anatomie d'une attaque ransomware : kill chain
• Investigation numérique : méthodologie et services
• Réponse à incident : workflow DFIR
• Site officiel Volatility Foundation
• Dépôt GitHub Volatility 3
• SANS Digital Forensics & Incident Response Blog