Monter un lab CTF sur Hyper-V : le guide complet

Monter un lab CTF sur Hyper-V, c'est la façon la moins chère que je connaisse de pratiquer la sécurité offensive en toute légalité, sur du matériel que tu as déjà payé. Rien à louer. Pas besoin de demander la permission au cloud de qui que ce soit. On va monter un vrai champ de tir CTF sur Hyper-V, l'hyperviseur Type-1 gratuit qui dort sur ta machine Windows 10 ou 11 Pro depuis tout ce temps. À la fin, tu te retrouves avec un petit réseau de VM isolées : un attaquant Kali Linux, un routeur pfSense, puis Metasploitable3 et un Windows 10 volontairement cassé sur lesquels tirer, avec une appli web DVWA garée sur un switch qui ne peut atteindre absolument rien. Dans les 80 Go de disque. Une soirée, en supposant que les téléchargements se tiennent bien.

Trois ordinateurs portables. C'est le nombre de fois où j'ai monté exactement ce lab, et ça reste la façon la moins chère que je connaisse de pratiquer la sécurité offensive en toute légalité, sur du matériel que tu as déjà payé. Rien à louer. Pas besoin de demander la permission au cloud de qui que ce soit. On va monter un vrai champ de tir CTF sur Hyper-V, l'hyperviseur Type-1 gratuit qui dort sur ta machine Windows 10 ou 11 Pro / Education / Enterprise depuis tout ce temps, que tu l'aies remarqué ou non. À la fin, tu te retrouves avec un petit réseau de VM isolées : un attaquant Kali Linux, un routeur pfSense, puis Metasploitable3 et un Windows 10 volontairement cassé sur lesquels tirer, avec une appli web DVWA garée sur un switch qui ne peut atteindre absolument rien. Dans les 80 Go de disque. Une soirée, en supposant que les téléchargements se tiennent bien, ce qui honnêtement n'est pas toujours le cas.

Trois switches, trois zones de confiance. C'est en gros toute l'astuce. External, c'est ta ligne bridgée vers l'extérieur pour les mises à jour. Internal, c'est le terrain de jeu routé où Kali peut effectivement rencontrer les cibles. Et Private, c'est la pièce verrouillée : pas d'hôte, pas d'Internet, l'endroit où je gare tout ce que je ne voudrais pas voir appeler la maison, comme une machine retraitée de Hack The Box.

Pourquoi un lab CTF sur Hyper-V (et pas VirtualBox)

VirtualBox est plus sympa le premier jour. Hyper-V est plus sympa au trentième. Et tu vas vivre dans ce lab pendant des mois, pas des jours, donc c'est l'arbitrage que je refais à chaque fois. Mon vrai raisonnement, pour ce que ça vaut. Il tourne en hyperviseur Type-1 juste au-dessus de la couche hyperviseur de Windows, donc les VM sortent de l'hibernation en bien meilleur état et le passthrough CPU marche tout seul sans que tu aies à te battre avec. Le Virtual Switch Manager te donne de vrais types réseau External / Internal / Private d'entrée de jeu, ce qui est exactement la séparation dont tu as besoin pour empêcher une cible compromise de balancer un beacon vers l'Internet ouvert. Et puis, soyons clairs, tu le possèdes déjà. Deux cases à cocher sur n'importe quelle édition Pro / Education / Enterprise et c'est plié. Pas de licence à dénicher. Pas de compte à rebours d'essai qui joue contre toi.

Deux choses m'ont mordu ici, alors laisse-moi t'épargner le même après-midi. Si tu fais aussi tourner VMware Workstation 16 ou plus ancien, tu ne peux pas garder les deux en vie en même temps. Hyper-V s'empare du matériel et la négociation s'arrête là. L'autre : la nested virtualisation, dont tu auras besoin pour quelques box HTB, exige un CPU Intel VT-x ou AMD-V avec support VBS. Vérifie ça d'abord. Monter la moitié d'un lab pour découvrir ensuite que ton CPU n'en est pas capable, c'est un genre d'agacement bien particulier.

Prérequis et dimensionnement matériel

La petite liste que je passe en revue avant de commencer à cliquer :

