GhostAction-Angreifer verstecken Credential-Stealer in gefälschten Schriftarten auf GitHub
Die GhostAction-Gruppe nutzt jetzt Phishing und getarnte Schriftartdateien, um Zugangsdaten aus 94 GitHub-Repositories zu stehlen und dabei die Sicherheitskontrollen der Plattform zu umgehen.
Automatisch aus dem englischen Original übersetzt.
Der Akteur hinter dem GhostAction-Angriff auf die Lieferkette hat seine Taktik geändert. Statt bösartige Workflows in GitHub-Projekte einzuschleusen, greifen sie Entwickler nun direkt mit Phishing an. In einer Kampagne, die OpenSourceMalware am 19. Oktober 2026 detailliert beschrieb, setzte die Gruppe einen als Schriftartdatei getarnten Credential-Stealer in 94 kompromittierten Repositories ein. Diese Weiterentwicklung ermöglicht es den Angreifern, sensible Daten auch dann zu ernten, wenn GitHub ihre automatisierten Workflows blockiert.
Was geschah
Die Angreifer registrierten am 9. Oktober 2026 die Domain "my-github[.]com" und leiteten sie auf die IP-Adresse 193.32.204[.]199 weiter. Diese IP dient auch als Exfiltrations-Endpunkt für Daten, die über bösartige GitHub Actions gestohlen werden. Am Tag der Registrierung versandte die Gruppe Phishing-E-Mails, die sich als GitHub-Sicherheitswarnungen ausgaben, an Maintainer von Open-Source-Projekten. Diese Nachrichten warnten vor verdächtigen Logins aus Moskau und leiteten die Opfer auf eine gefälschte Login-Seite. Diese Seite fungierte als Reverse Proxy, der Passwörter und Zwei-Faktor-Authentifizierungscodes abfing, während im Hintergrund stillschweigend eine OAuth-Anwendung mit weitreichenden Berechtigungen zur Änderung von Workflows und zum Lesen von Organisationsdaten autorisiert wurde.
Nachdem der Zugriff gesichert war, schlichen die Angreifer bösartige Dateien in die Repositories ein. Die Kampagne umfasst eine Komponente der zweiten Stufe, die darauf ausgelegt ist, sich auf den Rechnern der Entwickler dauerhaft festzusetzen. Dies beinhaltet das Einchecken einer Visual Studio Code Tasks-Konfiguration, die automatisch ausgelöst wird, wenn ein Ordner geöffnet wird, eine gefälschte Schriftartdatei mit einem Stealer-Payload sowie ein Backup-GitHub-Actions-Workflow. Die Schriftartdatei mit dem Namen "fa-solid-400.woff2" imitiert ein legitimes Asset, sammelt aber tatsächlich AWS-Schlüssel, PyPI-Tokens, npm-Tokens, Git-Logins, Kubernetes-Zugangsdaten, SSH-Schlüssel sowie KI-Anbieter-Credentials für Anthropic Claude und Google Gemini.
Diese zweite Stufe installiert einen Cron-Job, der alle fünf Minuten vom Angreifer bereitgestellten Code ausführt, falls der ursprüngliche Stealer nicht läuft. Die gesammelten Daten werden über unverschlüsseltes HTTP auf Port 8080 übertragen. OpenSourceMalware identifizierte 94 Repositories, die 66 Besitzern gehören und diese Komponente der zweiten Stufe enthalten. Fünfzehn dieser Repositories wurden seitdem gelöscht, umbenannt oder privat gestellt. Die meisten betroffenen Projekte wirken verlassen; bei 65 der 79 zugänglichen Repositories gab es seit über einem Jahr keine Commits mehr.
Wichtige Details
- Die Angreifer registrierten "my-github[.]com" am 9. Oktober 2026 und nutzten dieselbe IP-Adresse wie ihre frühere Exfiltrations-Infrastruktur.
- Phishing-E-Mails gaben sich als GitHub-Sicherheitswarnungen aus und nutzten einen Reverse Proxy, um Zugangsdaten zu stehlen und OAuth-Apps ohne Nutzerzustimmung zu autorisieren.
- Eine gefälschte Schriftartdatei namens "fa-solid-400.woff2" enthält einen Stealer, der Cloud-Schlüssel, Tokens und Credentials für KI-Anbieter ins Visier nimmt.
- Die Malware installiert einen Cron-Job, der alle fünf Minuten ausgeführt wird, um Persistenz und kontinuierliche Datenexfiltration sicherzustellen.
- 94 Repositories im Besitz von 66 Eigentümern wurden kompromittiert, wobei viele Projekte verlassen oder seit über einem Jahr inaktiv erscheinen.
- GitHub begann am 9. Oktober, die ursprünglichen bösartigen Workflows zu blockieren, was den Wechsel zu clientseitigen Persistenzmethoden auslöste.
Hintergrund
Angriffe auf die Lieferkette zielen auf den Softwareentwicklungslebenszyklus ab, indem vertrauenswürdige Komponenten oder Tools kompromittiert werden. In diesem Fall nutzten die Angreifer das Vertrauen aus, das Entwickler in Open-Source-Repositories und integrierte Entwicklungsumgebungen wie Visual Studio Code setzen. Durch die Tarnung der Malware als gängige Schriftartdatei umgingen sie oberflächliche Inspektionen. Der Einsatz von Phishing über den OAuth-Gerätefluss ist besonders gefährlich, da er den Autorisierungsprozess automatisiert und den Angreifern API-Tokens gewährt, die Repository-Einstellungen ändern und weiteren bösartigen Code einschleusen können.
Cron-Jobs sind geplante Aufgaben, die auf Unix-ähnlichen Systemen in festen Intervallen laufen. Obwohl sie für die Automatisierung unerlässlich sind, können Angreifer sie missbrauchen, um einen dauerhaften Zugang zu einem System aufrechtzuerhalten. Wenn ein bösartiges Skript in die Crontab eines Benutzers aufgenommen wird, kann es wiederholt ohne weitere Interaktion ausgeführt werden, sodass gestohlene Daten weiterhin an den Server des Angreifers gesendet werden, selbst wenn der ursprüngliche Infektionsvektor entfernt wird.
Warum das wichtig ist
Für Teams, die eigene Software betreiben, unterstreicht dieser Vorfall das Risiko, sich ausschließlich auf plattformseitige Sicherheitskontrollen zu verlassen. Die Fähigkeit von GitHub, bösartige Workflows zu blockieren, stoppte die Angreifer nicht; sie wechselten einfach zu einer Methode, die auf dem lokalen Rechner des Entwicklers operiert. Das bedeutet, dass selbst wenn Ihre CI/CD-Pipeline sicher ist, kompromittierte Abhängigkeiten oder geklonte Repositories Malware einführen können, die Zugangsdaten aus Ihrer lokalen Umgebung stiehlt. Diese Zugangsdaten umfassen oft den Zugriff auf Produktionsinfrastrukturen, weshalb lokale Hygiene für die Gesamtsicherheit entscheidend ist.
Das Ziel verlassener oder inaktiver Repositories ist eine erhebliche Sorge für Organisationen, die ältere Open-Source-Projekte forken oder davon abhängen. Diese Projekte haben möglicherweise keine aktiven Maintainer, die bösartige Commits schnell identifizieren und entfernen können. Wenn Ihr Team solche Bibliotheken nutzt, könnten Sie unwissentlich stealthige Hintertüren in Ihren Entwicklungsworkflow einschleusen. Die Nutzung von unverschlüsseltem HTTP für die Exfiltration deutet zudem darauf hin, dass Netzwerküberwachung diese Angriffe erkennen könnte, allerdings nur, wenn der Traffic zu verdächtigen IPs genau beobachtet wird.
Was Sie tun können
- Widerrufen Sie sofort alle GitHub-Zugangstokens und ändern Sie Passwörter von einem bekannten sauberen Gerät aus, wenn Sie eine Kompromittierung vermuten.
- Überprüfen Sie Ihre Repositories auf ungewöhnliche Dateien, insbesondere in öffentlichen Asset-Ordnern wie Fonts, und suchen Sie nach unerwarteten VS Code Task-Konfigurationen.
- Rotieren Sie alle potenziell exponierten Zugangsdaten, einschließlich AWS-Schlüsseln, npm-Tokens und SSH-Schlüsseln, besonders jene, die in Umgebungsvariablen gespeichert sind.
- Überwachen Sie Ihre lokalen Cron-Jobs und geplanten Aufgaben auf unbekannte Einträge, die häufig ausgeführt werden oder Verbindungen zu externen Servern herstellen.
- Warnen Sie alle Benutzer, die die betroffenen Repositories geklont oder geforkt haben, damit sie den bösartigen Code nicht weiterverbreiten.
- Implementieren Sie Netzwerküberwachung, um ausgehenden HTTP-Traffic zu unbekannten IPs oder Ports (wie Port 8080, der in dieser Kampagne verwendet wurde) zu kennzeichnen.



