Analyse d'un "dropper" de ransomware

C'est vendredi, c'est permis. Comme beaucoup (trop) de monde, je reçois pas mal d'e-mails contenant des pièces jointes malveillantes. Ces derniers temps, la tendance est aux ransomwares. Après tout, pas besoin de dépenser des fortunes dans des exploits touchant la dernière version du navigateur ou du client mail de l'utilisateur, quand on peut compter sur sa coopération lorsqu'il s'agira de lui demander d'ouvrir un document, et ensuite de payer pour récupérer (ou pas) l'accès à ses fichiers.

Alors le document du jour a été envoyé par l'adresse IP 182.180.112.194 (au Pakistan, mais ça on s'en fout un peu vu qu'il s'agit probablement d'une machine compromise) depuis une adresse gmail, visiblement spoofée en raison d'un en-tête SPF en "softfail" (signifiant que l'IP ayant envoyé l'e-mail n'est pas autorisée via les règles SPF à utiliser le domaine GMail, mais que le propriétaire du domaine le tolère). La pièce jointe est un document Word 2007+ d'environ 45ko :

Alors on peut évidemment aller droit au but et balancer le document dans notre sandbox préférée, voire sur VirusTotal, si l'on a pas de contraintes de confidentialité des données etc. Dans mon cas, il s'agit d'une boite mail perso, je n'ai pas de contraintes particulières. Dans le pire des cas, on peut calculer le hash du document, et le rechercher directement sur les sites mentionnés ci-dessus, comme ça, si l'on ne peut pas (pour diverses raisons) soumettre le fichier, on saura si des informations existent à son sujet.

Mais on peut aussi avoir envie de décortiquer un peu le document. Alors attention, l'analyse qui suit est loin d'être un modèle, mais certains y trouveront sûrement des informations intéressantes.

Un outil que j'ai découvert il n'y a pas si longtemps, c'est "mraptor" de la suite "oletools". Son verdict est immédiat :

On voir direct le gros "SUSPICIOUS" (qui ne se traduit pas par "SUSPICIEUX", mais "SUSPECT"), ainsi que les flags signifiant que la macro s'exécute dès l'ouverture du document (pour peu que les macros soient activées), que des données sont écrites sur le disque, et que la macro exécute un binaire.

D'ailleurs, intéressons nous davantage à cette macro. On va utiliser l'outil "olevba", toujours de la suite oletools :

Malgré plusieurs essais d'options du script, il n'a pas été en mesure de déchiffrer les chaines obfusquées. Ce n'est pas parce que c'est complexe, mais parce qu'il n'a pas été en mesure d'identifier le pattern et de les décoder. Ce n'est pas bien grave, ça se fait très facilement à la main. Avec le même outil, on obtient le code de la macro (juste au dessus du tableau). Au premier abord, le code de la macro ressemble à un set de fonctions de conversions d'unités de mesures diverses, comme par exemple des conversions de volumes, de pressions, etc. Puis on repère assez vite ce morceau de code (pas reproduit dans son intégralité) :

Evidémment, vu comme ça ça ne ressemble à rien. Juste une sorte de chaine de caractères comportant plusieurs valeurs numériques séparées par des caractères ressemblant à des guillemets, qui est splittée, vraissemblablement en prenant ces caractères comme séparateurs, afin de ne garder en sortie qu'un tableau d'entiers, qui ne correspondent pas à un charset connu. On regarde si "sOvetSPL" est utilisé ailleurs dans le code, pour voir quel traitement est fait sur ce tableau :

On a donc une itération sur chacun des entiers, divisé par 16, et converti ensuite en caractère. C'est vrai que si on regarde la gueule de la chaîne d'origine, on repère des patterns à l'oeil nu. Les premiers caractères évoquent assez facilement un "http://". Plutôt que faire chaque caractère à la main (vu la longueur de la chaîne obfusquée ça peut se faire cela dit), on va scripter ça :

On obtient donc une URL. Le reste de l'obfuscation est assez lourde à décortiquer, certaines informations étant obtenues depuis les fichiers embarqués dans le document, mais il est assez facile de déterminer qu'il s'agit d'une fonction effectuant le téléchargement du fichier présent à l'URL ci-dessus, et que ce fichier est par la suite exécuté. L'analyse de ce malware nécessiterait un post à part entière, mais sans surprises, il s'agit d'un ransomware, visiblement un bon vieux Locky :

Notons qu'il s'agit ici des seuls anti-virus qui détectent cette variante de Locky :-)

Autre point amusant vu sur Malwr, le malware refuse visiblement de s'exécuter sur une machine virtuelle. C'est bon à savoir pour ne pas se faire chiffrer ses données :-)

Review de la formation FOR 610 - Reverse Engineering Malware du SANS

Comme mentionné dans mon post précédent, j'ai eu l'occasion de suivre la formation "Reverse Engineering Malware" du SANS Institute, ainsi que passer la certification GREM qui l'accompagne. Je proposais d'en faire une review dans un post blog, et vu que j'ai eu de la demande pour ça dans les commentaires, j'ai décidé de passer une petite heure et demie à écrire mes impressions.

