En septembre 2024, le Threat Labs de Netskope a publié un rapport sur le malware XWorm et sa chaîne d’infection, dévoilant alors de nouvelles instructions de commande et de contrôle (C2) et analysant ses fonctionnalités notables.
Communiqué – Après près d’un an de suivi de ce malware, les chercheurs de Netskope ont découvert une nouvelle version (version 6.0) en circulation, qui a introduit de nouvelles fonctionnalités, telles que la protection des processus et des capacités anti-analyse améliorées. Conformément à la chaîne d’infection précédemment signalée, XWorm s’exécute toujours en mémoire et continue d’utiliser des techniques d’évasion à l’exécution.
Parmi les principales conclusions relatives à la dernière version de XWorm :
- L’émergence d’une nouvelle variante de XWorm indique que le logiciel malveillant est toujours en cours de développement actif et sera probablement utilisé dans un futur proche.
- Cette dernière version inclut des fonctionnalités supplémentaires pour maintenir la persistance et échapper à l’analyse.
- Le chargeur inclut une nouvelle fonctionnalité de contournement de l’AMSI (Antimalware Scan Interface) utilisant la modification en mémoire de CLR.DLL pour éviter la détection.
XWorm 6.0 commence sa chaîne d’infection via un fichier VBScript (un « dropper ») probablement fourni via l’ingénierie sociale. Le VBScript intègre et reconstruit une autre charge utile de VBScript obscurci au moment de l’exécution. Il commence par un tableau de variables de codes de caractères. Il itère sur le tableau dans l’ordre inverse en utilisant UBound, et chaque valeur numérique est convertie en son caractère Unicode correspondant en utilisant la fonction ChrW de VBScript. Ces caractères sont ensuite concaténés pour former le VBScript malveillant réel et l’exécuter en utilisant la fonction eval.
XWorm 6.0 obtient la persistance en stockant la mise à jour.vbs à la fois dans les dossiers TEMP et APPDATA et en ajoutant ces chemins à la clé d’exécution du registre. Cela diffère du dernier échantillon XWorm précédemment signalé, qui s’est appuyé sur des tâches programmées pour maintenir l’accès.
Le constructeur client XWorm offre aux attaquants la flexibilité de sélectionner les méthodes de persistance, y compris la clé d’exécution du registre, les tâches programmées, ou le dossier de démarrage, indiquant que nous continuerons à voir des variantes en utilisant l’une de ces méthodes de persistance.
Le script PowerShell wolf-8372-4236-2751-hunter-978-ghost-9314.ps1 commence par implémenter une interface de balayage d’antimalware (AMSI) en passant en revue l’instance de la bibliothèque d’exécution du langage commun (CLR.DLL) en mémoire.
Il le fait en récupérant des informations de mémoire système et en itérant à travers toutes les régions de mémoire du processus courant en utilisant la fonction GetCurrentProcess(). Il recherche CLR.DLL dans ces régions et recherche la chaîne « AmsiScanBuffer ». Lorsqu’il est trouvé, il remplace la chaîne par des octets nuls. En conséquence, le CLR ne peut plus résoudre la méthode AmsiScanBuffer, l’empêchant de soumettre un contenu de mémoire suspect à AMSI pour inspection. L’attaquant a copié le script d’un dépôt public GitHub, remplaçant certains noms de fonction. Il télécharge ensuite le binaire XWorm à partir d’un référentiel GitHub public en utilisant le . Classe NET HTTP.client. Il le charge ensuite en mémoire en utilisant la méthode Assembly.Load, l’invoquant à son point d’entrée.
Cet échantillon XWorm 6.0, nommé Microsoft.exe, conserve la même conception opérationnelle que la version précédemment rapportée, avec quelques améliorations supplémentaires. La présente section examine les principales différences.
L’application commence par récupérer sa configuration à partir d’une chaîne codée de base-64. Le XWorm comprend un serveur de commande et de contrôle (C2) codé en dur. Bien que ce comportement soit courant parmi d’autres échantillons, il diffère de la version antérieure de Netskope Threat Labs, qui reçoit l’adresse C2 par le biais d’un argument de ligne de commande à partir d’un script PowerShell.
Une autre nouvelle fonctionnalité que nous avons découverte est la capacité de XWorm à empêcher la terminaison de processus en se marquant comme un processus critique. La définition d’un processus critique nécessite un privilège élevé, c’est pourquoi il vérifie d’abord s’il s’exécute avec des privilèges d’administrateur en vérifiant si l’utilisateur actuel appartient au groupe WindowsBuiltInRole.Administrator, qui correspond à la valeur 544.
Si XWorm est exécuté avec les privilèges d’administrateur, il invoque EnterDebugMode pour permettre à SeDebugPrivilege, lui permettant de signaler le processus XWorm comme critique. Les utilisateurs ne peuvent pas mettre fin à un processus critique sans privilèges d’administrateur. Si un utilisateur surélevé l’arrête avec force, le système va planter et nécessite un redémarrage, sur lequel XWorm sera redémarré en utilisant la clé d’exécution du registre.
XWorm intègre plusieurs techniques anti-analyse. Bien que les précédentes techniques anti-analyse restent en place, nous avons identifié une nouvelle technique qui n’était pas présente dans les échantillons précédents.
XWorm intègre plusieurs techniques anti-analyse. Bien que les précédentes techniques anti-analyse restent en place, nous avons identifié une nouvelle technique qui n’était pas présente dans les échantillons précédents.
Conclusions
La dernière version de XWorm observée dans la nature introduit de nouvelles fonctionnalités. Notamment, il marque son processus comme essentiel pour empêcher la terminaison, et améliore l’anti-analyse en évitant l’exécution dans les appareils fonctionnant sous Windows XP. De plus, XWorm est toujours exécuté directement en mémoire, et contourne AMSI en utilisant le patching en mémoire de clr.dll. Ces détails peuvent aider les défenseurs à détecter XWorm dans leur environnement et à développer des stratégies de détection basées sur ses techniques.
