Stealth Falcon s'attaque au ciel du Moyen-Orient avec Deadglyph

Depuis des années, le Moyen-Orient entretient sa réputation de terrain fertile pour les menaces avancées persistantes (APT). Au milieu d'une surveillance régulière des activités suspectes sur les systèmes de clients de premier plan, dont certains sont basés dans cette région, ESET Research est tombé sur une porte dérobée très sophistiquée et inconnue que nous avons baptisée Deadglyph. Nous avons dérivé le nom d'artefacts trouvés dans la porte dérobée (tels que 0xDEADB001, montré également dans REF _Ref111452440h lampe de table 1
), couplé à la présence d'un homoglyphe attaque. À notre connaissance, il s’agit de la première analyse publique de cette porte dérobée jusqu’alors non documentée, utilisée par un groupe faisant preuve d’un degré notable de sophistication et d’expertise. Sur la base du ciblage et des preuves supplémentaires, nous attribuons Deadglyph avec une grande confiance au groupe Stealth Falcon APT.

L'architecture de Deadglyph est inhabituelle car elle se compose de composants coopérants : 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 un développement séparé de ces deux composants tout en tirant également parti des fonctionnalités uniques des langages de programmation distincts qu'ils utilisent. Différents langages peuvent également être exploités pour gêner l’analyse, car le code mixte est plus difficile à parcourir et à déboguer.

Les commandes traditionnelles de porte dérobée ne sont pas implémentées dans le binaire de porte dérobée ; au lieu de cela, ils sont reçus dynamiquement par le serveur de commande et de contrôle (C&C) sous la forme de modules supplémentaires. Cette porte dérobée présente également un certain nombre de fonctionnalités pour éviter d'être détectée.

Dans cet article de blog, nous examinons de plus près Deadglyph et fournissons une analyse technique de cette porte dérobée, son objectif et certains des composants supplémentaires que nous avons obtenus. Nous présentons également nos découvertes sur Deadglyph au LABScon 2023 conférence.

Points clés du 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 cryptés à l'aide d'une clé spécifique à la machine.
• Les commandes de porte dérobée traditionnelles sont implémentées via des modules supplémentaires reçus de son serveur C&C.
• Nous avons obtenu trois modules parmi tant d'autres : créateur de processus, lecteur de fichiers et collecteur d'informations.
• Nous attribuons Deadglyph au groupe Stealth Falcon.
• De plus, nous avons trouvé un téléchargeur de shellcode associé ; nous postulons 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 de cette région, en particulier du Qatar. La région ciblée est représentée sur la carte en REF _Ref143614671h Figure 1
.

Stealth Falcon (également connu sous le nom de Project Raven ou FruityArmor) est un groupe menaçant lié aux Émirats arabes unis. selon MITRE. Actif depuis 2012, Stealth Falcon est connu pour cibler les militants politiques, les journalistes et les dissidents au Moyen-Orient. Il a été découvert et décrit pour la première fois par Lab Citizen, qui a publié un selon une analyse de l’Université de Princeton 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 prétendument d'anciens agents de la NSA et viserait les mêmes types de cibles que Stealth Falcon. Sur la base de ces deux rapports faisant état des mêmes cibles et attaques, Amnesty International a conclu (montré dans REF _Ref144978712h Figure 2
) que Stealth Falcon et Project Raven sont en réalité le même groupe.

En septembre 2019, nous recherche publiée 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 à l'ensemble d'outils d'espionnage de Stealth Falcon.

Porte dérobée des glyphes morts

La chaîne de chargement de Deadglyph se compose de plusieurs composants, comme illustré dans REF _Ref144978760h Figure 3
. Le composant initial est un chargeur de shellcode de registre, qui charge le shellcode à partir du registre. Ce shellcode extrait, à son tour, charge 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 sur le disque du système sous forme de fichier est le composant initial, qui se présente sous la forme d'une bibliothèque de liens dynamiques (DLL). Les composants restants sont chiffré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 soupçonnons qu'un composant d'installation est impliqué dans le déploiement d'autres composants et l'établissement de la persistance au sein du système.

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

Chargeur de shellcode de registre

