Surveillance comportementale

Le triage statique vous dit ce qu’un échantillon pourrait faire. L’exécuter vous dit ce qu’il fait — du moins sur cette machine, ce jour-là, dans le temps que vous lui avez accordé. Cette nuance est tout l’art de la surveillance comportementale. Une exécution est une expérience et, comme toute expérience, elle ne vaut quelque chose que si vous maîtrisez les conditions de départ, que vous enregistrez tout pendant qu’elle se déroule et que vous pouvez comparer le résultat à une référence connue.

Cette leçon transforme le laboratoire de Construire un laboratoire d’analyse sûr en instrument de mesure. Vous savez déjà, grâce à Processus, threads et DLL, ce que signifient les objets à l’écran ; ici, l’accent est mis sur la capture de leur historique et sur sa distillation en indicateurs. La leçon compagne, Simuler et capturer le trafic réseau, couvre la moitié réseau de la même exécution.

La routine de détonation

Chaque exécution doit suivre les mêmes sept étapes, dans le même ordre. La routine est volontairement ennuyeuse : quand quelque chose d’inattendu apparaît, vous voulez être sûr que cela vient de l’échantillon et non d’une étape que vous avez sautée.

Pendant l’exécution, gardez Process Explorer ou System Informer ouvert pour saisir ce que les journaux montrent mal : un processus qui reste résident, une fenêtre qu’il ouvre, ou un échantillon qui ne s’est pas terminé parce qu’il attend quelque chose.

Deux détails décident si la routine fonctionne en pratique. D’abord, les artefacts doivent quitter la VM avant l’étape 7 : journaux, fichiers PML, diff de registre et fichiers déposés partent vers la machine auxiliaire REMnux par le réseau interne, jamais par un dossier partagé, et les exécutables déposés voyagent dans une archive protégée par le mot de passe infected, comme n’importe quel autre échantillon. Ensuite, écrivez le plan avant l’étape 4 : combien de temps vous attendrez, si vous redémarrerez, sur quoi vous cliquerez. Un plan écrit avant l’exécution vous garde honnête quand vous lisez les résultats.

Astuce : Tenez un fichier texte par échantillon avec le SHA-256, le nom du snapshot, les heures de début et de fin, et tout ce que vous avez fait à la main pendant l’exécution. Ce sont les horodatages de ce fichier qui vous permettent ensuite d’aligner Procmon, Sysmon et la capture de paquets.

Process Monitor

Process Monitor enregistre l’activité du système de fichiers, du registre, des processus/threads et du réseau depuis un pilote noyau, avec une trace de pile pour chaque événement. C’est la vue la plus fine dont vous disposiez sans débogueur, et elle produit beaucoup de données : une machine Windows au repos génère des milliers d’événements par seconde.

Capturer sans se noyer

Les filtres de Procmon ne contrôlent que ce qui est affiché ; chaque événement est tout de même conservé, si bien que vous pouvez élargir le filtre plus tard sans relancer l’échantillon — au prix de la mémoire sur une longue exécution. Deux réglages aident :

• File → Backing Files écrit les événements dans un fichier PML sur disque au lieu du fichier d’échange. Pointez-le vers un dossier que vous exporterez.
• Filter → Drop Filtered Events écarte, au moment de la capture, les événements qui ne passent pas le filtre. Ne l’utilisez qu’une fois que vous avez confiance dans votre filtre, car les événements écartés sont perdus pour de bon.

Pour des exécutions reproductibles, pilotez Procmon en ligne de commande :

# Start capturing to a backing file, minimised, with a saved filter set
Procmon64.exe /AcceptEula /Quiet /Minimized /LoadConfig C:\analysis\lab.pmc /BackingFile C:\analysis\run1.pml

# ... run the sample, wait ...

Procmon64.exe /Terminate
# Convert the log to CSV for scripting
Procmon64.exe /OpenLog C:\analysis\run1.pml /SaveAs C:\analysis\run1.csv

Les filtres qui comptent

