Die Malware SnatchLoader ist wieder aktiv

Dennis Schwarz 28. November 2017

Die Malware SnatchLoader ist wieder aktiv

Die Malware Snatchloader lädt einen Banking-Trojaner namens Ramnit. © sdecoret / Fotolia.com — © sdecoret / Fotolia.com

SnatchLoader ist eine "Downloader"-Malware, die explizit auf die Verbreitung und das Herunterladen weiterer Malware auf infizierte Computer ausgerichtet ist. Die Malware trat im Januar 2017 zum ersten Mal auf und blieb für einige Monate aktiv. Danach wurde es ruhig um sie. Nun aber scheint sich die Entwicklung dieser Malware fortzusetzen. In den letzten Wochen wurden neue Updates entdeckt. Aktuell wird sie verwendet, um einen Banking-Trojaner namens Ramnit zu laden. Darüber hinaus macht sie sich eine interessante Funktion zunutze, die als "IP-basiertes Geoblocking" bekannt ist und bewirkt, dass nur Computer in bestimmten geographischen Gebieten infiziert werden. Wir konnten feststellen, dass zumindest Großbritannien und Italien im Visier stehen, während z. B. die USA, Frankreich und Hongkong nicht betroffen sind.

Hintergrundinformationen

Vor ein paar Monaten gab es einen interessanten Thread auf Twitter [1] über eine Spam-Kampagne [1], mit der eine damals noch unbekannte "Downloader"-Malware verteilt wurde, die darauf spezialisiert war, andere Malware-Familien zu verbreiten. Auf der Basis unserer Analysen gehen wir davon aus, dass es sich hierbei um ein Update des unter dem Namen "SnatchLoader" bekannten Downloaders handelt, der im Januar kurz im Forum KernelMode.info diskutiert wurde [3]. Wie in dem Post angemerkt wurde, gibt es Ähnlichkeiten zwischen SnatchLoader und einer weiteren Malware-Familie, die unter der Bezeichnung H1N1 Loader bekannt ist [4]. Allerdings wurde kein detaillierter Vergleich der Codes vorgenommen. Außer den Hinweisen auf die Herkunft der Malware haben wir keine weiteren Diskussionen über SnatchLoader gefunden, sodass der Post sich vermutlich mit der neuesten Version beschäftigt.

Beispiele

Das Beispiel, auf das sich der ursprüngliche Thread bezieht, ist auf VirusTotal verfügbar [5]. Allerdings wurde unsere statische Analyse zum großen Teil auf der Basis einer aktualisierten Version der Core DLL mit einem Kompilierungsdatum vom 04.10.2017 durchgeführt. Diese DLL ist ebenfalls auf VirusTotal verfügbar und wurde erstmals am 11.10.2017 entdeckt. 

Windows API-Aufrufe

Alle Windows API-Aufrufe erfolgen zur Laufzeit durch Hashing des Funktionsnamens. Der Hashing-Algorithmus kombiniert ROL- (ROtate Left) und XOR-Operationen. Das Beispiel einer Python-Implementierung ist auf GitHub zu finden [6]. Dies sind einige der API-Funktionsnamen und die jeweiligen Hashwerte:

RtlZeroMemory - 0x6b6c652b
CreateMutexW - 0x43725043
InternetConnectA - 0x1d0c0b3e

Statische Konfiguration

In einem PE-Abschnitt der DLL-Datei wird eine statische Konfiguration in verschlüsselter Form gespeichert. Bisher haben wir zwei Namen gefunden, die für diesen Abschnitt verwendet werden: .idata und .xdata (s. Abb.1).

Das erste Binärwort (DWORD) in diesem Abschnitt (0x99a8 in Abb.1) wird als Startwert für eine Schlüsselgenerierungsfunktion verwendet. Eine Python-Implementierung dieser Funktion ist auf GitHub zu finden [7]. Mit dem generierten Schlüssel werden unter Verwendung von RC4 die weiteren Daten entschlüsselt. Die entschlüsselte Konfiguration lässt sich in zwei Blöcke (Chunks) unterteilen. Der erste Block erinnert an XML und sieht wie folgt aus (die Leerräume wurden ergänzt, um die Lesbarkeit zu verbessern):

<STATIC>
   <CFG>
      <SRV>https://lookmans.eu/css/order.php</SRV>
      <TIME>3</TIME>
      <NAME>02.10</NAME>
      <KEY>547bnw47drtsb78d3</KEY>
   </CFG>
</STATIC>

