Banker Emotet: Evolution einer Bedrohung

Inhalt

Im Sommer 2014 berichtete das Unternehmen Trend Micro von der Entdeckung einer neuen Bedrohung, dem Bank-Trojaner Emotet. In der Beschreibung hieß es, dass der Schädling Bankkontodaten der Anwender stiehlt, indem er den Traffic abfängt. Im Folgenden werden wir diese Modifikation Version 1 nennen.

Im Herbst desselben Jahres entdeckten wir eine neue Version von Emotet, die aufgrund der folgenden Fakten unsere Aufmerksamkeit auf sich zog:

  • Die Entwickler des Trojaners wandten nun eine Technik zum Stehlen des Geldes von den Bankkonten ihrer Opfer an, die im russischen Cybercrime-Slang auch als „avtozaliv“ bekannt ist.
  • Der Trojaner nutzte eine modulare Struktur, zu der auch ein eigenes Installationsmodul gehörte, sowie ein Banker-Modul, ein Spambot-Modul, ein Modul zum Stehlen von Adressbüchern aus MS Outlook und ein Modul, das für die Organisation von DDoS-Attacken vorgesehen ist (Nitol DDoS bot).
  • Die Entwickler des Trojaners haben sich große Mühe gegeben um unentdeckt zu bleiben: Sie griffen bewusst keine Anwender in der Domain-Zone .ru an. Die Attacken richteten sich gegen eine kleine Zahl deutscher und österreichischer Banken (andere bekannte trojanische Banker stechen nicht durch derartige Selektivität hervor), die Domainnamen der ‚avtozaliv‘-Server des Trojaners wurden häufig verändert (mindestens einmal, meist aber mehrmals innerhalb von 24 Stunden).

Im Folgenden werden wir diese Modifikation Emotet Version 2 nennen (der Bot enthält und übermittelt an das C&C die Zahlen 1 und 7, was allem Anschein nach bedeutet, dass der Autor des Trojaners diese Variante als Version 1.7 betrachtet).

Beide Versionen des Trojaners griffen Kunden deutscher und österreichischer Banken an.

Wir haben die Version 2 von Emotet sorgfältig beobachtet, allerdings stellte sie im Dezember 2014 ihre Aktivität ein. Die Steuerungsserver antworteten den infizierten Computern nun nicht mehr. Der letzte Befehl, der von den Steuerungszentren ausgegeben wurde, registrierten wir am 10.12.2014 um 09:33:43 Mitteleuropäischer Zeit. Wir haben die Version 2 von Emotet sorgfältig beobachtet, allerdings stellte sie im Dezember 2014 ihre Aktivität ein. Die Steuerungsserver antworteten den infizierten Computern nun nicht mehr. Der letzte Befehl, der von den Steuerungszentren ausgegeben wurde, registrierten wir am 10.12.2014 um 09:33:43 Mitteleuropäischer Zeit.

Die Tatsache, dass die Autoren die Entwicklung des Trojaners derart ernsthaft betrieben haben, sowie der hohe Automatisierungsgrad der Funktionen des Schädlings ließen allerdings keinerlei Zweifel daran, dass das noch nicht das Ende war. Und so kam es auch – nach einer kurzen Pause im Januar 2015 erschien Emotet erneut auf der Bildfläche. In unserem Bericht werden wir diese Modifikation im Folgenden Version 3 nennen (der Bot enthält und übermittelt die Zahlen 1 und 16 an das C&C, was offensichtlich bedeutet, dass der Autor des Trojaners diese Variante als Version Nummer 1.16 bezeichnet).

