C2Looper 如何運作？從 HTTP Beacon 到 GitHub 指令中心

C2Looper 是一款新近被識別的 Rust 系 Windows 後門，能讓攻擊者取得受害主機的遠端控制權，執行命令、蒐集系統資訊、下載檔案並部署後續負載。Zscaler ThreatLabz 於 2026 年 7 月發現這個惡意軟體家族，並評估它可能被與勒索軟體相關的威脅行動者使用。不過，這仍屬研判，並非已確認的身分歸屬；其可能的投遞途徑也只有低至中等信心。

C2Looper 最值得注意的變化，是從早期的傳統明文 HTTP 命令與控制（C2），轉向利用 GitHub 儲存庫承載指令和回傳結果。對防禦團隊而言，這代表需要同時留意兩種截然不同的行為：舊版規律而密集的 HTTP Beacon，以及新版以每部主機為單位、透過 JSON 檔案運作的 GitHub 任務流程。

為什麼 C2Looper 與勒索軟體防禦有關？

C2Looper 本身並不是勒索軟體。它更像是入侵初期的「立足點」工具：攻擊者可藉此執行遠端命令、了解主機環境、下載檔案，再部署其他工具。這些能力有助於攻擊者在最初入侵後建立持久存取、擴大內部網路權限，為後續勒索軟體行動做準備。

目前公開資料並未證實 C2Looper 由某個已知勒索軟體團體操控。若研究報告提到它與其他惡意軟體基礎設施存在相似之處，應視為調查線索，而不是共同作者或同一行動控制者的證明。

C2Looper 的兩個版本如何運作？

舊版：直接連線至 HTTP C2 伺服器

早期樣本會透過明文 HTTP 與攻擊者控制的伺服器通訊，並使用 JSON 格式傳送任務。相關報告指出，它的輪詢頻率非常高，間隔可能約為 1 秒；這種規律性可能在端點或網路遙測中留下明顯訊號。

植入程式會在 Beacon 中提供多項受害主機資訊，包括：

• Windows 使用者名稱
• DNS 主機名稱
• 正在執行的 C2Looper 程序 ID
• 由主機名稱與使用者名稱衍生的 Bot 識別碼

Beacon 會傳送至 /api/beacon，而命令執行結果則透過 /api/result/ 回傳。

可用命令讓操作者取得實際的主機控制能力，包括：

• 執行任意 Shell 或系統命令
• 進行主機與系統偵察
• 下載檔案
• 更新植入程式與部署其他負載

其中一條值得注意的更新流程使用 upload 命令，從操作者提供的 URL 下載可攜式執行檔，並將它以 DLL 形式儲存於使用者的本機 OneDrive 目錄。接著，惡意程式可停止 OneDrive 程序，再利用合法的 OneDrive 執行檔載入這個被植入的 DLL，形成 DLL 側載。已回報的樣本使用 wtsapi32.dll，位置為 %LocalAppData%\\Microsoft\\OneDrive。

這種手法是把惡意程式放在可信任執行檔旁邊，借用該執行檔正常載入函式庫的行為。對防禦者來說，重點不只是主機上是否存在 OneDrive，而是合法 OneDrive 二進位檔是否從異常或可由使用者寫入的位置載入未預期的 DLL。

舊版的規避分析手法

C2Looper 會在執行期間使用 XOR 解密字串，報告指其重複使用一組 8 位元組金鑰；它也會透過 LoadLibrary 和 GetProcAddress 動態解析 Windows API。這些技巧可能降低單純靜態分析的可見度，因此端點偵測與回應（EDR）工具所提供的行為遙測更具價值。

新版：以 GitHub 作為命令與控制基礎設施

較新的 C2Looper 建置版本不再依賴傳統的專用 C2 伺服器，而是改用 GitHub 儲存庫處理任務、Beacon、命令結果，以及報告中提到的負載相關資料。

每部受感染主機都會獲分配一個專屬的儲存庫目錄。植入程式從該目錄讀取 cmd.json，依照檔案內容執行動作，再把結果寫入同一目錄中的 result.json。這讓操作者能以簡單的檔案流程下達命令和收集結果，而不必維護一個明顯的專用 C2 伺服器。

