Sous le SADBRIDGE avec GOSAR : QUASAR reçoit une réécriture de Golang

Introduction

Elastic Security Labs a récemment observé une nouvelle série d'intrusions ciblant les régions de langue chinoise, répertoriée sous le nom de REF3864. Ces campagnes organisées ciblent les victimes en se faisant passer pour des logiciels légitimes tels que des navigateurs web ou des services de messagerie de médias sociaux. Le groupe de menace à l'origine de ces campagnes fait preuve d'une certaine polyvalence en diffusant des logiciels malveillants sur de multiples plateformes telles que Linux, Windows et Android. Au cours de cette enquête, notre équipe a découvert une chaîne d'infection Windows unique avec un chargeur personnalisé que nous appelons SADBRIDGE. Ce chargeur déploie une réimplémentation de QUASAR basée sur Golang, que nous appelons GOSAR. C'est la première fois que notre équipe observe une réécriture de QUASAR dans le langage de programmation Golang.

Principaux points abordés dans cet article

• Campagnes continues ciblant les locuteurs de la langue chinoise avec des installateurs malveillants se faisant passer pour des logiciels légitimes tels que Telegram et le navigateur web Opera.
• Les chaînes d'infection emploient l'injection et le chargement latéral de DLL à l'aide d'un chargeur personnalisé (SADBRIDGE).
• SADBRIDGE déploie une variante récemment découverte de la porte dérobée QUASAR écrite en Golang (GOSAR).
• GOSAR est une porte dérobée multifonctionnelle en cours de développement actif, avec des caractéristiques incomplètes et des itérations de caractéristiques améliorées observées au fil du temps.
• Elastic Security offre des capacités complètes de prévention et de détection de cette chaîne d'attaque.

REF3864 Vue d'ensemble de la campagne

En novembre, l'équipe d'Elastic Security Labs a observé une chaîne d'infection unique lors de la détonation de plusieurs échantillons différents téléchargés sur VirusTotal. Ces différents échantillons ont été hébergés via des pages de renvoi se faisant passer pour des logiciels légitimes tels que Telegram ou le navigateur Opera GX.

Au cours de cette enquête, nous avons découvert plusieurs chaînes d'infection faisant appel à des techniques similaires :

• Installateurs MSI troyens faiblement détectés
• Se faire passer pour un logiciel légitime contenant des DLL malveillantes.
• Déploiement d'un chargeur SADBRIDGE sur mesure
• Phase finale GOSAR chargé

Nous pensons que ces campagnes sont passées inaperçues en raison des multiples niveaux d'abstraction. En général, la première phase consiste à ouvrir un fichier d'archive (ZIP) qui contient un programme d'installation MSI. Un logiciel légitime comme l'application de débogage Windows x64dbg.exe est utilisé en coulisses pour charger une DLL malveillante et corrigée (x64bridge.dll). Cette DLL lance un nouveau programme légitime (MonitoringHost.exe) dans lequel elle charge latéralement une autre DLL malveillante (HealthServiceRuntime.dll), pour finalement réaliser une injection et charger l'implant GOSAR dans la mémoire via l'injection.

Les chercheurs de logiciels malveillants ont extrait des configurations de SADBRIDGE qui révèlent des dates de campagne désignées par l'adversaire et indiquent que des opérations avec des TTP similaires sont en cours depuis au moins décembre 2023. L'infrastructure de commande et de contrôle (C2) de GOSAR se fait souvent passer pour des services ou des logiciels de confiance afin de paraître inoffensive et de répondre aux attentes des victimes en matière d'installation de logiciels. Tout au long de la chaîne d'exécution, l'accent est mis sur l'énumération des produits audiovisuels chinois tels que 360tray.exe, ainsi que sur les noms et les descriptions en chinois des règles de pare-feu. En raison de ces personnalisations, nous pensons que cette menace est destinée à cibler les locuteurs de la langue chinoise. En outre, l'utilisation intensive de la journalisation en langue chinoise indique que les attaquants sont également des locuteurs de la langue chinoise.

QUASAR a déjà été utilisé dans le cadre d'activités d'espionnage parrainées par des États, d'actes d'hacktivisme non étatiques et d'attaques criminelles à motivation financière depuis 2017 (Qualys, Evolution of Quasar RAT), notamment par APT10, un groupe lié à la Chine. Une réécriture en Golang pourrait tirer parti des connaissances institutionnelles acquises au cours de cette période, ce qui permettrait d'accroître les capacités sans avoir à reformuler en profondeur des TTP déjà efficaces.

