一台沒人看的排程機， 替別人挖了 356 天的礦

先知道「正常」長什麼樣

在判斷「異常」之前，得先知道這台機器原本該做什麼。這台排程機唯一的業務，是一支處理員工錄音的流程：每 15 分鐘由 crontab 觸發，讀試算表拿到錄音清單、下載原始檔、用 Whisper 轉逐字稿、用 GPT 改寫、用 TTS 合成語音、再回寫試算表。

問題是，這條流程其實已經死了。它依賴的服務帳戶早在數月前被刪除，每次執行都在 log 尾端固定拋出 Invalid JWT Signature。業務面沒有任何產出，CPU 卻長期滿載。

五條線索，逐步逼出真相

鑑識不是靠掃毒軟體給答案，而是每看到一個不合理，就追問「為什麼」。以下是實際的判讀順序與現場證據。

線索 1：CPU 滿載，但最耗資源的行程「說謊」

USER   PID  %CPU %MEM     TIME  COMMAND
root   404  25.9  8.3 17613:25  /usr/bin/python3 .../unattended-upgrade-shutdown --wait-for-signal
mysql  562   0.3 18.2   218:45  /usr/sbin/mysqld

# 一支「關機前套用更新」的程式燒了 17,613 分鐘 CPU？不合理。

線索 2：一條連往境外機房 3333 埠的連線

換個角度：不看行程，看連線。

State  Local Address:Port   Peer Address:Port      Process
ESTAB  10.x.x.x:36708       141.94.96.71:3333      users:(("log",pid=479))

# 141.94.96.71 → OVH SAS / 法國。port 3333 = 礦池 Stratum 常用埠。
# 發起程序名叫 "log"，執行檔卻是 /var/log/log。

線索 3：檔案一被讀取就 Segmentation fault

想算 /var/log/log 的雜湊去比對惡意程式庫，結果一碰就 core dump。連 /etc/ld.so.preload 都讀不了。

$ sudo sha256sum /var/log/log
Segmentation fault      /var/log/log (core dumped)

$ sudo cat /etc/ld.so.preload
Segmentation fault      /etc/ld.so.preload (core dumped)

# 一般檔案讀取不會 segfault。這是 LD_PRELOAD rootkit 的防偵察反應，
# 也解釋了為何 ps 抓不到礦工：它被藏起來了。

線索 4：三重開機自啟

透過 /proc/479/exe（rootkit 攔不到的路徑）確認礦工本體就是 9.4 MB 的 /var/log/log。再往持久化機制找：

$ cat /etc/systemd/system/log.service
[Unit]
Description=log Plugin Service
[Service]
ExecStart=/usr/bin/log -sshd
Restart=always
User=root

$ sudo crontab -l
@reboot /var/log/log > /dev/null 2>&1 & disown

# 偽裝成「log 外掛服務」+ root 的 @reboot，加上 ld.so.preload，三重保險。

線索 5：一個免密碼 sudo 的「系統帳號」

$ grep -vE 'nologin|false' /etc/passwd
root:x:0:0:root:/root:/bin/bash
ubuntu:x:1000:1000:Ubuntu:/home/ubuntu:/bin/bash
systemd:x:1001:1001::/home/systemd:/bin/bash      # ← 假的系統帳號

$ sudo grep -r '' /etc/sudoers*
systemd ALL=(ALL) NOPASSWD:ALL

$ sudo chage -l systemd | head -1
Last password change : Sep 23, 2025               # ← 入侵時間錨點

這次外洩了什麼

這台機器上沒有雲端憑證，所以「外洩」的東西跟一般想像的不一樣：被拿走的是登入能力本身，加上兩把寫死在腳本裡的 API key。

時間軸

1. 2025-09-23
   後門帳號 systemd 建立
   密碼設定日與惡意檔案時間戳一致。
2. 2025-09-24 05:30
   植入 XMRig、rootkit sshdd.so、第二礦工
   離線磁碟分析取得檔案時間戳。
3. 2025-09-24 00:00 之前
   入侵前的網站存取 log 全數消失
   access.log 最早一筆停在 9/24 00:00；攻擊者清過 log。
4. 2025-09-24 → 2026-09-15
   潛伏約 356 天，單核持續替攻擊者挖礦
   業務失效後無人登入，所以無人發現。
5. 2026-09-15
   偵測 → 活體取證 → 錢包 → 離線鑑識 → 關機封存
   全程唯讀。

356 天的帳

這台機器的業務早就死了，帳單一天也沒停。把雙方的帳擺在一起看：我們付的是雲端機時，他賺的是門羅幣。

可證明的金額：US$0。 這張表沒有一列是 proven，因為我們手上沒有這段期間的帳單明細——要把它升級成可證明，只要去 Cost Explorer 匯出這台在該期間的 BoxUsage 機時就行。這正是下一篇要講的：損害量化用機時，不是用礦池上的數字。

而推估的部分已經很清楚：他從這台賺到約 US$76，我們為此付出的雲端費用約 US$344（不含工時）。挖礦劫持的經濟學就長這樣：他的收益只是你成本的零頭，因為機時、磁碟、位址、電力、人力全部由你支付。

為什麼會被攻進來

主機上一支開發用的 Flask 對外開了一個端點，把使用者傳入的參數直接拼進 shell 執行，沒有任何驗證或白名單：

# 使用者可控的 param_n、param_data 直接進了指令字串
cmd = "python3 /var/www/app/" + param_n + ".py " + param_data
subprocess.run(cmd, shell=True)

整條路徑短得驚人：公網 → nginx :80 → Flask :5000 → 指令注入 → 以 ubuntu 執行 → ubuntu 有 NOPASSWD:ALL → root。

攻擊者 vs 防守者

已經中了怎麼辦

遇到 root 級 rootkit，不要嘗試就地清毒。你無法確認清乾淨，因為你看到的系統狀態本身就不可信。

1. 隔離：改 Security Group 切斷對外連線（尤其 egress），但先別關機。關機會失去記憶體裡的跡證。
2. 存證：趁礦工活著採集記憶體與封包（下一篇），再對 EBS 建立 snapshot。
3. 輪替金鑰：撤銷這台碰過的所有憑證：API key、SSH key、共用密碼。到對應後台檢查是否有異常用量。
4. 盤點連動：同一把 SSH pem、同一組密碼是否被其他主機共用？一併輪替。移除 DNS 記錄與健康檢查。
5. 銷毀重建：terminate 並確認 EBS 一併刪除、Elastic IP 釋放；從乾淨映像重建，切勿沿用舊 volume。

就算移除了已知的礦工與後門，也無法證明沒有殘留的第二層植入。唯一能回到已知乾淨狀態的方法，就是砍掉重建。

重點學習

今天就可以來試試