由於 GitHub 同時也是合法的開發與企業服務，單純封鎖網域的策略可能較難直接奏效。實務上，防禦團隊應調查平時不需要 GitHub 的端點是否出現週期性儲存庫或 API 存取，並區分每部主機的可疑 JSON 活動與正常的開發、CI/CD 工作流程。

C2Looper 轉向 GitHub，加上新版被報告具備更多負載執行能力，顯示這個惡意軟體仍在持續開發。

可能透過 ClickFix 社交工程投遞

ThreatLabz 以低至中等信心評估，C2Looper 可能透過多階段 ClickFix 感染鏈投遞。在這類攻擊中，受害者可能先看到假的驗證提示、瀏覽器錯誤、CAPTCHA 或系統修復訊息，之後被誘導把命令複製並貼到 PowerShell、Windows「執行」對話方塊或其他命令介面中。

這使得使用者互動本身成為重要的預防與偵測節點。網站或瀏覽器訊息不應要求使用者為了完成驗證或修復問題，把命令貼入 PowerShell、Terminal 或「執行」視窗。

相關報告也提到 Microsoft Teams 語音釣魚，以及濫用 Quick Assist 遠端協助工具的更廣泛社交工程活動。不過，現有證據並不能證明所有這類活動都投遞了 C2Looper；這些重疊之處應視為可能的背景脈絡，而非已確認的行動歸屬。

防禦團隊應監控哪些訊號？

組織不必試圖封鎖與惡意軟體相關的每一項工具或服務，而應優先掌握以下高價值行為：

• 高頻率明文 HTTP Beacon： 調查異常規律的 JSON POST 流量，尤其是類似 /api/beacon 和 /api/result/ 的請求，並與新出現或可疑程序交叉比對。
• 可疑 GitHub 活動： 尋找端點對 GitHub 儲存庫或 API 的週期性存取，特別是涉及每部主機專屬目錄及 cmd.json、result.json 的活動。不要無差別封鎖 GitHub，應先納入合法開發與自動化流程。
• OneDrive DLL 側載： 當合法 OneDrive 執行檔從異常的使用者設定檔路徑執行、從旁邊的可寫入目錄載入 DLL，或產生不尋常的子程序時發出警示。
• 命令執行與系統偵察： 利用 EDR 遙測識別可疑 PowerShell、cmd.exe、「執行」視窗活動、系統資訊蒐集、分階段下載，以及新出現二進位檔中的 Shell 執行行為。
• Rust 植入程式的綜合行為： 不要只依賴單一檔案特徵，而應把動態 API 解析、加密字串、網路輪詢與負載部署視為一組行為模式來分析。

預防工作的優先順序

技術控制必須與社交工程防禦並行。在符合業務需求的前提下，限制或嚴格管理由使用者啟動的 PowerShell、腳本主機、未簽署二進位檔，以及從使用者可寫入目錄執行的程式。應用程式允許清單也能進一步降低下載後的負載成功執行的機會。

安全團隊同時應教育員工與服務台人員：網站、CAPTCHA、瀏覽器錯誤頁面或未經要求的支援聯絡，絕不應要求使用者貼上命令。遠端支援工具則應採用核准流程、已驗證的支援管道、多因素驗證、工作階段記錄，並快速檢視異常連線。

網路分段、最小權限、多因素驗證、及時修補對外服務，以及經測試的離線或不可變備份，都能在 C2Looper 建立立足點後降低衝擊。若端點出現可疑 Beacon、Shell 活動或 DLL 側載，應立即隔離，同時保留端點日誌、網路紀錄，並在適當情況下保存記憶體資料供調查。

結論

C2Looper 的重要性，在於它已從較直接的 HTTP 後門，演變成能把 GitHub 儲存庫當作作業基礎設施的彈性植入程式。遠端 Shell、主機偵察、檔案下載與更新能力，使它成為勒索軟體相關入侵中可信的初始立足工具；但現有證據仍不足以支持確定性的威脅團體歸屬。

對組織而言，最有效的防禦組合是建立能抵抗 ClickFix 的使用者流程，並持續搜尋異常命令執行、OneDrive DLL 側載、高頻率 HTTP 輪詢，以及無法解釋的 GitHub 儲存庫活動。