Nach Angaben der Threat-Intelligence-Plattform registrierte der Akteur die Domain „my-github[.]com" und richtete sie auf die IP-Adresse 193.32.204[.]199 — dieselbe Adresse, die als Exfiltrationsendpunkt für die über den bösartigen Workflow abgegriffenen Daten dient. Die Registrierung erfolgte am 9. Oktober 2026, 17 Tage nach der Registrierung von „my-gitlab[.]com". Ob die zweite, ebenfalls an einen Code-Hoster angelehnte Domain vom selben Akteur betrieben wird, ist offen.
„Sie folgt demselben Namensmuster my-
Noch am Tag ihrer Registrierung wurde die Domain „my-github[.]com" für eine Phishing-Mail genutzt, die sich als GitHub-Sicherheitswarnung ausgab und gegen einen Open-Source-Maintainer gerichtet war. Die Nachricht stammte vermeintlich von „noreply@my-github[.]com" und warnte vor einer neuen Anmeldung am GitHub-Konto aus Moskau, Russland; der Empfänger sollte einem Link folgen, um sein Konto abzusichern.
Die gefälschte Seite arbeitete laut OpenSourceMalware als Reverse Proxy, griff Passwort und Zwei-Faktor-Code des Opfers ab und schleuste JavaScript ein, das eine OAuth-App mit der Berechtigung zum Ändern von Workflows autorisierte — die Grundlage für einen Angriff nach GhostAction-Muster. Das JavaScript autorisiert dabei still einen GitHub-OAuth-Device-Flow mit den Scopes repo, workflow und read:org. Damit erhält der Angreifer Lese- und Schreibzugriff auf Repositories, kann Actions-Workflow-Dateien verändern und erhält Einblick in Organisationsmitgliedschaften und zugehörige Organisationsdaten.
Das Prinzip entspricht dem Device-Code-Phishing: Ziel ist ein Zugriffstoken von GitHub, das anschließend über TCP/8443 an „my-github[.]com" exfiltriert wird. „Das Skript empfängt einen Device-Code und einen User-Code, lädt /login/device, extrahiert die GitHub-Formulare aus dem zurückgelieferten HTML und schickt sie automatisch ab", erläuterte McCarty. „Es fügt den User-Code ein, sucht das Autorisierungsformular, ergänzt authorize=1 und sendet die Bestätigung über die authentifizierte, proxyierte Sitzung des Opfers." Das Opfer müsse den Device-Code weder eintippen noch die OAuth-Anwendung bewusst bestätigen; das Kit automatisiere User-Code- und Autorisierungsschritt über die Reverse-Proxy-Sitzung.
Das erbeutete, auf Repositories ausgelegte OAuth-Token ist ein wiederverwendbarer API-Zugang. Die so erteilten Berechtigungen decken sich genau mit dem, was GhostAction braucht: Repositories aufzählen und bösartige Workflow-Dateien unter „.github/workflows/" einschleusen. „Der Akteur kann nun Automatisierung im Repository-Maßstab mit individuellem Social Engineering gegen Personen kombinieren, deren Konten Zugang zu Projekten, Organisationen, Registries und nachgelagerten Nutzern verschaffen", so OpenSourceMalware.
Hinzu kommt eine zweite Stufe, die auf Entwicklerrechnern auch dann bestehen bleibt, wenn der bösartige Workflow entfernt wurde. Dabei greift die Kampagne auf ein Vorgehen zurück, das aus nordkoreanischen Operationen bekannt ist, und committet drei Dateien:
- eine tasks.json für Visual Studio Code mit dem Auslöser „runOn: folderOpen", die beim Öffnen des Ordners automatisch ausgeführt wird;
- die Datei „public/fonts/fa-solid-400.woff2", die einen Stealer enthält — der Dateiname entspricht dem aus Nordkoreas PolinRider-Kampagne vom Januar 2026;
- einen zweiten GitHub-Actions-Workflow, der aktiv wird, falls der Infostealer nie läuft.
Der so automatisch gestartete Stealer sammelt AWS-Schlüssel, PyPI- und npm-Tokens, Git-Logins, Zugangsdaten für Kubernetes-Cluster, private SSH-Schlüssel sowie Zugangsdaten für die KI-Anbieter Anthropic Claude und Google Gemini. Zusätzlich richtet er einen Cronjob ein, der alle fünf Minuten vom Angreifer bereitgestellten Code ausführt. Die gesammelten Daten gehen unverschlüsselt per HTTP über Port 8080 an denselben Server. Insgesamt wurden 94 kompromittierte Repositories mit dieser zweiten Stufe identifiziert.
Der zweite CI-Workflow entspricht dem ursprünglichen bösartigen Workflow, sucht aber nach weiteren Zugangsdaten-Formaten und lädt die Funde ersatzweise in ein geheimes GitHub-Gist hoch, falls der POST fehlschlägt. Er tritt unter folgenden Dateinamen auf:
- lint.yml
- ci-check.yml
- build-check.yml
- repo-health.yml
- audit.yml
- code-review.yml
- test-suite.yml
- cache-cleanup.yml
Die 94 Repositories gehören laut OpenSourceMalware zu 66 Eigentümern; 15 davon wurden inzwischen gelöscht, umbenannt oder auf privat gestellt. Die weiterhin erreichbaren Projekte wirken überwiegend verwaist — eines blieb über neun Jahre unangetastet, 65 der 79 erhielten länger als ein Jahr keinen Commit.
„Stufe 1 braucht GitHub, um den Workflow auszuführen", erklärte OpenSourceMalware. „Am 9. Oktober begann GitHub, die Ausführung des bösartigen Workflows zu verhindern, und die Wellen am 10. und 12. Oktober förderten keine Secrets zutage. Stufe 2 bringt einen Starter mit, der überhaupt keinen Runner benötigt, und sie kam sechs Tage nach der Blockade. Wir können nicht sagen, dass die Blockade die Ursache war. Wir können sagen, dass der Betreiber an einen Ort ausgewichen ist, den GitHubs Kontrollen nicht erreichen."
Zur Eindämmung sollten Entwickler GitHub-Zugriffe und Tokens von einem sauberen Gerät aus widerrufen, Passwörter ändern, ihre Repositories prüfen, sämtliche durch die Workflows erreichbaren Zugangsdaten rotieren und Nutzer informieren, die die Repositories geklont haben.
„Wir wissen nicht, wer der Betreiber ist, aber seine Arbeit deutet auf begrenzte Erfahrung hin", sagte Jenn Gile, Mitgründerin von OpenSourceMalware. „Der Umgebungsvariablen-Filter des Stealers übersieht die meisten API-Schlüssel, seine Suche im Home-Verzeichnis kann in ein Timeout laufen und die eigenen Ergebnisse verwerfen, und eine einzige IP erledigt Exfiltration, Phishing und lautes Internet-Scanning. Genau dieser letzte Fehler ist der Grund, warum die Suche nach der IP noch immer Infektionen findet."