Windows et VMware ESXi visés par Payload, un nouveau ransomware dérivé de Babuk

Un nouveau ransomware baptisé Payload circule avec une promesse claire, frapper vite et fort en reprenant un chiffrement de type Babuk. Sa particularité, il vise à la fois des postes et serveurs Windows, et des infrastructures VMware ESXi, là où tournent souvent les machines virtuelles les plus critiques d’une entreprise.

Le sujet n’a rien d’anecdotique, les équipes d’intervention constatent une hausse nette des attaques centrées sur les hyperviseurs. Microsoft indique que les engagements de réponse à incident impliquant ESXi ont plus que doublé en trois ans. Dans ce contexte, une variante qui s’appuie sur des recettes éprouvées, dont du code issu de fuites passées, s’insère dans une tendance, industrialiser l’extorsion en visant le cur de la production.

Payload reprend des routines Babuk issues de la fuite de 2021

Le point de départ, c’est l’héritage Babuk. Identifié dès 2021, ce ransomware a marqué les grandes organisations par ses capacités multi-plateformes et des tactiques d’extorsion, avec vol de données avant chiffrement. Son histoire bascule quand le code source est divulgué sur un forum, incluant des composants pour Windows et ESXi. À partir de là, l’écosystème se fragmente, plusieurs familles reprennent des briques de chiffrement déjà prêtes.

Payload s’inscrit dans cette logique de réutilisation. Des chercheurs décrivent depuis plusieurs mois une accélération, des opérateurs reprennent des bases comme Conti, LockBit ou Babuk, et réduisent le délai entre versions Windows et Linux. Dit autrement, tu ne peux plus compter sur un « temps mort » entre deux plateformes, les attaquants cherchent une parité de fonctionnalités pour frapper les postes, puis les serveurs, puis l’hyperviseur.

Marc, analyste SOC dans une ETI industrielle, résume la difficulté, quand le code est public, le vrai différenciateur n’est plus le chiffreur, c’est l’accès initial et l’orchestration. Et c’est là la nuance importante, parler « d’un nouveau ransomware » peut donner l’impression d’une innovation majeure, mais la menace vient souvent d’une combinaison, un chiffrement connu, des outils d’administration détournés, et un ciblage plus agressif des actifs qui font mal, les VM et les sauvegardes accessibles.

Les hyperviseurs VMware ESXi deviennent la cible prioritaire des opérateurs

Pourquoi VMware ESXi attire autant? Parce qu’un hyperviseur concentre des dizaines, parfois des centaines de machines virtuelles. Quand un acteur obtient des privilèges élevés sur l’hôte, il peut chiffrer le système de fichiers et casser l’exécution des VM. Microsoft décrit des scénarios où l’attaquant obtient un contrôle administrateur sur des hyperviseurs joints au domaine, puis provoque une perte de fonctionnalité des machines hébergées. L’impact se mesure en heures d’arrêt, pas en alertes isolées.

Dans les observations publiées, les opérateurs exploitent une vulnérabilité visant l’hyperviseur, puis mettent en place des mécanismes d’administration persistants, comme la création du groupe « ESX Admins » dans le domaine et l’ajout d’un nouvel utilisateur. Ce détail compte, ce n’est pas un simple chiffrement opportuniste, c’est une prise de contrôle structurée. Une fois le terrain préparé, l’attaquant peut étendre l’attaque, accéder aux VM, exfiltrer, puis chiffrer.

Autre élément à retenir, les campagnes combinent souvent plusieurs outils. Microsoft a aussi observé l’usage de PsExec pour chiffrer des appareils hors ESXi, pendant que l’hyperviseur est attaqué. Et côté défense, l’éditeur explique que Microsoft Defender et des mécanismes de disruption automatique ont pu bloquer des tentatives de chiffrement sur des machines équipées de l’agent unifié. La critique, c’est que beaucoup d’environnements virtualisés restent gérés comme une « boîte noire », avec moins de télémétrie et de durcissement que les postes utilisateurs.

Réponse à incident et sauvegardes, les mesures qui limitent l’extorsion

Quand Payload ou une autre souche touche une organisation, les premières heures comptent. Les guides de réponse recommandent d’isoler immédiatement les systèmes infectés, de les déconnecter du réseau pour éviter la propagation, et d’activer l’équipe de réponse, interne ou externe. Dans les faits, si l’hyperviseur ESXi est atteint, l’isolement devient plus délicat, car il peut héberger des services vitaux, annuaire, ERP, fichiers, supervision.

La mesure la plus citée reste la stratégie de sauvegarde. La règle 3-2-1 revient comme standard, trois copies, sur deux supports, dont une hors site, idéalement déconnectée ou immuable. Le point dur, c’est que des sauvegardes « toujours en ligne » peuvent être chiffrées au même titre que la production. Les recommandations insistent aussi sur des tests réguliers de restauration, parce qu’une sauvegarde non testée, c’est une hypothèse, pas un plan. Et dans une attaque à double extorsion, restaurer ne règle pas la question des données volées.

D’autre part, la réduction de surface d’attaque passe par la gestion des correctifs et une gouvernance claire. Les playbooks institutionnels recommandent une évaluation des risques, l’identification des systèmes critiques, puis des procédures d’intervention avec rôles et pré-autorisations, pour éviter les blocages juridiques ou achats d’urgence au pire moment. Marc le dit sans détour, le ransomware n’attend pas ton comité de validation. Entre durcissement ESXi, segmentation, contrôle des comptes à privilèges et sauvegardes isolées, l’objectif n’est pas d’être parfait, c’est d’éviter l’arrêt complet et la négociation sous contrainte.