Les bases sur l’analyse de malwares

Hello tout le monde!

Aujourd’hui, je vais parler d’analyse de malwares, principalement des bases n’étant pas non plus un expert sur le sujet. Ce post sera découpé en 2 parties majeures précédées d’un prologue, qui correspond en fait à ma méthode de travail: analyse statique en première partie (recherche sur le contexte et sans exécution de code malveillant), puis analyse dynamique en deuxième point (comportement lors de l’exécution du malware).

Prologue: préparer son espace de travail

Avant de se lancer, il faut préparer son environnement de travail, et le faire bien. On va manipuler du code malveillant, et la dernière chose dont on a envie c’est qu’il s’exécute sur notre machine. Il nous faudra alors une VM pour être tranquille. En pratique, la plupart des malwares sont développés pour Windows, ce qui implique d’avoir une VM tournant sur cet OS. Ma méthode consiste à installer sur l’environnement virtualisé (Windows 7 pro pour le compromis légèreté / stabilité / compatibilité) un ensemble d’outils et préparer tout ce dont j’ai besoin pour travailler. Une fois terminé, un snapshot de la VM permettra une restauration après l’analyse de chaque bout de code. En parallèle, la machine hôte est un Linux (Fedora 26 aujourd’hui) ce qui a l’avantage de pouvoir utiliser des outils qui ne sont pas accessibles sur Windows et également de manipuler des fichiers malveillants sans crainte (un malware sous Windows sera innofensif sur Linux). Mais concrètement, j’installe quoi comme outils?

• Python 2.7 et python 3.X
• IDA Pro
• Chrome et Firefox (plugins: JS Deobfuscator, ADBlock, NoScript, Tamper Data)
• Immunity Debugger
• Wireshark
• Notepad++
• API Monitor v2
• Radar2
• OfficeMalSanncer
• SysInternalSuite
• PDF Tools par Didier Stevens
• Olly DBG
• PEiD
• 7Zip, Visual C++, Java, NetFramework
• dotPeek
• Volatility
• Yara
• Manalyzer
• Sandboxie v3.X
• BSA pour Sandboxie et configuré

Vous pouvez installer tout l’attirail sans vous poser de question, ou les installer au fur et à mesure de leur utilisation. Mais attention à ne pas avoir de Snapshot infecté! (ça devient vite relou quand on bosse, qu’on installe un tool et qu’on doit restaurer un snap donc du coup réinstaller le tool sur la version clean). Côté virtualisation, je suis sur VirtualBox mais libre à vous de choisir ce qui vous convient. Pour finir la préparation, il vous faudra bien sûr un fichier malveillant. Je vous propose trois échantillons: malware_1.mal – phishing Paypal, malware_2.mal – Locky, malware_3.mal – Dridex. Attention!! Ce sont des vrais malwares, ils ne sont pas là pour faire jolie! Le mot de passe de l’archive: Infect3d

I/ Analyse statique

Identification

Maintenant que vous êtes prêt, vous balancez votre malware dans votre VM. Théoriquement, l’analyse statique n’est pas dangereuse vu qu’on est censé analyser notre machin sans l’exécuter. En réalité, c’est tellement facile de cliquer dessus qu’on va faire gaffe et ne jamais manipuler sur machine hôte. En plus de cela, on les renomme en .mal pour éviter de les lancer si on double-click malencontreusement dessus. La première étape consiste à définir le type de notre malware: on peut utiliser la commande ‘file’ sous linux pour définir le type, un éditeur hexa ou la commande strings et vérifier si les chaînes “MZ” et “This command cannot be run in DOS mode” sont présents, indiquant ainsi un PE soit un exécutable Windows (.exe):

bash-4.4$ xxd malware_1.mal | head
00000000: 4d5a 9000 0300 0000 0400 0000 ffff 0000 MZ..............
00000010: b800 0000 0000 0000 4000 0000 0000 0000 ........@.......
00000020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000030: 0000 0000 0000 0000 0000 0000 8000 0000 ................
00000040: 0e1f ba0e 00b4 09cd 21b8 014c cd21 5468 ........!..L.!Th
00000050: 6973 2070 726f 6772 616d 2063 616e 6e6f is program canno
00000060: 7420 6265 2072 756e 2069 6e20 444f 5320 t be run in DOS 
00000070: 6d6f 6465 2e0d 0d0a 2400 0000 0000 0000 mode....$.......
00000080: 5045 0000 4c01 0400 3c51 0e58 0000 0000 PE..L...<Q.X....
00000090: 0000 0000 e000 0201 0b01 0800 0042 0200 .............B..

On a également la commande rtfscan ou officemalscanner qui permet de détecter et d’extraire un binaire malveillant dans un fichier type .rtf .docx .doc .ppt etc…