Partez d’un filtre sur l’échantillon et élargissez-le à mesure que l’arbre de processus grandit :

Tools → Process Tree montre chaque processus ayant existé pendant la capture, y compris ceux qui se sont déjà terminés, avec leurs lignes de commande. Commencez par là : cela vous indique quels noms de processus ont leur place dans votre filtre. Tools → File Summary et Registry Summary donnent ensuite des compteurs par chemin, un moyen rapide de repérer le répertoire que l’échantillon a martelé.

Les opérations à lire

Les opérations en échec sont aussi des preuves. Un NAME NOT FOUND sur une clé de registre ou un fichier que l’échantillon vérifie en début d’exécution est souvent une vérification de l’environnement ou un marqueur d’infection : l’échantillon demande « suis-je déjà passé par ici ? » ou « est-ce une machine d’analyse ? ».

Sauvegarder les preuves

Sauvegardez la capture au format PML natif (File → Save, tous les événements) avant de restaurer. Un PML peut être rouvert sur n’importe quelle machine Windows avec un autre filtre, ce qui est impossible avec un CSV. Exportez à côté un CSV filtré pour vos notes et vos scripts.

Sysmon avec une configuration communautaire

Procmon est un microscope que vous allumez pour une exécution. Sysmon est une boîte noire : un service et un pilote qui écrivent des événements choisis dans le journal Microsoft-Windows-Sysmon/Operational, avec des valeurs ProcessGuid stables qui survivent à la réutilisation des PID. C’est aussi la télémétrie que beaucoup de SOC collectent en production, ce qui en fait la source naturelle des détections que vous transmettez.

Sans configuration, Sysmon journalise peu ; avec une configuration verbeuse, il journalise trop. Partez d’une configuration communautaire maintenue — sysmon-config de SwiftOnSecurity ou sysmon-modular d’Olaf Hartong — et installez-la une fois, dans le snapshot propre :

Sysmon64.exe -accepteula -i C:\tools\sysmonconfig.xml
# Later, update the config without reinstalling
Sysmon64.exe -c C:\tools\sysmonconfig.xml

Les Event ID que vous utiliserez le plus :

Interrogez l’exécution avec PowerShell, en partant de l’heure de début notée :

$start = Get-Date '2026-09-29 14:02:00'
Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-Sysmon/Operational'
    StartTime = $start
} | Select-Object TimeCreated, Id, Message | Format-List

# Keep a copy of the raw log for later
wevtutil epl Microsoft-Windows-Sysmon/Operational C:\analysis\run1.evtx

Attention : Les configurations communautaires sont réglées pour la production, où le bruit coûte de l’argent. Elles excluent délibérément de nombreux chemins de fichiers et de registre. Un journal Sysmon silencieux prouve seulement que rien ne correspondait à la configuration, pas que rien ne s’est passé. Procmon est votre vérité de terrain ; Sysmon montre ce que le capteur d’un défenseur aurait capté.

Diffs avant/après

Les moniteurs en direct montrent des événements ; les diffs montrent le changement net. Un échantillon qui écrit une clé puis la supprime laisse une trace dans Procmon mais aucun diff ; un changement effectué par un processus que vous avez oublié d’inclure dans votre filtre Procmon apparaît quand même dans le diff. Utilisez les deux.

Snapshots du registre

Regshot est l’outil classique : 1st shot avant l’exécution, 2nd shot après, Compare pour obtenir un rapport texte ou HTML des clés et valeurs ajoutées, supprimées et modifiées. Il est ancien mais fonctionne toujours, et il peut inclure une arborescence de répertoires dans l’analyse. Attendez-vous à du bruit — graines aléatoires, listes MRU, horodatages que Windows met à jour de lui-même — et apprenez ce que votre VM propre modifie toute seule en faisant une exécution sans aucun échantillon.

Comparaison des démarrages automatiques

Autoruns connaît tous les endroits d’où Windows lance du code — clés Run, services, tâches planifiées, abonnements WMI, extensions de Winlogon et d’Explorer, pilotes, et plus encore. Sa version console produit un CSV que vous pouvez comparer entre la référence et l’après-exécution :

