研究顯示整個攻擊發生在 11:36 至 17:48(UTC) 之間,顯示攻擊完全由自動化工具驅動,目的是在維護者發現前快速滲透大量專案。
這次行動結合了自動化與「社交偽裝」,讓惡意提交看起來像正常的 CI 維護更新。
攻擊者建立大量一次性 GitHub 帳號,並使用看似自動化工具的名稱,例如:
這些名稱讓提交看起來像是自動化系統產生,而不是駭客操作。
提交訊息與作者資訊被精心設計成常見的 CI 更新,例如「更新 workflow」或「調整 pipeline」。這種做法讓惡意變更能混入正常開發歷史中,延後被察覺的時間。
攻擊活動主要針對 沒有嚴格 branch protection 規則的專案。在缺乏強制 Pull Request 審查或權限限制的情況下,攻擊者可以直接把 workflow 檔案推送到預設分支。
每一次惡意提交都會新增一個 GitHub Actions workflow,其中包含 Base64 編碼的 Bash 腳本。當 CI pipeline 執行時,腳本會在 runner 環境中解碼並執行,開始收集敏感資訊。
因此許多專案在提交後並不會立刻出現異常,而是在下一次 CI 執行時才觸發攻擊。
這些 workflow 內嵌的腳本主要目標是 CI/CD 環境中的憑證與機密資料,並將其傳送到攻擊者控制的伺服器。
研究報告指出其蒐集目標包括:
腳本會讀取系統環境資訊與 CI 變數,蒐集後再傳送到攻擊者的指揮與控制(C2)伺服器。
由於 CI pipeline 通常擁有部署權限,一旦取得這些憑證,攻擊者就可能進一步進入雲端基礎設施、套件倉庫甚至生產環境。
Megalodon 攻擊的一個核心目標是 GitHub Actions 的 OIDC token。
在現代 CI/CD 架構中,許多團隊使用 OpenID Connect(OIDC)身分聯盟 讓工作流程直接向雲端平台取得短期憑證,而不需要儲存長期 API 金鑰。
例如:
這種設計本來是為了提高安全性,但如果攻擊者能在 pipeline 執行期間竊取 token,就可能 短暫冒充該 CI 任務的身分。
被竊取的 token 可能被交換成具有相同權限的雲端臨時憑證,導致:
即使 token 有效時間很短,只要權限足夠,攻擊者仍然可以在短時間內造成重大影響。
在同一時期,GitHub 也披露另一個安全事件:一名員工的裝置安裝了 遭植入惡意程式的 Visual Studio Code 擴充套件,導致約 3,800 個 GitHub 內部儲存庫 被未授權存取。
該事件的攻擊方式是透過被污染的 VS Code Marketplace 擴充套件竊取憑證並取得內部存取權。
一些安全研究指出,這些事件在時間點與攻擊手法上有相似之處。但目前 沒有公開證據證明這次內部 GitHub 事件直接導致 Megalodon 攻擊。
因此多數研究者將兩者視為 同一時間發生、但彼此獨立的供應鏈安全事件。
Megalodon 顯示供應鏈攻擊的重點正從「程式碼」轉向 自動化與部署基礎設施。
透過修改 CI workflow,攻擊者可以:
對於依賴 CI/CD 部署的現代軟體團隊而言,以下措施變得更加重要:
隨著 CI/CD 系統逐漸成為雲端部署的核心控制點,保護自動化流程本身,已成為軟體供應鏈安全的關鍵防線。