那串 95 碼只活幾分鐘，
關機就永遠問不到了

一個 95 碼的字串，只在那幾分鐘裡看得到

確認那台排程機正在挖礦之後（過程見偵測篇），下一個問題是：誰在收錢？答案是一個 95 碼的字串，而它不存在於磁碟上的任何一個檔案裡——它只在礦工活著的時候，以字串的形式躺在行程記憶體與登入封包中。關機、terminate、甚至只是 kill 掉那個行程，它就永遠消失。

2026-09-15 這一天，那個字串從兩個互相獨立的地方被撈了出來：一邊是 /proc/PID/mem 的記憶體 dump，一邊是主動逼礦工重連後抓到的明文 Stratum 登入封包。兩邊完全一致，而且礦池當下正在派工。拿這個錢包去查兩個公開礦池的 miner API，結論就從「這台有挖礦行為」升級成「受害主機提供算力，對應帳戶因此領到了錢」——這是能不能送出去的分水嶺。

但升級的同時也要立刻踩煞車。礦池上顯示的金額是他整個活動、上百台受害機加總的結果，不是這一台的損失。這篇要講的除了採集順序，還有一條寫報告時最容易犯錯的界線：他賺了多少，查礦池；我們賠了多少，查帳單。兩本帳不能互相代替。

這一篇的「環境」不是架構圖，是一台還在 running 的主機

同一台受害排程機，採集時刻意維持在 running：礦工在跑、連線還在、記憶體還沒清空。這個狀態不是規劃來的——主機在處置過程中曾被重開機一次，@reboot 把礦工拉了起來，它又自己連回礦池，證據因此回來了一次。這是運氣，不是流程，下一次不該指望它。

直覺會想「趕快關機止血」或「重開機看看」，但錢包位址是礦工登入礦池時送出的參數，平時只以字串常駐在行程記憶體裡。主機一旦關機或終止，記憶體清空、連線中斷，這條證據就永久消失。取證的第一原則因此很反直覺：發現當下先在活體狀態採集，不要先關機。

網路面幫了我們一把：礦工以明文 Stratum 連 141.94.96.71 的 3333 埠，另有三個備援端點涵蓋 5555、9443、13333，而受害端出向流量完全沒有管制——所以他送得出去，我們也抓得到。工具面則全部是系統本來就有的東西：ss、dd、strings、tcpdump、curl，採集全程唯讀，沒有在原機寫入任何檔案。這份清單值得事前確認，因為缺哪一樣，事發當下就採不到對應的那一種證據。

這一篇處理的憑證也比較特別：前三列不是我們外洩的，是攻擊端用來領錢的識別。它一樣有服務、用途、存在形式，只是擁有者是他。

同一份清單放在前一篇是「我們漏掉什麼」，放在這裡是「他靠什麼收錢」。角色互換，格式一樣。

同一天之內，證據從揮發性走到服務端

這一天的每一格都發生在 2026-09-15，所以順序比時刻重要：前三格只要錯一步，後面全部拿不到。

1. 2026-09-15
   主機重開機，@reboot 把礦工拉起並重新連上礦池
   重開後 ss 仍見 ESTABLISHED 至 141.94.96.71:3333。
2. 2026-09-15
   由礦池連線反查礦工 PID，確認礦工仍在跑
   ss -tnp 對 3333 埠比對；rootkit 攔不到連線表。
3. 2026-09-15
   dump 行程記憶體，抽出錢包字串與 pass C4
   /proc/PID/mem 逐段讀出後 strings 過濾。
4. 2026-09-15
   逼礦工重連，擷取明文 Stratum login，取得一致的錢包與 XMRig 6.22.2
   tcpdump 先開，再切斷既有連線。
5. 2026-09-15
   查兩個公開礦池 miner API，取得已付金額與 40 筆撥款紀錄
   curl 存原始 JSON。
6. 2026-09-15
   以同一組 IOC 盤點同叢集其餘 8 台，7 台乾淨、1 台無法連線
   逐台看對外 ESTABLISHED 與 load。
7. 2026-09-15 之後
   主機保持 stopped，分析改走離線磁碟
   詳見 -03 篇。

這七格剛好是一條由快到慢的斜坡：記憶體以秒計、連線以分鐘計、磁碟撐到 terminate 為止，而礦池那本帳反而留得最久——它在第三方手上，我們刪不掉，他也改不掉。

同一條攻擊鏈，這次看的是「每一格還留下什麼可採的東西」

