Grafana‑GitHub‑Token kompromittiert: Angriff, Erpressung und die Folgen für die Software‑Supply‑Chain

Die Untersuchung führte die Ursache später auf eine verwundbare GitHub‑Actions‑Konfiguration zurück. Der Angreifer manipulierte einen Fork eines Repositories und schleuste Befehle in den Workflow ein, um Umgebungsvariablen – darunter Zugangsdaten – aus der Workflow‑Umgebung auszulesen.

Mit diesen gestohlenen Zugangsdaten konnte der Angreifer mehrere private Repositories abrufen und deren Inhalte herunterladen, bevor die Aktivitäten entdeckt wurden. Grafana widerrief anschließend die betroffenen Tokens und deaktivierte die fehlerhafte Workflow‑Konfiguration.

Wichtig ist dabei: Nach Angaben der Untersuchung handelte es sich um einen reinen Datenzugriff. Der Angreifer lud Code herunter, änderte jedoch keine Repositories und installierte keine Malware in Grafanas Systemen.

Die Lösegeldforderung

Nachdem der Quellcode kopiert worden war, kontaktierte der Angreifer das Unternehmen und verlangte Geld. Im Gegenzug versprach er, den gestohlenen Code nicht öffentlich zu veröffentlichen.

Solche Angriffe werden häufig als „Pay‑or‑Leak“‑Erpressung bezeichnet. Anders als bei klassischer Ransomware werden Systeme nicht verschlüsselt. Stattdessen stehlen Angreifer wertvolle Daten und drohen mit deren Veröffentlichung, falls das Opfer nicht zahlt.

Grafana entschied sich gegen eine Zahlung.

Warum Grafana die Forderung ablehnte

Nach eigenen Angaben fand das Unternehmen keine Hinweise darauf, dass Kundendaten, persönliche Informationen, Produktionssysteme oder Geschäftsabläufe betroffen waren.

Da sich der Zugriff ausschließlich auf Quellcode‑Repositories beschränkte, war der Druckmittel‑Effekt für den Angreifer deutlich geringer. Ohne kompromittierte Kundendaten oder Betriebsstörungen entschied sich Grafana, der Erpressung nicht nachzugeben.

Parallel dazu implementierte das Unternehmen zusätzliche Sicherheitsmaßnahmen und sperrte alle kompromittierten Zugangsdaten.

Wer hinter dem Angriff steckt

Eine eindeutige Zuordnung zu einer bestimmten Hackergruppe gibt es bislang nicht. Die Täterschaft ist öffentlich weiterhin unklar.

Sicherheitsforscher vergleichen solche Vorfälle jedoch häufig mit Kampagnen von Gruppen wie ShinyHunters. Diese Gruppe ist dafür bekannt, in Systeme einzudringen, Daten zu stehlen und anschließend Geld zu verlangen, um eine Veröffentlichung zu verhindern.

Typisch für diese Akteure ist ein Geschäftsmodell, das auf Datendiebstahl und Monetarisierung basiert – etwa durch Verkauf der Daten oder durch öffentliche Leaks, wenn Opfer nicht zahlen.

Für den Grafana‑Vorfall gibt es jedoch keinen bestätigten Beweis, dass ShinyHunters tatsächlich dahintersteckt. Die Vorgehensweise ähnelt lediglich bekannten Mustern solcher Gruppen.

Auswirkungen auf Kunden und Systeme

Grafana betonte mehrfach, dass der Vorfall keine Auswirkungen auf Kundenumgebungen oder operative Systeme hatte.

Nach der internen Untersuchung gilt:

• Es wurden keine Kundendaten oder persönlichen Informationen abgerufen.
• Produktionssysteme wurden nicht kompromittiert.
• Der Geschäftsbetrieb blieb unbeeinträchtigt.

Der bestätigte Schaden beschränkte sich damit auf den Diebstahl von Quellcode aus privaten GitHub‑Repositories.

Warum der Vorfall für die Software‑Supply‑Chain wichtig ist

Auch ohne Kundendaten kann gestohlener Quellcode für Angreifer wertvoll sein.

Private Repositories können beispielsweise Einblicke geben in:

• interne Systemarchitektur
• Sicherheitspraktiken und Umgang mit Zugangsdaten
• unveröffentlichte Funktionen oder geistiges Eigentum
• potenzielle Schwachstellen für zukünftige Angriffe

Genau deshalb sind Entwicklerplattformen wie GitHub, Zugriffstoken und CI/CD‑Automatisierung inzwischen attraktive Ziele für Angreifer.

Der Grafana‑Vorfall zeigt deutlich, wie ein einziger kompromittierter Token innerhalb eines automatisierten Workflows ausreichen kann, um Zugang zu sensiblen Code‑Beständen zu erhalten – selbst ohne direkten Angriff auf Produktionssysteme.

Mit der zunehmenden Nutzung cloudbasierter Entwicklungsplattformen wird daher klar: Der Schutz von Entwickler‑Credentials und Build‑Pipelines ist heute ein zentraler Bestandteil moderner Software‑Supply‑Chain‑Sicherheit.