Le composant initial de Deadglyph est une petite DLL avec une seule exportation, nommée 1. Ce composant est conservé en utilisant Abonnement aux événements Windows Management Instrumentation (WMI) et sert de chargeur de shellcode de registre. Il est exécuté via la ligne de commande rundll32 C:WINDOWSSystem32pbrtl.dll,#1.

Le chargeur de shellcode du registre commence son fonctionnement en déchiffrant le chemin d'accès au shellcode crypté stocké dans le registre Windows, à l'aide de RC4. Nous pensons que le cheminement est unique pour chaque victime ; dans le cas analysé ici, le chemin du registre était :

SoftwareClassesCLSID{5abc7f42-1112-5099-b082-ce8d65ba0c47}cAbRGHLg

La clé de registre racine est soit HKLM or HKCU, selon que le processus actuel s'exécute avec des privilèges élevés ou non. La même logique peut être trouvée dans d’autres composants.

Ensuite, le chargeur dérive une clé RC4 spécifique à la machine en utilisant l'UUID système récupéré du table brute du micrologiciel SMBIOS. À l’aide de cette clé, il charge, déchiffre puis exécute le shellcode. Il est important de souligner que cette approche de dérivation de clé garantit qu'un déchiffrement 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 indicateur dans son .Les données pour utiliser une clé codée en dur pour déchiffrer le shellcode, au lieu de celle spécifique à la machine.

Nous avons repéré une attaque homoglyphe imitant Microsoft Corporation dans le INFO VERSION ressource de ceci et d’autres composants PE. Cette méthode utilise des caractères Unicode distincts qui semblent visuellement similaires, mais dans ce cas non identiques, aux caractères originaux, en particulier la lettre majuscule grecque San (U+03FA, Ϻ) et la lettre minuscule cyrillique O (U+043E, о) dans Ϻicrоsоft Corpоroueоn.

Shellcode du registre

Composé de deux parties, le shellcode du registre se compose d'une routine de décryptage et d'un corps chiffré. Tout d’abord, la routine de décryptage fait pivoter chaque octet du corps chiffré d’un point vers la gauche (ROL 0x01). Par la suite, le contrôle est transféré à cet organisme décrypté. Le corps déchiffré est constitué d'un chargeur PE et d'un fichier PE, ce dernier étant l'Executor, qui représente la partie native de la porte dérobée. Ce chargeur est responsable de l'analyse et du chargement du fichier PE associé.

Exécuteur

L'Executor est la partie x64 native de la porte dérobée Deadglyph, qui effectue les opérations suivantes :

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

Tout d'abord, deux configurations par défaut intégrées dans le .Les données section sont déchiffré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 ultérieures, permettant la mise en œuvre des mises à jour. Le chemin de registre pour chaque configuration est généré au format suivant :

{HKCU|HKLM}SoftwareClassesCLSID{ }(Défaut)

est un GUID généré, unique à chaque victime.

Ensuite, le runtime .NET est initialisé, puis l'Executor RC4 déchiffre la partie .NET de la porte dérobée connue sous le nom d'Orchestrator. L'Orchestrateur est situé au sein du .rsrc section de l’Exécuteur. La configuration spécifie la méthode d'exécution d'Orchestrator comme point d'entrée. De plus, une structure distincte est prévue pour faciliter l'accessibilité des fonctions de l'Exécuteur par l'Orchestrateur.

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

Orchestrateur

Écrit en .NET, Orchestrator est le composant principal de la porte dérobée Deadglyph. Le rôle principal de ce composant consiste à établir la 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, Orchestrator est obscurci, utilisant .NET Reactor. En interne, la porte dérobée est appelée agent, qui est un nom commun pour la partie client dans divers frameworks de post-exploitation.

Initialisation

L'Orchestrator 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 Dégonfler compressé et AES crypté. Ils sont référencés par un identifiant haché SHA-1 dans un nom de ressource. Un aperçu de ces ressources est fourni dans REF _Ref111452440h lampe de table 1
.

Tableau 1. Ressources de l'orchestrateur