C:\Users\IEUser\Desktop\OfficeMalScanner>RTFScan.exe BOA.mal scan
+------------------------------------------+
| RTFScan v0.26 |
| Frank Boldewin / www.reconstructer.org |
+------------------------------------------+

[*] SCAN mode selected
[*] Opening file BOA.mal
[*] Filesize is 321636 (0x4e864) Bytes
[*] RTF format detect

Scanning for shellcode in THEMEDATA...
No shellcode found in THEMEDATA

Embedded OLE document found in DATASTORE
Scanning for shellcode in DATASTORE...

Dumping embedded OLE document as filename: OLE_DOCUMENT__BOA__1.bin
!!! OLE_DOCUMENT has been found and dumped. This should be re-scanned wi
th officemalscanner now !!!
!!! This file contains overlay data, which is unsual for legiti
mate rtf-files !!!
Analysis finished!
------------------------------------------------
BOA seems to be malicious! Malicious Index = 20
------------------------------------------------

Côté PDF, l’outil de Didier Stevens marche à merveille pour détecter du JS (hey oui Acrobat Reader embarque un moteur JS…), l’afficher puis l’extraire. La marche à suivre n’est pas beaucoup plus complexe, mais je ne le détaillerai pas ici (fera peut être l’objet d’un billet à part). Bref, vous vous retrouvez souvent avec un PE à la fin, ou du script (powershell, vbscript, js). L’identification permet parfois de retrouver le langage avec lequel le PE a été codé (voir la partie headers sur Manalyzer plus bas). En regardant .NET, Java, Python entre autre, n’hésitez pas à utiliser des outils de reverse de façon à retrouver le code source (ou quelque chose s’y approchant). Par exemple, si on ouvre malware_1.mal avec l’appli dotPeek, voici ce que l’on peut retrouver:

Structure d’un PE

Ok on a notre PE malveillant, sauf que contrairement à du script, ça ne s’ouvre pas avec une éditeur de texte… Il faut donc connaître un peu sa structure pour pouvoir lire une analyse de ce dernier. Concernant les outils à utiliser, j’utilise l’interface web Manalyzer qui a été écrit par Ivan Kwiatkowski et qui à l’avantage de regrouper un tas d’outils et d’automatiser leur utilisation. Je vous conseille d’installer l’équivalent en ligne de commande sur votre machine au cas où vous n’auriez pas de connexion internet lors d’une analyse. Un PE est divisé en plusieurs sections, qui sont nommées de façon arbitraires mais standardisées par les compilateurs. On retrouve:

• .text
• .rdata, .idata, .edata…
• .data
• .rsrc
• .reloc

Un bon réflexe est de faire attention aux noms donnés, souvent modifiés par le pirate de façon à brouiller les pistes pour l’analyste. Un PE comporte également des imports, exports et ressources:

• Imports: l’ensemble des fonctions importées par le binaire. Un programme à besoin d’un ensemble de fonctions, du simple print au malloc en passant par des appels systèmes (création de sockets etc…) et ce de façon tout à fait légitime. Cependant, pour brouiller les pistes, le pirate souhaite cacher l’utilisation de ces fonctions (si une socket est créee, on peut chercher l’ouverture d’un port sur la machine, cibler le comportement etc..). Il va alors utiliser principalement deux fonctions: ‘LoadLibrary’ et ‘GetProcAddress’ qui permettent un import manuel. Le pirate chiffrera les strings du programme au passage qui seront déchiffrées avec la clé embarquée, toujours dans l’idée de casser les pieds de l’analyste.

• Exports: l’ensemble des appels externes possibles. Ici on parle par exemple d’une .dll qui n’est pas à l’origine de l’exécution malveillante, mais qui peut tenter de remplacer une .dll légitime pour être appelée par un programme Windows légitime également. On peut par exemple retrouver ‘ServiceMain’, point d’entrée standard de la .dll. Pour l’exécuter manuellement, on peut utiliser:

  • rundll32 fichier.dll,pointd'entrée

  • Ex: rundll32 printui.dll,ServiceMain

• Ressources: les ressources concernent tous types de fichiers embarqués dans votre PE. Il s’agit par exemple de l’icône, mais il peut être question d’un deuxième EXE malveillant ‘encapsulé’ dans le PE d’origine. On peut retrouver un PDF malveillant, un script, bref tout type de fichier.

  

Manalyzer et Virus Total