autorunsc64.exe -accepteula -nobanner -a * -c -h -s > C:\analysis\autoruns-before.csv
# ... run ...
autorunsc64.exe -accepteula -nobanner -a * -c -h -s > C:\analysis\autoruns-after.csv
Compare-Object (Get-Content C:\analysis\autoruns-before.csv) (Get-Content C:\analysis\autoruns-after.csv)

L’interface graphique peut faire de même avec File → Compare contre un fichier .arn sauvegardé, en surlignant les nouvelles entrées. Toute nouvelle entrée est un mécanisme de persistance candidat ; la leçon Mécanismes de persistance recense ce que signifie chaque emplacement.

Sandbox automatisées

Une sandbox (bac à sable) exécute la même routine pour vous : snapshot, détonation, enregistrement, rapport, restauration. CAPE, le descendant open source de Cuckoo, ajoute le dump de charges utiles et l’extraction de configuration ; les services commerciaux et hébergés ajoutent la finition, le passage à l’échelle, les sessions interactives et le renseignement partagé. Comme le montre la leçon Construire une chaîne d’analyse, elles s’intègrent naturellement comme étape de détonation d’un flux de travail automatisé.

Leurs limites sont celles de toute exécution sans surveillance, amplifiées :

• Des budgets de temps fixes. Quelques minutes par échantillon. Tout ce qui attend plus longtemps est manqué, et les astuces qu’utilisent les sandbox pour raccourcir les pauses sont elles-mêmes détectables (détection de l’accélération du sommeil).
• Des environnements reconnaissables. Les images de sandbox sont partagées par de nombreux clients, et les échantillons en relèvent l’empreinte — artefacts d’hyperviseur, absence de fichiers récents, aucun mouvement de souris (vérifications d’activité utilisateur).
• Aucun contexte. La sandbox ne connaît ni les arguments de ligne de commande, ni le document parent, ni l’appartenance au domaine qu’attend l’échantillon.
• La divulgation. Soumettre à un service public partage l’échantillon, et souvent son rapport, avec tout le monde — y compris l’attaquant, qui peut surveiller ses propres hachages. Vérifiez la politique de votre organisation avant de soumettre quoi que ce soit issu d’un incident.

Un rapport de sandbox est un excellent premier regard et un piètre dernier mot. Quand sa sortie est maigre, c’est une raison d’exécuter l’échantillon vous-même, pas un verdict.

Des événements aux IOC hôte

L’exécution est terminée lorsque ses observations sont consignées sous une forme que d’autres peuvent utiliser. Regroupez-les par type :

Pour chaque indicateur, notez s’il est stable (identique à chaque exécution et chez chaque victime) ou généré (noms aléatoires, GUID par hôte). Exécutez l’échantillon deux fois depuis le même snapshot, ou une fois sur une seconde VM avec un autre nom d’utilisateur ; tout ce qui change est un motif, pas un IOC littéral. Le format de rapport de triage du module 3 prévoit de la place pour les deux.

Pièges courants

L’échantillon attend. De longues pauses, une vérification de date, ou l’attente d’un redémarrage ou d’une connexion utilisateur produisent toutes une exécution vide. Regardez les derniers événements Procmon du processus : un thread garé dans un appel de pause ou d’attente est un indice. Des vérifications de temps comme les écarts de GetTickCount peuvent aussi remarquer une horloge accélérée.

L’échantillon vérifie l’environnement. Une sortie propre après une rafale de lectures d’informations sur le matériel, le BIOS ou la liste des processus est la signature d’une vérification d’évasion comme le bit hyperviseur de CPUID ou un test du processus parent. La leçon prévue Anti-VM et évasion de sandbox explique comment les neutraliser.

L’échantillon a besoin de quelque chose de votre part. Des arguments de ligne de commande, un nom de fichier précis, un lancement par un document ou — pour les DLL — un chargement via le bon export avec rundll32.exe dllname,Export. Le triage statique des chaînes et des exports dit généralement ce qu’il attend.