GOSAR étend QUASAR avec des capacités supplémentaires de collecte d'informations, une prise en charge multi-OS et une meilleure évasion contre les produits antivirus et les classificateurs de logiciels malveillants. Cependant, les sites web génériques de leurre et l'absence d'informations supplémentaires sur le ciblage ou d'actions sur l'objectif nous laissent avec des preuves insuffisantes pour identifier les motivations de l'attaquant.

SADBRIDGE Introduction

Le chargeur de logiciels malveillants SADBRIDGE est présenté sous la forme d'un exécutable MSI et utilise le chargement latéral de DLL avec diverses techniques d'injection pour exécuter des charges utiles malveillantes. SADBRIDGE exploite des applications légitimes telles que x64dbg.exe et MonitoringHost.exe pour charger des DLL malveillantes telles que x64bridge.dll et HealthServiceRuntime.dll, ce qui conduit à des étapes ultérieures et à des shellcodes.

La persistance est assurée par la création de services et la modification du registre. L'escalade des privilèges vers l'administrateur se produit silencieusement en utilisant une technique de contournement de l'UAC qui abuse de l'interface ICMLuaUtil COM. En outre, SADBRIDGE intègre un contournement de l'escalade des privilèges par le biais du planificateur de tâches de Windows afin d'exécuter sa charge utile principale avec des privilèges de niveau SYSTÈME.

La configuration de SADBRIDGE est cryptée par une simple soustraction de 0x1 sur chaque octet de la chaîne de configuration. Les étapes cryptées sont toutes accompagnées d'une extension .log et décryptées en cours d'exécution à l'aide de XOR et de l'algorithme de décompression LZNT1.

SADBRIDGE utilise les techniques de PoolParty, de files d'attente APC et de manipulation de jetons pour l'injection de processus. Pour éviter l'analyse du bac à sable, il utilise de longs Sleep longs. Une autre technique d'évasion de la défense consiste à appliquer des correctifs à l'API afin de désactiver les mécanismes de sécurité de Windows, tels que l'interface d'analyse antimalware (AMSI) et le suivi des événements pour Windows (ETW).

L'analyse approfondie qui suit est structurée de manière à explorer la chaîne d'exécution, en fournissant une description étape par étape des capacités et des fonctionnalités des principaux fichiers et étapes, sur la base de la configuration de l'échantillon analysé. L'analyse vise à mettre en évidence l'interaction entre chaque composant et leur rôle dans l'atteinte de la charge utile finale.

SADBRIDGE Analyse du code

Analyse MSI

Les fichiers initiaux sont empaquetés dans un MSI à l'aide d'Advanced Installer, les principaux fichiers d'intérêt étant x64dbg.exe et x64bridge.dll.

En utilisant l'outil MSI(lessmsi), nous pouvons voir que le point d'entrée LaunchApp dans aicustact.dll est configuré pour exécuter le chemin d'accès au fichier spécifié dans la propriété AI_APP_FILE.

Si nous naviguons vers cette propriété AI_APP_FILE, nous pouvons voir que le fichier lié à cette configuration est x64dbg.exe. Il s'agit du fichier qui sera exécuté une fois l'installation terminée, le fichier légitime NetFxRepairTool.exe n'étant jamais exécuté.

x64bridge.dll Chargement latéral

Lorsque x64dbg.exe est exécuté, il appelle l'exportation BridgeInit de x64bridge.dll. BridgeInit est une enveloppe pour la fonction BridgeStart.

À l'instar des techniques observées avec BLISTER, SADBRIDGE patche l'exportation d'une DLL légitime.

Au cours de la routine d'initialisation du logiciel malveillant, SADBRIDGE commence par générer un hachage à partir du nom d'hôte et d'une graine magique 0x4E67C6A7. Ce hachage est utilisé comme nom de répertoire pour stocker le fichier de configuration crypté. La configuration cryptée est écrite sur C:\Users\Public\Documents\<hostname_hash>\edbtmp.log. Ce fichier contient les attributs FILE_ATTRIBUTE_SYSTEM, FILE_ATTRIBUTE_READONLY, FILE_ATTRIBUTE_HIDDEN pour se cacher d'une liste de répertoires ordinaire.

Le décryptage de la configuration est simple, les morceaux cryptés sont séparés par des octets nuls. Pour chaque octet contenu dans les morceaux cryptés, nous pouvons les incrémenter de 0x1.

La configuration est la suivante :

• Date possible de la campagne
• Chaînes à utiliser pour la création de services
• Nouveau nom pour MonitoringHost.exe (DevQueryBroker.exe)
• Nom de la DLL à charger en parallèle par MonitoringHost.exe (HealthServiceRuntime.dll)
• Chemins absolus pour les étapes supplémentaires (.log fichiers)
• La cible d'injection primaire pour l'hébergement de GOSAR (svchost.exe)