Si vous avez passé un des fichier sur Manalyzer (uniquement pour les PE), par exemple malware_1.mal, vous avez toutes les infos dont on a parlé ci-dessus (sections, ressources, signature, imports etc…) et bien d’autres détails comme les headers (qui quoi quand où comment?) ou les mutex (sémaphores qui permettent de vérifier si la machine est déjà infectée, si oui alors le processus ne sera pas lancé) qui peuvent être intéressants sur une faille non patchée: vous ajouter le mutex en question ce qui vous protège du malware associé.

Vous pouvez apercevoir également un résumé Virus Total, site incontournable qui analyse de façon statique tout type de malware. Vous avez donc là des informations pivots pour faire des recherches sur vos fichiers, avec tout plein d’IoC (Indicator Of Compromise). Vous avez le choix d’uploader le fichier directement (attention aux données éventuellement sensibles!!!) ou faire une recherche par hash (généralement préférable). Gardez aussi à l’esprit que si vous êtes victime d’une attaque ciblée et que vous uploadez le payload sur Virus Total alors que celui-ci est inconnu, l’attaquant sera que vous savez… (oui Virus Total passe à la moulinette via les anti-virus les plus connues tout fichier inconnu et l’enregistre en base, alors que si le hash n’existe pas il n’y aura simplement aucun résultat).

Obfuscation

Il peut également vous arriver de tomber sur du code obfusqué, c’est à dire volontairement allourdie (noms de variables impitables, fonctions inutiles ajoutées etc…). Dans ce cas, plusieurs techniques:

• Décrypter le code à la main si vous avez le temps. Reprendre ligne par ligne ou fonction par fonction et essayer de comprendre l’objectif du bout de code.

• Utiliser des déobfuscateurs comme celui pour le javascript de façon à automatiser le processus et gagner un temps inimaginable! Petite astuce: copiez collez votre code JS dans un fichier .js. Installez Firefox + l’extension NoScript + l’extension JavaScript Déobfuscator. Ouvrez votre fichier JS, le code sera bloqué par NoScript (donc pas d’exécution malveillante) puis ouvrez le déobfuscator via les outils pour développeurs. Rechargez la page, ce qui aura pour effet de charger le JS dans l’appli toujours sans exécution malveillante. Vous pouvez également utiliser des déobfuscator online.

II/ Analyse dynamique

L’analyse statique nous permet donc de regrouper un très grand nombre d’informations, mais malheureusement, ce n’est pas toujours suffisant. Des techniques dites de packing permettent de transformer un exécutable (compressions / chiffrement) dans un autre exécutable qui sert de container. Il n’est alors -quasiment- impossible de travailler sur le code, vu que celui-ci est indéchifrable. Au lieu de se casser la tête à décoder tout ça, on va “simplement” exécuter le code malveillant, et étudier son comportement. Evidemment, VM obligatoire voir Sandbox (boîte bac à sable qui permet de segmenter un code).

Sandbox et Sandboxie sont sur un bateau…

Je vous propose l’utilisation de Sandboxie. Ne téléchargez pas la dernière version, téléchargez la 3.76 à cet endroit. Installez-le sur un Windows XP ou Windows 7 uniquement. Ces contraintes ne viennent pas de ce soft, mais de BSA. Ce dernier va travailler en parallèle avec la Sandbox. Une fois Sandboxie installé sur votre VM et le tuto du site BSA suivi, vous pouvez lancer votre malware (par exemple malware_1.mal renommé en malware_1.exe) en faisant un clic droit –> run Sandboxed. Notez le cadre jaune autour du soft indiquant une appli sandboxé. Votre appli est lancé dans un container sécurisé, bravo =) Bon fermez tout ça, maintenant on va analyser un peu le machin, car l’analyse dynamique ne se limite pas à cliquer sur des virus. Vous ouvrez BSA que vous avez configuré au préalable. Vérifiez bien que le répertoire de la sandbox indiqué correspond bien à la sandbox par défaut de Sandboxie. Vous pouvez cliquer sur “Start Analysis”. Si BSA vous demande de supprimer le contenu du répertoire, préférez confirmer l’opération pour partir sur une analyse vierge. Maintenant vous ouvez votre soft toujours sandboxé, ici malware_1.exe: Essayez de jouer avec l’application (ajoutez 400€ sur votre compte Paypal, ne renseignez pas votre vrai mail / mdp évidemment!!!).

Maintenant vous pouvez fermer l’appli sandboxé puis stopper l’analyse. Ouvrez “Analysis” dans l’onglet “Viewer”. Un résumé du comportement est affiché, youhou =) Vous pouvez également voir plus de détails par exemple les connections ouvertes ou encore les fichiers crées au sein de la sandbox. Pensez aussi à regarder les clés de registres, que vous pouvez retrouvez avec l’explorateur “regedit”, et surveillez les clés qui ajoutent un lancement au démarrage du type:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

Who watches the watchers? Détection d’un poste d’analyste

