Analyse mémoire et réseau après un incident

L’analyse disque répond à ce qui a été écrit et persisté. L’analyse mémoire répond à ce qui existait encore au moment de la capture, tandis que l’analyse réseau répond à ce qui a circulé, à condition que la collecte ait commencé avant l’incident. Ces trois sources ne sont pas interchangeables : perdre la mémoire, c’est perdre une scène de crime qui s’évapore à l’extinction.

→ Lire l’explication complète de la marmotte

Capture mémoire : l’état vivant que le disque ne contient pas

Une capture de mémoire vive, ou RAM (Random Access Memory), fige le contenu volatile d’une machine à un instant donné. Elle peut contenir les processus actifs, leurs arguments de lancement, les bibliothèques chargées, les connexions ouvertes, les jetons d’authentification, les secrets applicatifs et parfois des clés cryptographiques en cours d’usage. Le disque ne contient pas cet état. Il contient, au mieux, des traces indirectes et souvent anciennes.

Un malware fileless, c’est-à-dire exécuté sans binaire durable sur le système de fichiers, illustre brutalement la différence. Un script injecté dans un interpréteur déjà autorisé, une charge placée dans la mémoire d’un processus légitime ou un module téléchargé puis exécuté sans écriture persistante peuvent ne laisser aucun fichier malveillant exploitable. Chercher le programme sur disque revient alors à inspecter une étagère après qu’un illusionniste a rangé ses accessoires ailleurs.

La mémoire révèle également les incohérences entre l’état déclaré par le système et l’état réel. Sous Linux, une comparaison entre la liste des processus exposée par /proc, les structures du noyau et les sockets associés permet de détecter certaines techniques de dissimulation. Sous Windows, l’analyse des listes de processus, des handles, des régions mémoire exécutables et des connexions permet de repérer une injection de code ou un processus parent improbable. Aucune de ces méthodes ne rend un rootkit omniscient soudainement bavard, mais elles multiplient les angles de contrôle.

Le compromis central est brutal : capturer la mémoire modifie nécessairement la mémoire. Le collecteur charge du code, alloue des buffers, déclenche des accès disque et réseau, puis produit un fichier volumineux. Pourtant, ne pas la capturer détruit bien davantage de preuve. La position à tenir est donc nette : accepter une altération documentée et minimale pour préserver un état autrement irrécupérable.

L’ordre d’investigation ne se négocie pas :

Isoler le système sans l’éteindre, en coupant ou filtrant les flux non nécessaires.
Photographier l’état visible, heure, connexions console, interfaces réseau, utilisateurs connectés.
Capturer la mémoire vive.
Collecter les journaux volatils et les fichiers temporaires.
Acquérir les disques et les stockages attachés.
Éteindre seulement si le confinement ou la sécurité physique l’exige.

Acquérir le disque avant la mémoire est une erreur classique. La lecture intensive modifie caches, journaux, métadonnées et pression mémoire. Un arrêt, même propre, supprime la mémoire vive. La réanalyse ultérieure ne résout rien : une mémoire non capturée n’est pas une source manquante dans une archive, c’est une source détruite.

Artefacts RAM : processus, clés et connexions actives

Une image mémoire permet d’extraire une liste de processus à l’instant de capture, mais cette liste seule a une valeur limitée. Un navigateur, un agent de supervision, un service Java ou un interpréteur PowerShell peuvent tous héberger du code malveillant sans changer de nom. L’analyse doit corréler quatre dimensions : processus, arbre de parenté, mémoire exécutable et activité réseau.

Un processus dont le parent est absent, dont la ligne de commande est incohérente ou dont la mémoire contient une région exécutable privée mérite une analyse. Une région privée exécutable n’est pas une condamnation : les environnements d’exécution modernes génèrent du code. Elle devient suspecte lorsqu’elle contient une charge sans module associé, des chaînes de commande, des adresses de contrôle ou des clés inattendues.