Le répertoire DevQueryBroker (C:\ProgramData\Microsoft\DeviceSync\Device\Stage\Data\DevQueryBroker\) contient toutes les étapes cryptées (.log fichiers) qui sont décryptées au moment de l'exécution. Le fichier (DevQueryBroker.exe) est une copie renommée de l'application légitime de Microsoft (MonitoringHost.exe).

Enfin, il crée un processus pour exécuter DevQueryBroker.exe qui charge latéralement le fichier malveillant HealthServiceRuntime.dll dans le même dossier.

HealthServiceRuntime.dll

Ce module dépose un shellcode chiffré et partiellement déchiffré dans le répertoire %TEMP% de l'utilisateur. Le nom du fichier du shellcode suit le format suivant : log<random_string>.tmp. Chaque octet du shellcode partiellement décrypté est ensuite décrémenté de 0x10 pour un décryptage complet. Le shellcode est exécuté dans un nouveau thread du même processus.

Le logiciel malveillant exploite le hachage de l'API en utilisant le même algorithme que celui utilisé dans les recherches publiées par SonicWall ; l'algorithme de hachage est répertorié dans la section Annexe. Le shellcode décrypte DevQueryBroker.log dans un fichier PE, puis effectue une simple opération XOR avec un seul octet (0x42) dans le premier tiers du fichier) et décompresse le résultat à l'aide de l'algorithme LZNT1.

Le shellcode annule ensuite toutes les correspondances existantes à l'adresse de base préférée du fichier PE en utilisant NtUnmapViewOfSection, ce qui garantit qu'un appel à VirtualAlloc allouera de la mémoire à partir de l'adresse de base préférée. Enfin, il fait correspondre le fichier PE décrypté à la mémoire allouée et transfère l'exécution à son point d'entrée. Tous les shellcodes identifiés et exécutés par SADBRIDGE partagent une structure de code identique, ne différant que par les fichiers .log spécifiques qu'ils référencent pour le décryptage et l'exécution.

DevQueryBroker.log

Le logiciel malveillant charge dynamiquement amsi.dll pour désactiver les mécanismes de sécurité critiques de Windows. Il corrige AmsiScanBuffer dans amsi.dll en insérant des instructions pour modifier la valeur de retour en 0x80070057, le code d'erreur standardisé de Microsoft E_INVALIDARG indiquant des arguments non valides, et en retournant prématurément, afin de contourner efficacement la logique d'analyse. De même, il corrige AmsiOpenSession pour qu'il renvoie toujours le même code d'erreur E_INVALIDARG. En outre, il corrige EtwEventWrite en ntdll.dll, en remplaçant la première instruction par une instruction ret pour désactiver le suivi des événements pour Windows (ETW), supprimant ainsi tout enregistrement d'activité malveillante.

Après l'application du correctif, un shellcode crypté est écrit sur temp.ini au niveau du chemin (C:\ProgramData\Microsoft\DeviceSync\Device\Stage\Data\DevQueryBroker\temp.ini).
Le logiciel malveillant vérifie l'appartenance au groupe du jeton de processus actuel afin de déterminer son niveau de privilège. Il vérifie si le processus appartient au compte LocalSystem en initialisant un SID avec le SECURITY_LOCAL_SYSTEM_RID et en appelant le CheckTokenMembership. Si ce n'est pas le cas, il tente de vérifier l'appartenance au groupe des administrateurs en créant un SID à l'aide de SECURITY_BUILTIN_DOMAIN_RID et DOMAIN_ALIAS_RID_ADMINS et en effectuant une vérification similaire de l'appartenance à un jeton.

Si le processus en cours ne dispose pas des privilèges LocalSystem ou Administrateur, les privilèges sont d'abord élevés au niveau Administrateur par un mécanisme de contournement de l'UAC en utilisant l'interface ICMLuaUtil COM. Il crée une chaîne de moniker "Elevation:Administrator!new:{3E5FC7F9-9A51-4367-9063-A120244FBEC7}" pour créer une instance de l'objet CMSTPLUA avec des privilèges d'administrateur. Une fois l'objet créé et l'interface ICMLuaUtil obtenue, le logiciel malveillant utilise la méthode ShellExec exposée de l'interface pour exécuter DevQueryBroker.exe.

Si une tâche ou un service n'est pas créé pour exécuter DevQueryBroker.exe de manière routinière, le logiciel malveillant vérifie si le processus antivirus 360tray.exe est en cours d'exécution. S'il n'est pas en cours d'exécution, un service est créé pour l'escalade des privilèges vers SYSTEM, avec les propriétés suivantes :

• Nom du service : DevQueryBrokerService
  Nom du chemin binaire : "C:\ProgramData\Microsoft\DeviceSync\Device\Stage\Data\DevQueryBroker\DevQueryBroker.exe -svc".
