Volatility 3

Architecture et principe de fonctionnement

Volatility 3 repose sur une architecture entièrement modulaire articulée autour de trois couches : les layers (translation d'adresses, gestion des formats de capture), les symbol tables au format JSON (ISF – Intermediate Symbol Format) et les plugins d'analyse. Contrairement à Volatility 2 qui imposait la sélection manuelle d'un profil via --profil, la version 3 identifie automatiquement le système d'exploitation en scannant la KDBG ou la DTB, puis résout les symboles correspondants. Cette approche supprime la maintenance de centaines de profils codés en dur et rend l'outil compatible avec les noyaux récents dès leur publication.

Le moteur exploite un système de configuration hiérarchique et un cache persistant, ce qui accélère considérablement les analyses répétées sur un même dump. Le code, réécrit en Python 3, abandonne les dépendances obsolètes et gagne en performance sur les captures volumineuses (plusieurs dizaines de Go).

Cas d'usage en cybersécurité

• Détection de malwares sans fichier : identification de code injecté en mémoire (process hollowing, reflective DLL injection) via windows.malfind, invisible pour l'analyse disque.
• Investigation post-ransomware : récupération de clés de chiffrement résiduelles, reconstruction de la chronologie d'exécution.
• Chasse aux rootkits : comparaison des listes de processus actives et détection de hooking SSDT ou IRP.
• Extraction d'artefacts d'authentification : hachages, tickets Kerberos et sessions résidant dans LSASS.
• Analyse réseau mémoire : reconstitution des connexions établies au moment de la capture, utile pour identifier un canal de commande et contrôle.

Installation et prise en main

L'installation s'effectue via pip install volatility3 ou par clonage du dépôt GitHub officiel. Seul Python 3.8+ est requis ; les dépendances optionnelles (yara-python, capstone, pycryptodome) débloquent respectivement le scan par règles YARA, le désassemblage et le déchiffrement d'artefacts. Les tables de symboles Windows sont générées à la volée depuis les serveurs Microsoft PDB ; pour Linux et macOS, il faut compiler soi-même les fichiers ISF avec dwarf2json à partir des symboles du noyau cible. En environnement isolé, il est recommandé de pré-télécharger les packs de symboles dans le répertoire symbols/.

Avantages et limites

Les bénéfices majeurs sont la rapidité, la suppression des profils, une API stable facilitant le développement de plugins personnalisés et une sortie structurée (JSON, CSV) exploitable par des scripts d'automatisation. En contrepartie, la couverture de plugins reste inférieure à celle de Volatility 2 pour certains cas de niche, et le support Linux/macOS dépend entièrement de la disponibilité des symboles — un frein réel lors d'une réponse à incident sur une distribution personnalisée. La qualité de l'analyse dépend enfin intégralement de celle de l'acquisition mémoire : un dump incohérent produira des résultats partiels.

Intégration dans l'écosystème DFIR

Volatility 3 s'intègre naturellement en aval des outils d'acquisition (WinPmem, LiME, AVML, DumpIt) et en amont des plateformes de corrélation. Sa sortie JSON alimente directement un SIEM ou une timeline Plaso, permettant de croiser artefacts mémoire et journaux système. Les processus suspects extraits peuvent être soumis à un bac à sable ou à une base d'indicateurs de compromission. De nombreuses distributions forensiques (SIFT Workstation, Tsurugi, REMnux) l'embarquent par défaut, et son usage est fréquemment combiné à des solutions EDR pour valider une alerte par une preuve mémoire irréfutable.