整個攻擊窗口大約在 UTC 11:36 至 17:48 之間,顯示攻擊很可能完全自動化,目標是在維護者發現前快速滲透大量倉庫。
Megalodon結合自動化腳本同「社交偽裝」,令惡意提交看起來像正常的CI維護更新。
攻擊者建立大量一次性GitHub帳號,並偽裝成自動化服務,例如:
呢類名稱通常出現在CI系統,自然降低開發者的警覺性。
提交訊息與作者資訊都被精心設計,看起來像例行的CI設定更新或workflow優化。結果就是這些惡意提交很容易混入正常開發歷史中,延遲被發現的時間。
攻擊活動主要針對 branch protection(分支保護)不足 的倉庫。如果沒有強制Pull Request審核、或允許過多帳號直接修改workflow檔案,攻擊者就可以把變更直接推到預設分支。
每個惡意提交都新增一個 GitHub Actions workflow檔案,裏面包含 Base64編碼的Bash payload。當CI pipeline運行時,腳本就會在GitHub Actions runner中執行。
因此攻擊通常不會即時發作,而是等到下一次CI自動化流程被觸發時才開始偷取資料。
這段Base64編碼腳本的主要目標是 CI環境中的憑證與秘密資訊,然後把資料傳送到攻擊者控制的伺服器。
研究報告指出,目標資料包括:
腳本會掃描runner環境變數、系統資訊甚至 /proc/*/environ 等系統路徑,收集可用的秘密資料再外傳。
由於CI pipeline通常持有部署權限,一旦被入侵,攻擊者就可能進一步進入:
Megalodon其中一個重點目標是 GitHub Actions OIDC(OpenID Connect)令牌。
現代CI/CD系統越來越多使用 OIDC聯邦身份驗證 來登入雲端服務,而不再儲存長期API金鑰。例如GitHub Actions可以透過OIDC向雲端平台請求短期憑證。
好處是:
但同時也帶來新風險:
如果攻擊者在CI運行期間 偷到OIDC令牌,就可能暫時冒充該CI工作流程的身份。
由於雲端平台信任這些令牌,攻擊者有機會把它交換成 臨時雲端存取權限,而權限級別與原本CI部署流程相同。
結果可能包括:
即使令牌有效時間很短,對攻擊者來說仍然足夠發動下一步滲透。
差不多同一時間,GitHub亦披露另一宗安全事故:
一名員工裝了 被植入惡意程式的VS Code擴充套件,導致攻擊者能夠存取約 3,800個GitHub內部倉庫。
該事件屬於開發環境被入侵,惡意擴充套件會收集憑證與token,再讓攻擊者進入GitHub內部系統。
有些安全分析指出,兩宗事件在 時間與供應鏈攻擊模式 上有某些相似之處。不過目前公開證據 未能證明VS Code事件直接導致Megalodon攻擊。
因此普遍看法是:
Megalodon顯示供應鏈攻擊策略正逐漸轉向 開發自動化基礎設施。
與其改程式碼,攻擊者更傾向:
由於CI/CD pipeline通常持有大量權限,一個被修改的workflow就可能影響整個部署鏈。
安全團隊普遍建議採取以下防護措施:
隨著開發流程越來越依賴自動化,CI/CD安全已經成為軟件供應鏈防禦的核心環節。