• Nom d'affichage : DevQuery Background Discovery Broker Service
• Description : Permet aux applications de découvrir des appareils à l'aide d'une tâche d'arrière-plan.
• Type de démarrage : Automatiquement au démarrage du système
• Privilèges : Système local

Si 360tray.exe est détecté en cours d'exécution, le logiciel malveillant écrit un fichier PE crypté sur DevQueryBrokerService.log, puis mappe un fichier PE de l'étape suivante (étape 1) dans la mémoire du processus en cours, lui transférant l'exécution.

Une fois que DevQueryBroker.exe est redéclenché avec des privilèges de niveau SYSTEM et qu'il atteint cette partie de la chaîne, le logiciel malveillant vérifie la version de Windows. Pour les systèmes fonctionnant sous Vista ou une version ultérieure (à l'exception de Windows 7), il mappe une autre étape suivante (étape 2) dans la mémoire et y transfère l'exécution.

Sous Windows 7, cependant, il exécute un shellcode, qui décrypte et exécute le fichier DevQueryBrokerPre.log.

Stage 1 Injection (explorer.exe)

SADBRIDGE utilise la variante 7 de PoolParty pour injecter un shellcode dans explorer.exe en ciblant la file d'attente d'achèvement des E/S de son pool de threads. Il duplique d'abord un handle vers la file d'attente d'achèvement des E/S du processus cible. Il alloue ensuite de la mémoire dans explorer.exe pour stocker le shellcode. De la mémoire supplémentaire est allouée pour stocker une structure TP_DIRECT élaborée, qui comprend l'adresse de base du shellcode en tant qu'adresse de rappel. Enfin, il appelle ZwSetIoCompletion, en passant un pointeur à la structure TP_DIRECT pour mettre en file d'attente un paquet dans la file d'attente d'achèvement des E/S de la fabrique de travailleurs du processus cible (gestionnaire de threads de travailleurs), ce qui déclenche effectivement l'exécution du shellcode injecté.

Ce shellcode décrypte le fichier DevQueryBrokerService.log, décode les régions de mémoire occupant son adresse de base préférée, mappe le fichier PE à cette adresse, puis exécute son point d'entrée. Ce comportement reflète celui du shellcode observé précédemment.

Stage 2 Injection (spoolsv.exe/lsass.exe)

Pour l'étape 2, SADBRIDGE injecte un shellcode dans spoolsv.exe, ou lsass.exe si spoolsv.exe n'est pas disponible, en utilisant la même technique d'injection qu'à l'étape 1. Le shellcode présente un comportement similaire aux étapes précédentes : il décrypte DevQueryBrokerPre.log dans un fichier PE, dématérialise toutes les régions occupant son adresse de base préférée, dématérialise le fichier PE, puis transfère l'exécution à son point d'entrée.

DevQueryBrokerService.log

Le shellcode décrypté à partir de DevQueryBrokerService.log, comme indiqué dans la section précédente, exploite une technique d'escalade des privilèges utilisant le planificateur de tâches de Windows. SADBRIDGE intègre une technique publique de contournement de l 'UAC utilisant l'objet IElevatedFactorySever COM pour créer indirectement la tâche planifiée. Cette tâche est configurée pour s'exécuter quotidiennement DevQueryBroker.exe avec des privilèges de niveau SYSTÈME en utilisant le nom de tâche DevQueryBrokerService.

Afin de brouiller les pistes, le logiciel malveillant falsifie le chemin d'accès à l'image et la ligne de commande en modifiant directement le bloc d'environnement de processus (PEB), probablement dans le but de masquer le service COM comme provenant de explorer.exe.

DevQueryBrokerPre.log

SADBRIDGE crée un service nommé DevQueryBrokerServiceSvc sous la sous-clé de registre SYSTEM\CurrentControlSet\Services\DevQueryBrokerServiceSvc avec les attributs suivants :

• Description: Permet aux applications de découvrir des appareils à l'aide d'une tâche d'arrière-plan.
• Nom d'affichage: DevQuery Background Discovery Broker Service
• Contrôle d'erreur: 1
• ImagePath: %systemRoot%\system32\svchost.exe -k netsvcs
• Nom de l'objet: LocalSystem
• Démarrage: 2 (démarrage automatique)
• Type: 16.
• Actions en cas d'échec:
  • Réinitialise le comptage des défaillances toutes les 24 heures.
  • Exécute trois tentatives de redémarrage : un délai de 20 ms pour la première, et un délai d'une minute pour la deuxième et la troisième.

Les paramètres de service spécifient le ServiceDll situé au C:\Program Files (x86)\Common Files\Microsoft Shared\Stationery\<hostname_hash>\DevQueryBrokerService.dll. Si le fichier DLL n'existe pas, il sera déposé sur le disque immédiatement après.

