Forscher von Trend Micro haben ein bislang undokumentiertes Linux-Implantat mit dem Codenamen Quasar Linux RAT (QLNX) beschrieben, das nach ihren Angaben auf Systeme von Entwicklern und DevOps-Ingenieuren abzielt, um Zugangsdaten zu stehlen, die den Zugriff auf Paket-Registries, Cloud-Infrastruktur und CI/CD-Pipelines ermöglichen. Die Malware wird demnach dateilos direkt aus dem Arbeitsspeicher ausgeführt, nutzt eine zweistufige Rootkit-Architektur und unterstützt 58 verschiedene Befehle, die dem Operator die vollständige Kontrolle über den kompromittierten Host ermöglichen. Die Bedrohung betrifft Linux-Systeme, die in Entwicklungs- und Betriebsprozessen von Software eingesetzt werden.

Gezieltes Sammeln von Entwickler-Secrets

Das zentrale Merkmal von QLNX, das es von anderen Linux-Trojanern für Remotezugriff unterscheidet, ist ein spezialisierter Modul zur Sammlung von Zugangsdaten, der gezielt auf die Entwicklungsökosysteme ausgerichtet ist. Laut den Forschern Aliakbar Zahravi und Ahmed Mohamed Ibrahim extrahiert das Modul Secrets aus folgenden Dateien und Konfigurationen:

• .npmrc — NPM-Tokens
• .pypirc — PyPI-Zugangsdaten
• .git-credentials — Zugangsdaten für Git-Repositories
• .aws/credentials — AWS-Zugriffsschlüssel
• .kube/config — Kubernetes-Konfiguration
• .docker/config.json — Docker-Zugangsdaten
• .vault-token — HashiCorp-Vault-Tokens
• Terraform-Zugangsdaten, GitHub-CLI-Tokens und .env-Dateien

Die Kompromittierung dieser Assets ermöglicht es dem Angreifer nach Einschätzung von Trend Micro potenziell, bösartige Pakete in NPM- oder PyPI-Registern zu veröffentlichen, Zugriff auf Cloud-Infrastruktur zu erhalten oder sich über CI/CD-Pipelines lateral zu bewegen. Dies schafft ein Risiko für Kettenreaktionen in der Software-Lieferkette: Ein einziger kompromittierter Maintainer eines Pakets kann zum Einstiegspunkt für die massenhafte Verbreitung von Schadcode werden.

Mechanismen zur Tarnung und Persistenz

QLNX zeigt den Angaben zufolge einen fortgeschrittenen Satz von Techniken zur Umgehung der Erkennung. Das Implantat wird dateilos aus dem Arbeitsspeicher ausgeführt und tarnt sich als legitime Kernel-Threads – etwa kworker oder ksoftirqd –, was seine Erkennung mit Standardwerkzeugen zur Prozessüberwachung erschwert.

Für die Persistenz in der Umgebung werden mutmaßlich mindestens sieben verschiedene Methoden eingesetzt, darunter:

• systemd-Units
• crontab-Jobs
• Injektionen in .bashrc

Das Implantat profiliert den Host außerdem, um containerisierte Umgebungen zu erkennen, und bereinigt Systemprotokolle, um Spuren seiner Aktivität zu verwischen.

Zweistufige Rootkit-Architektur

Besondere Aufmerksamkeit verdient die zweistufige Architektur zur Verschleierung. Auf Ebene des Userlands nutzt QLNX laut den Forschern den Mechanismus LD_PRELOAD des dynamischen Linkers von Linux, um Systemaufrufe abzufangen und Artefakte sowie Prozesse des Implantats zu verbergen. Auf Kernel-Ebene kommt eine auf eBPF basierende Komponente zum Einsatz, die auf Befehl vom Command-and-Control-Server Prozesse, Dateien und Netzwerk-Ports vor Standard-Tools wie ps, ls und netstat verbirgt.

Die Kombination aus Rootkits im Userland und im Kernel erschwert die Entdeckung erheblich: Selbst wenn eine der Verschleierungsebenen neutralisiert wird, maskiert die andere weiterhin die Präsenz des Implantats.

Abgreifen von Authentifizierung über PAM

QLNX enthält den Angaben zufolge eine auf Pluggable Authentication Module (PAM) basierende Backdoor, die Zugangsdaten im Klartext während Authentifizierungsereignissen abfängt, Daten ausgehender SSH-Sitzungen protokolliert und die gesammelten Informationen an den Command-and-Control-Server übermittelt. Zusätzlich wird ein zweites, auf PAM basierendes Modul zur Sammlung von Zugangsdaten beschrieben, das automatisch in jeden dynamisch gelinkten Prozess geladen wird, um den Servicenamen, den Benutzernamen und das Authentifizierungs-Token zu extrahieren.

Command-and-Control-Infrastruktur und Fähigkeiten

Nach erfolgreicher Persistenz geht das Implantat in die eigentliche Operationsphase über und versucht kontinuierlich, über die Protokolle raw TCP, HTTPS und HTTP eine Verbindung zum C2-Server aufzubauen und aufrechtzuerhalten. Der von den Forschern dokumentierte Satz von 58 unterstützten Befehlen umfasst:

• Ausführung beliebiger Shell-Befehle
• Dateiverwaltung und Code-Injektion in Prozesse
• Anfertigen von Screenshots und Aufzeichnen von Tastatureingaben
• Einrichten von SOCKS-Proxys und TCP-Tunneln
• Starten von Beacon Object Files (BOF)
• Verwaltung eines Peer-to-Peer-(P2P)-Mesh-Netzwerks

Der genaue Mechanismus der anfänglichen Auslieferung von QLNX ist zum Zeitpunkt der Veröffentlichung der Analyse noch unbekannt.

Auswirkungsanalyse

Am stärksten gefährdet sind Organisationen, in denen Entwickler auf Linux-Systemen arbeiten und dort Secrets für den Zugriff auf die Infrastruktur speichern – etwa Tokens für Paket-Registries, Schlüssel von Cloud-Providern oder Konfigurationen für Container-Orchestrierung. Die Kompromittierung eines einzelnen Entwicklerarbeitsplatzes kann zur Veröffentlichung manipulierter Pakete, zu unautorisiertem Zugriff auf produktive Cloud-Infrastrukturen und zu lateraler Bewegung über CI/CD-Pipelines führen.

Wichtiger Hinweis: Zum Zeitpunkt der Veröffentlichung wurden keine Indikatoren einer Kompromittierung (Hashes, IP-Adressen, Domains), keine bestätigten Fälle realer Angriffe oder von Paketvergiftungen bereitgestellt. Die Einschätzung des Bedrohungsumfangs basiert auf der Analyse der Fähigkeiten des Implantats, nicht auf dokumentierten Vorfällen.

Empfehlungen zum Schutz

1. Audit der Secret-Speicherung: Stellen Sie sicher, dass NPM-, PyPI-, AWS-, Docker-, Kubernetes-Tokens und andere Secrets nicht im Klartext in Home-Verzeichnissen gespeichert werden. Verwenden Sie Secret-Manager und kurzlebige Tokens.
2. Monitoring von LD_PRELOAD: Überprüfen Sie die Umgebungsvariable LD_PRELOAD und die Datei /etc/ld.so.preload auf unerwartete Einträge.
3. Kontrolle von eBPF-Programmen: Nutzen Sie bpftool, um geladene BPF-Programme zu inventarisieren und anomale Module zu identifizieren.
4. Prüfung der PAM-Konfiguration: Überprüfen Sie regelmäßig die Dateien in /etc/pam.d/ sowie geladene PAM-Module auf unautorisierte Änderungen.
5. Überwachung getarnter Prozesse: Achten Sie auf Prozesse mit den Namen kworker oder ksoftirqd, die nicht den erwarteten Kernel-Threads entsprechen.
6. Prüfung von Persistenzmechanismen: Führen Sie ein Audit der systemd-Units, crontab-Jobs und .bashrc-Dateien auf verdächtige Einträge durch.
7. Rotation von Secrets: Rotieren Sie bei Verdacht auf eine Kompromittierung umgehend alle Tokens und Zugriffsschlüssel, die auf dem betroffenen System gespeichert waren.

Das beschriebene QLNX-Implantat zeigt einen Trend hin zu Malware, die speziell auf Entwicklungsinfrastrukturen ausgerichtet ist. Vorrangige Maßnahme für Security-Teams ist es, eine Inventarisierung der auf Entwicklerarbeitsplätzen im Klartext gespeicherten Secrets durchzuführen und diese in zentrale Secret-Stores mit Unterstützung für kurzlebige Tokens und Zugriffs-Audits zu überführen.