Dans la capture d’écran ci-dessus, notez les deux lignes surlignées: un malware peut vérifier, du moins essayer, l’utilisation d’un debugger, d’un environnement virtualisé, d’un anti-virus ou l’utilisation d’une sandbox via les moyens suivants:

• Présence d’un debugger via l’API Windows
  • IsDebuggerPresent() retourne 0 si aucun débugger n’est présent (recherche de la variable isDebugged dans le Process Environment Block)
  • checkRemoteDebuggerPresent() fait de même mais en vérifiant sur tous les processus lancés
  • NTQuerryInformationProcess vérifie la valeur du port ProcessDebugPort
  • Vérifier la valeur de outputDebugString()
• Présence d’un environnement spécifique
  • Nom des fenêtres ouvertes (ollyDBG ou tout autre soft qui n’est utilisé que par des analystes)
  • Clés de registres pour les programmes installés
  • L’adresse du premier tas du process (ProcessHeap)
  • Le temps passé depuis le démarrage de la machine avec getTickCount() sur Windows ou uptime sur Unix (si temps très court: probablement lancé via une sandbox)
  • Vérification des dossiers dans C:/Programs (présence des VirtualTools etc…)
  • Présence d’un anti-virus dans C:/Programs etc…

Si c’est le cas avec votre échantillon, il faudra repérer le ou les tests et faire en sorte qu’ils sautent (par exemple en désinstallant l’anti-virus, en installant les VirutalTools sur un autre emplacement / disque etc…).

Analyse directement depuis la machine virtuelle

La méthode Sandboxie + BSA est très efficace, mais parfois insuffisante. Par exemple si l’on veut récupérer des informations sur un ransomware ou encore sur le comportement à long terme d’un trojan. On va donc les lancer directement depuis une VM clean, à laquelle on aura pris soin d’effectuer un snapshot avant toute manipulation! Une fois le tout préparé, et bien on double-click sur notre PE, ou tout autre machin infecté… On va utiliser plusieurs outils pour analyser les modifications en temps réel sur le système. Attention il faudra certainnement restaurer le snapshot plusieurs fois pour analyser les tous premiers comportements du malware, qui peuvent avoir une grande importance. Donc comme vu plus haut, on analyse les fichiers et dossiers crées, on surveille le registre mais on vérifie également les processus lancés (avec procexp de la suite SysInternalSuite), les ports ouverts avec un bon vieux netstat et on lance en parallèle une capture réseau avec Wireshark. Il y a bien d’autres moyens et outils, mais c’est une bonne base pour soulever quelque chose de louche.

Si vous avez fait une analyse statique correcte du malware_2.mal (renommé en malware_2.js), vous n’apprendrez pas grand chose de plus sur son comportement, mais vous pouvez relever les processus utilisés et récupérer des informations sur la méthode de rançon (c’est un cryptolocker nommé locky). Dans le cas contraire, vous aurez la surprise de tomber là dessus:

Pour aller plus loin

Aller plus loin dans l’analyse dynamique, c’est peut être désassembler votre échantillon avec IDA Pro sur Windows et essayer de comprendre le comportement global. Je ne vous ferai pas de cours sur l’assembleur, cette représentation du langage machine ‘lisible’ par un humain car ce serait bien trop long et je n’ai ni les compétences ni la pédagogie pour cela. J’ai bien précisé ‘global’, ne perdez pas de temps sur ce qui n’en vaut pas la peine. IDA a l’avantage d’être ergonomique et de vous simplifier le travail, utilisez donc les fonctions de recherche de strings pour retrouver un bout du programme intéressant avec un message que vous avez pu relever lors de son exécution. Renommez les variables pour clarifier le tout, utilisez la vue par arborescence pour visualiser un ensemble de conditions, n’hésitez pas à descendre ou remonter un jump, bref fouiner un peu dans le code. Mais il est aussi possible d’utiliser un debugger comme OllyDBG sur Windows ou EDB sur Linux: une fois que vous avez compris tout ou partie du code asm de votre échantillon, vous pouvez essayer de jouer avec en regardant ce qui est mis sur la pile ou sur le tas, ce qu’il se passe si on saute une instruction, qu’on modifie une adresse pour arriver là où l’on souhaite… et abusez des breakpoints, et soyez attentifs à tout ce qui se passe lors de l’exécution du programme.

Conclusion

L’analyse de malware est un monde à part entière, vaste et complexe. Plus on apprend, et plus l’on comprend qu’on ne sait rien… J’espère tout de même vous avoir donné les bases et la compréhension minimum pour vous permettre de débuter dans ce domaine ou d’avancer dans un autre tout en ayant une meilleure compréhension gloable =)