DevQueryBrokerService.dll a une structure de code similaire à celle de HealthServiceRuntime.dll, qui apparaît dans les premières étapes de la chaîne d'exécution. Il est chargé de décrypter DevQueryBroker.log et de l'exécuter. Le ServiceDll sera chargé et exécuté par le svchost.exe lorsque le service démarrera.

En outre, il modifie la clé SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost\netsvcs pour inclure une entrée pour DevQueryBrokerServiceSvc afin d'intégrer le service nouvellement créé dans le groupe de services géré par le groupe d'hôtes de services netsvcs.

SADBRIDGE supprime ensuite la tâche planifiée et le service créés précédemment en supprimant les sous-clés de registre SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Schedule\\TaskCache\\Tree\\DevQueryBrokerService et SYSTEM\\CurrentControlSet\\Services\\DevQueryBrokerService.

Enfin, il supprime les fichiers DevQueryBroker.exe et HealthServiceRuntime.dll du dossier C:\ProgramData\Microsoft\DeviceSync\Device\Stage\Data\DevQueryBroker, car le nouveau mécanisme de persistance est en place.

Injection GOSAR

Dans la seconde moitié du code, SADBRIDGE énumère toutes les sessions actives sur la machine locale à l'aide de l'API WTSEnumerateSessionsA.

Si des sessions sont trouvées, il parcourt chacune d'entre elles :

• Pour chaque session, il tente de récupérer le nom d'utilisateur (WTSUserName) en utilisant WTSQuerySessionInformationA. Si la requête échoue, elle passe à la session suivante.
• Si WTSUserName n'est pas vide, le code cible svchost.exe, en transmettant son chemin d'accès, l'identifiant de session et le contenu de la configuration du chargeur à une sous-routine qui injecte l'étape finale.
• Si WTSUserName est vide mais que WinStationName de la session est "Services" (indiquant une session de service), il cible dllhost.exe à la place, en transmettant les mêmes paramètres au sous-programme d'injection de l'étape finale.

Si aucune session n'est trouvée, il entre dans une boucle infinie pour énumérer plusieurs fois les sessions et invoquer le sous-programme d'injection de l'étape finale, tout en effectuant des contrôles pour éviter les injections redondantes.

Les sessions connectées ciblent svchost.exe, tandis que les sessions de service ou les sessions sans utilisateur connecté ciblent dllhost.exe.

Si un identifiant de session est disponible, le code tente de dupliquer le jeton d'utilisateur pour cette session et d'élever le niveau d'intégrité du jeton dupliqué à S-1-16-12288 (intégrité du système). Il utilise ensuite le jeton élevé pour créer un processus enfant (svchost.exe ou dllhost.exe) via CreateProcessAsUserA.

Si la manipulation du jeton échoue ou si aucun identifiant de session n'est disponible (les processus du système peuvent avoir un identifiant de session de 0), la création d'un processus sans jeton est rétablie en utilisant CreateProcessA.

Le shellcode crypté C:\ProgramData\Microsoft\DeviceSync\Device\Stage\Data\DevQueryBroker\temp.ini est décrypté à l'aide de la même technique de décompression XOR et LZNT1 que celle utilisée précédemment pour décrypter les fichiers .log, et l'injection APC est utilisée pour mettre le shellcode en file d'attente en vue de son exécution dans le fil d'exécution du processus nouvellement créé.

Enfin, le shellcode injecté déchiffre DevQueryBrokerCore.log en GOSAR et l'exécute dans la mémoire du processus nouvellement créé.

Introduction au GOSAR

GOSAR est un cheval de Troie multifonctionnel d'accès à distance qui cible les systèmes Windows et Linux. Cette porte dérobée permet notamment de récupérer des informations sur le système, d'effectuer des captures d'écran, d'exécuter des commandes, d'enregistrer les frappes au clavier, et bien plus encore. La porte dérobée GOSAR conserve une grande partie des fonctionnalités et du comportement de base de QUASAR, tout en incorporant plusieurs modifications qui la différencient de la version originale.

La réécriture des logiciels malveillants dans des langages modernes tels que Go permet de réduire les taux de détection, car de nombreuses solutions antivirus et classificateurs de logiciels malveillants peinent à identifier les chaînes de caractères ou les caractéristiques malveillantes dans ces nouvelles constructions de programmation. Vous trouverez ci-dessous un bon exemple d'un GOSAR déballé ne recevant que 5 détections lors du téléchargement.

Cette variante prend notamment en charge plusieurs plates-formes, y compris les binaires ELF pour les systèmes Linux et les fichiers PE traditionnels pour Windows. Cette capacité multiplateforme s'aligne sur l'adaptabilité de Go, ce qui le rend plus polyvalent que le QUASAR original basé sur .NET. Dans la section suivante, nous nous concentrerons sur la structure du code de GOSAR, les nouvelles fonctionnalités et les ajouts par rapport à la version open-source (QUASAR).

