Combien de temps prend généralement une analyse mémoire ?

Le triage prend des minutes. Une analyse complète sur un seul hôte sans IOC préalable prend typiquement une demi-journée à une journée. Avec des IOC ciblés, une à deux heures.

Faut-il dumper chaque processus suspect ?

Non. Dumpez seulement quand vous avez besoin d'analyse statique (chaînes, désassemblage, sandbox). La plupart des conclusions viennent de preuves structurelles (parent/enfant, points d'extrémité réseau, modules chargés), pas de l'analyse statique au niveau octet.

Que cherche malfind ?

Des régions mémoire qui semblent exécutables mais ne correspondent à aucun fichier sur disque (pages PAGE_EXECUTE_READWRITE, RWX sans fichier de soutien). C'est la signature structurelle de l'injection DLL réflective et du shellcode.

Quand faut-il dépasser l'analyse mémoire ?

Quand les preuves mémoire mettent en cause le disque de l'hôte (persistance), le réseau (mouvement latéral), ou d'autres endpoints (portée de la campagne). La mémoire dit ce qui tourne maintenant ; le reste du DFIR dit comment cela y est arrivé et où c'est ailleurs.

Un flux d'analyse mémoire qui trouve des choses

Une analyse mémoire n'est pas une checklist. C'est un flux à cinq étapes qui se nourrissent mutuellement : le triage pointe des suspects, les suspects ouvrent des pivots, les pivots mettent en place l'analyse approfondie, l'analyse approfondie fait remonter ce que le carving corrobore, et tout atterrit dans un rapport qui rattache les affirmations à des preuves. Sautez une étape et vous ratez des choses. Faites-les dans l'ordre et vous attrapez à quoi ressemblent les menaces modernes en 2026.

Cette version est construite autour de ramparser pour le triage et de Volatility 3 pour la profondeur. Pour la vue d'ensemble de la discipline, lisez Forensique RAM : outils, techniques et un flux 2026. Pour les compromis par outil, voir la comparaison des outils de forensique mémoire.

Étape 1 : Triage

L'objectif est une seule question : y a-t-il quelque chose qui cloche visiblement ? Vous cherchez la fumée, pas le feu. Cette étape suppose que vous avez déjà une image mémoire sur disque ; sinon, le guide Magnet RAM Capture couvre l'acquisition de bout en bout.

Déposez l'image dans ramparser. En quelques secondes :

pslist : l'arbre de processus actif depuis ActiveProcessLinks du noyau.
psscan : chaque objet _EPROCESS trouvé par le scanner pool.
psxview : le diff. Une ligne dans psscan absente de pslist est la signature classique d'un processus caché par DKOM.
pstree : relations parent/enfant.

Cherchez :

Noms inattendus. Un svchost.exe tournant depuis C:\Users\…\AppData plutôt que System32. Un chrome.exe sans parent Chrome.
Parents incohérents. cmd.exe enfanté par winword.exe, powershell.exe rattaché à un service qui n'a rien à faire en lançant des shells.
Lignes cachées. Tout HIDDEN dans psxview reçoit une étoile.
Comptes suspects. Cinq lsass.exe. Trois wininit.exe. Il doit y en avoir exactement un de chaque.

Le livrable du triage est une liste de suspects, typiquement 1 à 5 PID.

Étape 2 : Pivoter sur les suspects

Trois pivots par suspect racontent l'histoire.

Ligne de commande (PEB)

cmdline lit le Process Environment Block et récupère la ligne de commande exacte. C'est ici que vous attrapez :

PowerShell encodé en base64.
Drapeaux suspects (-EncodedCommand, -WindowStyle Hidden, -NoProfile -ExecutionPolicy Bypass).
Chemins vers des binaires déposés.
Indices de configuration de beacon.

Modules chargés

dlllist montre chaque module chargé dans le processus. Cherchez :

