LabubaRAT est un cheval de Troie d'accès distant écrit en Rust qui se déguise en composant logiciel NVIDIA. Son exécutable se nomme "nvidia-sysruntime.exe" et usurpe l'identité de l'outil de runtime container NVIDIA, un composant légitime utilisé dans des environnements de calcul accéléré par GPU. Cette usurpation d'identité permet à LabubaRAT de passer inaperçu dans des environnements où des processus NVIDIA sont attendus, notamment sur des postes de travail d'ingénieurs, des serveurs d'inférence IA, ou des environnements de développement avec accélération GPU. Le panneau de contrôle de l'infrastructure C2 est baptisé "LabubaPanel" et affiche un favicon à l'effigie de Labubu, une figurine de collection dont la popularité a récemment explosé.
LabubaRAT supporte un ensemble de fonctionnalités qui en fait un outil de contrôle à distance complet : exécution de commandes arbitraires, exécution PowerShell, exécution de JavaScript, capture d'écrans, transfert de fichiers dans les deux sens, gestion d'archives, proxy SOCKS5, profilage de l'hôte, et détection active des logiciels de sécurité présents sur la machine compromise. Son architecture de communication supporte trois canaux distincts : HTTPS standard, le runtime WebView2 de Microsoft Edge, et le tunneling DNS, ce dernier permettant à LabubaRAT de maintenir des communications C2 même dans des environnements dont les sorties HTTP sont filtrées ou surveillées.
Le choix du langage Rust pour implémenter LabubaRAT n'est pas anodin. Rust produit des binaires natifs qui ne dépendent pas d'un runtime interprété comme .NET, Java, ou Python, ce qui réduit les traces que le malware laisse dans l'environnement d'exécution. Les outils d'analyse statique traditionnels ont des signatures et des patterns d'analyse établis pour les binaires C, C++, et pour les malwares basés sur des frameworks comme .NET. Rust est suffisamment récent dans le paysage du malware pour que certains outils d'analyse aient des couvertures moins matures sur les binaires Rust, bien que cet avantage soit en train de se réduire à mesure que les chercheurs en sécurité développent des outils spécialisés.
L'usurpation d'identité NVIDIA est un choix stratégique adapté au contexte actuel. La demande en GPU pour les charges de travail d'intelligence artificielle a transformé NVIDIA de fabricant de cartes graphiques de jeu en fournisseur critique d'infrastructure pour l'entraînement et l'inférence de modèles de langage. Les outils de runtime NVIDIA, comme le NVIDIA Container Runtime et ses composants associés, sont désormais présents dans des environnements variés : postes de développeurs IA, clusters de calcul, serveurs d'inférence en production, et environnements cloud avec instances GPU. Un processus nommé "nvidia-sysruntime.exe" dans ces environnements est suffisamment attendu pour ne pas déclencher de suspicion immédiate, contrairement à un nom de fichier générique ou manifestement suspect.
La liste des logiciels de sécurité que LabubaRAT détecte activement est révélatrice de ses cibles prioritaires. LabubaRAT recherche la présence de Google Chrome, Mozilla Firefox, Microsoft Edge, et Brave pour le profil navigateur de la victime, mais aussi de Microsoft Defender, CrowdStrike, SentinelOne, Carbon Black, Sophos, Malwarebytes, Bitdefender, ESET, Kaspersky, McAfee, Symantec, et Trend Micro pour cartographier les défenses présentes sur l'hôte compromis.
Cette cartographie des défenses sert plusieurs objectifs opérationnels. Premièrement, elle permet aux opérateurs du RAT de décider quelles actions sont risquées sur un hôte spécifique : un hôte protégé par CrowdStrike ou SentinelOne sera traité différemment d'un hôte avec uniquement Defender, car les EDR avancés ont des capacités de détection comportementale que les solutions antivirus traditionnelles n'ont pas. Deuxièmement, la liste des logiciels de sécurité est transmise au C2 comme partie du profil initial de l'hôte, permettant aux opérateurs de prioriser leurs actions sur les hôtes où le risque de détection est le plus faible. Troisièmement, dans un modèle MaaS où les clients du service achètent l'accès à LabubaRAT pour leurs propres opérations, le profil de sécurité de chaque hôte est une information commerciale : certains acheteurs d'accès initial payent plus cher pour des hôtes dans des environnements moins bien défendus.
La présence de CrowdStrike et SentinelOne dans la liste de détection indique que LabubaRAT cible des environnements d'entreprise, pas seulement des particuliers ou des petites organisations. Ces deux EDR sont principalement déployés dans des environnements corporate avec des équipes de sécurité actives. Un malware qui détecte leur présence le fait parce qu'il a été conçu pour opérer dans des environnements où ces outils sont courants, ce qui positionne LabubaRAT comme un outil destiné à des opérations contre des cibles d'entreprise.
Les chercheurs qui ont analysé LabubaRAT ont trouvé des preuves suggérant un modèle Malware-as-a-Service. Dans un modèle MaaS, l'opérateur du malware ne conduit pas lui-même toutes les attaques mais fournit l'outil, l'infrastructure C2, et parfois la formation à des clients qui paient pour accéder au service. L'indicateur principal d'un modèle MaaS dans LabubaRAT est l'architecture de configuration : les paramètres de l'implant peuvent être fournis via des arguments en ligne de commande ou des valeurs encodées en Base64, permettant la création de versions personnalisées du même binaire compilé sans nécessiter de recompilation. Cette flexibilité est caractéristique des outils conçus pour être déployés par plusieurs opérateurs distincts avec des infrastructures différentes.
Le modèle MaaS a des implications pour la défense. Dans un modèle MaaS, l'infrastructure C2 change fréquemment entre les différents clients et campagnes. Le domaine C2 connu, pipicka[.]xyz, est l'infrastructure associée à une campagne spécifique, pas nécessairement à toutes les campagnes utilisant LabubaRAT. D'autres campagnes utilisant le même outil peuvent opérer sur des domaines C2 complètement différents, ce qui rend le blocage basé uniquement sur l'IOC de domaine insuffisant. Les détections comportementales, c'est-à-dire les règles qui détectent les actions que LabubaRAT effectue plutôt que les adresses vers lesquelles il communique, sont plus robustes pour les outils MaaS que les blocages d'IOC ponctuels.
La capacité de tunneling DNS de LabubaRAT mérite une attention particulière. Le DNS est l'un des protocoles les moins susceptibles d'être bloqué dans des environnements d'entreprise, parce que sa disponibilité est indispensable pour la résolution de noms qui permet à presque toute application réseau de fonctionner. Un environnement qui bloque les requêtes DNS non essentielles risque de casser des fonctionnalités légitimes, ce qui rend la politique de filtrage DNS délicate à mettre en place.
Le DNS tunneling permet à LabubaRAT d'encoder ses communications C2 dans des requêtes DNS qui semblent normales en surface mais transportent des données arbitraires dans leurs champs de requête et de réponse. Un sous-domaine comme "abcdef1234.pipicka.xyz" peut encoder une commande ou une donnée d'exfiltration, et la réponse DNS correspondante peut encoder la réponse du serveur C2. Cette technique est détectable avec une analyse DNS suffisamment granulaire, notamment en surveillant le volume élevé de requêtes DNS vers un domaine spécifique, les sous-domaines inhabituellement longs ou à l'aspect aléatoire, et les patterns temporels de requêtes DNS qui diffèrent du comportement normal de la navigation web.
Pour les équipes sécurité, la présence de DNS tunneling dans LabubaRAT implique que la détection ne peut pas reposer uniquement sur la surveillance des connexions HTTP/HTTPS sortantes vers des destinations suspectes. Les règles de détection doivent couvrir le protocole DNS lui-même, avec des alertes sur les volumes anormaux de requêtes DNS et les patterns d'encodage caractéristiques du DNS tunneling. Des outils comme des analyseurs de logs DNS avec détection d'anomalies sont nécessaires pour couvrir ce vecteur de communication.
LabubaRAT stocke sa configuration et ses données opérationnelles dans une base de données SQLite locale. Ce choix d'implémentation a des implications pour les enquêtes forensiques. SQLite crée un fichier de base de données persistant sur le système de fichiers, généralement dans un emplacement sous le contrôle de l'utilisateur courant ou dans un répertoire temporaire selon la configuration de LabubaRAT. Ce fichier SQLite peut survivre à une tentative de suppression manuelle du binaire principal si l'attaquant a oublié de nettoyer le fichier de données, et il peut contenir des informations opérationnelles précieuses pour une investigation : historique des commandes reçues, liste des fichiers transférés, et paramètres de configuration utilisés par l'implant.
Pour les équipes de réponse aux incidents qui investiguent une infection LabubaRAT soupçonnée, rechercher des fichiers SQLite dans les répertoires temporaires, les profils utilisateur, et les répertoires d'application est une étape d'investigation à ne pas omettre. La présence d'un fichier SQLite inexpliqué dans un emplacement inhabituel sur un système où le binaire "nvidia-sysruntime.exe" a été trouvé est un indicateur fort de l'activité de LabubaRAT. Ce fichier peut également fournir des informations sur la chronologie de l'infection et la nature des données accédées ou exfiltrées.
Les indicateurs de compromission connus pour LabubaRAT incluent le nom de fichier "nvidia-sysruntime.exe" dans des emplacements qui ne correspondent pas à une installation NVIDIA légitime, le domaine C2 pipicka[.]xyz dans les logs de connexion réseau ou DNS, et des fichiers SQLite inexpliqués dans des emplacements d'utilisateur. Ces indicateurs doivent être intégrés dans les règles de détection des outils SIEM et EDR déployés dans l'organisation.
Au-delà des IOC spécifiques, les mesures défensives qui adressent LabubaRAT s'appliquent plus largement aux RAT Rust modernes. La surveillance des processus qui effectuent à la fois des lectures de fichiers système, des connexions réseau sortantes, et des requêtes WMI pour obtenir des informations matérielles (comme RAM et modèle CPU) dans une fenêtre de temps courte est caractéristique du profilage d'hôte que LabubaRAT effectue lors de son initialisation. Ce comportement combiné est inhabituel pour des processus légitimes et mérite une investigation.
Les organisations qui déploient des workloads GPU avec des outils NVIDIA devraient maintenir une liste d'inventaire des processus NVIDIA légitimes attendus dans leur environnement et surveiller les processus dont le nom ressemble à des composants NVIDIA mais dont le chemin d'exécution ou la signature numérique ne correspondent pas aux installations NVIDIA officielles. Un "nvidia-sysruntime.exe" sans signature numérique NVIDIA valide ou s'exécutant depuis un répertoire inhabituel est un signal d'alerte fort qui justifie une investigation immédiate. Comprendre votre surface d'attaque externe inclut l'identification de ces vecteurs d'usurpation d'identité logicielle qui exploitent la confiance implicite accordée aux outils reconnus.
La capacité de LabubaRAT à communiquer via Microsoft Edge WebView2 est un détail technique qui mérite une explication pour les équipes sécurité qui ne sont pas familières avec ce composant. WebView2 est le composant de rendu web de Microsoft Edge que les développeurs peuvent intégrer dans leurs applications Windows pour afficher du contenu web dans une fenêtre d'application native. Il est utilisé légitimement par de nombreuses applications d'entreprise : certaines applications Microsoft 365, des outils de développement, des interfaces d'administration, et des applications métier qui intègrent du contenu web dans leur interface utilisateur.
En utilisant WebView2 pour certaines de ses communications, LabubaRAT peut faire passer son trafic réseau comme provenant d'un processus WebView2 légitime plutôt que de son propre processus "nvidia-sysruntime.exe". Les outils de surveillance réseau qui associent les connexions réseau aux processus qui les initient pourraient attribuer certaines connexions LabubaRAT au processus WebView2 de l'application hôte, compliquant l'attribution de la connexion malveillante au bon processus. Cette technique d'utilisation de processus légitimes pour proxier des communications C2 est connue sous le nom de "process injection" ou de "living-off-the-land" dans la terminologie de threat hunting, et elle représente un défi de détection spécifique qui exige des règles de surveillance plus granulaires que la simple surveillance des connexions réseau par processus.
Pour les équipes de sécurité, la présence de WebView2 dans l'arsenal de communication de LabubaRAT implique que les règles de surveillance qui filtrent les connexions réseau en excluant les processus "connus et approuvés" peuvent manquer les communications LabubaRAT qui transitent via WebView2. Les règles de détection doivent prendre en compte non seulement le processus qui initie directement la connexion mais aussi l'arborescence de processus parent-enfant qui a mené à cette connexion, pour identifier les cas où un processus légitime est utilisé comme proxy par un processus malveillant parent.
LabubaRAT fait partie d'une tendance plus large dans le développement de malwares : la migration depuis des langages de programmation traditionnels comme C, C++, et les langages interprétés vers Rust. Cette migration a commencé à s'accélérer vers 2022-2023, quand des groupes de ransomware sophistiqués ont commencé à réécrire leurs payloads en Rust, et elle s'est depuis diffusée vers d'autres catégories de malware incluant les RAT, les infostealers, et les loaders.
Les avantages de Rust pour les développeurs de malwares sont multiples. Rust produit des binaires sans dépendances de runtime, ce qui simplifie le déploiement sur des systèmes cibles qui pourraient ne pas avoir les bibliothèques .NET, Java, ou Python requises par des malwares écrits dans ces langages. La gestion mémoire de Rust, qui garantit la sécurité mémoire à la compilation plutôt qu'à l'exécution, produit des binaires plus stables et moins susceptibles de crasher de façon révélatrice pendant les opérations. Et la relative nouveauté de Rust dans le paysage du malware signifie que certains outils d'analyse automatisée ont des signatures moins complètes pour les binaires Rust que pour les binaires écrits dans des langages plus traditionnels.
Pour les équipes de sécurité et les fournisseurs d'antivirus, la migration vers Rust présente un défi d'analyse. Les outils de décompilation et d'analyse statique traditionnels ont été optimisés pour les binaires C et C++, dont les patterns de code compilé sont bien documentés. Les binaires Rust, en particulier ceux qui utilisent les bibliothèques asynchrones et les macros complexes de Rust, produisent des patterns de code compilé différents qui peuvent dérouter les décompilateurs et les analyseurs automatisés. La communauté de recherche en sécurité développe des outils spécialisés pour l'analyse de binaires Rust, mais la maturité de ces outils est inférieure à celle des outils équivalents pour les binaires C, ce qui donne aux développeurs de malwares Rust un avantage d'obscurité temporaire.
La persistance de LabubaRAT repose sur sa configuration par arguments de ligne de commande ou valeurs Base64, ce qui signifie que le mécanisme de persistance doit créer une entrée dans le registre Windows, une tâche planifiée, ou un service Windows qui relaunch "nvidia-sysruntime.exe" avec les paramètres de configuration appropriés au démarrage du système. Chacun de ces mécanismes de persistance laisse des traces dans des emplacements standard : le registre Windows aux emplacements HKCU\Software\Microsoft\Windows\CurrentVersion\Run ou HKLM\Software\Microsoft\Windows\CurrentVersion\Run pour la persistance par registre, le planificateur de tâches Windows pour les tâches planifiées, ou le gestionnaire de services Windows pour les services.
La surveillance de la création de nouvelles entrées de registre aux emplacements de démarrage automatique, de nouvelles tâches planifiées, ou de nouveaux services Windows qui référencent des exécutables dans des emplacements inhabituels (comme les répertoires Temp, AppData, ou des chemins sans signature numérique valide NVIDIA) est une approche de détection comportementale qui fonctionnera indépendamment du nom du binaire LabubaRAT. Un "nvidia-sysruntime.exe" dans %APPDATA% ou %TEMP% qui crée une entrée de démarrage automatique est un signal d'alarme clair, même si le nom du fichier ressemble à un composant légitime.
La base de données SQLite que LabubaRAT maintient localement est également un artefact forensique précieux. Les fichiers SQLite dans des emplacements inhabituels, en particulier ceux qui contiennent des tables nommées de façon générique ou qui ont été créés par un processus nommé "nvidia-sysruntime.exe", peuvent être identifiés lors d'une investigation forensique même si le binaire principal a été supprimé. Les outils forensiques qui crawlent le système de fichiers à la recherche de fichiers SQLite et analysent leur contenu peuvent récupérer l'historique opérationnel de LabubaRAT, notamment les commandes reçues, les fichiers accédés, et les informations exfiltrées.
Le fait que l'infrastructure C2 de LabubaRAT affiche un titre "LabubaPanel" et un favicon Labubu est une décision de branding qui s'explique dans le contexte d'un modèle MaaS. Dans un service de malware vendu à plusieurs clients, un panneau d'administration reconnaissable et bien présenté est un argument commercial : il signale que le service est professionnel, bien maintenu, et développé par des opérateurs qui font attention à l'expérience utilisateur de leurs clients. La référence à Labubu, la figurine dont la popularité mondiale a explosé à travers des collaborations avec des marques de mode et de pop culture, peut également être un signal de positionnement destiné à un marché spécifique, peut-être les forums souterrains où ce type de référence culturelle résonne avec le profil démographique des acheteurs de services MaaS.
Pour les équipes de threat intelligence, la présence d'un branding distinctif dans les outils malveillants est un outil de clustering : elle permet d'associer différentes campagnes qui utilisent le même panneau ou le même service MaaS. Si "LabubaPanel" apparaît comme titre dans d'autres campagnes utilisant des domaines C2 différents de pipicka[.]xyz, ces campagnes peuvent être attribuées au même opérateur ou service MaaS avec un niveau de confiance élevé, même si les autres indicateurs techniques (domaine, IP, nom de fichier) sont entièrement différents. Le branding est, paradoxalement, l'un des éléments les plus persistants dans les opérations de malware car les opérateurs ont tendance à le maintenir pour la reconnaissance de leur "marque" auprès de leurs clients.
Les attaques comme celles décrites dans cet article rappellent pourquoi la surveillance proactive de votre exposition externe ne peut pas rester optionnelle. Quand des identifiants sont volés, quand des agents IA sont manipulés, ou quand des données d'organisation circulent dans des canaux souterrains, les dégâts sont souvent déjà faits au moment où votre équipe les détecte.
Defendis surveille le dark web, les forums criminels et les marchés souterrains pour remonter les preuves d'exposition de votre organisation avant que les attaquants ne passent à l'action. Si des identifiants ou des données liés à votre organisation apparaissent dans un log de stealer ou une annonce de broker, Defendis les remonte avec le contexte complet : l'individu concerné, les données exposées, et comment la compromission s'est probablement produite.
Réservez une démo pour voir Defendis en action.