Aperçu de l'analyse du code GOSAR

Structure du code de GOSAR

Le binaire ayant conservé tous ses symboles, nous avons pu reconstruire la structure du code source, qui a été extraite d'un échantillon de la version 0.12.01

• vibrant/config: Contient les fichiers de configuration du logiciel malveillant.
• vibrant/proto: contient toutes les déclarations de Google Protocol Buffers (proto).
• vibrant/network: Inclut les fonctions liées au réseau, telles que la boucle de connexion principale, la gestion du proxy, ainsi que le fil de configuration du pare-feu et la mise en place d'un auditeur.
• vibrant/msgs/resolvers: Définit les commandes gérées par le logiciel malveillant. Ces commandes sont assignées à un objet dans les fonctions vibrant_msgs_init*.
• vibrant/msgs/services: Introduit de nouvelles fonctionnalités, telles que l'exécution de services comme les enregistreurs de frappe, les enregistreurs de presse-papiers, ces services sont lancés dans la fonction vibrant_network._ptr_Connection.Start.
• vibrant/logs: Responsable de l'enregistrement de l'exécution du logiciel malveillant. Les journaux sont cryptés à l'aide d'une clé AES stockée dans la configuration. Le logiciel malveillant décrypte les journaux par morceaux à l'aide de l'AES.
• vibrant/pkg/helpers: Contient des fonctions d'aide utilisées par divers services et commandes de logiciels malveillants.
• vibrant/pkg/screenshot: Gère la fonctionnalité de capture d'écran sur le système infecté.
• vibrant/pkg/utils: Inclut des fonctions utilitaires, telles que la génération de valeurs aléatoires.
• vibrant/pkg/native: Fournit des fonctions pour appeler les fonctions de l'API Windows (WINAPI).

Nouveaux ajouts au GOSAR

Communication et collecte d'informations

Cette nouvelle variante continue d'utiliser la même méthode de communication que l'originale, basée sur TCP TLS. Lors de la connexion, il envoie d'abord des informations sur le système au C2, en y ajoutant 4 de nouveaux champs :

• Adresse IP
• AntiVirus
• Paramètres du presse-papiers
• Portefeuilles

La liste des antivirus et des portefeuilles numériques est initialisée dans la fonction vibrant_pkg_helpers_init et se trouve au bas de ce document.

Services

Le logiciel malveillant gère 3 services qui sont lancés lors de la connexion initiale du client au C2 :

• vibrant_services_KeyLogger
• vibrant_services_ClipboardLogger
• vibrant_services_TickWriteFile

KeyLogger

La fonctionnalité de keylogging dans GOSAR est implémentée dans la fonction vibrant_services_KeyLogger. Cette fonction s'appuie sur les API Windows pour intercepter et enregistrer les frappes de clavier sur le système infecté en définissant un crochet Windows global avec SetWindowsHookEx avec le paramètre WH_KEYBOARD_LL pour surveiller les événements de bas niveau du clavier. La fonction de crochet est nommée vibrant_services_KeyLogger_func1.

ClipboardLogger

La fonctionnalité d'enregistrement du presse-papiers est simple et repose sur les API de Windows. Il vérifie d'abord la disponibilité des données du presse-papiers à l'aide de IsClipboardFormatAvailable, puis les récupère à l'aide de GetClipboardData. API.

TickWriteFile

Les services ClipboardLogger et KeyLogger collectent des données qui sont écrites périodiquement par le service TickWriteFile dans le répertoire (C:\ProgramData\Microsoft\Windows\Start Menu\Programs\diagnostics) sous un fichier de la date actuelle, exemple 2024-11-27.
Il peut être décrypté en soustrayant d'abord la valeur 0x1f, puis en la xant avec la valeur 0x18, comme le montre la recette de CyberChef.

Mise en réseau

Après avoir initialisé ses services, le logiciel malveillant crée trois threads dédiés à sa configuration réseau.

• vibrant_network_ConfigFirewallRule
• vibrant_network_ConfigHosts
• vibrant_network_ConfigAutoListener

Gestion des fils pour la mise en réseau

ConfigFirewallRule

Le logiciel malveillant crée une règle de pare-feu entrant pour la plage de ports 51756-51776 sous un nom chinois qui est traduit par Distributed Transaction Coordinator (LAN). Il autorise tous les programmes et toutes les adresses IP à entrer, la description étant définie comme suit :Inbound rules for the core transaction manager of the Distributed Transaction Coordinator service are managed remotely through RPC/TCP..

ConfigHosts

Cette fonction ajoute une entrée à c:\Windows\System32\Drivers\etc\hosts le 127.0.0.1 micrornetworks.com suivant. La raison de l'ajout de cette entrée n'est pas claire, mais elle est probablement due à des fonctionnalités manquantes ou incomplètes dans la phase actuelle de développement du logiciel malveillant.

ConfigAutoListener

Cette fonctionnalité du logiciel malveillant exécute un serveur HTTP sur le premier port disponible dans la plage 51756-51776, qui était auparavant autorisé par une règle de pare-feu. Il est intéressant de noter que le serveur ne traite aucune commande, ce qui prouve que le logiciel malveillant est encore en cours de développement. La version actuelle ne traite qu'une requête GET vers l'URI /security.js et répond par la chaîne callback();, toute autre requête renvoie un code d'erreur 404 . Cette réponse minimale pourrait indiquer que le serveur est un espace réservé ou qu'il fait partie d'un stade de développement précoce, avec la possibilité d'ajouter ultérieurement des fonctionnalités plus complexes.

Logs

Le logiciel malveillant enregistre ses journaux d'exécution dans le répertoire : %APPDATA%\Roaming\Microsoft\Logs sous le nom de fichier formaté comme suit : windows-update-log-<YearMonthDay>.log: .
Chaque entrée de journal est cryptée avec l'algorithme HMAC-AES ; la clé est codée en dur dans la fonction vibrant_config, dont voici un exemple :

L'attaquant peut récupérer à distance les journaux d'exécution du logiciel malveillant en lançant la commande ResolveGetRunLogs.

Plugins

Le logiciel malveillant a la capacité d'exécuter des plugins, qui sont des fichiers PE téléchargés à partir du C2 et stockés sur le disque crypté à l'aide d'un algorithme XOR. Ces plugins sont sauvegardés dans le chemin d'accès : C:\ProgramData\policy-err.log. Pour exécuter un plugin, la commande ResolveDoExecutePlugin est appelée, elle vérifie d'abord si un plugin est disponible.

Il charge ensuite de manière réflexive une DLL native stockée au format base64 dans le fichier binaire nommé plugins.dll et exécute sa fonction d'exportation ExecPlugin.

ExecPlugin crée un processus suspendu de C:\Windows\System32\msiexec.exe avec les arguments /package /quiet. Il met ensuite en file d'attente les appels de procédure asynchrones (APC) vers le thread principal du processus. Lorsque le thread est repris, le shellcode mis en file d'attente est exécuté.

Le shellcode lit le plugin crypté stocké à C:\ProgramData\policy-err.log, le décrypte à l'aide d'une clé XOR codée en dur sur 1 octet, puis le charge et l'exécute par réflexion.

HVNC

Le logiciel malveillant prend en charge le VNC caché (HVNC) par le biais du socket existant, il expose 5 commandes

• Résoudre la commandeHVNCC
• ResolveGetHVNCScreen
• RésoudreArrêterHVNC
• ResolveDoHVNCKeyboardEvent
• ResolveDoHVNCMouseEvent

La première commande exécutée est ResolveGetHVNCScreen, qui va d'abord l'initialiser et mettre en place une vue, elle utilise une DLL native intégrée HiddenDesktop.dll au format base64, la DLL est chargée par réflexion dans la mémoire et exécutée.

La DLL est chargée d'exécuter les API de bas niveau pour configurer la HVNC, avec un total de 7 fonctions exportées :

• ExcuteCommand
• DoMouseScroll
• DoMouseRightClick
• Déplacement de la souris
• DoMouseLeftClick
• DoKeyPress
• CaptureScreen

La première fonction d'exportation appelée est Initialise pour initialiser un bureau avec CreateDesktopA API. Cette implémentation HVNC gère 17 commandes au total qui peuvent être trouvées dans l'exportation ExcuteCommand, comme indiqué, il y a une faute de frappe dans le nom, l'ID de la commande est transmis à partir de la commande ResolveHVNCCommand du logiciel malveillant qui appellera ExcuteCommand.

Capture

Le logiciel malveillant charge par réflexion la troisième et dernière DLL PE intégrée au format base64 nommée Capture.dll, elle possède 5 fonctions d'exportation :

• CaptureFirstScreen
• CaptureNextScreen
• GetBitmapInfo
• GetBitmapInfoSize
• Définir la qualité

La bibliothèque est d'abord initialisée en appelant resolvers_ResolveGetBitmapInfo qui charge et exécute de manière réflexive DllEntryPoint qui configurera les structures de capture d'écran à l'aide des API Windows courantes telles que CreateCompatibleDC, CreateCompatibleBitmap et CreateDIBSection. Les fonctions d'exportation 2 CaptureFirstScreen et CaptureNextScreen sont utilisées pour effectuer une capture d'écran du bureau de la victime sous forme d'image JPEG.

