Les ransomwares visant directement les hyperviseurs ne sont plus un scénario théorique. Depuis 2023, plusieurs campagnes ont ciblé des hôtes ESXi en exploitant des interfaces de management accessibles depuis Internet, des vulnérabilités non corrigées, des identifiants administrateur compromis ou des services distants laissés actifs. L’objectif est simple : chiffrer ou détruire les fichiers de machines virtuelles sur les datastores, neutraliser les sauvegardes accessibles et exercer une pression maximale sur l’organisation.

Le durcissement d’un hôte ESXi ne se limite donc pas à appliquer les correctifs VMware. Il repose sur une réduction stricte de la surface d’attaque, une séparation réelle des plans réseau, une chaîne de démarrage vérifiable, une supervision exploitable et une procédure de réponse adaptée aux contraintes de la virtualisation.

Comprendre le chemin d’attaque contre ESXi

Dans les incidents observés, l’attaquant ne “casse” pas nécessairement l’hyperviseur au sens technique. Il obtient d’abord un accès au plan de management, puis utilise les fonctions légitimes de l’administration ESXi : connexion SSH, ESXi Shell, API, services de fichiers, commandes esxcli, arrêt des machines virtuelles et accès aux datastores VMFS ou vSAN.

Les vecteurs les plus fréquents sont les suivants :

Le ransomware peut ensuite arrêter les VM pour libérer les verrous de fichiers, supprimer les snapshots, désactiver certains mécanismes de récupération, puis chiffrer les fichiers .vmdk, .vmx, .vmsd ou les objets associés. Un attaquant mieux équipé cherchera également à compromettre vCenter, les serveurs de sauvegarde, les dépôts immuables mal isolés et Active Directory.

La priorité est donc de rendre l’accès au plan de management difficile, observable et limité dans le temps.

Isoler strictement le plan de management

Un hôte ESXi ne doit pas être administrable depuis un réseau utilisateur, un VLAN bureautique, une zone Wi-Fi, un réseau de serveurs applicatifs ou, a fortiori, Internet. Cette règle doit être considérée comme un prérequis architectural, pas comme une recommandation de configuration.

Le réseau de management ESXi doit être placé dans un segment dédié. Selon l’architecture, il peut être séparé des réseaux vMotion, vSAN, FT, IPMI/iDRAC/iLO, sauvegarde et réplication. L’objectif est d’éviter qu’une compromission d’une VM ou d’un poste utilisateur fournisse un chemin direct vers les interfaces de contrôle de l’hyperviseur. Pour aller plus loin, consultez notre guide complet sur la sécurisation d’un cluster.

Les principes à appliquer sont :

Sur chaque hôte, configurez le firewall ESXi avec une logique de liste blanche. Le service SSH ne doit pas accepter des connexions depuis n’importe quelle source. Si SSH est utilisé ponctuellement, limitez les adresses IP autorisées aux bastions ou stations d’administration.

Exemple de vérification de la configuration SSH et du firewall :

esxcli system ssh server config list
esxcli network firewall ruleset list | grep -i ssh
esxcli network firewall ruleset allowedip list -r sshServer

Exemple d’ajout d’une source autorisée, à adapter à votre politique réseau :

esxcli network firewall ruleset set -r sshServer -e true
esxcli network firewall ruleset allowedip add -r sshServer -i 10.50.10.25

Cette restriction ne remplace pas l’isolation réseau. Elle apporte une couche complémentaire : si le cloisonnement est mal configuré ou si une route inattendue apparaît, le service continue de refuser la majorité des origines.

Pour vCenter Server, évitez de le publier par translation d’adresse, proxy inverse ou règle firewall permissive. Un accès distant doit passer par un VPN avec MFA ou, mieux, par une solution d’accès à privilèges contrôlée avec poste rebondi. Le VPN ne doit pas donner un accès réseau total : il doit déposer l’administrateur dans une zone dédiée où seuls les flux nécessaires sont permis.

Désactiver SSH et ESXi Shell par défaut

SSH et ESXi Shell sont utiles lors d’un dépannage, mais ils constituent également des voies d’exécution particulièrement attractives pour un attaquant. Dans une exploitation standard, ces services doivent être arrêtés et configurés pour ne pas démarrer automatiquement.

Vérifiez leur état :

vim-cmd hostsvc/enable_ssh
vim-cmd hostsvc/enable_esx_shell

Les commandes ci-dessus ne sont pas des commandes d’état : elles activent les services. Pour contrôler et gérer les services, utilisez plutôt :

esxcli system services list

Cherchez notamment TSM-SSH et TSM. Pour arrêter les services et désactiver leur démarrage automatique :

esxcli system services stop --service TSM-SSH
esxcli system services stop --service TSM
esxcli system services set --service TSM-SSH --policy off
esxcli system services set --service TSM --policy off

Le bon fonctionnement opérationnel consiste à activer SSH temporairement, pour un besoin documenté, depuis vCenter ou via une procédure d’administration approuvée. Définissez un délai d’expiration des services dans les paramètres avancés de l’hôte afin que l’activation ne devienne pas permanente par oubli.

Une politique efficace comprend :

Désactivez également les services non nécessaires à votre environnement. Chaque ruleset actif dans le firewall ESXi doit avoir une justification : accès matériel, supervision, sauvegarde, réplication, stockage ou usage opérationnel identifié.

Renforcer l’identité, les privilèges et les certificats

La compromission d’un compte ayant le rôle administrateur sur vCenter reste l’un des scénarios les plus dangereux. Ce compte permet souvent de déployer une appliance malveillante, modifier les permissions, accéder aux consoles, arrêter des VM ou changer des paramètres de sécurité.

Le durcissement du plan de management reste la priorité numéro un.
Le durcissement du plan de management reste la priorité numéro un.

L’administration doit suivre le principe du moindre privilège :

L’usage de l’intégration avec un annuaire doit être traité avec prudence. Si Active Directory est compromis, il ne faut pas qu’un groupe largement administré fournisse automatiquement un contrôle total de l’infrastructure. Séparez les groupes d’administration de virtualisation des groupes d’administration généralistes et protégez les identités privilégiées avec des postes d’administration dédiés.

La gestion des certificats est également une mesure de sécurité opérationnelle. Des certificats expirés, autosignés non maîtrisés ou remplacés dans l’urgence incitent les équipes à ignorer les alertes navigateur et les erreurs de confiance. Cela facilite les redirections frauduleuses et les attaques d’interception sur les réseaux internes.

Utilisez une autorité de certification d’entreprise ou une PKI adaptée pour les certificats de vCenter et, selon votre modèle d’exploitation, pour les hôtes ESXi. Documentez :

Ne contournez pas les erreurs de certificat en ajoutant des exceptions permanentes dans les navigateurs ou les outils d’administration. Toute alerte inattendue doit être considérée comme un signal à investiguer. Pour aller plus loin, consultez le regard d’un RSSI sur ces enjeux.

Assurer l’intégrité : Secure Boot, TPM et images contrôlées

La protection contre le ransomware ne concerne pas uniquement l’accès distant. Un attaquant ayant obtenu un accès administrateur peut chercher à altérer l’hyperviseur, installer un composant persistant ou modifier la configuration de démarrage. La chaîne de confiance matérielle et logicielle doit donc être activée et surveillée.

Sur les serveurs compatibles, activez dans le firmware :

Dans ESXi, vérifiez l’état de Secure Boot :

esxcli system settings encryption get
esxcli hardware trustedboot get

Les commandes disponibles et leur sortie peuvent varier selon la version d’ESXi, le matériel et la présence d’un TPM. L’important est de valider simultanément le mode de démarrage, la détection TPM, l’attestation et l’absence d’alerte d’intégrité dans vCenter.

Les journaux d'audit permettent de détecter les accès suspects.
Les journaux d'audit permettent de détecter les accès suspects.

Les versions récentes d’ESXi proposent une approche renforcée de l’intégrité de l’image, notamment via l’Execution Installation Image et les mécanismes de vérification de l’image installée. L’objectif est de s’assurer que l’hôte exécute une image cohérente, signée et conforme au profil attendu, plutôt qu’un ensemble de composants modifiés localement.

Dans une exploitation gérée par vCenter, utilisez les images souhaitées pour clusters lorsque votre version et votre matériel le permettent. Définissez une image de référence incluant la version ESXi, les pilotes et compléments matériels approuvés. Évitez les installations manuelles non documentées de VIB ou de pilotes récupérés hors de la chaîne de support.

Quelques règles concrètes :

Le contrôle d’intégrité ne remplace pas la segmentation ni les correctifs, mais il limite la capacité d’un attaquant à rester discret après une compromission.

Mettre en place une supervision orientée détection

Les journaux ESXi et vCenter doivent être centralisés vers une plateforme de collecte sécurisée, idéalement hors du périmètre administré par les mêmes comptes que la virtualisation. Un ransomware qui compromet vCenter ne doit pas pouvoir effacer facilement les traces de son activité.

