Construire un laboratoire d’analyse sûr

L’analyse statique se contente de lire un fichier ; en principe, elle est donc sûre n’importe où. Mais dès l’instant où vous exécutez un échantillon — ou l’ouvrez dans un outil dont le parseur a un bug, ou double-cliquez dans la mauvaise fenêtre —, vous exécutez le code hostile de quelqu’un d’autre. Un laboratoire est l’ensemble des murs qui rendent cela acceptable : quand l’échantillon fait le pire, il le fait sur une machine jetable qui ne communique avec rien de réel.

Cette leçon construit l’environnement que supposent tous les labs ultérieurs de ce parcours. Cela prend un après-midi une fois, puis quelques secondes de vérification avant chaque session.

Le modèle de menace

Avant de choisir des outils, soyez clair sur ce dont vous vous protégez. Un échantillon exécuté dans votre laboratoire peut tenter de :

La dernière ligne n’est pas un risque de sécurité, mais elle façonne votre laboratoire. Un malware qui détecte une machine virtuelle peut tout simplement ne rien faire. Le catalogue de techniques documente de nombreuses vérifications de ce type, du bit hyperviseur de CPUID au port d’E/S backdoor de VMware. Vous apprendrez à les reconnaître et à les contourner ; vous ne devez jamais « corriger » la détection en exécutant des échantillons sur une machine physique connectée à un vrai réseau.

Attention : Les évasions de machine virtuelle existent, mais ce sont des exploits rares et précieux que les malwares courants n’embarquent presque jamais. Les façons réalistes dont un échantillon quitte un laboratoire sont banales : un dossier partagé resté activé, une carte réseau en mode pont, ou un analyste qui copie un fichier vers l’extérieur sans réfléchir. L’essentiel de cette leçon consiste à fermer ces portes.

Architecture

La disposition recommandée consiste en deux machines virtuelles sur un réseau virtuel privé, sans aucune carte connectée à quoi que ce soit de réel :

  ┌──────────────────────── Host machine ────────────────────────┐
  │                                                               │
  │   ┌──────────────────┐   internal network   ┌──────────────┐  │
  │   │  Windows analysis │   "malnet"          │   REMnux      │  │
  │   │  VM (FLARE-VM)    │◄───────────────────►│   INetSim     │  │
  │   │  10.0.0.10        │   10.0.0.0/24        │   10.0.0.1    │  │
  │   │  gw/DNS=10.0.0.1  │                      │   fake DNS,   │  │
  │   └──────────────────┘                      │   HTTP, SMTP  │  │
  │                                              └──────────────┘  │
  │          no NAT · no bridge · no shared folders · no clipboard │
  └───────────────────────────────────────────────────────────────┘
                    ✕ no path to the real LAN / internet

• La VM d’analyse Windows est celle où s’exécutent les échantillons. La plupart des malwares que vous rencontrerez ciblent Windows ; c’est donc votre poste de travail principal.
• La VM REMnux est un auxiliaire Linux. Elle se fait passer pour internet — elle répond aux requêtes DNS, sert de fausses réponses HTTP, accepte le SMTP — et capture le trafic. Elle héberge aussi des outils Linux pour l’analyse statique de documents, de scripts et de fichiers ELF.

Pour des sessions rapides, une alternative consiste à exécuter FakeNet-NG directement dans la VM Windows. Il intercepte localement le trafic sortant et y répond avec de faux services, si bien qu’une VM unique sans aucune carte réseau peut quand même vous montrer ce qu’un échantillon tente de contacter.

Choisir le mode réseau

Chaque hyperviseur nomme ses modes à sa façon. Ce qui compte, c’est où les paquets peuvent aller :

Préférez un réseau interne. Le mode privé hôte est acceptable, mais il laisse l’interface virtuelle de votre hôte joignable depuis l’échantillon, ce qui expose tout service à l’écoute sur l’hôte.

Construire la VM d’analyse Windows

1. Installez Windows 10 ou 11 dans une nouvelle VM à partir des supports officiels de Microsoft. Donnez-lui au moins 4 cœurs de processeur, 8 Go de RAM et 80 Go de disque ; les outils lourds comme Ghidra et IDA l’apprécieront, et une petite VM est d’ailleurs un indice classique de sandbox.
2. Laissez-la en NAT pour l’instant. L’installation a besoin d’un accès internet. C’est le seul moment où la VM d’analyse a le droit d’être en ligne.
3. Désactivez les protections qui vont vous gêner. L’installeur de FLARE-VM exige que la protection en temps réel et la protection contre les falsifications de Windows Defender soient désactivées, et que Windows Update soit suspendu. Cette VM est censée être un territoire hostile ; faites-le uniquement dans la VM, jamais sur votre hôte.
4. Installez FLARE-VM en suivant les instructions de son dépôt : téléchargez le script d’installation, exécutez-le depuis une invite PowerShell élevée, et laissez-le récupérer son ensemble de paquets. Il installe des débogueurs (x64dbg), des désassembleurs (Ghidra), des outils PE (PE-bear, Detect It Easy), Sysinternals, FakeNet-NG et bien plus.
5. Durcissez l’intégration de la VM avec l’hôte. Désactivez les dossiers partagés, le presse-papiers partagé, le glisser-déposer, et retirez tout périphérique USB rattaché. Les Guest Additions ou les VMware Tools sont pratiques pour redimensionner l’écran, mais ce sont aussi des artefacts détectables ; beaucoup d’analystes les gardent installés et acceptent ce compromis.
6. Basculez la carte sur le réseau interne et définissez une IP statique (10.0.0.10/24), avec passerelle et DNS pointant tous deux vers la VM REMnux (10.0.0.1).

