跳到內容
ExpTech StudioExpTech
主控台

09/18 基礎設施遭入侵事件完整說明

RCA閱讀時間約 37 分鐘
YuYu1015
YuYu1015
Full-Stack Engineer (全端工程師)
嚴重程度：嚴重狀態：修補完成，11/15 複查無再入侵
問題描述
承載服務的四台網路設備遭到入侵，攻擊者取得了完整管理權限
根本原因
設備的系統版本落後於已公開的安全性修補，而且管理介面直接暴露在網際網路上。
最早入侵痕跡
2026/09/02
發現日
2026/09/18
影響範圍
承載 DPIP 服務的四台網路設備

先講結論

Section titled “先講結論”

2026/09/18 上午，DPIP 服務出現異常。排查後我們發現，承載服務的四台網路設備遭到入侵，攻擊者取得了完整管理權限。

進一步取證後確認，最早的入侵痕跡可以回溯到 2026/09/02 —— 也就是說，攻擊者在我們的設備上待了約 16 天，我們才發現。

這是我們的疏失。設備的系統版本落後於已公開的安全性修補，而且管理介面直接暴露在網際網路上。這兩件事都是我們自己該做而沒做好的。

截至 2026/09/20，四台設備的修補與清除已全部完成並經實測驗證。 期間我們還捕捉到兩次攻擊者嘗試重新利用同一漏洞、被新版本擋下的紀錄 —— 這是修補確實有效的直接證據。

之後到 2026/11/15 為止的複查都沒有再入侵跡象，見後續追蹤。

這篇文章把我們查到的東西完整寫出來，包含每一項結論是怎麼驗證的，以及還沒查完的部分。

對你的影響

Section titled “對你的影響”

這是你最需要知道的部分，所以放在最前面。

你的資料

Section titled “你的資料”
項目 狀態 依據
DPIP 蒐集的使用者相關資料 本即為去識別化資料，經確認未受影響 ——
經過這些設備的網路流量 被側錄的可能性已基本排除 見下方「關於流量是否被側錄」
設備上的憑證、VPN 金鑰、私鑰 一律視為已洩漏 → 已全部輪換完成 9 把 WireGuard 私鑰、4 組 CA、5 個 .ovpn、4 把 SSH host key
內網服務的認證資訊 無法排除曾被讀取 → 已輪換或加上認證 見還沒查完的部分

被入侵的四台是網路層設備（路由器 / 負載平衡），它們負責把封包送到正確的地方，本身不存放應用程式資料。攻擊者拿到的是「網路設備的管理權」，不是「使用者資料庫」。

關於流量是否被側錄

Section titled “關於流量是否被側錄”

攻擊者確實具備側錄能力（植入的排程帶有 sniff 權限，且他們處在所有流量的路徑上）。但 RouterOS 上所有「實際有效」的側錄手法都必須修改設定，而設定變更會留下紀錄。

我們逐一檢查了全部 9 種手法在取證當下的實際狀態：

側錄手法 需改設定 取證時的實際狀態
/tool sniffer 設過濾器後啟動 需要 22 個過濾欄位全部為空（出廠預設）
/tool sniffer 串流外送至遠端 需要 streaming-enabled=no、目標為預設值
/tool sniffer 存檔 需要 檔名欄位空白；設備上無任何 .pcap / .cap 檔
/tool sniffer 放大緩衝區 需要 100KiB（出廠預設，未動）
防火牆 action=sniff-tzsp 鏡像至遠端收集器 需要 0 條規則
交換晶片埠鏡像 需要 來源 / 目標皆為 none（預設）
NetFlow 外送 需要 四台皆 enabled=no
容器內跑 tcpdump 需要 container 套件四台皆未安裝
/tool sniffer quick（純執行期） 不需要 無法從設定排除 —— 見下方

決定性的一點是：我們能證明「修改設定一定會留紀錄」。

攻擊者自己留下了 32 筆 log action changed 紀錄 —— 那正是他們破壞日誌所用的 /system logging action set 操作。這證明了 /system X set 這類操作確實會被記錄。既然如此，/tool sniffer set … 也會被記錄。

而入侵期間（09/15 起）四台合計 47 筆此類操作紀錄，分類如下：

操作 筆數 性質
修改日誌輸出設定 32 反取證
修改日誌規則 8 反取證
新增使用者 4 建立後門帳號
從排程移除腳本 4 惡意程式的重複投放設計
與側錄相關 0 ——

紀錄緩衝區的覆蓋範圍也經過確認（最舊紀錄早於入侵日，因此沒有被捲掉）：

節點 紀錄筆數 最舊紀錄日期 早於入侵日 09/15？
core-tnn1 101 2026-06-30 是
node-tnn1 40 2026-07-02 是
node-tnn2 22 2026-09-03 是
lb-khh1 19 2026-09-02 是

唯一無法從設定排除的是 /tool sniffer quick（純執行期操作，不留設定紀錄）。但在未經修改的預設設定下，它的緩衝上限是 100KiB、單封包上限 2048 bytes，大約只能保存 50 到 100 個封包，而且沒有過濾器 —— 抓到的是隨機流量，不是針對特定服務的憑證。要有效擷取憑證就必須設過濾器或放大緩衝，那就回到「必須改設定」，而那些紀錄是 0 筆。

