Stealth Faulcon survole le ciel du Moyen-Orient avec Deadglyph

Depuis des années, le Moyen-Orient a la réputation d'être un terrain fertile pour les menaces persistantes avancées (APT). Dans le cadre d'une surveillance de routine des activités suspectes sur les systèmes de clients importants, dont certains sont basés dans cette région, ESET Research est tombé sur une porte dérobée inconnue et très sophistiquée que nous avons baptisée Deadglyph. Nous avonstiré ce nom des artefacts trouvés dans la porte dérobée (tels que0xDEADB001, illustré également dans letableau 1 ), associés à la présence d'une attaque parhomoglyphes. À notre connaissance, il s'agit de la première analyse publique de cette porte dérobée non documentée, utilisée par un groupe qui fait preuve d'un degré notable de sophistication et d'expertise. Sur la base du ciblage et de preuves supplémentaires, nous attribuons Deadglyph, avec un degré de confiance élevé, au groupe APT Stealth Falcon.

L'architecture de Deadglyph est inhabituelle car elle est constituée de composants coopératifs - l'un est un binaire x64 natif, l'autre un assemblage .NET. Cette combinaison est inhabituelle car les logiciels malveillants n'utilisent généralement qu'un seul langage de programmation pour leurs composants. Cette différence pourrait indiquer que ces deux composants ont été développés séparément tout en tirant parti des caractéristiques uniques des différents langages de programmation qu'ils utilisent. Des langages différents peuvent également être utilisés pour entraver l'analyse, car un code mixte est plus difficile à parcourir et à déboguer.

Les commandes traditionnelles de la porte dérobée ne sont pas mises en œuvre dans le binaire de la porte dérobée ; au lieu de cela, elles sont reçues dynamiquement du serveur de commande et de contrôle (C&C) sous la forme de modules supplémentaires. Cette porte dérobée dispose également d'un certain nombre de capacités permettant d'éviter d'être détecté.

Dans ce billet de blog, nous examinons Deadglyph de plus près et fournissons une analyse technique de cette porte dérobée, de son objectif et de certains des composants supplémentaires que nous avons obtenus. Nous présenterons également nos conclusions sur Deadglyph lors de la conférence LABScon 2023.

Points clés de l'article de blog :

• ESET Research a découvert une porte dérobée sophistiquée à l'architecture inhabituelle que nous avons baptisée Deadglyph.
• Les principaux composants sont chiffrés à l'aide d'une clé spécifique à la machine.
• Les commandes traditionnelles de la porte dérobée sont mises en œuvre via des modules supplémentaires reçus de son serveur C&C.
• Nous avons obtenu trois des nombreux modules - créateur de processus, lecteur de fichiers et collecteur d'informations.
• Nous attribuons Deadglyph au groupe Stealth Falcon.
• En outre, nous avons trouvé un téléchargeur de shellcode connexe ; nous supposons qu'il pourrait potentiellement être utilisé pour l'installation de Deadglyph.

La victime de l'infiltration analysée est une entité gouvernementale du Moyen-Orient qui a été compromise à des fins d'espionnage. Un échantillon connexe trouvé sur VirusTotal a également été téléchargé sur la plateforme d'analyse de fichiers à partir de cette région, plus précisément du Qatar. Larégion ciblée est représentée sur la carte de Figure 1 .

Stealth Falcon (également connu sous le nom de Project Raven ou FruityArmor) est un groupe de menace lié aux Émirats arabes unis selon MITRE. Actif depuis 2012, Stealth Falcon est connu pour cibler les activistes politiques, les journalistes et les dissidents au Moyen-Orient. Il a été découvert et décrit pour la première fois par Citizen Lab, qui a publié une analyse d'une campagne d'attaques de logiciels espions en 2016.

En janvier 2019, Reuters a publié un rapport d'enquête sur le projet Raven, une initiative qui emploierait d'anciens agents de la NSA et viserait les mêmes types de cibles que Stealth Falcon. Surla base de ces deux rapports faisant référence aux mêmes cibles et aux mêmes attaques, Amnesty International a conclu (voir Figure 2 ) que Stealth Falcon et Project Raven sont en fait le même groupe.

ven

En septembre 2019, nous avons publié des recherches sur une porte dérobée, attribuée à Stealth Falcon, qui utilisait une technique inhabituelle, Background Intelligent Transfer Service, pour la communication C&C. Nous révélons maintenant le résultat de notre analyse approfondie de ce qui est vraisemblablement le dernier ajout à la panoplie d'outils d'espionnage de Stealth Falcon.

