Aufgedeckt: Gezielter Malware-Einsatz gegen polnische Banken

Das polnische News-Sicherheitsportal ZaufanaTrzeciaStrona.pl (hier in Englisch) informiert über erfolgreiche Angriffe gegen polnische Banken. Die Folgen der Attacken sind dramatisch und ernst zu nehmen. Auch Symantec und BAE Systems berichten über die Thematik. Angeblich befinden sich weitere hochkarätige Ziele aus Mexiko und Uruguay im Visier der Cyber-Kriminellen. Der Malware-Einsatz weist einige interessante Aspekte in Anbetracht der Ziele, des Kompromittierungsweges und der spezifischen Features auf.

Bisher wurden nur die zwei erst genannten Punkte ausführlicher untersucht. Den schädlichen Binaries kam indes weniger Aufmerksamkeit zu teil. In diesem Blog-Beitrag möchten wir uns deshalb mehr mit den technischen Details des Malware-Einsatzes gegen die polnischen Banken auseinandersetzten.

Der Verbreitungsweg

Laut dem polnischen Sicherheitsportal wird die Bedrohung durch eine versteckte „Wasserloch-Attacke“ initiiert. Bei dieser Angriffs-Art kompromittiert ein Angreifer eine dritte Webseite, die Mitglieder seines Angriffs möglicherweise häufiger besuchen – sowohl privat und auf Arbeit. Über eine Schwachstelle (z.B. bösartige Umleitungen) auf dieser Webseite versucht der Cyber-Kriminelle sich Zugang zu einem Unternehmensnetzwerk zu verschaffen. In unserem Fall bildet die polnische Finanzaufsichtsbehörde (Komisja Nadzoru Finansowego) den Ausgangspunkt der Attacke.

Unsere Analysen haben ergeben, dass andere gleichwertige Webseiten anderer Nationalstaaten ebenfalls betroffen sind. Darunter fällt zum Beispiel auch die mexikanische Behörde Comisión Nacional Bancaria y de Valores (Nationalbank und Wertpapierkommission). Diese Seite beinhaltet ähnlich bösartige Weiterleitungen. Leider konnten Web-Tracking Dienste noch keine weiteren Informationen liefern.

Stufe 1: Dropper

Wenn das Exploit-Kit erfolgreich die beabsichtigte Malware liefert, wird die schädliche Nutzlast - eine 64-Bit-Konsolenanwendung - auf dem Computer des Opfers ausgeführt. Anders als von BAE-Systems berichtet, erwartet der Dropper einen von drei Parametern in der Argument List: -l, -e, oder -a (siehe Abschnitt 2 im folgenden Bild). Die Parameter -e und -a sind erforderlich, um Binärdateien aus der Ressource der nächsten Stufe zu extrahieren (Abschnitt 4) und einen der Dienste (auto) zu starten (Abschnitt 5).

In abgebildeten Abschnitt 5 versucht der Dropper die Konfiguration eines Systemdiensts zu verändern, um den Start eines neuen Diensts zu initiieren. Der ist so konfiguriert, dass er automatisch während des Systemstarts vom Dienststeuerungs-Manager gestartet wird. Um dieses Ziel zu erreichen, sind jedoch Admin-Rechte notwendig.

Anders als in den darauffolgenden Stufen versteckt sich die Bedrohung im ersten Stadium nicht sehr sorgfältig. Es sind sogar ausführliche Anweisungen verfügbar, die den Status der Ausführung dokumentieren (In unserem Fall über die Extraktion verschlüsselter Ressourcen).

Der Dropper nutzt eine dynamische API anstelle Windows-Funktionen in seiner Import-Tabelle zu haben. (Gut erklärt im Novetta-Bericht "Operation Blockbuster" zur Lazarus-Gruppe, Seite 34) Abschnitt (3) in der obigen Abbildung zeigt einen Wrapper des Features, der eine Systembibliothek nach der anderen durchläuft.

