Pentest Virtualisation — VMware, Hyper-V, Proxmox

Non. Nos règles d'engagement interdisent explicitement l'arrêt de VM, la modification de datastores ou toute action destructive sur la production. La simulation ransomware se limite à démontrer le chemin d'accès (preuves d'accès vCenter admin, ESXi Shell, listing des VM) sans exécuter l'étape de chiffrement. Pour les tests plus intrusifs (VM escape), nous utilisons un hyperviseur de test dédié quand c'est possible. Tout est défini dans le périmètre contractuel avant le démarrage.

Oui. Avec le changement de politique tarifaire de VMware par Broadcom, de nombreuses organisations migrent vers Proxmox VE. Le pentest est particulièrement pertinent dans ce contexte : la nouvelle plateforme introduit de nouveaux vecteurs d'attaque (API REST Proxmox, KVM/QEMU, LXC containers, Ceph storage) que vos équipes ne maîtrisent pas encore. Nous pouvons pentest les deux environnements (VMware et Proxmox) dans la même mission pour comparer la posture de sécurité.

Comptez 12 à 17 jours ouvrés pour un pentest complet incluant la simulation ransomware. Pour une infrastructure plus simple (un seul cluster, une seule plateforme), 10 à 12 jours suffisent. Le rapport est livré dans les 5 jours ouvrés suivant la fin des tests. Les findings critiques (accès vCenter admin, CVE exploitée) sont signalés immédiatement.

Oui, c'est une partie critique du pentest. Les groupes de ransomware ciblent systématiquement les backups avant de chiffrer les VM. Nous testons l'accès au repository Veeam, vérifions l'immutabilité des backups, testons la segmentation réseau entre les backups et le reste de l'infrastructure, et vérifions que les credentials Veeam ne sont pas compromis via l'AD. Si les backups sont accessibles et supprimables, le scénario ransomware est total : VM chiffrées + backups détruits = aucune récupération possible.

Non, c'est précisément l'objectif du pentest : démontrer comment un attaquant peut obtenir l'accès admin sans l'avoir au départ. En mode black-box, nous partons de zéro. En mode gray-box (recommandé), nous partons d'un compte utilisateur AD standard — exactement comme un attaquant ayant compromis un poste de travail. L'intérêt est de montrer le chemin complet : de l'utilisateur standard jusqu'au vCenter admin et ESXi root.

Un VM escape complet via une vulnérabilité dans l'hyperviseur est rare mais pas impossible — plusieurs ont été démontrés lors de Pwn2Own et par des chercheurs en sécurité. En pratique, les attaquants préfèrent le chemin le plus simple : compromettre vCenter via l'AD ou une CVE, puis accéder aux ESXi via le management plane. Le VM escape reste néanmoins un vecteur testé dans notre pentest car il évalue la robustesse de votre configuration d'isolation (virtual devices, VMware Tools, seccomp).

Oui. Si vous utilisez NSX-T (ou NSX-V), nous testons l'efficacité de vos règles de microsegmentation : est-ce qu'une VM compromise peut accéder au réseau de management, aux autres VM, aux datastores ? Nous testons les règles de firewall distribué, le gateway firewall, et les politiques de segmentation. C'est également valable pour la segmentation VLAN classique sans NSX : nous vérifions que les vSwitches sont correctement configurés et que le VLAN hopping n'est pas possible.

Au minimum une fois par an, complété par un contre-pentest à 6 mois. Tout changement majeur (upgrade vSphere, migration Proxmox, ajout de cluster, changement d'architecture réseau) devrait déclencher un pentest ciblé. Avec l'explosion des ransomwares ciblant ESXi (+370% depuis 2022), un pentest annuel est le minimum pour valider la résistance de votre infrastructure de virtualisation.