結論：流量側錄基本排除。 這不是「我們覺得應該沒事」，是逐項查證後的結果。

我們仍然無法排除的部分

Section titled “我們仍然無法排除的部分”

服務可用性

Section titled “服務可用性”

  1. 服務出現異常

  2. 取證完成

  3. 開始清理，服務陸續恢復

你需要做什麼

Section titled “你需要做什麼”

發生了什麼事

Section titled “發生了什麼事”

一句話版本

Section titled “一句話版本”

MikroTik 這家廠商的路由器作業系統在 2026 年 9 月被公開了一組安全漏洞，攻擊者可以不需要密碼就取得路由器的最高管理權限。我們的四台設備版本太舊、沒有修補，而且管理介面對全世界開放，所以被打進來了。

稍微詳細一點

Section titled “稍微詳細一點”

2026/09/02，資安社群開始觀測到有人在網路上大規模掃描並攻擊 MikroTik 路由器（這波攻擊被稱為 MikroTrick）。 2026/09/03，MikroTik 釋出修補版本。 2026/09/05，波蘭國家電腦緊急應變小組（CERT Polska）正式公告，當時全球有 122,500 台 MikroTik 設備的管理介面暴露在公網上。 2026/09/14，統計顯示全球約 260 萬台 MikroTik 設備處於曝險狀態。

我們的四台設備，系統版本的發布日期全部早於 09/03 的修補釋出日。 從攻擊活動開始的那天起，這四台就一直是可以被攻破的狀態，而我們完全不知道。

攻擊者在 09/02 就進來了。

修補在攻擊者部署主要惡意程式的 12 天前就已經可以取得。 這一點我們必須講清楚 —— 這不是零時差攻擊，是我們沒有及時更新。

為什麼會被打進來

Section titled “為什麼會被打進來”

漏洞本身

Section titled “漏洞本身”

這次公開的其實是六個 CVE，不是新聞上常提到的那兩個：

CVE 攻擊面 修補版本
CVE-2026-67276 SSH 認證（RSA exponent 未驗證） 7.23.4 / 7.24.2
CVE-2026-67277 btest / bandwidth-test 6.49.21 / 7.23.4 / 7.24.2
CVE-2026-67278 TLS + SSH host-key 7.23.6 / 7.24.3
CVE-2026-67279 SSH rekey 6.49.21 / 7.23.4 / 7.24.2
CVE-2026-67281 WebFig /jsproxy 7.23.4 / 7.24.2
CVE-2026-86060 SSH 登入提權 6.49.21 / 7.23.4 / 7.24.2

其中 CVE-2026-67277 與 CVE-2026-86060 已於 2026/09/10 被美國 CISA 列入 KEV（已知遭利用漏洞清單） —— 代表這不是理論風險，是確定有人在用它攻擊。

攻擊者怎麼進來的

Section titled “攻擊者怎麼進來的”

真正的接管鏈是兩個漏洞串起來的，全程走 SSH，不需要任何帳號密碼：

[1] CVE-2026-67276
    RouterOS 在比對 SSH 公鑰時，只比對 key type 與 modulus，「不比對 exponent」。
    攻擊者送出一把 exponent = 1 的公鑰，就能在沒有私鑰的情況下偽造出有效簽章
    → 認證通過。
              ↓
[2] CVE-2026-86060
    用一個「開頭是禁用字元」的使用者名稱（例如 -2）登入，
    RouterOS 的登入處理程式沒有正確處理參數分隔符，
    導致這個連線可以改寫自己的權限設定
    → 提權成功。
              ↓
[3] 未認證的攻擊者取得完整 administrator 權限

我們自己的問題

Section titled “我們自己的問題”

漏洞是廠商的，但設備沒更新、管理介面對外開放，是我們的責任。

節點 事發版本 版本發布日 落後
core-tnn1 7.23.1 2026-06-02 約 3 個月
node-tnn2 7.22.2 2026-04-22 約 5 個月
node-tnn1 7.22.1 2026-03-23 約 6 個月
lb-khh1 7.22.1 2026-03-23 約 6 個月

而且四台的 SSH 管理介面都設定成允許任何來源 IP 連入。

時間軸

Section titled “時間軸”

所有時間為台灣時間（UTC+8）。node-tnn1 的系統時鐘當時慢了 6 小時 45 分（NTP 未同步、期間未重開機，偏差固定），該台的時間都已換算成實際的台灣時間。

外部事件

  1. CERT Polska 觀測到針對 RouterOS 的攻擊開始

  2. MikroTik 釋出修補版本 7.24.2 / 7.23.4

  3. CERT Polska 正式公告，全球 122,500 台設備曝險

  4. CISA 將兩個 CVE 列入 KEV

  5. 全球曝險設備統計約 260 萬台