七個階段的事實與偵測篇相同，換個看法讀：把每一格的 signal 欄當成「這裡還採得到什麼」。

值得注意的是第六格：本案證據最集中的地方，恰好是攻擊者最不在意的地方。他不加密 Stratum，因為對他來說被看見也無所謂——除非你把看見的東西寄給礦池。

記憶體、封包、礦池，三個獨立來源對上同一個錢包

礦工要領獎勵，就一定得在登入礦池時報上自己的錢包位址與 worker 名稱。順著那條連往 3333 埠的連線往回追，就能挖出攻擊者的收款帳號。可用的途徑有四條，可靠度差很多。

本案走的是前兩條。第一條的起點不是 ps——在 rootkit 底下它不可信——而是從礦池連線反查 PID：

# 先由礦池連線反查礦工 PID（ss 較不易被 rootkit 攔截）
$ P=$(sudo ss -tnp | grep :3333 | grep -oE 'pid=[0-9]+' | cut -d= -f2)

# 逐段 dump 可讀記憶體 → 抽字串 → 比對礦池／錢包特徵
$ sudo dd if=/proc/$P/mem ... | strings -n5 | grep -aiE \
  "stratum|xmrig|randomx|pool\.|rig_id|\"user\"|4[0-9AB][0-9A-Za-z]{62,105}"

# 門羅幣主網位址 = 95 碼 Base58，以 4 開頭（整合式以 8 開頭）。

第二條需要一個違反直覺的動作：主動切斷他的連線。礦工不會抗議，它會立刻重連，而重連就得重送一次登入。

$ sudo tcpdump -i any -n -A 'tcp port 3333' -w /tmp/m.pcap &

# 切斷礦工目前連線，xmrig 會立刻重連並重送登入
$ sudo ss -K dst 141.94.96.71 dport = 3333

$ sudo tcpdump -r /tmp/m.pcap -A | grep -iE 'login|authorize|user'
# 典型 payload：method=login, params.login=<錢包>, params.pass=<worker>

兩條路徑同時採，撈到的是同一個字串：

// ① 礦工記憶體裡的 xmrig 設定 JSON
"user": "47qQHFXfGixiVEjwPNaVpQ8LJ6p8xNPHLjWKZC86us4WfhxacyXivPAGoThcgbwUaiAi4CjveFdsMLEYEUMhhrLA4nrCgHe",
"pass": "C4", "rig-id": null, "worker-id": null

// ② 逼重連後 tcpdump 抓到的 Stratum 登入封包（明文）
{"method":"login","params":{
  "login":"47qQHFXfGixiVEjwPNaVpQ8LJ6...LA4nrCgHe",
  "pass":"C4",
  "agent":"XMRig/6.22.2 (Linux x86_64) libuv/1.49.2 gcc/7.5.0"}}

// 礦池回派 job → 證實正在挖（algo rx/0 = RandomX = Monero）
{"method":"job","params":{"algo":"rx/0","height":3762742, ...}}

整理成一張對照，後面的檢舉信與 IOC 盤點都從這裡取材：

拿到錢包之後，不查區塊鏈，查礦池

門羅幣有隱私設計，區塊鏈瀏覽器查不到某個位址的餘額或入帳。但礦池會為每個錢包記帳：把錢包丟進礦池的公開 miner API，就能讀到算力、有效與無效 share、應付與已付金額，不需要帳號，也不需要付費。

$ curl https://www.supportxmr.com/api/miner/47qQHF…CgHe/stats
{"hash": 114019,                # 目前算力 114 KH/s
"totalHashes": 21241747108287, # 累計 21.24 TH
"validShares":104642508,"invalidShares":409,
"amtPaid": 18487033321205,     # 已付 18.487 XMR（原子單位 ÷ 1e12）
"amtDue": 7567687709}

$ curl https://api.c3pool.com/miner/47qQHF…CgHe/stats
{"hash": 33875,"lastShareAlgo":"rx/0",
"validShares":71699083,"invalidShares":51085,
"amtPaid": 3698865099345,      # 已付 3.699 XMR
"txnCount": 684}

$ curl https://www.supportxmr.com/api/miner/47qQHF…CgHe/payments
[{"pt":"pplns","ts":1789341566,"amount":73332000000,
"txnHash":"ed38df2f8ac78ce99382a8af5cce2884f00ca01020043bb1f664d375ec7e3f1c"}, …]