Im Grunde genommen unterscheidet sich Emotet Version 3 nicht allzu stark von der Version 2 – die wichtigsten Neuheiten zielen darauf ab, den Trojaner noch besser zu verbergen. Unter den von uns identifizierten Neuerungen sind die folgenden besonders erwähnenswert:

  • Der Trojaner hat einen neuen integrierten öffentlichen RSA-Schlüssel, und obgleich die Kommunikationsprotokolle mit den Steuerungszentren von Emotet der Versionen 2 und 3 identisch sind, so gibt es bei der Verwendung des alten Schlüssels keine korrekte Antwort vom Steuerungszentrum.
  • Die „avtozaliv“-Skripte werden häufig von Debugging-Informationen und Kommentaren gereinigt.
  • Neue Ziele! Emotet hat es jetzt auch auf Kunden von Schweizer Banken abgesehen.
  • Die Technologie zum Einschleusen von Code in den Adressraum von explorer.exe hat sich leicht geändert. Die Version 2 wandte ein klassisches Schema zum Einschleusen von Code an: OpenProcess+WriteProcessMemory+CreateRemoteThread. Die Version 3 verwendet nur zwei der drei oben aufgeführten Schritte, und zwar OpenProcess+WriteProcessMemory. Die Ausführung des eingeschleusten Codes wird mit Hilfe einer Modifikation des Codes der Funktion ZwClose im Adressraum des Prozesses explorer.exe gewährleistet, was ebenfalls mit Hilfe von WriteProcessMemory erreicht wird.
  • Emotet Version 3 widersetzt sich einer Untersuchung: Wenn der Trojaner erkennt, dass er auf einer virtuellen Maschine ausgeführt wird, funktioniert er wie immer, aber er verwendet eine andere Adressliste für die Steuerungsserver (C&C). Allerdings sind diese Adressen alle gefälscht und sollen lediglich die Forscher in die Irre führen.
  • Der Trojaner enthält fast keine Textzeilen: Alle Zeilen, die AV-Forscher aufmerksam machen könnten, sind mit Hilfe von RC4 verschlüsselt und werden in einem isolierten Speicher direkt vor ihrer Verwendung dechiffriert und nach Gebrauch zerstört.

Insgesamt gewannen wir den Eindruck, dass mit Hilfe der Version 2 die wichtigsten Technologien, die der Banker verwendet, unter „Kampfbedingungen“ erprobt wurden und auf der Grundlage dieser Version die Version 3 geschrieben wurde, die sich durch einen höheren Grad der Verborgenheit unterscheidet.

Die Produkte von Kaspersky Lab detektieren den hier zu untersuchenden Trojaner unabhängig von der Version als Trojan-Banker.Win32.Emotet. Darüber hinaus detektieren wir einzelne Komponenten von Emotet:

  • Das Modul zur Modifizierung des HTTP(S)-Traffics – Trojan-Banker.Win32.Emotet.
  • Das Spam-Modul Trojan.Win32.Emospam.
  • Das Modul zum Sammeln von E-Mail-Adressen – Trojan.Win32.Emograbber.
  • Das Modul zum Stehlen von E-Mail-Accounts – Trojan-PSW.Win32.Emostealer.
  • Das Modul für die Organisation von DDoS-Attacken – Trojan.Win32.ServStart.

In Bezug auf das letzte Modul weisen wir auf Folgendes hin: Dieses Modul haben wir auch schon im Zusammenhang mit anderer Schadsoftware gesehen. Wir nehmen an, dass es Emotet mit einem Crypter hinzugefügt wird. Es ist durchaus möglich, dass die Autoren von Emotet gar nicht wissen, dass dieses Modul ein Bestandteil ihrer Malware ist. Wie auch immer, die Steuerungszentren dieses Moduls antworten nicht und das Modul wird nicht aktualisiert (Erstellungsdatum ist der 19. Oktober 2014).

Infektion

Heute wissen wir, dass der Trojaner Emotet ausschließlich über Spam-Mails mit schädlichen Anhängen und schädlichen Links verbreitet wird.

Bei den angehängten Dateien handelt es sich um gewöhnliche ZIP-Archive, in denen sich der Emotet-Downloader befindet. Die Dateien in den Archiven haben lange Namen, wie z.B. rechnung_november_2014_0003900028_2014_11_0029302375471_03_444_0039938289.exe. Das ist kein Zufall: Ein Anwender, der das Archiv im Windows Explorer geöffnet hat, kann die Erweiterung .exe nicht sehen, da der überschüssige Teil des Dateinamens nicht angezeigt werden kann. Manchmal fehlt ein Anhang, dafür enthält der Text einen Link auf eine schädliche ausführbare Datei oder ein Archiv.

Unten stehend einige Beispiele für Mails, die zur Verbreitung des Trojaners Emotet verwendet werden.

Version 2 (Link auf den Schädling):

Version 2 (angehängtes Archiv):

Version 3 (Link auf den Schädling):

Die Mails, die wir gefunden haben, kopieren fast perfekt Mitteilungen großer Unternehmen – der Deutschen Telekom AG oder der DHL International GmbH. Selbst die in den Mails enthaltenen Abbildungen werden von den offiziellen Servern telekom.de und dhl.com geladen.

In dem Fall, in dem ein Schreiben einen Link auf eine schädliche Datei enthielt, wurde diese von den Adressen gehackter legitimer Sites geladen:
hxxp://*******/82nBRaLiv (für Version 2)
oder von den Adressen
hxxp://*******/dhl_paket_de_DE und hxxp://*******/dhl_paket_de_DE (für Version 3).

In Emotet Version 3 wurde dem Anwender bei dem Aufruf von Adressen nach Art von hxxp://*/dhl_paket_de_DE ein ZIP-Archiv von einer solchen Adresse geliefert:
hxxp://*/dhl_paket_de_DE/dhl_paket_de_DE_26401756290104624513.zip.
Das Archiv enthielt eine EXE-Datei mit langem Namen (um die Erweiterung zu verbergen) und das Icon eines PDF-Dokuments.

Laden des Trojaners

Die Datei des Trojaners ist mit einer Verschlüsselungssoftware gepackt, deren Zweck es ist, die Erkennung durch Antivirenprodukte zu verhindern. Nach dem Start der Verschlüsselungssoftware erhält das Hauptmodul von Emotet – der Downloader – die Kontrolle. Er soll sich im System festsetzen, sich mit dem Steuerungsserver verbinden und zusätzliche Module laden und ausführen.

Das Festsetzen im System wird auf recht gewöhnliche Art umgesetzt – Emotet Version 2 speichert sich in “%APPDATA%Identities” mit einem zufälligen Namen aus 8 Zeichen (beispielsweise – wlyqvago.exe), fügt sich selbst dem Autostart hinzu (HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionRun) und löscht seine ursprüngliche Datei mittels Start einer bat-Datei, die in %APPDATA% mit dem Namen “ms[7_zufällige_Ziffern].bat” erstellt wird.

Emotet Version 3 speichert sich in “%APPDATA%Microsoft“ mit einem Namen des Formats “msdb%x.exe” (beispielsweise – C:Documents and SettingsAdministratorApplication DataMicrosoftmsdbfe1b033.exe), fügt sich in dem Autostart hinzu (HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionRun) und löscht sich mittels Start einer bat-Datei (die in „%APPDATA%del%x.bat” erstellt wird).

Nachdem der Schädling sich im System eingenistet hat, erhält Emotet eine Liste mit den Namen aller im System gestarteten Prozesse und errechnet/liest die Hash-Funktion aus den Namen jedes Prozesses und vergleicht den erhaltenen Wert mit dem hart codierten Wert 0xB316A779 – diese Hash entspricht dem Namen des Prozesses explorer.exe. Auf diese Weise findet Emotet den Prozess zum Einschleusen seines Körpers. Im Folgenden entpackt der Trojaner seinen Hauptkörper und schleust ihn in den Prozess explorer.exe ein.

Kommunikation mit dem Steuerungszentrum

Das Hauptmodul des Trojaners, der Downloader, realisiert die Kommunikation mit dem C&C unter Verwendung der RC4-Verschlüsselung.

Der Port, an den sich der Downloader richtet, ist hart codiert: 8080.

Adressen der Steuerungszentren

Die IP-Adressen der Steuerungsserver von Emotet sind im Code des Bots festgeschrieben. Davon gibt es mehrere – in einem der von uns untersuchten Samples der Version 2 waren es 30 (erwähnenswert ist, dass 3 Adressen aus der unten aufgeführten Liste zu populären legitimen Ressourcen gehören):

hxxp://109.123.78.10
hxxp://66.54.51.172
hxxp://108.161.128.103
hxxp://195.210.29.237
hxxp://5.35.249.46
hxxp://5.159.57.195
hxxp://206.210.70.175
hxxp://88.80.187.139
hxxp://188.93.174.136
hxxp://130.133.3.7
hxxp://162.144.79.192
hxxp://79.110.90.207
hxxp://72.18.204.17
hxxp://212.129.13.110
hxxp://66.228.61.248
hxxp://193.171.152.53
hxxp://129.187.254.237
hxxp://178.248.200.118
hxxp://133.242.19.182
hxxp://195.154.243.237
hxxp://80.237.133.77
hxxp://158.255.238.163
hxxp://91.198.174.192
hxxp://46.105.236.18
hxxp://205.186.139.105
hxxp://72.10.49.117
hxxp://133.242.54.221
hxxp://198.1.66.98
hxxp://148.251.11.107
hxxp://213.208.154.110

In dem von uns untersuchten Sample der Version 3 fanden wir 19 Steuerungszentren:

hxxp://192.163.245.236
hxxp://88.80.189.50
hxxp://185.46.55.88
hxxp://173.255.248.34
hxxp://104.219.55.50
hxxp://200.159.128.19
hxxp://198.23.78.98
hxxp://70.32.92.133
hxxp://192.163.253.154
hxxp://192.138.21.214
hxxp://106.187.103.213
hxxp://162.144.80.214
hxxp://128.199.214.100
hxxp://69.167.152.111
hxxp://46.214.107.142
hxxp://195.154.176.172
hxxp://106.186.17.24
hxxp://74.207.247.144
hxxp://209.250.6.60

Kommunikation mit dem C&C beim Start auf einer virtuellen Maschine

Emotet Version 3 enthält noch eine weitere Liste mit Adressen von „Steuerungszentren“, die folgendermaßen aussieht:

hxxp://142.34.138.90
hxxp://74.217.254.29
hxxp://212.48.85.224
hxxp://167.216.129.13
hxxp://91.194.151.38
hxxp://162.42.207.58
hxxp://104.28.17.67
hxxp://8.247.6.134
hxxp://5.9.189.24
hxxp://78.129.213.41
hxxp://184.86.225.91
hxxp://107.189.160.196
hxxp://88.208.193.123
hxxp://50.56.135.44
hxxp://184.106.3.194
hxxp://185.31.17.144
hxxp://67.19.105.107
hxxp://218.185.224.231

Mit diesen Adressen versucht der Trojaner zu kommunizieren, wenn er erkennt, dass er auf einer virtuellen Maschine ausgeführt wird. Doch nicht eine einzige dieser Adressen ist eine korrekte Adresse eines Steuerungszentrums des Bots, folglich hat der Bot auch kein Glück, wenn er versucht eine Verbindung mit ihnen herzustellen. Der Sinn der Sache besteht höchstwahrscheinlich darin, die Forscher in die Irre zu führen und bei ihnen den Eindruck zu erwecken, die Steuerungsserver des Trojaners seien tot. Eine ähnliche Methode kam schon früher in dem Aufsehen erregenden Trojaner Citadel zum Einsatz.

Die Erkennung von virtuellen Maschinen ist recht simpel umgesetzt. Sie funktioniert aufgrund der Namen der Prozesse, die für verschiedene virtuelle Maschinen charakteristisch sind. Vom Namen jedes Prozesses im System wird die Hash nach dem folgenden Algorithmus berechnet:

Algorithmus des Hash-Wertes aus dem Namen des Prozesses

Der so erhaltene Hash-Wert wird daraufhin mit der Liste der im Trojaner festgeschriebenen Werte verglichen:

Hashfunktionen von den Prozessnamen, die zur Erkennung der virtuellen Maschinen benutzt werden

Wir haben die Namen der Prozesse für einige Hashes ausgewählt. So entspricht die Hashfunktion 0xBCF398B5 dem Prozess vboxservice.exe, die Hashfunktion 0x2C967737 dem Prozess vmacthlp.exe, die Hashfunktion 0xE3EBFE44 dem Prozess vmtoolsd.exe, 0x61F15513 dem Prozess vboxtray.exe.

Zu übermittelnde Daten

Die Anfrage an das Steuerungszentrum sieht im Traffic folgendermaßen aus (hier ein Beispiel für Version 2, allerdings sieht die Anfrage der Version 3 genauso aus):

Dialog des Emotet-Bots mit seinem Steuerungsserver

Der URL-Pfad, den der Bot aufruft, sieht so aus: „/722ffc5e/355c7a0a/“, wobei 722ffc5e die Zahl ist, die auf der Grundlage der Informationen aus dem Zugriffsmarker des Anwenders errechnet wurde, und 0x355c7a0a = 0x722ffc5e xor 0x47738654 (der Wert 0x47738654 ist im Bot-Körper hart codiert).

Die Daten, die von dem Bot und dem Steuerungszentrum übermittelt werden, sind mit RC4 verschlüsselt. Die Antworten die vom Steuerungszentrum kommen, sind mit einer digitalen Signatur versehen. Möglicherweise wird so vorgegangen, um das Abfangen der Kontrolle über das Botnet zu erschweren: Damit ein Paket von einem Bot angenommen wird, muss es signiert sein. Dafür benötigt man wiederum unbedingt einen geheimen Schlüssel.

Im Körper des Bots befindet sich der öffentliche RSA-Schlüssel. Im Format PEM für die Version 2 sieht er folgendermaßen aus:

PEM-Variante eines öffentlichen RSA-Schlüssels, im Körper des Bots der Version 2 hart codiert

Wie bereits oben erwähnt, wurde der Schlüssel in der Version 3 verändert. Im Format PEM sieht er folgendermaßen aus:

PEM-Variante eines öffentlichen RSA-Schlüssels, im Körper des Bots der Version 3 hart codiert

Das Paket, das an den Server geschickt wird, wird auf die folgende Art erstellt:

  1. Es wird eine Anfrage erstellt die in sich den Identifikator des infizierten Computers enthält, Werte, die vermutlich die Version des Bots bezeichnen sowie Informationen über das System (Betriebssystem-Version, Version der Service-Packs, Produkttyp), das hart codierte dword (der Wert im untersuchten Sample ist 7), Kontrollsummen des Banker-Moduls und Informationen über Web-Einschleusungen. Die Informationen über die Einschleusungen enthalten: die Adresse der Seite (mit Jokern), in die etwas eingeschleust werden soll, die Daten vor den einzuschleusenden Daten, die Daten nach den einzuschleusenden Daten und die einzuschleusenden Daten selbst.
  2. Aus der erstellten Anfrage wird eine SHA1-Hashfunktion errechnet.
  3. Die Anfrage wird mit Hilfe eines zufällig generierten RC4-Schlüssels mit einer Länge von 128 Bit chiffriert.
  4. Der generierte RC4-Schlüssel wird mit Hilfe eines öffentlichen RSA-Schlüssels chiffriert.
  5. Bei dem Gesamtpaket handelt es sich um die Konkatenation der Resultate, die aus den Schritten 4, 2 und 3 erhalten wurden.

Daher lässt sich das Anfragepaket in Form des folgenden Schemas darstellen:

Struktur der Anfrage vom Bot an den Server

Als Antwort vom Server kommt ein Paket mit der folgenden Struktur:

Struktur der Antwort des Servers an den Bot

In der Antwort können Informationen über Web-Einschleusungen von Emotet, die Emotet-Module und Links für den Download von externen Modulen (beispielsweise Spam-Bot oder Update des Downloaders) enthalten sein.

Module

Wie die überragende Mehrheit moderner Bank-Trojaner auch, hat Emotet eine modulare Struktur. Bis zum gegenwärtigen Zeitpunkt haben wir die folgenden Module entdeckt:

Name Beschreibung Art des Transports auf das infizierte System
loader Downloader In Spam-Mails oder mittels Download über einen Link auf kompromittierte Websites (im Fall von Updates)
nitol-like-ddos-module DDoS-Bot
mss Spam-Modul Wird von dem Modul „loader“ von kompromittierten Websites heruntergeladen
email_accounts_grabber Stiehlt E-Mail-Accounts, verwendet Mail PassView, eine legitime Software zur Wiederherstellung vergessener Passwörter für E-Mail-Accounts Wird mit dem Modul „loader“ im Antwort-Paket von dem Steuerungszentrum geliefert
banker Modul zur Modifizierung des HTTP(S)-Traffics Wird mit dem Modul „loader“ im Antwort-Paket von dem Steuerungszentrum geliefert
outlook_grabber Modul zum Diebstahl des Outlook-Adressbuchs Wird mit dem Modul „loader“ im Antwort-Paket von dem Steuerungszentrum geliefert

Einige Module funktionieren auch unabhängig von dem Modul loader, da nichts aus diesem Modul importiert wird.

Die gesamte Anlage des Bots zeugt von einem hohen Grad der Automatisierung seiner Arbeit: Automatisch werden neue E-Mail-Adressen aus den Adressbüchern des Opfers gesammelt, automatisch wird Spam mit dem Emotet-Downloader verschickt, automatisch wird Geld vom Anwender abgezogen. Die Beteiligung des Betreibers ist auf ein Minimum reduziert.

Hier als Beispiel der an die Kriminellen geschickte Bericht des Moduls outlook_grabber (aus Emotet Version 2) mit dem gestohlenen Outlook-Adressbuch:

Gestohlenes Outlook-Adressbuch, weitergeleitet an den Server der Cyberkriminellen

Als positiven Aspekt vermerken wir das Folgende: Bei dem Versuch, sich mit einem der Server der Cyberkriminellen zu verbinden, erhält man eine Antwort, die «X-Sinkhole: Malware sinkhole» enthält, das heißt, die gestohlenen Daten kommen nicht bei den Cyberkriminellen an – diese Domain, die von Emotet Version 2 benutzt wurde, befindet sich nicht mehr unter der Kontrolle der Autoren des Trojaners.

Bei der Version 3 sieht das allerdings anders aus. Hier der Bericht des Moduls email_accounts_grabber aus Emotet Version 3:

Bericht, der die Daten über den E-Mail-Account des Nutzers enthält

Wie man sieht, antwortet der Server mit „200 OK“. Das bedeutet, dass die Cyberkriminellen die übertragenen Daten erhalten haben.

Rücken Sie Ihr Geld raus!

Die Informationen über die auf der Seite einzuschleusenden Daten die Emotet nach dem Entpacken erhält, sehen folgendermaßen aus:

Dechiffrierte Daten über Web-Einschleusungen von Emotet Version 2

Dechiffrierte Daten über Web-Einschleusungen von Emotet Version 3

Der entscheidende Unterschied in den Daten über die Web-Einschleusungen der verschiedenen Versionen verhält sich wie folgt: Emotet Version 3 richtet sich gegen Kunden von Schweizer Kreditinstituten. Bisher haben wir noch keine Skripte für das automatisierte Stehlen von Geld von den Kunden dieser Schweizer Kreditinstitute gefunden, doch wir sind davon überzeugt, dass solche Skripte geschrieben werden.

Obgleich einzelne Fragmente des HTML-Codes im entschlüsselten Paket leicht zu lesen sind, ist es durchaus nicht einfach, die Anwendungsregeln der Web-Einschleusungen aufgrund der dechiffrierten Daten zu verstehen. Unten stehend sind im Format JSON einige Regeln der Web-Einschleusungen für ein Ziel – die Website einer deutschen Bank – dargestellt (Emotet Version 2).

Regeln der Web-Einschleusungen auf der Website einer deutschen Bank (Emotet Version 2)

Die Anwendung dieser Web-Einschleusung führt zur Erstellung eines neuen Elements des Typs <div>, das in jedem sichtbaren Bereich der Seite eine Größe haben wird, sowie zum Hinzufügen eines neuen Skriptes in das HTML-Dokument. In dem angeführten Beispiel wird das Skript von der folgenden Adresse geladen: hxxps://*******.eu/birten/luck.php?lnk=js&id=44.

Und hier ein analoger Eintrag mehrere Einschleusungsregeln für ein neues Ziel – die Website einer großen österreichischen Bank (Emotet Version 3).

Webeinschleusungsregeln auf der Website einer österreichischen Bank (Emotet Version 3)

Es ist offensichtlich, dass die Struktur der Konfigurationsdatei mit Web-Einschleusungen klassisch ist – verwendet werden Felder mit den Bezeichnungen data_before, data_after und data_inject (d.h. Daten vor den einzuschleusenden Daten, Daten nach den einzuschleusenden Daten sowie die einzuschleusenden Daten selbst).

Bemerkenswert ist, dass die Adresse des Hostes, bei dem die Datei luck.php (für Version 2) und a_00.php (für Version 3) platziert ist, sich häufig ändert, der restliche Teil der Skriptadresse jedoch gleich bleibt.

