Vague d’attaques contre les serveurs ESXi : un script pour automatiser la récupération

Que s’est-il passé ?

Une vaste campagne de cyberattaques avait été lancée contre certains serveurs VMware ESXi exposés directement sur Internet afin d’y exécuter ce qui a l’apparence d’un ransomware.

Après exécution, l’interface Web d’administration de l’hyperviseur et son interface en ligne de commande, son Shell, affichaient le même message (voir capture) : « Comment restaurer vos fichiers. Alerte de sécurité !!! Nous avons piraté votre entreprise avec succès […] ».

Le montant demandé était systématiquement le même, pour chaque machine compromise : un peu plus de 2 btc. À verser sur une adresse bitcoin apparemment exclusive à chaque serveur atteint.

Selon nos informations, les premières traces d’accès aux machines concernées remontent au jeudi 2 février. Mais il n’est pas possible, à ce stade des enquêtes, d’exclure des initiaux antérieurs.

L’ampleur de la campagne suggère une opération automatisée. Celle-ci a pu être conduite par un groupe ou par un acteur isolé. Mais un seul contact a été fourni à toutes les victimes, avec la même adresse de messagerie instantanée chiffrée Tox. Son pseudonyme : Sirene.

Comment l’attaquant a-t-il eu accès aux serveurs ?

Comme l’explique, avec toute la prudence qui s’impose, l’Agence nationale de la sécurité des systèmes d’information (Anssi), via le CERT-FR, « dans l’état actuel des investigations », cette campagne semble avoir exploité « la vulnérabilité CVE-2021-21974, pour laquelle un correctif est disponible depuis le 23 février 2021 ».

« Cette vulnérabilité affecte le service Service Location Protocol (SLP) et permet à un attaquant de réaliser une exploitation de code arbitraire à distance. Les systèmes actuellement visés seraient des hyperviseurs ESXi en version 6.x et antérieurs à 6.7 ».

Ce serait donc l’exploitation de cette vulnérabilité, facilitée par une exposition directe sur Internet des serveurs ESXi affectés, qui aurait permis d’en prendre le contrôle, avant de lancer l’exécution d’un script Shell chargé de déclencher l’exécutable réalisant lui-même le chiffrement. Le tout avant d’en effacer les traces après coup.

Le script Shell contient toutefois une surprise, en cours d’exécution, lors de la phase de nettoyage : une référence à un autre script, écrit en Python, dont le nom rappelle une porte dérobée pour serveurs ESXi, découverte en octobre 2022 par les Threat Labs de Juniper, et documentée en décembre dernier.

Qui a été touché ?

Selon les dernières constatations du moteur de recherche spécialisé Onyphe, près de 2 220 serveurs ESXi à travers le monde ont été frappés. Son concurrent Shodan n’en avait pour sa part repéré que plusieurs centaines, ce lundi 6 février au matin, contre plus de 3 000 pour Censys. Les balayages de ces moteurs prenant du temps, il n’a pas été possible d’obtenir immédiatement une photographie complète de la situation. Ce qui a pu donner, durant le week-end, l’impression d’une propagation.

Surtout pour chaque serveur ESXi attaqué, ce sont potentiellement plusieurs organisations affectées. Car chaque serveur peut supporter des machines virtuelles utilisées par différentes organisations. C’est notamment le cas lorsque le serveur ESXi est utilisé par un prestataire pour mutualiser ses ressources informatiques entre plusieurs clients finaux. Chacun de ces clients finaux est alors concerné.

Une recherche sur Google permet de se faire une idée de l’étendue des dégâts, certaines interfaces Web d’administration défigurées par le maliciel ayant été indexées.

En France, on trouve ainsi des systèmes rattachés à la ville de Biarritz, l’imprimerie Villière, le groupe Sofimar, les cosmétiques Payot, ou l’application Ready4Sea, notamment. La situation est d’une ampleur telle que le patron du CERT-FR, Mathieu Feuillet, est sorti de sa réserve pour l’occasion.

La grosse majorité des serveurs ESXi touchés étaient déployés sur des serveurs hébergés de type Bare Metal. De quoi expliquer la forte prévalence des hébergeurs dans la victimologie, avec notamment OVHcloud, mais également Scaleway et Ikoula.

Ce n’est pas sans raison qu’Arnaud de Bermingham, fondateur et président de Scaleway, sonnait l’alarme peu après 14h30 ce vendredi 3 février, précédé de quelques minutes par Ikoula.

