Ein gefälschter Kunde hat mir diese Woche ein bösartiges GitHub-Repository in mein Postfach geschickt, und allein das Ausführen des Starter-Skripts löschte zwei Tage Arbeit und legte jedes Passwort offen, das ich in meinem Browser gespeichert habe.

Der „Kunde“ schaltete eine hochbezahlte Stelle als Senior Engineer, meldete sich schnell und schickte ein professionell wirkendes Repo. Die Anfrage war simpel: Klonen, npm run dev ausführen und einen Screenshot schicken, um zu beweisen, dass die Demo funktioniert – kein Vertrag, kein Hintergrundcheck. In dem Moment, als der Dev-Server startete, kontaktierte ein versteckter Code in einer Konfigurationsdatei einen Command-and-Control (C2)-Server, lud einen Second-Stage-Payload herunter und begann, Anmeldedaten vom lokalen Rechner abzusaugen.

Wie der Angriff ablief

Der bösartige Payload befand sich in postcss.config.js, einer Datei, die die meisten Entwickler nur flüchtig betrachten, da sie normalerweise nur eine Handvoll einfacher CSS-Verarbeitungsregeln enthält. In diesem Fall hängte der Angreifer eine Zeile mit verschleiertem JavaScript weit rechts neben einer legitimen Anweisung an, die mit Leerzeichen aufgefüllt wurde, um unauffällig zu wirken. Als der Befehl npm run dev die PostCSS-Pipeline ausführte, lief die versteckte Zeile unbemerkt mit.

Die Malware führte drei Schritte in schneller Folge aus:

  • C2-Kontakt – sie öffnete eine Netzwerkverbindung zu einem vom Angreifer kontrollierten Server und meldete den kompromittierten Host an.
  • Second-Stage-Download – sie lud zusätzlichen Code herunter, der die eigentliche Logik zur Datenexfiltration enthielt.
  • Diebstahl von Browser-Anmeldedaten – unter macOS fragte sie den Chrome Safe Storage Key aus dem System-Keychain ab. Wenn der Benutzer die Keychain-Abfrage bestätigte, erntete der Angreifer jedes in Chrome gespeicherte Passwort.

Über den unmittelbaren Diebstahl hinaus schrieb sich der Payload in mehrere gängige Entwickler-Tools – VS Code, npm, Discord – ein, sodass bei jedem zukünftigen Start dieser Anwendungen der bösartige Code erneut aktiviert wurde. Ein einfacher Neustart beseitigte die Infektion nicht; das nächste npm install oder das Öffnen des Editors reaktivierte die Backdoor.

Warnsignale, die oft übersehen werden

  • Anfragen, Code auszuführen, bevor ein Vertrag unterzeichnet wurde. Seriöse Einstellungsprozesse beinhalten in der Regel eine formelle Vereinbarung, bevor proprietäre Arbeit geteilt wird.
  • Komprimierte Dateien, die als „Projektbriefings“ getarnt sind. Zip- oder RAR-Archive können ausführbare Skripte oder bösartige Binärdateien verbergen.
  • Anfragen nach persönlichen E-Mail-Adressen, um „Plattformfilter zu umgehen“. Dieser Trick verlagert die Kommunikation von der geschützten Plattform weg, auf der Missbrauch gemeldet werden kann.
  • Stellenbeschreibungen, die vom Kandidaten verlangen, eine Krypto-Wallet zu finanzieren oder Test-Token zu kaufen. Solche Forderungen sind für echte Entwicklungsarbeit untypisch.

Praktische Schritte zur Sicherheit

  1. Führen Sie niemals Code von Fremden ohne Prüfung aus. Öffnen Sie das Repository in einer schreibgeschützten Ansicht (z. B. über die Raw-Dateiansicht auf GitHub) und scannen Sie jedes Skript, insbesondere Konfigurationsdateien und die Einträge unter scripts in der package.json.
  2. Behandeln Sie alle Anhänge als reinen Text. Wenn eine Zip-Datei gesendet wird, entpacken Sie diese in einer Sandbox-Umgebung und untersuchen Sie den Inhalt, bevor Sie etwas öffnen.
  3. Verwenden Sie einen dedizierten Passwortmanager anstelle der Browser-Speicherung. Selbst wenn der Keychain des Browsers kompromittiert wird, bleibt der Tresor des Managers isoliert.
  4. Führen Sie nicht vertrauenswürdigen Code in einer isolierten virtuellen Maschine oder einem Container ohne Netzwerkzugriff aus. Dies verhindert, dass der Angreifer einen C2-Server erreichen kann.
  5. Aktivieren Sie die Zwei-Faktor-Authentifizierung (2FA) für alle Konten. Wenn ein Passwort gestohlen wird, verhindert der zweite Faktor unbefugte Logins.
  6. Halten Sie Entwickler-Tools auf dem neuesten Stand und aktivieren Sie, falls verfügbar, automatische Integritätsprüfungen. Einige Editoren warnen mittlerweile, wenn Core-Dateien unerwartet geändert werden.

Wenn Sie vermuten, bösartigen Code ausgeführt zu haben, gehen Sie davon aus, dass das System kompromittiert ist. Sichern Sie wichtige Daten, löschen Sie die Festplatte und installieren Sie das Betriebssystem neu. Ein einfacher Neustart wird einen Persistenzmechanismus, der Dateien in gängigen Anwendungen umschreibt, nicht beseitigen.

Fazit: Eine einzige Zeile versteckten JavaScript kann eine routinemäßige Demo in eine massive Operation zum Diebstahl von Anmeldedaten verwandeln. Behandeln Sie jedes Repository als nicht vertrauenswürdig, bis Sie es verifiziert haben, und machen Sie Isolation zu einem Standardbestandteil Ihres Workflows. Die Kosten eines Moments der Eile überwiegen bei weitem den Aufwand, eine Datei doppelt zu prüfen.