Practical Malware Analysis - Lab 03x3
Lab 3-3 (Lab03-03.exe) / (Lab12-2.exe)
1 - What do you notice when monitoring this malware with Process monitor ?
Au lancement du binaire, une nouvelle instance du processus “svchost.exe” est créé, en tant que processus enfant du malware:
Puis, le processus parent du malware est terminé, laissant le processus enfant seul:
Ce comportement est typique d’une injection de contenu en mémoire.
2 - Can you identify any live memory indicators ?
Le nouveau processus svchost est détaché des processus svchost légitimes, et son PID est logiquement plus haut que les autres processus:
De manière plus précise, en observant le processus parent des svchost.exe, celui démarré par le malware possède de simples droits utilisateurs, et n’a pas été initié par services.exe (à gauche un processus svchost malicieux, à droite un processus svchost légitime):
3 - What are the malware’s host-based indicator ?
Le malware drop un fichier de log sur le bureau, au nom de “practicalmalwareanalysis.log”.
4 - What is the purpose of this program ?
Le programme injecte un keylogger dans la fausse instance svchost. En effet, le fichier trouvé précédemment contient la liste des programmes avec lesquels l’utilisateur interagit ainsi que les frappes claviers effectuées:
Analyse complète:
Stage 1 (injector):
Puisque le premier stage du malware va injecter du contenu malveillant dans un processus ‘svchost.exe’, le chemin relatif de ce processus est construit dynamiquement en mémoire:
Le contenu à injecter en mémoire est ensuite récupéré depuis un ressource interne au malware. La ressource est située dans l’arborescence “UNICODE/LOCALIZATION”. La ressource est chargée en mémoire à l’aide des fonctions LoadResource et LockResource:
LoadResource va retourner un handler vers la ressource spécifiée, et LockResource un pointeur vers l’espace mémoire contenant la ressource. Cette dernière est chiffrée / obfusqué de façon à ce que le contenu ne soit pas lisible pour le moment:
Le déchiffrement de la ressource va donc se faire en mémoire. Une portion mémoire suffisamment grande pour l’accueillir est donc allouée avec la fonction Virtualalloc puis memcpy:
Enfin, la copie mémoire de la ressource est déchiffrée avec un simple xor, bytes par bytes:
La clé permettant de déchiffrer le xor est “0x41”.
Il est maintenant possible de dumper le contenu du payload déchiffré via un débugger. J’ai personnellement écrit un script python capable d’extraire la ressource du malware et de la déchiffrer en mémoire, avant d’écrire le résultat dans un nouvel exécutable:
Le script, bien que mal optimisé, est disponible à cet adresse: https://github.com/GuillaumeOrlando/MalwareAnalysisArtifacts
Le scan VirusTotal du dump est le suivant: https://www.virustotal.com/gui[…]
La fonction d’injection en mémoire est ensuite appelée, et prenant comme argument un pointeur vers l’espace mémoire contenant le payload à injecter, et le nom du processus cible dans lequel injecter le contenu malicieu:
Le processus vierge svchost.exe est créé:
Le processus est créé dans un état suspendu (“CreationFlag” à 0x00000004) de façon à permettre au malware d’interagir avec:
Le contexte du thread est récupéré par la fonction GetThreadContext, puis, à l’aide de la fonction ZwUnmapViewOfSection, le contenu du processus cible est nettoyé:
Une fois l’espace mémoire nettoyé, un nouvel section mémoire est attribué avec VirtualAlloc:
Enfin, la fonction WriteProcessMemory va permettre d’écrire unes-à-unes les sections (.text, .rdata et .data) du payload dans le processus svchost.exe:
L’état suspendu du processus est levé, pour permettre au keylogger de fonctionner:
Le malware se termine à la suite, après une période de sommeil brève, pour laisser place au keylogger en mémoire:
Stage2 (payload):
Le fichier extrait du processus svchost.exe est un keylogger qui va monitorer tous les événements systèmes relatif aux frappes claviers via la fonction SetWindowsHookA. La fonction prend plusieurs arguments, dont “idHook” qui permet de cibler uniquement les événements claviers (via l’argument 0x13), et “lpfn” qui pointe vers le code à exécuter dès qu’un événement est intercepté par le hook (ici, la fonction “hook_procedure”):
Si aucun événement clavier n’est retourné par le système d’exploitation, le keylogger se contente de récupérer les messages suivants, jusqu’à en trouver un intéressant:
Dans le cas où une frappe clavier est détectée, la procédure liée au coeur du keylogger est appelée:
Le fichier dans lequel les frappes claviers vont êtres sauvegardés est créé dans un premier temps:
Le nom du processus avec lequel l’utilisateur interagit est récupéré avec les fonctions GetForegroundWindows (retourne un handler vers la fenêtre au premier plan) et GetWindowsTextA (retourne le titre de la fenêtre, en fonction du handler spécifié):
Le nom de la fenêtre en question est ajoutée à la suite du fichier de log, au sein d’une balise “_[Window:
Le résultat est le suivant:
La touche clavier ayant déclenchée l’événement est, pour finir, écrite au sein du fichier de log. Si la touche est une simple touche alphabétique, celle-ci est ajoutée telle-quelle à la suite du fichier. Si la touche correspond à une action particulière (i.e: une barre d’espace, un “entrer”, un “shift”, etc …) ou à un chiffre, un switch de 19 valeurs est appliquée de façon à déterminer et formater l’entrée qui sera ajoutée au fichier de log:
Par exemple, le code responsable d’ajouter la touche “shift” au fichier de log est le suivant:
Le résultat est ensuite appliqué au fichier de log:
Le keylogger boucle sur cette suite d’actions, à partir du moment ou une frappe clavier est détectée. À noter que la malware ne possède pas de méthode de persistance, ni de technique l’exfiltration de données.