Zurück
2026/11/11
Das heruntergeladene Sicherheitstool ist die Malware: Gefälschte GitHub-Repos infizieren über 2.000 Windows-PCs
Doctor Web fand auf GitHub gefälschte Sicherheitstools, die beim Build Malware ausführen. So funktioniert die Falle und das sollten Sie vorher prüfen.
Sie finden auf GitHub ein kleines Hilfsprogramm, das die Ausgabe eines Netzwerkscanners aufbereitet. Es hat eine README, ein Visual-Studio-Projekt und eine Build-Anleitung. Sie klonen es und klicken auf Erstellen. Nichts wirkt verdächtig, doch noch bevor der Compiler startet, ist auf Ihrer Workstation bereits ein versteckter Befehl gelaufen.
Diese Falle hat Doctor Web am 5. November 2026 beschrieben. Die Forscher fanden GitHub-Repositories, die sich als Werkzeuge für Scan-Automatisierung, Sicherheitstests und Loganalyse ausgaben, und zählten zum Zeitpunkt der Untersuchung mehr als 2.000 infizierte Windows-PCs. Dieser Artikel erklärt, wie die Falle funktioniert, warum sie auch erfahrene Engineers erwischt und was Sie prüfen sollten, bevor Sie gerade geklonten Code bauen.
Das Wichtigste in Kürze
- Die Repositories geben sich als Sicherheitswerkzeuge aus, und der schädliche Befehl läuft beim Build oder beim Start eines Skripts, ohne dass ein separates Programm gestartet werden muss.
- Der Code versteckt sich in Visual-Studio-Projektdateien, in
.suo-Dateien und hinter langen Folgen von Leerzeichen in Python- und Go-Quelltexten. - Die eigentlichen Schadprogramme sind zwei AsyncRAT-Backdoors, ein Clipper, der Krypto-Wallet-Adressen in der Zwischenablage austauscht, und ein Infostealer, der Browserdaten, VPN- und FTP-Einstellungen sowie Discord-Tokens stiehlt.
- Lesen Sie die Build-Dateien, bevor Sie bauen, und bauen Sie unbekannten Code in einer Wegwerf-VM, die keine Zugangsdaten enthält.
- Wenn Sie eines dieser Projekte bereits gebaut haben, betrachten Sie die Workstation als kompromittiert und ändern Sie alle darauf gespeicherten Zugangsdaten von einem sauberen Gerät aus.
Was Doctor Web gefunden hat
Laut dem Bericht von Doctor Web tauchten die ersten infizierten Repositories vor etwa zwei Jahren auf. Damals richteten sie sich an Nutzer von Krypto-Wallets und wurden als Blockchain-Spiele, Spiel-Bots und Cheats präsentiert. Inzwischen haben die Betreiber IT-Sicherheitsfachleute ins Visier genommen. Eines der gefälschten Repositories enthielt ein Skript, das die Ausgabe des Netzwerkscanners Fscan parst, bereinigt und formatiert.
Es handelt sich nicht um eine Software-Schwachstelle, und es gibt keine CVE, die man patchen könnte. Es ist eine Supply-Chain- und Social-Engineering-Kampagne: Die Angreifer veröffentlichen ein nützlich wirkendes Projekt und warten, bis jemand es baut. Die Zusammenfassung von BleepingComputer bezeichnet den Leerzeichen-Trick als alte Technik, die sich weiterhin als wirksam erweist.
Wie die Falle funktioniert
Doctor Web fand den Schadcode in drei Arten von Dateien. Keine davon ist die Datei, die ein Reviewer normalerweise zuerst öffnet.
| Wo er sich versteckt | Was passiert | Warum er leicht übersehen wird |
|---|---|---|
Projektdatei .csproj | Ein PreBuildEvent führt vor dem Kompilieren einen Befehl aus | Reviewer lesen den Quellcode, nicht die Projektdatei |
.suo-Datei | Die Datei enthält einen PowerShell-Befehl | Es ist eine binäre Einstellungsdatei, die Visual Studio normalerweise in einem versteckten Ordner ablegt |
| Python- und Go-Quelldateien | Der Schadcode steht hinter einer großen Zahl von Leerzeichen | Die Zeile wirkt leer, solange Sie nicht weit nach rechts scrollen oder den Zeilenumbruch einschalten |
Ab hier ist die Kette immer gleich. Ein PowerShell-Skript (der Bericht nennt C:\Users\Public\Pictures\t.ps1 und L.ps1 als Beispiele) fragt bei den Servern der Angreifer oder bei legitimen Diensten wie YouTube, Telegram, Google Docs, GitCode und Pastebin eine verschlüsselte Zeichenkette ab. Entschlüsselt ergibt sie einen Download-Link für ein Archiv, das nach C:\ProgramData\Windows.Microsoft.Photos entpackt wird.
Darin steckt ein Electron-basierter Loader namens Microsoft.exe, den Doctor Web als Trojan.Loader.3261 erkennt. Der Loader meldet Systeminformationen über einen Telegram-Bot, versucht höhere Rechte zu erlangen und schaltet Windows Defender, die Benutzerkontensteuerung, Benachrichtigungen, die Systemwiederherstellung und Volumeschattenkopien ab. Außerdem versucht er, Produkte von ESET, McAfee und Malwarebytes zu entfernen, und ändert die hosts-Datei, um Domains von Antivirenherstellern zu blockieren.
Um unentdeckt zu bleiben, lässt der Loader im Standardmodus explorer.exe als seinen übergeordneten Prozess erscheinen, ändert den Registry-Wert VerifiedAndReputablePolicyState, um Smart App Control zu umgehen, stellt den Originalcode von ntdll.dll wieder her, um die dort von Sicherheitsprodukten gesetzten Hooks zu entfernen, nutzt direkte Systemaufrufe und patcht die Windows-Funktionen für Ereignisablaufverfolgung und Skriptprüfung. Anschließend injiziert er seine Schadprogramme in legitime Windows-Prozesse wie RegAsm.exe.
Drei Schadprogramme folgen:
- Zwei AsyncRAT-Backdoors. Die Dateien sind identisch, nutzen aber unterschiedliche Netzwerkports; laut Doctor Web könnten so zwei Betreiber dasselbe Gerät gleichzeitig steuern.
- Ein Clipper. Er tauscht Krypto-Wallet-Adressen in der Zwischenablage aus und sendet Screenshots, den Titel des aktiven Fensters, den Benutzernamen und die IP-Adresse an einen Telegram-Bot.
- Ein Infostealer (JS.Stealer.191). Er prüft auf Sandboxes und virtuelle Maschinen und sammelt dann Browserdaten, Verbindungsdateien von FileZilla, MobaXterm und Total Commander, VPN-Einstellungen, Messenger-Dateien, Daten von Spielekonten und Discord-Tokens, die er über einen Telegram-Bot verschickt.
Doctor Web fand außerdem eine unfertige Komponente, die einen Windows-Dienst installieren und den Loader erneut herunterladen würde, falls er gelöscht wird. Das deutet darauf hin, dass die Betreiber ihr Werkzeugset weiterentwickeln.
Warum es bei Profis funktioniert
Die Kampagne baut auf Gewohnheiten auf, die normalerweise als gute Praxis gelten.
- Aus dem Quellcode zu bauen fühlt sich sicherer an, als einen Download auszuführen. Viele Engineers weigern sich, ein unbekanntes Binary zu starten, kompilieren aber bereitwillig ein Projekt, weil sie den Code lesen können. Hier ist der gelesene Code sauber, und der Befehl steckt in der Build-Konfiguration.
- Es gibt keinen Moment „dieses Programm starten“. Der Befehl läuft als Teil eines gewöhnlichen Builds, sodass das übliche Innehalten vor dem Start eines unbekannten Programms nie kommt.
- GitHub gilt als vertrauenswürdig. Ein Repository mit ordentlicher README und Installationsanleitung sieht aus wie Tausende ehrliche Projekte. Doctor Web weist darauf hin, dass die Angreifer sogar Anleitungen zur Installation von Visual Studio und zum Klonen des Repositorys lieferten.
- Die Workstation eines Engineers hält die Schlüssel. Gespeicherte Browsersitzungen, VPN-Profile und Server-Verbindungsdateien sind genau das, was der Infostealer sammelt, und sie öffnen oft den Weg in Produktivsysteme und Kundenumgebungen.
Was Sie vor dem Build prüfen sollten
Diese Prüfungen dauern wenige Minuten und funktionieren für jedes gerade geklonte Projekt, unter Windows, Linux oder macOS. Führen Sie sie im Repository-Ordner aus, bevor Sie das Projekt in einer IDE öffnen.
# 1. Build hooks and command execution in project files
grep -rniE 'PreBuildEvent|PostBuildEvent|<Exec |powershell|cmd\.exe' \
--include='*.csproj' --include='*.vbproj' --include='*.vcxproj' \
--include='*.props' --include='*.targets' .
# 2. Visual Studio user-option files that should not be in a repository
find . -name '*.suo'
# 3. Files with very long runs of spaces or tabs on one line
grep -rlE '[[:space:]]{200,}' .
Unter Windows ohne Unix-ähnliche Shell erledigt PowerShell die Leerzeichen-Prüfung:
Get-ChildItem -Recurse -File |
Select-String -Pattern '\s{200,}' -List |
Select-Object -ExpandProperty Path
Ein Treffer ist kein Beweis für Malware. Viele ehrliche Projekte nutzen Build-Events, und minifizierte Dateien enthalten lange Zeilen. Er ist ein Anlass, die Datei zu öffnen und zu lesen, was der Befehl tut, bevor irgendetwas ausgeführt wird.
- Lesen Sie zuerst die Build-Dateien. Projektdateien,
Makefiles,setup.py, Installationsskripte von Paketen und CI-Dateien können alle Befehle ausführen. Lesen Sie sie so sorgfältig wie den Quellcode. - Löschen Sie
.suo-Dateien und.vs-Ordner, die mit einem Repository mitkommen. Es sind benutzerbezogene Einstellungen, die ein Projekt zum Bauen nicht braucht. - Schalten Sie Zeilenumbruch oder sichtbare Leerzeichen ein, wenn Sie unbekannten Code in Ihrem Editor prüfen.
- Sehen Sie sich die Historie des Repositorys an. Ein neues Konto, ein einziger großer Commit, kaum echte Issues oder Mitwirkende und ein Werkzeug, das ein bekanntes Projekt dupliziert, sind Gründe für mehr Vorsicht. Sterne und Forks allein beweisen wenig, weil sie gefälscht werden können.
- Bauen Sie unbekannten Code in einer Wegwerfumgebung. Verwenden Sie eine Einweg-VM oder einen Container ohne gespeicherte Passwörter, ohne VPN-Profil und ohne SSH-Schlüssel, und löschen Sie die Umgebung danach.
Tipp: Halten Sie einen sauberen VM-Snapshot zum Ausprobieren von Werkzeugen bereit. Klonen, bauen und testen Sie dort und kehren Sie danach zum Snapshot zurück. Erweist sich ein Werkzeug als nützlich, prüfen Sie es gründlich, bevor es in die Nähe Ihrer täglichen Workstation kommt.
Wenn Sie bereits eines gebaut haben
Doctor Web hat Datei-Hashes, Domains, Adressen und Beispielnamen von Repositories in seiner Liste der Indicators of Compromise veröffentlicht. Zu den im Bericht beschriebenen Anzeichen gehören:
- ein Ordner
C:\ProgramData\Windows.Microsoft.Photosoder ein Programm namensMicrosoft.exe; t.ps1oderL.ps1inC:\Users\Public\Pictures;- Windows-Defender-Ausnahmen für
regasm.exeoderdwm.exe, die Sie nicht angelegt haben; - Domains von Antivirenherstellern in der
hosts-Datei oder abgeschaltete Systemwiederherstellung und Schattenkopien; - Sicherheitssoftware, die verschwunden ist oder sich nicht mehr aktualisiert.
Wenn Sie eines dieser Anzeichen finden oder wissen, dass Sie ein Projekt aus der Liste gebaut haben, gehen Sie davon aus, dass alles auf diesem Rechner gelesen wurde:
- Trennen Sie die Workstation vom Netzwerk und informieren Sie Ihr Sicherheitsteam.
- Ändern Sie von einem anderen, sauberen Gerät aus die im Browser gespeicherten Passwörter und melden Sie aktive Sitzungen ab, damit gestohlene Sitzungscookies nicht mehr funktionieren.
- Ersetzen Sie VPN-Profile sowie die in FTP- und Terminal-Clients gespeicherten Passwörter oder Schlüssel, und überprüfen Sie die Server, die damit erreichbar waren.
- Setzen Sie Sitzungen von Discord und anderen Messengern zurück und übertragen Sie Krypto-Assets in eine Wallet, die auf einem sauberen Gerät erstellt wurde.
- Installieren Sie das Betriebssystem neu, statt es zu bereinigen. Der Loader schaltet Sicherheits- und Wiederherstellungsfunktionen ab und installiert zwei Backdoors; einem bereinigten System kann man daher kaum vertrauen.
Tipp: Prüfen Sie Server- und VPN-Logs auf Anmeldungen des betroffenen Kontos nach dem Datum, an dem das Projekt gebaut wurde. Gestohlene Verbindungsdateien werden von den Systemen der Angreifer aus genutzt, nicht von der infizierten Workstation.
Wie LOGIQ helfen kann
LOGIQ hilft Organisationen, Open-Source-Software sicher zu betreiben, von Enterprise Linux und OpenJDK bis zu den Build- und Deployment-Pipelines rundherum. Wenn Sie einen zweiten Blick darauf wünschen, wie Ihre Teams externen Code in ihre Umgebung holen, oder Unterstützung brauchen, um Build-Systeme von wichtigen Zugangsdaten zu trennen, sprechen Sie uns an.
Global
Japan
Korea
China
Taiwan
Vietnam
Thailand
Indonesia
Portugal
Spain
France
Egypt
Russia