À l’intérieur du code d’une nouvelle variante de XWorm

XWorm est un représentant relativement nouveau de la cohorte des chevaux de Troie d’accès à distance qui a déjà gagné sa place parmi les menaces les plus persistantes à travers le monde.

Depuis 2022, date à laquelle il a été observé pour la première fois par des chercheurs, il a subi un certain nombre de mises à jour majeures qui ont considérablement amélioré ses fonctionnalités et solidifié sa pérennité.

L’équipe d’analystes de TOUT.RUN est tombé sur la dernière version du malware et n’a pas pu refuser l’opportunité de le démonter pour examiner les configurations mécaniques de XWorm. Voici comment ils ont procédé et ce qu’ils ont trouvé.

Source de l’exemple XWorm

L’échantillon en question a été découvert dans ANY. La base de données de logiciels malveillants de RUN, un référentiel contenant des rapports d’analyse détaillés sur tous les fichiers et liens téléchargés par les utilisateurs du bac à sable en mode public.

Un rapide coup d’œil aux résultats de l’analyse a révélé que l’échantillon avait été initialement distribué via MediaFire, un service d’hébergement de fichiers. Le malware était regroupé dans une archive RAR et protégé par un mot de passe.

Figure 1 : La page MediaFire contenant le lien de téléchargement de l’archive.

Lors de son exécution, la menace a été instantanément détectée par les règles Suricata et identifiée comme étant XWorm.

Figure 2 : trafic de XWorm marqué comme malveillant par le bac à sable.

Tactiques, techniques et procédures (TTP) de XWorm

Le rapport sandbox a mis en évidence plusieurs techniques utilisées par l’échantillon :

Figure 3 : Activités de XWorm sur le système infecté.

MITRE T1547.001 : XWorm a ajouté son raccourci au répertoire de démarrage.

MITRE T1053.005 : il a utilisé le planificateur de tâches pour se redémarrer avec des privilèges élevés, comme indiqué par le paramètre “/RL HIGHEST”.

MITRE T1074.001 : Le logiciel a été installé dans le répertoire Public.

MITRE T1571 : le logiciel malveillant a tenté de se connecter à un serveur distant, mais aucune réponse n’a été reçue.

Tentative ratée de XWorm pour échapper à l’analyse sandbox

Le rapport d’analyse initial datant de plusieurs jours, l’équipe a décidé de faire passer à nouveau l’échantillon dans le bac à sable pour vérifier de nouvelles activités.

Cependant, après son lancement, le malware s’est écrasé presque immédiatement. Une brève enquête a montré que l’échantillon interrogeait désormais un service spécial pour déterminer s’il fonctionnait dans un bac à sable virtuel.

Essentiellement, les développeurs de XWorm ont mis en œuvre une technique d’évasion, qui provoquait l’arrêt du logiciel malveillant dès qu’il détectait un environnement virtualisé.

Pour surmonter ce problème, l’équipe a activé Residential Proxy dans les paramètres du bac à sable. Cette fonctionnalité remplace l’adresse IP du centre de données de la machine virtuelle par celle d’un véritable FAI, faisant croire au logiciel malveillant qu’il s’exécute sur la machine d’un utilisateur réel.

Figure 4 : Le proxy résidentiel fournit des adresses IP provenant de nombreux

Après avoir réexécuté l’exemple avec le proxy résidentiel activé, XWorm a été exécuté avec succès et a commencé son activité.

De plus, grâce à la fonction proxy MITM, il a été possible d’extraire les informations transmises par XWorm à Telegram (MITRE T1102). Les données comprenaient : la version du malware (XWorm V3.1), le nom d’utilisateur de la machine, la version du système d’exploitation et probablement le hachage de la victime.

Figure 5 : XWorm a collecté des informations système (MITRE T1082).

Analyse statique de la nouvelle variante XWorm

Après avoir rassemblé toutes les informations cruciales fournies par le bac à sable, les analystes ont entamé la phase d’analyse statique de leurs recherches. La première étape consistait à charger l’échantillon dans Detect it Easy (DIE), une norme industrielle pour l’analyse initiale des logiciels malveillants. Le programme a rapidement déterminé qu’il s’agissait d’une variante .NET de XWorm.

Figure 6 : DIE a fourni un aperçu du compilateur du malware.

À partir de là, la seule étape logique pour l’équipe était d’ouvrir le fichier dans dnSpy, un débogueur .NET, qui a rapidement révélé que le binaire était sujet à une forte obscurcissement. Cependant, DIE n’a pas réussi à reconnaître le conditionneur, même en utilisant l’analyse heuristique.

Figure 7 : Le code du XWorm s’est avéré obscurci (MITRE T1027).

L’utilisation de de4dot, un désobfuscateur et décompresseur .NET, n’a également eu aucun effet.

Plus de techniques d’évasion et de persistance de XWorm

Une enquête plus approfondie sur le binaire malveillant a permis à l’équipe de découvrir des pièces supplémentaires du puzzle. Plus précisément, un certain nombre de mécanismes supplémentaires utilisés par le malware ont été découverts :

Détection de virtualisation : XWorm a utilisé la requête WMI « Select * from Win32_ComputerSystem » pour vérifier les environnements VmWare ou VirtualBox.

Figure 8 : Le malware exploitait Windows Management Instrumentation (MITRE T1047).

Détection du débogueur : Il a également exécuté la fonction API CheckRemoteDebuggerPresent pour voir si elle était en cours de débogage.

Figure 9 : Xworm a tenté d’échapper à l’analyse du débogueur.

Détection du bac à sable : Le binaire a analysé le système pour voir si la bibliothèque SbieDll.dll était chargée.

Figure 10 : SbieDll.dll est associé à Sandboxie, un programme d’isolation basé sur un bac à sable.

Vérification IP du centre de données : Xworm a interrogé la machine pour déterminer si elle était hébergée dans un centre de données.

Figure 11 : L’analyse IP du malware explique la raison de son crash initial.

Persistance: XWorm a utilisé le registre et le planificateur de tâches pour établir une présence persistante sur le système.

Figure 12 : Le code a révélé la capacité du malware à modifier le registre.

Extraction de la configuration de XWorm

Ensuite, les analystes ont trouvé un constructeur qui ressemblait à un bloc contenant des paramètres. Ils ont utilisé une fonction pour réaffecter certains de ses champs. Le malware a d’abord calculé un hachage MD5 à partir d’une valeur dans la section des paramètres présumés.

Il a ensuite copié la valeur obtenue deux fois dans un tableau temporaire, mais en raison d’une erreur un par un, le MD5 n’a pas été copié entièrement deux fois. L’équipe a utilisé le tableau obtenu comme clé pour déchiffrer les chaînes base64 entrantes à l’aide d’AES en mode ECB.

Ils ont également constaté que le champ utilisé était un mutex. L’ensemble du processus est décrit en détail dans l’article du blog d’ANY.RUN “XWorm : analyse technique d’une nouvelle version de malware“.

Configuration de XWorm

La configuration complète de la nouvelle variante de XWorm est la suivante :

Conclusion

L’obtention des configurations des derniers logiciels malveillants est cruciale mais prend du temps. Pour le rendre plus efficace, vous pouvez exécuter vos échantillons via le bac à sable ANY.RUN pour accéder aux informations nécessaires en quelques secondes.

Vérifiez-le vous-même à l’aide du XWorm échantillon. De plus, ANY.RUN propose un essai gratuit de 14 jours de son plan principal aux équipes de sécurité pour les aider à tester les capacités du service.