Alors les formations SANS, dans leur principe, s'adressent principalement à des gens ayant pas ou peu de notions dans le domaine; en tout cas, les prérequis ne sont pas énormes. Concernant cette formation, je ne partais pas non plus de rien, ou du moins, j'avais déjà eu affaire à du code assembleur au préalable, j'avais déjà observé le fonctionnement d'un malware dans une sandbox et j'avais déjà utilisé un debugger avant d'entamer la formation. De plus, ayant été développeur quelques années, les notions de liste chainée et pointeur en mémoire ne m'étaient pas inconnues. Alors ça tombe bien parce qu'au niveau des prérequis, si on fait abstraction des besoins logiciels et matériel (un ordinateur capable de faire tourner 2 VM pas trop gourmandes dans VMware), il est juste recommandé d'avoir des notions relatives à des concepts de programmation telles que "variable", "boucle" et "fonction".

Alors vous allez vous demander, "mais que Diable allons nous reverser si on ne lit pas dans la matrice/en assembleur ?". Eh bien sur les 5 jours que comporte la formation, une journée (quasi complète) est consacrée à la l'apprentissage (basique) de l'assembleur. Mais j'y reviendrai un peu plus bas, parce que là, je vais détailler le programme des 5 jours de formation (alors je précise que j'ai suivi la formation via l'outil "OnDemand", qui est la plateforme d'e-learning du SANS - la formation avec un vrai instructeur se passe en 6 jours, la dernière journée étant un petit challenge de reverse entre les élèves, mais là je n'en sais pas plus). Notez que j'ai suivi la formation entre mai et août 2013, et que le contenu a peut-être changé sensiblement depuis.

Donc sans plus attendre, voici ce qu'on apprend, avec mes commentaires :

- Jour 1

On commence par des banalités sur ce à quoi ça sert de reverser un malware (utile lorsque l'on bosse dans un CERT, ou tout simplement à titre perso pour la curiosité/la culture/la gloire), en donnant un exemple réel (vieux de quasiment 15 ans) puis sur la manière de procéder (le sieur Zeltser préconise d'effectuer une analyse comportementale, et lorsqu'on arrive aux limites de cette analyse, procéder à une analyse du code (désassemblage / debug / etc) pour déterminer des éléments pouvant faire avancer l'analyse comportementale, et recommencer).

On passe ensuite à l'installation d'un lab d'analyse de malware (comprendre une VM sous Windows avec plein d'outils (IDA / OllyDbg / la suite Sysinternals / LordPE / etc + la distribution REMnux) puis on commence vraiment ce pour quoi on est là, à savoir analyser du malware.

Alors sans spoiler quoi que ce soit, en gros on analyse (entre autres) un "slackbot" (un vieux bot qui prend ses ordres sur un chan IRC, configurable, avec un petit twist à la fin). Donc un sniffe le trafic en provenance de la VM infectée, on voit qu'elle essaie de joindre un hostname précis => on lui donne l'ip de notre remnux => elle se connecte à un port fermé => on ouvre le port en question sur remnux => c'est un ircd => on la laisse se connecter => on récupère le chan => on est bloqué. A partir de là on voit que le binaire est packé avec UPX => upx -d => strings => on repère des chaines genre !@info => on les tape dans le chan irc => ça marche mais pas !@run ni !@login => on repère l'endroit où ces chaines sont utilisées dans le code => on pose quelques breakpoints => on récupère le password => WIN.

Au cours de cette première journée on fait ça sur 2 ou 3 autres malwares histoire de bien comprendre le principe.

- Jour 2

Au cours du jour 2, on approfondit un peu ce qu'on a vu la veille :

On reprend notre malware de la veille (sdbot) et on voit qu'il est également possible de le "patcher" pour qu'il accepte n'importe quel password (au lieu de breaker sur le "call strcmp" de la fonction correspondant à "!@login") en remplaçant un jnz par un jmp.

On apprend aussi la base de l'unpacking manuel en voyant comment unpacker de l'UPX à la main, sans utiliser "upx -d", puis aussi comment faire pour forcer la VM infectée à se connecter à notre VM remnux lorsque le malware utilise une adresse IP hardcodée à la place d'un fqdn (vu que la veille on fait ça en modifiant le fichier "hosts" ou via un tool genre "fakedns").

On termine la journée en voyant comment on analyse du JavaScript de manière assez basique (mais on approfondit un peu plus tard).

- Jour 3

La majorité de la journée consiste en un cours d'assembleur pour les nuls. On voit comment s'effectuent les affectations, les modes d'adressage, les sauts, etc etc. Puis on enchaîne sur comment reconnaître les fonctions potentiellement malveillantes d'un malware (genre si le malware utilise telle fonction c'est un keylogger, ou cette fonction là nous indique qu'il s'injecte dans un autre processus, ou que s'il fait ça c'est que c'est un sniffer réseau).

Concernant ce jour là je peux pas m'étendre plus, c'est juste un cours d'assembleur, auquel on a ajouté une liste des "patterns" malveillants dans un programme.

