Les auteurs de menaces chinois sont soupçonnés d'exploiter un périphérique VPN SonicWall compromis comme vecteur d'accès initial pour déployer un exploit VMware ESXi qui aurait pu être développé dès février 2024.
La société de cybersécurité Huntress, qui a observé l’activité en décembre 2025 et l’a arrêtée avant qu’elle puisse passer à l’étape finale, a déclaré qu’elle pourrait avoir abouti à une attaque de ransomware.
En particulier, l’attaque aurait exploité trois vulnérabilités VMware que Broadcom a divulguées comme étant de type « jour zéro » en mars 2025 : CVE-2025-22224 (score CVSS : 9,3), CVE-2025-22225 (score CVSS : 8,2) et CVE-2025-22226 (score CVSS : 7,1). Une exploitation réussie de ce problème pourrait permettre à un acteur malveillant disposant de privilèges d'administrateur de fuir la mémoire du processus exécutable de la machine virtuelle (VMX) ou d'exécuter du code en tant que processus VMX.
Le même mois, l'Agence américaine de cybersécurité et de sécurité des infrastructures (CISA) a ajouté la faille au catalogue des vulnérabilités exploitées connues (KEV), citant des preuves d'exploitation active.
“L'ensemble d'outils analysé […] “Il inclut également des chaînes en chinois simplifié dans ses chemins de développement, y compris un dossier appelé '全版本逃逸–交付' (traduit : 'Toutes les versions s'échappent – livrent'), et des preuves suggérant qu'il a été potentiellement construit comme un exploit zero-day plus d'un an avant la divulgation publique de VMware, pointant vers un développeur disposant de ressources suffisantes opérant probablement dans une région de langue chinoise”, ont déclaré les chercheurs Anna Pham et Matt Anderson.
L'évaluation de la boîte à outils selon laquelle elle exploite les trois lacunes de VMware est basée sur le comportement de l'exploit, son utilisation du système de fichiers hôte-invité (HGFS) pour la fuite d'informations, de l'interface de communication de la machine virtuelle (VMCI) pour la corruption de la mémoire et du shellcode s'échappant dans le noyau, a ajouté la société.
L'ensemble d'outils comprend plusieurs composants, le principal étant « exploit.exe » (alias MASTER), qui fait office d'orchestrateur pour l'intégralité de l'échappement de la machine virtuelle (VM) en utilisant les binaires intégrés suivants :
- devcon.exe, pour désactiver les pilotes VMware côté invité VMCI
- MyDriver.sys, un pilote de noyau non signé contenant l'exploit qui est chargé dans la mémoire du noyau à l'aide d'un outil open source appelé Kernel Driver Utility (KDU), après quoi l'état de l'exploit est surveillé et les pilotes VMCI sont réactivés.
 |
| Flux d'exploitation d'évasion de VM |
La principale responsabilité du pilote est d'identifier la version exacte d'ESXi exécutée sur l'hôte et de déclencher un exploit pour CVE-2025-22226 et CVE-2025-22224, permettant finalement à l'attaquant d'écrire trois charges utiles directement dans la mémoire VMX.
- Shellcode de l'étape 1, pour préparer l'environnement à l'échappement du bac à sable VMX
- Shellcode étape 2, pour prendre pied sur l'hôte ESXi
- VSOCKpuppet, une porte dérobée ELF 64 bits qui fournit un accès à distance persistant à l'hôte ESXi et communique via le port VSOCK (Virtual Sockets) 10000.
“Après avoir écrit les charges utiles, l'exploit écrase un pointeur de fonction dans VMX”, a expliqué Huntress. “Il enregistre d'abord la valeur du pointeur d'origine, puis l'écrase avec l'adresse du shellcode. L'exploit envoie ensuite un message VMCI à l'hôte pour activer VMX.”
 |
| Protocole de communication VSOCK entre client.exe et VSOCKpuppet |
« Lorsque VMX traite le message, il suit le pointeur corrompu et passe au shellcode de l'attaquant au lieu du code légitime. Cette dernière étape correspond à CVE-2025-22225, que VMware décrit comme une « vulnérabilité d'écriture arbitraire » qui permet une « évasion du bac à sable ».
Étant donné que VSOCK fournit un chemin de communication direct entre les machines virtuelles invitées et l'hyperviseur, il a été constaté que les acteurs malveillants utilisent un « client.exe » (également connu sous le nom de plug-in GetShell) qui peut être utilisé à partir de n'importe quelle machine virtuelle Windows invitée sur l'hôte compromis et envoyer des commandes de sauvegarde à l'ESXi compromis et interagir avec la porte dérobée. Le chemin PDB intégré dans le binaire révèle qu'il pourrait avoir été développé en novembre 2023.
Le client prend en charge la possibilité de télécharger des fichiers d'ESXi vers la VM, de télécharger des fichiers de la VM vers ESXi et d'exécuter des commandes shell sur l'hyperviseur. Fait intéressant, le plugin GetShell est placé dans la machine virtuelle Windows sous la forme d'un fichier ZIP (“Binary.zip”), qui comprend également un fichier README avec des instructions d'utilisation, donnant un aperçu de ses fonctions de transfert de fichiers et d'exécution de commandes.
On ne sait pas clairement qui se cache derrière cette boîte à outils, mais l'utilisation du chinois simplifié, associée à la sophistication de la chaîne d'attaque et à l'abus des vulnérabilités du jour zéro des mois avant la divulgation publique, indique probablement qu'un développeur disposant de ressources suffisantes opère dans une région de langue chinoise, a théorisé Huntress.
“Cette intrusion démontre une chaîne d'attaque sophistiquée à plusieurs étapes conçue pour échapper à l'isolement des machines virtuelles et compromettre l'hyperviseur ESXi sous-jacent”, a ajouté la société. “En enchaînant fuite d'informations, corruption de mémoire et évasion du bac à sable, l'acteur malveillant a obtenu ce que craint tout administrateur de VM : un contrôle total de l'hyperviseur à partir d'une VM invitée.”
« L'utilisation de VSOCK pour la communication par porte dérobée est particulièrement préoccupante, car elle contourne complètement la surveillance réseau traditionnelle, ce qui rend la détection beaucoup plus difficile. L'ensemble d'outils donne également la priorité à la furtivité plutôt qu'à la persistance.