Bonjour, j’aimerais aujourd’hui partager avec vous un des sujets qui me passionne le plus dans l’informatique : La rétro-ingénierie appliquée à l’analyse de malware. Tout d’abord une petite définition selon Wikipédia :

La rétro-ingénierie, ou ingénierie inverse ou inversée, est l’activité qui consiste à étudier un objet pour en déterminer le fonctionnement interne ou la méthode de fabrication. On parle également de rétroconception et dans le domaine du vivant de biomimétisme. Le terme équivalent en anglais est reverse engineering.

Je vais vous montrer pas à pas comment on peut s’en servir pour examiner un virus ou malware dans le cadre d’une attaque informatique. Cela nous permettra de voir à peu près quelles fonctionnalités comporte le malware, comment il est piloté…

Première étape : Télécharger le malware

Tout d’abord, où trouver un malware ? Malheureusement, il n’est pas difficile d’en trouver. Une simple recherche sur YouTube permet d’en trouver des centaines. Lorsque vous cherchez un logiciel qui permet d’augmenter son score dans un jeu par exemple, les pirates aiment bien mettre un malware dans le lien de téléchargement à la place de leur super logiciel qui permet de gagner le jeu (qui est au passage très réaliste dans la vidéo).

Nous voilà en possession de l’exécutable, ou plutôt dans mon cas du script malicieux. J’ai vraiment pris le lien de la première vidéo que j’ai trouvé. Dans ce cas, je tombe sur un fichier .vbs.

Attention, si vous tentez de réaliser de la rétro-ingénierie sur un exécutable dont vous n’êtes pas certain de la source, il faut prendre beaucoup de précautions, surtout ne l’ouvrez pas.

Deuxième étape : Préparation du laboratoire d’analyse

C’est peut être un bien grand mot pour ce que je vais déployer mais j’aime bien utiliser ce terme ! J’utiliserai une machine virtuelle sous Windows 7 pour ne pas infecter mon PC (bien que je ne puisse pas exécuter le script nativement sous mon Ubuntu).

Petit astuce si vous faites souvent ce genre de manipulation. Préparez vous une installation virtualisée de Windows qui sera propre et dans laquelle tous vos outils sont installés. Vous n’exécuterez rien de malicieux sur cette machine car vous la clonerez avec VirtualBox (Logiciel libre et OpenSource) à chaque nouveau cas. Vous restez ainsi avec une machine toujours à disposition et un clonage ne vous prend que quelques minutes.

Personnellement, je désactive dans ma nouvelle machine clonée la carte réseau pour être certain que le malware ne se répande pas au travers du réseau. Le seul risque c’est qu’il ai été développé pour sortir de la machine virtuelle ce qui nécessite une faille dans VirtualBox. En gardant votre logiciel à jour, vous réduisez drastiquement les risques. De plus, le genre de virus que l’on trouve sur YouTube sont en général des logiciels malveillants fait par des personnes qui utilisent des logiciels pour les générer comme des outils d’administration à distance (RAT en anglais). Ces personnes ne sont donc pas vraiment compétentes et ne développement pas leur propre malware qui pourrait être vraiment dangereux.

Troisième étape : Analyse post-exécution

Une fois notre malware prêt à être exécuté, nous allons tout d’abord l’ouvrir avec un éditeur hexadécimal pour avoir une idée de ce qu’il va faire. Dans mon cas c’est faisable car je vous rappelle que c’est un script.

Voici donc ce que j’obtiens : Contenu script malicieux Le code est difficilement lisible mais on peut se douter de ce qu’il va faire. On peut déjà lire la déclaration d’une variable au nom douteux (le premier bloc surligné en rouge).

On voit plusieurs appels à des noms de méthodes SaveFile, Temp, CreateObject, CreateElement, Stream, Write mais également un appel à la méthode Close et un nom de fichier YEFDGYT.EXE.

Tout de suite, on comprend que le code de l’exécutable contenu dans B1 va être écrit dans le dossier Temp de Windows avec le nom YEFDGYT.EXE.

On parcourt ensuite le fichier qui contient que le code du binaire malveillant et lorsque l’on arrive à la fin, on remarque qu’il va être exécuté.

Execution script malicieux

On peut maintenant lancer le script et se rendre dans le dossier Temp. A ma grande surprise, je remarque que deux binaires ont été écrits dans le dossier. Le fichier YEFDGYT.EXE a bien été créé mais aussi un autre qui se nomme isas.exe.

