© kosobu / 123RF.com

Immer mehr cyberkriminelle Gruppen entdecken Linux für sich und adaptieren ihre bisher für Windows-Systeme ausgelegte Malware. In einer Studie haben Sicherheitsforscher Ransomware-Angriffe auf beide Betriebssysteme verglichen.

Seit 2021 steigt die Zahl der Ransomeware-Attacken auf Linux-Systeme stark an. Analysen von Sicherheitsforschern identifizieren einen Auslöser für die Entwicklung in der Veröffentlichung des Quellcodes der Babuk-Malware. Für Schlagzeilen sorgte im April 2024 eine Zero-Day-Lücke namens Xz-Backdoor in der Xz-Bibliothek. Die Bibliothek kommt unter anderem in der Datenbank PostgreSQL zum Einsatz – wer die Backdoor ausnutzt, hätte damit massiven Schaden hätte anrichten können. Linux rückt also mehr und mehr in den Fokus der Sicherheitsabteilungen, denn sie müssen auf die Bedrohungslage reagieren und ihre Open Source-Strategie hinsichtlich der erforderlichen Cybersecurity-Maßnahmen überdenken.

Seit Beginn des Jahres haben Sicherheitsforscher von Check Point Research (CPR) die Aktivitäten eines chinesischen Cyberspionage-Bedrohungsakteursuntersucht, der sich auf Südostasien, Afrika und Südamerika konzentriert. In seinem Tool-Set befindet die plattformübergreifende Backdoor DinodasRAT [1], auch bekannt als XDealer, die zuvor bei Angriffen des chinesischen Bedrohungsakteurs LuoYu beobachtet wurde.

Der Artikel befasst sich mit der technischen Analyse der Linux-Version (v11) von DinodasRAT, genannt Linodas. Sie scheint ausgereifter zu sein als die Windows-Version und verfügt über eine Reihe speziell auf Linux-Server zugeschnittener Funktionen. Darüber hinaus führt die untersuchte Version ein separates Umgehungsmodul ein, um Spuren von Malware im System zu verbergen. Dabei wird die Ausführung der System-Binärdateien durch Proxys modifiziert.

Die Ursprünge von Dinodas

Mehrere Hinweise deuten darauf hin, dass DinodasRAT ursprünglich auf dem Open-Source-Projekt SimpleRemote [2] basierte. Dahinter steckt ein Fernzugriffstool, das wiederum auf dem Gh0st RAT [3] beruht, aber einige zusätzliche Verbesserungen aufweist. Zu den Ähnlichkeiten zwischen SimpleRemote und einer älteren Version von DinodasRAT gehören das Verwenden derselben Zlib-Bibliothek in Version 1.2.11 sowie Überschneidungen im Code, beispielsweise die nahezu identisch ausfallende Funktion zum Erkennen der Betriebssystemversion (Abbildung 1).

Abbildung 1: Ähnlichkeiten in der Funktion zur Erkennung der Betriebssystemversion zwischen dem Dinodas-Beispiel (links) und dem Open-Source-Code. Quelle: Check Point Software

Die Entwickler von DinodasRAT verwendeten aber nicht nur Teile des Quellcodes wieder, sondern auch zusätzlichen Open-Source-Code aus einem anderen Respository. Dabei handelt es sich um Funktionen für die Handhabung von INI-Dateien. Das letzte Beispiel dafür, dass Open-Source-Code in die Backdoor eingeflossen ist, ist die von den Entwicklern gewählte Verschlüsselungsmethode. Anstatt ihre eigene Methode zu implementieren, entschieden sie sich für die im QQ-Messenger eingesetzte Verschlüsselung.

Eigenständige Codebasis

Alle Beispiele des plattformübergreifenden DinodasRAT betten eine Zeichenfolge ein, die die interne Version der Backdoor enthält. In den Linux-Samples tauchen einige die Entwicklung der Backdoor widerspiegelnde Strings auf (Tabelle “Strings und die Entwicklung der Backdoor”).

Die früheste Linux-Version haben die Sicherheitsforscher erstmals im Juli 2021 in freier Umgebung gesichtet. Linodas besitzt zwar dieselbe Logik wie die Windows-Variante, fügt aber ebenso eine Reihe eigener Verhaltensweisen hinzu und zielt speziell auf Linux-Server ab. Die jüngste Linodas-Version (v11) lässt sich auch in der Windows-Variante beobachten, das mit demselben C2-Server »update.microsoft-setting[.]com« kommuniziert (Tabelle “Linux- und Windows-Version im Vergleich”).