Nom de la ressource	ID (décimal)	ID (hexadécimal)	Description
43ed9a3ad74ed7ab74c345a876b6be19039d4c8c	2570286865	Assistance	Configuration de l'orchestrateur.
3a215912708eab6f56af953d748fbfc38e3bb468	3740250113	0xDEEFB001	Module réseau.
42fb165bc9cf614996027a9fcb261d65fd513527	3740250369	0xDEEFB101	Configuration des modules réseau.
e204cdcf96d9f94f9c19dbe385e635d00caaf49d	3735924737	0xDEADB001	Module minuterie.
abd2db754795272c21407efd5080c8a705a7d151	3735924993	0xDEADB101	Configuration du module minuterie.

La configuration d'Orchestrator et des modules embarqués est stockée au format XML. Un exemple de configuration Orchestrator est présenté dans REF _Ref111452611h
Figure 4
.

La description des entrées de configuration d'Orchestrator est affichée dans REF _Ref111452782h lampe de table 2
.

Tableau 2. Entrées de configuration d'Orchestrator

Une fois les composants de ressources chargés, plusieurs threads sont créés pour effectuer des tâches distinctes. L'un de ces threads est chargé d'effectuer les vérifications de l'environnement, une fonction implémentée dans l'Executor. Un autre thread est consacré à l'établissement d'une communication périodique avec le serveur C&C, permettant la récupération des commandes. Enfin, un ensemble de trois threads est utilisé dans le but d'exécuter les commandes reçues et de transmettre ensuite toute sortie générée au serveur C&C.

Le thread de vérification de l'environnement surveille les processus en cours d'exécution pour identifier ceux 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 suspendues jusqu'à ce que le processus indésirable n'existe plus. S'il y a une correspondance pour un processus de la deuxième liste, la porte dérobée se ferme immédiatement et se désinstalle.

Aucune des deux listes n'a été configurée dans l'instance analysée, nous ne savons donc pas quels processus peuvent généralement être vérifiés ; nous pensons qu'il est probablement destiné à é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 Orchestrator, ces modules sont masqués par .NET Reactor. La configuration des deux modules est fournie par Orchestrator. Dans Orchestrator, une configuration prédéfinie pour les modules est incluse ; en option, Orchestrator peut également charger une version de configuration mise à jour à partir du registre :

{HKCU|HKLM}SoftwareClassesCLSID{ }

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 la communication avec le serveur C&C pendant une durée dépassant un seuil prédéfini, configuré dans l'Executor, un mécanisme d'auto-désinstallation est déclenché. Ce seuil temporel est précisé en heures et a été fixé à une heure dans le cas examiné.

Cette approche répond à un double objectif. D'une part, cela évite la génération de requêtes réseau redondantes vers un serveur inaccessible. D’un autre côté, cela réduit les chances de détection ultérieure si les opérateurs perdent le contrôle de la porte dérobée.

Minuterie

Ce petit module exécute le rappel spécifié à un intervalle configurable. Il est utilisé par Orchestrator en combinaison avec le module Réseau pour communiquer périodiquement avec le serveur C&C. Pour empêcher la création de modèles détectables dans les journaux réseau, l'intervalle d'exécution est soumis à une randomisation, basée sur un pourcentage spécifié dans la configuration. Dans le cas analysé, l'intervalle a été fixé à cinq minutes, avec une variation de ± 20 % introduite pour tenir compte du caractère aléatoire.

Une autre méthode permettant d'éviter les modèles de réseau détectables dans les communications périodiques consiste à générer des requêtes envoyées au serveur C&C. Ce mécanisme, implémenté dans Executor, implique l'inclusion d'un remplissage de longueur variable, composé d'octets aléatoires, dans les requêtes, ce qui donne lieu à 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. Notamment, il propose plusieurs mécanismes pour acquérir les détails de configuration du proxy. Cette fonctionnalité suggère une concentration potentielle sur les environnements où l'accès direct à Internet n'est pas disponible.

Un exemple de configuration décryptée (et embellie) est présenté dans REF _Ref144978805h Figure 5
.

Les entrées de configuration contiennent des détails liés aux communications réseau : URL C&C, agent utilisateur HTTP et éventuellement une configuration de proxy.

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

Commandes

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

• Tâches d'orchestrateur,
• Tâches de l'exécuteur, et
• Téléchargez des tâches.

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

Tâches de l'orchestrateur

