Pourquoi la mémoire est importante, et son acquisition

Une image disque montre ce qu'un système a stocké ; une image mémoire montre ce qu'il faisait : quels programmes s'exécutaient et avec quels arguments, qui avait une session ouverte, à quels réseaux la machine était connectée et quels secrets étaient déverrouillés. La plupart de ces éléments disparaissent à la mise hors tension. Cette leçon présente ce qui réside uniquement en RAM, les éléments à collecter en premier et la manière d'acquérir la mémoire de systèmes Windows, Linux et de machines virtuelles afin que la capture puisse être analysée et défendue. Le problème de la table des symboles sous Linux fait l'objet d'une attention particulière, car il constitue la cause la plus fréquente d'échec d'une analyse Linux.

Ce qui réside uniquement en RAM

La mémoire vive (RAM) contient l'état de travail du système d'exploitation et de chaque programme en cours d'exécution. Une partie de son contenu est ensuite écrite sur disque, dans le fichier d'échange, le fichier de mise en veille prolongée ou un vidage sur incident (leçon 5.4), mais une grande partie ne l'est jamais :

• Les processus et leurs lignes de commande. La ligne de commande complète, par exemple powershell.exe -enc <Base64>, n'existe souvent que dans la mémoire du processus.
• Les connexions réseau. Les sockets ouverts, les ports en écoute et les adresses distantes, ainsi que le cache ARP et la table de routage.
• Les sessions ouvertes. Les sessions interactives, de Bureau à distance et de service, avec leurs jetons d'accès. Sous Windows, le processus Local Security Authority (lsass.exe) contient des éléments d'authentification des utilisateurs ayant une session ouverte.
• Les données déchiffrées et les clés de chiffrement. Lorsqu'un volume BitLocker est déverrouillé ou qu'un conteneur VeraCrypt est monté, la clé principale qui permet de le déchiffrer se trouve en RAM. Sa récupération peut être le seul moyen de lire ultérieurement le disque chiffré (le module 7 traite des volumes chiffrés).
• Le contenu du presse-papiers, notamment du texte copié mais jamais enregistré.
• Le code injecté ou sans fichier. Un logiciel malveillant chargé directement dans un autre processus ou exécuté sous forme de script en mémoire peut ne laisser aucun exécutable sur disque (leçon 5.3).
• Les documents non enregistrés et les tampons des éditeurs.
• Les traces de navigation privée. Les modes privés évitent d'écrire l'historique sur disque, mais les URL, le texte des pages et les données des formulaires restent dans la mémoire du processus du navigateur.

La mémoire corrobore également les éléments de preuve présents sur disque : Prefetch prouve qu'un programme s'est exécuté à un moment donné, tandis qu'un processus présent dans une image mémoire prouve qu'il s'exécutait au moment de la capture, avec une heure de démarrage, un processus parent et un utilisateur.

L'ordre de volatilité

La RFC 3227, Lignes directrices pour la collecte et l'archivage des éléments de preuve (2002), indique à la personne chargée de la collecte de procéder des éléments de preuve les plus volatils aux moins volatils. Sa liste est la suivante :

1. Registres et cache
2. Table de routage, cache ARP, table des processus, statistiques du noyau, mémoire
3. Systèmes de fichiers temporaires
4. Disque
5. Données de journalisation et de surveillance distantes pertinentes pour le système
6. Configuration physique et topologie du réseau
7. Supports d'archivage

Les registres et le cache changent en quelques nanosecondes et ne sont presque jamais collectés ; en pratique, l'image mémoire vient donc en premier. La table de routage, le cache ARP et la table des processus résident tous en RAM : une image mémoire complète les préserve, tandis que l'exécution préalable de commandes sur le système en fonctionnement, comme netstat ou ps, modifie la mémoire. Les systèmes de fichiers temporaires tels que tmpfs sous Linux (/dev/shm, et /tmp sur certaines distributions) reposent sur la RAM et disparaissent à la mise hors tension. Les journaux distants survivent à l'incident, mais font l'objet d'une rotation selon la politique de conservation ; demandez-les donc rapidement.

Décider de capturer la mémoire et documenter l'empreinte laissée

Si un système est découvert en fonctionnement, la démarche par défaut consiste à capturer sa mémoire avant de l'arrêter ou de couper son alimentation. L'arrêter d'abord détruit les éléments de preuve en RAM et peut verrouiller définitivement un volume chiffré monté. Les raisons d'agir autrement, par exemple la présence d'un logiciel malveillant qui efface activement des données, doivent être évaluées et consignées.

Toute acquisition à chaud modifie le système. L'outil s'exécute en tant que processus, charge un pilote ou un module, ou ouvre des fichiers de périphériques, et écrase des pages mémoire qui pouvaient contenir des données libérées mais récupérables. Vous ne pouvez pas éviter cette empreinte ; vous devez donc la réduire au minimum et la documenter. La norme ISO/IEC 27037 traite de l'acquisition à chaud et exige que chaque action soit justifiée et documentée, et le guide NIST SP 800-86 recommande de collecter les données volatiles dans l'ordre de volatilité avec des outils de confiance, en tenant compte de leurs effets. Consignez le nom, la version et l'empreinte de hachage de l'outil, la commande exacte, le compte utilisé, les heures de début et de fin en UTC avec leur source de temps, ainsi que chaque action effectuée dans la console.

