駭客用一年時間在 GitHub 上偷藏 10,000 個木馬，研究人員無心插柳才曝光

編按：本文綜合整理自 Orchid Files 原作者親自調查的 GitHub 木馬大規模散布事件，並交叉比對 Hexastrike、Trend Micro、Help Net Security 的相關安全研究，加入 Siami 編輯部觀點與分析。

一句話總結

一位獨立開發者從「發現自己倉庫被冒名頂替」開始追查，最後寫了一支小腳本，意外翻出 GitHub 上藏著 10,000 個散布木馬惡意程式的假倉庫——而且有些已經活了超過一年。

事件經過：一個意外的起點

故事起點很個人化。Orchid Files 的作者有一個 GitHub 專案，想確認搜尋引擎有沒有收錄。Google 找得到，但 Bing 出現另一個一模一樣名稱、一模一樣描述的倉庫。仔細一看：所有 commit 都複製過來，作者還被列為貢獻者——但幾小時前多了一個新 commit，把 README 裡某個連結換成了一個 zip 壓縮檔。

接下來在另一個專案的標籤裡，他又撞到同樣模式。這次他花時間監看，發現這些倉庫每幾小時就把上一次 commit 砍掉、重推一次一模一樣的內容，唯一差別只是 README 多了一個 zip 連結。

他向 GitHub Support 檢舉——兩週後沒回應。在 GitHub 討論區發文，三個人回了一堆「AI slop」般的罐頭建議。又過了一個月，Support 才回信說「已刪除」。

把模式抽象化，寫腳本撈出全貌

作者後來在半夜突然想通：要找出所有這類倉庫，必須先把共通模式寫成規則，再寫腳本全 GitHub 跑。

他歸納出 6 個必要條件：

1. 每隔幾小時刪前一個 commit、重推一次
2. 該 commit 只修改 README 一個檔案
3. README 內含一個 zip 壓縮檔連結
4. 所有 commit 是從別的倉庫複製來的
5. 不是 fork，是新倉庫
6. 不同貢獻者、不同名稱

GitHub 上有 5 億個倉庫，每個都得用 GitHub API 撈 commits、改動檔案、README 內容。一個 API token 一小時只能打 5,000 次，照這個速度要跑一年。

他改用 gharchive 服務——這服務會記錄每天所有 GitHub 事件。下載最近幾天的 event archive，過濾成「每 10 小時被 push 2 到 10 次」的倉庫（這種 cadence 才是可疑的更新模式）。

最近 5 天 GitHub 共有 1,600 萬次 commit push，符合「每幾小時就 push」這個條件的只有 3,000 個倉庫。再用 GitHub API 確認每個倉庫的具體改動內容。

加上額外條件：commit 必須來自真人帳號（不是 bot）、上次 commit 與上上次 commit 之間間隔超過一個月、貢獻者不只一人——剩下 14 個。但作者自己都覺得不對勁：「怎麼可能只有 14 個？應該還有更多吧。」

他親手人工複查，發現這 14 個 20 小時前才被更新。他原本的「每幾小時就 push」條件，把所有更新頻率較低的假倉庫都過濾掉了。而且還有另一種模式：commit 內容其實是「零改動」，但 README 裡本來就有 zip 連結——這種也會被他的腳本漏掉。

還有一個關鍵線索：所有假倉庫的最後一個 commit，訊息都一模一樣叫「Update README.md」。

放寬條件變成「24 小時內更新 1 到 24 次」之後，候選名單從 14 個膨脹到 40,000 個。其中 10,000 個完整符合所有模式——佔了 25%。每個都內含一支木馬。

木馬內容長什麼樣？

作者抽樣幾個假倉庫打開看，每個壓縮檔裡固定 4 個檔案：

• Application.cmd 或 Launcher.cmd（批次啟動腳本）
• loader.exe / luajit.exe 或其他名字的 exe
• 一個 .cso 或 .txt（誘餌檔）
• lua51.dll

最妙的是：

把 zip 裡的「exe 檔單獨」丟到 VirusTotal 掃，0 病毒警訊。 把整個 zip 檔丟進去掃，才會抓到木馬。

駭客故意把惡意 payload 切成好幾段、藏在 zip 結構裡的 metadata / 隱藏欄位，讓單檔掃毒看不出來。這跟 2026 年 3 月 Help Net Security 報導的「GitHub-hosted malware uses split payload to evade detection」是同一個套路——Netskope 研究人員發現 OpenClaw AI 假倉庫用的也是這種 LuaJIT-based trojan。

駭客的兩個目標

Orchid Files 作者在文末推測這批攻擊者的動機：

目標一：摸熟 GitHub 演算法。

為什麼要每幾小時刪 commit 重推一次？為什麼 commit 訊息永遠叫「Update README.md」？最有可能的答案是：這種 cadence 跟 commit 訊息能繞過 GitHub 的安全偵測。他們在用 10,000 個倉庫當大型 A/B 測試樣本，研究 GitHub 哪條規則有效、哪條規則形同虛設。

目標二：讓受害者自己找上門。

為什麼只 clone 新倉庫、不碰熱門的？新倉庫會立刻出現在低競爭關鍵字的搜尋結果頂端。Bing、Google、GitHub 自己的搜尋都是這個排序邏輯——新內容有優先曝光加成。他們也會把假倉庫塞進熱門標籤裡（如 lua、gaming、ai），增加被搜出來的機會。

為什麼連 commit 歷史都完整複製？這是「信任偽裝」：使用者點進倉庫會看到「這個專案已經運作幾個月、貢獻者都是正常帳號」，降低警覺。同時也繞過 GitHub 用 commit 數量、帳號年齡判斷「是否為垃圾帳號」的演算法。

🚨 為什麼這件事重要

這不是單一駭客的即興攻擊，這是一條自動化、大規模、運作了至少 12 個月的攻擊鏈。Orchid Files 不是第一個發現的——Hexastrike 在 2026 年 4 月就揭露了 109 個同樣模式的假倉庫（命名為「SmartLoader + StealC」攻擊鏈），當時他們還不知道規模已經膨脹到 10,000 個。

把這兩份報告並排看：

短短兩個月成長 91 倍，代表：

1. 這個攻擊模式已經驗證有效、可以自動化量產——不是實驗，是量產線。
2. GitHub 的偵測系統完全沒跟上。10,000 個假倉庫裡面還有很多存活超過一年，作者自己當初檢舉只有「2 個」GitHub Support 也拖了一個月才處理。
3. 目標正在從「人」轉向「AI agent」——Hacker News 上 guhcampos 留言指出，現代開發流程大量依賴 AI agent 自動搜尋依賴套件，「在搜尋結果佔一小部分，偶爾成功一次」就足以擴散感染。

對台灣 / 華文開發者的具體意義：台灣開源社群大量使用 GitHub，許多公司內部工具、side project 也是。如果你的 GitHub 搜尋結果曾跳出「看起來正常但有 zip 連結」的倉庫，你可能早就被列入散播路徑之一，只是還沒人下載那個 zip。

🚨 數據解讀與質疑

幾個值得停下來想一下的數字：

1. 10,000 / 40,000 = 25% 的命中率

作者放寬條件後，40,000 個高頻更新倉庫裡有 10,000 個確實藏木馬。這個 25% 高得離譜——一般 GitHub 上 40,000 個隨機倉庫，藏木馬的應該 < 0.1%。這個比例本身就是「GitHub 已被系統性污染」的證據，不是「個案」。

2. 為什麼 GitHub 自己沒抓到？

作者文中直接點出：他受限於一小時 5,000 次 API 上限，腳本其實只跑了很小的覆蓋率。GitHub 內部沒有這個限制，但他們分析 5 億個倉庫的成本也不低。真正的問題是：GitHub 把「掃描 zip / exe」當作 lazy load（使用者下載才掃），而不是 build-time 掃描。

3. VirusTotal 對「單檔 exe」抓不到木馬

這個發現特別值得注意：把 exe 單獨掃是 0 警告，把整個 zip 掃才會跳警告。意思是大多數開發者「下載 → 掃 exe → 看到乾淨 → 執行」的安全習慣，在這個攻擊鏈下完全失效。正確做法是掃整個 zip、並在隔離環境（如 VM / sandbox）執行。

4. Orchids 的 14 個 vs 真實的 10,000 個

作者一開始只找到 14 個時，以為「可能真的只有 14 個」。事實上他條件設錯漏了 99.86%。這告訴我們：威脅情資研究裡的「負面結果」幾乎永遠是誤判，不是真的「沒有威脅」。

業界與社群反應

文章在 Hacker News 拿到 361 點、102 則留言（截至 Siami 撰稿時），引發幾個重要討論：

針對 TOTP/MFA 該不該放密碼管理員：

tedd4u 留言引發小辯論——「這個案子的 Disney 工程師就是把 MFA 放在 1Password 裡，結果被一起偷走」。8cvor6j844qw_d6 反駁：「同樣道理，密碼管理員本來就假設裝置沒被感染，沒有『專為受感染裝置設計』的密碼管理員。重要帳號的 TOTP 該放 Yubikey。」

針對 GitHub OAuth 權限混亂：

socalgal2 直接開砲：「GitHub 的授權系統連『這支 app 會要求哪些權限』都沒清楚告訴使用者。」多數使用者點下去根本不知道自己給了什麼。

針對攻擊者的目標不是人：

guhcampos 提出新觀點——「他們不是要騙人，是要騙 AI agent。現代開發流程大量依賴 agent 搜尋依賴套件，駭客只要在搜尋結果佔一小部分就能擴散感染。」這個論點跟 2026 年 AI 開發普及的趨勢直接相關。

針對 GitHub 的態度：

mustaphah 直接開嗆：「GitHub 完全不在乎惡意程式的規模問題。」他附上自己經營 GitHub trends newsletter 看到的無數案例佐證。

待觀察的後續發展

1. GitHub 會全面掃描 5 億個倉庫嗎？ 作者文章發布後，GitHub 已開始刪除腳本找到的那批 10,000 個倉庫。但其他 4.99 億個沒被這個腳本找到的，怎麼辦？
2. AI agent 攻擊面會持續擴大嗎？ guhcampos 點出的「攻擊 agent」是新興領域，未來可能出現專門針對 Cursor、Claude Code、Devin 等 AI 編程工具的倉庫污染攻擊。
3. 下游供應鏈攻擊事件何時會爆？ 10,000 個假倉庫、每個都有人下載過，一定有人中標。只是受害者還沒公開通報。等第一個被勒索軟體找上門的開發者公開故事，會是下個重大新聞。

給讀者的具體建議

如果你最近從 GitHub 下載過開源工具，特別是 AI 工具、遊戲外掛、盜版軟體周邊工具：

• 重新掃毒整個 zip 檔（不是只掃 exe）
• 檢查該倉庫最後一個 commit 訊息是不是「Update README.md」——這是這波攻擊鏈的指紋
• 檢查 commit 歷史的時間分佈——如果前 N 個 commit 都集中在某天，後面才開始持續更新，幾乎可以確定是冒名倉庫
• 重要專案的依賴套件，不要用 AI agent 自動搜尋結果的第一個——手動到套件官網 / PyPI / npm 確認作者與下載量