Les tâches Orchestrator offrent la possibilité de gérer la configuration des modules Réseau et Timer, et également d'annuler les tâches en attente. La présentation des tâches Orchestrator est présentée dans REF _Ref111101783h lampe de table 3
.

Tableau 3. Tâches de l'orchestrateur

Tâches de l'exécuteur

Les tâches de l'exécuteur offrent la possibilité de gérer la porte dérobée et d'exécuter des modules supplémentaires. Il est à noter que la fonctionnalité traditionnelle de porte dérobée n’est pas intrinsèquement présente dans le binaire lui-même. Au lieu de cela, ces fonctions sont obtenues à partir 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 libèrent efficacement ses véritables capacités. Un aperçu des tâches du module est présenté dans REF _Ref117677179h lampe de table 4
, qui comprend des détails sur les quelques modules identifiés. De la même manière, REF _Ref117677188h lampe de table 5
fournit un aperçu des tâches de gestion associées à l'exécuteur.

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

Type	Description
0x??–0x63	Inconnu
Assistance	Lecteur de fichiers
Assistance	Inconnu
Assistance	Inconnu
Assistance	Inconnu
Assistance	Inconnu
Assistance	Créateur de processus
0x6A	Inconnu
0x6B	Inconnu
0x6C	Collecteur d'informations
0x6D	Inconnu
0x6E	Inconnu

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

Type	Description
0x6F-0x76	Pas mis en œuvre
Assistance	Définir la configuration de l'exécuteur
Assistance	Obtenir la configuration de l'exécuteur
0x79-0x7C	Pas mis en œuvre
0x7D	Mises à jour
0x7E	quitter
0x7F	Désinstaller

La commande qui définit la configuration de l'Exécuteur peut modifier :

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

Modules

Nous avons réussi à obtenir trois modules uniques du serveur C&C, chacun correspondant à un type de tâche d'exécuteur différent, comme indiqué dans REF _Ref117677179h lampe de table 4 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003100310037003600370037003100370039000000
. Sur la base des informations disponibles, nous estimons qu'il y a neuf à 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 puis renvoient éventuellement leur sortie. Les modules que nous avons obtenus sont des DLL avec une exportation sans nom (ordinal 1), dans lequel ils résolvent les fonctions API nécessaires et appellent la fonction principale.

Une fois exécutés, les modules sont dotés d'une fonction de résolution d'API, qui peut résoudre les API Windows et les API Executor personnalisées. 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) sont traitées spécialement, faisant référence à la fonction API Executor. L'API Executor comprend un total de 39 fonctions accessibles aux modules. Ces fonctions concernent diverses opérations, notamment :

• opérations sur les fichiers,
• le cryptage et le hachage,
• compression,
• Chargement PE,
• accéder à l'usurpation d'identité de jeton, et
• utilitaire.

Dans la suite de cette section, nous décrivons les modules que nous avons obtenus.

Créateur de processus

Module Assistance exécute la ligne de commande spécifiée en tant que nouveau processus et renvoie la sortie résultante à Orchestrator. Le processus peut être créé sous un utilisateur différent et son temps d'exécution peut être limité. Notamment, un phénomène inhabituel API de tâches est utilisé dans les fonctionnalités de ce module.

Ce module a été servi avec la ligne de commande cmd.exe /c liste des tâches /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

Module 0x6C collecte des informations détaillées sur l’ordinateur via des requêtes WMI et les renvoie à Orchestrator. Les informations sur les éléments suivants sont collectées :

• système opérateur,
• adaptateurs réseau,
• logiciel installé,
• disques,
• prestations de service,
• les conducteurs,
• processus,
• les utilisateurs,
• variables d'environnement, et
• logiciel de sécurité.

Lecteur de fichiers

Module Assistance lit le fichier spécifié et renvoie le contenu à Orchestrator. En option, il peut supprimer le fichier après lecture.

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

c:Utilisateurs AppDataLocalMicrosoftOutlookoutlook.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 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 à plusieurs étapes, partageant certaines ressemblances de code avec Deadglyph. La chaîne de chargement est illustrée dans REF _Ref143693067h Figure 6
.

