Une équipe de recherche indépendante a mis en lumière une nouvelle porte dérobée Windows baptisée SLEEPWALKER. Son fonctionnement repose sur un principe simple mais efficace : tant qu’un paquet réseau spécialement construit n’atteint pas la machine, la charge utile demeure inactive. Une fois le déclencheur reçu, le composant exécute des commandes via un langage de type bytecode, conçu pour ne laisser que peu de traces exploitables hors du binaire lui-même.
D’après les éléments documentés, le malware n’initie pas de connexions sortantes et ne comporte pas de domaines, d’adresses IP ou d’URL intégrés dans son fichier. Cette approche vise notamment à réduire la visibilité côté outils de sécurité qui surveillent les communications avec des infrastructures connues.
Une DLL 64 bits chargée par side-loading
Le échantillon analysé prend la forme d’une DLL Windows 64 bits non signée d’environ 59 904 octets. Sa particularité est de pouvoir être side-loadée dans le processus ERAAgent.exe, le composant exécutable de ESET Management Agent.
Le binaire imite une bibliothèque système de Microsoft, dpapi.dll, en exportant les mêmes sept fonctions liées à la protection des données. Il inclut aussi une ressource de version copiée depuis l’artefact ESET Management Agent, ce qui peut aider à tromper certains contrôles superficiels basés sur les métadonnées.
Autre point notable : le fichier ne contient pas d’adresse réseau et n’effectue pas, de lui-même, de trafic vers l’extérieur. En clair, un hôte infecté peut sembler “propre” pour des solutions qui se focalisent sur les connexions sortantes.
Inertie jusqu’au paquet déclencheur
SLEEPWALKER ne s’active pas immédiatement après son chargement. Les informations partagées indiquent que l’exécution se déclenche uniquement après réception d’un paquet correspondant à un format attendu. Une configuration embarquée, chiffrée via AES-256-CCM, est ensuite décryptée pour produire une instruction de surveillance.
À partir de ce moment, le malware se met à observer indéfiniment toutes les interfaces réseau pour détecter le paquet déclencheur précis. Le composant ne se limite pas au trafic destiné à la machine : il capture également les échanges adressés à d’autres hôtes.
Cette conception a une conséquence importante en environnement partagé. Dans un segment comprenant un gateway, un serveur VPN ou un pont reliant deux sous-réseaux, un déclencheur destiné à une autre cible pourrait indirectement être “vu” par SLEEPWALKER et provoquer l’activation sur un hôte inattendu.
Bytecode et clé : des opcodes à déchiffrer dans le fichier
Au lieu de recevoir des instructions sous forme de texte lisible, le backdoor attend des commandes codées, présentées comme du bytecode. Selon la documentation, récupérer la clé de déchiffrement permet d’obtenir des opcodes dans un format qui n’existe que dans ce fichier spécifique.
Cette logique rend l’analyse plus complexe : même si l’on parvient à comprendre le mécanisme général, la sémantique précise des instructions dépend du contenu déchiffré et de la structure interne du binaire.
Le chercheur Dominik Reichel souligne que la démarche correspond davantage à une opération ciblée, dotée de ressources, qu’à un déploiement opportuniste.
Exécution dépendante du processus hôte
Pour déclencher son fonctionnement, SLEEPWALKER ne vérifie pas une signature numérique, mais s’appuie sur le nom du processus hôte. L’intégration du composant dans le bon répertoire requiert par ailleurs des droits d’administrateur locaux déjà détenus par l’opérateur.
Le malware ne semble pas cherchant à escalader les privilèges par lui-même. Il exploite le contexte de sécurité du processus dans lequel il est chargé. Autrement dit, SLEEPWALKER agit davantage comme un implant post-compromission qu’un point d’entrée initial.
Un autre élément confirme cette idée : la persistance repose sur le seul chargement side-loadé, qui se reproduit à chaque démarrage du service d’ESET Management Agent. Comme la technique s’appuie sur l’ordre de recherche des DLL de Windows plutôt que sur un défaut précis dans le logiciel ESET, il n’y aurait pas de “patch” ciblé côté application.
Transports multiples et suivi réseau étendu
Les commandes peuvent emprunter plusieurs voies (transports) selon les éléments recensés dans la documentation. Il est notamment question de TCP, UDP, ICMP, de pipes nommés SMB permettant un mouvement latéral avec des identifiants valides, ainsi que de mécanismes de capture “promiscuités” à niveau paquet.
Le binaire utilise également l’interface de communication d’une machine virtuelle, VMCI (Virtual Machine Communication Interface). Dans ce cas, le trafic passe par la couche de virtualisation plutôt que par une carte réseau classique. Résultat : une capture réalisée “entre deux machines” peut ne pas inclure ce flux particulier.
La documentation rappelle des observations déjà vues dans des intrusions précédemment décrites, où VMCI a pu servir de canal entre hôtes ESXi compromis et machines virtuelles invitées.
Signaux de détection et configuration système
La recherche liste plusieurs indicateurs utiles. Parmi eux :
- Un dpapi.dll inattendu à côté de ERAAgent.exe
- Un dpapisvc.dll inattendu dans le même répertoire
- Des empreintes : SHA-256 et MD5 fournies dans l’analyse
- La valeur EveryoneIncludesAnonymous définie à 1
- Une entrée inattendue dans NullSessionPipes
Il est toutefois précisé que les deux clés de registre ne sont pertinentes que par rapport à une base “connue correcte” pour le parc concerné. Autrement dit, la comparaison à l’état normal de vos systèmes reste essentielle pour éviter les faux positifs.
Le chercheur a également publié une règle YARA et un scanner PowerShell en lecture seule afin de rechercher ces indices dans un ensemble de machines. Il indique que la couverture de détection du fichier serait faible au moment de la publication, sans détailler le contexte de cette évaluation.
Un point technique supplémentaire mérite attention : la règle YARA se base en partie sur une clé AES statique et sur du code de protocole compilé. Une recompilation avec d’autres paramètres de compilation pourrait casser une partie de la reconnaissance statique.
Nettoyage : attention au registre NullSessionPipes
Pour permettre à des appelants non authentifiés d’atteindre son canal basé sur un pipe nommé, SLEEPWALKER configure EveryoneIncludesAnonymous à 1 et ajoute le nom du pipe dans NullSessionPipes.
Le malware garde une trace pour savoir si son propre écriture dans cette clé a réussi, plutôt que de vérifier l’existence préalable d’une entrée. En conséquence, lors de la suppression, le nettoyage pourrait supprimer une valeur qui était déjà légitime avant l’infection.
Ce détail est important pour les équipes de réponse à incident : après confirmation, il faut vérifier l’historique et la configuration d’origine du système.
Portée limitée des preuves : attribution et victimes non établies
Le billet de recherche s’appuie sur un seul binaire sans contexte de collecte additionnel. Le chercheur indique ne pas pouvoir rattacher l’échantillon à un acteur connu, ni établir le type de victimes, le secteur ou le pays.
Il n’a pas non plus déterminé si le malware a réellement été déployé dans la durée. En outre, au moment du partage, aucune déclaration publique n’a été publiée par ESET concernant un avis ou des mesures spécifiques, et l’analyse mentionne que l’équipe a été sollicitée pour fournir d’éventuelles informations de télémétrie.
Pourquoi cette porte dérobée Windows mérite une vigilance accrue
Plusieurs facteurs font de SLEEPWALKER un cas à surveiller : l’inertie jusqu’au déclencheur réseau, l’absence de connexions sortantes “classiques”, l’exécution via bytecode, et la dépendance à une chaîne de chargement DLL par side-loading.
Le fait que la surveillance capture le trafic passant par les interfaces, y compris celui destiné à d’autres machines, renforce aussi l’idée que l’impact peut dépasser une cible “attendue” dans certains environnements réseau.
Dans une démarche de sécurité pragmatique, l’approche recommandée consiste à comparer la configuration actuelle (notamment les valeurs de registre citées) à des baselines connues, et à rechercher les indicateurs de fichiers et d’empreintes présents dans la documentation.
Conclusion
SLEEPWALKER illustre une manière discrète d’opérer : une porte dérobée Windows chargée via side-loading, qui reste muette tant qu’un paquet réseau précis n’arrive pas. Une fois activée, elle surveille durablement les interfaces réseau et exécute des commandes sous forme de bytecode, rendant l’analyse difficile sans disposer du binaire complet.
Pour les équipes défensives, la meilleure réponse consiste à vérifier les indicateurs partagés, à contrôler l’état des paramètres de registre, et à s’assurer que l’environnement ne permet pas des chargements DLL abusifs dans les répertoires attendus.
Source: https://thehackernews.com/2026/08/newly-sleepwalker-backdoor-waits-for.html
