Artefacts live de /proc : processus, sockets, suppressions

Ce que c'est

/proc est un pseudo-système de fichiers généré à la demande par le noyau. Rien n'y est stocké sur disque : chaque lecture interroge le noyau sur l'état courant d'un processus, d'une table de sockets ou d'un sous-système du noyau. Sur un système live, c'est le moyen le plus rapide de voir ce qui tourne, d'où vient chaque processus et avec quoi il communique, et il résiste à certaines astuces anti-forensiques qui mettent en échec l'analyse du disque, comme un binaire supprimé après son lancement.

Comme il s'agit d'un état live, /proc se situe tout en haut de l'ordre de volatilité : collectez-le avant toute action qui modifie le système, idéalement en même temps qu'une image mémoire.

Où il se trouve

Les chemins sont identiques d'une distribution à l'autre. Sur les systèmes où /proc est monté avec hidepid=, les utilisateurs non root ne voient pas les processus des autres utilisateurs.

Ce qu'il prouve

• Quels processus existent en ce moment, leur arborescence parent-enfant, leurs identifiants d'utilisateur et de groupe, et leurs arguments.
• Quel binaire se trouve derrière chaque processus, même après suppression (exe -> /path (deleted)), et permet de récupérer ce binaire.
• L'exécution sans fichier : un exe pointant vers /memfd:<name> (deleted) montre un programme lancé depuis un fichier mémoire anonyme créé avec memfd_create.
• Quels fichiers, sockets et pipes chaque processus garde ouverts ; à quelles adresses distantes il est connecté (en joignant les numéros d'inode de /proc/net/* aux liens de fd/).
• Les variables d'environnement comme LD_PRELOAD, HISTFILE ou les réglages de proxy transmis à un processus.
• Non prouvé : quoi que ce soit sur les processus déjà terminés. Un rootkit noyau peut aussi filtrer ce qu'affiche /proc : comparez avec l'analyse mémoire.

Champs clés

Horodatages

Les fichiers sous /proc affichent l'heure à laquelle le noyau a créé l'inode pour le lecteur, et non le démarrage du processus : n'utilisez donc pas les heures de ls -l. Convertissez plutôt starttime : divisez par la fréquence des ticks d'horloge (getconf CLK_TCK, généralement 100) et ajoutez l'heure de démarrage du système (btime dans /proc/stat, secondes Unix UTC).

pid=1234
st=$(awk '{print $22}' /proc/$pid/stat)          # safe unless comm contains spaces
btime=$(awk '/^btime/{print $2}' /proc/stat)
date -u -d @$(( btime + st / $(getconf CLK_TCK) ))

ps -o lstart= -p <pid> donne la même valeur en heure locale.

Rétention

Aucune. Les entrées disparaissent à la fin du processus, et tout /proc est reconstruit au démarrage. Capturez-le avant toute action de confinement comme tuer des processus, redémarrer des services ou isoler le réseau (ce qui coupe les connexions).

Collecte

• UAC : les artefacts de réponse live enregistrent les listes de processus, les liens /proc/<pid>, les fichiers ouverts et /proc/modules ; son artefact live_response/process/deleted.yaml copie le binaire de tout processus dont l'exécutable apparaît comme (deleted) (20 premiers Mo), ainsi que les fichiers supprimés que ces processus gardent ouverts.
• Velociraptor : Linux.Sys.Pslist, Linux.Sys.Maps, Linux.Network.Netstat et artefacts apparentés sur un parc.
• Manuellement, avec des binaires de confiance :

# recover a deleted or memfd binary before the process ends
cp /proc/1234/exe /cases/host01/pid1234.bin && sha256sum /cases/host01/pid1234.bin
tr '\0' ' ' < /proc/1234/cmdline; echo
tr '\0' '\n' < /proc/1234/environ
ls -l /proc/1234/fd /proc/1234/cwd
ls -l /proc/[0-9]*/exe 2>/dev/null | grep -E '\(deleted\)|memfd:'

Réalisez aussi une image mémoire (voir LiME et AVML) : /proc répond à « que se passe-t-il maintenant », la mémoire permet de reposer la question plus tard.

Analyse

ps -eo pid,ppid,user,lstart,args --forest, ss -tanp, ss -xp et lsof -nP lisent /proc pour vous. Sur une image mémoire, Volatility 3 reconstitue la même vue hors ligne avec linux.pslist, linux.pstree, linux.psaux, linux.envars, linux.lsof, linux.proc.Maps et linux.sockstat.

Conseils d'investigation

• Un processus dont l'exe est (deleted) ou memfd: est une découverte prioritaire : des cas légitimes existent (mises à jour de paquets remplaçant un binaire en cours d'exécution), mais vérifiez d'abord l'historique des paquets.
• comm et argv[0] peuvent être modifiés par le processus ; fiez-vous plutôt à exe et aux fichiers mappés.
• Les processus dont le cwd se trouve dans /tmp, /var/tmp ou /dev/shm méritent un examen.
• Comparez la liste des PID de /proc avec la sortie de ps et avec la mémoire : une incohérence suggère un hooking userland (ld.so.preload) ou un rootkit noyau (modules noyau).
• Un lien root différent de / indique un chroot ou un conteneur ; associez-le à l'identifiant du conteneur avant de conclure (conteneurs).
• Notez l'horloge : les heures de collecte live n'ont de sens que si l'heure et le fuseau horaire de l'hôte sont capturés au même moment.