我們的設備上發生的事

  1. 後門帳號 ops 登入 —— 最早的入侵痕跡core-tnn1

  2. 後門帳號 ops 登入node-tnn1

  3. 兩台各殘存的唯一一筆日誌：possible SYN flooding on tcp port 22（相距 16 分鐘，同一波 SSH 攻擊）lb-khh1 / core-tnn1

  4. 後門帳號 routeradmini 登入，11 秒後開始修改日誌設定lb-khh1

  5. 同一個後門帳號做同樣的事core-tnn1

  6. 植入「每日自動重建後門帳號」的排程lb-khh1

  7. 後門帳號 system 登入兩台，相隔 38 秒 → 自動化橫向移動core-tnn1 / node-tnn2

  8. 植入 C2 遠端控制程式，每 3 分鐘對外回連node-tnn1

  9. 四台在 4 小時內被依序套用相同的日誌破壞設定四台

  10. 日誌壓制動作被反覆執行 20 次以上四台

  11. 新增後門帳號 gabor76core-tnn1

  12. 新增後門帳號 mark65node-tnn1

  13. 攻擊者建立兩條管理員權限的 SSH 連線core-tnn1

  14. 新增後門帳號 martin1node-tnn1

我們的應變

  1. 服務異常，開始排查

  2. 確認遭植入惡意腳本

  3. 開始完整取證（四台，全程唯讀）

  4. 取證完畢，SHA256 與保管鏈建立

  5. 開始清理，服務陸續恢復

  6. 四台逐台升級至 7.24.4（16:00–16:06），各台升級後立即輪換管理密碼

  7. 四台建立磁碟日誌規則

  8. RouterBOOT 韌體升級的重開機

  9. 修補約 4 小時後，兩次 -2 再入侵嘗試被新版本擋下（見下節）

  10. VPN PKI 重建（09-18）、9 把 WireGuard 私鑰輪換（站對站 09-18、roadwarrior 09-19）

  11. 四台 SSH 管理介面設來源白名單

  12. 記憶體日誌上限拉到 65535、每週自動更新排程上線

  13. 擴大範圍稽核 → 發現資料平台的認證缺口並修補（見下節）

  14. 移除 46 個受污染／調查產物檔案，建立乾淨基準備份

  15. 重新入侵比對：四台皆無新入侵跡象

  16. 第二次健康檢查：四台無再入侵跡象

  17. 第三次健康檢查：四台無再入侵跡象

    （見後續追蹤）

修補有效的直接證據

Section titled “修補有效的直接證據”

這是我們認為最值得分享的一段。

升級完成約 4 小時後，攻擊者回來了兩次，而設備日誌把過程完整記下來了：

時間 節點 來源 IP 來源歸屬 使用者名稱 結果
2026-09-18 20:20:44 node-tnn2 46.101.236.154 DigitalOcean -2 失敗
2026-09-18 20:55:16 lb-khh1 159.89.228.250 DigitalOcean -2 失敗

使用者名稱 -2 正是 CVE-2026-86060 的引數注入特徵。同一個攻擊手法，在修補後的版本上失敗了。

攻擊者被完全擋在門外的驗證

Section titled “攻擊者被完全擋在門外的驗證”

09/19 凌晨我們把四台的 SSH 管理介面限制為來源白名單。效果可以直接量化 —— 以下是外部來源的 SSH 登入失敗次數逐日統計：

節點 09-18 09-19 09-20 最後一次外部嘗試
core-tnn1 140 12 0 2026-09-19 00:30:06
node-tnn1 1667 120 0 2026-09-19 01:01:34
node-tnn2 145 14 0 2026-09-19 01:41:57
lb-khh1 166 24 0 2026-09-19 00:37:28

白名單的套用時間是 09-19 00:35 到 00:45。外部嘗試在那之後隨即歸零。截至 11/15，近兩個月一次都沒有 —— 期間所有登入失敗紀錄的來源，都是我們自己的站台。

這不是「我們相信設定生效了」，是從外部實測的結果。

技術細節：攻擊者做了什麼

Section titled “技術細節：攻擊者做了什麼”

攻擊者不是只留一條後路，而是在不同設備上用了四種完全不同的手法。這也是為什麼「升級 + 改密碼」完全不夠。

1. 後門帳號（四台都有）

Section titled “1. 後門帳號（四台都有）”

四台合計 25 個帳號條目、12 個不重複的帳號名稱，全部是最高權限、全部不限制來源 IP。

帳號 core-tnn1 node-tnn2 node-tnn1 lb-khh1 備註
ops CERT Polska 公告的 MikroTrick 特徵帳號
saryn 攻擊者取證當下使用中
SystemMikrotik 偽裝成系統帳號
routeradmin 偽裝成管理帳號
routeradmini 上一個的 typo 變體
system 偽裝成系統帳號
operator
test
gabor76 人名型
mark65 / martin1 人名型
zkadmin 刪掉會自己長回來

ops 這個帳號是本案最強的關聯證據。 它是 CERT Polska 公告中點名的 MikroTrick 特徵帳號，而它在我們兩台設備上的最後登入時間是 2026-09-02 —— 正好就是全球攻擊活動開始的那一天。

攻擊者的互動來源 IP 是 203.74.122.229（取證當下 saryn 的兩條活躍連線來源）。

2. C2 遠端控制程式（node-tnn1）

Section titled “2. C2 遠端控制程式（node-tnn1）”

