GitVenom Fake-Jobangebote und GitHub-Repos als Malware-Falle

Anbieter zum Thema

MicroConsult Academy GmbH

emlix GmbH

RTI Real-Time Innovations

Kriminelle nutzen gefälschte Jobangebote, um Entwickler zum Ausführen von Malware-Code zu bringen. Die Angriffe sind technisch ausgefeilt und richten sich gezielt an Software-Entwickler mit GitHub-Erfahrung.

Immer mehr Software-Entwickler geraten über scheinbar seriöse Jobangebote ins Visier von Cyberkriminellen. Der Einstieg ist fast immer harmlos: eine Kontaktaufnahme per Mail oder LinkedIn, ein gut bezahltes Projekt, ein kurzer Coding-Test. Doch genau hier beginnt das Risiko.

Die internationale Entwickler-Community hat über Seiten wie Dev.to bereits im vergangenen Jahr vor der Masche gewarnt. Doch wie ein aktueller Bericht auf heise.de zeigt, ist diese Form von Malware-Attacke mittlerweile auch hierzulande anzutreffen.

Im konkreten Fall hatte ein Freelancer auf einer Vermittlungsplattform für Software-Entwickler ein Jobangebot erhalten, dass mit einem Zugang auf ein privates Git-Repository verbunden war. Das reine Klonen des Repos ist unproblematisch. Gefährlich wird es erst beim Starten des Projekts, etwa mit npm run. Dann wird ein verstecktes Node-Skript ausgeführt, das weiteren Schadcode aus dem Netz nachlädt und dauerhaft im System verankert.

Der nachgeladene Code verbindet sich mit einem Command-and-Control-Server und installiert Infostealer-Funktionen. Diese durchsuchen den Rechner nach Browser-Profilen, entschlüsseln gespeicherte Zugangsdaten und sammeln Cookies, Wallet-Daten und sensible Dateien wie .env. Die Auswertung stammt aus einem realen Analysefall, den ein betroffener Entwickler selbst durchgeführt hat.

Wie die Angriffe technisch funktionieren

Die Repositories wirken auf den ersten Blick seriös. Ordentliche Ordnerstrukturen, realistische Abhängigkeiten, ausführliche READMEs und eine glaubwürdige Commit-Historie gehören zum Standard. Laut Sicherheitsforschern versteckt sich der Schadcode oft in unscheinbaren Dateien oder wird erst zur Laufzeit aktiviert.

Bekannt ist diese Masche unter dem Namen „GitVenom“. Sicherheitsforscher von Kaspersky beobachten entsprechende Kampagnen seit rund drei Jahren. Weltweit wurden bereits hunderte bösartige Repositories identifiziert, die gezielt Entwickler angreifen.

Technisch setzen die Angreifer unter anderem auf stark verschleierten Code, Base64-kodierte Funktionsnamen oder manipulierte Abhängigkeiten. Teilweise steckt Malware sogar in Dateien, die normalerweise niemand genauer prüft, etwa Lizenztexte oder scheinbar ungenutzte Skripte.

Warnzeichen, die Entwickler ernst nehmen sollten

Entwickler werden im Rahmen dieser fingierten Stellen- oder Auftragsangebote aufgefordert, für einen „Eignungstest“ oder im Rahmen eines anstehenden „Job-Interviews“ fremden Code herunterzuladen und lokal auszuführen. Die Angreifer setzen darauf, dass ein solches Vorgehen den Opfern nicht ungewöhnlich vorkommt.

Daher lohnt es sich, bei solchen vermittelten oder gerade bei unaufgeforderten Stellenangeboten, misstrauisch zu sein. Bestimmte Muster, die auf Social Engineering setzen, tauchen in vielen dieser Fälle immer wieder auf. Dazu zählen etwa unaufgeforderte Jobangebote, die fachlich perfekt passen und ungewöhnlich gut bezahlt sind, ebenso wie Zeitdruck im Bewerbungsprozess.

Weitere technische Red Flags sind großflächig verteilter Base64-Code, Dateien ohne erkennbare Funktion, widersprüchliche README-Beschreibungen oder Abhängigkeiten, die nicht zum Projekt passen. Auch das Umfeld des Repositories kann Hinweise liefern: Ganz neue GitHub-Accounts ohne Historie, mehrere nahezu identische Projekte vom selben Account oder künstlich wirkende Contributor-Profile sollten Entwickler skeptisch machen. GitHub selbst kann in solchen Fällen oft wenig tun, insbesondere wenn es sich um private Repositories handelt.

Schutzmaßnahmen im Entwickleralltag

Der wichtigste Schutz ist Verifikation. Entwickler sollten Firmen unabhängig recherchieren, Stellenausschreibungen auf offiziellen Webseiten suchen und auf Video-Gespräche bestehen. Seriöse Auftraggeber können ihr Unternehmen und ihr Projekt schlüssig erklären.

Technisch empfiehlt es sich, unbekannten Code grundsätzlich isoliert auszuführen, etwa in virtuellen Maschinen, Containern oder separaten Benutzerkonten. Produktiv- und Testumgebungen sollten strikt getrennt sein. Wer fremden Code prüft, sollte sich jede Datei ansehen, auch die vermeintlich langweiligen.

Die Angriffe zeigen, dass Malware-Angriffe nicht mehr länger nur auf technisch unerfahrene Privatpersonen oder auf Unternehmensstrukturen, sondern mittlerweile auch auf fachlich versierte Entwickler selbst abzielen. Ein gesundes Maß an Skepsis, saubere Trennung von Umgebungen und die Bereitschaft, ein Angebot auch abzulehnen, gehören inzwischen zur professionellen Sicherheitsstrategie.(sg)

(ID:50679993)