StingyBasilisk : un APT inconnu utilise les Named Pipes Windows pour espionner discrètement

Ce qui s'est passé

Les chercheurs de Positive Technologies ont publié un rapport détaillé sur un groupe APT jusque-là inconnu qu'ils ont baptisé StingyBasilisk. La découverte est le fruit d'une réponse à incident sur un réseau d'une organisation non divulguée, sur lequel les analystes ont retracé une présence persistante remontant à au moins avril 2022. À l'heure de la détection, le groupe était encore actif. L'investigation a permis de reconstituer une infrastructure technique sophistiquée dont la caractéristique principale est l'utilisation des named pipes Windows comme canal de commande et contrôle (C2).

Les named pipes sont un mécanisme de communication inter-processus intégré à Windows depuis ses premières versions. Ils permettent à deux processus — sur la même machine ou sur des machines du même réseau local — d'échanger des données via un canal nommé, sans passer par des sockets réseau classiques visibles par les outils de surveillance du trafic. Cette architecture présente un avantage tactique considérable pour un attaquant : les communications C2 ne génèrent pas de flux TCP ou UDP sortants directement attribuables à un processus malveillant, ce qui les rend invisibles pour la grande majorité des solutions de détection réseau traditionnelles.

L'implant principal identifié par Positive Technologies est un backdoor qu'ils ont nommé CunningDoor. Ce composant s'appuie sur une technique de DLL sideloading utilisant des bibliothèques signées de SafeNet, un fabricant de matériels d'authentification. Concrètement, CunningDoor charge ses modules malveillants en exploitant le mécanisme de résolution des DLL de Windows : un exécutable légitime et signé de SafeNet (notamment IKEYUI64.exe avec IKEYUI64.dll, ou eToken.exe avec DLPReel.dll) charge en réalité une DLL malveillante placée dans le même répertoire, qui est ensuite exécutée dans le contexte de confiance du binaire signé. Cette approche permet à l'implant de s'exécuter en contournant les contrôles d'intégrité basés sur les signatures.

Pour le mouvement latéral, StingyBasilisk s'appuie sur Impacket, le framework Python open source largement utilisé en tests d'intrusion. Plus précisément, les attaquants utilisent atexec, le module d'Impacket qui ouvre le named pipe atsvc et crée des tâches planifiées via MS-RPC. Pour éviter d'être détectés par les règles de surveillance ciblant les noms de tâches standard d'Impacket, les opérateurs ont modifié la convention de nommage par défaut : les tâches créées suivent un pattern de type GUID (par exemple, {3F7A9B2C-1D4E-4F5A-8B2C-9D1E3F7A9B2C}) plutôt que le préfixe caractéristique d'Impacket. Ce détail, en apparence mineur, révèle un niveau de familiarité avec les techniques de détection qui distingue StingyBasilisk d'un groupe peu sophistiqué.

L'architecture C2 via named pipes présente une autre caractéristique remarquable : elle permet d'atteindre des machines sans accès direct à Internet en les chaînant à travers le réseau local. Un hôte compromis connecté à Internet peut servir de relais pour d'autres hôtes situés sur des segments réseau isolés, qui communiquent via des named pipes SMB. Les implants créent des pipes avec des patterns de nommage prévisibles (souvent de type GUID) et attendent l'arrivée de shellcode chiffré. Cette architecture rappelle le fonctionnement des implants Cobalt Strike Beacon en mode SMB, mais avec des composants sur mesure permettant à StingyBasilisk d'éviter les signatures associées aux outils commerciaux connus.

Positive Technologies mentionne également l'utilisation de la technique de COM hijacking — le détournement de clés de registre COM pour faire charger des bibliothèques malveillantes par des processus légitimes — ainsi que la manipulation des fournisseurs Windows Time (W32Time). En enregistrant un fournisseur W32Time malveillant, les attaquants peuvent faire charger leur code à chaque démarrage du service de synchronisation horaire, assurément l'une des méthodes de persistance les moins surveillées dans les environnements d'entreprise.

L'identité de StingyBasilisk reste inconnue. Positive Technologies indique ne pas pouvoir relier l'activité de manière fiable à un groupe APT connu. Aucune infrastructure partagée, aucun code réutilisé et aucun artefact linguistique ne permettent d'établir un lien avec les groupes documentés dans les bases de renseignement existantes. Le vecteur d'accès initial reste lui aussi non déterminé. La durée de la présence — plus de quatre ans — suggère soit une opération d'espionnage de long terme à la recherche d'informations stratégiques, soit que l'organisation cible ne réalisait pas le niveau de visibilité requis pour détecter ce type d'activité persistante.

La divulgation publique intervient dans un contexte de multiplication des découvertes de groupes APT à l'architecture C2 non conventionnelle. Plusieurs groupes récents ont adopté des canaux DNS-over-HTTPS, des communications via des services cloud légitimes (GitHub, OneDrive) ou, comme StingyBasilisk, des mécanismes IPC natifs de l'OS. Cette évolution reflète l'adaptation des acteurs sophistiqués aux progrès des plateformes EDR modernes, qui ont rendu les C2 HTTP/HTTPS classiques beaucoup plus facilement détectables.

Pourquoi c'est important

La découverte de StingyBasilisk illustre une réalité inconfortable pour les équipes de sécurité : quatre ans de présence sur un réseau sans détection. Même dans des organisations dotées de solutions de sécurité, un attaquant suffisamment patient et technique peut maintenir un accès durable en restant sous les seuils de détection. L'utilisation de named pipes comme C2 est précisément choisie pour cette raison : elle exploite un mécanisme légitime et omniprésent de Windows, générant peu ou pas de bruit réseau, et reste encore aujourd'hui en dehors du périmètre de surveillance de nombreuses organisations.

Le DLL sideloading avec des bibliothèques SafeNet signées mérite une attention particulière. Les logiciels de gestion de tokens matériels sont présents dans de nombreuses entreprises, notamment celles qui utilisent l'authentification forte via HSM ou smartcards. Ces environnements chargent régulièrement des DLL SafeNet dans des répertoires variés, ce qui rend l'anomalie plus difficile à isoler dans les logs d'audit. Les équipes de défense doivent enrichir leurs règles de surveillance pour détecter les exécutables SafeNet chargeant des DLL depuis des chemins inhabituels comme %TEMP% ou les répertoires utilisateur.

La technique de modification des noms de tâches planifiées Impacket est également un signal que les opérateurs de StingyBasilisk connaissent précisément les règles de détection déployées par leurs cibles. Cette conscience des mécanismes de détection adversariale n'est pas le fait de groupes débutants ou d'acteurs opportunistes : elle caractérise des opérateurs entraînés dont les TTP évoluent en réponse directe aux publications de la communauté de sécurité.

Pour les entreprises, ce cas soulève la question fondamentale de la détection dans la durée. Un SOC efficace doit être capable d'identifier des activités qui, prises individuellement, semblent anodines, mais révèlent un pattern d'intrusion sur des semaines ou des mois. Les technologies UEBA (User and Entity Behavior Analytics) et les plateformes XDR avec corrélation temporelle longue deviennent, face à des groupes comme StingyBasilisk, non plus des options mais des nécessités opérationnelles.

Ce qu'il faut retenir

• StingyBasilisk est un APT non attribué actif depuis au moins 2022, utilisant les named pipes Windows pour un C2 furtif qui contourne la surveillance réseau classique.
• CunningDoor, son backdoor principal, exploite le DLL sideloading avec des bibliothèques SafeNet signées, et les attaquants adaptent leurs TTP pour contourner les règles de détection Impacket connues.
• Pour détecter ce type d'activité : surveiller l'événement 106 du Task Scheduler, les événements 4688, les nouvelles entrées de fournisseurs W32Time et les chargements de DLL SafeNet depuis des répertoires temporaires.