GhostAction-Kampagne zielt auf GitHub-CI/CD-Geheimnisse über kompromittierte Konten ab

Eine erneute Welle des GhostAction-Angriffs auf die Lieferkette hat zwischen dem 8. und 9. Oktober 2026 etwa 1.900 GitHub-Benutzerkonten kompromittiert. Sicherheitsforscher von GitGuardian beobachteten, wie Angreifer mehr als 30.000 Repositories von 3.000 Benutzern und Organisationen ins Visier nahmen, um sensible Zugangsdaten aus Continuous-Integration-Umgebungen zu extrahieren.

Was passiert ist

Die Kampagne, die erstmals im September 2025 identifiziert wurde, basiert darauf, dass Angreifer Schreibzugriff auf legitime Entwickler-Repositories erhalten. Dies erreichen sie durch die Verwendung gestohlener Personal Access Tokens (PATs) oder durch Credentials, die aus Logs von Infostealer-Malware geerntet wurden. Sobald sie sich im System befinden, injizieren die Angreifer bösartige GitHub Actions Workflow-Dateien in die betroffenen Repositories. Diese Dateien werden oft mit irreführenden Namen wie "security-audit.yml" oder "github_actions_security.yml" getarnt, um bei oberflächlichen Code-Reviews keinen sofortigen Verdacht zu erregen.

Das primäre Ziel ist der großangelegte Diebstahl von Geheimnissen, die in CI/CD-Pipelines gespeichert sind. Dazu gehören Cloud-Provider-Zugangsdaten, Paket-Registry-Tokens für Dienste wie npm, PyPI und DockerHub sowie API-Schlüssel für KI-Anbieter. Der jüngste Anstieg der Aktivität stellt eine erhebliche Eskalation dar, wobei die Angreifer versuchten, 3.174 Geheimnisse aus öffentlichen Repositories zu extrahieren. Gaetan Ferry und Guillaume Valadon von GitGuardian merkten an, dass die Kompromittierung von 1.900 Konten die direkte Ursache dieses weit verbreiteten Versuchs war.

Diese neue Phase von GhostAction scheint experimenteller und manueller zu sein als frühere Iterationen. Die Payload hat sich seit dem 31. August 2026 durch mehrere Versionen entwickelt. Die erste Version führte eine Funktion ein, die den Git-Historie-Verlauf nach Geheimnissen scannt und dabei reguläre Ausdrücke verwendet, um AWS-Key-IDs, GitHub- und GitLab-Tokens sowie andere Cloud-API-Schlüssel zu identifizieren. Spätere Varianten verbesserten diese Fähigkeit, indem sie den Kontext um AWS-Key-IDs erfassten, um sie mit ihren entsprechenden Secret Access Keys zu paaren, was die Wahrscheinlichkeit erhöhte, dass die gestohlenen Daten nutzbar wären.

Wichtige Details

• Ausmaß der Auswirkungen: Der Anstieg am 8.–9. Oktober zielte auf über 30.000 Repositories ab, die zu 3.000 Benutzern und Organisationen gehörten.
• Konto-Kompromittierung: Etwa 1.900 GitHub-Konten wurden unter Verwendung gestohlener PATs oder Credentials aus Infostealer-Logs kompromittiert.
• Zielgeheimnisse: Angreifer versuchten, 3.174 Geheimnisse zu extrahieren, darunter Cloud-Zugangsdaten, Paket-Tokens und KI-API-Schlüssel.
• Payload-Entwicklung: Der bösartige Workflow entwickelte sich so weiter, dass er das Scannen der Git-Historie einschloss; spätere Versionen erfassten den Kontext um AWS-Schlüssel, um den vollständigen Diebstahl von Zugangsdaten zu erleichtern.
• Bereitstellungsmethode: Bösartige Workflows wurden unter irreführenden Namen wie "security-audit.yml" gepusht, um sich in legitime Wartungsaufgaben einzufügen.
• Timing der Gegenmaßnahmen: GitHub begann am 9. Oktober damit, die Ausführung des bösartigen Workflows zu verhindern, wodurch nachfolgende Wellen am 10. und 12. Oktober daran gehindert wurden, neue Geheimnisse zu extrahieren.

Hintergrund

