1. 總覽與 Threat actor 模型
SoopSocks 軟體套件聲稱提供 SOCKS5 代理服務,以及可設定 Webhook 的回報機制。然而,其更深層的功能揭示了它本質上是一個後門代理(backdoor proxy),能夠路由任意流量、執行主機偵察,並在被入侵的機器上保持持續性。該套件版本不斷演變,從純 Python 版本到已編譯的 Go (Golang) 可執行檔,但保留了相同的架構模組 [1] 。
開源軟體庫中惡意軟體的氾濫對軟體供應鏈安全構成了重大威脅。本報告針對 SoopSocks 軟體套件進行深入的技術探討,該軟體包已被確認具有後門代理伺服器功能,重點關注其內部架構、外掛模組、持續性策略,以及網路行為。本分析是基於對其 Python 實作和已編譯可執行檔版本(如先前研究 [1] 中所觀察到的)進行反向工程而得。
1. 總覽與 Threat actor 模型
從 Threat actor 模型的角度來看,該專案作為一個出站隧道運行:攻擊者可以將此套件注入目標系統,將其啟用為服務或排程任務,並透過代理通道滲透資料或執行進一步的橫向存取。
2. 模組化架構與內部元件
無論是 Python 還是 Go 版本,SoopSocks 的實作都是模組化的。主要的幾項功能模組包含:
- SERVER / 代理模組 — 實作 SOCKS5 協定 (CONNECT, UDP ASSOCIATE, NO AUTH) 並處理 TCP/UDP forwarding。
- CLI 模組 (指令 / 持續性控制器) — 解析參數、選擇運行模式(服務、排程任務、備援)、處理防火牆規則和權限提升邏輯。
- DISCORD / webhook 模組 — 定期向 webhook URL 發送 JSON 嵌入訊息,回報主機網路狀態。
- EGRESS / 偵察模組 — 偵測內部和外部 IP 位址、使用 STUN 偵測 NAT 行為,並監控出站的變化。
- AUTOSTART / 持續性模組 — 建立 Windows 服務或排程任務,以在開機或登入時重新啟動。
- FIREWALL 模組 — 新增或確保防火牆規則,以允許代理通訊埠 (預設 1080) 上的入站流量。
- SERVICE_WINDOWS 模組 (在 Python 中) — 透過 pywin32 將代理運行邏輯包裝成 Windows 服務。
在已編譯的 Go 版本中,可執行檔內的目錄結構通常模擬如下:
main ├── socks5/internal/diag ├── socks5/internal/install ├── socks5/internal/proxy ├── socks5/internal/webhook └── (other supporting modules)
這與最初的 Python 模組細項分類相符,表示邏輯模組的直接移植 [1] 。每個模組中的內部程式碼在這兩個版本中大致相似。
2.1 代理 / SOCKS5 伺服器實作
SoopSocks 的核心在於實作一個支援 TCP 和 UDP 流程、網域解析、IPv4/IPv6,以及最少錯誤處理的 SOCKS5 代理。下面是根據反向分析改編的簡化 pseudocode:
- def handle_socks5(client_sock):
- version = client_sock.recv(1)
- if version != 0x05:
- client_sock.close()
- return
- n_methods = client_sock.recv(1)[0]
- methods = client_sock.recv(n_methods)
- # no authentication (0x00) accepted:
- client_sock.send(b"\x05\x00")
- # client request
- ver, cmd, _, addr_type = client_sock.recv(4)
- if addr_type == 0x01: # IPv4
- addr = client_sock.recv(4)
- elif addr_type == 0x03: # domain
- length = client_sock.recv(1)[0]
- addr = client_sock.recv(length)
- port = int.from_bytes(client_sock.recv(2), 'big')
- if cmd == 0x01: # CONNECT
- remote = socket.connect((addr, port))
- client_sock.send(b"\x05\x00\x00\x01" + local_ip + local_port)
- forward_loop(client_sock, remote)
- elif cmd == 0x03: # UDP ASSOCIATE
- # handle UDP relay logic...
- pass
- else:
- # reply command not supported
- client_sock.send(b"\x05\x07\x00\x01" + b"\x00"*6)
- client_sock.close()
實作上有意地省略了認證,使代理對任何入站流量保持開放。在 Go 版本中,此邏輯是透過 goroutines 移植以處理協同性。缺乏嚴格的錯誤處理和日誌記錄是故意的 — 為了最大限度地減少偵測的 Fingerprint。
2.2 持續性邏輯與權限提升
CLI 模組負責確保代理程式可以在重新開機時保持持續性,並在需要時提升權限。該邏輯可以歸納為一個決策樹:
在 Python 版本中,如果 `pywin32` 服務安裝失敗,它會退而求其次,建立一個名為 `SoopSocksAuto` 的排程任務,在開機或使用者登入時觸發,執行一個隱藏指令來啟動代理程式。防火牆規則也透過 PowerShell 指令插入,例如:
New-NetFirewallRule -DisplayName 'SoopSocks TCP 1080' -Direction Inbound -Action Allow -Protocol TCP -LocalPort 1080 -Profile Any
New-NetFirewallRule -DisplayName 'SoopSocks UDP 1080' -Direction Inbound -Action Allow -Protocol UDP -LocalPort 1080 -Profile Any
這些指令會為 1080 上的 TCP 和 UDP 開放 Inbound port,以允許代理連線
[1]
。
2.3 偵察與回報模組
Egress / 偵察模組收集內部和外部 IP 位址以及 NAT 行為。所使用的技術包括:
- 查詢 HTTP API (例如 `api.ipify.org`、`ifconfig.me`) 以取得 Public IP
- 檢查本地路由表(local route tables)以取得內部 IP
- 使用 STUN 協定 (例如 `stun.l.google.com:19302`) 來偵測 NAT 對映行為
接著,Discord/webhook 模組會定期發出 HTTPS POST 請求,其中包含帶有此資訊的 JSON Payload。一個典型的 Payload 嵌入可能看起來像:
{ "embeds": [ { "title": "SOCKS5.Egress.Update", "fields": [ { "name": "Hostname", "value": "<hostname>" }, { "name": "LAN.Public.IPv4", "value": "<external ip="">" }, { "name": "LAN.Local.IPv4", "value": "<internal ip="">" }, ... ], "timestamp": "2025-09-28T12:32:06Z" } ] }因為 webhook URL 是 hardcoded(或可設定的),它提供了一個隱密且使用合法 HTTPS 流量的 Command & Control (C2) 通道,使得偵測不那麼容易。
3. 版本演進與部署途徑
SoopSocks 的開發歷史顯示了從 Python 轉向已編譯 Go 二進位檔的轉變,目的是為了規避偵測並使部署更為穩健。版本進程包括:
- v0.1.x: 基本 Python SOCKS5 伺服器
- v0.2.0 ~ v0.2.4: 新增了透過 Python 的 Windows 服務支援,引入了 `_autorun.exe` 可執行檔
- v0.2.5 ~ v0.2.6: 新增了 VBScript 安裝程式路徑 (`_autorun.vbs`),它會抓取一個可攜式的 Python 並進行引導啟動
- v0.2.7: 精簡為僅限 Go 的 EXE 版本,具有相同的模組化行為 [1]
- 一個已編譯的可執行檔 (`_autorun.exe`),它會將自己安裝為一個帶有隱藏執行的服務
- 一個 VBScript 程式碼 (`_autorun.vbs`),它會下載一個可攜式的 Python,執行 `pip install soopsocks`,並靜默執行 Python 代理程式
- 透過 `pip install soopsocks pywin32` 的直接 Python 軟體套件,接著觸發相同的持續性與代理模組
4. 偵測與防禦策略
從防禦者的角度來看,偵測必須同時針對網路和主機訊號:
4.1 基於網路的偵測
- 監控埠號 1080 (TCP/UDP) 上的 SOCKS5 協定流量
- 檢查流向非典型 webhook 端點或與嵌入格式一致的重複模式的 HTTPS POSTs
- 偵測 STUN 流量,或出站連線到 STUN 伺服器 (例如 埠號 19302)
- 觀察與內部主機行為相關聯的流向已知 IP 偵測服務 (例如 `api.ipify.org`) 的 DNS 或 HTTP 流量
4.2 基於主機的偵測
- 掃描名為 `_autorun.exe`、`_autorun.vbs`、`pp_bootstrap.ps1`、`run_soopsocks.cmd` 的檔案
- 列舉 Windows 服務中的 `SoopSocksSvc` 以及排程任務中的 `SoopSocksAuto`
- 檢查防火牆規則中名為 `SoopSocks TCP 1080` 或 `SoopSocks UDP 1080` 的項目
- 偵測隱藏的 PowerShell 執行、跳過的設定檔載入、靜默錯誤,以及 UAC 權限提升嘗試
4.3 緩解與修復
一個妥善的事件回應包括:
- 隔離受影響的主機
- 封鎖出站 webhook 網域 / IP,並封鎖 `install.soop.space` 網域
- 移除服務、排程任務、防火牆規則,並刪除代理程式檔案
- 清除可攜式 Python 安裝和登錄檔 Artifact
- 部署具有偵測規則 (YARA、行為) 的端點偵測與回應 (Endpoint Detection & Response, EDR),以應對已知的指標 (例如 webhook 模式、VBScript 引導行為) [1]
5. 限制、規避與未來工作
雖然 SoopSocks 的方法相對直接,但在未來的強化和規避方面仍有以下空間:
- 更動態地嵌入 webhook URL 或使用網域生成演算法 (Domain Generation Algorithms, DGAs) 來避免靜態偵測
- 實作可選的代理認證或透過 DNS/ICMP 進行隧道傳輸以增加隱密性
- 使用加密設定儲存和運行時加密來避免靜態掃描
- 新增點對點備援或多階段通訊,以避免依賴單一 webhook 端點
- 多型態或混淆版本的引導載入器 (VBScript/PowerShell) 以規避簽章偵測
6. 結論
SoopSocks 軟體套件呈現了一個引人注目的案例研究,說明了一個看似良性的代理服務如何演變成一個功能齊全的後門代理程式。其模組化架構、跨版本的一致性,以及對隱密性的關注 (例如 靜默呼叫、隱藏的權限提升、最少的日誌記錄) 顯示了明確的秘密行動意圖。上述的技術解剖突顯了防禦者可以針對的關鍵模組和行為。
防禦者應採用結合網路遙測、主機 Artifact 檢查和行為分析的分層偵測策略。未來的 Threat actor 可能會在此範例的基礎上,增加動態行為和規避戰術。