LONDON (IT BOLTWISE) – Der aktuelle Gheist-Angriff missbraucht kompromittierte GitHub-Token, um eine manipulierte Workflow-Datei in fremde Repositories zu pushen. Anschließend werden die Secrets aus dem Actions-Log ausgelesen, bevor der Run kurz nach dem Abschluss wieder gelöscht ist. Laut Wiz Research wurden dabei über 13.500 präparierte Branches aus mehr als 850 kompromittierten Konten sichtbar. Besonders kritisch: In privaten Repositories und GitHub Enterprise laufen die Payloads offenbar ohne das übliche öffentliche Freigabe-Stoppsignal.
Mit Gheist steht derzeit ein Angriffsmuster im Fokus, das weniger auf klassische Malware-Downloads setzt, sondern auf eine präzise Ausnutzung der GitHub-Actions-Mechanik. Die Kampagne startet am 15. September 2026 nach den vorliegenden Beobachtungen mit dem systematischen Missbrauch von kompromittierten GitHub-Tokens: Der Angreifer legt für jedes betroffene Repository einen Branch an und fügt eine neue Workflow-Datei unter.github/workflows/sync-check.yml hinzu. Der Workflow trägt laut Bericht den Commit-Message-Stil „ci: sync config“, wird über einen Push ausgelöst und zielt darauf, Secrets in das eigene Workflow-Log zu schreiben. Danach wird der Run über die GitHub API ausgelesen und sehr schnell wieder gelöscht – wodurch der Angriff in vielen Fällen weniger wie ein „Docking einer Payload“ wirkt, sondern wie eine kurze, schwer nachverfolgbare Datenabzugsroutine.
Technisch wichtig ist dabei, wie die Exfiltration technisch überhaupt funktioniert. In den Logs werden Secret-Werte nur dann maskiert, wenn sie exakt im Klartext vorkommen. Gheist umgeht diese Regel offenbar, indem es die Geheimnisse in eine Form bringt, die nicht 1:1 als „bekannter“ Secretstring erkannt wird – im Bericht wird explizit beschrieben, dass base32-kodierte Werte nicht maskiert werden und daher vollständig ausgegeben werden. Parallel dazu wird eine weitere Komponente genutzt: Selbst wenn Job-Constraints wie permissions: {} eingesetzt sind, die den GITHUB_TOKEN im Hinblick auf API-Rechte einschränken, bleibt der Zugriff auf den secrets-Kontext im Workflow erhalten. Ergebnis: Der Angreifer muss nicht zwingend die API-Rechte des GITHUB_TOKEN erweitern, solange der Workflow selbst die Secrets in ein Log schreibt und der Angreifer anschließend diese Logs über die GitHub API abzieht.
Der Angriff wird zudem durch eine zweite Logik verstärkt, die vor allem für Organisationen mit gestaffelten Freigaben und produktionsnahen Konfigurationen relevant ist: Wenn ein Repository Deployment Environments besitzt, arbeitet Gheist mit einem Job-Matrix-Ansatz. Das Workflow-Template setzt environment: ${{ matrix.environment }} und zwingt damit die Ausführung so, dass environment-spezifische Secrets mit an Bord kommen. Damit kann die Aktion nicht nur allgemeine Token oder.env-Werte exportieren, sondern auch production-scoped Credentials, die in solchen Umgebungen typischerweise strenger gepflegt werden. Dazu kommt im Bericht die Beobachtung, dass durch den Exfiltrationsweg über GitHub selbst kein klassischer „Outbound“-Block gegen fremde Domains greift: Da der Datenabzug über die Plattform-APIs läuft, fehlt oft ein klarer Netzwerk-Indikator außerhalb von GitHub.
Wiz beschreibt, dass die Kampagne nicht nur eine statische Variante fährt. Vielmehr existieren zwei beobachtete Tool-Varianten, unterscheidbar über die Branch-Namenssuffixe: Tool A nutzt einen hexadezimalen Suffix, Tool B einen base36-Suffix. Auffällig ist außerdem, dass Tool B in zeitlichem Abstand zunächst zusätzliche Parameter in das Payload-Verhalten einbaut (im Bericht etwa timeout-minutes: 6) und später den eigentlichen Dump-Prozess verändert: Am 19. Oktober wurde zwischen den Ausgaben ein base32-Transformationselement ergänzt, das als LAFA-Separator für eine Operator-spezifische Logauswertung dienen soll. Stunden später soll Tool B dann sogar einen zusätzlichen Job (sync-host) mit runs-on: self-hosted angestoßen haben, allerdings scheinbar nur für Repositories mit registrierten Self-Hosted Runners. Dieser Self-Hosted-Teil schreibt im Bericht drei Hilfsdateien (.gdmp_pat, .gdmp_patg, .gdmp_sweep) und versucht danach eine breite lokale Suche nach 31 Token-Formaten, darunter auch Schlüssel für KI-Anbieter wie Anthropic, Hugging Face, Groq und NVIDIA, außerdem private Keys, .env-Dateien, Terraform State und Shell-Historie.
Gerade die Self-Hosted-Komponente macht aber auch deutlich, warum Gheist nicht als „einfacher“ Workflow-Diebstahl abgetan werden sollte: Der Bericht nennt eine Buggy-Implementierung. So sucht der Self-hosted Job nach dem falschen Runner-Key-Dateinamen, eine URL-Credential-Regex sei fehlerhaft und es würden offenbar keine GCP- oder Azure-Tokens gesammelt. Trotzdem bleibt die Gesamtwirkung relevant, weil ein erfolgreicher Zugriff auf Tokens auf dem Runner die Daten- und Credential-Landschaft stark erweitern kann. Dazu passt eine weitere Beobachtung: In Self-hosted Umgebungen beschreibt der Bericht das Erkennen über spezifische Job-Artefakte wie gdmp-pivot in Logs sowie das Vorhandensein der genannten Datei-Namen. Für Sicherheitsteams heißt das: Neben GitHub-spezifischen Spuren muss auch der Host-Betrieb genauer überwacht werden, insbesondere dort, wo Docker-Socket-Zugriff oder tiefergehende Dateisystemrechte üblich sind.
Ein Kernpunkt in der Verteidigungsplanung liegt in der unterschiedlichen Behandlung öffentlicher und nicht-öffentlicher Ausführungen. Für öffentliche Repositories soll GitHub seit dem 28. Juli 2026 potenziell bösartige Workflow-Runs bis zur Freigabe durch einen Collaborator zurückhalten. Laut Bericht zeigen die geprüften öffentlichen Gheist-Runs aber stets action_required; das Control habe damit gewirkt, sodass die Payloads dort nicht „durchliefen“. Gleichzeitig greift dieses Stoppsignal in privaten Repositories und in GitHub Enterprise Server offenbar nicht. In diesen Umgebungen dokumentieren Audit-Logs abgeschlossene Runs auf ci-sync-* Branches, die anschließend vom User-Agent gheist wieder gelöscht werden. Für Defender bedeutet das: Das „Fehlen“ im normalen GitHub-Event-Feed kann trügerisch sein, weil die Plattformspuren zwar existieren, aber durch schnelle Löschung weniger sichtbar werden.
Die Kampagne ordnet Wiz zudem in ein breiteres Muster kompromittierter GitHub-Zugriffe ein. Gleiche Konten werden demnach auch von anderen Akteuren und Kampagnen genutzt, was die typische Credential-Mobilität im Threat-Ökosystem unterstreicht. Der Bericht nennt Überschneidungen etwa mit Lure-Repositories, in denen zahlreiche Dateien und Branches umbenannt werden, sowie mit Aktivitäten, die auf „Free Compute“ für Mining-Fähigkeiten zielen. Daneben wird PolinRider als ein Fall erwähnt, bei dem Opfer offenbar zusätzlich mit einem Malware-Mechanismus konfrontiert werden, der JavaScript in Build-Konfigurationen versteckt und Commits mit Backdating-Charakter zurückschiebt. Wichtig ist hier weniger der genaue Malware-Name als die Aussage: Wenn ein GitHub-Zugang kompromittiert ist, kippt die Rolle von „GitHub Actions“ schnell von einem Build-System zu einem operativen Hebel.
Für Security-Teams leiten sich daraus sehr konkrete Vorgehensweisen ab. Beim Threat-Hunting sollen Branches mit dem Muster ci-sync- plus sechs zufälligen Zeichen gefunden werden, wobei eine Änderung ausschließlich das Hinzufügen der sync-check.yml unter.github/workflows betrifft und der Commit-Message-Stil „ci: sync config“ nahezu alleiniger Indikator bleibt. In Audit-Logs gilt es nach Workflow-Runs auf ci-sync-* Branches zu suchen, die innerhalb kurzer Zeitspanne nach Abschluss wieder gelöscht wurden, plus nach Aktivität mit dem User-Agent gheist. Wenn Workflows Cloud-Zugänge per OIDC absichern, empfiehlt der Bericht zusätzlich die Prüfung von Cloud-Audit-Logs auf Role-Assumptions oder Token-Exchange-Ereignisse, deren Subject auf einen ci-sync- Branch verweist – besonders relevant, wenn GitHub-seitige Logs durch Löschung schwerer auffindbar sind. Auf Self-Hosted Runnern sollten Verteidiger nach den genannten Dateien und nach dem gdmp-pivot-Marker suchen und Hosts im Zweifel als kompromittiert behandeln. Gleichzeitig fordert der Bericht harte Maßnahmen zur Geheimnisrotation: Repo-, Orga- und Environment-Secrets, die in betroffenen Repositories verfügbar waren, müssen rotiert werden, weil ein „Run löschen“ die bereits ausgelesenen Werte nicht rückgängig macht.
🔥 Heutige Hot Deals bei Amazon: Bis zu 80% Rabatte!
🎉 Amazon Haul-Store für absolute Schnäppchenjäger!
- ★ 23-stufiges KI-Go-Training – Für Spieler mit Grundkenntnissen der Regeln – Entwickelt als intelligenter Trainingspartner passt sich die KI Spielern von 18K bis 9D an. Ideal für alle, die die Grundregeln bereits beherrschen und ihr Spiel verbessern möchten.
- IHR EMOTIONALER AI-BEGLEITER: Eiliko ist mehr als nur ein Anhänger, es ist ein charismatischer KI-Freund. Mit einem dynamischen LED-Bildschirm, der eine Vielzahl von animierten Gesichtern und Ausdrucksformen anzeigt, reagiert er auf Ihre Interaktionen mit einzigartiger Persönlichkeit und Charme.
- 【MEHR LEBEN FÜR DEINEN SCHREIBTISCH】 Lerne Eilik kennen – deinen kleinen Roboter-Freund mit Persönlichkeit. Mit liebevollen Animationen, ausdrucksstarken Reaktionen und spielerischen Interaktionen bringt Eilik mehr Freude in deinen Alltag. Ob auf dem Schreibtisch, im Büro oder am Nachttisch – Eilik wird schnell zu einem vertrauten Begleiter für besondere Momente.
- 【XL-Größe für gedeihende Pflanzen】Geben Sie Ihren Pflanzen den Raum, den sie verdienen! Unser verbessertes, großes 13,7 cm großes Design bietet Platz für Pflanzen mit einem Durchmesser von bis zu 8,9 cm und damit deutlich mehr Platz für Wurzelwachstum und Pflanzengesundheit im Vergleich zu kleineren, veralteten Modellen. Die Produktabmessungen betragen 13,6 x 13,6 x 13,2 cm und das Gerät wiegt nur 355 g.
- V28 Update - JETZT MIT NEUEN FUNKTIONEN! Als Reaktion auf das Ladeproblem von Loona haben wir das automatische Aufladen 2.0 verbessert. Diese Optimierung hilft Loona, die Ladewege in verschiedenen Szenarien zu erkennen und anzupassen, um die Erfolgsquote beim automatischen Aufladen zu erhöhen. Mobile Hotspots können sich mit Loona verbinden und überwinden WLAN-Einschränkungen, sodass Sie jederzeit und überall mit Loona interagieren können.
- Die besten Bücher rund um KI & Robotik!
- Die besten KI-News kostenlos per eMail erhalten!
- Zur Startseite von IT BOLTWISE® für aktuelle KI-News!
- IT BOLTWISE® kostenlos auf Patreon unterstützen!
- Aktuelle KI-Jobs auf StepStone finden und bewerben!
- Künstliche Intelligenz: Dem Menschen überlegen – wie KI uns rettet und bedroht | Der Neurowissenschaftler, Psychiater und SPIEGEL-Bestsellerautor von »Digitale Demenz«
Du hast einen wertvollen Beitrag oder Kommentar zum Artikel "Gheist-Angriff missbraucht GitHub-Token und exfiltriert Secrets via Actions" für unsere Leser?
#Sophos
#AmazonPrime
#Bestseller
Es werden alle Kommentare moderiert!
Für eine offene Diskussion behalten wir uns vor, jeden Kommentar zu löschen, der nicht direkt auf das Thema abzielt oder nur den Zweck hat, Leser oder Autoren herabzuwürdigen.
Wir möchten, dass respektvoll miteinander kommuniziert wird, so als ob die Diskussion mit real anwesenden Personen geführt wird. Dies machen wir für den Großteil unserer Leser, der sachlich und konstruktiv über ein Thema sprechen möchte.
Du willst nichts verpassen?
Du möchtest über ähnliche News und Beiträge wie "Gheist-Angriff missbraucht GitHub-Token und exfiltriert Secrets via Actions" informiert werden? Neben der E-Mail-Benachrichtigung habt ihr auch die Möglichkeit, den Feed dieses Beitrags zu abonnieren. Wer natürlich alles lesen möchte, der sollte den RSS-Hauptfeed oder IT BOLTWISE® bei Google News wie auch bei Bing News abonnieren.
Nutze die Google-Suchmaschine für eine weitere Themenrecherche: »Gheist-Angriff missbraucht GitHub-Token und exfiltriert Secrets via Actions« bei Google Deutschland suchen, bei Bing oder Google News!