Wenn sich ein Forscher direkt an das Skript wendet, so erhält er lediglich eine Fehlermeldung. Bei einer realen Attacke allerdings, wenn die Zeile

der echten Bankenseite hinzugefügt wird, wird das Skript erfolgreich geladen.

Das geschieht deshalb, weil der Server der Cyberkriminellen das Header-Feld “Referer” der HTTP-Anfrage überprüft und das Skript nur in dem Fall herausgibt, wenn die Anfrage von einer Seite einer der Banken stammt, die von Emotet angegriffen werden.

Hat man den erforderlichen Referer eingesetzt, so kann man problemlos den Code des Skriptes erhalten.

Wir bei Kaspersky Lab haben Skripte erhalten, die für Einschleusungen auf den Seiten der angegriffenen Banken vorgesehen sind.

Tabelle 1. Ziele von Emotet Version 2, Angriffstypen und ID-Nummern der Skripte, die für die Durchführung dieser Attacken geladen werden.

Tabelle 2. Ziel von Emotet Version 3, Angriffstypen und ID-Nummern der Skripte, die für die Durchführung dieser Attacken geladen werden

In einem der Skripte aus Emotet Version 2, das für Angriffe auf eine deutsche Bank verwendet wird, fand sich die folgende Zeile:

Artefakt aus einem Skript für einen Angriff auf eine deutsche Bank (Emotet Version 2)
Anm. d. Übers.: Die deutsche Übersetzung dieser russischen Phrase lautet: „Alle Überweisungen löschen“

Ganz offensichtlich sprechen die Entwickler der für die Angriffe verwendeten Skripte russisch.

Umgehung der Zwei-Faktoren-Authentifizierung

Die wichtigste Aufgabe der oben besprochenen Skripte ist die Durchführung betrügerischer Geldüberweisungen vom Konto des Anwenders. Allerdings kann der Bot die Zwei-Faktoren-Authentifizierungssysteme (Chip TAN oder SMS TAN) nicht eigenständig umgehen, er benötigt hier die „Hilfe“ des Anwenders. Um das potentielle Opfer hinters Licht zu führen, werden Social-Engineering-Methoden eingesetzt: In einer Mitteilung, die mit Hilfe eines Skriptes auf der Webseite eingeschleust wurde, wird der Nutzer darüber informiert, dass auf der Website gerade ein neues Sicherheitssystem eingeführt werde, und der Nutzer nur beschränkten Zugriff auf sein Konto habe, bis er eine kurze Schulung im Demo-Modus abgeschlossen hat.

Gefälschte Mitteilung über ein neues Sicherheitssystem

Es folgt die Aufforderung, mit den realen Chip TAN- oder SMS TAN-Daten eine „Testüberweisung“ durchzuführen:

Und schließlich wird dem Nutzer zur „erfolgreich bestandenen Prüfung“ gratuliert:

Tatsächlich führt das schädliche Skript unter dem Deckmantel der „Testüberweisung“ eine reale Überweisung vom Konto des Opfers auf das Konto eines Strohmannes durch – eines so genannten Droppers, und der Anwender selbst bestätigt diese Überweisung via Chip TAN oder SMS TAN.

Auf die Daten der Konten, auf die das gestohlene Geld überwiesen werden soll, wird im Skript nicht verwiesen, diese werden aber mit Hilfe einer bestimmten Anfrage vom Steuerungsserver der Cyberkriminellen geliefert. In der Antwort auf diese Anfrage gibt der Steuerungsserver eine Zeile mit Informationen über den „Dropper“ für jede konkrete Transaktion heraus. In den Kommentaren in einem der Skripte wurde diese Zeile gefunden:

Offensichtlich haben die Cyberverbrecher ihre Skripte getestet, indem sie 1500,90 EUR auf ein Testkonto überwiesen haben.

Außerdem wurden in diesem Skript die folgenden Informationen über den Dropper gefunden:

Im entsprechenden Skript von Emotet Version 3, das für Attacken auf dieselbe Bank vorgesehen ist, wurden ebenfalls Informationen über einen Dropper gefunden, allerdings über einen anderen:

Hier ein Vergleich zwischen dem Feld JSON __DropParam und dem entsprechenden Feld im legitimen Formular aus der Demoanwendung der angegriffenen Bank.

Online-Banking-Formular der Bank für Überweisungen innerhalb Deutschlands und in der SEPA-Zone

Tabelle 3. Übereinstimmungen zwischen den Daten des Droppers und den Feldern auf dem Überweisungsformular

Name im __DropParam JSON Bezeichnung des entsprechenden Formularfeldes
name Empfängername
ibanorkonto IBAN/Konto-Nr.
bicorblz BIC/BLZ
description Verwendungszweck
amount Betrag

Die Felder in JSON __DropParam entsprechen den Feldern auf dem Formular.

So erhält der Bot alle notwendigen Informationen über den Dropper von seinem Server und stellt auf ihn eine Überweisung aus. Der in die Irre geführte Anwender bestätigt die Überweisung mittels Chip TAN oder SMS TAN und verabschiedet sich damit für immer von seinem Geld.

Fazit

Der Trojaner Emotet ist eine hochautomatisierte, sich fortlaufende entwickelnde und geografisch zielgerichtete Bank-Bedrohung. Die geringe Größe, die angewandten Selbstverbreitungsmechanismen und die modulare Architektur machen Emotet zu einer überaus wirksamen Waffe in den Händen Cyberkrimineller.

Da der Trojaner jedoch keine prinzipiell neuen Techniken einsetzt, ist durch den Einsatz moderner Antiviren-Software ein zuverlässiger Schutz vor dieser Bedrohung gewährleistet.

Hinzu kommt, dass dieser Bank-Trojaner ohne Beteiligung des Anwenders überhaupt nicht funktioniert – die Autoren von Emotet setzen aktiv Social-Engineering ein, um ihre verbrecherischen Ziele zu erreichen.

Daher gilt: Vorsicht und technische Aufgeklärtheit in Kombination mit einer modernen Antiviren-Lösung sind das Fundament eines soliden Schutzes – nicht nur vor Emotet, sondern auch vor neuen Bank-Trojanern, die nach demselben Prinzip funktionieren.

Einige MD5

Emotet Version 2:
7c401bde8cafc5b745b9f65effbd588f
34c10ae0b87e3202fea252e25746c32d
9ab7b38da6eee714680adda3fdb08eb6
ae5fa7fa02e7a29e1b54f407b33108e7
1d4d5a1a66572955ad9e01bee0203c99
cdb4be5d62e049b6314058a8a27e975d
642a9becd99538738d6e0a7ebfbf2ef6
aca8bdbd8e79201892f8b46a3005744b
9b011c8f47d228d12160ca7cd6ca9c1f
6358fae78681a21dd26f63e8ac6148cc
ac49e85de3fced88e3e4ef78af173b37
c0f8b2e3f1989b93f749d8486ce6f609
1561359c46a2df408f9860b162e7e13b
a8ca1089d442543933456931240e6d45

Emotet Version 3:
177ae9a7fc02130009762858ad182678
1a6fe1312339e26eb5f7444b89275ebf
257e82d6c0991d8bd2d6c8eee4c672c7
3855724146ff9cf8b9bbda26b828ff05
3bac5797afd28ac715605fa9e7306333
3d28b10bcf3999a1b317102109644bf1
4e2eb67aa36bd3da832e802cd5bdf8bc
4f81a713114c4180aeac8a6b082cee4d
52f05ee28bcfec95577d154c62d40100
772559c590cff62587c08a4a766744a7
806489b327e0f016fb1d509ae984f760
876a6a5252e0fc5c81cc852d5b167f2b
94fa5551d26c60a3ce9a10310c765a89
A5a86d5275fa2ccf8a55233959bc0274
b43afd499eb90cee778c22969f656cd2
b93a6ee991a9097dd8992efcacb3b2f7
ddd7cdbc60bd0cdf4c6d41329b43b4ce
e01954ac6d0009790c66b943e911063e
e49c549b95dbd8ebc0930ad3f147a4b9
ea804a986c02d734ad38ed0cb4d157a7

Der Autor dank Vladimir Kuskov, Oleg Kupreev und Yury Namestnikov für Ihre Hilfe beim Verfassen des vorliegenden Artikels.

Ähnliche Beiträge

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.