# SupportXMR 25 筆 + C3Pool 15 筆 = 40 筆已完成付款，每筆帶鏈上 txnHash。

兩個礦池回來的四個數字，決定了這份報告能寫到什麼程度：

三個容易寫錯的地方，先在這裡擋掉

第四個數字（148 KH/s）看起來只是旁註，其實是整篇最重要的一個煞車。

第四個來源：其他七台什麼都沒有

錢包拿到之後最有價值的用途不是追金流（門羅幣追不到），是當成 IOC 去掃別台。拿同一組識別——錢包、礦池 IP、/var/log/log、ld.so.preload、後門帳號、@reboot 排程——掃過同叢集其餘 8 台，判定依據是「主動外連礦池是挖礦的必要條件」。

把這些材料排成一條線，就是完整的利益鏈：未授權存取（對外免驗證 RCE）→ 植入現成礦工、rootkit 與後門帳號 → 消耗受害者的 CPU、電力與雲端資源 → 執行 RandomX 運算提交 share 到自架代理，再 fallback 到公開礦池 → 以錢包加 worker 代號作為收益識別 → 累積並領取報酬。對照國際雲端挖礦判例的採證邏輯，這條線分成三層舉證：犯罪目的由記憶體與封包雙證支撐，最強；受害者實際損害要查自家帳單，權威值在 Cost Explorer；犯罪所得則是礦池的已付金額，引用時必須標明那是整個活動的總額。

為什麼證據差一點就沒了，原因不在技術

這一篇的根因追的不是「為什麼被入侵」（那在偵測篇），是「為什麼證據差一點就沒了」。

表面原因可以證明：錢包與 worker 代號只以字串存在礦工的行程記憶體與明文登入封包裡，關機或 terminate 即永久消失。技術原因同樣可證：礦池走明文協定、出向流量未管制，所以他送得出去、我們也抓得到——反過來說，如果他改走 TLS，封包這條路當場失效，只剩記憶體那條。

再往上一層就不是技術了，只能寫成推論：發現當下沒有既定的採證順序，主機先被重開機一次，揮發證據是靠攻擊者自己的 @reboot 才回來的，不是流程保住的。最上面那層同樣是推論：缺事件處置 SOP 與取證工具基線，也缺「損害量化以帳單機時為準」的舉證規範，所以我方損失到現在仍然停在推估——他的收益有第三方紀錄，我們的損失沒有。

線索不只在主機上，礦池那本帳一直是公開的

這一年裡，能發現它的機會不只在那台機器裡。

主機面的三條都指向同一個缺口：整年對境外 3333 埠的連線沒有 egress 管制也沒有流量紀錄；礦池埠從來沒有被告警過，而這是成本最接近零的一條規則——閒置主機連這些埠幾乎等同確診；行程建立與 sudo 使用沒有留下可查的紀錄，事後只能從程式碼與磁碟反推。

另外兩條更值得記住，因為它們不是技術問題。第一，帳單看起來完全正常：挖礦不吃頻寬，機時本來就每天照付，費用曲線一點都不會動——缺的不是帳單，是「帳單抓不到挖礦」這個認知。第二，礦池的公開 API 一直查得到這個活動，免費、免帳號，只是沒有人把自家 IOC 拿去對一次。

先採活體，再談隔離

這一天做對的關鍵只有一個：順序。

偵測階段並不新鮮，是前一篇五條線索的延續；差別在於確認之後沒有伸手去關機，而是先用 ss 反查礦工 PID，確認礦池連線仍是 ESTABLISHED、礦工仍在運算。接著在 running 狀態下 dump 行程記憶體抽出錢包，再開 tcpdump 並切斷既有連線逼礦工重送登入——這兩個動作合起來只花幾分鐘，卻決定了整案有沒有證據。取得錢包之後才讓主機保持 stopped，並以同一組 IOC 盤完同叢集 8 台。那次意外的重開機必須再說一次：它不是計畫的一部分。

清除這一格同樣刻意留白：沒有在原機清除任何東西，改採「讓他的基礎設施變貴」——錢包與礦池端點送交礦池與機房（見舉發篇），腳本內兩把 AI 服務 API key 視為已外洩並撤銷，是否已撤銷未確認。復原則沒有壓力，因為業務早已失效；唯一還欠的是損害量化，那份 Cost Explorer 匯出至今尚未完成。

做對的都跟順序有關，做錯的也是

做對的五件事，每一件都是「忍住沒做某事」的結果：在拿到錢包之前沒有關機、沒有 terminate；記憶體與封包兩條獨立路徑同時採，兩邊對上才下結論；礦池 API 存的是原始 JSON 而不是截圖，第三方可以自己重跑；克制住沒有把礦池總額寫成本機損失——這是全案最重要的一次自我約束；當天就用同一組 IOC 盤完同叢集，把範圍畫出來。

做錯的也同樣關於順序與準備。過程中重開機了一次，揮發證據是靠攻擊者的 @reboot 才回來的；取證工具箱事前沒有清點，tcpdump、strings、gdb 在不在，是到現場才知道；沒有當場匯出機時，導致我方損失至今仍是推估；同叢集有 1 台無法連線，狀態至今未確認，範圍只能畫到那裡；第二支礦工的收益沒有可查的公開 API，那條變現管道完全算不出來。一句話總結：證據守住了，但守住的方式裡有一段是運氣。

讓下一次不必靠運氣

當天就能補的有三件：把本案 IOC（錢包、worker 代號、四個礦池端點、礦工的 agent 字串）加進盤點與偵測清單，檔名就叫 ioc-wallet-sweep-d3k.csv，下次掃叢集直接餵它；到 Cost Explorer 匯出那台過去 12 個月的機時與實付金額，把損失從推估變成可證明；以及最便宜的那一件——在動任何手腳之前，先確認可疑主機是不是還在 running，還在就先別關。

一個月內要補的是準備工作：把 tcpdump、strings、gdb、sha256sum 納入 AMI 基線事前預裝；寫一頁「發現挖礦的前 30 分鐘」SOP，順序是查狀態、記連線、採記憶體、抓封包、才隔離；對礦池埠與未知境外 egress 設告警；把礦池與威脅情資查詢納入標準調查流程，因為服務端證據免費，證據力卻最強。

這一季以後要處理的是制度：log 集中外送與流量紀錄，讓連線與行程都有第三方可比對的來源；導入執行期監控，補上行程建立與提權的稽核；訂一條損害量化規範——我方損失一律以帳單機時為準，礦池數字只用於描述犯罪所得；並定期演練活體取證，把順序練成反射動作。

最後一條規範不是形式主義。同一件事其實有兩本帳：礦池那本記著他領走多少，雲端帳單那本記著我們付了多少。把它們並排，才看得出這門生意的形狀。

這張表最難堪的地方是：整件事唯一有第三方可驗證資料的金額，是攻擊者的收益（合計 US$11,302.88）；我們自己的損失反而還停在推估。受害方要把損失講到能上法庭，缺的不是律師，是一次 Cost Explorer 匯出。

帶得走的五件事

從他的角度看，worker 代號只是一種記帳方式：標記這是第幾批肉雞。他用自架 proxy 聚合算力，公開礦池只看得到一個 worker、一個錢包，追查者因此很難估算他手上有多少台；備援礦池寫了四個，主池被封還能繼續領；門羅幣的隱私設計讓金流追不到，他要的就是「拿得到、追不到」。而他也知道，你大概率會先重開機或直接 terminate——那樣錢包就永遠消失了。他賭的不是你查不到，是你動作太快。

如果重來一次，證據要照這個順序收

本案的揮發證據是靠攻擊者自己的 @reboot 救回來的。下一次不該把希望放在他身上。

前十五分鐘先查一件事：主機狀態是不是 running。這一格決定了記憶體與連線還在不在，答案是 running 就什麼都先別動——不 terminate、不重開機、不 kill 礦工行程——只用 ss -tnp 把礦池連線、目的 IP 與 PID 原樣存檔。

第二個十五分鐘採兩個獨立來源：dump /proc/PID/mem 抽字串，找 95 碼 Base58 的錢包與設定 JSON；先開 tcpdump 再切斷既有連線，逼礦工重送登入。兩邊字串對上才算數，對不上就繼續找，不要先下結論。第三個十五到三十分鐘轉向服務端與橫向：拿錢包查公開礦池 API，存原始 JSON、SHA256 與 UTC 時間；用同一組 IOC 掃同叢集每一台把範圍畫出來；最後對磁碟建立 snapshot，把靜態分析交給離線那條路（見舉發篇）。

一小時之後才是收尾：匯出機時把我方損失升級成可證明；錢包送礦池檢舉、礦池 IP 送機房 abuse；報告裡把「他的收益」與「我方損失」分成兩張表寫，永遠不要合併。

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

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