GhostAction-Kampagne kapert GitHub-Konten, um CI/CD- und KI-Secrets zu stehlen

Eine koordinierte Cyberkampagne namens GhostAction hat im Oktober 2026 etwa 1.900 GitHub-Konten kompromittiert. Die Angreifer nutzten diese Zugänge, um bösartige GitHub Actions Workflows in mehr als 30.000 Repositories einzuschleusen, um sensible Credentials wie Cloud-Zugriffsschlüssel und API-Tokens von KI-Anbietern zu exfiltrieren.

Was passiert ist

Die Attacke intensivierte sich am 8. und 9. Oktober 2026, als die Bedrohungsakteure Repositories anvisierten, die zu etwa 3.000 Benutzern und Organisationen gehörten. Während dieser Spitzenphase versuchten die bösartigen Workflows, 3.174 verschiedene Secrets zu extrahieren. GitGuardian, das die Kampagne verfolgte, stellte fest, dass die Angreifer die Payload in mehreren Phasen deployten. Ein initialer Push zielte auf etwa 160 bereits zuvor betroffene Konten ab, gefolgt zwanzig Minuten später von einer viel größeren Bereitstellung, die 28.000 neue Repositories betraf.

Im Gegensatz zu früheren Supply-Chain-Angriffen, die Schwachstellen in geteilten Actions ausnutzten, wie beim tj-actions/changed-files Vorfall, verließ sich GhostAction auf gestohlene Entwickler-Credentials. Eine Analyse von StepSecurity vom 9. Oktober deutet darauf hin, dass die Angreifer wahrscheinlich persönliche Access Tokens verwendeten, die aus Credential-Dumps stammten, obwohl die ursprüngliche Quelle dieser Credentials noch unbestätigt ist. Mit gültigen Schreibzugriffen modifizierten die Angreifer Repository-Workflows direkt und umgingen so die Notwendigkeit jeglicher Schwachstelle in der GitHub Actions Plattform selbst.

Die bösartigen Dateien wurden mit harmlosen Namen wie security-audit.yml oder github_actions_security.yml getarnt. Diese Fake-Jobs referenzierten Secrets, die bereits von legitimen Build-Prozessen verwendet wurden, sodass sie laufen konnten, ohne sofortiges Misstrauen zu wecken, während sie im Hintergrund Credentials sammelten. GitHub’s Approval Controls blockierten viele dieser Workflows, aber die Angreifer passten sich an, indem sie 92 ältere Workflows aus früheren Angriffen wiederverwendeten, einige davon waren seit September 2025 aktiv gewesen.

Wie es funktioniert

Der Kernmechanismus des Angriffs bestand darin, YAML-Workflow-Dateien zu injizieren, die Standard-Checkout-Actions mit aggressivem History-Fetching ausführten. Konkret nutzten die Workflows actions/checkout@v4 mit dem Parameter fetch-depth: 0. Diese Konfiguration weist den Runner an, die gesamte Git-History herunterzuladen, statt nur den letzten Commit. Durch den Zugriff auf die vollständige History konnten die bösartigen Skripte nicht nur den aktuellen Working Tree, sondern auch vergangene Commits nach hartcodierten Secrets durchsuchen.

Die Scanner suchten nach einer breiten Palette von Credentials, darunter AWS Keys, persönliche Access Tokens für GitHub und GitLab, Google- und Firebase-Keys sowie API-Tokens von KI-Anbietern wie Anthropic, OpenAI und OpenRouter. Spätere Iterationen der Malware verbesserten ihre Extraktionslogik, indem sie umgebende Codezeilen erfassten, was es ermöglichte, AWS Key IDs ihren entsprechenden Secret Access Keys zuzuordnen, selbst wenn sie in der Dateistruktur getrennt waren.

Nach der Ernte wurden die Credentials über HTTP an einen angreiferkontrollierten Server unter der IP-Adresse 193.32.204.199 gesendet. Diese Methode ermöglichte es den Angreifern, Schlüssel abzurufen, die vor Monaten oder Jahren aus dem aktuellen Codebase entfernt worden waren, aber in der Git-History weiterhin zugänglich blieben. Der Exfiltrationsprozess war leise und nutzte die legitime Ausführungsumgebung von GitHub Actions, um sich in den normalen CI/CD-Traffic einzufügen.

