(Rédacteurs : Sylvain Sarméjeanne - Fabien Périgaud)

Dans le billet précédent, nous avions analysé le malware Storm du 1er avril avec des outils automatiques. Cela permet d'obtenir rapidement une première vision des impacts du virus sur un système infecté, et de développer les scripts de désinfection. Pour avoir une vue plus précise de son fonctionnement interne, il est toutefois nécessaire de passer par une analyse manuelle. Une analyse complète n'est pas nécessaire, le but ici est simplement de déterminer quelques point précis.

Unpacking

Le malware étant évidemment "packé", la première phase consiste à retrouver le binaire original. Il faut pour cela exécuter le malware jusqu'à retrouver le point d'entrée original (OEP, ou "Original Entry Point"). En fonction des techniques anti-debug utilisées, cette étape peut demander du temps. Dans le cas présent, l'analyse a été rapide. Sur le schéma ci-dessous, les parties en rouge constituent des routines de chiffrement XOR :

La partie verte contient un CALL vers 0x401327 ; pour passer toute cette partie, il suffit de poser un point d'arrêt au début de cette fonction. Un coup d'oeil rapide à la suite semble indiquer que nous sommes (déjà !) à l'OEP du binaire. Le moins que l'on puisse dire est que ce packer brille par son absence totale de techniques anti-debug...

Le but étant d'arriver le plus vite possible au code malveillant lui-même, on passe très rapidement sur le code, jusqu'à tomber sur un LoadLibraryW("testdll_f.dll") :

Cette bibliothèque n'existe nulle part. Chose étonnante, les bibliothèques externes ne sont pas mappées en mémoire avant cet appel mais le deviennent juste après. Cela mérite bien que l'on s'y attarde quelques secondes.

En revenant en arrière, on note que le malware récupère un handle sur ntdll.dll avec la fonction GetModuleHandleA, puis construit son IAT avec une succession de GetProcAddress :

Suit une boucle dans laquelle le malware :

  • récupère l'adresse de ntdll.dll
  • récupère les adresses de NtOpenFile, NtCreateSection, NtQueryAttributeFile, NtQuerySection, NtClose, NtMapViewOfSection et NtProtectVirtualMemory
  • pose des hooks sur ces fonctions

A l'appel de LoadLibraryW, les hooks modifieront directement le mapping mémoire du binaire.

Peu après le LoadLibraryW, un CALL EAX nous fait arriver en section 0x320000, adresse à laquelle la bibliothèque testdll_f.dll vient d'être mappée :

Nous arrivons donc à l'OEP de cette bibliothèque, qui fait apparaitre des chaînes en clair déjà trouvées lors de l'analyse automatique ("aromis") :

Un LordPE plus tard, on obtient un dump en clair de cette bibliothèque.

Repérage manuel

Encore une fois, il ne s'agit pas de réaliser une analyse complète du malware, mais seulement de repérer ses principales fonctionnalités. Commençons par regarder les fonctions importées. On repère la présence de fonctions relatives au DNS :

Dans les chaînes de caractères qui sont cette fois-ci en clair, on remarque :

  • les fameuses adresses "interdites" auxquelles le malware n'enverra pas de spam (on retrouve par exemple le nom de certaines sociétés anti-virales) :

  • une liste d'extensions de documents dans lequel le virus va rechercher des emails à qui envoyer du spam :

  • des mots clés des protocoles FTP et SMTP :

  • le mot NameServer. Un tour rapide par les XREFs nous apprend l'existence d'une fonction permettant de modifier les serveurs DNS associés à une interface (clé de registre HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\ <interface>) :

Au final, cet exemplaire de Storm s'est révélé d'un mode opératoire très classique. Il n'incorpore pas de nouveauté particulière de furtivité ni de fonctionnalité novatrice.