SRV ist die URL des Command-and-Control-Servers (C2), TIME ist das Polling-Intervall (in Minuten) für die Phone-Home-Kommunikation und NAME ist die Kennung (ID) der Kampagne (im Beispiel steht "02.10" vermutlich für den 2. Oktober). KEY dient der Verschlüsselung der Phone-Home-Kommunikation. Der zweite Konfigurationsblock ist ein RSA-Zertifikat, mit dem die Signatur der heruntergeladenen Daten geprüft wird.

Command-and-Control-Server

Abb.2: Phone-Home-Kommunikation als Klartext. © Dennis Schwarz

Alle bislang beobachteten C2-URL-Adressen verwenden HTTPS. Allerdings kann die Kommunikation mithilfe eines Debuggers so modifiziert werden, dass HTTP anstelle von HTTPS verwendet wird und die Phone-Home-Kommunikation als Klartext zu sehen ist (s. Abb.2).

Die POST-Daten werden auf vier Ebenen verschlüsselt:

RC4 auf der Basis des KEY-Werts in der Konfiguration
Base64
Zeichenersetzung
Splitten in jeweils 64 Byte lange Teilblöcke mit \r\n-Trennzeichen

Insgesamt gibt es drei Zeichenersetzungen, die reversibel sind:

+ in –
/ in _
. in =

Die Antwortdaten werden auf ähnliche Weise verschlüsselt; allerdings entfällt die Ebene 4. Die Kommunikationsströme können vier Anforderungstypen zugeordnet werden:

Abruf der dynamischen Konfiguration
Senden der Systeminformationen
Befehlsabfrage
Senden der Befehlsergebnisse

Anforderung zum Abrufen der dynamischen Konfiguration

Die Klartextversion einer Anforderung zum Abrufen der dynamischen Konfiguration (get dynamic config) sieht wie folgt aus:

req=0&guid=FCD08AEE3C0E9409&name=02.10&trash=ulbncmamlxwjakbnbmaklvvhamathrgsfrpbsfrfqeqpatisgsfrqbtfrgqfrpbuithtisrctisgsfrqbujtiuistduith

Die Elemente sind:

req: Anforderungstyp
guid: Bot-ID
name: NAME-Wert aus der statischen Konfiguration
trash: zufällige Zeichen zufälliger Länge

Eine Beispielantwort sieht wie folgt aus:

SUCCESS|<CFG><SRV>https://lookmans[.]eu/css/order.php|https://vertasikupper[.]eu/css/order.php</SRV><TIME>120</TIME><NAME>02.10</NAME><KEY>547bnw47drtsb78d3</KEY></CFG>|

Diese Antwort kann in zwei Felder unterteilt werden: in das Statusfeld und in den Datenteil. Im Beispiel stellt SUCCESS das Statusfeld dar, während die Parameter <CFG>...</CFG> den Datenteil umschließen. Diese Konfiguration wird im Code als DYNAMIC-Konfiguration bezeichnet.

Anforderung zum Senden der Systeminformationen

Mit der zweiten Phone-Home-Anforderung werden verschiedene Systeminformationen gesendet. Sie sieht wie folgt aus:

req=1&guid=FCD08AEE3C0E9409&name=02.10&win=9&x64=1&adm=1&det=0&def=0&nat=1&usrn=SYSTEM&cmpn=JOHN-PC&uagn=Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E)&sftl=AddressBook|Connection Manager|DirectDrawEx|Fontcore|IE40|IE4Data|IE5BAKEX|IEData|MobileOptionPack|SchedulingAgent|WIC|&prcl=[System Process]\r\nSystem\r\nsmss.exe\r\ncsrss.exe\r\nwininit.exe\r\ncsrss.exe\r\nwinlogon.exe\r\nservices.exe\r\nlsass.exe\r\nlsm.exe\r\nsvchost.exe\r\nVBoxService.exe\r\nsvchost.exe\r\nsvchost.exe\r\nsvchost.exe\r\nsvchost.exe\r\naudiodg.exe\r\nsvchost.exe\r\nsvchost.exe\r\nspoolsv.exe\r\nsvchost.exe\r\ntaskhost.exe\r\nsvchost.exe\r\ndwm.exe\r\nexplorer.exe\r\nVBoxTray.exe\r\nSearchIndexer.exe\r\nwmpnetwk.exe\r\nsvchost.exe\r\nsppsvc.exe\r\nsvchost.exe\r\nmscorsvw.exe\r\nmscorsvw.exe\r\nSearchProtocolHost.exe\r\nmsiexec.exe\r\nsvchost.exe\r\nTrustedInstaller.exe\r\ntaskhost.exe\r\nSearchFilterHost.exe\r\nmsiexec.exe\r\ndllhost.exe\r\ndllhost.exe\r\nmsiexec.exe\r\nsvchost.exe\r\n&trash=ilnyyiittddnoyyiblambllvwgblalakjvufynamblcmambllwugxlwkwjvu\r\n

