Gheist-Kampagne nutzt gestohlene GitHub-Tokens zum massenhaften Abgreifen von Repository-Geheimnissen

Das Cloud-Sicherheitsunternehmen Wiz verfolgt eine automatisierte Angriffskampagne namens Gheist, die gestohlene GitHub-Zugriffstoken nutzt, um systematisch Geheimnisse aus privaten Repositories und Unternehmens-GitHub-Umgebungen zu extrahieren. Wiz hat seit Beginn der Verfolgung der Kampagne am 15. September 2026 mehr als 13.500 bösartige Branches auf über 850 kompromittierten Konten wiedergefunden, und zum 24. Oktober war die Operation noch aktiv und entwickelte sich weiter.

Der Name stammt von der User-Agent-Zeichenfolge «gheist», die das automatisierte Tool der Angreifer mit jeder GitHub-API-Anfrage sendet, laut dem am 26. Oktober von The Hacker News veröffentlichten Bericht.

Wie der Angriff Geheimnisse ohne Kommandoserver extrahiert

Der Mechanismus von Gheist ist so aufgebaut, dass den Angreifern nichts zum Blockieren bleibt. Mit einem gestohlenen Token zählt das Tool jedes Repository auf, auf das dieses Token zugreifen kann. Für jedes erstellt es einen Branch mit einem Namen wie ci-sync-, gefolgt von sechs zufälligen Zeichen, und committet dann eine einzelne Datei — .github/workflows/sync-check.yml — mit der harmlosen Commit-Nachricht «ci: sync config». Der Commit bleibt unsigniert.

Das Pushen dieses Branches löst automatisch den Workflow aus, der einfach jede Umgebungsvariable und jedes Geheimnis ausgibt, das der Job lesen darf. Um die automatische Protokollmaskierung von GitHub für bekannte Geheimnismuster zu umgehen, kodiert das Tool die Ausgabe vor der Ausgabe in Base32. Der Angreifer lädt dann das resultierende Protokoll über die eigene API von GitHub herunter — was bedeutet, dass die gestohlenen Daten nie über einen externen Server austreten müssen, den ein Verteidiger erkennen oder blockieren könnte — und löscht den Workflow-Lauf innerhalb von Sekunden nach dem Abruf.

Ausmaß und reale Folgen

Wiz hat nicht offengelegt, wie viele Organisationen tatsächlich Geheimnisse offengelegt hatten, bestätigt aber, dass die Kampagne sowohl gegen private Repositories als auch gegen vollständige GitHub-Enterprise-Server-Bereitstellungen erfolgreich war — nicht nur gegen öffentliche, persönliche Projekte.

Der bestehende Schutz von GitHub deckt nur die Hälfte des Problems ab

Seit dem 28. Juli erfordert GitHub, dass ein Mitarbeiter mit Schreibzugriff als verdächtig markierte Workflow-Läufe manuell genehmigt — eine Änderung, die laut Wiz jeden gegen öffentliche Repositories getesteten Gheist-Versuch stoppte. Diese Genehmigungspflicht erstreckt sich jedoch nicht auf private Repositories oder GitHub Enterprise Server, genau dort, wo Gheist seine dokumentierten Erfolge hatte.

Empfohlene Reaktion

Wiz empfiehlt Organisationen, ihre Audit-Protokolle nach Branches zu durchsuchen, die dem Namensmuster ci-sync- entsprechen, und alle damit verbundenen OIDC-Rollenübernahmen zu überprüfen. Jedes Geheimnis, auf das ein betroffenes Repository zugreifen kann, sollte als kompromittiert behandelt und sofort rotiert werden.