Observation

Il est intéressant de noter que le serveur QUASAR .NET d'origine peut toujours être utilisé pour recevoir des balises des échantillons GOSAR, étant donné qu'ils ont conservé le même protocole de communication. Toutefois, son utilisation opérationnelle nécessiterait d'importantes modifications pour prendre en charge les fonctionnalités du GOSAR.

Il n'est pas clair si les auteurs ont mis à jour ou étendu le serveur QUASAR .NET à source ouverte, ou s'ils en ont développé un entièrement nouveau. Il est intéressant de noter qu'ils ont conservé le port d'écoute par défaut, 1080, conformément à l'implémentation originale.

Nouvelle fonctionnalité

Le tableau suivant fournit une description de toutes les commandes nouvellement ajoutées :

Logiciels malveillants et MITRE ATT&CK

Elastic utilise le cadre MITRE ATT& CK pour documenter les tactiques, techniques et procédures communes que les menaces utilisent contre les réseaux d'entreprise.

Tactiques

Les tactiques représentent le pourquoi d'une technique ou d'une sous-technique. Il s'agit de l'objectif tactique de l'adversaire : la raison pour laquelle il effectue une action.

• Collecte
• Commande et contrôle
• Évasion par la défense
• Découverte
• Exécution
• Exfiltration
• Persistance
• Escalade des privilèges

Techniques

Les techniques représentent la manière dont un adversaire atteint un objectif tactique en effectuant une action.

• Flux d'exécution du pirate : chargement latéral de DLL
• Capture d'entrée : Enregistrement du clavier
• Injection de processus : Appel de procédure asynchrone
• Découverte du processus
• Cacher les artefacts : Fenêtre cachée
• Créer ou modifier un processus système : Service Windows
• Port non standard
• Abuser d'un mécanisme de contrôle d'élévation : Contournement du contrôle de compte d'utilisateur
• Masquage des fichiers ou des informations
• Affaiblir les défenses : Désactiver ou modifier des outils
• Évasion par virtualisation/boîte à sable : Evasion basée sur le temps

Atténuation REF3864

Détection

• Contournement potentiel de l'interface d'analyse antimalware via PowerShell
• Processus enfant du spooler d'impression inhabituel
• Exécution à partir d'un répertoire inhabituel - Ligne de commande
• Recherche d'adresse IP externe à partir d'un processus non lié au navigateur
• Relation parent-enfant inhabituelle
• Connexion réseau inhabituelle via DllHost
• Persistance inhabituelle via le registre des services
• Usurpation du PID du processus parent

La prévention

• Connexion au réseau via un processus avec des arguments inhabituels
• Potential Masquerading as SVCHOST (Camouflage potentiel en SVCHOST)
• Module réseau chargé à partir d'une mémoire non sauvegardée suspecte
• UAC Bypass via ICMLuaUtil Elevated COM Interface (Contournement de l'UAC via l'interface COM à privilèges élevés ICMLuaUtil)
• Chargement potentiel d'une image avec un temps de création falsifié

YARA

Elastic Security a créé des règles YARA pour identifier cette activité.

• Multi.Trojan.Gosar
• Windows.Trojan.SadBridge

Observations

Les observables suivants ont été examinés dans le cadre de cette recherche :

Références

Les éléments suivants ont été référencés tout au long de la recherche ci-dessus :

• https://zcgonvh.com/post/Advanced_Windows_Task_Scheduler_Playbook-Part.2_from_COM_to_UAC_bypass_and_get_SYSTEM_dirtectly.html
• https://www.sonicwall.com/blog/project-androm-backdoor-trojan
• https://www.safebreach.com/blog/process-injection-using-windows-thread-pools/
• https://gist.github.com/api0cradle/d4aaef39db0d845627d819b2b6b30512

Annexe

Algorithme de hachage (SADBRIDGE)

def ror(x, n, max_bits=32) -> int:
    """Rotate right within a max bit limit, default 32-bit."""
    n %= max_bits
    return ((x >> n) | (x << (max_bits - n))) & (2**max_bits - 1)

def ror_13(data) -> int:
    data = data.encode('ascii')
    hash_value = 0

    for byte in data:
        hash_value = ror(hash_value, 13)
        
        if byte >= 0x61:
            byte -= 32  # Convert to uppercase
        hash_value = (hash_value + byte) & 0xFFFFFFFF

    return hash_value


def generate_hash(data, dll) -> int:
    dll_hash = ror_13(dll)
    result = (dll_hash + ror_13(data)) & 0xFFFFFFFF
    
    return hex(result)

Produits AV vérifiés dans GOSAR