GitHub-Repos als Malware-Schleusen: 290 gefälschte Developer-Tools
ki-pentesting

GitHub-Repos als Malware-Schleusen: 290 gefälschte Developer-Tools

ki-pentesting3 unabhängige QuellenFlowKI Newsroom

Laut Bleeping Computer betreibt ein finanziell motivierter Angreifer derzeit knapp 300 gefälschte GitHub-Repositorys, die sich als legitime Software von Sicherheitsanbietern, Entwickler-Tools und etablierten Firmen ausgeben. Die Repositories verteilen einen Infostealer — Malware, die Zugangsdaten, Browserhistorien und Krypto-Wallets ausliest. Laut Help Net Security wurden dabei Hunderte bekannter Marken imitiert, die Repos beschäftigen sich vorwiegend mit Developer- und Security-Tools.

Die Mechanik ist klassisch: Der Angreifer erstellt ein Repository mit täuschend echtem Namen (beispielsweise leicht abgewandelte URL oder Schreibweise), befüllt es mit README-Dateien und Installationsskripten, die das Infostealer-Payload herunterladen und ausführen. Heise Security berichtet, dass die Fake-Repos zum Teil mehrere hundert Stars sammelten — ein Vertrauenssignal für unwissende Nutzer. Die Malware wird oft als komprimierte Datei oder als Teil eines Setup-Scripts getarnt.

Für DACH-Unternehmen entsteht hier ein doppeltes Risiko: Zum einen können Entwickler in Mittelstand und Konzernen unbewusst den Infostealer installieren, wenn sie schnell ein vermeintlich bekanntes Tool downloaden. Zum anderen zeigt sich hier ein Muster, das auch auf andere Infrastruktur übertragbar ist — die Masche funktioniert, weil GitHub-Verzeichnisse hohe Relevanz in Suchmaschinen und auf Stack Overflow haben. Aus DSGVO-Sicht ist relevant: Ein Infostealer auf Entwickler-Maschinen bedeutet Zugriff auf Firmen-Git-Credentials, Datenbank-Keys und möglicherweise Kundendaten in Repositories.

Developer-Teams sollten aktuell zwei konkrete Handgriffe durchführen: (1) Überprüfen, ob in browsing history oder lokalen Verzeichnissen unbekannte oder neu installierte GitHub-Repos auftauchen — Infostealer hinterlassen Log-Dateien. (2) Alle Git-Credentials und API-Token rotieren, falls Entwickler auf unbekannten Geräten tätig waren. Die Größe der Kampagne unterstreicht, warum Pentesting von LLM-Applikationen und deren Prompt-Injection-Anfälligkeit auch für interne Developer-Tools relevant wird — AI-gestützte Code-Generatoren könnten versehentlich solche Repos empfehlen.

GitHub hat die Repositories nach Meldung gelöscht, aber die Kampagne demonstriert ein Grundproblem: Vertrauen in Open-Source-Quellen bleibt fragil. Eine technische Ergänzung bietet die Safety-Pipeline für eigene LLM-Apps, die auch auf Developer-Tools anwendbar ist — Validierung von Abhängigkeiten und Quellen gehört in jeden Security-Prozess.

Quellen