Acquisition sous Windows

Les outils d'acquisition mémoire sous Windows nécessitent des droits d'administrateur, car ils chargent un pilote noyau pour lire la mémoire physique. Exécutez l'outil depuis un support externe et écrivez la sortie sur un disque externe préparé ou un partage réseau. N'écrivez jamais une capture sur le propre disque du système examiné : cela écraserait des clusters non alloués susceptibles de contenir des fichiers supprimés. Calculez l'empreinte de hachage de la sortie dès qu'elle est complète.

Les formats de sortie courants sont le format brut (une copie à plat de la mémoire physique, avec l'extension .raw, .mem ou .img), le format de vidage sur incident Microsoft (.dmp, un en-tête suivi de pages mémoire) et le format AFF4 (Advanced Forensic Format 4, un conteneur avec compression et métadonnées). Volatility 3 lit directement les fichiers bruts et les fichiers de vidage sur incident, mais pas les fichiers AFF4 ; exportez donc d'abord une capture AFF4 au format brut.

Deux fonctionnalités de Windows compliquent l'analyse. Les données transférées dans le fichier d'échange : les pages déplacées vers pagefile.sys ne figurent pas dans l'image RAM, ce qui laisse des lacunes ; collectez également le fichier d'échange lorsque cela est possible (leçon 5.4). La compression mémoire : depuis Windows 10, le gestionnaire de mémoire compresse les pages rarement utilisées en RAM au lieu de les transférer dans le fichier d'échange ; dans les versions actuelles de Windows 10 et 11, le magasin de compression appartient à un processus nommé Memory Compression. Ces données figurent dans l'image, mais sont compressées, et seuls les outils prenant en charge le magasin de compression peuvent les lire.

Machines virtuelles

Un hyperviseur peut enregistrer la mémoire du système invité sans rien exécuter à l'intérieur de celui-ci ; il n'y a donc aucune empreinte d'outil. De plus, une machine virtuelle suspendue est arrêtée, ce qui rend sa mémoire enregistrée cohérente.

• VMware : la mémoire du système invité est écrite dans un fichier .vmem lorsque la machine virtuelle est suspendue (avec un fichier d'état .vmss) ou lorsqu'un instantané inclut la mémoire (avec un fichier d'instantané .vmsn). Collectez le fichier .vmem avec le fichier .vmss ou .vmsn correspondant : le fichier d'état décrit l'organisation de la mémoire du système invité dans le fichier .vmem, et Volatility 3 l'utilise.
• Hyper-V : depuis Windows Server 2016 et Windows 10, l'état enregistré et les points de contrôle sont stockés dans des fichiers d'état d'exécution .vmrs ; les versions antérieures utilisaient des fichiers .bin (mémoire) et .vsv (état enregistré). Aucun de ces formats n'est une image brute : convertissez-le avec un outil qui comprend le format, par exemple les outils Microsoft de vidage d'état enregistré, puis testez le résultat.

Acquisition sous Linux

LiME (Linux Memory Extractor) est un module noyau chargeable. Un noyau n'accepte un module que s'il a été compilé pour cette version et cette configuration exactes du noyau ; LiME doit donc être compilé à partir des en-têtes du noyau en cours d'exécution, sur un système sain distinct utilisant la même distribution et le même noyau, et non sur le système examiné. La compilation produit lime-<release>.ko, chargé, par exemple, avec insmod lime-6.1.0-18-amd64.ko "path=/mnt/usb/mem.lime format=lime". Le paramètre format accepte raw, padded ou lime. Le format lime écrit un en-tête de 32 octets avant chaque plage de mémoire physique, commençant par la valeur magique 0x4C694D45, qui apparaît dans le fichier sous la forme des octets ASCII EMiL. LiME peut également transmettre la capture sur le réseau avec path=tcp:<port>, évitant ainsi toute écriture locale. Lorsque Secure Boot et l'obligation de signature des modules sont activés, un module LiME non signé est refusé.

AVML (Acquire Volatile Memory for Linux) est l'alternative de Microsoft : un programme statique en espace utilisateur qui ne nécessite pas de compilation propre à chaque noyau. Il lit les données via /dev/crash, /proc/kcore ou /dev/mem, selon ce qui est disponible, et les écrit au format LiME, éventuellement compressé (Volatility 3 lit le fichier compressé si la bibliothèque snappy est installée ; sinon, convertissez-le avec avml-convert).

/proc/kcore présente la mémoire virtuelle du noyau sous la forme d'un fichier de vidage mémoire ELF. Il ne s'agit pas d'une image physique prête à l'emploi : sa taille apparente reflète l'espace d'adressage du noyau (environ 128 TiB sur les systèmes x86-64 courants), le verrouillage du noyau peut en restreindre l'accès, et sa copie avec dd ne produit pas un fichier conforme à ce qu'attendent les outils d'analyse. /dev/mem n'est pas non plus une source utilisable en pratique : avec l'option noyau STRICT_DEVMEM, activée sur la plupart des distributions, il ne peut pas lire la RAM ordinaire (les noyaux x86 actuels renvoient des zéros, même pour la RAM située dans le premier 1 MiB).

Le tableau résume les options d'acquisition présentées dans cette leçon.

Le problème de la table des symboles

Pour analyser une image Linux, Volatility 3 a besoin d'une table des symboles correspondant à la compilation exacte du noyau : un fichier JSON ISF (Intermediate Symbol Format) décrivant les structures du noyau et les adresses des symboles. Il est construit avec dwarf2json à partir d'un fichier vmlinux contenant les informations de débogage DWARF et du fichier System.map correspondant, par exemple dwarf2json linux --elf vmlinux-6.1.0-18-amd64 --system-map System.map-6.1.0-18-amd64 > debian12-6.1.0-18.json. Sous Debian, le fichier vmlinux de débogage provient du paquet linux-image-<release>-dbg. Volatility 3 associe le fichier de symboles à l'image à l'aide de la chaîne de bannière du noyau, et son plugin banners indique quelle bannière contient une image. Une capture sans symboles correspondants peut être inutilisable ; consignez donc la sortie de uname -a lors de l'acquisition : elle indique à l'analyste exactement pour quel noyau obtenir les symboles.

Intégrité, incohérence temporelle et durée

Calculez immédiatement l'empreinte de hachage de la capture, généralement avec SHA-256. Cette empreinte prouve que le fichier n'a pas changé depuis l'acquisition, mais elle ne peut pas être vérifiée par rapport à la source : la mémoire change constamment, de sorte que deux captures du même système en fonctionnement n'ont jamais la même empreinte de hachage.

La mémoire change également pendant sa lecture : les pages copiées à la fin d'une capture reflètent un état plus tardif que celles copiées au début. Cette incohérence temporelle peut produire des structures incohérentes, comme une entrée de liste pointant vers un processus déjà terminé. Une capture n'est pas un instantané parfait ; corroborez donc les résultats inhabituels.

Exemple détaillé : acquisition sur un serveur Linux

Un serveur web Debian 12 en fonctionnement doit être préservé. Un module LiME a été compilé à l'avance sur un système de laboratoire doté d'un noyau identique. Le relevé d'acquisition indique :

Dimensionnement. Les capacités de RAM sont binaires : 8 GiB = 8 × 1 073 741 824 = 8 589 934 592 octets. Les débits des disques sont décimaux : 200 MB/s = 200 000 000 octets par seconde. Durée = 8 589 934 592 ÷ 200 000 000 ≈ 42,9 s, soit environ 43 secondes. Considérer 8 GiB comme 8 000 000 000 octets donne 40 s, soit une sous-estimation de 7 %. Les 46 secondes consignées correspondent à l'estimation augmentée du temps de chargement du module. Un serveur de 64 GiB au même débit nécessite 68 719 476 736 ÷ 200 000 000 ≈ 344 s, soit près de six minutes d'incohérence temporelle. Le fichier lime ne fait pas non plus exactement 8 GiB : LiME ne copie que les plages que le noyau répertorie comme System RAM dans /proc/iomem et ajoute 32 octets par plage.

Habilitation et protection de la vie privée

La mémoire contient des mots de passe, des messages privés et des données de personnes extérieures à l'enquête. Confirmez que votre habilitation (un mandat, le consentement du propriétaire ou un mandat de réponse à incident) couvre l'acquisition à chaud, respectez le périmètre autorisé et protégez la capture en tant que données sensibles.

Points clés pour l'examen : Attendez-vous à des questions qui appliquent l'ordre de volatilité à un scénario, demandent ce qu'une image mémoire contient qu'une image disque ne contient pas, et vérifient pourquoi l'empreinte de hachage d'une capture mémoire ne peut pas être revérifiée par rapport au système en fonctionnement. Sachez que l'analyse Linux avec Volatility 3 dépend d'un fichier de symboles ISF correspondant exactement à la bannière du noyau.

Points essentiels

• La RAM contient des processus en cours d'exécution, des lignes de commande, des connexions, des sessions, des clés de chiffrement et du code sans fichier qui ne sont jamais écrits sur disque.
• Collectez les éléments des plus volatils aux moins volatils (RFC 3227) : capturez la mémoire avant l'arrêt et documentez l'empreinte inévitable de l'outil.
• Exécutez les outils Windows en tant qu'administrateur depuis un support externe, écrivez sur un support externe et calculez immédiatement l'empreinte de hachage de la sortie.
• LiME doit être compilé pour le noyau exact en cours d'exécution ; AVML est une alternative en espace utilisateur ; /proc/kcore n'est pas une image physique prête à l'emploi.
• Consignez la sortie de uname -a : sans table des symboles ISF correspondant à ce noyau exact, Volatility 3 peut être incapable d'analyser la capture.
• L'incohérence temporelle, les pages transférées dans le fichier d'échange et la compression mémoire de Windows font qu'une capture n'est jamais un instantané complet et cohérent.