這是最嚴重的一項。攻擊者在其中一台植入了一支會主動對外回連、接收遠端指令的程式。

  • 連線目標： http://85.137.54.178:8080（荷蘭，VSYS-AMS-COLO）
  • 頻率： 每 3 分鐘一次
  • 植入時間： 2026-09-15 08:04:59（設備時鐘顯示 01:19:52，該台時鐘慢 6 小時 45 分）
  • 截至取證的執行次數： 1536 次

它做兩件事：

  1. 把設備資訊（架構、系統版本、硬體型號、設備名稱）回報給對方

  2. 去對方的伺服器抓一個指令檔回來執行，執行完立刻把檔案刪掉

也就是說，攻擊者可以隨時在這台設備上執行任何指令，而且不留痕跡。

這支程式的原始碼第一行是它自己寫的註解：

# RouterOS foothold — beacon CNC every 3 minutes WITH identity
# Installed via /import after /tool fetch

「foothold（立足點）」、「beacon CNC（向指揮控制伺服器回連）」—— 它自己說明了自己是什麼，我們不需要任何外部情報就能判定它是惡意程式。

三個設計細節值得說明：

  • start-time=startup —— 重開機會自動復活。所以「重開機就好了」是錯的。
  • 安裝程式具幂等性 —— 它執行時會先刪掉舊的再裝一次，代表它被設計成可以重複投放。只要對方還連得到設備，刪掉它沒有意義。
  • 靜默失敗 —— 整段程式碼包在錯誤忽略的區塊裡，出錯不會留下任何記錄。

我們刻意沒有去連線或掃描那個 C2 伺服器。觸碰攻擊者的基礎設施可能驚動對方、讓他清除痕跡或加速破壞，這部分交由司法機關與 CERT 處理。

完整 IoC 清單（供其他防守方比對）：

# C2
85.137.54.178:8080          # 本案實際觀測（荷蘭 VSYS-AMS-COLO），未見於公開清單
82.192.72.4                 # 公開 IoC，本案未出現
103.102.31.18               # 公開 IoC，本案未出現


# 攻擊者互動來源
203.74.122.229              # 取證當下的活躍管理連線


# 再入侵嘗試來源（修補後，皆失敗）
46.101.236.154              # DigitalOcean
159.89.228.250              # DigitalOcean


# 後門帳號名稱
ops saryn SystemMikrotik routeradmin routeradmini
system operator test gabor76 mark65 martin1 zkadmin


# 持久化的檔案／排程／腳本名稱
boat_ros                    # C2 排程與腳本（node-tnn1）
daily-maint                 # 帳號復活排程（lb-khh1）
logrotate                   # 帳號復活腳本（lb-khh1）
ros-task.rsc                # C2 下載的指令檔（執行後即刪）


# SSH 登入特徵
使用者名稱以 "-" 開頭（例如 -2）   # CVE-2026-86060 引數注入

3. 會自己長回來的後門帳號（lb-khh1）

Section titled “3. 會自己長回來的後門帳號（lb-khh1）”

另一台設備上沒有 C2，但有一套更陰險的東西：

排程「daily-maint」（每日維護）  每天 03:00 執行
      ↓
腳本「logrotate」（日誌輪替）
      ↓
如果後門帳號 zkadmin 不存在 → 用固定密碼重新建立為最高權限

你刪掉那個帳號，隔天凌晨三點它就回來了。

最值得警惕的是偽裝手法：daily-maint（每日維護）和 logrotate（日誌輪替）這兩個名字，看起來比我們自己寫的排程還像正常維運工作。

唯一能區分的是建立者欄位 —— 同一台設備上所有合法的排程（NTP 校時、MAC 重置、DDNS 更新、韌體升級、WAN 備援檢查）全部標示為 admin，只有這兩個標示為 0（代表非由使用者互動建立）。

看建立者，不要看名字。

4. 注入的 SSH 金鑰（lb-khh1）

Section titled “4. 注入的 SSH 金鑰（lb-khh1）”

這是四種手法裡最隱蔽的一種：攻擊者在合法的 admin 帳號上，掛了一把自己的 SSH 金鑰（RSA 3072，指紋 SHA256:zJ8ypOH1lW4DtgPrO+V1qmZUJprP8WzxlJGFYIFWZt8=）。

為什麼難發現：

  1. 它不是一個新帳號 —— 稽核帳號清單看不到

  2. 它不是一個新排程或腳本 —— 稽核持久化機制看不到

  3. 它掛在合法帳號上

  4. 金鑰登入不受暴力破解防護限制（金鑰認證不計失敗次數）

它還有一個副作用，而這個副作用其實就是我們最初遇到的怪事 —— 正確的管理密碼在這台設備上突然失效了。

原因是 RouterOS 的一項設定語義：「這個使用者如果已經註冊了金鑰，就拒絕密碼登入」。攻擊者掛上金鑰之後，我們自己的密碼就被擋在門外了。

我們一開始以為是憑證記錯了。「管理密碼突然失效」本身就是一個入侵指標，這是我們學到的一課。

這台最後是改用 RouterOS 的 REST API 完成取證的，取得 119/121 個端點、238 個證據檔。

此外這台的 SOCKS 代理伺服器也被開啟且沒有任何來源限制，並建立了一個代理帳號（r7n2k）—— 這是把設備變成攻擊他人的中繼站的典型手法。同一個帳號也出現在 core-tnn1，而另外兩台的 SOCKS 帳號清單是空的，這個差異本身就證明它是攻擊者留下的。