• Windows 10 / 11 Pro, Education ou Enterprise. Home n'embarque pas le rôle Hyper-V. Point final, aucun contournement qui vaille ton temps. Faire passer Home à Pro coûte environ 99 EUR si tu es coincé dessus.
• 16 Go de RAM minimum, 32 Go si tu peux te le permettre. Avec Kali, pfSense, Metasploitable3, plus la cible Windows 10 et DVWA tous réveillés en même temps, j'ai vu la mémoire validée culminer autour de 11 Go. 16 suffit. 32, ça veut dire que tu arrêtes de jouer la nounou.
• Un SSD avec au moins 120 Go de libre. Les differencing disks ont l'air malins jusqu'au moment où tes snapshots se transforment en plat de spaghettis. Donne à chaque VM son propre VHDX dynamique et tu dormiras mieux.
• Un CPU avec la virtualisation matérielle activée dans le BIOS (Intel VT-x + EPT, ou AMD-V + RVI). Une vérif rapide te dit où tu en es : systeminfo | findstr /i "hyper".

Étape 1 : activer Hyper-V proprement

Ouvre PowerShell en administrateur et lance la ligne ci-dessous. Je zappe la boîte de dialogue Fonctionnalités optionnelles à chaque fois. C'est plus rapide, et ça te rapporte vraiment ce qui a changé au lieu de te laisser deviner.

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -All

Redémarre quand il le demande. Une fois revenu, confirme que le rôle est bien monté et que la console de gestion voit l'hôte. Deux vérifs rapides tranchent la question :

PS> Get-WindowsFeature -Name Hyper-V
Display Name   Name      Install State
[X] Hyper-V    Hyper-V   Installed

PS> Get-VMHost | Select VirtualHardDiskPath, VirtualMachinePath
VirtualHardDiskPath              VirtualMachinePath
-----------------------          -----------------------
C:\Hyper-V\Virtual Hard Disks    C:\Hyper-V

Tu as un second disque ? Déplace ces deux chemins hors de C: tout de suite, avant qu'il y ait quoi que ce soit à perdre. Le jour où tu rases et réinstalles Windows, tout ton lab reste bien en place, et le toi du passé a l'air d'un génie. Set-VMHost -VirtualHardDiskPath 'D:\HyperV\VHDs' -VirtualMachinePath 'D:\HyperV\VMs'.

Étape 2 : créer les trois virtual switches

Si tu ne lis qu'une section en diagonale, fais en sorte que ce ne soit pas celle-ci. Chaque frontière de confiance qui compte vraiment pour toi vit ou meurt ici même, dans la config des switches : l'attaquant qui atteint la cible, le lab qui atteint ton réseau domestique, n'importe quoi qui atteint l'Internet ouvert. Rate ça et tu n'as pas monté un lab. Tu as monté une box vulnérable avec un chemin tout tracé vers le monde, soit l'exact opposé du but. Ouvre le Hyper-V Manager, puis le Virtual Switch Manager, et construis trois switches conformes à la topologie ci-dessus.

# Pure PowerShell equivalent (preferred for reproducibility)
New-VMSwitch -Name 'External-vSwitch' -NetAdapterName 'Ethernet' -AllowManagementOS $true
New-VMSwitch -Name 'Internal-vSwitch' -SwitchType Internal
New-VMSwitch -Name 'Private-vSwitch' -SwitchType Private

# Pin a host-side IP on the internal switch so the host can reach pfSense's web UI
New-NetIPAddress -InterfaceAlias 'vEthernet (Internal-vSwitch)' -IPAddress 10.10.10.5 -PrefixLength 24

Alors, à quoi sert chacun, concrètement ? External bridge ta carte réseau physique, et c'est comme ça que Kali récupère ses mises à jour et les bases de données Metasploit. Internal relie l'hôte aux VM mais ne touche jamais une seule fois ton réseau domestique. pfSense fera le NAT de ce sous-réseau vers l'extérieur via External un peu plus tard. Private, c'est le sas. Rien à l'intérieur n'atteint jamais l'hôte ni l'Internet, point barre. Tout ce en quoi tu n'as pas pleinement confiance va là-dedans et y reste.

Étape 3 : monter la VM attaquante Kali

