Wenn der nächste Auftrag dein System kompromittiert

Eine neue Betrugsmasche gegen Freelancer und Entwickler

Als Freelancer ist man es gewohnt, auf mehreren Plattformen gleichzeitig unterwegs zu sein. Ob über klassische Freelancer-Marktplätze, persönliche Kontakte oder Netzwerke wie Malt, Upwork oder ähnliche Plattformen – regelmäßig flattern neue Projektanfragen ins Postfach. Genau so eine Anfrage habe ich vor kurzem selbst erhalten.

Der Kontakt wirkte dabei völlig unauffällig. Entweder tritt jemand mit einem Firmenprofil auf, das zu einer etablierten Firma gehört, oder es ist eine reale Person mit Online-Präsenz, Projekthistorie und einer Vita, die nicht nach einem klassischen Fake aussieht. Nichts wirkt wie ein 08/15-Scam. Im Gegenteil: Genau diese Seriosität schafft Vertrauen.

Früher liefen solche Anfragen meist recht klassisch ab: ein erstes Gespräch, eine grobe Projektbeschreibung, vielleicht ein Call, in dem jemand erklärt, worum es technisch geht. Heute soll alles schneller gehen. „Schau dir doch kurz das Projekt an“, heißt es dann. Entweder bekommt man eine ZIP-Datei zugeschickt – was viele inzwischen zum Glück schon skeptisch macht – oder, deutlich subtiler, direkt Zugriff auf ein GitHub-Repository.

Ein ganz normales Repo. Sauber aufgebaut. Moderner Tech-Stack. Keine auffälligen Dateien. Kein obskurer Code. Genau deshalb habe ich mir das Repository zunächst ohne größere Bedenken angeschaut. Und genau hier beginnt die eigentliche Masche.

Wie der Angriff funktioniert – und warum man ihn nicht sofort erkennt

Die Methode ist perfide einfach und nutzt genau das aus, was für Entwickler Alltag ist: Vertrauen in bekannte Tools und gewohnte Workflows. Das Repository selbst enthält zunächst keinen offensichtlich schädlichen Code. Es sieht aus wie ein ganz normales Frontend- oder Fullstack-Projekt.

Der Schadcode wird nicht beim Klonen aktiv, sondern erst dann, wenn man das Projekt wie gewohnt startet – zum Beispiel mit npm run dev. Während viele Entwickler inzwischen sensibel gegenüber klassischen postinstall-Skripten sind (und diese teilweise bewusst deaktivieren), nutzen die Angreifer einen anderen Weg: parallele npm-Skripte.

Beim Starten des Projekts läuft unbemerkt ein zusätzliches Node-Script im Hintergrund, das nichts mit dem eigentlichen Projekt zu tun hat. Dieses Script lädt externen Code nach, führt ihn dynamisch aus und installiert sich dauerhaft im Benutzerverzeichnis. Von dort aus läuft es im Hintergrund weiter – völlig unabhängig davon, ob das eigentliche Projekt noch offen ist oder längst wieder geschlossen wurde.

Es gibt keinen Absturz, keine Warnung, keine verdächtige Konsolenausgabe. Das Projekt startet ganz normal. Und genau das macht diese Art von Angriff so gefährlich.

Was im Hintergrund tatsächlich passiert

Der nachgeladene Code fungiert als Infostealer und Backdoor zugleich. Er durchsucht das System nach Browser-Profilen, liest gespeicherte Zugangsdaten aus, entschlüsselt Passwörter, sammelt Cookies, Wallet-Daten, .env-Dateien und andere sensible Konfigurationsdateien.

Zusätzlich baut er eine dauerhafte Verbindung zu einem externen Command-and-Control-Server auf. Über diese Verbindung kann der Angreifer weitere Befehle ausführen, Dateien nachladen, Verzeichnisse auslesen oder beliebige Daten exfiltrieren – alles gesteuert aus der Ferne.

Besonders tückisch: Es wird kein klassischer Exploit verwendet. Es wird nichts „gehackt“. Es werden ausschließlich legitime Entwickler-Tools wie Node.js, npm und Socket-Verbindungen missbraucht. Genau deshalb greifen viele Schutzmechanismen hier nicht.

Warum diese Masche so effektiv ist

Diese Angriffe zielen nicht auf Server oder Produktionssysteme, sondern direkt auf Entwickler. Sie setzen darauf, dass wir regelmäßig fremden Code ausführen, weil genau das Teil unseres Berufs ist.

Reines Klonen eines Repositories ist in der Regel noch unkritisch. Die eigentliche Kompromittierung passiert erst, wenn der Code ausgeführt wird. Und in einem Projekt- oder Bewerbungsprozess ist genau das völlig normal.

Die Professionalität der Ansprache, der seriöse Kontext und ein technisch sauberes Repository sorgen dafür, dass die üblichen Alarmglocken oft zu spät angehen.

Fazit: Zero Trust – auch im Entwickleralltag

Diese Erfahrung hat mir sehr deutlich gezeigt, dass Sicherheitsdenken nicht erst in der Produktion beginnt. Auch lokale Entwicklungsumgebungen sind ein Angriffsziel. Gerade Freelancer, die täglich neue Projekte evaluieren, sind besonders attraktiv.

Die wichtigste Lehre daraus ist simpel, aber unbequem: Zero Trust. Auch wenn ein Repository professionell wirkt. Auch wenn der Kontakt seriös erscheint. Auch wenn es sich wie „nur kurz reinschauen“ anfühlt.

Unbekannte Projekte gehören nicht auf den Hauptrechner, nicht auf Maschinen mit produktiven Zugangsdaten und nicht in Umgebungen, in denen sensible Informationen liegen. Vertrauen ist gut – aber im Zweifel sollte Code erst in einer isolierten Umgebung laufen.

Diese Masche ist kein Einzelfall. Und sie wird mit Sicherheit nicht die letzte ihrer Art sein.