Wichtige Details

• Etwa 1.900 GitHub-Konten wurden kompromittiert, um den Angriff zu ermöglichen.
• Bösartige Workflows wurden in mehr als 30.000 Repositories über 3.000 Benutzer und Organisationen hinweg eingeschleust.
• Die Angreifer zielten auf 3.174 Secrets, einschließlich Cloud-Keys und API-Tokens von KI-Anbietern.
• Workflows nutzten fetch-depth: 0, um die vollständige Git-History nach zuvor gelöschten Credentials zu scannen.
• Exfiltrierte Daten wurden per HTTP an die IP-Adresse 193.32.204.199 gesendet.
• Nur 16 % der betroffenen Repositories aus früheren Phasen waren bis zum 5. Oktober bereinigt worden.

Warum das wichtig ist

Dieser Vorfall hebt eine kritische Blindstelle in der modernen Entwicklungssicherheit hervor: die Persistenz von Secrets in der Git-History. Viele Teams gehen davon aus, dass das Entfernen eines hartcodierten Schlüssels aus dem aktuellen Branch das Risiko eliminiert. Da Git jedoch designbedingt unveränderlich (immutable) ist, bleiben diese Secrets in der History, es sei denn, sie werden explizit gelöscht. Die GhostAction-Kampagne zeigt, dass Angreifer diese Lücke aktiv ausnutzen und Standard-CI/CD-Tools verwenden, um alte Credentials wiederzufinden, die Entwickler möglicherweise vergessen haben.

Für Engineering-Leader und DevOps-Teams ist die Abhängigkeit von GitHub’s nativen Approval Controls nicht ausreichend. Obwohl GitHub viele bösartige Runs blockierte, führte die Fähigkeit der Angreifer, alte Workflows wiederzuverwenden und gültige Credentials zu nutzen, dazu, dass dennoch einige Exfiltrationen stattfanden. Die Tatsache, dass nur 16 % der zuvor betroffenen Repositories Monate nach der ersten Erkennung bereinigt wurden, deutet auf eine erhebliche Verzögerung bei Incident Response und Remediation-Bemühungen im gesamten Ökosystem hin.

Darüber hinaus signalisiert das Targeting von KI-Anbieter-Keys eine Verschiebung der Prioritäten der Angreifer. Da Unternehmen immer mehr KI-Services in ihre Produkte integrieren, sind API-Tokens für Anbieter wie OpenAI und Anthropic zu Zielen mit hohem Wert geworden. Das Kompromittieren dieser Keys kann nicht nur zu finanziellen Verlusten durch unbefugte Nutzung führen, sondern auch zu potenziellen Datenlecks, falls die Keys Zugriff auf proprietäre Modelle oder Kundendaten gewähren, die von diesen Services verarbeitet werden.

Was Sie tun können

• Überprüfen Sie GitHub Audit Logs und die Aktivität persönlicher Access Tokens, um Konten zu identifizieren, die kürzlich .github/workflows/ modifiziert haben.
• Prüfen Sie die Run-Historien von GitHub Actions, um Jobs zu erkennen, die unerwartet ausgeführt wurden oder auf Secrets zugriffen, die sie nicht benötigten.
• Widerrufen Sie Credentials für jedes kompromittierte Konto sofort, auch wenn der bösartige Workflow bereits gelöscht wurde.
• Rotieren Sie alle Cloud-Keys, Deployment-Credentials, Registry-Tokens und API-Keys von KI-Anbietern, die möglicherweise exponiert wurden.
• Scannen Sie Ihre vollständige Git-History nach hartcodierten Secrets, nicht nur den aktuellen Head, unter Verwendung von Tools, die für Deep-History-Inspektionen entwickelt wurden.
• Implementieren Sie strenge Approval-Anforderungen für Workflow-Änderungen und begrenzen Sie den Scope der persönlichen Access Tokens, die in CI/CD verwendet werden.