Construire l’auxiliaire REMnux

1. Importez l’appliance virtuelle REMnux (un fichier OVA disponible sur le site de documentation de REMnux), ou installez-la sur une VM Ubuntu avec l’installeur officiel.

2. Mettez-la à jour tant qu’elle a encore un accès NAT, puis déplacez sa carte sur le même réseau interne et donnez-lui l’adresse statique 10.0.0.1/24.

3. Configurez INetSim dans /etc/inetsim/inetsim.conf pour que ses services écoutent sur l’interface interne et que son faux DNS réponde à chaque nom avec l’adresse de REMnux elle-même :

   service_bind_address   10.0.0.1
   dns_default_ip         10.0.0.1

4. Démarrez-le avec inetsim. Pour capturer le trafic en vue d’un examen ultérieur, lancez une capture de paquets en parallèle :

   sudo tcpdump -i any -w /tmp/session.pcap

Astuce : INetSim et FakeNet-NG répondent à n’importe quelle requête : l’échantillon croit donc son C2 vivant. Il révèle ainsi davantage de comportement — la prochaine URL qu’il demande, les données qu’il tente d’envoyer —, qui devient autant d’IOC réseau.

Les snapshots : votre bouton « annuler »

Un snapshot capture le disque de la VM et, éventuellement, sa mémoire. C’est la fonction de sécurité et de productivité la plus importante du laboratoire.

• Prenez un snapshot « propre » une fois tous les outils installés, le réseau isolé et rien exécuté. Nommez-le avec une date.
• Revenez au snapshot propre avant chaque nouvel échantillon. N’analysez jamais deux échantillons dans le même état de VM ; les artefacts du premier contamineraient vos conclusions sur le second.
• Prenez des snapshots de travail en cours d’analyse — par exemple juste après que l’échantillon s’est dépaqueté — pour pouvoir revenir à ce point sans tout réexécuter.
• Reconstruisez périodiquement le snapshot propre avec les mises à jour des outils, en ne vous reconnectant au NAT qu’à partir d’un état propre, jamais après l’exécution d’un échantillon.

Manipuler les échantillons

Les échantillons circulent entre machines — depuis un ticket, un dépôt ou un collègue — et chaque transfert est une occasion d’accident.

Archives protégées par mot de passe

La convention du secteur est une archive ZIP (ou 7z) protégée par le mot de passe infected. Ce mot de passe n’est pas secret ; il sert à empêcher les passerelles de messagerie, les moteurs antivirus et votre propre bureau d’analyser, de mettre en quarantaine ou d’ouvrir accidentellement le fichier. Des dépôts comme MalwareBazaar distribuent les échantillons ainsi, et vous devriez les partager de la même manière.

# Package a sample for transfer (7-Zip, AES-256, encrypted file names)
7z a -tzip -pinfected -mem=AES256 sample.zip sample.bin

Décompressez les archives uniquement dans la VM d’analyse.

Renommer les extensions

Stockez les exécutables avec une extension neutralisée : invoice.exe devient invoice.exe_ ou invoice.bin. Windows ne le lancera alors pas sur un double-clic malencontreux. Renommez-le délibérément lorsque vous êtes prêt à l’exécuter. Identifiez les échantillons par leur empreinte plutôt que par leur nom de fichier d’origine, que les attaquants choisissent pour paraître innocent.

Neutraliser les indicateurs

Lorsque vous écrivez des indicateurs dans des rapports, des tickets ou une messagerie, neutralisez-les (defang) pour qu’aucun ne devienne un lien actif et cliquable :

La neutralisation protège vos collègues des clics accidentels et empêche les outils de messagerie de récupérer des aperçus de liens — ce qui contacterait l’infrastructure de l’attaquant depuis votre réseau d’entreprise et alerterait l’opérateur.

Si quelque chose s’échappe

Partez du principe qu’un jour une erreur se produira. Décidez de la réponse maintenant, pas sur le moment :

