Bonjour à tous! En prévision du démarrage d'une nouvelle filière au cours de
reverse engineering, nous partageons avec vous la traduction d'un matériel très intéressant. Bonne lecture
Les deux dernières années peuvent être appelées des années de hackers de ransomwares. Les ransomwares sont sans aucun doute le type de malware le plus populaire. Cependant, à la fin des dernières années, nous avons commencé à observer leur baisse de popularité et son augmentation en faveur des mineurs. Il est possible qu'en 2018, cette tendance ne fera que croître.
Du point de vue de la victime, c'est un soulagement, car les mineurs ne sont pas aussi dangereux que les ransomwares. Oui, ils ralentissent le système, mais dès que vous vous en débarrassez, vous pouvez continuer à utiliser votre ordinateur comme avant. Vos données ne sont ni volées ni perdues, comme c'est le cas avec le virus ransomware.
Du point de vue d'un chercheur de logiciels malveillants, les mineurs sont décevants. Ils ne fournissent pas suffisamment de nouveaux matériaux pour une analyse plus approfondie, principalement parce qu'ils sont basés sur des composants open source bien connus avec peu ou pas de confusion ou de furtivité.
Cependant, de temps en temps, nous trouvons des mineurs utilisant des astuces intéressantes. Nous avons récemment observé une technique appelée «Heaven's Gate», qui permet des injections dans des processus 64 bits à partir de chargeurs de démarrage 32 bits. Cette idée n'est pas nouvelle, sa première implémentation remonte à 2009, mais il est intéressant de voir comment elle a été implémentée sous une nouvelle forme, obtenue directement «à l'état sauvage».
Les débutants en analyse de virus peuvent lire un guide sur ce qu'est Heaven's Gate et comment aborder son analyse.
Matériel d'analyse
Ce modèle a été trouvé dans la suite de la campagne
Ngay (plus à ce sujet
ici ). La vérification de la biographie de ces échantillons m'a conduit à l'
article @_qaz_qaz , qui décrit une campagne antérieure avec un échantillon similaire. Cependant, son analyse n'a pas inclus la technologie Heaven's Gate.
Analyse comportementale
Pour voir l'injection mentionnée, nous devons exécuter l'exemple sur un système 64 bits. Nous voyons qu'il lance l'essence du portable, avec les paramètres spécifiques à l'extraction de crypto-monnaie:
En regardant les lignes en mémoire dans ProcessExplorer, nous voyons que ce n'est pas un vrai portable, mais le
mineur XMRig Monero.
Donc, pour le moment, nous sommes sûrs que l'image de l'ordinateur portable en mémoire a probablement été remplacée par la méthode RunPE (Process Hollowing).
Le compte-gouttes principal est de 32 bits, mais déplace la charge utile vers un ordinateur portable 64 bits:
Plus intéressant, ce type d'injection n'est pas pris en charge par l'API Windows officielle. Nous pouvons lire / écrire dans la mémoire des processus 32 bits à partir d'une application 64 bits (en utilisant l'API WoW64), mais pas l'inverse.
Cependant, il existe des solutions non officielles, comme une technique appelée «Heaven's Gate».
Critique de Heaven's Gate
La technique Heaven's Gate a été décrite pour la première fois en 2009 par un hacker avec le surnom de Roy G. Biv. Plus tard, de nombreuses implémentations ont été créées, par exemple, la bibliothèque
Wow64ext ou, sur cette base,
W64oWoW64 . Dans son blog de 2015, Alex Ionescu a décrit les
mesures de lutte contre cette technique .
Voyons comment cela fonctionne.
Exécution de processus 32 bits sur Windows 64 bits
Chaque processus 32 bits exécuté sur une version 64 bits de Windows s'exécute sur un sous-système spécial
WoW64 qui émule un environnement 32 bits. Vous pouvez tracer une analogie avec un sandbox 32 bits créé dans un processus 64 bits. Tout d'abord, un environnement de processus 64 bits est créé. Et déjà à l'intérieur, un environnement 32 bits est créé. L'application s'exécute dans cet environnement 32 bits, mais n'a pas accès à sa partie 64 bits.
Si nous analysons un processus 32 bits de l'extérieur à l'aide d'un scanner 64 bits, nous verrons qu'il contient à la fois des DLL 32 et 64 bits. Plus important encore, il a deux versions de NTDLL: 32 bits (chargé à partir du répertoire SysWow64) et 64 bits (chargé à partir du répertoire System32):
Cependant, le processus 32 bits lui-même ne voit pas la partie 64 bits et se limite à l'utilisation de DLL 32 bits. Pour injecter dans un processus 64 bits, vous devez utiliser les versions 64 bits des fonctions correspondantes.
Segments de code
Pour accéder à la partie restreinte de l'environnement, nous devons comprendre comment l'isolement se fait. Il s'avère que tout est assez simple. L'exécution de code 32 bits et 64 bits est disponible via une adresse de segment de code différente: 32 bits - 0x23 et 64 bits - 0x33.
Si nous appelons l'adresse de la manière habituelle, le mode utilisé pour l'interpréter est défini par défaut. Cependant, nous pouvons explicitement demander une modification à l'aide du code assembleur.
À l'intérieur du mineur: mise en œuvre de Heaven's Gate
Je ne procéderai pas à une analyse complète de ce mineur, comme il a déjà été décrit
ici . Allons directement à l'endroit où le plaisir commence. Le programme malveillant vérifie son environnement et s'il détecte qu'il s'exécute sur un système 64 bits, il utilise une méthode différente pour injecter dans le processus 64 bits:
Après quelques vérifications anti-analyse, il crée un nouveau processus 64 bits suspendu (dans ce cas, un bloc-notes):
Il s'agit de la cible dans laquelle la charge malveillante sera implémentée.
Comme nous l'avons appris précédemment, afin d'intégrer la charge utile dans un processus 64 bits, nous devons utiliser les fonctions 64 bits appropriées.
Tout d'abord, le chargeur de démarrage passe le traitement NTDLL 64 bits:
Ce qui se passe à l'intérieur de la fonction
get_ntdll nécessite une explication plus détaillée. À titre d'explication, nous pouvons également jeter un œil à un
code similaire dans la bibliothèque ReWolf.
Pour accéder à la partie 64 bits de l'environnement de processus, nous devons travailler avec des sélecteurs de segments. Voyons comment le malware passe en mode 64 bits.
Il semble que ce code ait été copié directement à partir de la bibliothèque ouverte:
https://github.com/rwfpl/rewolf-wow64ext/blob/master/src/internal.h#L26Le sélecteur de segment 0x33 est poussé sur la pile. Ensuite, le malware appelle la ligne suivante: (de cette manière, l'adresse de la ligne suivante est également poussée sur la pile.)
L'adresse qui a été
retf pile est fixée en ajoutant 5 octets et est définie après
retf :
À la fin, l'instruction RETF est appelée. RETF est un «retour lointain» et, contrairement au RET normal, il vous permet de spécifier non seulement l'adresse à partir de laquelle vous souhaitez continuer l'exécution, mais également un segment. Comme arguments, il prend deux DWORD de la pile. Ainsi, lorsque RETF est exécuté, l'adresse de retour de retour devient:
0x33: 0x402A50Grâce au segment modifié, le code commençant à l'adresse spécifiée est interprété comme 64 bits. Ainsi, le code que le débogueur voit est 32 bits ...
... en fait 64 bits.
Pour changer rapidement de vue, j'utilise la fonction PE-bear:
Et voici à quoi ressemble ce morceau de code s'il est interprété comme 64 bits:
Ainsi, le code qui est exécuté ici est responsable du déplacement du contenu du registre R12 vers une variable de la pile, puis repasse en mode 32 bits. Ceci est fait afin d'obtenir le
bloc d'informations sur les threads (TEB) 64 bits, à partir duquel nous obtenons le
bloc d'environnement de processus (PEB) 64 bits à
partir d'ici - nous examinons un
code similaire .
Un PEB 64 bits est utilisé comme point de départ pour rechercher une version 64 bits de NTDLL. Cette partie est implémentée de manière assez
triviale (une implémentation «vanille» de cette méthode peut être trouvée
ici ), en utilisant un pointeur vers les bibliothèques chargées, qui sont l'un des champs de la structure PEB. Donc, de PEB, nous obtenons un champ appelé
Ldr :
Ldr est une structure de type
_PEB_LDR_DATA . Il contient une entrée appelée
InMemoryOrderModuleList :
Cette liste contient toutes les bibliothèques chargées qui sont présentes dans la mémoire du processus à l'étude. Nous parcourons la liste jusqu'à ce que nous trouvions la bibliothèque qui nous intéresse, dans notre cas c'est NTDLL. C'est exactement ce que fait la fonction
get_ntdll ci-dessus. Pour trouver un nom approprié, il appelle la fonction suivante, désignée
is_ntdll_lib , qui vérifie le nom de la bibliothèque par rapport à ntdll.dll par caractères. L'équivalent de
ce code s'avère.
Si les noms correspondent, l'adresse de la bibliothèque est renvoyée dans deux registres:
Une fois que nous avons trouvé NTDLL, nous avons juste besoin d'obtenir les adresses des fonctions correspondantes. Nous pouvons le faire en regardant la table d'exportation de la bibliothèque:
Les fonctions suivantes sont récupérées:
- NttUnmapViewOfSection
- NtGetContextThread
- NtAllocateVirtualMemory
- NtReadVirtualMemory
- NtWriteVirtualMemory
- NtSetContextThread.
Comme nous le savons, ces fonctions sont typiques de la technique RunPE. Tout d'abord, NtUnmapViewOfSection est utilisé pour démapper le fichier PE d'origine. Ensuite, dans le processus distant, la mémoire est allouée et un nouveau PE est écrit. À la fin, le contexte du processus est modifié de sorte que l'exécution commence à partir du module intégré.
Les adresses de fonction sont stockées et appelées ultérieurement (de manière similaire à
ce code) pour contrôler le processus distant.
Conclusion
Jusqu'à présent, les auteurs de mineurs n'ont pas fait preuve de beaucoup de créativité. Ils atteignent leurs objectifs en s'appuyant sur des composants open source. Le cas décrit reflète bien cette tendance, car une mise en œuvre prête à l'emploi a été utilisée.
Heaven's Gate existe depuis plusieurs années. Certains programmes malveillants l'utilisent pour augmenter la
furtivité . Mais dans le cas de ce mineur, les auteurs ont probablement cherché plutôt à maximiser les performances en utilisant la charge utile qui correspond le mieux à l'architecture cible.
C’est tout. Vous pouvez en savoir plus sur notre cours
ici .