同一顆磁碟換一台機器讀，
多出了第二種幣

同一顆磁碟，換一台機器讀，多出一種幣

在原機上，sha256sum 連一個檔案的雜湊都算不出來——一讀就 core dump。把同一顆磁碟做成 snapshot、還原成新 volume、唯讀掛到另一台乾淨主機，十分鐘內四個惡意檔的雜湊全部到手。差別不在工具，在於那台機器會不會載入攻擊者的那支 .so。

離線讀出來的東西有兩樣是原機上永遠看不到的：rootkit 本體 /usr/local/lib/sshdd.so 的路徑與雜湊，以及一支偽裝成 bash、正在挖 Ravencoin 的第二礦工。原本以為是一條變現管道，實際上是兩條，跨兩個機房、兩種幣。最後四個雜湊被固定成 SHA256SUMS.txt，證物封存，四封檢舉信寄出，其中兩封當天就有回音。

這一篇的順序是保全在前、舉發在後，因為兩者的前提是同一件事：磁碟要先沒被動過。而最常見的證據破壞不是攻擊者做的，是善意的第一反應——重開機、掃毒、砍檔、直接 terminate。前面兩篇的偵測與活體取證見偵測篇與取證篇。

兩台機器，中間隔著一個 snapshot

這一篇的環境有兩台機器。一台是受害排程機，保持 stopped，磁碟裡有 rootkit、兩支礦工與後門帳號；另一台是乾淨的分析主機，它沒有 /etc/ld.so.preload，所以不會載入攻擊者那支函式庫。中間的橋是 EBS snapshot。攻擊端則橫跨兩個國家：主礦池代理在 OVH（法國），第二支礦工連的 kawpow 礦池在 Hetzner（德國）。

直覺會想「趕快關機止血」或「重開機看看」，但對取證而言，stopped 才是理想狀態：磁碟一致、礦工沒在跑。重開機反而會做兩件壞事——@reboot 讓礦工復活繼續替攻擊者挖，同時洗掉記憶體與連線這些揮發證據。正確順序是發現當下先採活體，之後讓它保持 stopped，靜態分析一律改走 snapshot。

之所以要分階段，是因為證據不只一種，而三類證據消失的方式完全不同。

第三類就是這一篇的主場。而離線掛載多挖出一條收款管道之後，這次入侵的完整形狀才看得出來：兩種幣的收款識別、攻擊者替自己留的登入能力、還有讓前兩者得以隱形的那支函式庫。

最後一列是寫給自己的規矩：舉發時給的是可驗證的識別，不是可用的憑證。

兩天之內，從一顆磁碟走到四封信

前一天做的是活體採集（見取證篇），這一段接在它後面。日期只有兩天，但每一格都改變了證據的狀態。

1. 2026-09-15
   原機上 sha256sum 與 cat 讀取受保護檔案即 segfault，判定為執行期 rootkit
   原機指令輸出。
2. 2026-09-15
   對 EBS 建立 snapshot 封存為證物，主機保持 stopped，不 terminate
   唯讀處置原則，原碟不寫入。
3. 2026-09-15
   snapshot 還原成新 volume，以 ro,noexec,nodev 掛到乾淨分析主機
   分析全程在複製品上進行。
4. 2026-09-15
   四個惡意 binary 的 SHA256 到手，ld.so.preload 指向 /usr/local/lib/sshdd.so
   離線讀取不載入 rootkit。
5. 2026-09-15
   發現第二支礦工 /var/tmp/bash，在挖 Ravencoin
   原機被 rootkit 隱藏，離線才現形。
6. 2026-09-15 → 09-16
   整理 Incident Evidence Package 並寄出四封檢舉信
   SHA256SUMS.txt 與 UTC 時間一併附上。
7. 2026-09-16
   SupportXMR 回覆已 denylist、OVH 受理 abuse ticket、C3Pool 索取補件後已補；Hetzner 已寄、尚無回覆
   三方回信留存；Hetzner 只有寄出紀錄。
8. 待提交
   TWCERT/CC 通報與刑事舉發
   需完整證據包；狀態見下方舉發表。

潛伏花了 356 天，保全與舉發只花兩天。這個對比不是效率，是順序：前面兩天之所以能這麼快，是因為沒有在第一天做錯任何一個不可逆的動作。

同一條攻擊鏈，這次看的是「哪一格只有離線讀得到」

七個階段的事實與偵測篇相同。差別在於，rootkit 在場時，有三格在原機上看到的是假的；換一台機器讀同一顆磁碟，它們才說實話。

把第三、第四、第六格連起來看，會得到一條很省事的原則：凡是「只有原機說了算」的證據，一律改到別台去讀。

離線一掛，rootkit 全現形

本案的 ld.so.preload 是執行期機制：只要在那台機器上載入它，任何工具讀被保護的檔案都會 segfault，連雜湊都算不出來。解法不是更強的工具，是換一台不會載入它的機器，把那顆磁碟當成單純的資料碟來讀。

# EBS snapshot → 新 volume → attach 到乾淨機 /dev/xvdf，再：
$ sudo mount -o ro,noexec,nodev /dev/xvdf1 /mnt/evid

$ sudo sha256sum /mnt/evid/var/log/log /mnt/evid/usr/bin/log   # ← 這次算得出來
$ sudo cat /mnt/evid/etc/ld.so.preload                           # ← 看到 rootkit 路徑
$ sudo zcat /mnt/evid/var/log/nginx/*access.log* | grep -i py_exec  # ← 找入侵向量

$ sudo umount /mnt/evid
# binary 雜湊可上 VirusTotal 關聯同源活動；原碟一律不寫入。

十分鐘後，證物清單上多了四行：

166b2551b810e2747d68a47a8431fb1dab24ed54cef47eb9d3a53c46e4291896  /var/log/log            # XMRig 礦工 9.4MB
75711c01…1ef6b88                                                   /usr/bin/log            # rootkit helper / launcher
acb2e78d…9207e3c                                                   /usr/local/lib/sshdd.so # ← LD_PRELOAD rootkit 本體（hook readdir 藏檔）
e71cffd0ef65adef9d73cc1c5f83ed7d8af1d2c9fad48018c568bb5e08a888df  /var/tmp/bash           # ← 第二礦工（Go，exec -a bash 偽裝）

看不到，是因為用被入侵的系統看它自己

表面原因可以證明：第二支礦工與 rootkit 本體在原機上完全隱形，連雜湊都算不出來。技術原因同樣可證，而且只有一句話——LD_PRELOAD 是執行期機制，hook 了 readdir 等呼叫，所以只要在同一台載入它，任何工具的輸出都經過它的過濾。你不是看不清楚，你是在看一份被編輯過的世界。

往上一層就只能寫成推論了：面對可疑主機的直覺反應是重開機、掃毒、砍檔，而這三個動作都會先破壞證據再說。最上層的制度原因同樣是推論：缺證物保全 SOP 與雲端層的保全設定基線（磁碟是否隨執行個體一起刪除、稽核軌跡是否跨區域、有沒有鑑識專用角色），所以「要不要留證據」變成了當下的臨場判斷——而臨場判斷在半夜三點永遠會輸給直覺。

第二條管道藏了 356 天

門羅幣那條至少還留下高 CPU 與外連；Ravencoin 這條連跡象都被蓋掉了。

它整年沒有出現在任何一份行程清單裡，因為 rootkit hook 了 readdir，用 ls 與 ps 看它就是看不到——缺的是一種不依賴原機工具的檢視方式。它的檔名叫 /var/tmp/bash，正常到不會有人多看一眼，而 /var/tmp 下出現可執行檔本身就該被問一句；缺的是檔案完整性監控與可疑路徑基線。它走 9443 埠連德國機房，而礦池埠告警清單即使有人設，通常也只涵蓋 3333、5555，漏掉第二種幣常用的埠。

還有兩條與主機無關。/etc/ld.so.preload 被新增這件事沒有任何人知道，而這個檔案在乾淨系統上通常根本不存在，是最容易寫的一條監控規則。最後一條是雲端層的：沒有跨區域的稽核軌跡，快照被誰刪、何時刪都查不到——刪一個 snapshot 只要一個 API 呼叫，證據保全從來不只是主機的事。

唯讀、封存、寄出去

這一段是本案的主場，而真正決定結果的是第二個動作：先 snapshot，再談其他。

偵測這一格很快就結束了：原機讀取受保護檔案即 segfault，判定為執行期 rootkit，同時確認原機上的一切檢視結果都不可信，只能改走離線路線。接著是圍堵，做法是「什麼都不做」——主機保持 stopped，不重開機、不掃毒、不刪檔、不 terminate；對磁碟建立 snapshot 並封存為證物，之後所有分析一律在 snapshot 複製出的 volume 上以 ro,noexec,nodev 唯讀進行。

清除這一格刻意留白，而且是有意識的取捨：後門帳號與 rootkit 都保留在原機當證據，反正這台無論如何都要砍掉重建，證物完整優先於機器乾淨。替代做法是讓攻擊者的基礎設施變貴——四封檢舉信寄給 SupportXMR、OVH、C3Pool、Hetzner，其中 C3Pool 索取補件後已補；分析用的 volume 用畢即刪，鑑識用的 IAM 權限盤點完立即收回。復原則尚未執行：原機重建與憑證輪替還沒做，TWCERT/CC 通報待提交，而這台的業務早已失效，沒有服務恢復壓力。

支撐這一切的是四條監管鏈規矩，每一條都是為了回答日後別人會問的問題：

• 雜湊固定：每個原始證物算 SHA256（SHA256SUMS.txt），記下 UTC 擷取時間。日後要證明「沒被改過」，靠的就是它。
• 唯讀掛載：分析都在複製品上做，原始 snapshot 當證物封存，絕不寫回原碟；分析用 volume 用畢即刪。
• 可獨立重驗：礦池 JSON 這類服務端證據，第三方可以自行重跑 API 比對，證據力最強——截圖不能驗完整性，務必存原始資料。
• 權限用畢即收：鑑識用的 IAM 權限在盤點完成後立即收回，並留稽核。

反過來說，會毀掉這條鏈的動作也只有五個：重開機（揮發證據全失，礦工復活繼續挖）、在原機掃毒或砍檔（看到的一切本來就不可信，還會破壞時間戳）、沒先 snapshot 就 terminate（磁碟證據永久消失）、只截圖不存原始資料（無法驗完整性）、以及寫回或修改原碟（鏈一斷，證據等於沒有）。

把散落的證據變成能交出去的東西

給執法或檢方看的不是一句「伺服器疑似被駭」，而是一份結構化的文件：事件摘要、每一筆都標了可證明或推論的時間軸、IOC、附 SHA256 的證物清單、三層舉證、損害量化、缺口、後續動作。本案證據包裡裝的是：活體記憶體字串與 pcap 節錄、兩個礦池的 API 原始 JSON 與 40 筆撥款紀錄、EBS snapshot、離線算出的四個 binary 雜湊、叢集盤點結果，以及 SHA256SUMS.txt。

私人查不到攻擊者本人，身分揭露必須由檢警憑證據包向機房與交易所發傳票。但礦池與機房可以直接處理「基礎設施」，而且回應速度比想像中快。

一封有效的檢舉信不長，也不需要文采。它只要讓對方能自己驗證：

Subject: [Abuse] Cryptojacking mining proxy at 141.94.96.71 (Monero) - INC-xxxx

Reporting organization : <受害方／資產擁有者>
Incident ref           : INC-xxxx
Victim host            : <雲端>, <區域>
Compromise window      : 2025-09-24 through 2026-09-15 (UTC+8)
Nature                 : Unauthorized root access; XMRig cryptominer + LD_PRELOAD rootkit + backdoor account.

The malware (XMRig 6.22.2) maintained an ESTABLISHED connection to your IP as its
primary mining pool / proxy:
  Pool/Proxy IP : 141.94.96.71 (ports 3333, 443, 5555, 7777)
  Protocol      : Stratum (rx/0 / RandomX, Monero)
  Attacker XMR wallet (login): 47qQHF…CgHe
  Worker/pass   : C4

Evidence (captured 2026-09-15):
  - Live process memory dump AND tcpdump of the Stratum "login" containing the wallet above.
  - Malware SHA256: /var/log/log (XMRig) 166b2551…4291896

Request: Please investigate and take down the mining proxy hosted at 141.94.96.71.
Full evidence package (pcap extract, memory strings, SHA256SUMS) available on request.

C3Pool 回信要求補充伺服器資訊、擁有權證明、取證方式、雜湊與時間戳。補件時把不能提供的項目明確標成無法提供，憑證與密碼雜湊一律遮蔽，附上 SHA256SUMS.txt。對方要的是可驗證，不是可怕。

這一篇的重點就是流程，而這次流程守住了

做得好的部分可以一口氣列完，而且每一件都是「沒有做某事」：沒有在原機掃毒、砍檔或 terminate，磁碟證據完整；先 snapshot 再分析，原碟全程不寫入；唯讀掛載加雜湊加 UTC 時間，證物固定的三件事一次做完；存的是原始資料不是截圖；主動對外檢舉並完成補件；鑑識用的權限盤點完就收回，分析用 volume 用畢即刪。

該改的則集中在兩端。前端是前一天那次重開機，揮發證據差點全失（見取證篇）；後端是還沒結清的帳：證物 snapshot 的容量與保存期沒有明確記錄，連保全成本都只能用牌價估；第二支礦工的收益沒有可查的公開 API，那條變現管道完全算不出金額；TWCERT/CC 通報至今仍是待提交，刑事那條路還沒走；原機重建與憑證輪替尚未執行。流程守住了證據，但沒有守住結案。

把「要不要留證據」從臨場判斷變成預設值

當天就能做完的有三件：主機維持 stopped，snapshot 打上 evidence-hold=e2m 這類標籤、標記為證物並設定不自動刪除；關掉受害主機與同類主機的 DeleteOnTermination，讓一次誤按不會消滅磁碟證據；把四個惡意檔雜湊與兩個錢包整理成 IOC 清單，送出檢舉並上公開情資比對。

一個月內要補的是規則：寫一份證物保全 SOP（先活體、再 snapshot、唯讀掛載、SHA256SUMS、UTC 時間）；開多區域 CloudTrail，讓 snapshot 被誰刪、何時刪查得到；檔案完整性監控盯 ld.so.preload、/usr/local/lib、/var/tmp 與 /etc/passwd；礦池埠告警清單補上第二種幣常用的 9443、13333，不要只顧 3333。

這一季以後要做的是讓下次不必臨場發揮：備妥證據包範本與 abuse 信樣板，事發時只要填空；建立鑑識專用 IAM 角色，預設關閉、用畢即收、全程留稽核；每季演練一次離線鑑識，從 snapshot、掛載、算雜湊到封存全程計時；把通報路徑（TWCERT/CC、刑法第 358～360 條）寫進事件處置流程，不要等到出事才查。

這些事看起來很多，但它們的共同特徵是便宜。下面把保全與舉發這一輪的帳攤開來看，就知道「沒做保全」從來不是預算問題。

這張表要花錢的沒有一列是 proven，因為最關鍵的幾筆仍是牌價推估；但結構已經很清楚：雲端保全成本 US$0.13，人力成本 US$859。 一個 snapshot 的錢不到一杯咖啡，卻是「有證據」與「只有一句伺服器疑似被駭」之間的全部差距。

帶得走的五件事

他的基礎設施是照「被拆掉一塊也還能跑」設計的：主池自架在一個機房、備援放公開礦池，被封一個還有三個；第二支礦工挖不同的幣、連不同國家的機房，門羅幣那條被切了，另一條照樣運作。他也不怕你發現——rootkit 只是用來拖時間的，真正讓他麻煩的是你把錢包交給礦池、把代理 IP 交給機房，因為那會動到他所有肉雞，不只你這一台。

如果重來一次，保全的順序長這樣

這一案的證據守住了，但守住的方式裡有一段是運氣。把運氣換成流程，順序是這樣。

前十五分鐘先採活體：記憶體與封包，主機留在 running（做法見取證篇）。這段時間裡不重開機、不掃毒、不砍檔，在原機看到的一切都先當成不可信；順手確認磁碟的 DeleteOnTermination 是不是 true，避免有人一按就消滅證據。接下來十五分鐘轉成靜態保全：對磁碟建立 snapshot 並標記為證物、設定不自動刪除，然後把主機改為 stopped 而不是 terminate——磁碟一致、礦工沒在跑，這才是理想狀態。

第一個小時的最後半小時才開始分析：snapshot 還原成新 volume，唯讀掛到乾淨主機，算四個惡意檔的雜湊、讀 ld.so.preload、翻 nginx log 找進入點，並當場產出 SHA256SUMS.txt 與 UTC 時間把證物固定。

一小時之後是慢工：把散落的東西組成證據包；寄檢舉信給礦池與機房，補件時把不能提供的項目明確標示；向 TWCERT/CC 通報，必要時走刑法第 358～360 條；最後刪掉分析用 volume、收回鑑識權限，原機從乾淨映像重建，不沿用舊 volume。

這六步今天就可以在自己的環境走一次，全部唯讀，十五分鐘內做得完。

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