dans ce cours on va voir une méthodologie concrète pour analyser un système Windows suspect à l’aide de deux outils devenus classiques en analyse terrain : Process Explorer et Autoruns.
Le but ici n’est pas de faire de la théorie “générale malware” détachée du réel, mais de raisonner comme un analyste système qui cherche des incohérences concrètes sur une machine : processus anormaux, parent douteux, signature absente, DLL injectées, persistance multiple, ou encore écart entre ce qui est visible en exécution et ce qui est censé exister au démarrage.
Autrement dit, on ne cherche pas d’abord “un virus” comme une entité abstraite.
On cherche une anomalie logique dans l’état du système.
Objectif du cours
Ce cours a pour but de t’apprendre à :
- raisonner sur ce qui est normal ou anormal dans un système Windows
- utiliser Process Explorer pour analyser ce qui s’exécute réellement
- utiliser Autoruns pour comprendre les mécanismes de persistance
- corréler processus, modules, démarrage, signatures et comportement
- détecter des indices réalistes d’injection ou de rootkit user-mode
- éviter les erreurs classiques d’interprétation
Code: Select all
un malware peut mentir partiellement
mais il ment rarement de manière parfaitement cohérente partout
1) Comprendre les processus Windows avant toute analyse
Avant de chercher quelque chose de suspect, il faut d’abord connaitre le normal. C’est probablement la partie la plus importante du travail. Quelqu’un qui ne sait pas à quoi ressemble un système Windows sain verra des “malwares” partout, ou au contraire manquera les vrais signaux forts.
1.1 Processus système légitimes : base minimale
Quelques processus système typiques qu’il faut reconnaitre rapidement :
- System
- smss.exe
- csrss.exe
- wininit.exe
- services.exe
- lsass.exe
- svchost.exe
- explorer.exe
- winlogon.exe
- RuntimeBroker.exe
- dwm.exe
- le chemin réel du binaire
- la signature numérique
- la cohérence parent / enfant
- le contexte de session
- le comportement mémoire ou les modules chargés
- un lsass.exe hors de System32 est extrêmement suspect
- un svchost.exe lancé depuis AppData ou Public est suspect
- un nom système correct mais dans le mauvais chemin est souvent plus révélateur qu’un faux nom grossier
- les processus critiques Microsoft ont en général une hiérarchie cohérente et une signature cohérente
- C:\Users\...
- C:\Users\Public\...
- C:\ProgramData\...
- C:\Temp\...
- AppData\Roaming\...
1.2 Le nom seul ne veut rien dire
Un malware user-mode se trahit souvent par l’une des stratégies suivantes :
- imiter un nom légitime
- utiliser un nom aléatoire
- se cacher derrière un chemin plausible
- injecter son code dans un binaire réel
- svch0st.exe
- expl0rer.exe
- lsasss.exe
- scvhost.exe
- xYp9Q.exe
- a8f3.exe
- kqjv.exe
- un binaire non signé n’est pas automatiquement malveillant
- un binaire signé n’est pas automatiquement sain
Code: Select all
nom
+ chemin
+ signature
+ parent
+ persistance
+ modules
+ comportement
= jugement plus fiable
Beaucoup d’analyses rapides oublient le parent process, alors que c’est souvent l’un des signaux les plus parlants.
Questions à se poser :
- qui a lancé ce processus
- est-ce normal dans cette session
- la chaîne de création a-t-elle du sens
Code: Select all
explorer.exe
└── svch0st.exe
└── powershell.exe
En pratique, la hiérarchie parent / enfant est un excellent outil d’analyse initiale.
2) Analyse avec Process Explorer
Process Explorer est l’un des meilleurs outils pour comprendre ce qui tourne réellement dans le système. Il donne une vision plus riche que le Gestionnaire des tâches classique : arborescence, chemins, signatures, handles, threads, DLL, consommation mémoire, etc.
Ce qu’il faut regarder en priorité :
- l’arbre des processus
- le chemin réel de l’image
- la signature
- les DLL chargées
- les handles ou objets ouverts si besoin
- les threads et l’activité anormale
La Process Tree View est fondamentale.
C’est souvent la première chose à analyser, parce qu’elle donne la généalogie logique du processus.
Questions utiles :
- ce parent est-il logique
- ce processus devrait-il vraiment exister dans cette session
- est-ce cohérent avec la manière normale dont Windows lance ce type de programme
- un binaire système enfant d’un processus utilisateur non cohérent
- une chaîne Office → cmd.exe → powershell.exe → script
- un processus lancé depuis un emplacement utilisateur alors qu’il imite un service système
- plusieurs descendants suspects créés à partir d’un parent inhabituel
Le chemin du binaire est un signal majeur.
Toujours vérifier :
- le chemin complet
- la date de création ou de modification
- l’emplacement du fichier
- la cohérence avec la nature du processus
- C:\Users\Public\
- C:\ProgramData\
- C:\Users\<user>\AppData\Roaming\
- C:\Users\<user>\AppData\Local\Temp\
- C:\Temp\
- un malware injecté dans explorer.exe aura le chemin légitime d’explorer.exe
- un processus compromis peut donc paraitre sain si on ne regarde que son image path
Code: Select all
chemin légitime ≠ mémoire saine
Dans Process Explorer, la signature est un indicateur très utile.
Ce qu’il faut vérifier :
- éditeur
- présence ou absence de signature
- cohérence entre le nom du binaire et le signataire
Une absence de signature sur un composant qui prétend etre système est un signal fort.
Mais il faut éviter les raccourcis simplistes :
- un malware peut utiliser un binaire signé vulnérable ou détourné
- un outil maison légitime peut etre non signé
2.4 Détection d’injection via les DLL
Un malware user-mode ou un injecteur se trahit souvent par ses modules chargés.
Scénarios fréquents :
- injection dans explorer.exe
- injection dans un navigateur
- injection dans svchost.exe
- injection dans RuntimeBroker.exe
- injection dans un processus à forte visibilité utilisateur
Dans Process Explorer, l’onglet DLLs est capital.
Ce qu’il faut regarder :
- DLL non Microsoft chargée dans un processus très système
- DLL chargée depuis AppData, Temp, ProgramData, Public
- module sans signature
- module présent dans plusieurs processus sans raison claire
- nom de DLL étrange ou trop générique
- une DLL inconnue injectée dans explorer.exe, chrome.exe et RuntimeBroker.exe
- une DLL non signée chargée dans lsass.exe ou svchost.exe
- une DLL au nom flou du style helper32.dll ou mscoreui.dll hors emplacement attendu
2.5 Rootkits user-mode : ce qu’ils cachent vraiment
Un rootkit user-mode ne devient pas invisible au noyau. Il agit surtout au niveau des API ou de la présentation des données.
Techniques classiques :
- API hooking
- filtrage de listes retournées par l’API
- injection de DLL dans les outils d’inspection
- masquage partiel de fichiers, processus ou clés registre
- processus visible dans un outil mais pas un autre
- DLL inconnue injectée dans plusieurs processus
- incohérences entre Process Explorer, Task Manager et d’autres outils
- hooks ou modules étranges autour de ntdll.dll ou d’APIs critiques
Code: Select all
un rootkit user-mode ne peut pas tout rendre cohérent partout
2.6 Vérifier les handles, threads et comportement secondaire
Même si le cœur de l’analyse rapide repose sur l’arbre et les DLL, Process Explorer permet aussi d’aller plus loin :
- handles ouverts
- threads
- activité CPU anormale
- pics mémoire
- usage disque ou réseau anormal selon le moment
- maintient des handles vers des emplacements suspects
- crée beaucoup de threads courts ou anormaux
- consomme du CPU sans raison visible
- reste résident avec une activité faible mais une forte persistance
Process Explorer répond surtout à la question :
Code: Select all
qu’est-ce qui tourne maintenant
Code: Select all
comment cela revient au redémarrage
C’est un outil fondamental en analyse terrain, parce qu’un malware un peu sérieux ne se contente pas d’exécuter un binaire une fois. Il cherche à revenir.
3.1 Première règle : réduire le bruit
Dans Autoruns, la première étape pratique consiste souvent à :
- activer Hide Microsoft Entries
- trier par Publisher
- regarder ce qui reste
- cela retire une énorme partie du bruit légitime
- cela rend plus visible l’anormal
- cela évite de perdre du temps sur des composants Microsoft attendus
- éditeur inconnu
- signature absente
- chemin douteux
- composant présent au démarrage sans raison claire
Les grandes zones à surveiller sont :
- Run / RunOnce
- Services
- Scheduled Tasks
- Winlogon
- Explorer
- AppInit DLLs
- KnownDLLs ou extensions shell selon le cas
- Drivers si l’analyse l’exige
Dans beaucoup de cas réels, un malware sérieux n’utilise pas une seule persistance.
Il peut combiner :
- Run key
- Scheduled Task
- Service
- DLL chargée par un composant utilisateur
3.3 Les services et tâches planifiées
Deux zones sont particulièrement importantes en pratique :
- les services
- les tâches planifiées
- elles permettent une persistance robuste
- elles paraissent plus “système”
- elles sont souvent moins visibles à l’utilisateur
- nom de service trompeur
- description floue
- binaire non signé
- chemin vers AppData, ProgramData, Temp, Public
- Scheduled Task exécutant PowerShell, cmd ou un script dans un répertoire utilisateur
Autoruns peut aider à consulter VirusTotal ou au moins corréler un hash avec une réputation.
C’est utile, mais il faut bien garder une règle simple :
Code: Select all
VirusTotal = indice, pas preuve absolue
- 0 détection ne garantit pas que le fichier est sain
- un malware récent ou très ciblé peut être inconnu
- certaines détections peuvent être fausses
3.5 Rootkits user-mode et masquage du registre
Certains malwares user-mode peuvent essayer de masquer des éléments de persistance en filtrant la vue du registre ou de certaines zones de démarrage.
Indices possibles :
- différence entre ce que voit Autoruns et ce qu’on voit dans une autre méthode
- fichier présent mais persistance “introuvable”
- processus actif mais point d’entrée démarrage difficile à expliquer
- incohérence entre analyse live et analyse offline
La bonne logique est toujours :
- corréler
- recouper
- chercher les incohérences
L’erreur fréquente du débutant consiste à ouvrir un outil, voir quelque chose de bizarre, puis conclure trop vite. Une vraie analyse suit plutot un ordre méthodique.
Ordre recommandé :
- 1. Process Explorer
arbre des processus, signature, image path, modules, DLL injectées, parent / enfant - 2. Autoruns
persistance, éditeur, signature, emplacements de démarrage, tâches, services, vérification éventuelle VirusTotal - 3. Corrélation
faire le lien entre processus observé en mémoire et mécanisme de persistance - 4. Hypothèse
injection ? persistance multiple ? faux processus système ? rootkit user-mode ? simple logiciel légitime un peu sale ?
5) Corrélation : là où l’analyse devient solide
Un bon analyste ne s’arrête jamais à un seul signe. Il cherche une chaîne logique.
Exemples de corrélations utiles :
- un processus non signé trouvé dans Process Explorer ↔ une clé Run correspondante dans Autoruns
- une DLL injectée dans explorer.exe ↔ un chargeur persistant au démarrage
- un service suspect ↔ un binaire non signé dans ProgramData
- une tâche planifiée étrange ↔ un powershell.exe lancé régulièrement
- un parent anormal ↔ un enfant au nom trompeur ↔ une persistance associée
6) Ce qu’un analyste cherche vraiment
L’analyste efficace ne cherche pas d’abord “un virus”. Il cherche :
- une incohérence logique
- un écart par rapport au comportement normal du système
- une relation parent / enfant impossible ou douteuse
- un module injecté là où il ne devrait pas être
- une persistance injustifiée
- une absence de signature là où elle devrait exister
7) Erreurs classiques à éviter
Il y a plusieurs erreurs très fréquentes en analyse utilisateur :
- penser qu’un fichier non signé est forcément malveillant
- penser qu’un fichier signé est forcément sain
- se fier uniquement au nom du processus
- oublier de vérifier le chemin réel
- ignorer le parent process
- analyser la persistance sans corréler avec l’exécution mémoire
- croire qu’un seul outil donne toute la vérité
- prendre VirusTotal comme verdict absolu
8) Limites de la méthode
Il faut rester honnête : Process Explorer et Autoruns sont très puissants, mais ils ne suffisent pas à tout.
Ils sont excellents pour :
- analyse rapide
- hunting user-mode
- persistance
- diagnostic de base à intermédiaire
- kernel rootkits
- drivers malveillants
- manipulations mémoire plus avancées
- tampering profond du système
- analyse mémoire
- outils kernel
- logs ETW
- offline triage
- forensic plus poussée
Les idées essentielles de ce cours sont les suivantes :
- avant de chercher le malveillant, il faut connaitre le normal
- le nom seul d’un processus ne suffit jamais
- le parent process est souvent l’un des meilleurs indices
- la signature est un signal fort, mais pas une preuve absolue
- les DLL injectées trahissent souvent les malwares user-mode
- Autoruns permet de comprendre comment une menace survit aux redémarrages
- la vraie force de l’analyse vient de la corrélation entre exécution mémoire et persistance
- un malware ne peut généralement pas tout rendre cohérent partout
Process Explorer montre ce qui s’exécute réellement en mémoire.
Autoruns montre ce qui revient au démarrage.
Ensemble, ils forment une base extrêmement solide pour l’analyse d’un système Windows suspect.
Un analyste efficace ne cherche pas un “virus” au sens abstrait.
Il cherche une anomalie logique dans la machine : un faux parent, une signature incohérente, un chemin douteux, une DLL injectée, une persistance injustifiée.
Et c’est précisément là que la compréhension du système fait toute la différence.
Quand tu comprends bien Windows, beaucoup de malwares user-mode deviennent beaucoup plus faciles à repérer, parce qu’ils finissent presque toujours par casser une cohérence quelque part.
