Die Zahl an Malware, die es auf die Zugangsdaten von Onlinebanking-Kunden abgesehen hat, ist in der Vergangenheit stark angestiegen. Zu diesen schädlichen Codes gehört auch Emotet, eine gefährliche Malware, über die wir bereits Anfang des Jahres berichtet haben. ESET erkennt die Bedrohung unter der Signatur Win32/Emotet.AB.
Die Malware verbreitet sich über gefälschte E-Mails und betrifft hauptsächlich Nutzer in Europa – ganz besonders in Deutschland. Aus unserer Analyse geht allerdings hervor, dass der schädliche Code über lateinamerikanische URLs verbreitet wird. In diesem Artikel werden wir euch erklären, wie die Payload der Bedrohung extrahiert wird.
Laut ESETs Frühwarnsystem war Win32/Emotet.AB im November 2014 besonders aktiv. Die folgende Grafik zeigt, dass jede fünfte Malware-Erkennung in diesem Monat deutsche Nutzer betraf:
Anhand der URLs, die für die Verbreitung der Malware genutzt wurden, konnten wir die Namen der Dateien herausfinden, die im Zuge der Angriffe am häufigsten als Köderdokumente auftauchten:
- rechnung_11_2014_3280000236_telekom_de.zip
- rechnung_11_2014_vodafone_team.zip
- volksbank_de_transaktions_id_000023928001_2014_11.zip
- de_rechnung.zip
- ihre_telekom_mobilfunk_december_2014.zip
- 1 & 1_2014_11rechnung_onlinerechnung.zip
- 2014_11vodafone_onlinerechnung.zip
- ihre_telekom_mobilfunk_november_2014.zip
- 2014_11_rechnung_1_1_000309399002.zip
- zahlung_in_auftrag_2014_12.zip
ESETs Analyse- und Forschungszentrum in Lateinamerika konnte über 200 Kampagnen entdecken, die über 125 verschiedene Domains und 169 URLs verbreitet wurden. Die meisten URLs gehörten zu Brasilien, Chile und Mexiko.
Im Zuge einer dynamischen Analyse haben wir herausgefunden, dass die Malware Dateien und Prozesse erstellt und Registry Keys verändert.
Mit bestimmten Tools haben wir uns die Pfade für die ausführbaren Dateien anzeigen lassen, die von der Malware erstellt werden. In den entsprechenden Verzeichnissen waren sie allerdings nicht zu sehen.
Deshalb sind wir einen Schritt weiter gegangen und haben die Samples mit einem Debugger und einem Disassembler analysiert. Dabei mussten wir die Analyse allerdings beenden, bevor die Datei vollständig ausgeführt werden konnte.
Dafür haben wir den Immunity Debugger genutzt und bei bestimmten Funktionsaufrufen der Windows API Breakpoints gesetzt, z.B. bei OpenProcess, CreateProcessW, WriteProcessMemory, CreateRemoteThread und ResumeThread. Dann haben wir die Ausführung des Codes gestartet:
Bei der ersten Markierung, der OpenProcess-Funktion, wird die Ausführung gestoppt. Diese Funktion startet einen Prozess mit der ID C54 (Heximaldezimal), welche einem Dezimalwert von 3156 entspricht.
Wir fahren mit der Ausführung des Codes fort, bis wir den nächsten Breakpoint erreichen, der den Start der CreateProcessW-Funktion anzeigt. Diese Funktion wird häufig von Malware ausgenutzt, weil sie, wie der Name schon sagt, einen neuen Prozess erstellt. In unserem Fall wird ein anderer Prozess mit der gleichen ausführbaren Datei erstellt, allerdings befindet sie sich im Suspended Mode:
Beim nächsten Breakpoint erhalten wir durch die WriteProcessMemory-Funktion Informationen über die Prozess-ID (6C), den Puffer, aus dem gelesen wird (013E0000) und die ersten Bytes, die geschrieben werden sollen (400 in Hexadezimal, 1024 in Bytes).
Wie weiter oben erwähnt, konnten wir die Prozesse und Dateien, die die Malware erstellt hat, zunächst nicht sehen. Nun können wir sie sichtbar machen. An dieser Stelle müssen wir die Ausführung des Codes allerdings abbrechen, weil der Prozess ansonsten beendet wird und die Daten dann verloren gehen. Der wichtige Teil ist an dieser Stelle die Adresse des Puffers: 013E0000.
Die Bedrohung hat daneben allerdings auch andere Dateien, wie z.B. eine „.bat“-Datei, erstellt. Wir erstellen einen Speicherauszug, um die Dateien zu finden, die wir zu Beginn der dynamischen Analyse nicht sehen konnten.
Dafür nutzen wir ein Tool namens LordPE Deluxe. In dem Haupt-Programmfenster suchen wir nach der Bedrohung, führen auf ihr einen Rechtsklick aus und wählen „dump region…“:
In dem neuen Fenster suchen wir dann nach der Adresse des Puffers, die wir bei der Ausführung des Schadcodes erhalten haben: 013E0000. Wir wählen diesen Wert aus und klicken dann auf „Dump“. Die Datei, die hierdurch erstellt wird, speichern wir irgendwo auf unserem Computer ab – so steht sie für spätere Analysen bereit.
Diese Datei trägt die Endung „.dmp“. Wenn wir sie zu „.exe“ ändern, erhalten wir die tatsächliche Bedrohung Win32/Emotet.AB.
Fazit
In dem ersten Teil unserer Analyse haben wir herausgefunden, dass in der ursprünglichen Datei nicht nur eine Bedrohung eingebettet ist, sondern auch eine zweite, die ESET als Win32/ServStar.AD erkennt.
Wir können vermuten, dass der Angreifer bemüht war, eine Art Dropper zu erstellen, um den wirklich schädlichen Code zu verstecken und dadurch einer Erkennung zu entgehen. In diesem Artikel haben wir gezeigt, wie man die Payload von Emotet extrahieren kann. In zukünftigen Analysen werden wir dann genaueres über die Mechanismen und die Kommunikation zwischen der Malware und dem Command & Control Center erklären.
Picture Credits: ©Stephen Coles/Flickr
