GhostAction ist eine laufende Kampagne, bei der Angreifer Entwicklerkonten übernehmen und anschließend Workflow-Dateien für GitHub Actions in Repositories einschleusen. Workflows legen fest, welcher Code bei bestimmten Ereignissen ausgeführt wird — etwa beim Push eines Commits oder beim Öffnen eines Pull Requests. Die manipulierten Dateien nutzen das hohe, konstruktionsbedingte Vertrauen von GitHub in solche Workflows aus und greifen Repository-Secrets, Tokens zum Veröffentlichen von Paketen, persönliche GitHub-Zugriffstokens sowie im Quellcode hinterlegte Zugangsdaten ab. Die Logik dahinter: Aus einer ersten Kompromittierung sollen weitere Zugriffspunkte über Repositories, CI/CD-Systeme und Cloud-Umgebungen hinweg entstehen — ähnlich dem Prinzip der zuletzt beobachteten Lieferketten-Würmer, wenn auch technisch anders umgesetzt.
Die Kampagne wurde erstmals im vergangenen Jahr dokumentiert und wird seither fortgesetzt. Neu ist die Eskalation in diesem Monat: In einer früheren Welle vom 8. bis 12. Oktober schoben die Angreifer die Datei security-audit.yml in rund 30.000 Repositories und verteilten über gekaperte Konten im großen Stil Code zum Abgreifen von Zugangsdaten.
In der jüngsten Welle beobachtete GitGuardian, dass der Betreiber nach der Übernahme eines Entwicklerkontos je nach eingesetztem Runner unterschiedliche Schadroutinen ausspielte. Runner sind die Systeme, die GitHub-Actions-Workflows ausführen; viele Organisationen nutzen von GitHub gehostete Runner, andere betreiben eigene Runner in ihrer Umgebung. Zum Einsatz kamen fünf Varianten:
- „seven workflows" — durchsucht Repositories und Wikis von GitHub-Runnern nach Zugangsdaten, darunter API-Schlüssel von KI-Anbietern
- „Security-audit.yml" — die aus früheren GhostAction-Angriffen bekannte Datei, die auf GitHub gehosteten Quellcode und die Git-Historie nach Zugangsdaten durchsucht
- eine Variante gegen selbst gehostete CI-Runner
- eine Variante gegen GitHub-Runner und AWS, die GitHub-OIDC-Tokens anfordert, um AWS-Rollen zu übernehmen und Zugang zu Cloud-Konten zu erlangen
- der „font stealer"
Die Font-Stealer-Familie ist die bemerkenswerteste Variante — wegen ihrer Herkunft. Sie installiert auf lokalen Entwicklerrechnern einen in Node.js geschriebenen Credential-Stealer, getarnt als VS-Code-Task. Die Technik scheint von PolinRider kopiert zu sein, einer Kampagne, die verschleierte Loader in Entwickler-Repositories versteckt, um Zugangsdaten zu stehlen, und die mit Nordkorea in Verbindung gebracht wird. Zwischen dem 22. und 26. Oktober fügte der Angreifer zusätzlich PolinRider-Loader in bereits von GhostAction betroffene Repositories ein.
Gaetan Ferry von GitGuardian zufolge hatte von den fünf Varianten allein der an PolinRider angelehnte lokale Stealer überhaupt eine Chance, erfolgreich zu laufen; Belege für eine tatsächliche Ausführung hat GitGuardian jedoch nicht. Ob es Überschneidungen zwischen GhostAction und PolinRider gibt, konnte das Unternehmen nicht beurteilen. Als Hypothese nennt GitGuardian, dass der GhostAction-Betreiber einen öffentlich verfügbaren PolinRider-Launcher kopiert haben könnte, um eine sich überschneidende Opfergruppe anzugreifen.
Jenn Gile, Mitgründerin von OpenSourceMalware, sieht in dem Nachbau Hinweise auf die Arbeitsweise der Gruppe. Ihre Organisation hatte die GhostAction-Angriffe in diesem Monat bereits beschrieben und vor einigen Wochen Anzeichen für den PolinRider-Nachahmer entdeckt. „Was wir sehen, sieht nach Nachahmung aus, nicht nach Weiterentwicklung. Die Fake-Font-Technik bei GhostAction ist eine Kopie dessen, was die PolinRider-Kampagne aus Nordkorea fast das gesamte Jahr 2026 über eingesetzt hat", schrieb sie per E-Mail. „Die mehreren Payloads sind real, aber es sind Variationen eines Themas — fünf Workflow-Versionen in etwa zehn Tagen in einem Repository, das wir untersucht haben —, keine neue Fähigkeit. Früher hätten wir das vielleicht Weiterentwicklung genannt, weil echtes Können nötig war, um darauf zu kommen. Das hier sieht aber stark danach aus, als helfe ein LLM dem Angreifer dabei, verschiedene Varianten durchzuprobieren."
Entscheidend für die Betroffenen ist die anhaltende Persistenz: Laut Ferry waren „1.382 der 1.792 kompromittierten Konten bereits am 8. Oktober im Einsatz, dieselben gestohlenen Tokens funktionieren also weiterhin". Die Welle selbst bezeichnet er als „auf Seiten der bösartigen Workflows hochgradig wirkungslos". Zugleich zeige die Ausrichtung einzelner Varianten — etwa jener auf Cloud-Zugang —, wohin die Angreifer als Nächstes ausweichen könnten: in interne Netze, in denen weniger Schutzmechanismen auf Plattformebene greifen. „Wir erwarten in naher Zukunft neue Wellen mit überarbeiteten Payloads", so Ferry. „Diese Strategie des frühen Scheiterns und schnellen Anpassens wurde bei diesem Akteur bereits beobachtet."
Da angegriffene Konten und Repositories weiterhin kompromittiert sind, sollten Repository-Betreiber die von GitGuardian im IoC-Abschnitt ihrer Veröffentlichung aufgeführten Dateien in jedem Branch suchen und löschen. Bei Anzeichen einer Kompromittierung sind sämtliche Tokens des Kontos zu widerrufen und alle im betroffenen Repository oder dessen Historie eingecheckten Zugangsdaten zu rotieren — ebenso jedes Actions-Secret und jede im Wiki hinterlegte Zugangsinformation.