Offenbar „schenkten“ die Cyber-Kriminellen der zweiten Stufe dem „Loader“. Die dritte Stufe beinhaltet dann die hauptsächliche Malware als „Modul“. Der Loader wird entschlüsselt, das „Modul“ extrahiert und gelöscht. Um Spuren für eventuelle forensische Aktivitäten zu reduzieren, „leihen“ sich die Dateien ihre Erstellungszeit aus der systemeigenen shlwapi.dll. Ein interessantes Merkmal besitzt der Verschlüsselungsalgorithmus. Dieser nutzt einen ziemlich neuen RC4-ähnlichen Stream Cipher namens Spritz (https://people.csail.mit.edu/rivest/pubs/RS14.pdf, 2014). C und Python-Implementierungen von Spritz sind bereits vorhanden und entsprechen dem folgenden auseinandergebauten Code aus dem Dropper:

Stufe 2: Loader

Es gibt außerdem weitere Indikatoren, die auf ein erhöhtes Maß an Geheimhaltung hindeuten. Der Loader ist zum Beispiel durch einen kommerziellen Packer namens Enigma Protector geschützt. Wie wir erfahren haben, verharrt das Modul in einem verschlüsselten Status und wartet, vom Loader „freigelassen“ zu werden. Bei näherem Hinsehen, fiel uns auf, dass allerdings eine nicht registrierte Kopie der 64-bit Enigma v1.31 Version benutzt wurde. Etwas Anderes erwarteten wir auch nicht unbedingt, denn Malware-Entwickler auf diesem Niveau unterläuft nicht der Fehler, sich mit einer registrierten Version selbst zu enttarnen. Allerdings verwenden Angreifer, die ein großes Botnet aufbauen wollen keine kommerziellen Packer, da diese teilweise von Anti-Malwares als Bedrohung eingestuft werden. Damit beschränken sie die potentielle Größe des Botnets. Für gezielte Angriffe ist der Enigma Protector aber durchaus von nutzen. Die Rekonstruktion der original Binary ist nahezu unmöglich.

Der Eindruck, nur 64-bit Systeme seien gefährdet, trügt. Unter den Kompromittierten Rechnern der angegriffenen Institute waren auch 32-bit Computersysteme zu finden. Obwohl die Struktur insgesamt die gleiche ist, ist die 32-bit Variante nicht nur eine Re-Kompilierung, sondern unterscheidet sich auch geringfügig von der 64er: Die Dropper- und Loader-Stufen benutzen nun eine klassische RC4-Verschlüsselung anstelle von Spritz. Das Modul wird außerdem in der Registry anstelle im Dateisystem gespeichert.

Stufe 3: Modul

Die dritte und letzte Stufe ist das relativ große Modul (~ 730 KB), das die Hauptmerkmale der Malware enthält: die Kommunikation mit dem C&C-Server und die Befehle von den Betreibern.

Das Modul impft alle laufenden Sitzungen auf dem kompromittierten Windows-System.

Der nächste Screenshot zeigt die Situation nach dem Laden des Moduls in das Demontagewerkzeug IDA Pro. Die obere Leiste zeigt verschiedene Teile der Binärdatei: die Codeabschnitte in Blau und die Datenabschnitte in Grau-Gelb. Der Unterschied zwischen den Cyan- und Dunkelblau-Abschnitten ist, dass Cyan ein Code darstellt, der statisch mit existierenden Bibliotheken verknüpft ist. Neben der üblichen C-Laufzeit haben wir die Verknüpfung der Open-Source-Programmbibliothek libcurl (Version 7.47.1, veröffentlicht am 8. Februar 2016) zusammen mit Codes aus Projekten wie OpenSSL und XUnzip identifiziert. Der Farbeffekt in der Leiste wird nicht automatisch erzeugt. In unserem Fall mussten wir ausdrücklich die Teile markieren, die wir als verknüpften Bibliothekscode betrachten wollten. Außerdem importierten wir alle Funktionsnamen. Die dunkelblauen Abschnitte repräsentieren den von den Angreifern geschriebenen Code.

Im Modul ist nur eine verschlüsselte URL gespeichert. Die Kommunikation ist verschlüsselt. Wir haben auch keine Kommunikation aufzeichnen können, da der Remote-Server zum Zeitpunkt der Analyse nicht antwortete. Das Modul unterstützt eine Menge von Befehlen, mehr als genug, um es eindeutig als Remote Access Trojan (RAT) zu charakterisieren. Das Wörterbuch der Befehle lautet: “SLEP”, “HIBN”, “DRIV”, “DIR”, “DIRP”, “CHDR”, “RUN”, “RUNX”, “DEL”, “WIPE”, “MOVE”, “FTIM”, “NEWF”, “DOWN”, “ZDWN”, “UPLD”, “PVEW”, “PKIL”, “CMDL”, “DIE”, “GCFG”, “SCFG”, “TCON”, “PEEX”, “PEIN”. Viele der Befehle sind selbsterklärend (SLEP ist schlafen, PKIL ist, einen Prozess zu beenden, UPLD ist, Daten zu exfiltrieren, DOWN ist herunterzuladen, DEL ist, eine Datei löschen usw.). Unter Umständen sind die ursprünglichen libcurl-Funktionen auf die Bedürfnisse der Angreifer angepasst. Allerdings ist libcurl ein riesiges Projekt mit hunderten Beitragenden, zehntausend Zeilen Code und hunderten Optionen. Die genaue Überprüfung und Analyse der Verknüpfung ist zum Zeitpunkt des Schreibens des Artikels noch im Gange.

Lazarus-ähnliche Toolkits

Laut BAE-Systems, die sich auf die 32-bit Variante beziehen, setzt der Dropper eine wohlbekannte Malware ab, die zum Lazarus Toolkit passt. Darüber hinaus sagt Symantec: "Einige Code-Strings in der Malware teilen Gemeinsamkeiten mit Code von Malware, die von der Lazarus Gruppe eingesetzt wird. Diese Verbindung findet man auch im Bericht von Novetta (wie der bereits erwähnte Einsatz der dynamischen API). Alle diese Zeichen motivieren uns, die eigentlichen entscheidenden Eigenschaften des Lazarus-ähnlichen Toolkits wie folgt zu beschreiben:

1. mehrstufige Malware, die in einer Kaskade ausgeführt wird
2. Die Anfangsstufe ist eine Konsolenanwendung, die mindestens einen Parameter erwartet
3. WINAPIs werden dynamisch geladen
4. RC4 oder ähnliche lange Verschlüsselung, wird für die Entschlüsselung der nächsten Stufen verwendet
5. die nachfolgenden Stufen sind dynamisch verbundene Bibliotheken, die als Dienst mit dem Starttyp SERVICE_AUTO_START geladen werden (für diese Aktion sind Admin-Rechte erforderlich)

Vor Kurzem zeigten unsere Daten Lazarus-ähnliche Malware „in freier Wildbahn“. Um jedoch ein klareres Bild des gesamten Falls zu liefern, benötigen wir mehr Zeit, weitere relevante Informationen zu sammeln.

Seltsame Entdeckung

Während unserer Forschung fanden wir ein weiteres interessantes Sample, das zur gleichen Malware-Familie gehört. Eine Konsolenanwendung namens fdsvc.exe ((2.) check), die vier Parameter erwartet, wird in einer Kaskade ((1.) check) ausgeführt. Darüber hinaus entschlüsselt es die nächste Stufe via RC4 und einem 32-Byte-Schlüssel ((4.) check). Die Eigenschaften (3.) und (5.) konnten wir nicht feststellen.

Die Nutzlast in alle laufenden Windows-Sitzungen geimpft. Was dieses Sample besonders interessant macht, ist, wie die letzte Stufe Befehle von Operatoren analysiert. Die Operatoren benutzen Befehle in russischer Sprache, die in einem Translit vorliegen. Das ist eine Methode der Kodierung kyrillischer Buchstaben mit lateinischen.

Mit voreiligen Schlüssen sollten wir aber vorsichtig sein. Die Sprache könnte genauso gut eine Falle sein! Ein wichtiger Grund: Malware-Autoren implementieren Befehle meist über Zahlen oder englische Tastenkombinationen. Mit einem zwölf-Buchstaben-Befehl gestaltet sich die ganze Angelegenheit ein wenig unpraktisch.

Schlussfolgerung

Angesichts der Hinweise im Code, wagen wir zu sagen, dass es sich hier um die Wiederverwendung eines Codes handelt, der zu einem längst vergessenen Projekt gehört. Außerdem haben wir eine Häufung derartiger Malware in den letzten Wochen beobachtet. Die hinter der Bedrohung steckenden Angreifer wissen genau was sie tun. In der nächsten Zeit dürften den Incident Response Teams der Finanzinstitute unruhige Nächte bevorstehen.

IoCs

Samples aus den Angriffen

Malware mit Translit