Je décide donc de scanner les deux fichiers sur un service en ligne qui se nomme VirusScanJotti. Le premier fichier est bien détecté comme un cheval de Troie par pratiquement tous les antivirus. Je scanne donc le deuxième fichier et je me rend compte que la somme md5 est la même. Le virus a donc été écrit deux fois.

Dans la partie information du fichier nous apprenons qu’il est de type PE32 executable (GUI) Intel 80386 Mono/.Net assembly, for MS Windows.

On est donc en possession d’un malware écrit avec le framework .NET qui sera facilement décompilable. J’utiliserai le logiciel ILSpy qui est sous licence MIT donc libre et Open Source.

Quatrième étape : Décompiler le malware

Une fois décompilé, on retrouve dans le main l’appel à une classe statique qui comporte toutes les variables du programme. Cette fois, il n’y a plus de doutes, cet exécutable possède des variables qui sont basiques d’un outil d’administration à distance, c’est bien un logiciel malveillant.

Liste des variables présentes dans le malware

On retrouve dans les variables VN et RG à première vue des chaînes générées aléatoirement qui seront sûrement des Mutex. Ce Mutex sert à outrepasser l’analyse statique des signatures du virus par les antivirus. Nous avons ensuite le nom de l’exécutable et son dossier d’installation TEMP.

Les variables les plus intéressantes pour moi sont les variables H et P qui sont l’adresse de connexion et le port utilisé pour la connexion. On remarque que l’adresse de connexion est un DNS fourni par le service NoIP.org. C’est une technique classique qui permet de ne pas mettre directement son adresse IP dans le code de l’exécutable. Il suffit alors à l’attaquant de synchroniser son IP avec son DNS pour qu’il puisse se connecter au malware.

Cette technique n’est évidemment pas infaillible car un ping vers le DNS ou un trace route permettrait de retrouver l’adresse IP de l’attaquant.

Nous avons aussi la variable sf qui est déclarée et contient un chemin Software\\Microsoft\\Windows\\CurrentVersion\\Run. Ce chemin va sans doute permettre au virus de démarrer en même temps que le système d’exploitation grâce à l’écriture d’une clé dans le registre Windows.

On note enfin la variable C qui correspond au TCPClient pour la connexion.

Lorsque je rentre dans la méthode appelée par le main, on peut lire que le programme se réécrit dans un autre exécutable, et le lance dans un nouveau thread. Il s’agit sûrement d’une technique pour ne pas perdre la porte dérobée en cas de détection et d’éradication par l’antivirus.

On voit ensuite que le programme essai de s’ajouter aux programmes de confiance dans le pare-feu :

Interaction.Shell("netsh firewall add allowedprogram " + LO.FullName + "\" + LO.Name + "\" ENABLE ", AppWinStyle.Hide, true, 5000);

Par la suite, le programme s’ajoute au registre pour démarrer automatiquement grâce à la variable sf.

Le virus s’ajoute au registre pour démarrer en même temps que Windows.

Lorsque l’on continue dans cette méthode, un nouveau Thread est exécuté. La méthode lancée par le Thread est le point d’entrée de toutes les commandes que peut recevoir le serveur.

C’est en fait une suite de tests conditionnels (Case) où l’attaquant envoie une chaîne de caractère et le serveur réalise l’action souhaitée.

On apprend ainsi que l’attaquant peut exécuter un programme dont il spécifiera l’emplacement, démarrer un WebClient pour récupérer un fichier, changer l’adresse et le port du serveur, accéder au registre Windows et écrire dedans, effectuer une capture d’écran, activer la Webcam du PC…

En explorant les classes de l’exécutable, on peut aisément comprendre qu’il possède un enregistreur de frappe (Keylogger) avec sauvegarde des logs par date et heure mais aussi fonctionnalité qui permet de lister les spécifications du système d’exploitation et de tous les disques durs branchés.

J’ai également retrouvé une classe Plugin qui permet certainement de charger un module crée par soi-même. Cette classe m’amène à penser que le pirate n’a pas crée lui même ce malware mais a utilisé un des outils d’administration à distance très connu tel que DarkcometRAT ou encore Poison Ivy, Cybergate…

Je m’arrêterai ici pour cette analyse. J’espère vous avoir fait découvrir quelques astuces,

Enjoy.

Vous avez aimé l'article ? Partagez le :