Un ransomware sur hyperviseur ne passe presque jamais par une faille exotique d’évasion de machine virtuelle : il passe par un mot de passe root réutilisé, un accès SSH laissé ouvert ou des identifiants notés dans un fichier texte. Corriger ces quelques erreurs de configuration réduit davantage le risque, pour une PME, que n’importe quel correctif isolé.
C’est la conclusion de deux enquêtes publiées en novembre par l’équipe de réponse à incident de Kaspersky (GERT), l’une sur un environnement VMware ESXi, l’autre sur un cluster Proxmox. Dans les deux cas, aucun exploit sophistiqué n’a été nécessaire : un accès administratif ordinaire a suffi pour chiffrer toute l’infrastructure virtuelle. Or c’est précisément le modèle de nombreuses PME et ETI : deux ou trois hôtes, un outil de supervision, un administrateur qui fait tout.
Pourquoi l’hyperviseur est la cible préférée du ransomware
Chiffrer un poste de travail rapporte peu. Chiffrer l’hyperviseur, c’est arrêter d’un coup le contrôleur de domaine, l’ERP, la messagerie et souvent le serveur de sauvegarde, puisque tous tournent comme machines virtuelles sur les mêmes hôtes. L’attaquant obtient l’effet maximal avec une seule commande.
Le rapport de Kaspersky insiste sur un point que les petites équipes sous-estiment : un environnement virtualisé n’est pas seulement un hyperviseur. C’est un ensemble connecté qui comprend les consoles d’administration, les outils de supervision, les comptes d’automatisation, les datastores et les sauvegardes. Il suffit à l’attaquant d’un seul chemin utilisable entre ces couches. Un hôte parfaitement à jour reste compromis si le mot de passe qui l’administre traîne ailleurs.
Cas ESXi : la supervision devenue porte d’entrée
Dans le premier incident, attribué au ransomware BlackNevas, l’entreprise supervisait ses hôtes ESXi avec PRTG Network Monitor. La plateforme de supervision détenait un identifiant capable d’administrer directement les hôtes, et le même mot de passe root était utilisé sur plusieurs nœuds.
Une fois la supervision compromise, l’attaquant s’est connecté en SSH aux hôtes qui partageaient ce mot de passe. ESXi a d’abord bloqué l’exécution du binaire malveillant grâce à l’option execInstalledOnly, qui n’autorise que les logiciels installés proprement. Mais avec les droits root, l’attaquant a simplement désactivé cette protection par une commande esxcli, lancé le chiffrement puis effacé les journaux. Même scénario, le même jour, sur un deuxième hôte doté du même mot de passe.
La leçon est directe : un outil de supervision qui stocke des identifiants d’administration devient lui-même une infrastructure privilégiée, et doit être protégé comme tel.
Cas Proxmox : des identifiants dans un bloc-notes
Le second incident concerne le groupe The Gentlemen. Après l’intrusion initiale, l’attaquant a pris le temps d’explorer le réseau. Sur le poste d’un administrateur, il a trouvé des notes en clair contenant les identifiants et les adresses d’accès à Proxmox, dont le compte root.
Avec ce compte, il a ouvert des sessions console via l’interface web sur les différents nœuds, déposé puis exécuté le ransomware dans le cluster. Résultat : l’intégralité de l’environnement virtuel chiffrée. Une seule mauvaise habitude, des mots de passe notés dans un fichier, a transformé la compromission d’un poste en arrêt complet de l’activité.
Les cinq erreurs de configuration à corriger en priorité
Les deux enquêtes font ressortir les mêmes faiblesses. Elles sont classées ici de la moins coûteuse à corriger à la plus structurante.
1. Le même mot de passe root sur tous les hôtes
La réutilisation transforme un secret volé en accès à toute la ferme. Donnez à chaque hôte un mot de passe root unique, long et stocké dans un gestionnaire de mots de passe, et réservez-le aux situations d’urgence. L’administration courante doit se faire avec des comptes nominatifs, via vCenter côté VMware ou via des utilisateurs dédiés dans Proxmox.
2. Des identifiants d’administration en clair
Fichiers texte, tableurs, notes de bureau, scripts planifiés, gestionnaires de connexions : recensez chaque endroit où figure un identifiant d’hyperviseur, de stockage ou de sauvegarde. Rapatriez-les dans un coffre-fort de mots de passe protégé par MFA et changez-les immédiatement si un poste d’administration est suspecté d’être compromis.
3. Une supervision avec des droits d’administrateur
La supervision doit lire des métriques, pas administrer. Créez un compte dédié par plateforme, limité aux seules lectures dont les sondes ont besoin, et n’utilisez jamais le compte root pour l’interrogation périodique. Côté Proxmox, un rôle en lecture seule (PVEAuditor) suffit en général à la supervision.
4. SSH et interfaces d’administration joignables depuis le réseau des serveurs
Dans le cas ESXi, l’accès SSH direct a permis de contourner tous les contrôles centraux. Broadcom recommande d’administrer vSphere via vCenter, de laisser SSH et l’ESXi Shell arrêtés en temps normal et d’activer le mode Lockdown lorsque c’est possible. Placez les interfaces d’administration (ESXi, vCenter, Proxmox) sur un réseau d’administration séparé, accessible uniquement depuis quelques postes identifiés.
5. Des protections que root peut désactiver en silence
L’option execInstalledOnly a bien bloqué la première tentative, mais l’attaquant l’a désactivée avec le même compte que celui de l’administration quotidienne. Broadcom documente un mode d’application qui combine cette option avec le Secure Boot UEFI et la protection de configuration par TPM. Activez ces mécanismes, testez-les, et surtout surveillez leur modification : une protection qui peut être coupée sans alerte n’offre qu’une résistance limitée.
Surveiller la couche virtualisation comme un actif critique
Les deux attaques ont laissé des traces exploitables avant le chiffrement : connexion root en SSH, activation du service SSH, désactivation d’execInstalledOnly, ouvertures de sessions console répétées sur plusieurs nœuds en quelques minutes. Kaspersky recommande de traiter chaque changement de configuration de sécurité comme un événement de sécurité.
Concrètement, envoyez les journaux de vos hôtes ESXi, de vCenter et de Proxmox vers un outil centralisé, et définissez quelques alertes simples : connexion root directe, démarrage du service SSH, modification d’un paramètre de sécurité avancé, connexion à l’interface d’administration depuis une adresse inhabituelle. Ces signaux sont rares en fonctionnement normal : leur apparition mérite une vérification immédiate, de jour comme de nuit.
Enfin, sortez la sauvegarde du périmètre de l’hyperviseur. Si le serveur de sauvegarde est une machine virtuelle sur les mêmes hôtes, administrée avec les mêmes identifiants, il sera chiffré en même temps que le reste. Une copie hors ligne ou immuable, sur un support dont les identifiants sont distincts, reste la dernière ligne de défense.
Ces signaux faibles sur la couche virtualisation se détectent et se contiennent avec une surveillance continue, y compris la nuit et le week-end : découvrez notre SOC managé 24/7 pour PME et ETI.
Pour aller plus loin sur la réduction des droits, lisez notre article sur les comptes administrateurs en PME, et notre analyse d’une faille vCenter exploitée.
Ce qu’il faut retenir
- Le ransomware sur hyperviseur exploite surtout des erreurs de configuration, pas des failles d’évasion.
- Un mot de passe root unique par hôte et stocké dans un coffre-fort coupe la propagation.
- La supervision doit avoir des droits de lecture, jamais d’administration.
- SSH arrêté par défaut et interfaces d’administration isolées ferment le chemin le plus utilisé.
- Toute modification d’un paramètre de sécurité de l’hyperviseur doit déclencher une alerte.
Sources
- Kaspersky GERT (Securelist) : Virtualization security, attack layers and misconfiguration impact
- Broadcom : Lockdown Mode et administration via vCenter
- Broadcom : application d’execInstalledOnly avec Secure Boot et TPM
- NIST SP 800-125 : Guide to Security for Full Virtualization Technologies
- Proxmox VE : gestion des utilisateurs et des rôles