Quel ransomware ?

La rumeur a, un temps, fait référence au ransomware Nevada tout récemment documenté par ReSecurity. Mais la demande de rançon observée sur les serveurs ESXi compromis aujourd’hui ne correspond pas : elle rappelle plutôt celle du rançongiciel CheersCrypt.

Des échantillons du rançongiciel et du script utilisé pour son exécution ont pu être étudiés durant le week-end. Michael Gillespie, d’ID Ransomware, a choisi de le baptiser ESXiArgs, au moins temporairement, parce que le maliciel impliqué dans cette campagne applique l’extension « .args » aux fichiers chiffrés.

Michael Gillespie a expliqué à nos confrères de Bleeping Computer que l’exécutable chargé du chiffrement utilise un algorithme peu utilisé, Sosemanuk, observé dans les dérivés de feu le rançongiciel Babuk – sur lequel est notamment basé CheersCrypt. Mais la méthode de chiffrement utilisé par ESXiArgs est différente de celle employée pour CheersCrypt.

À ce stade, la campagne déclenchée en fin de semaine dernière rappelle moins les attaques conduites avec les variants ESXi de ransomware tels qu’Avos, BlackCat, ou encore LockBit, que des campagnes comme celles ayant touché des NAS, avec Qlocker, eCh0raix ou DeadBolt.

Quels remèdes et précautions ?

Dans la nuit du vendredi au samedi 4 février, Enes Sonmez, directeur technique de YoreGroup, a produit un pas-à-pas, qui, de multiples sources concordantes, fonctionne et permet de récupérer les fichiers chiffrés sans avoir à passer par la restauration de sauvegardes. De quoi potentiellement aider à accélérer la remise en route des services affectés.

Dans son alerte, le CERT-FR recommande « d’appliquer sans délai le contournement proposé par [VMware en 2021] qui consiste à désactiver le service SLP sur les hyperviseurs ESXi qui n’auraient pas été mis à jour », et plus encore « d’appliquer l’ensemble des correctifs disponibles pour l’hyperviseur ESXi », en versions 7.x antérieures à 70U1c-17325551, 6.7.x antérieures à 670-202102401-SG, et 6.5.X antérieures à 650-202102101-SG.

Les soupçons d’exploitation d’une porte dérobée méritent également la recherche d’un fichier vmtools.py sur les serveurs ESXi restés trop longtemps exposés sur Internet sans que soient appliqués les correctifs disponibles.

Enfin, de nombreuses voix se sont élevées durant le week-end pour déplorer l’exposition directe, sur Internet, sans serveur de rebond ni application de certaines mesures d’hygiène dites de base pour les serveurs hébergés.

Des zones d'ombre

La relative facilité de récupération des données suscite de nombreuses interrogations sur la réelle motivation du (ou des) attaquant(s). Et cela d'autant plus que certains systèmes touchés dans le cadre de la campagne déclenchée le 3 février présentent des traces de primo-infection antérieure. Pour l'un d'entre eux, les premières constations d'Onyphe remontent au 20 janvier. Pour le second, elles datent du 18 janvier. Mais avec la même note de rançon.

Dans le cas de ces deux systèmes, la note de rançon observée en janvier mentionnait un montant moitié moindre, une adresse e-mail, et l'adresse d'un nœud Tor : yytf6btdhrikgywd6aluwbafjgm5oj3pan2lg3czvhs34obs3brid7ad[.]onion. Germán Fernández, chercheur au sein de CronUp, a trouvé les traces d'une note de rançon mentionnant ce nœud Tor remontant au 18 octobre 2022. Les scanners d'Onyphe l'avaient observé pour la première fois 12 octobre, et l'ont vu pour la dernière fois le 20 janvier 2023 - alors même que la rançon (un peu plus de 1 btc) a été versée le 14 octobre. A l'automne dernier, ce sont 12 serveurs ESXi compromis de la sorte qui ont été observés par Onyphe. 

Impossible de déterminer, en l'état, si le maliciel utilisé pour le chiffrement était le même, ou ne serait-ce que proche, de celui distribué et déclenché le 3 février. Mais la note de rançon suggère qu'il y avait, pour ces attaques antérieures, vol de données et double-extorsion. Le nœud Tor observé est aujourd'hui inaccessible. L'action isolée d'un membre d'un groupe plus vaste, ayant voulu prendre de vitesse ses comparses, n'est pas à exclure.