FakeGit ist zurück: 17.610 schädliche GitHub-Repos
Die Malware-Kampagne FakeGit ist auf GitHub wieder aktiv, und sie ist größer als zuvor. Forscher zählen 17.610 gefälschte Repositories, die die Malware SmartLoader verbreiten. Anfang des Monats war die Kampagne zurückgekehrt, um den Infostealer StealC zu verteilen.
Die Erkenntnisse stammen von Apiiro, einem Unternehmen, das sich auf die Sicherheit von Software-Lieferketten spezialisiert hat. Nach Angaben der Forscher nahm FakeGit am 4. Oktober seine Aktivitäten wieder auf.
Die meisten Konten hinter den Repositories wirken wie Wegwerfprofile, die eigens für die Kampagne angelegt wurden. Die Forscher fanden jedoch auch mindestens 700 Konten, die offenbar echten Entwicklern gehören.
Ein Loader, getarnt als Download
Der Aufbau ist simpel. Jedes schädliche Repository enthält eine README-Datei mit ausgefeilter Anleitung und einem Download-Button. Dieser Button führt zu einem ZIP-Archiv mit SmartLoader, der Schadsoftware der ersten Stufe. Die Aufgabe von SmartLoader ist es, weitere Malware auf den Rechner des Opfers zu laden und zu installieren.
Aktivitäten dieser Art, mit wechselnden Schadprogrammen, werden seit mindestens Januar beobachtet. Den Namen FakeGit erhielt die Kampagne im Juli, als Island, ein Anbieter einer Browser-Plattform für Unternehmen, über 7.600 gefälschte GitHub-Repositories berichtete, die SmartLoader verbreiteten.
In diesem Bericht wies Island darauf hin, dass sich 800 der Repositories als KI-Skills oder MCP-Server ausgaben. MCP-Server sind Komponenten, über die sich KI-Assistenten mit externen Werkzeugen und Daten verbinden können. Diese gefälschten Einträge tauchten in öffentlichen KI-Registern und -Katalogen auf, in denen Entwickler nach Erweiterungen suchen.
13.000 Repos in 34 Stunden umgelenkt
Laut Apiiro verlief die jüngste Welle sehr schnell. Innerhalb von 34 Stunden änderte FakeGit mehr als 13.000 Repositories. In der Spitze nahm sich der Betreiber 2.999 Repositories pro Stunde vor.
Die Änderungen waren klein und gezielt. "In den Commits, die wir stichprobenartig untersucht haben, betrafen 97 % nur die README, und 88 % ließen deren 'Download'-Button auf ein ZIP verweisen, das SmartLoader installiert", so Apiiro.
Dieses Detail ist wichtig. Der Angreifer musste für diese Runde keine neue Infrastruktur aufbauen.
"Niemand musste auch nur ein einziges neues Repo anlegen. Die Flotte war bereits da. Sie wurde einfach neu ausgerichtet", erklärten die Forscher.
Warum Löschungen bisher nicht greifen
Apiiro führt die Hartnäckigkeit von FakeGit darauf zurück, wie Entfernungen gehandhabt werden. Repositories werden anhand von Listen gelöscht, und diese Listen erfassen nur einen Teil der schädlichen Flotte.
Auch das Sperren der Schadprogramme reicht nicht aus. Gesperrte Dateien und ihre Sicherungskopien bleiben oft erreichbar, sodass der Betreiber einfach den Download-Link anpassen und dasselbe Repository online halten kann.
Auch die Threat-Intelligence-Feeds hinkten hinterher. "71 % der Flotte fehlten vor unserem Bericht in URLhaus, und eine DNS-Sperrliste auf Domain-Ebene kann keine einzelne Datei auf GitHub blockieren, ohne GitHub zu blockieren", merkt Apiiro an. URLhaus ist eine öffentliche Datenbank, die URLs zur Verbreitung von Malware erfasst.
Die schädlichen Archive lagen an vielen Stellen auf GitHub verteilt. Die Forscher fanden sie in Forks, älteren Dateien, Release-Assets, Anhängen von Issues und eigens angelegten Repositories, die nur als Download-Quelle dienten. Gegen eine solche Streuung bringt es wenig, Links einzeln zu entfernen.
"Löscht man eine Datei, kann der Betreiber den Köder auf eine Ersatzkopie umlenken: einen Fork, ein älteres ZIP, ein Release-Asset oder einen Issue-Anhang", sagten die Forscher.
Was Apiiro empfiehlt
Die Forscher raten, vor jedem Download zu prüfen, wem ein Repository gehört. KI-Skills und MCP-Server sollten nur aus offiziellen Registern oder aus den eigenen Repositories des Anbieters bezogen werden.
Wer vermutet, dass SmartLoader auf seinem System ausgeführt wurde, sollte das als mögliche Kompromittierung seines GitHub-Kontos behandeln. Das bedeutet: aktive Sitzungen und Zugriffstoken widerrufen und für die Anmeldung auf Passkeys umsteigen.
Unsere Einschätzung
FakeGit zeigt, dass die Schwachstelle nicht mehr nur die Malware selbst ist, sondern das Vertrauen, das Entwickler einer vertrauten Plattform entgegenbringen. Eine GitHub-Seite mit einer ordentlichen README und einem Download-Button wirkt alltäglich, und genau darauf setzt der Betreiber. Laufende Arbeiten an Schutzmechanismen auf Plattformseite, etwa GitHubs Push-Protection-Funktionen, zielen auf andere Risiken und scheinen Köder in README-Dateien nicht zu erfassen.
Die Kampagne passt auch in ein größeres Muster, bei dem Angreifer Entwickler-Ökosysteme als Verbreitungskanäle nutzen, ähnlich wie bei schädlichen npm-Paketen, die gezielt Programmierer erreichen sollen. Der Einsatz gefälschter KI-Skills und MCP-Server deutet darauf hin, dass Angreifer Entwicklern in neuere, weniger ausgereifte Kataloge folgen, in denen die Prüfung möglicherweise lückenhafter ist.
Auffällig sind die 700 Konten, die offenbar echten Entwicklern gehören. Falls diese Konten gekapert wurden, könnten gestohlene Zugangsdaten das Wachstum der Kampagne befeuern. Das macht die Empfehlung, Token zu widerrufen und Passkeys einzuführen, umso dringlicher, auch wenn Passkeys sich noch immer nur schleppend durchsetzen, selbst unter Sicherheitsexperten.
Es lohnt sich zu beobachten, ob GitHub seinen Umgang mit solchen Inhalten ändert und von listenbasierten Löschungen dazu übergeht, Forks, Release-Assets und Anhänge gemeinsam zu bereinigen. Bis dahin kann die Flotte einfach erneut umgelenkt werden.