BackSwap Banking-Malware leert Bank-Konten

ESET-Forscher entdecken eine Banking-Malware, die neue Techniken zum Überbrücken dedizierter Browser-Schutzmaßnahmen einsetzt.

Die Beliebtheit von Banking-Malware unter Cyberkriminellen ist in den vergangenen Jahren zurückgegangen. Weiterentwickelte Antimalware-Programme und Web-Browser bieten Usern besseren Schutz vor Banken-Trojanern als jemals zuvor. Damit gestaltet sich konventioneller Online-Banking Betrug sehr viel komplexer. Malware-Entwickler investieren ihre Zeit und Ressourcen eher in einfachere und gewinnbringendere Malware-Projekte wie Ransomware, Cryptominer oder Crypto-Trojaner.

Wir haben nun eine neue Banking-Malware Familie aufgedeckt, die innovative Techniken der Browser-Manipulation einsetzt. Anstelle des Einsatzes komplexer Process Injection Methoden, um die Browser-Aktivität aufzuzeichnen, klinkt sich die Malware in Key Window Message Loop Events ein. Dann untersucht sie die Werte der Window Objects nach Online-Banking Aktivitäten.

Entdeckt die Banking-Malware eine Online-Banking Aktivität, fügt sie schädlichen JavaScript Code zur aufgerufenen Online-Banking Seite hinzu – entweder in die JavaScript Console vom Browser oder direkt in die Adresszeilenleiste. Das alles passiert ohne das Wissen des Users. Dieser scheinbar einfache Trick hebelt sogar die fortschrittlichsten Browser-Schutzmechanismen aus.

Vorwort

Die für die neue Banking-Malware verantwortlichen Cyberkriminellen machten zunächst im Januar auf sich aufmerksam. Damals verbreiteten sie einen Crypto-Trojaner, der Kryptowährungen stahl, indem Walletadressen in der Zwischenablage gegen die der Kriminellen ausgetauscht wurden. Die Truppe fokussierte sich zunächst auf die Clipboard-Malware und entwickelte die erste Version der Banking-Malware nebenher.

ESET entdeckte die Banking-Malware BackSwap am 13. März 2018 als ESET as Win32/BackSwap.A.

In der nachfolgenden Grafik kann man die dramatischen Spitzen in der Erkennung von BackSwap im Vergleich zu vorherigen Projekten verfolgen. Die Malware-Entwickler waren sehr aktiv in der Entwicklung der Banking-Malware und haben täglich neue Versionen veröffentlicht – was nur am Wochenende unterbrochen wurde.

Abbildung 1: Übersicht der Erkennungsraten von der Banking-Malware Win32/BackSwap.A im Vergleich zu früheren Projekten der Cyberkriminellen

Verteilung und Ausbreitung der BackSwap Banking-Malware

Die BackSwap Banking-Malware verteilt sich durch E-Mail Spam-Kampagnen mit schädlichem Anhang. Es handelt sich hierbei um einen schwer verschleierten JavaScript Downloader, der aus der allgemein bekannten Malware-Familie Nemucod stammt. Die Spam-Kampagnen treffen momentan polnische Computer-User.

Sehr oft sind die Computer der Betroffenen schon mit dem bekannten Win32/TrojanDownloader.Nymaim Downloader kompromittiert. Diese Malware scheint sich auf die gleiche Weise zu verbreiten. Zum Zeitpunkt der Erstellung dieses Beitrags ist uns nicht bekannt, ob es sich hierbei um einen Zufall handelt, oder ob beide Malware-Familien miteinander verknüpft sind.

Die Payload wird als modifizierte Version einer eigentlich legitimen Software-Applikation dargeboten, die nun aber teilweise durch die schädliche Payload überschrieben ist. Die Köder-Anwendung, welche das Ziel der Modifikation ist, wechselt stetig. In der Vergangenheit zählten dazu beispielsweise TPVCGateway, SQLMon, DbgView, WinRAR Uninstaller, 7Zip, OllyDbg oder FileZilla Server. Die Apps werden so modifiziert, dass sie während der Initialisierungsphase zum schädlichen Code wechseln. Eine der verwendeten Techniken, ist das Hinzufügen eines Pointers zur bösartigen Payload in die _initterm() Function-Tabelle. Das ist ein interner Teil der C-Laufzeitbibliothek, der alle globalen Variablen und andere Teile des Programms initialisiert, die initialisiert werden müssen, bevor die main()-Function aufgerufen wird.

