Guillaume Orlando

Sommaire

• Introduction
• Reconnaissance
• Overview
• Analyse
  • A) Mutex
  • B) Injection sous iexplorer.exe
  • C) Persistance
  • D) Options de sécurité IE
  • E) Keylogger SecureDLL.dll
  • F) Memory harvester
  • G) Exfiltration de données
  • H) Serveur de contrôle
• Indicateurs d’infection

Introduction

Le sample analysé est le suivant:

140d24af0c2b3a18529df12dfbc5f6de

Celui-ci est téléchargeable sur la plateforme Malshare

Attention, bien que le sample ne soit pas tout jeune, celui-ci reste très agressif et capable de causer des dégâts à votre machine ou à vos données. Merci d’uniquement ouvrir le fichier dans un environnement contrôlé.

Reconnaissance

• Le scan VirusTotal du fichier confirme dans un premier temps le caractère malicieux du fichier : En croisant les appellations données par les différents antivirus du marché, il semblerait que le malware appartienne à la famille “Dexter” ou “Poxters”. Il s’agit dans les deux cas d’un banker/POS. L’analyse complète du binaire permettra de le catégoriser correctement par la suite.

• Au vu des différentes chaines de caractères observables dans l’exécutable, celui-ci ne semble pas packé. L’utilitaire DIE ne détecte pas de signature de packers connus, et confirme le fait que le fichier soit bien l’actuel payload. En revanche, le graphe d’entropie met en évidence le fait qu’une des sections du fichier possède une entropie particulièrement élevée: Pour déterminer la source de cet entropie anormalement élevée dans un fichier brute, l’ouverture du fichier dans un éditeur héxadécimal permet de voir qu’un second préfixe PE est présent au sein du fichier, mais que celui-ci semble obfusqué ou chiffré d’une certaine manière: Le malware risque donc d’extraire un autre exécutable de lui-même à un certain moment.

• Dans un second temps, la liste des imports permet d’observer les fonctionnalités globales du malware sans rentrer dans le détail du fonctionnement de celui-ci. La présence de nombreuses fonctions de manipulation mémoire (OpenProcess, CreateRemoteThread, VirtualAlloc ou encore HeapAlloc) pourraient être le signe d’une injection en mémoire ou d’une manipulation de processus.

Au travers de la bibliothèque WININET.dll et URLMON.dll et via les fonctions HttpSendRequest, InternetOpen, InternetGetCookie, InternetOpenUrl ou encore InternetReadFile et ObtainUserAgentString, le malware va pouvoir interagir avec un serveur distant, télécharger des ressources additionnelles, ou même interroger les navigateurs internet de la machine infectée.

Outre les manipulations de clés de registre ou de fichiers sur le système, cette liste reste non-exhaustive, et permet uniquement d’anticiper le comportement du binaire avant de l’analyser proprement.

• Pour terminer cette première phase de reconnaissance, les chaînes de caractères du binaire sont extraites. Puisque celles-ci ne sont pas obfusquées, et en les couplant avec les imports, de précieuses informations peuvent être extraites.

‣ La présence du chemin vers la clé de registre “Software\Microsoft\Windows\CurrentVersion\Run” met potentiellement en évidence une technique de persistance adoptée par le malware.

‣ L’adresse IP 151.248.115.107 et l’URL /w19218317418621031041543/gateway.php pourraient servir de serveur de contrôle pour le malware, ou d’un point de téléchargement de composants additionnels.

‣ Un header HTTP est présent :

Mozilla/4.0(compatible; MSIE 7.0b; Windows NT 6.0)
POST
Content-Type:application/x-www-form-urlencoded

Ceci confirme bien le fait que le malware va communiquer avec l’extérieur à un certain moment.

‣ Enfin de nombreuses références à une application Java sont faites, mêmes si elles n’ont aucune signification pour le moment :

Java Security Plugin
%s\%s
javaplugin
Java Security Plugin
%s\%s\%s.exe
Sun Java Security Plugin

Overview

Analyse

L’analyse complète va permettre de détailler chronologiquement et en en profondeur toutes les actions et procédures employés par le malware.

A) Mutex

L’exécutable commence sa routine par créer un nouveau Mutex, au nom de “WindowsServiceStabilityMutex”:

B) Injection sous iexplorer.exe

L’exécutable Internet Explorer est dynamiquement localisé sur la machine, avant d’être lancé et mis en pause : Le malware va ainsi pouvoir s’injecter dans un processus enfant d’Internet Explorer pour poursuivre ses actions malveillantes avec plus de discrétion. Les requêtes HTTP auront l’air plus légitimes par la suite si elles sont émises depuis un navigateur:

C) Persistance