Les clés de chiffrement constituent l’artefact le plus délicat. Une clé de session Transport Layer Security, ou TLS, peut apparaître dans la mémoire d’un client ou d’un serveur pendant une communication chiffrée. Une clé de chiffrement de volume, un mot de passe saisi dans un processus, un jeton d’accès ou une clé privée chargée par un service peuvent également être récupérables. Cela permet parfois de déchiffrer des données saisies pendant l’enquête ou de comprendre l’étendue d’une compromission.

Cette capacité impose une discipline sévère. Un dump mémoire est lui-même une donnée hautement sensible : il peut contenir des identifiants, des secrets de services, des données personnelles et des clés. Le chiffrer au repos, limiter les accès, journaliser toute consultation et détruire les copies de travail deviennent des exigences opérationnelles. Conserver une image mémoire sur un partage d’équipe ouvert, c’est transformer l’investigation en distribution de secrets avec une étiquette de preuve.

La mémoire ne garantit pas l’attribution, l’intégrité antérieure du système ni l’absence de persistance. Une capture montre un instant, pas toute l’histoire. Un attaquant peut avoir quitté la machine, effacé ses processus ou déclenché une charge à durée de vie très courte. L’analyse disque, les journaux d’identité et les événements de sécurité restent nécessaires pour reconstruire la chronologie. Les mécanismes de détection et réponse réseau ne remplacent pas davantage la capture mémoire : ils observent des flux, pas les secrets ni le code présents dans un processus.

Capture mémoire Linux reproductible

Avant toute collecte, il faut disposer d’un outil validé pour la distribution, le noyau et l’architecture concernés. AVML (Acquire Volatile Memory for Linux) produit une image mémoire Linux sans charger de module noyau tiers, ce qui réduit la friction opérationnelle mais ne dispense pas de tester le binaire sur les noyaux réellement exploités. Le binaire doit être acquis depuis une source vérifiée, stocké dans un dépôt d’outillage contrôlé et accompagné de son empreinte.

# Créer un répertoire de preuve sur un volume chiffré monté en écriture.
sudo install -d -m 0700 /evidence/host-incident-001

# Capturer la mémoire puis calculer une empreinte SHA-256 de l'image produite.
# AVML doit correspondre à l'architecture et au noyau de l'hôte ciblé.
sudo /opt/forensics/avml /evidence/host-incident-001/memory.lime
sudo sha256sum /evidence/host-incident-001/memory.lime \
  | sudo tee /evidence/host-incident-001/memory.lime.sha256

# Consigner l'heure UTC et les interfaces avant toute acquisition disque.
date -u --iso-8601=seconds | sudo tee /evidence/host-incident-001/capture-time.txt
ip -br address | sudo tee /evidence/host-incident-001/interfaces.txt

Cette commande ne suffit pas à qualifier la preuve. Il faut relever la version du noyau, l’horodatage UTC, l’empreinte du collecteur, l’identité de l’opérateur, le chemin de sortie et les erreurs remontées. Les principes de conservation détaillés dans les fondations de l’architecture cyber s’appliquent ici avec une contrainte supplémentaire : le délai compte autant que l’intégrité.

L’analyse doit être menée sur une copie. Volatility 3, framework d’analyse mémoire, peut identifier processus, sockets, modules chargés et régions mémoire selon le système cible. Les symboles du noyau Linux ou les informations de débogage Windows doivent correspondre précisément à la version capturée. Sans eux, l’outil produit parfois des résultats incomplets qui ont l’air parfaitement convaincants. Les faux positifs aiment les tableaux bien alignés.

Analyse réseau : reconstruire ce qui a réellement circulé

Une capture de paquets, ou PCAP (Packet Capture), conserve les paquets observés sur une interface ou un point de collecte. Elle permet de reconstruire des sessions, de mesurer les volumes, d’identifier les destinations, de retrouver des requêtes de protocole et, lorsque le trafic n’est pas chiffré ou que les clés sont disponibles légalement et techniquement, d’examiner le contenu applicatif.

Le PCAP répond à des questions que la mémoire ne peut pas résoudre seule : quelles données ont quitté le réseau, vers quelles adresses, pendant combien de temps, avec quelle cadence et via quel protocole. Un processus suspect avec une socket active indique une possibilité. Une session reconstruite établit un comportement observé. La distinction compte lorsqu’il faut séparer une hypothèse technique d’un fait vérifiable.

Le PCAP doit exister avant l’incident. Activer une sonde après une alerte ne reconstruit pas la session d’exfiltration terminée deux heures auparavant, pas plus qu’un journal vide ne révèle une authentification passée. Les métadonnées de flux, telles que NetFlow, sFlow ou IPFIX (Internet Protocol Flow Information Export), sont moins coûteuses à conserver mais ne contiennent généralement pas la charge utile. Elles permettent de détecter qu’un transfert a existé, pas de prouver précisément quel document a été transféré.

La recommandation est de combiner trois niveaux :

métadonnées de flux sur l’ensemble des segments pertinents ;
PCAP à rétention courte sur les zones à forte exposition ou à forte valeur ;
PCAP déclenché ou étendu lors d’une alerte corrélée.

Conserver du PCAP intégral partout et indéfiniment est rarement réaliste. Le volume dépend du débit moyen, des pointes, de la taille moyenne des paquets et du taux de compression réellement obtenu. Dimensionner sur une moyenne optimiste produit toujours une saturation lors de l’incident qui mérite justement une trace. Le stockage n’a aucune imagination, mais il sait tomber plein au mauvais moment.

Le chiffrement limite aussi l’analyse. TLS protège le contenu contre l’observateur réseau, ce qui est son rôle. Le PCAP conserve alors les adresses, ports, tailles, horaires, certificats visibles selon la version du protocole et caractéristiques de session, mais pas nécessairement les données. Les clés extraites d’une capture mémoire peuvent parfois compléter le PCAP, sous contrôle strict et seulement si les versions, sessions et mécanismes de dérivation le permettent.

Surface d’attaque et limites des preuves volatiles

La collecte mémoire et réseau devient elle-même une cible. Un attaquant ayant des privilèges élevés peut détecter des outils d’acquisition, tuer des processus, chiffrer ou purger des données, falsifier des journaux et manipuler les interfaces de capture. Un rootkit noyau peut masquer objets et connexions. Une sonde réseau mal positionnée peut manquer les flux internes, le trafic est-ouest ou les tunnels chiffrés.

Réduire ce risque impose plusieurs contrôles :

collecteurs prépositionnés, signés et dont l’empreinte est connue ;
accès d’intervention séparés des identités administratives ordinaires ;
synchronisation horaire vérifiée avant corrélation ;
sondes réseau hors bande lorsque l’architecture le permet ;
stockage de preuve chiffré avec contrôle d’accès distinct ;
supervision de la capacité, des pertes de paquets et des interruptions de capture.

Une sonde qui perd des paquets sous charge ne doit jamais être présentée comme une source exhaustive. Les statistiques de perte font partie de la preuve. Les omettre revient à annoncer une vidéo complète après avoir coupé les dix dernières minutes parce que le disque était plein.

Aucune de ces sources ne remplace le confinement. L’isolement réseau doit empêcher l’exfiltration et les mouvements latéraux, sans couper aveuglément l’accès nécessaire à une acquisition distante. Une décision de coupure totale peut être nécessaire face à un ransomware ou à une compromission active, mais elle doit être assumée comme une destruction de volatilité. Les arbitrages de crise ne se corrigent pas avec un meilleur tableur.

Exploitation, rétention et reprise de collecte

La préparation détermine la valeur d’une investigation. Sans outil compatible, compte de collecte, volume de sortie, chiffrement de stockage et procédure testée, la capture mémoire devient une improvisation sous pression. L’improvisation reste très populaire dans les démonstrations commerciales. En incident, elle produit surtout des fichiers incomplets et des silences gênants.

Les secrets utilisés pour chiffrer les preuves doivent être séparés des systèmes analysés. Une clé stockée uniquement sur l’hôte compromis ne protège rien : elle est potentiellement compromise avec lui. Prévoir une rotation des clés de stockage, des comptes d’acquisition à privilèges temporaires et des certificats d’accès aux collecteurs. L’usage d’un module cryptographique matériel peut protéger les clés de chiffrement des archives, mais ne rend pas automatiquement la procédure de collecte intègre.

Les sauvegardes des images mémoire et des PCAP doivent être testées par restauration et vérification d’empreinte. Une politique de rétention doit distinguer données d’investigation, données de détection et données personnelles. La durée relève des contraintes internes et réglementaires applicables, mais le mécanisme technique est constant : définir ce qui est capturé, où, combien de temps, sous quelle clé et qui peut relire. Sans ces réponses, la capture est un pari coûteux, pas une capacité de réponse.

🐝 Ce qui arrive si on s’en passe

Sans capture mémoire ni collecte réseau préalable, l’incident se raconte mais ne se démontre pas. La qualification du périmètre repose alors sur des suppositions : impossible d’établir quels comptes ont été utilisés, quels secrets étaient chargés en mémoire, ni de prouver qu’aucune donnée n’est sortie. Cette absence de preuve négative oblige à traiter tous les identifiants présents sur l’hôte comme compromis, ou à ne rien renouveler du tout. La remédiation devient aveugle : une machine réinstallée sans indicateur extrait peut être reprise par le même vecteur, sans que la répétition soit reliée au premier événement. Aucun marqueur exploitable n’alimente la détection sur le reste du parc, et les échanges avec un assureur, un régulateur ou un partenaire se réduisent à une chronologie invérifiable, non opposable et non rejouable.

🦫 Explication de la marmotte 🍫

Un ordinateur utilise une mémoire de travail pour garder ce qui est en train de fonctionner. Cette mémoire disparaît quand la machine s’éteint. Lors d’un incident, il faut donc la copier avant d’arrêter ou de redémarrer la machine. Cette copie peut montrer les programmes actifs, leurs communications, des mots de passe temporaires et parfois des clés utilisées pour chiffrer des échanges ou des fichiers.

Le disque donne une autre information : il montre surtout les fichiers et traces conservés après l’exécution. Un programme malveillant peut fonctionner sans enregistrer de fichier durable. Dans ce cas, l’analyse du disque peut ne rien révéler, tandis que la mémoire contient encore le programme ou ses traces.

Les enregistrements réseau servent à examiner les échanges passés entre machines. Ils doivent être collectés avant l’incident, car il est impossible de recréer ensuite les messages qui n’ont pas été enregistrés. Ils permettent de retrouver une connexion, son heure, sa destination et parfois les données transférées. Si les échanges sont chiffrés, leur contenu reste caché sans les clés nécessaires.

L’ordre compte : isoler la machine sans l’éteindre, copier sa mémoire, puis copier ses disques. Une collecte modifie légèrement la machine, mais l’absence de collecte détruit définitivement les informations volatiles. Les copies obtenues doivent être chiffrées, contrôlées et conservées avec leurs empreintes pour éviter qu’elles soient modifiées ou qu’elles exposent des secrets.

Pages voisines

La citent

Analyse mémoire et réseau après un incident

Elle cite

Analyse mémoire et réseau après un incident

Analyse mémoire et réseau après un incident

Capture mémoire : l’état vivant que le disque ne contient pas

Artefacts RAM : processus, clés et connexions actives

Capture mémoire Linux reproductible

Analyse réseau : reconstruire ce qui a réellement circulé

Surface d’attaque et limites des preuves volatiles

Exploitation, rétention et reprise de collecte

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines