這是一篇針對近期名為 Megalodon 的大規模 GitHub 攻擊事件的技術分析。對於剛接觸 DevOps 或 CI/CD 的工程師來說，最重要的一點是：你的自動化流水線（Pipeline）不僅僅是部署工具，它其實是一個擁有高度權限的執行環境。如果這個環境被污染，駭客拿走的將不只是程式碼，而是你整個雲端基礎設施的鑰匙。
理解 Megalodon 攻擊的運作邏輯
Megalodon 這次攻擊的核心在於利用 GitHub Actions 的工作流（Workflow）來植入惡意程式碼。GitHub Actions 是一種 CI/CD 工具，允許開發者定義在特定事件（例如 Push 或 Pull Request）發生時自動執行的指令。
駭客採取了自動化的大規模攻擊，在短短六小時內向 5,561 個儲存庫推送了超過 5,700 個惡意提交（Commits）。他們使用隨機生成的臨時帳號，並偽造作者身分（例如命名為 build-bot 或 ci-bot），讓這些提交看起來像是例行的 CI 維護更新，降低維護者的警覺心。
攻擊的技術手段
駭客在工作流檔案中植入了經過 Base64 編碼的 Bash 腳本。Base64 編碼是一種將二進位數據轉換為文字的方式，在這裡被用來掩蓋惡意指令的真實意圖，避開簡單的關鍵字掃描。
根據攻擊目的，他們使用了兩種不同的觸發模式：
第一種是 SysDiag 變體，設定為在每次 Push 或 Pull Request 時觸發。這種方式覆蓋面最廣，只要有提交動作就會執行，能快速擴散。
第二種是 Optimize-Build 變體，僅在 workflow_dispatch 時觸發。這是一種手動觸發機制，允許使用者按需執行。雖然觸發率較低，但具有更好的隱蔽性（Operational Security），能避開自動化監控，在特定的目標環境中精準執行。
為什麼 CI/CD 環境如此危險
當維護者不小心合併了這些惡意提交後，惡意腳本會在 CI/CD 的 Runner（執行環境）中執行。對於工程師來說，必須意識到 Runner 環境通常存有極其敏感的資訊，因為自動化部署需要這些權限。
Megalodon 攻擊目標明確，旨在竊取以下類型的機密資訊：
雲端憑證：包括 AWS、Google Cloud 和 Azure 的存取令牌（Tokens）以及實例元數據服務（IMDS）提供的權限。 環境變數：CI 流程中定義的 Secrets、API Key、資料庫連接字串。 基礎設施金鑰：SSH 私鑰、Terraform 憑證、Vault 令牌。 身份驗證令牌：GITHUB_TOKEN 以及 GitLab 或 Bitbucket 的相關 Token。
一旦這些資訊被外傳到駭客的 C2 伺服器（Command and Control Server，即指令控制伺服器），駭客就擁有了進入公司雲端環境的通行證，可以直接操控伺服器或竊取資料庫。
更深層的供應鏈威脅：TeamPCP 與 NPM 攻擊
Megalodon 並非孤立事件，它被認為與 TeamPCP 這個駭客組織有關。這類攻擊屬於典型的供應鏈攻擊（Supply Chain Attack），即不直接攻擊目標公司，而是攻擊目標公司所依賴的開源工具或套件。
除了 GitHub Actions，駭客也針對 NPM 套件生態系發動攻擊。例如，有攻擊者發布偽裝成 Polymarket 交易工具的惡意套件，利用 postinstall hook（套件安裝後自動執行的腳本）來誘導使用者輸入以太坊私鑰。這顯示了駭客正將社交工程（Social Engineering）與技術漏洞結合，利用開發者對開源工具的信任來獲利。
工程實務上的防禦建議
面對這種趨勢，開發團隊不能只依賴平台方的安全性，而應採取以下實務措施：
嚴格審核所有對工作流檔案（.github/workflows）的修改。任何變更 CI/CD 邏輯的提交都必須經過嚴格的 Code Review，絕不能因為看起來像 bot 的維護更新就直接合併。
限制 GITHUB_TOKEN 的權限。在 GitHub Actions 設定中，將預設的權限設為唯讀（read-all），僅在必要時才為特定 Job 開啟寫入權限。
避免在環境變數中存放長期有效的金鑰。建議使用 OIDC（OpenID Connect）與雲端平台（如 AWS, GCP）對接，實現短暫、動態的身份驗證，取代靜態的 Secret Key。
啟用 NPM 的 Trusted Publishing。減少對具有寫入權限且繞過二階段驗證（2FA）的 Token 依賴，降低 Token 被盜後直接污染套件庫的風險。
來源：thehackernews.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。