Récupère le VHDX Kali officiel pour Hyper-V depuis kali.org/get-kali/#kali-virtual-machines. L'image préfabriquée te donne une box fonctionnelle et t'épargne une bonne heure à cliquer dans un installeur sans aucune raison. Fais la VM en Generation 2 (UEFI, et l'interrupteur secure boot est juste là quand tu en as besoin), 4 Go de RAM, deux vCPU. Pour l'instant, accroche-la à Internal-vSwitch et à rien d'autre.

New-VM -Name 'kali-ctf' -MemoryStartupBytes 4GB -Generation 2 `
       -VHDPath 'D:\HyperV\VHDs\kali-linux-2026.2-hyperv-amd64.vhdx' `
       -SwitchName 'Internal-vSwitch'
Set-VM    -Name 'kali-ctf' -ProcessorCount 2 -DynamicMemory `
          -MemoryMinimumBytes 2GB -MemoryMaximumBytes 6GB
Set-VMFirmware -VMName 'kali-ctf' -EnableSecureBoot Off
Start-VM  -Name 'kali-ctf'

Saute une fois dans la console Hyper-V pour régler la disposition du clavier et fixer une IP statique de 10.10.10.10/24 avec la passerelle 10.10.10.1. Cette passerelle, c'est pfSense, qui ne tourne pas encore. Pas de panique, c'est attendu pour le moment. Ensuite, avant même de faire un apt install de quoi que ce soit, prends un checkpoint. Ce snapshot intact, c'est ta baseline propre, et tu vas y revenir bien plus souvent que tu ne l'imagines au départ.

Étape 4 : ajouter les cibles vulnérables

Voici le pack de départ sur lequel je reviens sans cesse, build après build :

• Metasploitable3 (Ubuntu 14.04 plus Windows Server 2008, cassé exprès d'une bonne douzaine de façons). Construis la box Vagrant une fois sur l'hôte, exporte le VHDX Hyper-V, puis attache-le à une VM Generation 1 sur Internal-vSwitch en 10.10.10.20.
• Un build Windows 10 vulnérable. Installe-le une fois, tue Defender, laisse SMBv1 activé, et donne à l'Administrateur local un mot de passe qu'un gamin de cinq ans craquerait. Generation 2, 3 Go de RAM, Internal-vSwitch en 10.10.10.21. Snapshot-le à la seconde où il est propre, puis encore après chaque changement d'outillage, parce que tu vas le restaurer en permanence. Crois-moi là-dessus.
• DVWA et bWAPP pour le côté web. La voie fainéante-mais-correcte, c'est le VHD OWASP Broken Web Apps, accroché à Private-vSwitch en 192.168.99.30. Ceux-là ne touchent jamais l'hôte, ce qui est exactement comme je les veux.
• Une box retraitée de Hack The Box. Importe l'OVA avec Convert-VHD et pose-la sur Private-vSwitch en 192.168.99.31.

Ne branche jamais une VM vulnérable sur le switch External. Une box Metasploitable3 avec une route vers l'Internet ouvert cesse d'être un lab. C'est désormais une machine cassée volontairement posée sur ton WAN, et c'est la première chose que n'importe quel attaquant qui s'ennuie sur le Wi-Fi de l'hôtel trouvera la prochaine fois que tu voyages. J'en ai vu une se faire compromettre en moins de dix minutes. Garde-les en cage.

Étape 5 : brancher pfSense pour le routage et le contrôle de sortie

Bien sûr, tu peux zapper pfSense. Mais alors tu as jeté la pièce la plus réaliste de tout l'ensemble : un vrai firewall assis entre toi et les cibles, faisant exactement ce que les firewalls font dans le monde réel. Récupère l'ISO de pfSense Community Edition, monte une VM Generation 1 avec deux adaptateurs (un sur External, un sur Internal), boote l'ISO, installe. Quand l'assistant console de premier démarrage apparaît :

1. Pointe WAN sur l'adaptateur External et LAN sur l'Internal. Inverse ça et plus rien ne route du tout, donc revérifie les MAC si tu as le moindre doute.
2. Donne au LAN l'IP 10.10.10.1/24 et active le serveur DHCP dans la même foulée (plage 10.10.10.50-10.10.10.99).
3. Redémarre, puis attaque la web UI depuis Kali en https://10.10.10.1 avec les identifiants par défaut admin / pfsense. Change ce mot de passe en premier, avant de toucher à quoi que ce soit d'autre.

Deux règles gagnent leur place dès le premier jour. D'abord, bloque tout ce qui part de 10.10.10.0/24 en direction des plages RFC1918 192.168.0.0/16 et 172.16.0.0/12. C'est le mur entre ton lab et ton LAN domestique, et il n'est pas optionnel. Ensuite, autorise le TCP sortant 80 / 443, mais seulement depuis 10.10.10.10, ta box Kali. Avec ces deux-là en place, Metasploitable3 ne peut pas appeler la maison, peu importe à quel point tu la compromets en profondeur. Kali, de son côté, peut toujours sortir pour récupérer un payload Empire au moment précis où tu en as besoin.

Étape 6 : première session d'exploit

Depuis Kali, balance nmap sur la cible Linux. Si tu as câblé les switches correctement, SSH, HTTP et SMB s'allument tout de suite. Et voir ce premier mur de ports ouverts ? Honnêtement, c'est le moment où le lab cesse d'être un tutoriel et commence à se sentir réel.

┌──(kali㉿kali)-[~]
└─$ nmap -sS -T4 -p- 10.10.10.20
PORT     STATE SERVICE       VERSION
22/tcp   open  ssh           OpenSSH 6.6.1p1
80/tcp   open  http          Apache 2.4.7
445/tcp  open  microsoft-ds  Samba 4.3.11
3306/tcp open  mysql         MySQL 5.5.46
8080/tcp open  http-proxy    Jetty 9.4.x

Maintenant, pointe Metasploit sur le partage SMB. Metasploitable3 est livré avec un compte vagrant / vagrant à peu près aussi devinable qu'un mot de passe peut l'être, donc celui-ci tombe vite :

msf6 > use auxiliary/scanner/smb/smb_login
msf6 > set RHOSTS 10.10.10.20
msf6 > set SMBUser vagrant
msf6 > set SMBPass vagrant
msf6 > run

Les identifiants passent ? Bien. Maintenant, fais un checkpoint de chaque cible que tu viens de toucher. C'est peut-être l'habitude la plus ignorée de toute la pratique CTF, ou au moins celle qui m'a le plus brûlé, et je l'oublie encore une fois sur deux. Tu poses un exploit, tu snapshot. Comme ça, la session suivante repart de la baseline exacte au lieu d'un état à moitié cassé que tu ne pourras pas reproduire plus tard quand tu essaieras de comprendre ce qui a vraiment marché.

Pièges courants

• VBS / Memory Integrity bloque Hyper-V sur Windows 11. Si une VM refuse catégoriquement de démarrer et balance « operating system cannot find a hardware resource », c'est presque toujours le coupable. Désactive Memory Integrity sous Core Isolation et elle bootera.
• Le switch External a bouffé mon Wi-Fi. Bridge un vSwitch External sur un adaptateur Wi-Fi et Hyper-V réquisitionne plus ou moins la carte réseau. J'ai perdu un après-midi entier là-dessus avant que la lumière se fasse enfin. Si tu vis en Wi-Fi, lie External à l'Ethernet uniquement et passe par un partage de connexion USB quand tu as besoin de mettre le lab en ligne.
• Les snapshots ne sont pas des sauvegardes. Les checkpoints s'empilent par-dessus le VHDX d'origine, et ils grossissent. Laisse-en s'accumuler une vingtaine et un matin tu découvriras un monstre de 200 Go en train de dévorer ton SSD en silence. Fusionne ou élague l'arbre toutes les deux semaines. Ne le laisse pas t'échapper.
• Confusions Generation 1 vs Generation 2. La Gen 2 veut une image bootable en UEFI, sans exception, sans débat. Si une cible reste à l'écran noir indéfiniment au boot, arrête de te battre et reconstruis-la en Generation 1.
• Les horloges dérivent après une mise en veille de l'hôte. L'hôte lui-même se suspend et se réveille très bien, mais pfSense et Metasploit vont discrètement s'éloigner de l'heure correcte. Pose chrony sur les cibles Linux et colle w32tm /resync dans un script de démarrage sur les box Windows. Fais ça et tu arrêteras de courir après d'étranges erreurs de certificat et d'authentification qui n'ont rien à voir avec ton exploit.

Sources et pour aller plus loin

• MITRE ATT&CK
• Microsoft Learn, Hyper-V

Questions fréquentes