- Jour 4

C'est ce jour là que les choses très sérieuses commencent. On aborde le reversing de malwares qui emploient des techniques diverses et variées destinées à ralentir le boulot d'analyse. Donc les packers un peu méchants et autres techniques anti désassemblage/anti debug (utilisation des callbacks TLS, des exceptions, du timing avec RDTSC, etc) et chaque fois, des moyens de bypasser ces mécanismes. L'idée ici c'est vraiment de donner des billes pour être capable de se démerder seul lorsque l'on se retrouve face à un packer custom. Bien évidemment, lorsque l'on se retrouve à unpacker un truc connu, on nous suggère de chercher s'il n'existe pas un plugin OllyDbg existant. Mais pour la gloire, on unpack du PEcompact aussi bien manuellement, qu'avec un plugin Olly, histoire de mieux comprendre.

En fin de journée, on approfondit l'analyse de code JavaScript malveillant (et obfusqué avec diverses manières de rendre le code plus lisible) ainsi que l'analyse de shellcodes, histoire de comprendre ce qu'ils font quand on se retrouve face à l'un d'entre eux.

Dans le bouquin, il y a une partie bonus sur le reverse engineering de code Java malveillant aussi.

- Jour 5

Dernier jour de la formation, qui croise une petite partie de la formation FOR 508 du SANS (Incident Response & Advanced Forensics, de mémoire). On s'éloigne "un peu" (mais pas beaucoup) du reversing de malware. En fait on apprend comment procéder à l'analyse de documents malveillants. Documents dans le sens "fichier office" ou "fichier pdf". Donc on nous présente un set d'outils (pour le format Office on est un peu limités, l'intégralité des outils existants sont abandonnés depuis 4 ou 5 ans) et pour le format PDF (genre Origami). On apprend à extraire des charges malveillantes de ces formats de document (ensuite, on a plus qu'à reprendre ce qu'on a appris les jours précédents pour les reverser), puis aussi comment reconnaitre certains patterns typiques (genre un shellcode qui parcourt la liste des filedescriptors ouverts et utilise GetFileSize() pour retrouver le document d'où il provient afin de pouvoir extraire le reste de sa charge active étant contenue à l'intérieur).

On termine la journée, et la formation, par un cours sur le framework Volatility (c'est à ce moment là qu'on croise la formation FOR 508), et l'analyse de dumps mémoire à la recherche de malwares (toujours dans le but de les extraire avant de les analyser avec les compétences acquises les jours précédents). On voit donc comment effectuer des dumps de ram (avec la fonction de snapshots de VMware ou à l'aide d'un outil conçu par un parfait inconnu).

Alors je serais totalement infoutu de dire si c'est difficile ou pas comme formation, vu que je ne partais pas de zéro. Seul le jour 4 avec l'unpacking manuel m'a un peu endormi car c'était, à mon sens, le jour le plus dense de la formation, et certaines explications étaient un peu légères (en fait, de manière générales les manipulations consistent à suivre aveuglément les instructions, genre "appuyez 3 fois sur F8 dans OllyDbg, vous arrivez là, vous sélectionnez le registre ESP dans le panneau d'état des registres, vous faites "follow in dump", puis vous sélectionnez les 4 premiers octets du dump et placez un breakpoint lors de l'accès puis vous faites F9" sans plus d'explications, ou alors assez mauvaises.

Concernant la difficulté de la certification elle même, c'est assez mitigé. Elle dure 2 heures et se passe en mode "open book" (donc on a le droit de ramener les bouquins / cheatsheets). On peut aussi bien se retrouver avec des questions du niveau "dans la liste suivante, quel outil permet d'analyser du trafic réseau ?" avec comme choix "wireshark / iptables / irssi / ollydbg", que des gros pavés de code assembleur avec des numéros sur certaines lignes, où il nous est demandé à quelle ligne il est le plus judicieux de placer un breakpoint si on veut pouvoir obtenir la version déchiffrée d'un fichier lu par une fonction appelée dans ce pavé d'assembleur.

Je me doute que si vous avez lu jusqu'ici, vous attendez une liste de trucs à lire pour se préparer à la certification. Ben la première réponse c'est bien évidemment les petits fascicules du SANS qui sont fournis lorsque vous suivez la formation. Pour les autodidactes, il y a deux excellents bouquins qui couvrent la quasi totalité du contenu du cours :

- Practical Malware Analysis

- Malware Analyst's Cookbook

Regardez le sommaire, vous y retrouverez 99% de ce dont j'ai parlé au dessus. Ensuite, c'est comme tout, il faut un minimum de curiosité pour s'en sortir. Il faut aussi continuer à pratiquer l'analyse de malwares à l'issue de la formation. Les connaissances c'est comme les muscles, ça s'entretient. Vous pouvez par exemple faire la série d'épreuves "Command & Control" du site de challenges root-me (enfin sauf la première qui est un peu différente. Vous pouvez également faire les labs d'un des bouquins cités ci-dessus.

En cas de questions relatives à cette formation, n'hésitez pas à m'envoyer un ptit mail ou écrire un commentaire.