1 Einleitung
RecordBreaker ist der Nachfolger von Raccoon Stealer und wird oft auch als Raccoon Stealer 2.0 bezeichnet. Die Malware wurde komplett in C umgeschrieben. Sie wird als MaaS (Malware as a Service) für ein paar hundert Dollar verkauft und gehört zur Kategorie der „Informationsdiebe“ mit der Möglichkeit, eine zweite Payload nachzuladen.
Er kann Anmeldedaten, Cookies und Kreditkarteninformationen aus Chrome-basierten Browsern (einschließlich Edge) und Firefox extrahieren.
Auch eine Konfiguration, die mithilfe von Filtern vielfältige Dateien aus dem infizierten Computer extrahiert, ist möglich. Diese Funktionen wird in erster Linie von Cyberkriminellen verwendet, die sich auf Krypto-Geldbörsen spezialisiert haben.
In diesem Artikel erläutern wir die Funktionen dieser Malware sowie ihr komplettes Netzwerkprotokoll. Außerdem stellen wir die Suricata-Regeln zur Erkennung des Datenverkehrs bereit, um die von ET Pro bereitgestellten Regeln zu ergänzen.
2 Sample Analyse
Wir haben ein erstes Sample mit folgendem Fingerabdruck analysiert, das wir am 14.09.2022 erhalten haben:
SHA2: 4d5a7eae22b4c2e72c6412e7cbd063c45ea93fca764d50c9aafc3065dd903a83
SHA1: aca730fa7214d2958cad1c61724449323547dace
MD5: 35a72d1d24bdf148a67b6db05866550a
Timestamp: 09/10/2018 20:41:02
Der Payload ist gepackt und geschützt (zumindest mit Anti-Debugging) und ein Prozess-Hollowing wird verwendet, um die endgültige Payload zu injizieren. Die von uns extrahierte Payload hatte die folgenden Hashes:
SHA2: c8de301b4ecded8361ad9a3de774f101efdec3757321ac6a9197f1ac07a21e2d
SHA1: 4ae55d73e1964ab6db24524d1f5c562227dc32e1
MD5: 06b8cde92b048f39377294a63477a7e6
Zeitstempel: 08/15/2022 05:59:17
Anmerkung: Wie man sieht, liegen fast 2 Monate zwischen der Kompilierung der Payload und der des ersten Packers.
2.1 Allgemein
Das folgende Schema veranschaulicht die verschiedenen Schritte und die Kommunikation der Malware:
2.2 Erste Schritte
The payload has no imports, except LoadLibrary and GetProcAddress:
Abbildung 2: Importtabelle Payload
Die erste Aktion besteht darin, diese 2 Funktionen zu verwenden, um eine große Anzahl anderer Funktionen zu laden. Sowohl die DLL-Namen als auch die Funktionsnamen sind im Klartext, es findet keine Verschleierung statt.
Alle maskierten Zeichenketten werden dann mit Hilfe einer einfachen xor-basierten Schleife (xor jedes Byte mit einem Multibyte-Schlüssel) dekodiert und in einen Wide String umgewandelt.
Ein Mutex (in unserem Beispiel HJSIDHG#WOEJGSDGOHWEGHSDJG) wird erstellt, um zwei gleichzeitige Ausführungen der Payload zu verhindern. Die Malware prüft dann, ob sie als Mitglied der lokalen Administratorgruppe ausgeführt wird, und wenn ja, durchläuft sie die aktuell ausgeführten Prozesse, verwendet diese Informationen aber nicht.
2.3 First request
Es gibt eine Reihe von 5 konfigurierten C2, die mit einer anderen Methode verschlüsselt werden, aber auf die gleiche Weise funktionieren. Die 5 C2-URLs in unserem Beispiel sind:
- http://94.131.106.92
- http://88.119.169.51
- 3 andere werden nicht verwendet (leere Strings)
An jede dieser URLs wird eine Anfrage gesendet, wobei mindestens 64 Bytes als Antwort erwartet werden. 2 Elemente werden in den POST-Daten gesendet:
- machineId: HKLM\SOFTWARE\Microsoft\Cryptography\MachineGuid
- configId: hardcoded string
Abbildung 3: Für die erste Anfrage verwendeter User-Agent
Die Konfigurationsinformationen, die als Antwort auf die erste Anfrage gesendet werden, sind eine durch Zeilenumbrüche (0x0A char) getrennte Listen von Befehlen. Jede Zeile besteht im Allgemeinen aus dem Befehlsnamen, gefolgt von einem Unterstrich, einem ersten Parameter, einem Doppelpunkt und einer durch eine Pipe getrennten Liste weiterer Parameter (mit einer Ausnahme).
Im Folgenden werden die einzelnen Konfigurationsoptionen und ihre Auswirkungen beschrieben.
2.4 Malware Aktionen und Konfiguration
In den folgenden Abschnitten wird jede von der Malware durchgeführte Aktion in der Reihenfolge ihrer Ausführung beschrieben. Einige von ihnen stammen aus einer Konfigurationszeile, andere nicht.
Alle Anfragen werden an den antwortenden C2 gerichtet, wobei das Konfigurationstoken (siehe unten) an die URL angehängt wird, und enthalten nur eine oder mehrere hochgeladene Dateien in mehrteiligen Daten.
2.4.1 libs (configuration)
Diese Funktion lädt DLL von einer beliebigen URL herunter und speichert sie im Verzeichnis LocalLow. Dieser Befehl wird verwendet, um Bibliotheken herunterzuladen, die für die Informationsextraktion aus Edge (sqlite3) und Firefox (nss3, und Abhängigkeiten) notwendig sind. Er ist optional, die Extraktion wird nur funktionieren, wenn die Bibliotheken bereits auf dem System vorhanden sind (in einem Bibliothekssuchpfad, wie System32), was in den meisten Fällen allerdings nicht zutrifft.
Format der Konfigurationszeile: libs_name:url
Parameter:
- name: Name der in LocalLow gespeicherten DLL Die .dll-Erweiterung ist fest kodiert und wird immer an den endgültigen Dateinamen angehängt.
- url: vollständige URL zum Download der Datei.
Number: multiple.
Beispiel:
2.4.2 token (Konfiguration, obligatorisch)
Dieser Parameter wird extrahiert, nachdem die Bibliotheken heruntergeladen wurden. Bei allen weiteren Anfragen wird die erste gefundene funktionierende Befehls- und Kontroll-URL mit dem Zusatz \tokenvalue verwendet. Format: token:value Parameter:- Value: 32 Zeichen lange Zeichenkette.
- Nummer: einfach, muss in der Konfiguration nach libs platziert werden
2.4.3 sstmnfo (Konfiguration)
Diese Funktion veranlasst die Extraktion von Hardware- und Software-Informationen. Format der Konfigurationszeile: ssmtnfo_filename:titlehard|titlesoft|unused Parameter:- filename: Name der hochgeladenen Datei.
- titlehard: Zeichenkette, die in die Extraktionsdatei kopiert wird, als Titel für die Hardware-Informationen.
- titlesoft: Zeichenkette, die in die Extraktionsdatei kopiert wird, als Titel für die Software-Informationen.
- 1 weiterer Parameter: scheint nicht verwendet zu werden.
- Nummer: single
Abbildung 5 : User-Agent, der bei allen Datei-Uploads verwendet wird
2.4.4 Edge/Chrome extraction (if sqlite3 can be loaded) / ews (Konfiguration)
If sqlite3 can be loaded (through LoadLibraryW, with a full path in the LocalLow folder), Microsoft Edge and Chrome browser data are extracted. A User-Data directory is searched recursively in %AppData%. Once found multiple sqlite request are made on the different file to extract different information, each sent in a separate file in the multipart request:
- The stored credentials (file \passwords.txt).
- The cookies (file \cookies.txt).
- The form autofill values (\autofill.txt).
- The stored credit cards (\CC.txt).
On each edge profile (User-Data directory), the ews_ command is applied, from the configuration:
Format: ews_unused:searched;Name;subfolder
Note: this is the only command using “;” as separator, with wlts_.
Parameters:
- The first parameter is unused.
- searched: the searched folder in the User-Data
- name: part of the uploaded file name.
- subfolder: subfolder of the User-Data folder to search in.
Number: multiple
Each file of the folder User-Data\subfolder\searched is sent under the name —wallets—Name_Edge_profileName—filename where profileName is the name of the profile, and filename the name of the extracted file.
A single request is sent will all edge files (cookies, password, autofill, credit cards and ews_ extracted). Each file is sent only when not empty).
2.4.5 Firefox extraction (if nss3 can be loaded)
If nss3 can be loaded, information is extracted from Firefox. Note than nss3 has multiple dependencies, so the following DLL are also needed:
- vcruntime140.dll
- mozglue.dll
- msvcp140.dll
For each Firefox profile, the same information as edge are extracted, and sent the exact same way, but the cookies file is named “ffcookies.txt”.
2.4.6 wlts (configuration)
This command extract files from a designated special folder, and search recursively inside a specified subfolder for files matching a filter list, and not a blacklist filter list. This command can be used to extract crypto wallets data but works with any filetype.
Format: wlts_unused:walletname;CSIDL;subfolder;filter;blacklist
Note: this is the only command using “;” as separator, with ews_.
Parameters:
- The first parameter is unused.
- walletname: a part of the uploaded filename.
- CSIDL: ASCII integer constant, a CSIDL constant for SHGetSpecialFolderPathW.
- Subfolder: subfolder of the CSIDL to search in.
- filter: comma separated filters to select files (for example: *.txt,*.bin).
- blacklist: comma separated filters to select files to be removed from the one whitelisted (for example: txt,*test.bin).
Number: multiple
If test.txt file matches the filters, the uploaded file name would be –walets–walletname–test.txt (walletname being the corresponding parameter value), and its content would be the content of test.txt.
2.4.7 wallet.dat (always done, no configuration)
The sample searches recursively in %AppData% files named wallet.dat and sends them, under the name —wallets—folder—filename where folder is the name of the parent folder of the file, and filename the name of file found, being always wallet.dat.
2.4.8 grbr (configuration)
This function is similar to wlts, but it is more generic and can be used to search for all system disks.
Format: grbr_name2:folder|filter|blacklist|CSIDL|unused|unused|name1
Parameters:
- name2: part of the sent file name.
- folder: the folder to search in, can use environment variables and a special DSK variable, explained below.
- filter: same as wlts command, a comma separated filter list to search for.
- blacklist: same as wlts command, a comma separated filter list to ignore.
- CSIDL: same as wlts, an ASCII integer value for
- unused: 2 parameters that don’t seem to be used.
- name1: part of the sent file name.
Number: multiple
The folder parameter can include a single environment variable, at the beginning (for example %appdata%\Firefox). A special variable can be used: %DSK<numbers>%\path. When this variable is used, all drives will be listed, GetDriveTypeW will be called on each one, and if the resulting integer (between 0 and 6) is present is the DSK number list, the search for files will start at the path provided after %DSK%. For example, %DSK24%\my\folder will list all removable (DRIVE_REMOVABLE = 2) and network folder (DRIVE_REMOTE = 4) and will search for each drive in they \my\folder directory.
It is also worth mentioning there is a bug in the %DSK feature: the sample put a 00 byte to end the search string at right before the closing %. Meaning %DSK24% becomes %DSK2, the 4 has been removed, and will be ignored. To make it work for all numbers provided, a character needs to be placed before the closing %, like a space.
The sent file name for an extracted file would be —name1—name2—filename.
2.4.9 tlgrm and dscrd (configuration)
Those 2 commands with the same format and usage.
Format: tlgrm_basename:subfolder|filter|unused
Parameters:
- basename: part of the uploaded filename.
- subfolder: subfolder of %AppData% to search in.
- filter: a comma separated filter to search for files.
- Unused
Number: single (each)
All files matching the filter in the provided subfolder of %appdata% are sent, with names like —basename—filename.
2.4.10 Scrnsht (configuration)
As the name suggests, this command takes and sends a screenshot.
Format: scrnsht_param1
Parameters:
- filename: part of the uploaded filename.
Number: single
The commands simply atakes a screenshot, saves it as a file, and uploads this file to the server with the name —param1 (param1 being the command parameter).
2.4.11 ldr (configuration)
Format: ldr_type:url|path|unused
Parameters:
- type: type of command (ascii integer)
- 1: file to download. The user-agent is the same as the libs_
- 2: removed from the code (value tested but no action).
- 3: shell command to execute (ShellExecuteW).
- url: URL to download the file (type1) or script content (type 3)
- path: directory to store de downloaded payload (type 1). Can use a single environment variable in the path.
- an unused parameter.
Number: many
This command can be used to download and execute a file (type 1). The file will be downloaded, saved in the configured directory, and executed. This command can also run a script command, with type 3 (the URL is replaced by the script command).
3 Hunting
3.1 Live C2 Konfiguration
Das C2 der ersten von uns analysierten Probe war zum Zeitpunkt der Analyse bereits abgeschaltet. Einige Zeit später (25.10.2022) fanden wir eine zweite Probe mit einem ansprechenden C2.
SHA2: 9c1dbb9ea37175feb2bdcd44b4b9cc0bf63a70d941a5c0951a9eeb2c2da0ef55
SHA1: 57edf41d7816f8d87faa177b9cff226816a6c48e
MD5: 9a6850ca36ed571c8fe8e794e22a5809
Zeitstempel: 10/07/2022 06:18:10 (0x63402712)
Hier ist die Konfiguration, die von dieser zweiten Probe am 25.10.2020 erhalten wurde, wobei die C2-IP 77.73.133.23 lautet:
Wie wir sehen, wird der Befehl grbr (am Ende) verwendet, um txt-Dateien in verschiedenen Ordnern zu erfassen. Die Befehle wlts und ews zielen auf Krypto-Geldbörsen ab (wie der Name schon sagt).
Die URL der libs befindet sich auf demselben Server wie der C2, der die Konfiguration sendet, könnte aber auch woanders liegen.
Der Befehl ldr wird verwendet, um ein weiteres Stück Malware von github herunterzuladen:
Abbildung 6: VT-Analyse der heruntergeladenen Payload
Dieses Github-Repository scheint mit einer anderen Kampagne verknüpft zu sein: Es enthält 4 Repositories mit exe-, sys– und DLL-Dateien, die ein paar Tage vor der Entdeckung des Beispiels erstellt wurden:
Abbildung 7: Blick auf die Aktivität des Github-Benutzers ledouxio, der die Payload der zweiten Stufe hält
3.2 Die aktualisierte Version eines Schadprogramms
Das Interessante an der vorherigen Konfiguration ist der neue Befehl xtntns, der dem ews-Befehl sehr ähnlich zu sein scheint. Nach der Analyse ersetzt der xtntns-Befehl den ews-Befehl. Die Zeichenkette, die beim Parsen der Konfiguration verwendet wird, wurde einfach geändert, es handelt sich um dieselbe Funktion. Da es sich um einen Ersatz handelt, werden die ews-Zeilen in der Konfiguration nun ignoriert. Vielleicht war das Absicht (gemeinsames C2 zwischen verschiedenen Versionen?) oder ein Fehler. Eine Funktion zum Extrahieren von Informationen aus der Firefox Metamask Cryptowallet-Erweiterung wurde ebenfalls hinzugefügt und lädt eine Datei hoch, deren Name mit -ffextensions-Met beginnt. Eine Randbemerkung: die String-Verschlüsselungsschlüssel sind zufällig, vielleicht bei der Kompilierung generiert:
Der User-Agent, der für die Anfrage verwendet wird, hat sich geändert und heißt jetzt TakeMyPainBack. Er ist für alle Anfragen derselbe. Wir können davon ausgehen, dass er regelmäßig geändert wird.
Dies beweist, dass diese Malware immer noch aktiv entwickelt wird.
4 Detection
5 ET pro-Regeln stimmten mit dem ersten Beispielverkehr überein:
- Die 2036934 stimmt mit der ersten Anfrage überein, mit den POST-Parametern und dem Format.
- Die 2037274 stimmt ebenfalls mit der ersten Anfrage überein, allerdings nur anhand der Namen der POST-Parameter und des User-Agents (“mozzzzzzzzzzz“).
- Die 2038487 stimmt mit dem DLL-Download überein, mit dem spezifischen Benutzer-Agenten (“qwrqrwrqwrqwr“) und “.dll” in der URL.
- Die 2038485 stimmt mit dem User-Agent “mozzzzzzzzzzz” überein (verwendet für die erste Anfrage).
- Die 2038486 entspricht dem User-Agent “qwrqrwrqwrqwr“, der für das Herunterladen der DLL verwendet wird.
Da sich der User-Agent im zweiten analysierten Beispiel geändert hat, hat ET Pro eine neue Regel hinzugefügt, um den neuen User-Agent (im zweiten Beispiel) zu erkennen:
[1:2038916:1] ET TROJAN Win32/RecordBreaker – Beobachteter UA M3 (TakeMyPainBack)
Wir schlagen einige weitere Regeln vor, um den Datenverkehr nach der ersten Anfrage zu erkennen, und zwar nicht auf der Grundlage des User-Agents (der leicht geändert werden kann):
Die erste Regel entspricht dem Konfigurationsinhalt (nicht der Anfrage). Und die zweite Regel stimmt mit dem Namen der hochgeladenen Dateien für die Datenexfiltration überein, mit Ausnahme der grundlegenden Inhalte von Edge und Firefox (Cookies, Autofill, …).
5 Bemerkungen zur Programmierung
Wenn man sich den Code ansieht, scheint es klar, dass mehrere Personen an der Entwicklung beteiligt waren, einige mit schlechten Programmiergewohnheiten. Hier sind einige Bemerkungen und Punkte, die wir interessant fanden.
Einige Befehle sind gleichwertig:
Die Befehle wlts, wallet.dat, tlgrm und dscrd sind alle Spezialfälle des Befehls grbr. Nur der grbr-Befehl ist notwendig.
Es wird viel kopiert und eingefügt:
Der größte Teil des Codes der zuvor erwähnten Befehle ist derselbe, dennoch ist er in verschiedenen Funktionen manchmal sehr ähnlich. Die Prüfung auf die “.”- und “..”-Einträge von FindFirstFileW erfolgt nicht immer auf die gleiche Weise (manchmal wird jedes Zeichen geprüft, manchmal wird nur auf einen Namen geprüft, der mit “.” beginnt). Aber alles andere ist im Allgemeinen gleich. Es scheint klar zu sein, dass diese Befehle nacheinander hinzugefügt wurden: der Code eines ersten Befehls wurde in einen neuen kopiert, um einen Teil der Funktionen zu ändern (manchmal nur einen kleinen Teil).
Die Funktionen tlgrm und dscrd sind völlig identisch. Sie rufen dieselben Unterfunktionen auf, was bedeutet, dass nur die Hauptfunktion (mit dem Befehlsnamen) kopiert wurde und nur die Zeichenkette des Befehlsnamens geändert wurde. Da sie dasselbe tun, mit denselben Parametern, sind sie völlig gleichwertig und können ohne Konsequenzen ausgetauscht werden.
Es gibt Bugs:
Die Speicherverwaltung ist manchmal fehlerhaft (LocalFree wird bei nicht zugewiesenen Adressen aufgerufen, was eine Ausnahme provoziert). Die %DSK%-Funktion von grbr entfernt das letzte Zeichen, wodurch möglicherweise eine Laufwerkstypnummer entfernt wird.
Mögliche Ascii/Binär/Hex-Verwechslung:
Die String-Verschleierung basiert auf einer xor-Schleife: Das Daten-Array wird mit dem Schlüssel-Array gexored. Im Beispiel ist der Schlüssel eine ascii-Hex-Darstellung (in edx unten):
Abbildung 9: Beispiel für die Verwendung von Hexadezimalzeichen als Zeichenkette (und nie dekodiert)
Anstelle eines xor mit beliebigen Byte-Werten werden die Daten also mit nur 16 verschiedenen ASCII-Werten xored. Wenn das Ziel darin bestand, eine Zeichenkette zu verwenden, warum sollte man dann das Alphabet auf die 16 Hex-Zeichen beschränken? Sie hätten jede beliebige Zeichenkette verwenden können, haben aber nur Hex-Zeichen verwendet, was uns zu der Annahme führt, dass es sich um einen Fehler handelt und der Autor beabsichtigte, beliebige Bytes in Hex zu verwenden.
Manuell tun, was bereits existiert:
Jedes Mal, wenn eine Umgebungsvariable in einem Pfad verwendet wird, ersetzt das Programm ihren Wert manuell. Es gibt bereits eine Win32-API-Funktion, die dies tut: ExpandEnvironmentStrings. Es gibt keinen Grund, sie nicht zu verwenden, was darauf hindeutet, dass der Autor nicht von ihrer Existenz weiß.
Diese Bemerkungen zum Code sowie der fehlende Kommunikationsschutz (keine Verschlüsselung, benutzerdefinierte User-Agents, die in einer Regel leicht ins Visier genommen werden können) werfen Fragen über das Niveau und die Fähigkeiten der Autoren dieser Malware auf.