Abbildung 2: _intterm Pointer Array einer legitimen Anwendung mit Pointer zum Shell-Code der Banking Malware am Ende

Diese Methode mag an einen Trojaner erinnern. Der Unterschied liegt allerdings darin, dass die Original-Anwendung nicht länger funktioniert. Und besitzt die Malware erst einmal die Kontrolle, ist eine Umkehrung zum originalen Code ausgeschlossen. Aus diesem Grund beabsichtigen die Malware-Entwickler nicht, den Computer-User glauben zu lassen, er oder sie benutze eine legitime Anwendung. Die Cyberkriminellen beabsichtigen eher ein hohes Maß an Unsichtbarkeit der Malware gegen Entdeckung und Analysen. Malware-Analysten haben es so in der Tat schwerer, die Schadsoftware aufzuspüren, da auch Reverse-Engineering-Tools wie IDA Pro die originale main() Function als legitimen Start einer Anwendung werten. Malware-Analysten bemerken auf den ersten Blick gar nicht, dass sie es mit einer Malware zu tun haben.

Die Payload ist ein positionsunabhängiges BLOB eines Codes mit allen eingebetteten Daten darin. Die Zeichenketten sind im Klartext gespeichert, was den ansonsten sehr kleinen Fußabdruck ruiniert, da alle benötigten Windows-APIs während der Laufzeit nach Hash-Werten durchsucht werden. Die Banking-Malware kopiert sich beim Starten zunächst einmal in den Autostart-Ordner, um Persistenz zu gewährleisten und dann mit dem Ausspähen fortzufahren.

Konventionelle Injection-Methoden

Damit Geld vom Online-Banking Konto eines Opfers über das Internet Banking Interface gestohlen werden kann, muss sich Banking-Malware oder hierfür spezielle Module üblicherweise selbst in den Adressbereich des Browserprozesses laden. Aus vielerlei Gründen ist das keine einfache Aufgabe. Wie bereits zuvor erwähnt, kann die Injection schon durch Drittanbieter Sicherheitsprogramme geblockt werden. Das eingespeiste Modul muss auch mit der Prozessorarchitektur zusammenpassen – ein 32-bit Modul kann nicht in ein 64-bit Browserprozess eingespeist werden und vice versa. Im Endeffekt muss der "Bankentrojaner" beide Versionen an Bord haben, um 32- oder 64-bit Versionen eines Browsers kompromittieren zu können.

War das erfolgreich, muss das Banking-Modul browserspezifische Funktionen aufspüren und diese anzapfen. Die Banking-Malware sucht nach Funktionen, die für das Senden und Empfangen von http-Anfragen in Klartext vor Verschlüsselung respektive nach Entschlüsselung verantwortlich sind. Die Schwierigkeit im Finden dieser spezifischen Funktionen variiert dabei von Browser zu Browser.

Im Fall von Mozilla Firefox werden die Funktionen von der nss3.dll Bibliothek exportiert, und ihre Adressen können mühelos nach den allgemein bekannten Namen durchsucht werden. Google Chrome und Chromium-basierte Browser halten diese Funktionen gut versteckt, tief in der Binärdatei. Das zwingt die Malware-Entwickler dazu, spezialisierte Methoden und Muster nur für diese spezifischen Browser-Versionen zu erfinden. Sobald eine neue Browser-Version erscheint, müssen auch neue Methoden und Muster implementiert werden. Sind die richtigen Funktionen gefunden und die Anker erfolgreich gesetzt (auch diese können von Sicherheitslösungen gefunden werden), beginnt die Banking-Malware den http-Trafic zu modifizieren bzw. auf eine nachgebaute, scheinbar gültige Webseite umzuleiten. Ähnliche Techniken werden derzeit von aktiven, bekannten Banken-Trojanern angewandt. Dazu zählen Dridex, Ursnif, Zbot, Trickbot, Qbot und viele andere.

Neue Browser-Manipulationstechnik

