Guillaume Orlando

Cette série de writeups couvre les différents exercices du lab “Practical Malware Analysis”. Ce premier chapitre à pour but d’introduire à l’analyse statique basique de différents samples.

Lab 1-1 (Lab01-01.exe and Lab01-01.dll)

1 - Does either file match any existing antivirus signatures

Les deux fichiers sont majoritairement reconnus comme étant malicieux par VirusTotal, avec un ratio de détection avoisinant les 40 / 65.

2 - When were these files compiled ?

Les dates de compilation sont accessibles dans le header des binaires. J’utilise ici CFF Explorer pour récupérer ces informations : En convertissant le timestamp hexadécimal 4D0E2FD3, j’obtiens une date de compilation du 19 Décembre 2010 à 16:16:19 pour le fichier exécutable, et du 19 Décembre 2010 à 16:16:38 pour le DDL.

3 - Are there any indications that either of these files is packed or obfuscated? If so, what are these indicators?

En observant la taille des différentes sections des deux fichiers, toujours via CFF Explorer, il semblerait que ceux-ci ne soient pas packés :

PEiD confirmera cette piste en indiquant que les deux fichiers ne sont pas packés puisque ceux-ci sortent tout droit du compilateur Microsoft C++ :

4 - Do any imports hint at what this malware does? If so, which imports are they?

En observant les appels fonctions effectués par le DLL, il est possible de deviner que celui-ci va interagir avec les processus système, et qu’un système de mutex est présent (identification unique de la machine cible pour ne pas lancer plusieur instances du même programme malveillant): De plus, des fonctions réseaux sont importés par le malware via la librairie WS2_32.dll, avec notamment des fonctions d’interaction avec le protocole RPC : Enfin, au niveau de l’exécutable, il semblerait que celui-ci manipule essentiellement des fichiers systèmes :

5 - Are there any other files or host-based indicators that you could look for on infected systems?

Oui, en récupérant les chaînes de caractères présentes dans le DLL et dans l’exécutable via l’utilitaire strings, il est possible d’observer la présence de nombreuses allusions au fichier kernel32.dll, avec une tentative d’obfuscation de “kernel32.dll” en “kernel132”. Ce malware va ainsi certainement chercher à modifier et / ou remplacer la librairie kernel32 du système. Pour vérifier si une machine est infectée, il suffit donc de vérifier la présence de la fausse librairie “C:/windows/system32/kerne132.dll”. Une analyse du code assembleur révèlera plus tard (question 7) qu’il est aussi possible de chercher la présence d’un processus nommé “SADFHUHF“ sur un système pour déterminer si le programme malveillant est encore en fonctionnement.

6 - What network-based indicators could be used to find this malware on infected machines?

Toujours en observant les chaînes de caractères présentes dans le binaire, une adresse IP est présente : L’analyse du code assembleur confirmera le fait que cette adresse IP est celle du serveur de contrôle du malware. Il est donc désormais possible de détecter la présence de machine infectées en créant un règle de détection de trafic en direction et en provenance de cette IP. L’ajout de quelques règles de firewall permet également de couper toute communications entre le malware et son serveur de contrôle sur les machines potentiellement infectées.

7 - What would you guess is the purpose of these files?

Afin de comprendre plus en profondeur ce que fait ce malware, et ne pas simplement deviner le comportement du binaire, je décide de terminer l’analyse du malware avec IDA, en me concentrant sur le DLL. Dans un premier temps, ce DLL va initier un mutex nommé “SADFHUHF”, de façon à ne pas infecter plusieurs fois une machine déjà infectée: Ensuite, un socket TCP va être ouvert en direction d’un serveur de contrôle : La machine infectée va alors se manifester auprès du serveur distant en envoyant un “hello”, toujours via le même socket : Si le serveur ne transmet aucunes informations au binaire, celui-ci va instantanément envoyer un nouveau un message “hello”, jusqu’à recevoir une instruction précise. Les instructions disponibles sont au nombre de deux :

• “sleep”
• “exec”

La première va initier une boucle d’attente d’environ 6 minutes, avant que le client ne recommence à envoyer un “hello” au serveur : La deuxième instruction va initier la création d’un nouveau processus attaché à ce DLL, et lui faire exécuter une commande en CLI : Ce DLL sert donc bien d’interface de commande pour le malware, et est installé par l’exécutable. Je n’irai pas plus loin dans l’analyse de ce sample, puisque l’exercice de cette première analyse s’inscrit dans le cadre d’une analyse statique basique. En conclusion, ce sample correspond a ce qui semblerais être une backdoor sous la forme d’un DLL. Ce DLL est installé par un exécutable, qui va hijacker la bibliothèque légitime Windows kenrel32.dll. Avec les informations à disposition, il est tout à fait possible de détecter une machine compromise, de bloquer ce malware, et de netoyer correctement un système infecté.