L’activité est attribuée à quelqu’un d’autre. Après une injection ou un process hollowing, les écritures intéressantes viennent d’explorer.exe ou de svchost.exe. Si le processus de l’échantillon devient silencieux, élargissez le filtre à tout le système pour la fenêtre de temps et suivez les handles qu’il a ouverts.

Vous êtes repéré. Certains échantillons cherchent Procmon64.exe ou Wireshark dans la liste des processus. Renommer les outils suffit contre les vérifications naïves ; Déboguer un malware avec x64dbg et Tracer les appels d’API et les appels système montrent comment trouver la vérification elle-même.

Lab : enregistrer l’empreinte d’un programme inoffensif

Ce lab utilise un programme bénin que vous compilez vous-même. Il crée un répertoire et un fichier sous %TEMP%\LabDemo, écrit une valeur sous HKCU\Software\LabDemo, puis se termine — un dropper miniature, sans la malveillance.

1. Écrivez-le et compilez-le sur n’importe quelle machine disposant de mingw-w64 :

   // labdemo.c — benign behaviour for a monitoring exercise:
   // creates %TEMP%\LabDemo\marker.txt and HKCU\Software\LabDemo\RunCount, then exits.
   #include <windows.h>
   #include <stdio.h>
   
   int main(void) {
       char dir[MAX_PATH], path[MAX_PATH];
       DWORD n = GetTempPathA(MAX_PATH, dir);
       if (n == 0 || n > MAX_PATH - 32) return 1;
   
       lstrcatA(dir, "LabDemo");
       CreateDirectoryA(dir, NULL);                 /* ok if it already exists */
       wsprintfA(path, "%s\\marker.txt", dir);
   
       HANDLE f = CreateFileA(path, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS,
                              FILE_ATTRIBUTE_NORMAL, NULL);
       if (f == INVALID_HANDLE_VALUE) return 2;
       const char msg[] = "LabDemo was here\r\n";
       DWORD written;
       WriteFile(f, msg, sizeof msg - 1, &written, NULL);
       CloseHandle(f);
   
       HKEY key;
       if (RegCreateKeyExA(HKEY_CURRENT_USER, "Software\\LabDemo", 0, NULL, 0,
                           KEY_SET_VALUE, NULL, &key, NULL) != ERROR_SUCCESS)
           return 3;
       DWORD one = 1;
       RegSetValueExA(key, "RunCount", 0, REG_DWORD, (const BYTE *)&one, sizeof one);
       RegCloseKey(key);
   
       printf("LabDemo: wrote %s and HKCU\\Software\\LabDemo\\RunCount\n", path);
       return 0;
   }

   x86_64-w64-mingw32-gcc -O1 -s -o labdemo.exe labdemo.c
   file labdemo.exe
   shasum -a 256 labdemo.exe

   Sur la machine de compilation utilisée pour cette leçon (votre hachage différera avec une autre version du compilateur) :

   labdemo.exe: PE32+ executable (console) x86-64 (stripped to external PDB), for MS Windows
   a8624ff5f3f3b330e302cd2faa0645748a0d0cd02af73221e8bc54f3051beea5  labdemo.exe

2. Prédisez avant d’exécuter. Listez les imports et les chaînes qui décrivent son comportement :

   x86_64-w64-mingw32-objdump -p labdemo.exe | grep -E 'Reg|CreateDirectory|CreateFile|WriteFile|GetTempPath'
   x86_64-w64-mingw32-strings -n 6 labdemo.exe | grep -iE 'labdemo|marker|software'

   Sortie abrégée :

   	000082e0  <none>  0266  RegCloseKey
   	000082e8  <none>  026e  RegCreateKeyExA
   	000082f0  <none>  02b3  RegSetValueExA
   	00008308  <none>  00c9  CreateDirectoryA
   	00008310  <none>  00d7  CreateFileA
   	00008330  <none>  0325  GetTempPathA
   	00008370  <none>  0648  WriteFile
   LabDemo
   %s\marker.txt
   Software\LabDemo
   LabDemo: wrote %s and HKCU\Software\LabDemo\RunCount

   À partir de cela seulement, notez ce que vous vous attendez à voir dans Procmon : un répertoire et un fichier créés dans le dossier temporaire de l’utilisateur, 18 octets écrits, et une valeur REG_DWORD écrite sous HKCU\Software\LabDemo. Pas de réseau, pas de processus enfant, pas de persistance.

