Ransomware ESXiArgs : une nouvelle version empêche la récupération de VMs !

Il fallait s'y attendre : les cybercriminels ont mis au point une nouvelle version du ransomware ESXiArgs pour qu'il soit impossible de récupérer les fichiers des machines virtuelles ! Faisons le point.

Hier, j'ai mis en ligne un article intitulé "Victime du ransomware ESXiArgs ? La CISA a mis en ligne un script de récupération !" : preuve que les cybercriminels sont réactifs, la méthode évoquée dans cet article est déjà obsolète.

Pour rappel, le ransomware ESXiArgs est impliqué dans une campagne d'attaques à grande échelle dans l'objectif de chiffrer les machines virtuelles d'hyperviseurs VMware ESXi. Même s'il a déjà fait plusieurs milliers de victimes, une méthode de récupération de données a rapidement vu le jour grâce au fait que le ransomware ne parvenait pas à chiffrer certains fichiers.

Ransomware ESXiArgs : une nouvelle version plus efficace

Sur un hôte infecté, le script "encrypt.sh" est présent et il recherche la présence de fichiers associés aux machines virtuelles, notamment avec les extensions suivantes : vmdk, vmx, vmxf, vmsd, nvram, etc.... Dans le but de chiffrer les VMs de l'hyperviseur.

Les pirates ont mis au point une nouvelle version du ransomware ESXiArgs dans le but d'améliorer le processus de chiffrement, notamment pour chiffrer correctement les fichiers volumineux (ce qui était le défaut de la première version).

Plus précisément, c'est la fonction "size_step" qui a été mise à jour de manière à chiffrer 50% des fichiers dont la taille est supérieure à 128 Mo, ce qui rend la récupération impossible. Ainsi les fichiers "-flat" utilisés pour récupérer les données jusqu'ici ne sont plus utilisables ! Autrement dit, la méthode de récupération qui a inspirée le script de la CISA devient inopérante.

Toutefois, gardez à l'esprit que le script de récupération peut fonctionner sur un serveur compromis à l'aide de la première version du ransomware ESXiArgs.

Des serveurs compromis même avec le service SLP désactivé ?

Au sein de cette nouvelle version, il y a un détail inquiétant : un administrateur affirme que son serveur a été compromis alors que le service SLP était bien désactivé sur son hôte VMware. Il affirme également que la backdoor "vmtool.py", vu lors de précédentes attaques, n'était pas présente sur l'hôte.

De ce fait, puisque le service SLP était désactivé, il est difficile de comprendre comment ce serveur a été compromis.... À moins que les cybercriminels exploitent une autre vulnérabilité.

A suivre...

Source