Quasar Linux (QLNX): Ein Einstiegspunkt in die Lieferkette mit vollständigen RAT-Fähigkeiten

Zusammenfassung

Quasar Linux (QLNX) ist ein fortschrittlicher Remote-Access-Trojaner für Linux, der ein User-Space- und eBPF-Rootkit mit einem PAM-Backdoor und umfangreichen Möglichkeiten zur Ernte von Zugangsdaten kombiniert. Die Malware unterstützt dateilose Ausführung, Prozessnamenverschleierung und mehrere Persistenztechniken, die ihr helfen, auf infizierten Systemen verborgen zu bleiben. Der Fokus auf Entwickler-Arbeitsstationen macht sie besonders gefährlich für den Missbrauch der Lieferkette, da sie Tokens, SSH-Schlüssel und Cloud-Zugangsdaten stehlen kann. Die Malware verwendet auch verschlüsselte Kommunikation und unterstützt eine Peer-to-Peer-Mesh-Architektur, um die Resilienz zu verbessern und den Zugang aufrechtzuerhalten.

Untersuchung

Forscher von Trend Micro erhielten die QLNX-Binärdatei und führten sowohl eine statische als auch eine dynamische Analyse durch, wobei sie im Quellcode eingebettete Komponenten des Rootkits und des PAM-Backdoors entdeckten. Ihre Untersuchung dokumentierte die Fähigkeit der Malware, Komponenten direkt auf dem Zielhost zu kompilieren, die Vielfalt der von ihr verwendeten Persistenzmechanismen und das vollständige Befehlssatz, der vom Implantat unterstützt wird. Die Netzwerkanalyse offenbarte auch ein benutzerdefiniertes TLS-basiertes Protokoll und einen einzigartigen Magic Identifier, der in der Kommunikation verwendet wird. Aus dieser Arbeit extrahierten die Forscher Indikatoren für Kompromittierungen, um Jagd und Erkennung zu unterstützen.

Abschwächung

Verteidiger sollten nach QLNX suchen, indem sie nach seiner einzigartigen Mutex-Sperrdatei, verdächtigen LD_PRELOAD Einträgen und ungewöhnlichen gcc Kompilierbefehlen überwachen, die bösartige Shared Objects erzeugen. Organisationen sollten auch die Ausführung unbekannter Binärdateien mit dem Namen quasar-implant blockieren und Schreibzugriffe auf /etc/ld.so.preloadeinschränken. Multi-Faktor-Authentifizierung sollte für Entwicklerkonten durchgesetzt werden, und Sicherheitsteams sollten engmaschig auf Versuche achten, Zugangsdaten und sensible Token-Dateien zu exfiltrieren.

Reaktion

Wenn QLNX-Indikatoren gefunden werden, isolieren Sie das betroffene System sofort, sammeln Sie Speicher- und Festplattenabbilder und beenden Sie den schädlichen Prozess. Entfernen Sie unautorisierte Einträge aus /etc/ld.so.preload, löschen Sie die kompilierten bösartigen .so Dateien und löschen Sie die vom Implantat verwendete Sperrdatei. Alle potenziell exponierten Zugangsdaten, insbesondere Cloud- und Paketregister-Token, sollten unverzüglich ausgetauscht werden. Ermittler sollten auch bewerten, ob irgendwelche Lieferkettensysteme, Repositories oder Build-Umgebungen während des Einbruchs kontaminiert wurden.

## Simulationsausführung

Voraussetzung: Der Telemetrie- und Basisvorflug-Check muss bestanden sein.

Begründung: Dieser Abschnitt beschreibt die präzise Ausführung der gegnerischen Technik (TTP), die zur Auslösung der Erkennungsregel entwickelt wurde. Die Befehle und der Text MÜSSEN die identifizierten TTPs direkt widerspiegeln und zielen darauf ab, die genaue Telemetrie zu erzeugen, die von der Erkennungslogik erwartet wird.

• Angriffserzählung & Befehle:

  1. Stufe 1 – Payload-Generierung: Der Angreifer schreibt ein minimales C-Payload, das memfd_create aufruft, um eine anonyme im Speicher befindliche ausführbare Datei zu erstellen, schreibt ein einfaches Shellcode (z.B. execve("/bin/sh", …)), markiert sie als ausführbar und startet sie dann über execveat.
  2. Stufe 2 – On-the-Fly-Kompilierung: Mit gcc (dem sichtbaren Indikator in der Regel) kompiliert der Angreifer den Quellcode, ohne die Festplatte zu berühren (Ausgabe an /dev/fd/3).
  3. gerichtet Stufe 3 – Ausführung & Injektion: memfd_createDie kompilierte Binärdatei wird ausgeführt, ruft execveat auf, lädt den Shellcode und ruft schließlich auf, um das speicherresident ELF auszuführen. Optional auf, um das speicherresident ELF auszuführen. Optional

• kann verwendet werden, um Code in einen Schwesterprozess zu injizieren, was ebenfalls die Regel erfüllen würde.

  Regressionstest-Skript:

• #!/usr/bin/env bash # # QLNX-ähnliche fileless Ausführungssimulation # Generiert im Speicher befindliches ELF via memfd_create und führt es mit execveat aus. # Erforderlich: gcc, libcap2-bin (für execveat-Demo), und auditd-Regeln vom Vor-Flug. set -euo pipefail # 1️⃣ Erstellen Sie eine C-Quelle, die den memfd + execveat Tanz durchführt cat > /tmp/payload.c <<‚EOF‘ #define _GNU_SOURCE #include <sys/mman.h> #include <sys/syscall.h> #include <unistd.h> #include <fcntl.h> #include <string.h> int main(void) { // Erstellen Sie einen anonymen Dateideskriptor (memfd) int fd = syscall(SYS_memfd_create, „memfd_payload“, MFD_CLOEXEC); if (fd == -1) _exit(1); // Einfaches ELF-Binary, das nur execve /bin/sh aufruft const unsigned char elf[] = { 0x7f,0x45,0x4c,0x46,0x02,0x01,0x01,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, // … (gekürzt zur Übersicht – ein minimal statisch verlinktes /bin/sh ELF) }; write(fd, elf, sizeof(elf)); // Machen Sie es ausführbar fchmod(fd, 0755); // Verwenden Sie execveat, um die im Speicher befindliche Binärdatei auszuführen syscall(SYS_execveat, fd, „“, NULL, NULL, AT_EMPTY_PATH); _exit(0); } EOF # 2️⃣ Kompilieren Sie mit gcc (dies wird von der Erkennungsregel erfasst) gcc -static -o /tmp/payload /tmp/payload.c # 3️⃣ Führen Sie die schädliche Binärdatei aus – dies löst execveat aus /tmp/payload # 4️⃣ Säubern rm -f /tmp/payload /tmp/payload.c

  Aufräumbefehle: