「關機前套用更新」這支程式，
跑了 17,613 分鐘

從一個矛盾開始：沒事做，卻很忙

2026-09-15 那天，有人終於登入了一台沒有人在看的機器。uptime 回來的 load average 是 1.7，一顆核心整顆滿載；而這台機器該做的工作，其實在數個月前就停止產出了。最耗 CPU 的那支行程更奇怪：名字寫著「關機前套用更新」，累積 CPU 時間卻是 17,613 分鐘，換算超過十二天。一支只該在關機前跑幾秒的程式，不可能累積出這個數字。

順著這個矛盾追下去，一天之內挖出來的東西是：一支 XMRig 礦工、一支把檢視工具全部接管的 LD_PRELOAD rootkit、三個互為備援的開機自啟點，以及一個偽裝成系統帳號、掛著免密碼 sudo 的後門。入侵起點釘在 2025-09-24，也就是說它在這裡待了大約 356 天，沒有一天被打擾。整個過程全程唯讀：沒有殺行程、沒有掃毒、沒有刪檔，主機最後保持 stopped，等待砍掉重建。

這一篇只講偵測：那個矛盾怎麼一步步變成五條互相印證的線索，以及為什麼在 rootkit 面前，ps 的輸出不能當證據。錢包怎麼在礦工還活著的時候撈出來，見取證篇；離線掛載與四封檢舉信，見舉發篇。

它原本該做什麼：一支每 15 分鐘失敗一次的排程

要判斷「異常」，得先知道正常長什麼樣。這台 t2.small 唯一的業務是一支處理員工錄音的流程：每 15 分鐘由 crontab 觸發，讀試算表拿到錄音清單、下載原始檔、轉逐字稿、改寫、合成語音，再回寫試算表。

問題是這條流程早就死了。它依賴的服務帳戶在數月前被刪除，每一次執行都在 log 尾端固定拋出 Invalid JWT Signature，業務面沒有任何產出。沒有產出，卻持續滿載——這正是開頭那個矛盾的由來。

技術面的形狀很單純：nginx 反向代理擺在最前面，後面是一支 Flask 開發用 API 綁在 5000 埠，整條路徑對公網開放；執行 Flask 的是應用帳號 ubuntu，而 ubuntu 在 sudoers 裡有 NOPASSWD:ALL；呼叫 AI 服務的兩把 API key 以明文常數寫死在排程腳本裡。至於原本就有的防護，講白了只有一項幫上忙：這台沒有掛 IAM Role，也沒有存放雲端憑證，所以橫向擴散到雲端帳號的路徑被擋住。那是設定的結果，不是設計的結果——egress 沒有管制、沒有檔案完整性監控、log 沒有集中外送、閒置高載沒有告警，一樣都沒有。

把這台主機上「等於憑證」的東西全部攤開，會發現真正外洩的不只是 API key，還包括攻擊者自己新增的登入能力；而最後一列是他用來收錢的識別，擁有者是他，不是我們。

這張表裡沒有一把是被暴力破解的。攻擊者拿到的是「執行權限」，然後自己替自己發了一組憑證。

一個密碼設定日，釘住了 356 天的起點

時間軸的起點不是靠存取紀錄推出來的——入侵前的網站 log 被清掉了。真正釘住日期的是兩個互相獨立的東西：後門帳號的密碼設定日，以及離線磁碟上惡意檔案的時間戳。它們指向同一天。

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
   偵測 → 活體取證 → 錢包 → 離線鑑識 → 關機封存
   全程唯讀。

中間那一格橫跨將近一年，卻只有一行字可寫，因為那一年什麼事都沒發生——對我們而言。最後一格相反，一行字裡塞了一整天：分鐘級的取證順序在取證篇，離線掛載與舉發在舉發篇。

從公網到 root 只有兩步，剩下的時間都在收租

七個階段依 ATT&CK 順序排列，不是依時間：提權其實發生在持久化之前，而且前四格全部擠在 2025-09-24 那一天完成。之後將近一年的時間，全部落在最後一格。另外有兩個技術橫跨整條鏈——rootkit（T1014）與偽裝成系統檔名的行程（T1036.005）——它們不屬於任何單一階段，卻是他能撐 356 天的真正原因。

把這七格的 signal 欄連起來讀，會得到一份很便宜的偵測清單：監聽埠、preload 檔、新 systemd unit、對外連線、閒置高載。沒有一項需要買工具，而我們一項都沒在看。

五條線索：每一條都在說「ps 不可信」

鑑識不是等掃毒軟體給答案，而是看到一個不合理就追問為什麼。「沒事做卻很忙」是第一個該追的矛盾——它不一定是挖礦，合法報表也會把 CPU 吃滿，所以它不能定案，只能當起點。真正把它推到定案的，是後面五條線索彼此咬合的方式。

第一條：最耗 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？不合理。

第二條：換個角度，不看行程看連線

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。

第三條：檔案一被讀取就崩潰

想算 /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 抓不到礦工：它被藏起來了。

第四條：不只一個開機自啟點

/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，三重保險。

第五條：一個「像系統」的帳號，還免密碼 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               # ← 入侵時間錨點

五條之外：兩件只能推論、一件根本查不到

五條線索彼此咬合，把「疑似」推到了「確診」。但同一份材料也劃出了三條界線，它們比前面五條更值得寫清楚。

破口在應用層，原因在沒有人認領這台機器

表面上的結論是一支叫 log 的程序長期佔滿一顆核心，替攻擊者跑 RandomX 運算並向境外礦池提交 share。這是五條線索可以證明的部分。

再往下一層是技術原因，而它短得令人不安。那支開發用的 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。兩步，沒有第三步。

但技術原因只解釋了「怎麼進來」，解釋不了「為什麼可以待 356 天」。往上追到管理層，答案就不再是技術問題：業務在數月前就失敗，每 15 分鐘失敗一次，卻沒有人關掉這台、沒有人認領它，排程失敗也沒有人收信。這一層只能寫成推論，因為「沒有人負責」本來就不會留下紀錄。再往上一層的制度原因同樣是推論：缺少資產盤點與閒置資源回收機制，也缺少「這台主機該有多忙」的基線、egress 管制與 log 集中外送這三條共通防線。第二層決定了他怎麼進來，第三、第四層決定了他可以待多久。

訊號一直都在，只是每一條都沒有人負責

這 356 天裡，沒有一天是「沒有跡象」的。

最明顯的是閒置主機單核滿載將近一年，但沒有 CPU 高載告警，也沒有「這台該有多忙」的基線——沒有基線，滿載就只是一個沒人解讀的數字。第二條是排程每 15 分鐘失敗一次：業務死了，通知沒有寄給任何人，也就沒有人想到要把這台關掉。第三條是整年對境外 3333 埠的主動連線，出向流量既沒有人看，也沒有 VPC Flow Logs 可以事後回溯。

另外三條則是被攻擊者主動蓋掉的。ps、ls、top 的輸出被 rootkit 接管，而我們沒有任何執行期監控，等於只用原機工具看原機——拿嫌犯的證詞當證據。ld.so.preload、systemd unit、/etc/passwd 三個最該盯的位置都被改過，而沒有檔案完整性監控可以比對基準。最後，入侵前的存取紀錄被清得乾乾淨淨，因為 log 就留在被入侵的那台上：攻擊者拿到 root，也就等於拿到歷史的編輯權。

六條裡有五條，補起來只需要一條告警規則或一份基線，不需要買新工具。

那一天：全程唯讀，沒有動過任何一個檔案

處置的第一個決定不是「清掉它」，是「先不要碰」。

偵測本身花掉的是判讀時間而不是工具時間：從那個矛盾出發，依序走完負載與行程、對外連線、讀檔 segfault、三重自啟、可登入帳號五條線索，確認礦工、rootkit 與後門帳號同時存在。確認之後的第一個動作是隔離並保持 stopped，而不是殺行程或掃毒——在 rootkit 底下，殺行程只是讓它從你看不見的地方重來，掃毒則會把時間戳全部破壞掉。過程中曾經有一次重開機，@reboot 把礦工拉了回來；這既是失誤，也意外讓活體取證有了機會（這一段的判讀見取證篇）。

清除這一格，我們刻意留空。後門帳號與 sudoers 規則都沒有在原機刪除，整台以 stopped 狀態封存為證物，等待砍掉重建；腳本裡兩把 API key 則視為已外洩，必須撤銷並回供應商後台查同期用量。至於復原，這台的業務早已失效，沒有任何服務需要恢復，所以也沒有復原壓力——這是全案唯一一件輕鬆的事。

這件事被發現，靠的不是監控

先講難看的部分：沒有任何一套系統告訴我們這台出事了，是有人終於去看了一台沒人看的機器。業務數月前就失效，主機卻一直開著，沒有人回收也沒有人認領；單核滿載將近一年完全沒有告警，最便宜的那條防線根本沒設；兩把 API key 明文寫死在腳本裡，也是出事才盤點到。加上處置過程中那次重開機——揮發證據等於重來一次，運氣好才沒有全丟。

做得好的部分幾乎都發生在追查的那幾個小時裡：從矛盾一路追到底，沒有停在「重開機看看」；不信任 ps 與 top，改用 ss 與 /proc/PID/exe 交叉驗證，才認出礦工本體；找到一個自啟點之後繼續翻，把三處一次盤完；全程唯讀，時間戳與證據完整保留。把兩邊排在時間軸上看，結論很清楚：判讀能力救回了這件事，但判讀能力本來不該被用在第 356 天。

之後我們改了什麼

排序原則只有一條：先做不必改架構就能做完的，再做需要改設計的。

當天就能做完的有四件：主機維持隔離與 stopped，不重開機、不掃毒、不刪檔；撤銷腳本裡兩把 AI 服務 API key，並到供應商後台查同期用量；把開發用 API 從公網下架，Security Group 收斂，5000 埠不對外；拿本案 IOC（錢包、礦池 IP、/var/log/log、ld.so.preload、後門帳號、@reboot 排程）掃過同叢集其餘主機。

接下來一個月做的是把臨場判斷變成預設值：開發／內部 API 一律綁 127.0.0.1 或內網，對外只留有驗證的路徑；移除應用程式帳號的 NOPASSWD:ALL，必要時限定到單一指令；閒置主機加 CPU 高載告警（規則名我們取 idle-but-busy-e5t，翻告警一眼就對得上這篇），並對 3333、5555、9443、14444 等礦池埠告警；金鑰移出原始碼改用 Secrets Manager，並在 CI 跑 gitleaks；log 集中外送，讓攻擊者清不掉時間軸。

這一季以後要處理的是制度：建立資產盤點與閒置資源回收，沒在用的主機就關掉，每一台都要有負責人；egress 白名單管制，未知境外目的地預設拒絕；部署檔案完整性監控，盯 ld.so.preload、/etc/systemd/system、crontab、/etc/passwd；把「先採活體、再隔離、不重開機」寫進事件處置 SOP 並定期演練。

這些事要花多少錢，可以和這台機器替別人賺的錢放在一起看。下面這張表把雙方的帳並排：我們付的是雲端機時，他賺的是門羅幣。

這張表沒有一列是 proven，因為我們手上沒有這段期間的帳單明細；要把它升級成可證明，只要去 Cost Explorer 匯出這台在該期間的機時就行——這正是下一篇要講的，損害量化用機時，不是用礦池上的數字。而推估的比例已經夠清楚：他從這台賺到約 US$76，我們為此付出的雲端費用約 US$344，還不含工時。挖礦劫持的經濟學就長這樣：他的收益只是你成本的零頭，因為機時、磁碟、位址、電力、人力全部由你支付。

帶得走的五件事

站在他的角度，這是一筆極划算的生意。免驗證的 RCE 加上免密碼 sudo，從公網到 root 只要兩步，成本趨近於零；而一台業務失效、沒人登入的機器，是最穩定的礦工宿主——沒人會看 top，也沒人會重開機。行程改名、rootkit 藏檔、三重自啟、假系統帳號，每一層都只為了拉長「被發現」的時間，因為潛伏的每一天都是收益。worker 代號還暗示這只是他上百台肉雞的其中一台：你不是被鎖定的目標，你是被掃到的。

如果只想記十個詞，就記這十個。順序是照「讀完最該帶走」排的，不是照它們在文章裡出現的先後。

如果重來一次，前 60 分鐘該這樣排

遇到 root 級 rootkit，不要嘗試就地清毒：你無法確認清乾淨，因為你看到的系統狀態本身就不可信。真正該爭取的是前 60 分鐘的順序。

前十五分鐘只做一件事——確認主機還是不是 running，因為揮發證據存不存在完全取決於這一格。這段時間裡不重開機、不掃毒、不砍檔（@reboot 會讓礦工復活，掃毒會破壞時間戳），只用 ss -tnp 記下礦池連線與 PID，把 uptime、ps、ss 的輸出原樣存下來。

第二個十五分鐘可以開始止血，但止血不等於關機：改 Security Group 切斷對外連線（尤其 egress），先斷掉他的收益，主機仍然留在 running，趁礦工還活著採集行程記憶體與 Stratum 登入封包（做法見取證篇）。接下來的半小時才輪到磁碟：對 EBS 建立 snapshot，再離線唯讀掛到乾淨主機算雜湊（見舉發篇），同時把三個自啟點與 /etc/passwd、sudoers 一次盤完。

一小時之後才是慢工：輪替這台碰過的所有憑證並到各後台檢查異常用量；盤點同一把 pem、同一組密碼有沒有被其他主機共用，一併輪替並移除 DNS 記錄與健康檢查；terminate 時確認磁碟一併刪除、Elastic IP 釋放，從乾淨映像重建，切勿沿用舊 volume；最後補上閒置高載告警、礦池埠告警與 log 集中外送，讓下一次不必靠人眼發現。

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

上面那一小時需要的所有判斷，都可以先在自己手上的主機練一次。下面六步全部唯讀，十五分鐘內做得完。

本文由 AI 團隊協助研究與撰寫，經隱私與事實檢查後發布；證據等級依來源可信度標註。