5. 反取證：日誌被系統性破壞（四台一致）

Section titled “5. 反取證：日誌被系統性破壞（四台一致）”

這是讓我們最難查的一件事。

四台設備的日誌設定都被改成了無法保留任何紀錄的狀態：

  • 記憶體日誌上限從原廠預設的 1000 筆改成 1 筆
  • 涵蓋「登入事件、帳號建立、設定變更」的日誌類別全部停用
  • 沒有設定外部 syslog 伺服器 → 設備之外沒有任何副本

結果是四台各只剩下 1 筆日誌。

節點 殘存的唯一一筆
lb-khh1 09-10 16:27:07 SSH 埠遭大量連線攻擊
core-tnn1 09-10 16:43:18 SSH 埠遭大量連線攻擊
node-tnn2 09-14 13:35:56 DHCP 警告
node-tnn1 09-09 17:34:34 排程移除紀錄（設備時鐘；實際為 09-10 00:19）

前兩筆很有意思 —— 兩台在 16 分鐘內都記錄到對 SSH 埠的大量連線攻擊。而 SSH 正是這次漏洞的攻擊面，2026-09-10 也正是 CISA 把這些漏洞列入 KEV 的同一天。

這是唯一殘存、時間點與攻擊活動吻合的日誌。其餘全部被抹掉了。

6. 但有一樣東西活下來了

Section titled “6. 但有一樣東西活下來了”

RouterOS 有一份「設定變更歷史」，記錄誰在什麼時候改了什麼。它只存在記憶體裡，重開機就永久消失。

攻擊者沒有動它（也動不了）。而它清楚地畫出了入侵分界線：

  • 合法的維運變更全部標示 admin
  • 惡意變更全部標示 0 或後門帳號名稱
  • 它直接記錄了 user gabor76 added、user mark65 added、user martin1 added
  • 它顯示日誌壓制被反覆執行 20 次以上，橫跨 9 天

如果我們當初「先重開機再說」，這份東西會永久消失，而且無法補救。

7. 第二條獨立的證據鏈

Section titled “7. 第二條獨立的證據鏈”

設備上的每日自動備份沒有加密，可以直接解析出每個時間點的帳號清單。這構成一條不依賴記憶體紀錄的獨立證據鏈。

最重要的發現是找到了入侵前的乾淨基準線：

節點 基準線備份時間 當時的帳號
core-tnn1 2026-06-13 只有 admin
node-tnn1 2026-04-05 只有 admin

這是「那些後門帳號全部不是我們自己建的」的客觀證據，不需要依賴任何人的記憶：這兩台上出現的 11 種後門帳號名稱，在基準線中都不存在；第 12 種 zkadmin 只出現在 lb-khh1，由攻擊者植入的排程自動建立。

兩條證據鏈交叉比對，完全沒有矛盾。

我們怎麼驗證這些結論

Section titled “我們怎麼驗證這些結論”

處置一旦執行，記憶體裡的證據和設備上的檔案就永久消失，沒有第二次機會。所以在動手之前，我們做了一輪對抗式驗證 —— 主動嘗試推翻自己已經寫下的結論，只留下經得起檢驗的部分。

我們用的標準是：這份取證要能直接交給執法單位。 每一項結論都要有獨立的依據，每一份證物都要能和設備上的原始資料逐位元對上。

這件事不是只做一次。修補與驗證期間，以及之後兩個月的複查，我們都用同樣的方式回頭核對結論與原始紀錄。

經覆核後確認成立的結論

Section titled “經覆核後確認成立的結論”

下列結論在對抗式驗證後確認成立：

  • 「7.23.4 / 7.24.2 修補不完全」成立
  • 攻擊者身分與來源成立（使用的是不存在於乾淨基準線中的後門帳號，時間與我方動作完全不重疊）
  • C2 程式的惡意性成立（程式碼自證，不依賴任何外部情報）
  • 反取證的責任歸屬反而被強化（有一個具名的後門帳號直接修改了日誌規則）
  • 流量側錄基本排除（見關於流量是否被側錄）

意外發現：資料平台的認證缺口

Section titled “意外發現：資料平台的認證缺口”

這一段嚴格來說不屬於這次入侵造成的損害，但它是這次事件調查的直接產物，而且風險比入侵本身更立即。我們認為必須一併公開。

怎麼發現的

Section titled “怎麼發現的”

在追查「攻擊者有沒有可能從路由器讀取內網服務資料」時，我們從網際網路直接對各服務埠實測。

結果發現的東西跟路由器無關 —— 有兩台資料平台主機把叢集協調服務直接開放在網際網路上，而且完全沒有認證。

發現的內容

Section titled “發現的內容”
項目 狀態（09/19 發現當時）
etcd（叢集協調服務）2379 兩台主機對全網開放，GET /v2/keys/ 直接回 200
etcd 寫入 未認證即可 PUT
Patroni（資料庫高可用管理）REST 8008 未認證，POST /config、/switchover、/restart 全部開放
etcd 版本 3.5.17 —— 含已知的認證繞過 CVE

處置與驗證

Section titled “處置與驗證”