Le malware va ensuite se copier dans l’exécutable “javaplugin.exe” fraichement créé pour l’occasion, sous “AppData\Roaming” : Ensuite, la clé de registre liée au démarrage des programmes sur la machine est modifiée, sous “SOFTWARE\Microsoft\Windows\CurrentVersion\Run”. Via cette clé de registre, le malware est certain de démarrer en même temps que la machine infectée : La technique est classique et très sommaire, mais mise sur la légitimité d’un programme se faisant passer pour un plugin de sécurité Java. Ce genre de nom sert à décourager les utilisateurs non-avertis de retirer ce programme de la liste des démarrage automatique.

Le malware va également supprimer l’exécutable depuis lequel il a été lancé dans cette section du code. Attention donc à en garder une copie dans le cadre d’une analyse.

A la fin de cette routine de persistance, un UUID est attribué à chaque machines infectés. Dans mon cas, il s’agit de l’UUID suivant : Ma machine sera désignée par cette chaine de caractère lors de l’exfiltration de données. Cette valeur est stockée dans une clé de registre sous SOFTWARE\HelperSolution Software, sous le nom de “Digit”: A noter que cet UUID n’identifie pas réellement la machine de manière unique. Chaque instance du malware génèrera un nouvel UUID qui n’est pas rattachable à la machine depuis laquelle l’UID à été généré (selon la documentation de la fonction UuidCreate). Ce n’est donc pas un mutex que l’opérateur du malware pourra utiliser pour identifier de manière unique une machine, mais uniquement un identifiant temporaire.

D) Options de sécurité IE

Afin de changer les options de sécurité de navigateur Internet Explorer, certaines clés de registre vont êtres modifiées. La première modification de clé permet d’indiquer si un message d’avertissement doit être affichée par le navigateur quand une action malveillante est détectée. Cette fonction est désactivée par le malware: Ensuite, la clé définissant les extensions de fichier ne présentants pas de risques au téléchargement est modifiée, de façon à inclure les fichier en “.exe”, “.bat”, “.reg” et “.vbs”: Le programme prépare ici le terrain pour télécharger et exécuter des fichiers additionnels depuis le navigateur.

E) Keylogger SecureDLL.dll

Un DLL, au nom de “SecureDLL.dll” est crée sur le bureau, en tant que fichier cachée : Le contenu du DLL est copié dans le fichier, avant d’être chargé en mémoire. La haute entropie d’une zone d’une des sections est en fait lié à la présence du contenu chiffré de ce DLL dans le binaire d’origine. A noter que l’auteur du malware à pensé à obfusquer le call de la fonction RtlDecompressBuffer lors de la copie du contenu mémoire du dll vers le fichier, de façon à rendre moins évidente l’interception du dit dll: Au final, il est plus simple d’attendre que le dll soit écrit sur le système, avant d’en récupérer une copie. Le hash du dll extrait est

“b5f429729f6ba45df4fc03b7b07a1fb8”.

Malgré son nom, fichier semble bel et bien dangereux: SecureDLL.dll est en fait le module servant de keylogger pour le malware Dexter. Le fonctionnement est classique, et le dump des touches est fait sous le fichier temporaire “strokes.log”.

Par la suite, un second fichiers temporaires “tmp.log” est initialisé: Le chemin de ces deux fichiers est ancré dans une clé de registre, déguisée en clé légitime sous le nom de “HelperSolution Software”. De cette façon, les autres modules du malware vont pouvoir interagir avec ces fichiers en récupérant dynamiquement ce path servant de point de rassemblement des données à exfiltrer. Finalement, un hook est fait via la fonction SetWindowsHookExA, de façon à passer l’état du clavier à une fonction du dll malicieux (le keylogger).

F) Memory harvester

Une fois avoir droppé et lancé le fichier SecureDLL.dll, le malware va récupérer une copie de tous les processus lancés, ainsi que de leurs espaces mémoires et de leurs processus enfants, avec la fonction CreateToolhelp32Snapshot (IDA Pro risque de ne pas aimer et de crasher à la suite de cette instruction). Les processus sont ensuites triés. Une liste de processus ne pouvant contenir des informations bancaires est hardcodée dans le binaire, de façon à les exclure de la recherches, et ne pas perdre de temps.

Les processus blacklistés sont les suivants: Ensuite, le malware lance plusieurs threads à la suite: Un premier thread responsable de prendre des snapshot des processus toutes les X secondes est lancé:

Un deuxième thread servant de mécanisme de protection de la persistance est créé à la suite. Celui-ci vérifie que la clé de registre de persistance du malware ne soit pas modifiée. Si c’est le cas, il la remplace avec la valeur permettant au malware de démarrer avec la machine infectée:

Un autre thread est créé, de façon à détecter si la machine cherche à être éteinte (DetectShutdownClass). Enfin, un dernier thread est créé, de façon à maintenir l’injection en mémoire du malware dans un processus Internet Explorer, même lorsque ce processus est manuellement fermé.

Ces quatres thread rendent le malware particulièrement agressif et résilient.

Pour récupérer des informations bancaire, le malware parcours les processus à la recherche des chaînes “%B” et “^”, qui servent respectivement de préfixe et de délimiteur aux données contenu dans les bandes magnétiques des cartes bancaires.

De cette façon, le programme utilise sa propre regex pour trouver des informations en mémoire, à la différences d’autres bankers, qui utilisent presques tous des règles yara. La recherche est ainsi affiné, mais de nombreux faux-positifs sont susceptibles d’apparaître.

Quand de telles informations sont trouvées, celles ci sont extraites dans les fichiers temporaires, avant d’être envoyés au serveur de contrôle.

G) Exfiltration de données

Afin d’exfiltrer les données volées, le malware va contacter un serveur de contrôle hardcodé dans sa configuration, via une requête HTTP.

L’interception d’une de ces requêtes donne le résultat suivant : La routine d’exfiltration du malware est une fonction composée de plusieurs étapes linéaires consécutives: Une requêtes HTTP POST est donc initiée en direction de l’adresse du serveur de contrôle (151.248.115.107) sur le port 80 :

Au préalable, un user-agent mozilla 4.0 est placé en mémoire, pour le header de la future requête web: Ensuite, une phase de collecte d’informations est faite de manière méthodique.

Dans un premier temps, c’est le nom d’utilisateur de la session qui est extrait : Suivi du nom de la machine: Ensuite, l’architecture de la machine est récupérée: La version Windows est elle aussi extraite, au moyen de la fonction GetVersionExA, GetSystemInfo et GetSystemNativeInfo de Kernel32.dll: Puis, une comparaison est effectuée sur le résultats des commandes pour tomber dans les cas de figures suivants: Le graphe de la fonction illustre bien le comportement (récolte d’informations dans les premiers blocs, puis comparaison des résultats avec des paternes indiquant la version de Windows) : Les fichiers debug.log et tmp.log sont ensuite créés à l’emplacement depuis lequel le malware est lancé.

Le malware va ensuite charger en mémoire le contenu du fichier debug.log, puis le parser, de façon à former une requête HTTP pouvant contenir les arguments suivants: Les informations sont chiffrées avec une simple clé XOR (6 caractères alphanumériques en minuscules et majuscules), avant d’êtres concaténées, et envoyées au serveur de contrôle.

H) Serveur de contrôle

Malheureusement, le serveur de contrôle (151.248.115.107) du malware correspondant à ce sample n’existe plus, et celui-ci pointe désormais sur une plateforme d’hébergement de serveurs russes.

En se renseignant sur le passif de cette adresse, le caractère malicieux de celle-ci ne fait aucuns doutes: Les différentes pages “gateway.php” sont ce qui semble être des interfaces de contrôle du malware. Enfin, il est possible de confirmer le fait que ce serveur est bien celui d’où provient spécifiquement le binaire analysé: Cette adresse IP semble aussi avoir servi de serveur de contrôle pour les binaires aux hashs suivants:

e1f07bef2bf727d9f6be772bfcbf629e 2017-04-20 01:47:22 140d24af0c2b3a18529df12dfbc5f6de 2016-11-04 23:26:16 215d113ceb0df7ac7f6edfd080f15dd7 2017-04-20 01:39:40

(D’après Threatminer)

Indicateurs d’infection

Hash du binaire (Win33.exe) : 140d24af0c2b3a18529df12dfbc5f6de
Hash du module Keylogger (SecureDLL.dll) : b5f429729f6ba45df4fc03b7b07a1fb8
Serveur de contrôle : 151.248.115.107
Clé de registre : Software\Microsoft\Windows\CurrentVersion\Run\SunJavaSecurityPlugin
Clé de registre : Software\HelperSolutions Software\val1
Clé de registre : Software\HelperSolutions Software\val2
Clé de registre : Software\HelperSolutions Software\Digit
Fichier système : C:\Users\HomardBoy\AppData\Roaming\Java Security plugin\javaplugin.exe

Yara rule:

1
2
3
4
5
6
7
8
9
10
11
12
rule DexterPOS
{
     meta:
          Author = “HomardBoy”
          description = “Dexter Point Of Sale Malware, StarDust version”
          sample = “140d24af0c2b3a18529df12dfbc5f6de”
     strings:
          $path = “/gateway.php”
          $version = “StarDust”
          $java = “Java Security Plugin”
          $UserAgnet = “Mozilla/4.0(compatible; MSIE 7.0b; Windows NT 6.0)”
}

Snort rule: