Cyberbedrohungen
Über Code-Repositorys Malware verbreiten
Wir haben Void Dokkaebi-Kampagnen gefunden, die infizierte Entwickler-Repositorys als Kanäle zur Verbreitung von Malware nutzen. So kann sich die Bedrohung von einem einzelnen Kompromittierungsfall zu einem umfassenderen Risiko für die Lieferkette ausweiten.
Save to Folio
Wichtige Erkenntnisse
- Void Dokkaebi (auch Famous Chollima) hat sich von Social-Engineering-Angriffen auf einzelne Ziele zu einer sich selbst verbreitenden Bedrohung für die Lieferkette entwickelt. Das kompromittierte Repository eines Entwicklers wird zum Infektionsvektor für die nächste Welle von Opfern und erzeugt so eine wurmartige Verbreitungskette durch das Entwickler-Ökosystem.
- Die Kampagne verbreitet sich über vertrauenswürdige Entwicklungs-Workflows unter Verwendung bösartiger VS-Code-Aufgaben und eingeschleusten Codes, die während normaler Entwicklungsaktivitäten ausgeführt werden können.
- Eine Analyse identifizierte mehr als 750 infizierte Repositorys, über 500 bösartige VS-Code-Aufgabenkonfigurationen und 101 Instanzen des Tools zur Manipulation von Commits.
- Die Kampagne nutzt Blockchain-Infrastrukturen für die Bereitstellung der Payloads, darunter Tron, Aptos und Binance Smart Chain, wodurch Teile ihrer Bereitstellungsinfrastruktur außerhalb der Reichweite herkömmlicher Sperrmaßnahmen liegen.
Void Dokkaebi, auch Famous Chollima, ist eine Nordkorea nahestehende Hackergruppe, die Entwickler mit Zugangsdaten für Kryptowährungs-Wallets, Signaturschlüssel sowie Zugriff auf CI/CD-Pipelines und die Produktionsinfrastruktur ins Visier nimmt. Die Gruppe gibt sich als Personalvermittler von Kryptowährungs- und KI-Unternehmen aus und verführt Entwickler im Rahmen vorgetäuschter Vorstellungsgespräche dazu, Code-Repositorys zu klonen und auszuführen. Dies ist ein Muster, das seit 2024 branchenweit beobachtet wird, doch wurde dem, was nach der anfänglichen Kompromittierung geschieht, bisher weniger Aufmerksamkeit geschenkt.
Der kompromittierte Rechner wird zu einer Startrampe, wobei der Angreifer die Repositorys des Opfers und dessen Code-Beiträge in Infektionsvektoren für nachgelagerte Entwickler verwandelt. Das Ergebnis ist eine sich selbst ausbreitende Kette, die eher dem Verhalten eines Wurms ähnelt als einem traditionellen gezielten Angriff.
Die Infektionswege
Die Verbreitung beruht auf zwei unterschiedlichen Mechanismen, die zusammenwirken.
Ablauf 1: Die Infektion beginnt mit einem vorgetäuschten Vorstellungsgespräch, bei dem das Opfer gebeten wird, ein Code-Repository zu klonen und es im Rahmen einer technischen Bewertung zu überprüfen oder auszuführen. Die Repositorys werden auf GitHub, GitLab oder Bitbucket gehostet und sehen wie legitime Programmierprojekte aus. Der Übertragungsmechanismus missbraucht das Workspace-Task-System von VS Code. Das Entwickler-Ökosystem ist zu diesem Zeitpunkt bereits kompromittiert, doch das wurmartige Verhalten beginnt erst, wenn das Opfer diesen Code auf GitHub committet. Jeder Entwickler, der dieses Repository anschließend klont und in VS Code öffnet, erhält dieselbe Vertrauensabfrage. Wird diese akzeptiert, wiederholt sich der Zyklus.
Dadurch entsteht eine sich selbst verbreitende Kette. Jeder kompromittierte Entwickler versieht neue Repositorys mit dem Infektionsvektor, und jedes neue Opfer wird zu einem potenziellen Verbreiter. Im Gegensatz zu traditionellem Social Engineering, bei dem der Angriff mit dem ursprünglichen Ziel endet, erweitert sich hier der Infektionsbereich mit jedem Commit.
Ablauf 2: Parallel dazu beobachteten wir einen zweiten Verbreitungsmechanismus. Bei Benutzern, die bereits von Void Dokkaebi kompromittiert waren, wurde mehrstufiger, verschleierter JavaScript-Code zu den Quellcode-Dateien in ihren Repositorys hinzugefügt. Der Angreifer zielt auf verschiedene Konfigurationsdateien und gängige Einstiegspunkte ab und wählt dabei Dateien aus, die Entwickler weniger genau unter die Lupe nehmen. Die technischen Einzelheiten dazu beinhaltet der Originalbeitrag.
In einigen kompromittierten Repositorys stellten wir fest, dass beide Techniken gleichzeitig vorhanden waren. Wir gehen davon aus, dass es Fälle gab, in denen Entwickler getrennt voneinander Opfer beider Verbreitungsmethoden wurden, aber auch Fälle, in denen die Angreifer beide Techniken bei einem einzigen Opfer einsetzten.
Dieser Mechanismus der „Doppelinfektion“ sorgt für Redundanz. Die Datei tasks.json erwischt Entwickler, die VS Code verwenden (Auslösung beim Öffnen eines Ordners), während das eingeschleuste JavaScript bei jedem ausgeführt wird, der das Projekt erstellt oder ausführt, unabhängig von der verwendeten IDE. Zusammen garantieren sie die Ausführung der Malware.
Der organisatorische Verstärker
Die wurmartige Verbreitung stellt ein höheres Risiko dar, wenn sie Entwickler erreicht, die über Commit-Zugriff auf Repositorys von Organisationen oder beliebte Open Source-Repositorys verfügen, etwa DataStax oder auch Neutralinojs. Hier wurden bösartige Code-Schnipsel gefunden, die mit diesen Techniken übereinstimmen. Die Indikatoren deuten auf ein Szenario hin, bei dem ein Mitwirkender mit Commit-Zugriff zunächst durch Social-Engineering-Tricks kompromittiert wurde (Ablauf 1), was anschließend die Infektion der Repositorys der Organisation ermöglichte (Ablauf 2). Sobald ein Repository dieser Größenordnung kompromittiert ist, wird jeder Mitwirkende, jeder Fork und jedes nachgelagerte Projekt, das davon abhängt, zu einem potenziellen Opfer. Dies erweitert den Umfang der Kampagne von einem einzelnen Entwickler auf ein gesamtes Ökosystem.
Dieses Ausbreitungsmodell unterscheidet sich grundlegend von traditionellen Supply-Chain-Angriffen. Hier wird kein Build-System angegriffen. Der Angriff nutzt etwas weitaus Einfacheres aus:
- Gewohnheiten im Entwickler-Workflow
- Die Tendenz, .vscode-Ordner nicht in gitignore aufzunehmen
- Konfigurationsdateien nicht Zeile für Zeile zu überprüfen
- Das Vertrauen in den Inhalt der eigenen Repositorys
Diese Kampagne verbreitet sich durch das Vertrauen in Entwicklungstools, in die Commits von Kollegen und in Open-Source-Projekte. Die Malware, die diese Infektionsvektoren übertragen ist eine DEV#POPPER RAT-Variante. Einzelheiten dazu liefert der Originalbeitrag. Zwei Aspekte dieser Variante sind für das Verbreitungsmodell von direkter Relevanz:
- Die RAT erkennt und umgeht gezielt CI/CD-Umgebungen (z. B. GitLab CI, BuildBot) und Cloud-Sandboxes und wird ausschließlich auf echten Entwickler-Workstations ausgeführt. Das bedeutet, dass automatisierte Pipeline-Scans sie vollständig übersehen werden.
- Zur Persistenz injiziert es versionierten Code in Entwickleranwendungen (z. B. Antigravity, VS Code, Cursor, Discord, GitHub Desktop) und erstellt einen versteckten .node_modules-Ordner, um die Suchreihenfolge der Node.js-Module zu manipulieren. Diese Persistenz in den Entwicklertools schafft zusätzliche Möglichkeiten für die zuvor beschriebene wurmartige Verbreitung.
Kontamination
Um die Reichweite der Kampagne zu quantifizieren, haben wir Ende März 2026 öffentliche Code-Hosting-Plattformen gescannt. Die folgenden Statistiken bieten einen Überblick über die Kontamination in öffentlichen Repositorys.
Das tatsächliche Ausmaß der Kontamination ist wahrscheinlich größer. Der Überblick enthält keine Repositorys, die vor unserem Scan identifiziert und bereinigt wurden, keine privaten Repositorys, die nicht von öffentlichen Suchmaschinen indiziert werden, sowie keine Forks oder Klone, die die Infektion auf Umgebungen übertragen haben, die wir nicht beobachten können. Die Zahlen spiegeln zudem die nachgelagerten Auswirkungen der kaskadierenden Ausbreitung wider und nicht die Anzahl der einzeln kompromittierten Entwickler.
Praktische Empfehlungen
Die folgenden Empfehlungen beziehen sich direkt auf die Mechanismen, auf die sich Void Dokkaebi zur Verbreitung und Persistenz stützt. Sie sind nach ihrer Auswirkung priorisiert:
- Verwenden Sie isolierte Umgebungen für Programmieraufgaben im Rahmen von Vorstellungsgesprächen. Verwenden Sie virtuelle Einwegumgebungen, die nach der Bewertung gelöscht werden. Dies ist die mit Abstand effektivste Methode, um die anfängliche Kompromittierung zu verhindern.
- Fügen Sie .vscode/ zu .gitignore hinzu und setzen Sie dies in allen Repositorys der Organisation durch. Dies unterbricht den passiven Wurmverbreitungsweg vollständig.
- Setzen Sie Zweigschutz und signierte Commits durch. Blockieren Sie Force-Pushes, verlangen Sie Pull-Anfragen und verlangen Sie GPG- oder SSH-signierte Commits. Diese Kontrollen neutralisieren es direkt.
- Überprüfen Sie Repositorys auf bekannte Infektionsmerkmale. Suchen Sie in Quellcode-Dateien nach „global['!']“ und „global['_V']“ und prüfen Sie auf „temp_auto_push.bat“. Wenn Sie etwas finden, gehen Sie davon aus, dass die Entwickler-Workstation kompromittiert wurde. Isolieren Sie den Rechner, widerrufen Sie Zugangsdaten und benachrichtigen Sie Mitarbeiter und nachgelagerte Nutzer.
- Überprüfen Sie Änderungen an Konfigurationsdateien genau. Dateien wie postcss.config.mjs, tailwind.config.js, eslint.config.mjs und next.config.mjs sind besonders anfällig, da sie selten genau überprüft werden. Achten Sie auf Inhalte, die über den sichtbaren Bildschirmbereich hinausgehen.
- Überwachen Sie den Datenverkehr von Blockchain-APIs und C&C-Servern. Ausgehende Verbindungen zu api.trongrid.io, fullnode.mainnet.aptoslabs.com und Binance Smart Chain RPC-Endpunkten von Entwickler-Workstations sind hochgradig zuverlässige Indikatoren. Überwachen Sie zusätzlich Verbindungen zum MongoDB-Port 27017 und die HTTP-Muster /u/f und /verify-human/[VERSION].
- Verlassen Sie sich nicht ausschließlich auf das Scannen der CI/CD-Pipeline. Die RAT erkennt und umgeht CI/CD-Umgebungen. Eine Erkennung auf Endpunkt-Ebene auf Entwickler-Workstations ist unerlässlich.
- Behandeln Sie Vertrauensabfragen im VS Code-Arbeitsbereich als Sicherheitsentscheidung. Überprüfen Sie die Datei .vscode/tasks.json auf „runOn: folderOpen“-Aufgaben, bevor Sie Vertrauen gewähren.
- Wenden Sie Netzwerk-Blockierungen für bekannte Infrastrukturen an.
- Beziehen Sie interviewbasiertes Social Engineering in die Sicherheitsschulungen ein.
Fazit
Die jüngsten Aktivitäten von Void Dokkaebi stellen eine Veränderung in der Funktionsweise von Supply-Chain-Angriffen dar. Ein einziger kompromittierter Entwickler wird zum Ausgangspunkt einer Infektion, die sich über persönliche Repositorys, Codebasen von Organisationen und beliebte Open-Source-Projekte ausbreitet, ohne dass weiteres Social Engineering erforderlich ist.
Das Ausmaß der Infektion bestätigt zudem, dass es sich um eine aktive und sich ausbreitende Kampagne handelt. Unternehmen, die Entwickler-Workstations und Repository-Workflows als Teil ihrer Angriffsfläche betrachten, sind besser in der Lage, diese Bedrohung zu erkennen und zu unterbinden, bevor sie sich weiter ausbreitet.