Qu’est-ce que l’analyse de malwares ?

Un binaire malveillant atterrit sur votre bureau. Peut-être qu’un EDR l’a mis en quarantaine, peut-être est-il arrivé en pièce jointe d’un e-mail, peut-être les équipes de réponse à incident l’ont-elles récupéré sur un serveur compromis. Quelqu’un doit savoir, vite et avec certitude : que fait ce programme, comment le retrouver partout ailleurs, et comment l’arrêter ?

L’analyse de malwares (logiciels malveillants) est la discipline qui répond à ces questions. La rétro-ingénierie — lire et comprendre un programme sans disposer de son code source — en est la compétence centrale. Ce parcours enseigne cette compétence à des fins défensives : détection, réponse à incident et renseignement sur la menace.

Ce que produit l’analyse

Personne ne rétro-ingénie un malware pour le plaisir. Chaque heure d’analyse doit se transformer en quelque chose d’exploitable par une autre équipe :

Livrable	Exploité par	Exemple
Indicateurs de compromission (IOC)	SOC, threat hunters	Empreintes de fichiers, domaines de C2, noms de mutex, clés de registre
Contenu de détection	Ingénieurs détection	Règles YARA, règles Sigma, requêtes EDR
Évaluation des capacités	Réponse à incident, direction	« Il vole les identifiants des navigateurs et peut télécharger d’autres charges utiles »
Recommandations de remédiation	Équipes d’exploitation IT	Emplacements de persistance à nettoyer, services à désactiver
Renseignement	Analystes CTI	Liens avec une famille connue, code partagé, réutilisation d’infrastructure

Gardez ce tableau en tête. C’est ce qui distingue l’analyste qui passe trois jours à rétro-ingénier intégralement un loader sans intérêt de celui qui extrait sa configuration C2 en une heure et remet au SOC une détection fonctionnelle avant le déjeuner.

Pourquoi les binaires sont difficiles

Lorsqu’un développeur compile un programme, l’essentiel de ce qui rendait le source lisible est jeté :

Les noms disparaissent. Noms de variables, la plupart des noms de fonctions et tous les commentaires ont disparu. Un binaire strippé (dépouillé de ses symboles) peut même ne pas nommer ses propres fonctions.
Les types disparaissent. Le processeur ne voit que des octets et des registres. Savoir si 8 octets à une adresse forment un pointeur, un double ou deux int, c’est à vous de le déduire.
La structure disparaît. Les boucles for, les instructions switch et les objets deviennent des sauts, des comparaisons et de l’arithmétique d’offsets. Le compilateur peut inliner, réordonner et fusionner le code de façon agressive.
Code et données se mélangent. Sur x86, les octets d’une instruction et ceux d’une chaîne ou d’une table de sauts peuvent se côtoyer, et rien dans le fichier n’indique de façon fiable qui est quoi.

Les malwares ajoutent par-dessus une couche délibérée : packing, chiffrement, obfuscation et astuces anti-analyse conçues pour vous faire perdre du temps. Une grande partie du catalogue de techniques de ce site documente ces astuces, et les leçons qui suivent montrent comment les analystes les déjouent.

Les trois façons d’examiner un échantillon

Analyse statique

Examiner le fichier sans l’exécuter. Cela va d’un triage de quelques secondes (empreintes, type de fichier, chaînes, imports) à des heures passées dans un désassembleur. L’analyse statique est sûre et, en principe, exhaustive — chaque instruction est sous vos yeux — mais elle est mise en échec par le packing et le chiffrement, car le code intéressant n’est pas présent dans le fichier sous une forme lisible.

Analyse dynamique

Exécuter l’échantillon dans un environnement contrôlé et observer ce qu’il fait : processus lancés, fichiers écrits, clés de registre modifiées, trafic réseau émis. La surveillance comportementale est rapide et passe outre le packing — l’échantillon se dépaquette lui-même pour vous. Sa faiblesse est la couverture : vous ne voyez que les chemins réellement exécutés, et un malware qui détecte la sandbox (bac à sable) peut tout simplement refuser d’agir.

Rétro-ingénierie du code

Lire le désassemblage ou le code décompilé, souvent en l’exécutant pas-à-pas dans un débogueur, pour comprendre la logique exacte : comment la configuration est déchiffrée, comment le protocole C2 est structuré, ce qui déclenche une charge utile destructrice. C’est le niveau le plus puissant et le plus coûteux, et il combine travail statique et dynamique.

Astuce : Statique et dynamique ne sont pas rivaux. Une vraie analyse alterne entre les deux : une session de débogage révèle une chaîne déchiffrée, que vous recherchez ensuite statiquement ; un coup d’œil statique aux imports vous indique où poser des points d’arrêt.

L’entonnoir d’analyse

L’effort ne doit croître que dans la mesure où les questions l’exigent. Un flux de travail pratique ressemble à un entonnoir :

text

  ┌──────────────────────────────────────────────────────────┐
  │ 1. Triage (minutes)                                        │
  │    hashes · file type · packer? · strings · imports        │
  │    known family? → reputation lookup, stop if answered     │
  └───────────────────────────┬──────────────────────────────┘
                              ▼
      ┌──────────────────────────────────────────────┐
      │ 2. Behavioural analysis (tens of minutes)     │
      │    sandbox / monitored VM · IOCs · persistence │
      └───────────────────────┬──────────────────────┘
                              ▼
          ┌──────────────────────────────────────┐
          │ 3. Targeted reversing (hours)         │
          │    unpack · config · crypto · C2      │
          └───────────────────┬──────────────────┘
                              ▼
              ┌──────────────────────────────┐
              │ 4. Full reversing (days)      │
              │    new family, full report    │
              └──────────────────────────────┘

La plupart des échantillons sortent à l’étape 1 ou 2. Savoir quand s’arrêter est aussi important que savoir aller plus loin.

Ce qu’il faut savoir pour aller plus loin

Tout le reste de ce parcours repose sur quelques fondations :

Comment un programme devient un binaire — compilation, édition de liens, symboles. Traité juste après dans Du code source au binaire.
Comment le système d’exploitation le charge — le loader, la mémoire virtuelle, les imports. Voir Comment un binaire est chargé et exécuté.
Le format de fichier — pour les malwares Windows, le format PE, qui fait l’objet d’un module entier commençant par Les en-têtes PE.
L’assembleur — inutile de l’écrire couramment, mais vous devez savoir le lire. La référence assembleur couvre les instructions que vous rencontrerez le plus souvent.

La défense d’abord

Ce parcours vise à comprendre les logiciels malveillants pour pouvoir les détecter, les contenir et les éliminer. Deux règles s’appliquent tout du long :

N’exécutez jamais un vrai échantillon sur une machine à laquelle vous tenez. La leçon suivante, Construire un laboratoire d’analyse sûr, met en place l’environnement isolé que supposent tous les labs ultérieurs.
Les labs de ce site utilisent des programmes bénins que vous compilez vous-même. Ils imitent les structures et les comportements des malwares — code packé, imports suspects, chaînes encodées — sans être nuisibles. Lorsque vous serez prêt pour de vrais échantillons, des dépôts publics comme MalwareBazaar existent, mais ne les manipulez qu’à l’intérieur de votre laboratoire.

Lab : votre premier triage, sur un fichier inoffensif

Ce lab ne nécessite pas encore de VM — vous ne faites que lire un fichier de confiance. Utilisez un shell Linux, macOS ou WSL.

Écrivez un petit programme C et compilez-le :

// hello.c
#include <stdio.h>
int main(void) {
    puts("connecting to update.example.com ...");
    return 0;
}

bash

gcc -O0 -o hello hello.c

Demandez au fichier ce qu’il est :
bash
```
file hello
sha256sum hello
```
Notez le format (ELF ou Mach-O), l’architecture, et s’il est strippé.
Cherchez du texte lisible :
bash
```
strings -n 6 hello | head -40
```
Retrouvez votre chaîne « update.example.com » au milieu du bruit du compilateur et des bibliothèques. Dans un vrai échantillon, c’est exactement ainsi qu’un domaine C2 codé en dur apparaît pour la première fois.
Strippez le binaire et comparez :
bash
```
cp hello hello-stripped && strip hello-stripped
ls -l hello hello-stripped
nm hello | head; nm hello-stripped
```
La copie strippée est plus petite et nm n’y trouve aucun symbole — la situation à laquelle vous ferez face avec presque tous les vrais échantillons.

Questions : Laquelle de vos quatre observations constituerait un IOC utile ? Lesquelles changeraient si l’auteur recompilait avec un autre compilateur ?

À retenir

L’analyse de malwares existe pour produire des IOC, des détections, des évaluations de capacités et des étapes de remédiation à destination d’autres équipes.
La compilation jette les noms, les types et la structure ; les auteurs de malwares y ajoutent une obfuscation délibérée.
L’analyse statique lit le fichier, l’analyse dynamique l’observe s’exécuter, et la rétro-ingénierie du code combine les deux pour retrouver la logique exacte.
Travaillez en entonnoir : triez tout, n’allez en profondeur que lorsque les questions l’exigent.

Objectifs