Die Banking-Malware Win32/BackSwap.A verfolgt einen völlig anderen Ansatz. Sie greift auf Windows GUI-Elemente und das Simulieren von User-Eingaben zurück. Das mag zunächst trivial erscheinen, allerdings verbirgt sich dahinter eine mächtige Technik, die manche "Probleme" der konventionellen Injection-Methode lösen. Außerdem interagiert die Banking-Malware nicht mit dem Web-Browser auf Prozessebene. Insofern werden keine besonderen Privilegien benötigt. Zudem müssen nicht irgendwelche besonderen Schutzprozesse des Browsers umgangen werden. Sehr positiv für die Angreifer ist auch die Tatsache, dass der Code nicht von den Prozessorarchitekturen der Webbrowser abhängt.

Die Malware überwacht die vom Opfer aktuell besuchte URL durch eine Installation eines Ereignis-Ankers für einen bestimmten Bereich relevanter Ereignisse, die über den Windows Message Loop verfügbar sind, z. B. EVENT_OBJECT_FOCUS, EVENT_OBJECT_SELECTION, EVENT_OBJECT_NAMECHANGE und einige andere. Der Anker sucht nach URL-Mustern, indem er die Objekte nach Strings durchsucht, die mit "https" beginnen, indem er die get_accValue-Methode von der IAccessible-Schnittstelle des Ereignisses aufruft.

Abbildung 3: Verfahrensweise zum Abrufen der vom Web-Browser kürzlich besuchten URLs. Diese URLs werden durch Überprüfen der Teil-Strings [ht] tp [s] (in rot) abgerufen.

Abbildung 4: Banking-Malware sucht spezielle Banken-spezifische Strings - der erste String ist der Seitentitel, der zweite beinhaltet einen Teil der URL.

Sobald eine Überweisung identifiziert ist, lädt die Banking-Malware aus den Ressourcen ein schädliches JavaScript, das für die entsprechende Online-Bank geeignet ist, und speist es in den Browser ein. Die Script-Injection erfolgt ebenfalls auf einfache, aber effektive Weise.

In älteren Samples fügt die Malware das schädliche Skript in die Zwischenablage ein und simuliert das Drücken der Tastkombination für das Öffnen der Console im Entwicklermodus (STRG+Umschalt+J in Google Chrome; STRG+Umschalt+K in Mozilla Firefox). Dem folgt STRG+V, was den Inhalt aus der Zwischenablage einfügt. Der ENTER-Befehl führt den Inhalt aus der Console aus. Zum Schluss reiht sich noch einmal der Shortcut für die Console ein, um sie wieder zu schließen. Während des ganzen Prozesses bleibt das Browserfenster unsichtbar – für den User scheint der Web-Browser kurzzeitig eingefroren zu sein.

In neueren Sample-Varianten der Malware wurde der Ansatz nochmal aktualisiert. Anstatt über die Developer Console wird das schädliche Script direkt aus der Adresszeile ausgeführt. Das ermöglicht das wenig benutzte Feature JavaScript Protocol URLs, dass aber von den meisten Browsern unterstützt wird. Die Malware simuliert das Drücken von STRG+L, um die Adresszeile des Web-Browsers auszuwählen. Dem folgt die LÖSCHEN-Taste, um das Feld zu leeren. Durch den Aufruf von SendMessageA im Loop folgt dann das eigentliche Einfügen des schädlichen Scripts durch die STRG+V-Kombination. ENTER führt das Script aus. Die Adresszeile wird abschließend wieder geleert, um Spuren einer Kompromittierung zu verwischen.

In Abbildung 5 ist ein Teil vom Console Injection Code abgebildet. Man sieht, dass die Malware zunächst den Browser bestimmt. Dazu überprüft es den "Class Name" des Vordergrundfensters (blau markiert). Das schädliche JavaScript wird in die Zwischenablage kopiert (rot). Dann ändert sich die Opazität des Browser-Fensters auf 3, was es unsichtbar macht (violett markiert). In grün ist der Teil der ToggleBrowserConsole Funktion dargestellt, welcher die Developer Console an und aus schaltet.

Abbildung 5: Script Injection Verfahrensweise

Win32/BackSwap.A unterstützt Angriffe gegen Google Chrome, Mozilla Firefox und in der neusten Version haben die Malware-Entwickler auch Unterstützung für den Internet Explorer implementiert. Bei den meisten Browsern funktioniert die Methode, insofern sie über eine JavaScript-Konsole verfügen oder die Ausführung von JavaScript über die Adressleiste zulassen. Beides ist also in vielen Browsern standardmäßig integriert.

