SideWalk : Potentiellement aussi dangereux que CROSSWALK

Découvrez SparklingGoblin, un membre de l’infâme famille Winnti.

Découvrez SparklingGoblin, un membre de l’infâme famille Winnti.

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 – 2e 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 :

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

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 :

Offset0x000x040x080x12
0x00"expa""nd 3""2-by""te k"
0x16Key Key Key Key
0x32Key Key Key Key
0x480x0000000BNonce Nonce Nonce

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.

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. Decompiled code of SideWalk’s anti-tampering procedure

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 :

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. Decompiled code responsible for user impersonation before retrieving the proxy configuration

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

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

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.

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

Command ID (C&C to malware)Response ID (malware to C&C) Description
0x00NoneDo nothing.
0x7C0x79Load the plug-in (as shellcode) sent by the C&C server.
0x820x83Collect information about running processes (owner SID, account name, process name, domain information).
0x8E0x8FWrite the received data to the file located at %AllUsersProfile%\UTXP\nat\<filename>, where filename is a hash of the value returned by VirtualAlloc at each execution of the malware.
0x64NoneCall one of the plug-ins received from the C&C server. Each command calls them differently using different arguments. In addition, the command 0x74 terminates all the threads.
0x74None
0x780x79 or 0x7B
0x7ENone
0x800x81
defaultNone

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

CategoryFeatureSimilaritiesScarcity
ArchitectureThreading modelMultiple threads are used, each thread being responsible for specific actions:
   · Making requests
   · Handling responses and processing commands
Low
Programming styleA main data structure is used to store all the backdoor configuration, strings and imports and passed as an argument to all the functions that need it.High
Module handlingInstalls, uninstalls, and executes modules in a similar manner to CROSSWALK.High
FunctionalityGathered information   · IP configuration
   · OS version
   · Username
   · Computer name
   · Filenames
   · Current process ID
   · Current time
Low
NetworkingSimilar proxy handlingMedium
Anti-tamperingCustom hash of the shellcode is computed and checked against a 32-bit reference value.High
ConfigurationInternal data handling   · Similar 16-byte XOR key decryption
   · Similar IAT resolution (similar hash/address pair structure)
   · Similar data processing order
High
Data layoutSimilar data structure layout with:
   · Encrypted string pool
   · IAT
   · Encrypted C&C configuration
High

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.

SHA-1DescriptionESET detection name
1077A3DC0D9CCFBB73BD9F2E6B72BC67ADDCF2ABInstallUtil-based .NET loader used to decrypt and load SideWalkMSIL/ShellcodeRunner.L.gen
153B8E46458BD65A68A89D258997E314FEF72181ChaCha20-based shellcode loader used to decrypt and load the SideWalk shellcodeWin64/Agent.AQD
829AADBDE42DF14CE8ED06AC02AD697A6C9798FESideWalk ChaCha20-encrypted shellcodeN/A
9762BC1C4CB04FE8EAEEF50A4378A8D188D85360SideWalk decrypted shellcodeWin64/Agent.AQD
EA44E9FBDBE5906A7FC469A988D83587E8E4B20DInstallUtil-based .NET loader used to decrypt and load Cobalt StrikeMSIL/ShellcodeRunner.O
AA5B5F24BDFB049EF51BBB6246CB56CEC89752BFCobalt Strike encrypted shellcodeN/A

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

Serial number8E812FCAD3B3855DFD78980CEE0BEB71
FingerprintD54AEB62D0102D0CC4B96CA9E5EAADE3846EC470
Subject CNCloudFlare Origin Certificate
Subject OCloudFlare, Inc.
Subject LSan Francisco
Subject SCalifornia
Subject CUS
Valid from2020-11-04 09:35:00
Valid to2035-11-01 09:35:00
X509v3 Subject Alternative NameDNS:*.facebookint.com
DNS:facebookint.com

Techniques MITRE ATT&CK

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

TacticIDNameDescription
Resource DevelopmentT1583.001Acquire Infrastructure: DomainsSparklingGoblin uses its own domains.
T1583.004Acquire Infrastructure: ServerSparklingGoblin uses servers hosted by various providers for its C&C servers.
T1583.006Acquire Infrastructure: Web ServicesSparklingGoblin uses Cloudflare worker services as C&C servers.
T1587.001Develop Capabilities: MalwareSparklingGoblin uses its own malware arsenal.
T1587.003Develop Capabilities: Digital CertificatesSparkling uses self-signed SSL certificates.
ExecutionT1053.005Scheduled Task/Job: Scheduled TaskSparklingGoblin’s .NET shellcode loaders are executed by a scheduled task.
PersistenceT1574.001Hijack Execution Flow: DLL Search Order HijackingSome SparklingGoblin shellcode loaders persist by being installed at locations used for DLL search order hijacking.
T1053.005Scheduled Task/Job: Scheduled TaskSparklingGoblin’s .NET shellcode loaders persist as scheduled tasks.
Privilege EscalationT1134.001Access Token Manipulation: Token Impersonation/TheftSideWalk uses token impersonation before performing HTTP requests.
Defense EvasionT1140Deobfuscate/Decode Files or InformationMost shellcode used by SparklingGoblin is stored encrypted on disk.
T1055.012Process Injection: Process HollowingSome SparklingGoblin loaders use process hollowing to execute their shellcode.
T1218.004Signed Binary Proxy Execution: InstallUtilSparklingGoblin’s .NET loaders are executed by InstallUtil.
DiscoveryT1012Query RegistrySideWalk queries the registry to get the proxy configuration.
T1082System Information DiscoverySideWalk and CROSSWALK collect various information about the compromised system.
T1016System Network Configuration DiscoverySideWalk and CROSSWALK retrieve the local proxy configuration.
Command And ControlT1071.001Application Layer Protocol: Web ProtocolsSideWalk and CROSSWALK use HTTPS to communicate with C&C servers.
T1573.001Encrypted Channel: Symmetric CryptographySideWalk uses a modified ChaCha20 implementation to communicate with C&C servers.
T1008Fallback ChannelsSideWalk uses a fallback IP address encrypted in a Google Docs document used as dead-drop resolver.
T1090ProxySideWalk and CROSSWALK can communicate properly when a proxy is used on the victim’s network.
T1102Web ServiceSideWalk uses Cloudflare workers web services.
T1102.001Web Service: Dead Drop ResolverSideWalk uses a Google Docs document as dead-drop resolver.

Infolettre

Discussion