Configurez l’envoi des logs ESXi vers un ou plusieurs serveurs syslog distants :

esxcli system syslog config set --loghost='tcp://10.60.20.15:514'
esxcli system syslog reload
esxcli system syslog config get

En production, préférez un transport chiffré lorsque votre collecteur et votre version le permettent, et assurez-vous que les certificats associés sont gérés correctement.

Les alertes utiles ne doivent pas se limiter aux échecs de connexion. Surveillez notamment :

Les alertes doivent être corrélées avec les journaux du bastion, du VPN, de l’annuaire, de la solution EDR sur les postes d’administration et de la sauvegarde. Un échec de connexion vCenter isolé est peu significatif. Le même événement suivi d’une connexion VPN inhabituelle, d’une activation SSH et d’un arrêt de VM est une séquence à très forte priorité.

Testez régulièrement la capacité de l’équipe à retrouver les éléments suivants : qui s’est connecté, depuis quelle source, avec quel compte, quelles permissions ont changé, quels hôtes ont été affectés et quelles VM ont été arrêtées.

Préparer un plan de réponse à incident spécifique VMware

Un plan générique de réponse ransomware est insuffisant si les équipes ne savent pas comment traiter un cluster ESXi sous pression. Il faut anticiper les choix difficiles : isoler un hôte sans couper toutes les VM, préserver les preuves, empêcher la propagation vers les sauvegardes et restaurer dans le bon ordre.

La première règle est de ne pas redémarrer ou éteindre aveuglément les hôtes. Une action précipitée peut détruire des preuves, interrompre des applications critiques ou compliquer la récupération de VM encore intactes.

Une procédure adaptée peut suivre les phases suivantes.

1. Qualification et confinement. Identifiez les hôtes, vCenter, comptes et datastores concernés. Coupez les accès suspects au niveau du firewall, du VPN et du bastion. Si un hôte est activement utilisé par l’attaquant, isolez son réseau de management tout en évaluant les conséquences pour les VM en cours d’exécution. Désactivez ou réinitialisez les identités compromises depuis un environnement de confiance.

2. Préservation des preuves. Exportez les journaux vCenter, ESXi, VPN, bastion, annuaire et stockage. Capturez les informations de configuration, la liste des processus, les tâches récentes, les événements de sécurité et l’état des services. Travaillez avec un horodatage cohérent : NTP doit être vérifié avant toute analyse détaillée. Pour aller plus loin, consultez l’administration quotidienne d’ESXi.

3. Protection de la restauration. Isolez les infrastructures de sauvegarde accessibles depuis le périmètre compromis. Vérifiez les copies hors ligne, immuables ou placées dans une zone d’administration distincte. Ne reconnectez pas immédiatement un dépôt de sauvegarde au réseau compromis.

4. Éradication. Réinstallez les hôtes compromis à partir d’images validées plutôt que de tenter une confiance progressive dans un système potentiellement altéré. Appliquez les correctifs nécessaires, rétablissez Secure Boot et l’attestation, puis restaurez une configuration hôte revue. Changez les mots de passe, secrets, certificats et jetons susceptibles d’avoir été exposés.

5. Restauration. Restaurez d’abord les services d’identité, DNS, NTP, PKI, sauvegarde et outils de management nécessaires, dans un réseau contrôlé. Réintroduisez ensuite les applications par vagues, avec validation de l’intégrité et surveillance renforcée. Ne restaurez pas mécaniquement toutes les VM : certaines peuvent contenir le point d’entrée initial ou des mécanismes de persistance.

6. Retour d’expérience. Documentez le vecteur initial, les délais de détection, les permissions utilisées, les lacunes de segmentation et les échecs de sauvegarde. Transformez chaque constat en action mesurable : fermeture de flux, réduction de rôle, ajout d’alerte, correction de procédure ou exercice de crise.

Un exercice de restauration trimestriel est plus utile qu’une politique de sauvegarde théorique. Il doit inclure au moins une VM critique, une restauration dans un réseau isolé, la validation applicative et la mesure du temps réel de reprise.

Le durcissement ESXi efficace repose finalement sur une idée simple : l’hyperviseur ne doit jamais être une cible facilement joignable, administrable avec un identifiant volé et insuffisamment surveillée. L’isolement du management, la désactivation des services distants par défaut, l’intégrité vérifiable de l’image, la discipline des identités et une réponse à incident testée constituent les contrôles les plus déterminants.