Alle drei großen Web-Browser besitzen allerdings ein interessantes Sicherheitsfeature, dass ursprünglich als Gegenmaßnahme gegen Self-XXS Attacken gedacht war. Wenn der User versucht, Text – beginnend mit "javascript:" – in die Adresszeile einzufügen, wird der Protokoll-Prefix entfernt und der User muss es manuell in die Adresszeilenleiste eingeben, damit die Script-Ausführung geschieht.  Win32/BackSwap.A umgeht diese Schutzmaßnahme, indem das Tippen des Prefix in die Adresszeilenleiste simuliert wird. Das geschieht Buchstabe für Buchstabe, bevor danach das schädliche Script eingefügt wird.

Mozilla Firefox verfügt über eine Schutzmaßnahme, die das Einfügen von Skripten standardmäßig blockiert. Der Computer-User wird zunächst über die potentiellen Risiken informiert und muss dann die Erlaubnis noch einmal durch eine Eingabe bestätigen. Aber auch das kann die Malware umgehen, in dem sie den Shell-Befehl aus Abbildung 6 ausführt. Das modifiziert die prefs.js Konfigurationsdatei. Damit ist die Firefox-Barriere ausgetrickst.

Abbildung 6: Der Shell-Befehl, der den Firefox-Schutz umgeht, Scripts einfügen zu können.

Schädliches JavaScript von BackSwap

Die Banking-Malware implementiert für jede anvisierte Bank ein spezifisches Script. Denn jede Banken-Webseite ist anders und besitzt unterschiedlichen Source Code und verschiedene Variablen. Die Skripte werden in die Webseiten eingefügt, welche die Malware als "Überweisungsseite" identifiziert. Das eingeschleuste JavaScript ersetzt heimlich den Empfänger und die Bankdaten der Überweisung beim betätigen des Senden-Buttons. Nun wird das Geld den Cyberkriminellen überwiesen. An dieser Stelle hilft auch keine 2-Faktor-Authentifizierung, da das Opfer bereits in den Transfer eingewilligt hat.

Win32/BackSwap.A besitzt momentan schädliche Scripts die 5 folgende polnische Banken anvisieren: PKO Bank Polski, Bank Zachodni WBK S.A., mBank, ING und Pekao. Bei manchen Versionen stehen nicht alle fünf Banken auf der Liste der Ziele. In der aktuellen Version sind es beispielsweise nur noch die drei: PKO BP, mBank und ING. In älteren Versionen bezog das Script die Bankdaten noch über einen C&C-Server, welche auf gehackten Wordpress-Webseiten gehostet waren. Nun sind die Malware-Entwickler dazu übergegangen, ihre Bankdaten direkt in das schädliche Script zu schreiben. Die Bankkontonummern ändern sich regelmäßig. Jede neue Malware-Kampagne hat praktische ihre eigene Kontonummer.

Wie wir dem Screenshot unten entnehmen können, stiehlt die Banking-Malware nur Geld, dessen Wert sich in einem bestimmten Bereich befindet. Normalerweise wird ein Betrag gestohlen, der zwischen 10.000 und 20.000 PLN liegt (momentan ca. zwischen 2322 und 4645 EUR). Das Skript tauscht nicht nur das Bankkonto des Empfängers aus, sondern manipuliert auch das Eingabefeld so, dass der Online-Banking User immer noch seine eingegebene Empfängernummer sieht. Damit soll kein Verdacht geschöpft werden.

Abbildung 7: Teil des bösartigen JavaScripts. Die roten Markierungen zeigen das Überprüfen des zu überweisenden Betrags und das Ersetzen mit der eigenen Bankverbindung

Fazit

Win32/BackSwap.A versinnbildlicht uns den nicht endenden Kampf zwischen Sicherheitsunternehmen und Entwicklern von Online-Banking Malware. Neue cyberkriminelle Methoden müssen nicht unbedingt komplex gestaltet werden, um effektiv zu sein. Wir sind der Auffassung, dass durch den besseren Schutz der Web-Browser vor konventioneller Code Injection die Malware-Entwickler nach anderen Wegen der Kompromittierung suchen. Win32/BackSwap.A zeigt uns nun eine Möglichkeit davon.

ESET Sicherheitslösungen erkennen und blockieren die Win32/BackSwap.A Bedrohung. Darüber hinaus wurden alle Browser-Anbieter über die neue Script Injection Technik informiert.

Unser besonderer Dank geht auch an Paweł Śmierciak, der die Malware-Familie aufgespürt und mit erforscht hat.

IoCs