Zwei Proben mit unterschiedlichen internen Versionen legen nahe, dass es zwei verschiedene Entwicklungsteams gab oder zumindest zwei Backdoors in unterschiedlichen Entwicklungsstadien, die mit demselben C2-Server kommunizieren. Die Linux- und Windows-Versionen weisen überlappende Befehls-IDs auf, die nahtlos dieselbe Malware-Funktionalität für verschiedene Betriebssysteme unterstützen. Die Cyberkriminellen installieren das Implantat auf Linux-Servern, um sich im Netzwerk weiter zu etablieren. Gefunden haben die Sicherheitsforscher Malware-Dateien, die sich mit den Namen ntfsys als System- oder Treiberdatei im Zusammenhang mit NTFS ausgeben.

Sobald die Backdoor ausgeführt wird, prüft sie, ob sie zum ersten Mal läuft, indem sie zwei Argumente abfragt: den Buchstaben d und die Prozess-ID des aufrufenden Daemons. Wenn sie die Argumente nicht findet, ruft sie die Daemon-Funktion auf und stellt die Persistenz im System her. Anschließend startet sich die Backdoor erneut selbst: Sie holt sich die Prozess-ID sowie den Selbstausführungspfad und führt den Befehl »[SELF_PATH] d [SELF_PID]« über die Funktion »system« aus.

Persistenz-Methoden

Der Persistenzprozess fällt relativ umfangreich aus und umfasst mehrere Ubuntu-Versionen und Red-Hat-Distributionen. Zunächst gilt es, die aktuelle Betriebssystemversion zu ermitteln, indem die Dateien »/proc/version« und »etc/lsb-release« gelesen und die Ausgabe analysiert wird. Danach lässt sich auf der Grundlage der gesammelten Daten die Persistenz mit einer der folgenden Methoden erreichen.

Methode 1 (Ubuntu) – »rc.local« über »systemd« aktiviert: Die Malware sieht zunächst nach, ob die Datei »/lib/systemd/system/rc.local.service« nicht existiert, und schreibt den Code aus Listing 1 in die Datei.

[Unit]
Description=/etc/rc.local Compatibility
ConditionFilelsExecutable=/etc/rc.local
After=network.target
[Service]
Type=forking
ExecStart/=etc/rc.local start
TimeoutSec=0
RemainAfterExit=yes

Daraufhin erstellt sie den nachstehenden Symlink.

/lib/systemd/system/rc.local.service --> /etc/systemd/system/

Im nächsten Schritt ermittelt die Malware, ob es die Datei »/etc/rc.local« gibt, und ergänzt bei Vorhandensein die folgende Zeichenkette.

#!/bin/bash
[SELF_FILE_PATH] exit 0

Anschließend macht sie die Datei »/etc/rc.local« mithilfe des Befehls »chmod 777« ausführbar und evaluiert, ob die Persistenz korrekt in die Datei geschrieben wurde. Schließlich ändert die Schadsoftware die INI-Felder in der Datei »/lib/systemd/system/rc.local.service« (Listing 2).

[Service]
RemainAfterExit=no
[Install]
WantedBy=multi-user.target Alias=rc-local.service

Methode 2 (Red Hat) – »init.d«-Skript: Die Backdoor ruft den Befehl auf, dessen Ausgabe Chkconfig analysiert, und versucht, ihn auszuführen. Wenn der Befehl gefunden und korrekt ausgeführt wird, fügt sie ihn der Umgebungsvariablen »PATH« hinzu und fährt mit der eigentlichen Persistenz fort. Die Malware prüft, ob die Datei »/etc/init.d/[SELF_FILE_NAME]« nicht existiert, und schreibt danach den Code aus Listing 3 hinein.

#!/bin/sh
### BEGIN INIT INFO
# Provides:          [SELF_FILE_NAME]
# Required-Start:    $local_fs $network
# Required-Stop:     $local_fs
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: [SELF_FILE_NAME] service
# Description:       [SELF_FILE_NAME] service daemon
### END INIT INFO
[SELF_FULL_ATH] restart

Wenn die Datei nicht erstellt wurde, schreibt es dieselben Daten in die Datei »/etc/ch.sh« und führt das folgende Kommando aus.