Porte dérobée Deadglyph

La chaîne de chargement de Deadglyph se compose de plusieurs éléments, comme l'illustre Figure 3 . Le composant initial est un chargeur de shellcode de registre, qui charge le shellcode à partir du registre. Ce shellcode extrait charge à son tour la partie x64 native de la porte dérobée - l'Executor. L'Executor charge ensuite la partie .NET de la porte dérobée - l'Orchestrator. Notamment, le seul composant présent sur le disque du système sous la forme d'un fichier est le composant initial, qui se présente sous la forme d'une bibliothèque de liens dynamiques (DLL). Les autres composants sont cryptés et stockés dans une valeur de registre binaire.

Bien que la méthode précise du vecteur de compromission initial ne soit pas encore déterminée, nous pensons qu'un composant d'installation est impliqué dans le déploiement d'autres composants et dans l'établissement de la persistance au sein du système.

Dans la suite de cette section, nous analysons chaque composant.

Chargeur de shellcode pour le registre

Le composantinitial de Deadglyph est une minuscule DLL avec une seule exportation, nommée 1. Ce composant est persisté à l'aide de l'abonnement aux événements WMI (Windows Management Instrumentation ) et sert de chargeur de shellcode de registre . Il est exécuté via la ligne de commande rundll32 C:\NWINDOWS\NSystem32\Npbrtl.dll,#1.

Le chargeur de shellcode de registre commence par décrypter le chemin d'accès au shellcode crypté stocké dans le registre Windows, à l'aide de RC4. Nous soupçonnons que le chemin est unique pour chaque victime ; dans le cas analysé ici, le chemin du registre était le suivant :

Software\Classes\CLSID\{5abc7f42-1112-5099-b082-ce8d65ba0c47}\cAbRGHLg

Laclé de registre racine est HKLM ou HKCU, selon que le processus en cours s'exécute ou non avec des privilèges élevés. La même logique se retrouve dans d'autres composants.

Ensuite, le chargeur dérive une clé RC4 spécifique à la machine en utilisant l'UUID du système récupéré à partir de la table brute du firmware SMBIOS. À l'aide de cette clé, il charge, décrypte et exécute le shellcode. Il est important de souligner que cette approche de dérivation de clé garantit qu'un décryptage correct ne se produira pas si le chargeur est exécuté sur un autre ordinateur.

Il est intéressant de noter que le chargeur peut également être configuré par un drapeau dans sa section.data pour utiliser une clé codée en dur pour décrypter le shellcode, au lieu d'une clé spécifique à la machine.

Nous avons repéré une attaque par homoglyphes imitant Microsoft Corporation dans la ressource VERSIONINFO de ce composant PE et d'autres. Cette méthode utilise des caractères Unicode distincts qui semblent visuellement similaires, mais dans ce cas pas identiques, aux caractères originaux, en particulier la lettre grecque majuscule San (U+03FA, Ϻ) et la lettre cyrillique minuscule O (U+043E, о) dans ϺicrоsоftCorpоratiоn.

Le shellcode du registre

Composé de deux parties, le shellcode du registre se compose d'une routine de décryptage et d'un corps crypté. Toutd'abord, la routine de décryptage fait pivoter chaque octet du corps crypté d'une unité vers la gauche (ROL 0x01). Ensuite, le contrôle est transféré à ce corps décrypté. Le corps déchiffré se compose d'un chargeur PE et d'un fichier PE, ce dernier étant l'exécuteur, qui représente la partie native de la porte dérobée. Ce chargeur est chargé d'analyser et de charger le fichier PE associé.

Exécutant

L'exécuteur est la partie native x64 de la porte dérobée Deadglyph :