Dans sa forme initiale, qui constitue une première étape, ce dossier prévoit une . Cpl (fichier du Panneau de configuration) et est destiné à être exécuté via une action de double-clic. Lors de son exécution de cette manière, le shellcode intégré subit un déchiffrement XOR et les processus en cours d'exécution sont vérifiés pour identifier un processus hôte approprié pour une injection ultérieure.

If avp.exe (un processus de sécurité du point final Kaspersky) est en cours d'exécution, %windir%system32UserAccountBroker.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 thread principal et reprend le thread.

La deuxième étape, le shellcode, se compose de deux parties. La première partie du shellcode résout les hachages d'API, en utilisant la même technique de calcul de hachage unique utilisée dans Deadglyph, et déchiffre les chaînes avec les noms de processus. Il démarre un thread d'auto-suppression chargé d'écraser puis d'effacer le fichier de première étape. Suite à cela, 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 dormant avec la priorité la plus basse (THREAD_PRIORITY_IDLE) et lui permet de rester actif pendant une durée de 60 secondes avant de mettre fin à son fonctionnement. Cet intervalle est probablement mis en œuvre à titre de 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’invocation 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 la troisième étape et appelle son exportation avec un numéro ordinal 1.

La troisième étape, une DLL, sert de chargeur .NET et contient la charge utile dans son .rsrc .

Pour charger la charge utile, le runtime .NET est initialisé. Lors de l'initialisation de .NET, deux techniques intrigantes sont utilisées, apparemment destinées à échapper à Windows Analyse de l'interface d'analyse antimalware (AMSI):

• Le chargeur .NET accroche temporairement le GetModuleHandleW importer dans le fichier chargé clr.dll, en appelant ICorRuntimeHost ::Démarrer. Le hook altère la valeur de retour lorsque GetModuleHandleW est appelé avec NULL. Il renvoie un pointeur vers un PE factice sans sections.
• Il corrige ensuite subtilement le AmsiInitialiser importer la chaîne de nom dans le .rdata section du chargé clr.dll à amsiiinitialiser.

La quatrième étape est un assembly .NET, obscurci avec ConfuserEx, qui sert de téléchargeur de shellcode. Tout d’abord, il décrypte par XOR sa configuration au format XML à partir de ses ressources. Une version embellie de la configuration extraite est présentée dans REF _Ref143695453h Figure 7
. Les entrées de configuration contiennent des détails liés à la communication réseau et aux processus sur liste noire.

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

Ensuite, il envoie une requête HTTP GET au serveur C&C pour récupérer du 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 pu acquérir aucun shellcode du serveur C&C. Néanmoins, nous émettons l’hypothèse que le contenu récupéré pourrait potentiellement servir d’installateur pour Deadglyph.

Suite à cela, 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 shellcode, le téléchargeur de shellcode supprime tous les fichiers situés dans le répertoire. %WINDIR%ServiceProfilesLocalServiceAppDataLocalTempTfsStoreTfs_DAV.

Enfin, il tente de se supprimer après un intervalle de 20 secondes, en utilisant la commande suivante, avant de terminer son opération et de quitter :

choix cmd.exe /CY /N /DY /T 20 & Del /f /q

Cette auto-suppression n'a pas de sens dans cette chaîne. Cela est dû au fait que le téléchargeur de shellcode est exécuté dans un navigateur ou un processus système après avoir été injecté, plutôt que de fonctionner comme un exécutable indépendant. De plus, 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 peut é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, révélant ainsi une fraction de toutes les capacités de Deadglyph.

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

De plus, notre enquête nous a conduit à la découverte d’une chaîne de téléchargement de shellcodes à plusieurs étapes convaincante sur VirusTotal. Nous soupçonnons que cette chaîne de téléchargement est probablement exploitée dans le processus d'installation de Deadglyph.

Pour toute question concernant nos recherches publiées sur WeLiveSecurity, veuillez nous contacter à menaceintel@eset.com.
ESET Research propose des rapports d'intelligence APT privés et des flux de données. Pour toute demande concernant ce service, rendez-vous sur Intelligence des menaces ESET .

IoCs

Fichiers