GitHub Actions ist eine beliebte Automatisierungsplattform, die Entwicklern ermöglicht, Workflows zum Erstellen, Testen und Bereitstellen von Code direkt innerhalb ihrer Repositories zu definieren. Diese Workflows erfordern häufig Zugriff auf sensible Informationen wie Datenbank-Passwörter oder Schlüssel für Cloud-Dienste, die als "Secrets" in den Repository-Einstellungen gespeichert werden. Obwohl dies bequem ist, macht diese Zentralisierung CI/CD-Pipelines zu einem lohnenden Ziel für Angreifer. Wenn ein Angreifer die Workflow-Definition ändern kann, kann er Skripte ausführen, die diese Secrets an externe Server exfiltrieren.

Angriffe auf die Lieferkette wie GhostAction nutzen das inhärente Vertrauen in Softwareentwicklungs-Ökosysteme aus. Durch die Kompromittierung eines einzelnen Entwicklerkontos können Angreifer bösartigen Code in jedes Projekt verbreiten, das diese Person verwaltet. Dies ist besonders gefährlich, da der bösartige Code von einer vertrauenswürdigen Quelle stammt, was es automatisierten Sicherheitstools oder Peer-Reviewern erschwert, ihn zu erkennen. Die Nutzung von Infostealer-Malware zur Ernte erster Credentials unterstreicht die Bedeutung der Endpoint-Sicherheit neben plattformspezifischen Schutzmaßnahmen.

Warum es wichtig ist

Für Teams, die ihre eigene Software-Infrastruktur verwalten, unterstreicht dieser Vorfall die Fragilität des Credential-Managements in CI/CD-Pipelines. Viele Organisationen verlassen sich auf langfristige Secrets, die selten rotiert werden. Die Tatsache, dass eine Untergruppe der Opfer in dieser neuen Welle bereits in früheren Angriffen kompromittiert worden war, deutet darauf hin, dass Angreifer darauf setzen, dass nicht rotierte Secrets weiterhin gültig bleiben. Wenn Ihr Team API-Schlüssel und Tokens nicht regelmäßig rotiert, kann ein einzelner Einbruch langfristige Folgen haben und Angreifern auch nach dem Patchen der ursprünglichen Schwachstelle Zugang gewähren.

Darüber hinaus zeigt die Entwicklung der GhostAction-Payload, dass Angreifer aktiv defensive Maßnahmen umgehen. Das Hinzufügen des Scannens der Git-Historie bedeutet, dass das bloße Entfernen eines Secrets aus der aktuellen Codebasis unzureichend ist, wenn es im Commit-Verlauf existiert. Teams müssen davon ausgehen, dass jedes jemals in ein Repository committete Secret potenziell exponiert ist. Dies erfordert einen Strategiewechsel von reaktiver Bereinigung zu proaktivem Secret-Management, einschließlich der Verwendung kurzlebiger Tokens und strenger Zugriffssteuerungen für Repository-Änderungen.

Was Sie tun können

• Rotieren Sie alle CI/CD-Secrets sofort: Gehen Sie davon aus, dass jedes in einem GitHub-Repository gespeicherte Secret exponiert sein könnte, wenn Ihr Konto Teil der betroffenen Benutzerbasis war oder wenn Sie ähnliche Muster verwenden.
• Aktivieren Sie Branch-Protection-Regeln: Erzwingen Sie Pull-Request-Reviews und Statusprüfungen vor dem Merge in Hauptbranches, um unbefugte Workflow-Modifikationen zu verhindern.
• Auditiert die Git-Historie auf Secrets: Verwenden Sie Tools, um Ihre gesamte Commit-Historie auf geleakte Credentials zu scannen, nicht nur den aktuellen Head des Branches.
• Implementieren Sie Least-Privilege-Zugriff: Beschränken Sie, wer Workflow-Dateien pushen und Secrets in Ihren Repositories verwalten darf, um die Schadensausbreitung eines kompromittierten Kontos zu reduzieren.
• Verwenden Sie kurzlebige Credentials: Ersetzen Sie, wo möglich, langfristige API-Schlüssel durch temporäre Tokens, die automatisch ablaufen, um das Zeitfenster für Angreifer zu begrenzen.
• Überwachen Sie ungewöhnliche Workflow-Aktivitäten: Richten Sie Warnungen für Änderungen an Workflow-Dateien ein, insbesondere für solche mit Namen, die Sicherheitsaudits oder Wartungsaufgaben ähneln.