Akira Ransomware cible les ESXi via une faille vCenter

Chaîne d attaque observée

L analyse forensique des incidents révèle une chaîne d attaque en 5 phases :

1. Accès initial : exploitation de la faille vCenter (CVSS 9.1) pour obtenir un shell sur le serveur vCenter
2. Reconnaissance : inventaire des hosts ESXi, datastores et VMs critiques via les API vSphere
3. Mouvement latéral : connexion SSH aux hosts ESXi avec les credentials vCenter compromises
4. Exfiltration : copie des fichiers VMDK critiques vers un serveur de staging via rsync chiffré
5. Chiffrement : déploiement du ransomware Akira Linux pour chiffrer les fichiers .vmdk, .vmx et .vmxf

Mesures de protection immédiates

• Patcher vCenter immédiatement (VMSA-2026-0008)
• Isoler le management plane : vCenter et ESXi ne doivent jamais être exposés sur Internet
• Activer le lockdown mode sur tous les hosts ESXi
• Sauvegardes offline : vérifier que les sauvegardes Veeam/NAKIVO sont sur un réseau isolé
• MFA obligatoire sur les accès vSphere Client

Pour renforcer la sécurité de votre infrastructure de virtualisation, consultez nos guides sur le hardening Proxmox et la sécurisation ESXi/vSphere.

Contexte : ESXi, cible de choix pour les ransomwares depuis 2023

L'attaque menée par Akira s'inscrit dans une tendance lourde observée depuis la campagne ESXiArgs de février 2023, qui avait touché plus de 3 800 serveurs VMware dans le monde en exploitant une vulnérabilité OpenSLP vieille de deux ans. Depuis, les hyperviseurs ESXi sont devenus une cible stratégique prioritaire pour les groupes de ransomware : chiffrer un seul host ESXi permet de paralyser simultanément des dizaines de machines virtuelles, démultipliant l'impact opérationnel pour un effort d'intrusion minimal. Les groupes LockBit, BlackCat/ALPHV et Akira lui-même disposent tous, depuis 2023, de chiffreurs Linux dédiés spécifiquement optimisés pour les systèmes de fichiers VMFS et les architectures ESXi. Akira, actif depuis mars 2023, avait déjà revendiqué plus de 350 victimes confirmées avant cette campagne, avec une prédilection marquée pour les PME et ETI des secteurs industriel, santé et services financiers — des organisations disposant souvent d'infrastructures de virtualisation critiques mais de ressources SOC limitées.

Une vulnérabilité vCenter à fort impact

La faille exploitée (CVSS 9.1) touche le moteur d'authentification SSO de vCenter Server et permet, selon les premières analyses de VMware, une exécution de code à distance sans authentification préalable dans certaines configurations. Ce type de vulnérabilité critique sur vCenter n'est pas inédit : en 2023 déjà, la CVE-2023-34048 (débordement de tampon dans le protocole DCE/RPC) avait été exploitée activement par des groupes APT chinois avant sa divulgation publique, démontrant que les acteurs étatiques et les groupes cybercriminels surveillent activement ce vecteur. La rapidité avec laquelle Akira a pu automatiser l'exploitation à grande échelle — 47 organisations touchées en un mois — suggère soit une fuite d'informations techniques sur la faille avant le correctif officiel, soit un travail de reverse engineering accéléré une fois le patch VMSA-2026-0008 publié, une pratique connue sous le nom de patch diffing.

Impact sectoriel et enjeux de continuité d'activité

Sur les 47 victimes recensées, l'analyse des communiqués publics et des données de threat intelligence fait apparaître une répartition sectorielle révélatrice : environ 40 % opèrent dans l'industrie manufacturière, 25 % dans la santé, 15 % dans les services financiers et le solde dans la distribution et les collectivités territoriales. Cette concentration n'est pas fortuite — ces secteurs combinent souvent une dépendance forte à la virtualisation pour des applications métier critiques (ERP, PACS médicaux, systèmes de paiement) et un niveau de maturité cybersécurité hétérogène. Le montant moyen des rançons exigées, entre 500 000 et 5 millions de dollars, reflète une stratégie de tarification adaptée à la taille et à la criticité perçue de l'infrastructure chiffrée : Akira ajuste historiquement ses demandes en fonction du chiffre d'affaires estimé de la victime, une pratique documentée depuis ses premières campagnes de 2023.

Au-delà du coût direct de la rançon, l'indisponibilité d'un cluster ESXi complet génère des pertes d'exploitation souvent sous-évaluées : arrêt de production, rupture de la chaîne logistique, interruption des systèmes de facturation. Le cabinet Coveware estimait déjà en 2025 le temps de récupération moyen après un chiffrement d'infrastructure de virtualisation à 18 jours ouvrés, contre 9 jours pour une compromission limitée à des postes de travail — un écart qui illustre la criticité particulière de ce vecteur d'attaque et justifie la priorité accordée par les RSSI au durcissement du plan de management de leurs environnements vSphere.

Réactions et recommandations des éditeurs

VMware (Broadcom) a qualifié la situation d'« urgence critique » dans son bulletin de sécurité et recommande un correctif immédiat, sans fenêtre de maintenance différée — une posture rare qui témoigne de la gravité perçue de l'exploitation active. L'agence américaine CISA a ajouté la vulnérabilité à son catalogue Known Exploited Vulnerabilities (KEV), imposant aux agences fédérales un délai de correction de 48 heures, tandis que l'ANSSI a émis une alerte CERT-FR appelant les opérateurs d'infrastructures critiques à vérifier immédiatement l'exposition de leurs serveurs vCenter. Plusieurs éditeurs de solutions EDR/XDR (CrowdStrike, SentinelOne, Microsoft Defender) ont publié en urgence des règles de détection spécifiques ciblant les commandes SSH anormales vers les hosts ESXi et les patterns d'exfiltration via rsync observés dans cette campagne, permettant une identification plus précoce des compromissions en cours avant la phase de chiffrement.

Indicateurs de compromission à surveiller

• Connexions SSH inhabituelles vers les hosts ESXi depuis le réseau de management vCenter
• Création de comptes locaux non documentés sur les hyperviseurs ESXi
• Volumes de trafic sortant anormaux via rsync ou rclone depuis le réseau de stockage
• Présence de fichiers de rançon akira_readme.txt dans les datastores VMFS
• Modifications non planifiées des règles de pare-feu ESXi (lockdown mode désactivé)