mv /etc/ch.sh /etc/init.d/[SELF_FILE_NAME]

Anschließend führt die Schadsoftware den Befehl »chmod 777« für die erstellte Datei aus und überprüft die Persistenz mithilfe des nächsten Aufrufs.

chkconfig --list | grep [SELF_FILE_NAME]

Wenn das Ergebnis nicht »6:« enthält, kommen die beiden folgenden Befehle zum Einsatz.

chkconfig --add [SELF_FLE_NAME] chkconfig zentao [SELF_FLE_NAME]

Methode 3 (Red Hat) – »rc.local«: Die Persistenz erfolgt über die Datei »/etc/rc.d/rc.local«. Wenn die Datei existiert, prüft die Backdoor, ob sich Selbstpfad im Inhalt findet – wenn nicht, fügt sie sich der Datei mit der Zeichenfolge »\n[SELF_PATH]\n« hinzu.

Kern-Logik

Nachdem die Malware mit zwei Argumenten ordnungsgemäß ausgeführt wurde, geht sie zur eigentlichen Logik über. Zunächst arbeitet sie eine Reihe von Überprüfungen ab, darunter die Root-Rechte, den Pfad/Ordner und die Prozess-ID des aufrufenden Daemons, und speichert alle in globalen Variablen. Dann ändert die Backdoor den Zeitstempel ihrer Datei.

touch
 -d \"2010-09-08:*12:23:02\" [SELF_FILE_PATH].

Nun wird eine auf der hartkodierten Zeichenfolge »/etc/.netsc.conf« basierende Konfigurationsdatei gelesen. Bei den Konfigurationsdateien für alle Beispiele handelt es sich üblicherweise um versteckte Dateien. Aus der Konfigurationsdatei versucht die Malware, das Feld »imei« unter dem Abschnitt »para« zu lesen. Das Feld steht für die für den infizierten Rechner generierte Bot-ID. Fehlt es in der Konfigurationsdatei, wird eine eindeutige Rechner-ID auf der Grundlage von Rechnerparametern in fünf Schritten erzeugt.

Zu Beginn geht es ans Ermitteln der MAC-Adresse des Rechners: Die Schadsoftware nutzt dazu den Befehl »ifconfig« oder »ip« und extrahiert die MAC-Adresse aus der Ausgabe, die von der jeweiligen Distribution abhängt. Daraufhin ruft die Malware das Kommando »dmidecode« auf, um das SMIBIOS des Systems zu erhalten. Nachdem sie die MAC-Adresse und die Ausgabe von »dmidecode« kombiniert hat, führt sie den Befehl »md5sum« aus. Schließlich erzeugt die Backdoor im vierten und fünften Schritt eine Zufallszahl und einen Zeitstempel auf Grundlage der aktuellen Uhrzeit. Sämtliche Felder sowie ein Beispiel dazu zeigt Listing 4. Nach der Generierung wird die Bot-ID in der Konfigurationsdatei gespeichert, und der Zeitstempel der Konfigurationsdatei wird ebenfalls geändert, ähnlich wie bei der ausführbaren Datei.

Linux_[TIMESTAMP]_[MD5SUM]_[RANDOM NUMBER]_V11
Linux_20240310_11cb06d0bf454c3708a3658c2601ea16_40459_V11

Danach führt die Backdoor eine grundlegende Systemaufzählung durch, um die Distribution, die genaue Betriebssystemversion und die Systemarchitektur zu ermitteln. All diese Werte werden in globalen Variablen gespeichert und später verwendet, wenn die Backdoor das C2 zum ersten Mal kontaktiert. Die hartkodierte C2-Adresse wird geparst, in einer globalen Struktur gespeichert, und die Malware liest zwei weitere Konfigurationsfelder, »mode« und »checkroot«, aus dem Bereich »para«. Das Feld »mode« gibt die Art der zu verwendenden C2-Kommunikation an: TCP oder UDP. Das Feld »checkroot« hingegen bestimmt, ob die Backdoor angemeldete Benutzer überwachen soll. Nach der anfänglichen Konfiguration generiert die Backdoor mehrere Threads, die zur Überwachung und Bereinigung dienen. Danach initiiert sie die Verbindung zum C2-Server.

Überwachen und Aufräumen

Die Backdoor erstellt fünf Threads, die mit der Systemüberwachung, dem Herunterladen von Hilfsmodulen und dem Aufräumen alter Reverse-Shell-Verbindungen beauftragt sind.

Thread #1 übernimmt die Überwachung des eingeloggten Benutzers. Wenn das Feld »mode« in der Konfiguration oder die globale Variable für »mode« auf »1« gesetzt ist, überwacht dieser Thread eingeloggte Benutzer mit dem Befehl »who«. Er analysiert dessen Ausgabe und schließt die C2-Verbindung, wenn die angemeldete IP nicht eine lokale IP oder die C2-IP ist.

Thread #2 verantwortet die Überwachung des C2-Verbindungsstatus. Jedes Mal, wenn eine gültige Anfrage an das C2 gestellt wird, wird das Zeitfeld in der globalen C2-Verbindungsstruktur aktualisiert. Wenn seit der letzten Anfrage an das C2 eine halbe Stunde vergangen ist, schließt der Thread die Verbindung zum C2.

Thread #3 kümmert sich um das Herunterladen und Einrichten des Filtermoduls. Der Thread prüft zunächst, ob das Modul nicht bereits durch die Verwendung einer Variablen heruntergeladen wurde. Trifft das nicht zu, führt der Thread erneut einige Schritte aus. Zu Beginn prüft er, ob die Datei »[SELF_PATH].so6« existiert, und berechnet einen Md5-Hash ihres Inhalts. Daraufhin sendet er eine verschlüsselte Anfrage an das C2, in der er den Md5-Hash eines auf dem C2-Server verfügbaren Moduls anfordert, und vergleicht den empfangenen Md5-Hash mit dem vorhandenen.

Unterscheidet sich der Hash davon, stellt der Thread eine weitere Anfrage an den C2 und speichert die neu erhaltene Datei unter demselben Namen. Im vorletzten Schritt liest er die Daten aus der Datei »/usr/lib/libsysattr.so«, die wahrscheinlich in einem früheren Stadium der Infektion abgelegt wurde. Diese Datei sollte eine Reihe von Werten enthalten, die durch Pipe-Zeichen »|« getrennt sind, und umfasst eine Reihe von Anweisungen für zu ersetzende ausführbare Dateien. Nun sucht der Thread im System nach jeder in der Anweisungsdatei gelisteten Datei und sichert sie unter Namen im Format »[DATEI_NAME].a«.

Zum Schluss ersetzt er die Originaldateien durch das neu erhaltene So6-Filtermodul und macht sie ausführbar. All diese Schritte ermöglichen es den Bedrohungsakteuren, bestimmte ausführbare Systemdateien zu verpacken.

Thread #4 überwacht und protokolliert angemeldete Benutzer. Wenn einer von ihnen auf dem Linux-Rechner angemeldet ist und seine IPv4 nicht einer lokalen IPV4 oder einer der C2s entspricht, werden seine Details protokolliert und an den C2-Server gesendet.

Thread #5 sorgt für die Bereinigung alter Reverse-Shell-Sitzungen. Zunächst überwacht der Thread Reverse-Shell-Sitzungen. Sobald sich eine Reverse-Shell-Sitzung findet, die fast eine Stunde nicht aktiv war, entfernt er die Sitzung.

C2-Kommunikation

Bevor die C2-Kommunikation beginnt, werden zwei globale Strukturen überprüft: Die eine enthält den Konfigurationswert, der angibt, ob bei der Verbindung mit dem C2 TCP oder UDP zum Einsatz kommen soll; die andere gibt an, ob die C2-Kommunikation unterbrochen werden soll, wenn angemeldete Benutzer vorhanden sind. Wenn eine dieser Prüfungen fehlschlägt, nimmt die Malware die Kommunikation mit dem C2 nicht auf. Wenn die Prüfungen erfolgreich sind, analysiert die Backdoor die C2-Adresse und löst bei Bedarf eine C2-Domain in IPv4 auf.

Als Nächstes richtet die Schadsoftware je nach Konfiguration einen Socket im TCP- oder UDP-Modus ein und versucht, eine Verbindung mit dem C2 herzustellen. Wenn die Verbindung erfolgreich ist, startet die Malware einen Thread zum Parsen von C2-Befehlen. Nachdem diese erste Verbindung zum C2-Server aufgebaut und der C2-Befehlsthread erstellt wurde, führt die Backdoor eine Endlosschleife aus, die für das Senden eines Heartbeats an den C2-Server zuständig ist. Der Heartbeat enthält die folgenden Werte, die kombiniert und durch »\t« getrennt werden: Informationen zur Verteilung, die Systemarchitektur, den String »root«, den konstanten Wert »0xC«, die UDP-Paketlänge 800 und einen eigenen Pfad. Wenn die Anfrage an den C2 fehlgeschlagen ist, wird die Verbindung zum C2 wiederhergestellt, der Heartbeat-String erzeugt und erneut gesendet.