DLL depuis %TEMP% ou des chemins inhabituels.
DLL avec des noms imitant ceux du système (typosquats à une lettre près).
DLL attendues manquantes (un gestionnaire d'identifiants sans samlib.dll).

Points d'extrémité réseau

netscan rattache le processus au monde extérieur :

Sortants vers des ASN inhabituels ou une infrastructure C2 connue.
Écouteurs locaux sur des ports élevés.
Connexions établies vers des adresses incompatibles avec le rôle de l'hôte.

Quand deux des trois s'accordent (une cmdline suspecte tournant depuis un chemin étrange avec un sortant vers une infrastructure connue malveillante), c'est une vraie conclusion, pas une intuition.

Étape 3 : Analyse approfondie

Le triage est rapide et large. L'analyse approfondie est lente et précise. Volatility 3 mérite sa place ici.

malfind

windows.malfind cherche des régions mémoire exécutables, en écriture, et non liées à un fichier. La signature structurelle de :

Injection DLL réflective.
Injection shellcode (VirtualAllocEx + WriteProcessMemory + CreateRemoteThread).
Process hollowing (combiné à un image base incohérent).

Un malfind propre ne signifie pas qu'il n'y a rien ; un malfind non vide vaut presque toujours d'être investigué.

Inspection noyau

windows.modscan énumère les modules noyau depuis le pool. Comparez contre windows.modules (la liste vivante) pour trouver les drivers déliés, l'équivalent noyau d'un processus caché par DKOM. windows.callbacks et windows.ssdt révèlent des hooks noyau que la télémétrie utilisateur ne peut voir.

Scans YARA

windows.yarascan.YaraScan exécute des règles sur les espaces d'adressage des processus. Associez à des règles maintenues (yara-rules/rules sur GitHub) plus vos détections internes. Manière la plus rapide de confirmer une charge utile connue malveillante.

Chronologie

timeliner.Timeliner construit une chronologie d'événements depuis chaque plugin qui émet des horodatages. Exportez en CSV, chargez dans Timesketch ou un tableur, et suivez l'activité autour du créneau suspect. Recoupez contre la chronologie sur disque depuis le MFT, le journal USN, et EVTX pour le récit le plus fort.

Étape 4 : Carving

Certaines preuves ne sont pas dans des objets structurés : ce sont juste des octets. bulk_extractor extrait :

Adresses e-mail (point de pivot phishing).
URL et noms de domaine (pivot infrastructure).
Adresses IP (pivot réseau).
Cartes de crédit, adresses Bitcoin, matériel cryptographique.
En-têtes ZIP et JPEG (carving d'artefacts encapsulés).

Recoupez ce que bulk_extractor trouve avec ce que le triage et les pivots ont montré. Un domaine C2 qui apparaît dans netscan et dans des chaînes brutes est plus fort que l'un ou l'autre seul.

Étape 5 : Conclure et documenter

Une analyse mémoire ne vaut que par son rapport. Rattachez chaque affirmation à des preuves spécifiques :

"Le PID 4128 (svchost.exe) a été injecté avec du shellcode" → citez la ligne malfind, la région mémoire suspecte, le PID parent.
"C2 sortant vers 203.0.113.5:443" → citez la ligne netscan, le processus associé, et tout résultat bulk_extractor correspondant.
"Identifiants moissonnés via accès à lsass.exe" → citez le handle (plugin handles), le PID suspect, et tout callback noyau qui s'est déclenché.

Une conclusion sans preuve est une supposition. Une supposition dans un rapport IR peut coûter le dossier.

À quoi ressemble "fini"

Chaque suspect du triage a été résolu (faux positif, voici pourquoi) ou confirmé (voici la preuve).
Les plugins d'analyse approfondie ont tourné de bout en bout, pas seulement contre les suspects, vous ne voulez pas découvrir plus tard une seconde compromission jamais examinée.
La passe de carving n'a rien apporté de nouveau, ou ce qu'elle a apporté a été réconcilié avec les conclusions structurelles.
La chronologie correspond au récit d'attaque suspecté, ou, sinon, le récit est mis à jour.

Où s'insère ramparser

ramparser est le moteur de triage. Il existe pour faire disparaître l'étape 1 dans le flux : pas d'environnement, pas de packs de symboles, pas d'envoi, juste la réponse. Quand le triage pointe quelque chose, vous passez à Volatility 3 pour le reste.