3. Snapshot et référence. Dans la VM d’analyse Windows, restaurez le snapshot propre, copiez-y labdemo.exe et enregistrez la référence : 1st shot de Regshot (cochez Scan dir et indiquez %TEMP%), autorunsc64 vers autoruns-before.csv, et l’heure courante dans votre fichier de notes.

4. Enregistrez. Lancez Procmon avec un fichier de sauvegarde, videz l’affichage et posez le filtre Process Name is labdemo.exe. Vérifiez que Sysmon tourne avec Get-Service Sysmon64.

5. Exécutez labdemo.exe depuis une invite de commandes, attendez dix secondes, puis arrêtez la capture Procmon et sauvegardez-la sous labdemo.pml.

6. Lisez Procmon. Trouvez le CreateFile sur le répertoire LabDemo, les CreateFile et WriteFile sur marker.txt (vérifiez la Length dans la colonne de détail), et la paire RegCreateKey / RegSetValue sous HKCU\Software\LabDemo. Double-cliquez sur l’événement RegSetValue et vérifiez le type et les données. Retirez ensuite brièvement le filtre et regardez combien d’événements le reste du système a produits pendant les mêmes dix secondes.

7. Lisez Sysmon. Interrogez le journal à partir de votre heure de début. Vous devriez trouver un Event 1 pour labdemo.exe avec ses hachages. Vérifiez si l’Event 11 (création de fichier) et l’Event 13 (écriture de valeur de registre) apparaissent — avec une configuration réglée pour la production, il est fort possible que non, car %TEMP%\*.txt et une clé HKCU quelconque ne font pas partie des emplacements que ces configurations surveillent.

8. Faites le diff. Prenez le 2nd shot de Regshot puis Compare ; relancez autorunsc64 et comparez les CSV. Le diff du registre doit lister la nouvelle clé et la nouvelle valeur ; le diff des démarrages automatiques doit être vide.

9. Exportez et restaurez. Copiez le PML, l’export EVTX, les deux diffs et vos notes vers REMnux, puis restaurez la VM.

Questions : Quelles actions de LabDemo votre configuration Sysmon a-t-elle enregistrées, et qu’ajouteriez-vous à la configuration pour capter le reste ? Pourquoi le diff d’Autoruns était-il vide alors que le registre a changé ? Si LabDemo supprimait marker.txt juste avant de se terminer, laquelle de vos trois sources (Procmon, Sysmon, Regshot) montrerait encore que le fichier a existé ? Rédigez les IOC hôte de LabDemo sous forme de tableau, en marquant chacun comme stable ou généré.

À retenir

• Une exécution comportementale est une expérience : restaurer, établir la référence, enregistrer, exécuter, arrêter, comparer, restaurer — de la même façon à chaque fois, avec des notes et des horodatages.
• Process Monitor est la vérité de terrain d’une exécution ; sauvegardez le PML complet, filtrez en partant de l’arbre de processus vers l’extérieur, et lisez les opérations en échec autant que les écritures.
• Sysmon avec une configuration communautaire montre ce qu’un capteur de production verrait ; un journal silencieux reflète autant la configuration que l’échantillon.
• Les diffs du registre et d’Autoruns révèlent le changement net et la persistance que les vues en direct manquent.
• Les sandbox automatisent la routine mais en partagent les angles morts : exécutions courtes, environnements identifiables et absence de contexte.
• Une exécution vide est une trouvaille à expliquer — attente, vérifications de l’environnement, arguments manquants ou injection — et non la preuve d’un fichier inoffensif.