SHA-1	Nom de fichier	Détection	Description
C40F1F46D230A85F702DAA38CFA18D60481EA6C2	pbrtl.dll	Win64/Deadglyph.A	Chargeur de shellcode de registre.
740D308565E215EB9B235CC5B720142428F540DB	N/D	Win64/Deadglyph.A	Porte dérobée Deadglyph – Exécuteur.
1805568D8362A379AF09FD70D3406C6B654F189F	N/D	MSIL/Deadglyph.A	Porte dérobée Deadglyph – Orchestrateur.
9CB373B2643C2B7F93862D2682A0D2150C7AEC7E	N/D	MSIL/Deadglyph.A	Module Réseau Orchestrateur.
F47CB40F6C2B303308D9D705F8CAD707B9C39FA5	N/D	MSIL/Deadglyph.A	Module de minuterie d'orchestrateur.
3D4D9C9F2A5ACEFF9E45538F5EBE723ACAF83E32	N/D	Win64/Deadglyph.A.gen	Module créateur de processus.
3D2ACCEA98DBDF95F0543B7C1E8A055020E74960	N/D	Win64/Deadglyph.A	Module lecteur de fichiers.
4E3018E4FD27587BD1C566930AE24442769D16F0	N/D	Win64/Deadglyph.A	Module collecteur d'informations.
7F728D490ED6EA64A7644049914A7F2A0E563969	N/D	Win64/Injecteur.MD	Première étape de la chaîne de téléchargement de shellcodes.

Certificats

Numéro de série	00F0FB1390F5340CD2572451D95DB1D92D
Empreinte	DB3614DAF58D041F96A5B916281EA0DC97AA0C29
Sujet NC	RHM LIMITED
Sujet O	RHM LIMITED
Sujet L	St. Albans
Sujets	Hertfordshire
Sujet C	GB
Email	rhm@rhmlimited[.]co.uk
Valide à partir de	2021-03-16 00:00:00
Valable pour	2022-03-16 23:59:59

Serveurs C&C

IP	Domaine	Vu la première fois	Commentaires
185.25.50[.]60	chessandlinkss[.]com	2021-08-25	Serveur C&C Deadglyph.
135.125.78[.]187	easymathpath[.]avec	2021-09-11	Serveur C&C Deadglyph.
45.14.227[.]55	rejoindreushealth[.]com	2022-05-29	Serveur C&C du téléchargeur de shellcodes.

Techniques d'ATT&CK D'ONGLET

Ce tableau a été construit avec Version 13 du cadre MITRE ATT&CK.

Tactique	ID	Nom	Description
Développement des ressources	T1583.001	Acquisition d'infrastructure : domaines	Stealth Falcon a enregistré des domaines pour les serveurs C&C et pour obtenir un certificat de signature de code.
	T1583.003	Acquérir une infrastructure : serveur privé virtuel	Stealth Falcon a utilisé des fournisseurs d'hébergement VPS pour les serveurs C&C.
	T1587.001	Développer des capacités : logiciels malveillants	Stealth Falcon a développé des logiciels malveillants personnalisés, notamment des chargeurs personnalisés et la porte dérobée Deadglyph.
	T1588.003	Obtenir des capacités : certificats de signature de code	Stealth Falcon a obtenu un certificat de signature de code.
Internationaux	T1047	Windows Management Instrumentation	Deadglyph utilise WMI pour exécuter sa chaîne de chargement.
	T1059.003	Interpréteur de commandes et de scripts : Shell de commandes Windows	Le téléchargeur de shellcode utilise cmd.exe pour se supprimer.
	T1106	API native	Un module Deadglyph utilise CréerProcessW ainsi que les CréerProcessAsUserW Fonctions API pour l'exécution.
	T1204.002	Exécution utilisateur : fichier malveillant	La chaîne de téléchargement de shellcode nécessite que l'utilisateur double-clique et l'exécute.