• charge sa configuration,
• initialiser le moteur d'exécution .NET,
• charge la partie .NET intégrée de la porte dérobée (l'Orchestrator) et
• agit comme une bibliothèque pour l'Orchestrator.

Tout d'abord, deux configurations par défaut intégrées dans la section.data sont décryptées par AES. Les configurations englobent divers paramètres, notamment les clés de chiffrement, les paramètres de sécurité et d'évasion, ainsi que le point d'entrée du composant suivant.

Lors de l'exécution initiale, ces deux configurations par défaut sont stockées dans le registre Windows, d'où elles sont chargées lors des exécutions suivantes, ce qui permet la mise en œuvre des mises à jour. Le chemin d'accès au registre pour chaque configuration est généré avec le format suivant :

{HKCU|HKLM}\Software\Classes\CLSID\{<variable_GUID>}\(Défaut)

<variable_GUID> est un GUID généré, qui est unique pour chaque victime.

Ensuite, le runtime .NET est initialisé, puis l'Executor déchiffre en RC4 la partie .NET de la porte dérobée connue sous le nom d'Orchestrator. L'Orchestrator setrouve dans la section.rsrc de l'Executor. La configuration spécifie la méthode d'exécution de l'Orchestrator comme point d'entrée. En outre, une structure distincte est fournie pour faciliter l'accès aux fonctions de l'Executor par l'Orchestrator.

Après le lancement de l'Orchestrator, l'Executor agit comme une bibliothèque de support pour l'Orchestrator. L'Executor contient de nombreuses fonctions intéressantes ; nous en décrivons quelques-unes dans la section suivante, dans le contexte de leur utilisation par l'Orchestrator et d'autres modules chargés.

L'orchestrateur

Écrit en .NET, l'Orchestrator est le composant principal de la porte dérobée Deadglyph. Le rôle principal de ce composant consiste à établir une communication avec le serveur C&C et à exécuter des commandes, souvent facilitées par le rôle intermédiaire de l'Executor. Contrairement aux composants précédents, l'Orchestrator est obscurci par l'utilisation de .NET Reactor. En interne, la porte dérobée est appeléeagent, ce qui est un nom commun pour la partie client dans divers cadres de post-exploitation.

Initialisation

L'orchestrateur charge d'abord sa configuration et deux modules intégrés, chacun accompagné de son propre ensemble de configurations, à partir de ressources. Ces ressources sont compressées par Deflate et chiffrées par AES. Elles sont référencées par un ID qui est haché SHA-1 dans un nom de ressource. Unevue d'ensemble de ces ressources est fournie dans le tableau 1 .

Tableau 1. Ressources de l'Orchestrator

La configuration de l'orchestrateur et des modules intégrés est stockée au format XML. Un exemple de configuration de l'Orchestrator est présenté à l'adresseFigure 4 .

l'orchestrateur

Ladescription des entrées de configuration de l'orchestrateur est présentée dans le tableau 2 .

Tableau 2. Entrées de configuration de l'Orchestrator

Une fois les composants de ressources chargés, plusieurs threads sont créés pour exécuter des tâches distinctes. L'un de ces threads est chargé de vérifier l'environnement, une fonction mise en œuvre au sein de l'Executor. Un autre thread est consacré à l'établissement d'une communication périodique avec le serveur C&C, ce qui permet de récupérer les commandes. Enfin, un ensemble de trois threads est utilisé pour exécuter les commandes reçues et transmettre ensuite tout résultat généré au serveur C&C.

Le thread de contrôle de l'environnement surveille les processus en cours d'exécution afin d'identifier ceux qui sont indésirables. Ce thread fonctionne avec deux listes distinctes de noms de processus. Si un processus de la première liste est détecté, la communication C&C et l'exécution des commandes sont interrompues jusqu'à ce que le processus indésirable n'existe plus. Si un processus de la deuxième liste correspond, la porte dérobée quitte immédiatement le système et se désinstalle.

Aucune des deux listes n'était configurée dans l'instance analysée, de sorte que nous ne savons pas quels processus pourraient être vérifiés ; nous pensons qu'il s'agit probablement d'un moyen d'échapper aux outils d'analyse qui pourraient détecter une activité suspecte et conduire à la découverte de la porte dérobée.

Communication

L'Orchestrator utilise deux modules intégrés pour la communication C&C : Timer et Network. Comme l'Orchestrator, ces modules sont obscurcis par .NET Reactor. La configuration des deux modules est fournie par l'orchestrateur. Dans l'Orchestrator, une configuration prédéfinie pour les modules est incluse ; en option, l'Orchestrator peut également charger une version de configuration mise à jour à partir du registre :

{HKCU|HKLM}\Software\Classes\CLSID\{<variable_GUID>}\<mod_cfg_res_ID>

La porte dérobée contient une mesure de sécurité intéressante liée à la communication. Si la porte dérobée ne parvient pas à établir une communication avec le serveur C&C pendant une durée supérieure à un seuil prédéfini, configuré dans l'exécuteur, un mécanisme d'autodésinstallation est déclenché. Ce seuil est spécifié en heures et a été fixé à une heure dans le cas examiné.

Cette approche a un double objectif. D'une part, elle empêche la génération de requêtes réseau redondantes vers un serveur inaccessible. D'autre part, elle réduit les risques de détection ultérieure si les opérateurs perdent le contrôle de la porte dérobée.

Module de temporisation

Ce petit module exécute le callback spécifié à un intervalle configurable. Il est utilisé par l'orchestrateur en combinaison avec le module Network pour communiquer avec le serveur C&C de manière périodique. Pour éviter la création de modèles détectables dans les journaux du réseau, l'intervalle d'exécution est soumis à une randomisation, sur la base d'un pourcentage spécifié dans la configuration. Dans l'exemple analysé, l'intervalle a été fixé à cinq minutes, avec une variation de ±20 % introduite pour le caractère aléatoire.

La génération de requêtes envoyées au serveur C&C est une autre méthode permettant d'éviter les schémas de réseau détectables dans les communications périodiques. Ce mécanisme, mis en œuvre dans l'Executor, implique l'inclusion d'un rembourrage de longueur variable, composé d'octets aléatoires, dans les requêtes, ce qui permet d'obtenir des requêtes de tailles diverses.

Module réseau

Le module Réseau met en œuvre la communication avec les serveurs C&C spécifiés dans sa configuration. Il peut envoyer des données à un serveur C&C à l'aide de requêtes HTTP(S) POST. Il offre notamment plusieurs mécanismes permettant d'obtenir des informations sur la configuration du proxy. Cette caractéristique suggère qu'il pourrait se concentrer sur les environnements où l'accès direct à l'internet n'est pas disponible.

Unexemple de configuration décryptée (et embellie) est présenté à l'adresseFigure 5 .

Les entrées de configuration contiennent des détails relatifs aux communications réseau - URL C&C, HTTP User-Agent, et éventuellement une configuration proxy.

Lors de la communication avec le serveur C&C, un protocole binaire personnalisé avec un contenu crypté est utilisé sous HTTPS.

Commandes

L'orchestrateur reçoit des commandes du serveur C&C sous la forme de tâches, qui sont mises en attente d'exécution. Il existe trois types de tâches traitées :

• Les tâches de l'orchestrateur
• Les tâches de l'exécuteur et
• Tâches de téléchargement.

Les deux premiers types sont reçus du serveur C&C et le troisième est créé en interne pour télécharger les résultats des commandes et les erreurs.

Tâches de l'orchestrateur

Les tâches de l'orchestrateur permettent de gérer la configuration des modules Réseau et Minuterie, ainsi que d'annuler les tâches en attente. Lavue d'ensemble des tâches de l'orchestrateur est présentée dans le tableau 3 .

Tableau 3. Tâches de l'Orchestrateur

Tâches de l'exécuteur

Les tâches d'exécution permettent de gérer la porte dérobée et d'exécuter des modules supplémentaires. Il est à noter que la fonctionnalité traditionnelle de la porte dérobée n'est pas intrinsèquement présente dans le binaire lui-même. Ces fonctions sont obtenues auprès du serveur C&C sous la forme de fichiers PE ou de shellcode. L'étendue du potentiel de la porte dérobée reste inconnue sans ces modules supplémentaires, qui débloquent effectivement ses véritables capacités. Unevue d'ensemble des tâches des modules est présentée dans le tableau 4 , qui contient des détails sur les quelques modules identifiés. De même, le tableau 5 donne un aperçu des tâches de gestion associées à l'Executor.

Tableau 4. Tâches de l'exécuteur - modules

Tableau 5. Tâches de l'exécuteur - gestion

La commande qui définit la configuration de l'Executor peut modifier les listes de processus :

• les listes de processus indésirables,
• le seuil de temps d'échec de la communication C&C, et
• le délai d'exécution des modules supplémentaires.

Modules

Nous avonsréussi à obtenir trois modules uniques du serveur C&C, chacun correspondant à un type de tâche différent de l'Executor, comme le montre le tableau 4 . Sur la base des informations disponibles, nous estimons qu'il y a entre neuf et quatorze modules au total. Comme les modules sont en fait des commandes de porte dérobée, ils ont une opération de base à exécuter et renvoient éventuellement leur résultat. Les modules que nous avons obtenus sont des DLL avec une exportation sans nom (ordinale 1), dans laquelle ils résolvent les fonctions API nécessaires et appellent la fonction principale.

Lorsqu'ils sont exécutés, les modules sont dotés d'une fonction de résolution d'API, qui peut résoudre les API de Windows et les API personnalisées de l'exécuteur. Les API Windows sont référencées par un hachage DWORD, calculé à partir du nom de l'API et de sa DLL. Les petites valeurs de hachage (<41) font l'objet d'un traitement spécial et renvoient à la fonction API de l'exécuteur. L'API de l'exécuteur comprend un total de 39 fonctions accessibles aux modules. Ces fonctions se rapportent à une variété d'opérations, y compris :

• les opérations sur les fichiers,
• le cryptage et le hachage,
• la compression,
• Le chargement de PE,
• l'usurpation d'identité par jeton d'accès, et
• utilitaire.

Dans le reste de cette section, nous décrivons les modules que nous avons obtenus.

Créateur de processus

Lemodule 0x69 exécute la ligne de commande spécifiée en tant que nouveau processus et renvoie le résultat à l'orchestrateur. Le processus peut être créé sous un autre utilisateur et son temps d'exécution peut être limité. Il convient de noter qu'une API Job inhabituelle est utilisée dans la fonctionnalité de ce module.

Ce module a été exécuté avec la ligne de commande cmd.exe /c tasklist /v.

Nous supposons qu'il s'agit d'une commande inactive émise automatiquement, pendant que les opérateurs attendent que quelque chose d'intéressant se produise sur l'ordinateur compromis.

Collecteur d'informations

Lemodule 0x6C collecte de nombreuses informations sur l'ordinateur via des requêtes WMI et les transmet à l'orchestrateur. Les informations suivantes sont collectées

• le système d'exploitation,
• adaptateurs réseau,
• logiciels installés,
• lecteurs,
• services,
• pilotes,
• processus,
• utilisateurs,
• les variables d'environnement et
• logiciels de sécurité.

Lecteur de fichiers

Lemodule 0x64 lit le fichier spécifié et transmet son contenu à l'orchestrateur. En option, il peut supprimer le fichier après la lecture.

Nous avons vu ce module utilisé pour récupérer le fichier de données Outlook de la victime

c:\NUsers<<redacted>\AppData\NLocal\NMicrosoft\NOutlook\Noutlook.ost.

Chaîne avec téléchargeur de shellcode

Au cours de notre enquête sur Deadglyph, nous avons rencontré un fichier CPL douteux signé avec un certificat expiré et sans contre-signature avec un horodatage, qui avait été téléchargé sur VirusTotal depuis le Qatar. Après un examen plus approfondi, il est devenu évident que ce fichier CPL fonctionnait comme un téléchargeur de shellcode en plusieurs étapes, partageant certaines similitudes de code avec Deadglyph. La chaîne de chargement est illustrée dans Figure 6 .

Dans sa forme initiale, qui sert de première étape, ce fichier prévoit une extension.cpl (fichier du panneau de configuration) et est destiné à être exécuté par un double-clic. Lorsqu'il est exécuté de cette manière, le shellcode intégré subit un décryptage XOR et les processus en cours d'exécution sont vérifiés afin d'identifier un processus hôte approprié pour une injection ultérieure.

Si avp.exe (un processus de Kaspersky endpoint security) est en cours d'exécution, %windir%\system32\UserAccountBroker.exe est utilisé. Sinon, le navigateur par défaut est utilisé. Ensuite, il crée le processus hôte dans un état suspendu, injecte le shellcode en détournant son fil principal, et reprend le fil.

La deuxième étape, le shellcode, se compose de deux parties. La première partie du shellcode résout les hachages de l'API, en utilisant la même technique de calcul de hachage unique que celle employée dans Deadglyph, et décrypte les chaînes de caractères contenant les noms de processus. Elle lance un thread d'autodestruction chargé d'écraser puis d'effacer le fichier de la première étape. Ensuite, le shellcode procède à l'inspection des processus actuellement actifs, en ciblant une solution de sécurité.

Si l'un des processus spécifiés est détecté, le shellcode crée un thread de sommeil avec la priorité la plus basse (THREAD_PRIORITY_IDLE) et lui permet de rester actif pendant 60 secondes avant de mettre fin à son opération. Cet intervalle est probablement mis en œuvre comme mesure de précaution pour échapper à certains mécanismes de détection utilisés par les solutions de sécurité. Enfin, le shellcode procède à l'exécution de la deuxième partie de son code.

La deuxième partie du shellcode charge un fichier PE intégré avec l'étape trois et appelle son exportation avec le numéro ordinal 1.

Latroisième étape, une DLL, sert de chargeur .NET et contient la charge utile dans sa section.rsrc.

Pour charger la charge utile, le moteur d'exécution .NET est initialisé. Au cours de l'initialisation .NET, deux techniques intrigantes sont mises en œuvre, apparemment dans le but d'échapper à l'analyse de l'interface AMSI (Antimalware Scan Interface) de Windows:

• Le chargeur .NET accroche temporairement l' importation GetModuleHandleW dans le fichierclr.dll chargé , tout en appelant ICorRuntimeHost::Start. Le crochet modifie la valeur de retour lorsque GetModuleHandleW est appelé avec NULL. Il renvoie un pointeur vers un PE factice sans section.
• Il corrige ensuite subtilement la chaîne de nom d'importation AmsiInitialize dans la section .rdata du fichierclr.dll chargé en amsiinitialize.

La quatrième étape est une assemblée .NET, obscurcie avec ConfuserEx, qui sert de téléchargeur de shellcode. Tout d'abord, il décrypte sa configuration au format XML à partir de ses ressources. Une version embellie de la configuration extraite est présentée dans Figure 7 . Les entrées de configuration contiennent des détails relatifs à la communication réseau et aux processus figurant sur la liste de blocage.

Avant de procéder, il vérifie les processus en cours d'exécution par rapport à une liste de processus bloqués provenant de la configuration. Si une correspondance est détectée, l'exécution s'arrête. Il est important de noter que dans l'exemple analysé, cette liste de blocage n'a pas été établie.

Ensuite, il envoie une requête HTTP GET au serveur C&C pour récupérer un shellcode, en utilisant les paramètres spécifiés dans la configuration (URL, User-Agent, et éventuellement Proxy). Malheureusement, au cours de notre enquête, nous n'avons pas pu obtenir de shellcode du serveur C&C. Nous avons néanmoins émis l'hypothèse qu'il s'agissait d'un code de sécurité. Néanmoins, nous émettons l'hypothèse que le contenu récupéré pourrait potentiellement servir d'installateur pour Deadglyph.

Ensuite, le shellcode récupéré est exécuté dans un thread nouvellement créé. Après avoir attendu la fin de l'exécution du thread du shellcode, le téléchargeur de shellcode supprime tous les fichiers situés dans le répertoire %WINDIR%\ServiceProfiles\LocalService\AppData\Local\Temp\TfsStore\Tfs_DAV.

Enfin, il tente de se supprimer lui-même après un intervalle de 20 secondes, en utilisant la commande suivante, avant de terminer son opération et de se déconnecter :

cmd.exe choice /C Y /N /D Y /T 20 & Del /f /q <current_process_exe_path>

Cette autodestruction n'a pas de sens dans cette chaîne. En effet, le téléchargeur de shellcode est exécuté au sein d'un navigateur ou d'un processus système après avoir été injecté, au lieu de fonctionner comme un exécutable indépendant. En outre, le fichier initial a déjà été supprimé lors de la deuxième étape. Cette observation suggère que le téléchargeur de shellcode pourrait ne pas être une charge utile exclusive de cette chaîne et qu'il pourrait également être utilisé séparément dans d'autres opérations.

Conclusion

Nous avons découvert et analysé une porte dérobée sophistiquée utilisée par le groupe Stealth Falcon que nous avons baptisée Deadglyph. Il possède une architecture inhabituelle et ses capacités de porte dérobée sont fournies par son C&C sous la forme de modules supplémentaires. Nous avons réussi à obtenir trois de ces modules, ce qui nous a permis de découvrir une fraction des capacités de Deadglyph.

Deadglyph se targue notamment d'une série de mécanismes de contre-détection, dont la surveillance continue des processus système et la mise en œuvre de modèles de réseau aléatoires. En outre, la porte dérobée est capable de se désinstaller pour minimiser la probabilité de sa détection dans certains cas.

En outre, notre enquête nous a permis de découvrir sur VirusTotal une chaîne de téléchargement de shellcodes en plusieurs étapes très convaincante. Nous pensons que cette chaîne de téléchargement est probablement utilisée dans le processus d'installation de Deadglyph.

Pour toute question concernant nos recherches publiées sur WeLiveSecurity, veuillez nous contacter à l'adresse threatintel@eset.com.
ESET Research propose des rapports privés de renseignements sur les APT et des flux de données. Pour toute question concernant ce service, visitez la page ESET Threat Intelligence.

IoCs

Fichiers

Certificats

Serveurs C&C

Techniques MITRE ATT&CK

Ce tableau a été construit en utilisant la version 13 du cadre ATT&CK de MITRE.