1. Déconnectez immédiatement la machine touchée du réseau. Pour une VM, déconnectez sa carte virtuelle ; pour un hôte, débranchez le câble ou désactivez le Wi-Fi.
2. Cessez de l’utiliser et n’essayez pas de la « nettoyer » à la main.
3. Prévenez votre équipe sécurité. S’il s’agit d’un environnement professionnel, le processus de réponse à incident existe précisément pour cela. Un signalement précoce vaut toujours mieux qu’une correction discrète.
4. Préservez les preuves — l’empreinte de l’échantillon, ce que vous avez exécuté, et quand — pour que les intervenants puissent délimiter le problème.
5. Reconstruisez à partir de supports sains. Revenir à un snapshot de VM ne suffit que si rien n’a quitté la VM.

Notes juridiques et éthiques

• Obtenez une autorisation. Analyser des malwares dans le cadre de votre travail est normal ; le faire sur le matériel ou le réseau de votre employeur sans approbation ne l’est pas. Suivez la politique de votre organisation.
• Ne redistribuez pas d’échantillons actifs en dehors de canaux de confiance, et jamais à des personnes dont vous ne pouvez pas vous porter garant.
• N’interagissez pas avec l’infrastructure de l’attaquant depuis un réseau réel — pas de « je vérifie juste si le C2 répond » depuis votre ordinateur portable. Cela peut alerter l’opérateur, enfreindre la loi ou la politique interne, et compromettre des enquêtes.
• Respectez les données. Les échantillons collectés lors d’incidents peuvent contenir des données de victimes, comme des identifiants ou des documents. Traitez-les comme confidentiels.

Lab : construire le laboratoire et prouver qu’il est isolé

Ce lab n’utilise aucun malware. Son objectif est un environnement propre et vérifié.

1. Construisez les deux VM comme décrit ci-dessus. Vérifiez qu’aucune n’a de dossiers partagés, de presse-papiers partagé ni de glisser-déposer activés, et que chacune possède exactement une carte réseau, rattachée au réseau interne.

2. Consignez l’état propre. Sur la VM Windows, ouvrez PowerShell :

   Get-NetAdapter | Format-Table Name, Status, MacAddress
   Get-NetIPConfiguration

   Vérifiez que la seule adresse IPv4 est 10.0.0.10 et que le serveur DNS est 10.0.0.1.

3. Prouvez que le vrai internet est injoignable. INetSim arrêté et FakeNet-NG non lancé :

   ping -n 2 1.1.1.1
   Test-NetConnection 1.1.1.1 -Port 443

   Les deux doivent échouer. Ensuite, ping 10.0.0.1 doit réussir (REMnux est le seul voisin). Si une adresse publique répond, arrêtez-vous et corrigez la configuration de la carte avant d’aller plus loin.

4. Prouvez que l’internet simulé fonctionne. Démarrez inetsim sur REMnux, puis, sur la VM Windows :

   Resolve-DnsName update.example.com
   Invoke-WebRequest http://update.example.com/ -UseBasicParsing

   Le nom doit se résoudre en 10.0.0.1, et la requête web doit renvoyer la fausse page par défaut d’INetSim. Consultez le journal d’INetSim sur REMnux (/var/log/inetsim/service.log) pour voir les deux requêtes enregistrées.

5. Essayez l’alternative à VM unique. Arrêtez INetSim, démarrez FakeNet-NG sur la VM Windows depuis une invite élevée, et répétez l’étape 4. Observez la console de FakeNet-NG : elle journalise la requête DNS et la requête HTTP, et répond avec ses propres fausses données.

6. Prenez le snapshot. Arrêtez FakeNet-NG, éteignez proprement les deux VM et prenez de chacune un snapshot nommé clean-2026-09-29.

Questions : Quel mode réseau avez-vous choisi, et qu’un échantillon pourrait-il atteindre si vous aviez choisi le mode privé hôte à la place ? Si un échantillon tentait de contacter une adresse IP codée en dur plutôt qu’un nom de domaine, INetSim seul l’intercepterait-il encore ? Que ferait FakeNet-NG différemment ?

À retenir

• Un laboratoire est un ensemble de contre-mesures face à des risques précis : accès à internet, mouvement latéral, intégration avec l’hôte et persistance.
• Utilisez un réseau virtuel interne, désactivez toutes les fonctions d’intégration avec l’hôte, et simulez internet avec INetSim ou FakeNet-NG.
• Revenez à un snapshot propre avant chaque échantillon ; prenez des snapshots de travail pendant l’analyse.
• Transférez les échantillons dans des archives protégées par le mot de passe infected, neutralisez les extensions, et neutralisez chaque indicateur que vous notez.
• Vérifiez l’isolement avant chaque session — et ayez un plan en cas d’évasion avant d’en avoir besoin.