Persistence	T1546.003	Exécution déclenchée par un événement : abonnement aux événements de Windows Management Instrumentation	Le chargeur Deadglyph initial est conservé à l’aide de l’abonnement aux événements WMI.
Évasion défensive	T1027	Fichiers ou informations obscurcis	Les composants Deadglyph sont cryptés. Deadglyph Orchestrator et les modules intégrés sont masqués par .NET Reactor. Le téléchargeur de shellcode est masqué par ConfuserEx.
	T1070.004	Suppression de l'indicateur : suppression de fichier	Deadglyph peut se désinstaller. La chaîne de téléchargement de shellcode se supprime et supprime les fichiers du cache WebDAV.
	T1112	Modifier le registre	Deadglyph stocke sa configuration et sa charge utile chiffrée dans le registre.
	T1134	Manipulation des jetons d'accès	Deadglyph peut se faire passer pour un autre utilisateur.
	T1140	Désobscurcir/décoder des fichiers ou des informations	Deadglyph déchiffre les chaînes cryptées. La chaîne de téléchargement de shellcode décrypte ses composants et configurations.
	T1218.011	Exécution du proxy binaire système : Rundll32	Le chargeur Deadglyph initial est exécuté en utilisant rundll32.exe.
	T1480.001	Garde-fous d’exécution : saisie environnementale	Deadglyph est crypté à l’aide d’une clé spécifique à la machine dérivée de l’UUID du système.
	T1562.001	Altérer les défenses : désactiver ou modifier les outils	Le téléchargeur de shellcode évite l'analyse AMSI en appliquant des correctifs clr.dll en mémoire .
	T1620	Chargement de code réfléchissant	Deadglyph charge ses modules de manière réfléchie à l'aide d'un chargeur PE personnalisé.
Découverte	T1007	Découverte des services système	A Le module Deadglyph découvre les services à l'aide de la requête WMI SÉLECTIONNEZ * FROM Win32_Service.
	T1012	Registre de requête	La chaîne de téléchargement de shellcode interroge le registre pour connaître le navigateur par défaut.
	T1016	Découverte de la configuration réseau du système	Un module Deadglyph découvre les cartes réseau à l'aide de requêtes WMI SELECT * FROM Win32_NetworkAdapter ainsi que les SELECT * FROM Win32_NetworkAdapterConfiguration où InterfaceIndex=%d.
	T1033	Propriétaire du système/Découverte des utilisateurs	Un module Deadglyph découvre les utilisateurs avec la requête WMI SELECT * FROM Win32_UserAccount.
	T1057	Découverte de processus	Un module Deadglyph découvre les processus à l'aide d'une requête WMI SELECT * FROM Win32_Process.
	T1082	Découverte des informations système	Un module Deadglyph découvre des informations système telles que la version du système d'exploitation, les lecteurs, les variables d'environnement et les pilotes à l'aide de requêtes WMI.
	T1518	Découverte de logiciels	Un module Deadglyph découvre les logiciels installés à l'aide d'une requête WMI SELECT * FROM Win32_Product.
	T1518.001	Découverte de logiciels : découverte de logiciels de sécurité	Un module Deadglyph découvre un logiciel de sécurité à l'aide de requêtes WMI SELECT * FROM AntiVirusProduct, SELECT * FROM AntiSpywareProduct ainsi que les SELECT * FROM FirewallProduct. La chaîne de téléchargement de shellcode vérifie les processus en cours d'exécution pour une solution de sécurité.
Collection	T1005	Données du système local	Deadglyph dispose d'un module de lecture de fichiers.
Commander et contrôler	T1071.001	Protocole de couche d'application : protocoles Web	Deadglyph et le téléchargeur de shellcode communiquent avec le serveur C&C via le protocole HTTP.
	T1090	procuration	Deadglyph et le téléchargeur de shellcode peuvent utiliser un proxy HTTP pour la communication C&C.
	T1573.001	Canal crypté : cryptographie symétrique	Deadglyph utilise AES pour crypter les communications C&C.
exfiltration	T1041	Exfiltration sur le canal C2	Deadglyph utilise le canal C&C pour l'exfiltration.

• Contenu propulsé par le référencement et distribution de relations publiques. Soyez amplifié aujourd'hui.
• PlatoData.Network Ai générative verticale. Autonomisez-vous. Accéder ici.
• PlatoAiStream. Intelligence Web3. Connaissance Amplifiée. Accéder ici.
• PlatonESG. Carbone, Technologie propre, Énergie, Environnement, Solaire, La gestion des déchets. Accéder ici.
• PlatoHealth. Veille biotechnologique et essais cliniques. Accéder ici.
• La source: https://www.welivesecurity.com/en/eset-research/stealth-falcon-preying-middle-eastern-skies-deadglyph/