Grafana GitHub Token 外洩與原始碼勒索事件解析

呢些資料之後被用來登入並下載多個私有 repository。

Grafana 發現異常活動後，立即撤銷相關 token 並停用有問題的 workflow，同時展開取證調查。

值得注意的是，調查結果顯示攻擊者 只是讀取並下載資料，沒有修改原始碼、植入惡意程式，亦沒有破壞系統。

黑客提出勒索

取得原始碼之後，攻擊者聯絡 Grafana，提出一個典型的「pay‑or‑leak」勒索：

如果公司付款，黑客就不會公開被盜的原始碼；如果拒絕，就可能把程式碼公開或出售。

這類攻擊模式近年愈來愈常見。與傳統勒索軟件不同，黑客不一定會加密系統，而是直接偷走資料，再利用公開威脅迫企業付款。

Grafana 最終選擇拒絕付款。

為甚麼 Grafana 拒絕支付贖金

Grafana 表示，內部調查確認以下幾點：

• 沒有客戶資料或個人資料被存取
• 沒有生產系統受到入侵
• 公司業務運作沒有受到影響

由於攻擊者只取得原始碼，而沒有掌握客戶資料或系統控制權，勒索的壓力相對較低。因此 Grafana 決定不向黑客付款。

公司亦同時撤銷被盜憑證並加強安全控制，以防止類似事件再次發生。

是否有已知黑客組織參與？

目前公開資料 未能確定攻擊者身份。

不過，安全研究人員指出，事件的操作方式與一些資料勒索組織相似，例如 ShinyHunters。這個組織以入侵企業、竊取資料，再威脅公開或出售資料而聞名。

這類團體通常採用「偷資料 → 勒索 → 若拒絕就公開或出售」的商業模式，而不是像傳統 ransomware 那樣加密系統。

目前並沒有證據證明 ShinyHunters 參與了 Grafana 事件，但整體策略確實與其常見行動模式相似。

對客戶與系統的實際影響

Grafana 強調事件影響範圍有限。

調查結果顯示：

• 沒有客戶資料或個人資料被存取
• 沒有生產環境系統被入侵
• 公司服務與營運未受影響

目前確認的影響主要是 部分私有 GitHub repository 的原始碼被下載。

為甚麼這宗事件值得整個科技行業注意

即使沒有客戶資料外洩，原始碼被盜本身仍然有價值。

私有程式碼庫可能揭示：

• 內部系統架構
• 安全設計與憑證處理方式
• 尚未發布的新功能
• 未被發現的潛在漏洞

這些資訊日後可能被用來發動更深入的攻擊。

Grafana 的案例亦說明了一個重要問題：開發流程本身已成為供應鏈安全的關鍵戰場。像 GitHub token、CI/CD pipeline、以及自動化 workflow 的安全性，如果處理不當，一個憑證外洩就可能讓攻擊者接觸到整個程式碼庫，而無需真正入侵生產系統。

隨住愈來愈多公司依賴雲端開發平台，保護開發憑證與自動化流程，已經成為現代軟件供應鏈安全不可忽視的一環。