09/19 當天完成修補。以下是修補後從外部實測的結果：

測試 修補前 修補後
etcd v2 GET /v2/keys/ 200 401
etcd v2 PUT /v2/keys/… 200 401
etcd v3 POST /v3/kv/range 正常回應 etcdserver: user name is empty
Patroni DELETE /switchover 200 401
Patroni GET /health（健康探測） 200 200（刻意保留）
etcd 版本 3.5.17 3.5.32

為什麼會這樣

Section titled “為什麼會這樣”

跟路由器那件事是同一個根因的不同表現：

路由器：管理介面對全世界開放，因為「它一直好好的」
資料平台：叢集協調服務對全世界開放，因為「它在內網」


→ 兩者都沒有人真的從外部驗證過「它到底有沒有對外」

處置

Section titled “處置”

為什麼「升級 + 改密碼」完全不夠

Section titled “為什麼「升級 + 改密碼」完全不夠”

這是最常見的誤解，也是我們必須說清楚的一點：

後門所在 升級能清除？ 改密碼能清除？
25 個最高權限後門帳號（12 種名稱） 不能 不能，帳號還在，只是密碼被改
C2 程式（腳本 + 排程） 不能 不能
每日自動重建的後門帳號 不能 不能，改密碼也會被腳本覆寫
注入的 SSH 金鑰 不能 不能，金鑰登入完全繞過密碼
SOCKS 代理 不能 不能
被破壞的日誌設定 不能 不能
已洩漏的憑證與私鑰 不能 不能，必須輪換
C2 可重新投放 不能，只要連得到就能重裝 不能

清理順序有硬性約束

Section titled “清理順序有硬性約束”

這不是可以隨便排的：

錯誤的順序 正確的順序
先刪後門帳號 → 隔天凌晨 03:00 自動重建，白做 先移除排程 → 再移除腳本 → 然後才刪帳號
先重開機 → C2 程式自動復活，記憶體證據全毀 先移除 C2 的腳本與排程 → 才能重開機
先換密碼再升級 → 漏洞還在，改了也能再被繞過 先升級切斷漏洞 → 再輪換憑證

完成進度

Section titled “完成進度”
項目 狀態 驗證方式
全程唯讀取證，未重開機、未清理 完成 記憶體證據完整保全
全部證物 SHA256 ＋ 證據保管鏈 完成 1000 份以上證據檔
四台升級至 7.24.4 ＋ RouterBOOT 韌體 完成 版本與韌體皆實測確認；之後由自動更新升到 7.24.5、7.25、7.25.1
移除全部後門帳號與持久化機制 完成 四台帳號各剩 1 個（僅 admin）；排程／腳本建立者全為 admin
移除注入的 SSH 公鑰 完成 四台 SSH 公鑰數皆為 0
關閉 SOCKS、bandwidth-server 完成 四台皆 enabled=no
輪換四台管理密碼 完成 舊密碼實測已失效
重建 VPN PKI（4 組新 CA ＋ 伺服器憑證） 完成 舊 CA 簽發的憑證全部失效
輪換 9 把 WireGuard 私鑰 完成 雙端同步，隧道握手正常
重新產生四台 SSH 主機金鑰 完成 升級後重新產生，舊主機金鑰作廢
SSH 管理介面限制來源白名單 完成 外部暴力破解量歸零（見前面）
日誌強化（磁碟落地 ＋ 65535 筆） 完成 磁碟日誌實際捕捉到再入侵嘗試
每週自動更新排程 完成 四台錯開時段；10–11 月已自動完成 3 次升級
移除受污染的備份與調查產物 完成 46 個檔案，並建立乾淨基準備份
資料平台認證缺口修補 完成 外部實測 401（見上一節）
重新入侵比對 完成 09/20、09/21、11/15 三次，四台皆無新跡象
剩餘節點檢查 未完成 5 台中已檢查 2 台，見還沒查完的部分

必須輪換的清單

Section titled “必須輪換的清單”
# 項目 狀態
1 全部 VPN 帳號密碼（其中確認有一組帳號在兩台設備間重用了完全相同的密碼） 完成
2 全部 9 把 WireGuard 私鑰 完成
3 VPN CA 與客戶端憑證（重簽並撤銷舊的） 完成
4 四台全部管理帳號密碼 完成
5 四台全部 SSH 主機金鑰 完成
6 內網主機的服務認證資訊 部分完成

根本原因：我們哪裡做錯了

Section titled “根本原因：我們哪裡做錯了”

漏洞是廠商的，但被打進來 16 天沒發現，是我們的問題。

直接原因

Section titled “直接原因”
四台設備版本落後於安全性修補（3 到 6 個月）
        +
SSH 管理介面對公網開放，且不限制來源 IP
        ↓
攻擊者不需要密碼就取得完整管理權限

為什麼會拖 16 天

Section titled “為什麼會拖 16 天”
# 問題 說明
1 沒有集中式日誌 日誌只存在設備本機，攻擊者一改設定證據就歸零。本案 80% 的證據缺口來自這一項
2 沒有設定變更告警 新增 25 個（12 種名稱）最高權限帳號、植入腳本與排程、修改日誌設定 —— 沒有任何一項觸發通知
3 沒有出向流量監控 一台設備每 3 分鐘對荷蘭的 IP 發 HTTP 請求，連續 3 天、1536 次，沒被發現
4 管理介面直接暴露於公網 設備上明明就有來源白名單機制，只是沒用在管理介面上
5 版本落後 3 到 6 個月 漏洞公告後 15 天仍未升級
6 沒有定期稽核 帳號清單、腳本、排程從來沒有定期比對過
7 過度信任內建偵測 「入侵旗標顯示正常」讓人安心，但它只比對已知指標
8 從未從外部驗證過暴露面 我們以為在內網的服務，實際上對全世界開放（見資料平台那一節）

五個為什麼

Section titled “五個為什麼”

  1. 為什麼設備被完整接管？

    因為六個 CVE 全部未修補，而 SSH 對公網無限制開放。

  2. 為什麼 CVE 未修補？

    因為沒有版本追蹤機制 —— 沒有人知道「我們的設備落後幾版」。

  3. 為什麼沒有版本追蹤機制？

    因為網路設備被當成「裝好就不用管」的基礎設施，不像應用服務有 CI/CD 與相依套件掃描在盯。

  4. 為什麼入侵持續 16 天沒被發現？

    因為日誌只存在設備本機，且沒有任何設定變更或出向流量的告警。

  5. 為什麼沒有集中式日誌？

    因為過去從沒發生過事故，沒有動機去建。

我們已經改的事

Section titled “我們已經改的事”
# 項目 為什麼 狀態
1 管理介面全面下架 只允許白名單與 VPN 來源。路由器本身於 09/19 完成；轉發到內網主機的 SSH 等服務則到 10/29 才補上白名單（見後續追蹤） 完成
2 啟用自動更新 本案的修補在攻擊前 12 天就存在 —— 自動更新原本就能擋下 完成
3 關閉不必要的服務 包含這次的攻擊面之一 bandwidth-server 完成
4 每台設備獨立的金鑰 不再用還原備份的方式複製設備設定 完成

還沒查完的部分

Section titled “還沒查完的部分”

誠實列出來，因為這些會影響結論的完整性。

與路由器相連的主機

Section titled “與路由器相連的主機”

透過隧道與四台路由器相連的 2 台 Linux 主機都已檢查，結果乾淨。

主機 狀態 結果
郵件 / WireGuard 對端主機（加拿大） 已檢查 帳號、sudoers、sshd_config、cron 皆未變動；authorized_keys 乾淨
WireGuard 對端主機（新加坡） 已檢查 同上

東京、大阪、台北三台是 VPS，沒有 RouterOS，不受這次的漏洞影響。

技術上無法補救的限制

Section titled “技術上無法補救的限制”
# 限制 影響
L-01 日誌已被破壞 無法取得攻擊過程本身的證據。初始入侵途徑是研判，不是確證
L-02 檔案系統層的植入無法檢查 這類植入無法透過一般指令觀察，需要離線磁碟鑑識
L-03 韌體層無法驗證 若植入在韌體層，設備自己的所有輸出都不可信
L-04 C2 是否曾成功下發指令無從查證 程式執行後立刻刪檔，沒有殘留

重刷（netinstall）方面：RouterOS 7.24beta1 起可以由另一台 RouterOS 遠端重刷，但兩台必須在同一個二層網段；我們四台實測不共用任何二層網段，所以重刷只能到場進行。

我們無法排除的一件事

Section titled “我們無法排除的一件事”

給其他維運者的 10 條具體建議

Section titled “給其他維運者的 10 條具體建議”

如果你也在跑 MikroTik，或更廣義地說，在跑任何「裝好就不太管」的網路設備，以下是我們用這次事件換來的東西。

如果你懷疑自己也被打了，先跑這幾項

Section titled “如果你懷疑自己也被打了，先跑這幾項”

  1. 列出帳號清單 —— 有沒有你不認識的名字？

    特別注意：ops / saryn / SystemMikrotik / routeradmin / system / operator

  2. 列出排程與腳本 —— 看「建立者」欄位，不要看名字

    建立者是 0（而非 admin）＋ 名字很像維運工作 = 高度可疑

  3. 列出使用者的 SSH 公鑰 —— 合法帳號上有沒有你沒掛過的金鑰？

    這是最隱蔽的一種後門，稽核帳號清單看不到

  4. 檢查日誌設定 —— 記憶體上限是不是被改小了？日誌規則是不是被停用？

    如果只剩 1 筆日誌，那本身就是入侵指標

  5. 檢查 SOCKS 代理是否被開啟

  6. 讀「設定變更歷史」 —— 它在記憶體裡，重開機就沒了，所以先讀它

十條建議

Section titled “十條建議”
# 建議 我們為什麼這樣說
1 不要先重開機 設定變更歷史只在記憶體。我們的整條時間軸都靠它。而且 C2 設定了開機自動啟動，重開機只會讓它復活
2 修補版本以原始通報者為準，不要相信漏洞資料庫 四個來源中只有 CERT Polska 寫出「7.23.4 修補不完全」。連原廠公告頁都沒寫
3 看建立者，不要看名字 daily-maint、logrotate 比我們自己寫的排程還像正常維運工作
4 「管理密碼突然失效」是入侵指標 掛上 SSH 金鑰會讓密碼登入被拒。我們一開始以為是自己記錯憑證
5 不要信任設備的內建入侵旗標 我們四台全部顯示正常，四台全部確認被入侵
6 不要只比對公開 IoC 清單 我們找到的 C2 不在任何公開清單上；公開清單上的兩個 IP 我們完全沒遇到
7 日誌必須離開設備 這是最高價值的一項。本案 80% 的證據缺口來自這一點
8 記憶體日誌不夠，要有磁碟日誌 我們捕捉到的兩次再入侵嘗試，在 15 分鐘內就被擠出記憶體緩衝區。靠磁碟日誌才留下來
9 升級先於改密碼 漏洞還在的話，改密碼也能被繞過
10 清理順序：排程 → 腳本 → 帳號 反過來做，帳號隔天就會被腳本重建

兩個容易誤判的技術細節

Section titled “兩個容易誤判的技術細節”

後續追蹤

Section titled “後續追蹤”

事件處置完成之後，我們持續檢查並收緊防護。以下是到 2026/11/15 為止的進展。

沒有再入侵

Section titled “沒有再入侵”
日期 檢查 結果
09/20、09/21 完整健康檢查，並與乾淨基準比對 四台皆無新跡象
11/15 同上，並把四台設定與最後一次授權變更後的快照逐行比對 0 處差異；已知的 9 項入侵特徵與漏洞利用嘗試皆為 0；日誌中每一筆設定變更與登入，都能對應到我們自己的操作或自動排程

自動更新確實在運作

Section titled “自動更新確實在運作”

本文提到的每週自動更新，在 10 月到 11 月間已自動完成三次升級。四台錯開時段，沒有同時中斷。

  1. 自動升級至 7.24.5

  2. 自動升級至 7.25

  3. 自動升級至 7.25.1

之後補上的防護

Section titled “之後補上的防護”
日期 內容
10/09 統一四台的 DNS 與校時：區網裝置的 DNS 查詢一律導向路由器，由路由器經加密 DNS（DoH）向上游查詢；校時統一由路由器提供。過程中發現其中一台的 DNS 攔截被另一條路由設定打壞而失效，已修正
10/11 VPN 使用者的 DNS 也強制導向路由器；清除四台上未使用的撥號與 VPN 範本設定（其中包含指向第三方 DNS 的設定）
10/29 從網際網路實際掃描四台的對外埠：轉發到內網主機的 10 個 SSH 埠與一個內部 AI 服務沒有來源限制，當日補上白名單並從白名單內外各驗證一次；經雲端主機轉入的流量也改為只放行服務需要的埠
10/31 修正 VPN 用戶端設定 auth-nocache 造成的每小時斷線：RouterOS 每小時重新協商金鑰時要再送一次帳密，而這個選項讓用戶端登入後就丟掉密碼。已從用戶端設定檔移除
11/05 盤點 IPv6：路由器底下的設備沒有任何 IPv6 對外路徑，白名單不會被 IPv6 繞過

為什麼有些細節沒寫出來

Section titled “為什麼有些細節沒寫出來”

這篇是公開版本。內部的完整取證報告含有明文密碼、私鑰、設備序號與內網拓樸，不會公開。

本文的處理原則：

類別 處理
我方設備的公網 IP、序號、金鑰指紋、內網位址與拓樸 移除，改以節點代號與地區表示
VPN 帳密、私鑰、憑證內容 只描述數量與型別，不列值
資料平台的主機位址、資料庫帳號密碼 移除
攻擊者的 C2 位址、來源 IP、後門帳號名稱、惡意程式檔名、持久化手法、注入金鑰指紋 完整揭露 —— 這些對其他防守方有價值

完整取證資料（1000 份以上的證據檔、全案 SHA256 清單、證據保管鏈、驗證紀錄）保存於 private 證據庫。

結語

Section titled “結語”

首先向所有受影響的使用者致歉。 DPIP 是一個防災服務，服務的穩定與可信度直接關係到它存在的意義。這次事件是我們在基礎設施維運上的疏失，沒有推託的餘地。

三件我們認為必須講出來的事：

  1. 修補在攻擊者植入 C2 的 12 天前就已經釋出。

    這不是零時差攻擊。任何形式的自動更新 —— 即使是每週跑一次 —— 都能擋下這次攻擊。我們沒有做，因為網路設備被當成「裝好就不用管」的東西。這是最便宜的防線，而我們沒有架。

  2. 我們差一點就毀掉自己的證據。

    「先重開機再說」是最自然的反應。如果當初那樣做，唯一能證明「誰在何時建立了哪個後門帳號」的紀錄會永久消失，而且 C2 程式會因為開機自動啟動的設定而復活。取證優先於復原，這個判斷事後證明是對的。

  3. 那個叫 ops 的後門帳號在設備上躺了 16 天。

    它是官方公告直接點名的入侵指標，只要跑一個指令列出帳號清單就看得到。我們沒有跑，因為沒有人覺得需要去看一台「一直好好的」路由器。

發布紀錄

Section titled “發布紀錄”

本文於 2026/11/15 發布。事件當天（09/18）我們先以公告發布摘要。

參考資料

Section titled “參考資料”
標籤：