Unterstützte C2-Befehle

Ähnlich wie die Windows-Backdoor unterstützt auch die Linux-Backdoor eine breite Palette von Funktionen. In der Tabelle “Unterstützte Funktionen” sind sie alle aufgeführt. Zusätzlich zeigt die Tabelle, ob sie in der Windows-Version der Backdoor vorhanden sind.

Das Filtermodul

Bei Linodas v11 ist der Thread #3 für das Herunterladen eines zusätzlichen Moduls verantwortlich, das alle angegebenen Binärdateien im System ersetzt. Keine der vorherigen Versionen unterstützt diese Funktion. Das Filtermodul (Abbildung 2), das durch Ausführung von »ntfsys« (v11) von dem vom Akteur kontrollierten C&C-Server bezogen wurde, ist als »ntfsys.so6« gespeichert.

Abbildung 2: Dateierkennungen für das Filtermodul, als es im November 2023 erstmals auftauchte.

Dem Modul kommt die Aufgabe zu, die Ausführung der Binärdateien zu steuern und ihre Ausgabe zu kontrollieren (Abbildung 3).

Abbildung 3: Diagramm der Ausführung einer Systembinärdatei, die vom Filtermodul umhüllt wird, das seine Ausgabe in Echtzeit ändert. Quelle: Check Point Software

Das Modul wird jedes Mal gestartet, wenn das System versucht, die ersetzte Binärdatei zu verwenden, mit oder ohne Parameter. Sobald es ausgeführt wird, prüft das Modul, ob sich die Konfigurationsdatei in »/usr/lib/libsysattr.a« findet. Diese separate Konfigurationsdatei wird nicht zusammen mit dem Modul heruntergeladen. Stattdessen platzieren die Bedrohungsakteure sie mithilfe der Linodas-Reverse-Shell auf dem Server.

Aus dem Abschnitt »para« der Konfigurationsdatei lädt das Modul die Felder »ip« und »name«. Es kombiniert sämtliche empfangenen Parameter, trennt sie durch Leerzeichen und sieht nach, ob die ursprüngliche Binärdatei mit dem Namen »[SELF_PATH].a« existiert. Wenn nicht, gibt es die Bash-Shell aus und beendet sich.

Ist die Datei dagegen vorhanden, führt das Modul sie mit den erhaltenen Argumenten aus und hängt die Zeichenkette »2>&1« an. Letztere führt die Fehlerausgabe mit der Standardausgabe zusammen, sodass sich beide gemeinsam manipulieren oder betrachten lassen.

Während das Modul das Unterprogramm ausführt, liest es Teile der Ausgabe und teilt sie zeilenweise auf. Jede Zeile durchläuft einen Filterungsprozess, bei dem die Zeile außer Acht bleibt, die einen der Werte für »ip« oder »name« aus der Konfiguration enthält. Wenn die Zeile die Filterung besteht, wird sie gedruckt.

Die Bedrohungsakteure setzen dieses Modul wahrscheinlich als Rootkit ein, um beliebige Werte wie IP, Benutzername, Prozessname oder andere Artefakte aus verschiedenen Binärprogrammen zum Sammeln von Informationen wie Who, Netstat, Ps und so weiter zu filtern. Auf diese Weise können sie Linodas vor den Überwachungsbemühungen verbergen.

Fazit

Die Linux-Version von DinodasRAT taucht im Zusammenhang mit chinesischen APT-Bedrohungsakteuren auf und findet seit mindestens 2021 immer wieder Verwendung. Während es zahlreiche Ähnlichkeiten mit der Windows-Version gibt, weist die Linux-Malware auf einen separaten und unabhängigen Entwicklungszweig hin. Er führt Zusatzmodule mit separaten Konfigurationsdateien und zusätzliche C2-Befehle ein, die sich auf die Einrichtung und Kontrolle von Reverse-Shells, das Sammeln von Benutzeraktivitäten aus den Protokollen und die Manipulation lokaler Dateiinhalte konzentrieren. (csi)