Die Elemente sind:

req: Anforderungstyp
guid: Bot-ID
name: NAME-Wert aus der Konfiguration
win: Windows-Version
x64: 64-Bit-Architektur
Adm: admin
det: auf Anti-Analyse bezogen
def: Name des Anti-Analyseprozesses erkannt
nat: hat RFC1918 IP-Adresse
Usrn: Benutzername
Cmpn: Computername
uagn: Benutzer-Agent
Sftl: Softwareeintrag aus dem Uninstall-Registrierungsschlüssel
Prcl: Prozesseintrag
trash: zufällige Zeichen zufälliger Länge

Eine Antwort sieht wie folgt aus:

SUCCESS|

Anforderung für Befehlsabfrage

Die Anforderung einer Befehlsabfrage unterscheidet sich von der Anforderung zum Abrufen der dynamischen Konfiguration nur durch die req-Nummer 2. Eine Beispielantwort sieht wie folgt aus:

SUCCESS|<TASK>20|1|2||MZ...\x00\x00</TASK>|

Diese Antwort hat zwei Felder, wobei das erste Feld ein Statusfeld und das zweite Feld der Datenteil ist. Das Datenfeld kann leer sein oder weitere TASK-Blöcke mit den folgenden Feldern enthalten:

Task-ID
Befehlstyp
Befehlsargument 1 (z. B. Dateityp)
Befehlsargument 2 (z. B. Hashwert)
Befehlsdaten (z. B. ausführbare Datei oder URL-Adresse)

Die wesentliche Funktion von SnatchLoader besteht wie erwähnt darin, weitere Malware-Familien zu verteilen und zu laden. Die meisten Befehlstypen und Argumente dienen daher auf die eine oder andere Weise diesem Ziel (normale Ausführung, Ausführung mittels rundll32 oder Einbetten in die Datei explorer.exe). In diesem Beispiel bewirkt der Befehl, dass die eingebettete ausführbare Datei extrahiert und normal ausgeführt wird.

Einige der weiteren unterstützten Befehle sind:

Plugin-Funktionalität (bisher wurde aber nur ein Plugin zum Mining der Kryptowährung Monero beobachtet [7])
Aktualisieren der Konfiguration
Selbstaktualisierung

Anforderung zum Senden der Befehlsergebnisse

Mit der Phone-Home-Anforderung des letzten Typs werden die Ergebnisse des Befehls gesendet:

req=3&guid=FCD08AEE3C0E9409&name=02.10&results=&trash=pffebxmawlawigdawkifcymbxmawlgebxlawkifcymbxmhebymbxlawkifcy

Diese Anforderung unterscheidet sich von der Befehlsabfrage nur durch die req-Nummer 3 und den zusätzlichen Parameter results. Für diese Anforderung sendet der C2-Server keinen Antwortinhalt.

IP-basiertes Geoblocking und aktuelles Payload

Ein interessantes Merkmal der von uns bislang untersuchten C2-Server besteht darin, dass sie eine Art Geoblocking basierend auf den IP-Quelladressen vornehmen. Versuche, mit den Servern über TOR- oder VPN-Exit-Knoten in den USA, Frankreich oder Hongkong zu interagieren, endeten mit dem Fehler 404 Not Found. Bei Kommunikationsversuchen über VPN-Exit-Knoten in Großbritannien und Italien wurde die Anfrage jedoch von den C2-Servern bestätigt. Geoblocking ist grundsätzlich keine ganz neue Funktion, wird aber nicht besonders häufig verwendet.

Zum Zeitpunkt der Abfassung dieses Texts wurde das analysierte SnatchLoader-Botnet eingesetzt, um den auf Datendiebstahl angelegten Banking-Trojaner Ramnit zu verteilen. Das Sample hat das Kompilierungsdatum 13.10.2017 und ist auf VirusTotal verfügbar.

Fazit

Dieser Artikel enthält eine Übersicht über eine "Downloader"-Malware, die als "SnatchLoader" bekannt ist. Ihre Ursprünge lassen sich bis Januar 2017 zurückverfolgen. Die letzte Aktualisierung liegt nicht lange zurück. Die Malware wird über Spam-Kampagnen verbreitet und nutzt eine Geoblocking-Funktionalität, die darauf schließen lässt, dass bestimmte geografische Regionen ins Visier genommen werden. Zum Zeitpunkt der Veröffentlichung dieses Artikels verteilt SnatchLoader die Ramnit-Malware zumindest in Großbritannien und in Italien.

Quellen