Synology 上的 C3RB3R 勒索軟體：起源、復原與如何保持安全

C3RB3R 勒索軟體 在 2026 年 10 月 28 日左右開始出現在 Synology NAS 設備上，不到一天時間，它就成為 r/synology 上唯一的討論話題。檔案被重新命名並帶有 L0CK3D 副檔名（是數字 0，而不是字母 O），每個資料夾都會產生一個 read-me3.txt 勒索說明檔，並有一個 Tor 入口網站要求支付比特幣。最快且最有用的資訊並非來自英文新聞網站，而是來自 Synology 擁有龐大使用者社群的中文論壇，以及由實際救回資料或證實無法救回的受害者所撰寫的三個 GitHub 儲存庫。本指南彙整了目前關於 C3RB3R 勒索軟體的已確認資訊：它從何而來、如何入侵、唯一有效的救回途徑，以及我們運作的備份設計，讓這類攻擊對我們而言僅需還原即可，而無需支付贖金。

更新，2026 年 10 月 31 日： Synology 現已確認入侵途徑。在 10 月 30 日寄給客戶的電子郵件中，官方證實 C3RB3R 勒索軟體僅利用了在 2024 年 12 月修補的 Synology-SA-24:20 漏洞，且此攻擊行動與同月修補的 PHP2Shell 漏洞無關。我們新增了 Synology 官方的四步驟檢查清單、我們對為何攻擊會在當時爆發的解讀，以及我們正在使用、且大多數用戶早已付費的額外防禦層：Active Insight 勒索軟體保護。

SynoPower Club 點：中文 NAS 社群中的一名受害者在單台設備上存有超過 50 TB 的資料且沒有快照。加密程式運作速度夠慢，因此只有他 2024 年的照片遭到加密，而這些照片剛好在雲端硬碟上有冷備份。另一位受害者則失去了五年來的私有 GitLab 儲存庫，因為 RAID 6 加上三個備份全都放在同一台機器上。C3RB3R 勒索軟體擊敗的不是他們的儲存空間，而是他們的備份架構。我們將公開網站以 Docker 形式運作於 Virtual DSM 內，從宿主機對整個客體機進行快照，複製到第二台 NAS，並按排程匯出至 USB 與雲端。如果客體機今晚被加密，我們只需將其復原至最新的快照，攻擊者將一無所獲。

什麼是 C3RB3R 勒索軟體？

C3RB3R 勒索軟體是 Cerber 家族的 Linux 版本，該勒索軟體系列自 2016 年以來就已存在，多年來斷斷續續以 NAS 設備為目標。360 將 2026 年 10 月針對 Synology 的攻擊波歸因於它。在受感染的 DSM 設備上，C3RB3R 勒索軟體加密程式作為名為 libgld的靜態連結、經 UPX 壓縮的 x86-64 二進位檔執行。它在啟動後會刪除自身的檔案，因此執行中的程序會在 (已刪除) 顯示於其可執行檔路徑旁。

作為遭受 C3RB3R 勒索軟體攻擊的設備擁有者，您所看到的現象在每份報告中都是一致的：

• 檔案被重新命名為 name.ext.L0CK3D。某些報告將其寫為 LOCK3D，但 GitHub 的分析引用的是數字 0。
• 每個受加密資料夾中都有一份名為 read-me3.txt 的勒索說明檔，標題為 C3RB3R INSTRUCTIONS。
• 標題為 C3rb3r Decryptor 的 Tor 頁面。一名受害者的螢幕截圖顯示，若在五天內支付需 0.03696 BTC（約 2,952 美元），之後則翻倍至 0.07392 BTC（約 5,904 美元），並附有倒數計時器。
• 透過符合 /etc/cron.d/synot*的 cron 項目保持常駐，這些項目會自我重建，且在至少一個案例中經過 DSM 升級後依然存在。
• 同一儲存區上的備份檔案連同其他所有內容一併被加密，包括 Hyper Backup 目標和資料庫傾印（dumps）。

始於何處：r/synology 與中文論壇

C3RB3R 勒索軟體最初於 2026 年 10 月 28 日至 29 日左右在 r/synology 英文版面上首次浮現，受害者相繼發文。數小時內，讀者表示每次重新整理該版面都會出現新的討論串。其中有三個討論串非常值得完整閱讀，因為每個討論串都補充了不同的資訊：

• 鑑識分析報告。 一位使用 DSM 7.2.1-69057 Update 5 的 DS918+ 擁有者，其網頁介面可從網際網路連線，他將設備關機並在 Proxmox 宿主機上以唯讀方式檢查硬碟。DSM 驗證日誌包含一個登入請求，其帳號欄位帶有注入的 LD_PRELOAD 和 LD_DEBUG_OUTPUT 行以及編碼後的 shell 指令，還有一個位於 /etc/cron.d下的檔案。這與已公開的 CVE-2024-10441 技術一致。3-2-1 備份意味著這次攻擊僅花費了還原時間，而非贖金。在此閱讀原文： 唉，終究還是發生了。這是我第一次遇到真正的勒索軟體事件.
• 僅使用 Photos 的使用者。 這位擁有者以為 DSM 已是最新版本，且僅使用 Synology Photos，但路由器上的 UPnP 處於開啟狀態。在進行 Mode 2 重置後，受 Snapshot Replication 保護的資料夾得以復原。沒有快照的資料夾則無法復原，且本機 Hyper Backup USB 外接硬碟連同 NAS 一起被加密。在此閱讀原文： 今天早上中了 c3rb3r 勒索軟體.
• QuickConnect 討論。 發帖者是在 DSM 降級且重新安裝顯示加密檔案後才注意到。在回覆中，另一位啟用了強密碼、2FA 和 QuickConnect 的讀者表示他們也遭受了攻擊，其他人則指出僅使用應用程式的使用者可以在 QuickConnect 中完全關閉 DSM 存取權限。在此閱讀原文： 中了 C3RB3R 勒索軟體.

綜合來看，模式非常清晰。C3RB3R 勒索軟體只需要一個能夠存取的 DSM 登入頁面即可，僅此而已。密碼和雙重驗證 (2FA) 毫無作用，因為漏洞利用是在身分驗證之前執行的。鑑識報告講得很明白：請求到達了存有漏洞的應用程式，就算多一層密碼提示也無法解決該問題。

更深入的技術工作是以中文進行的。微信與小紅書群組中的受害者張貼了勒索信、比對時間軸，並互相分享下方涵蓋的 GitHub 儲存庫。Facebook 上的台灣 Synology 社群 也收集了相同的復原連結 供在地使用者使用。這合情合理：Synology 是一家台灣公司，其最大的使用者社群以中文為主，因此大量的 C3RB3R 勒索軟體案例以及最快的特徵比對都來自這裡。

Synology 本身發布了 一份安全性公告 於 2026 年 10 月 29 日表示，已發現有威脅份子利用 2024 年 12 月修補的漏洞攻擊舊版 DSM，並呼籲所有人立即更新。

C3RB3R 勒索軟體是如何入侵的

在最初的兩天內，存在兩個潛在的入侵途徑。Synology 隨後確認了較舊的那一個。其 10 月 30 日的電子郵件指出，攻擊僅利用了 Synology-SA-24:20 中修補的漏洞，且 C3RB3R 勒索軟體與 PHP2Shell 完全無關。下表顯示了當時討論的兩個候選漏洞，因為這對 360 漏洞依然非常值得修補。

	Synology 表示	360 表示
諮詢	Synology-SA-24:20 (Pwn2Own 2024)	Synology-SA-26:13
CVE	CVE-2024-10441，CVSS 9.8，系統外掛程式守護行程 (plugin daemon) 中未經身分驗證的遠端執行程式碼漏洞	CVE-2026-13639（登入邏輯）與 CVE-2026-13684（SCGI），CVSS 均為 9.8
修補時間	2024 年 11 月至 12 月	2026 年 9 月 18 日
已修復版本	DSM 7.2.2-72806 Update 1、7.2.1-69057 Update 6、7.2-64570 Update 4、7.1.1-42962 Update 7	DSM 7.4-90075、7.3.2-86009 Update 4、7.2.2-72806 Update 9、7.2.1-69057 Update 12

鑑識證據指出至少在部分受害者身上，問題偏向較舊的漏洞。Reddit 上最詳細的分析報告將其存留的日誌與公開的 CVE-2024-10441 漏洞利用程式比對成功，同時也指出 Synology 尚未證實這一點，且該台機器同樣未達 SA-26:13 的修補版本。soimy 的分析報告提到，受感染虛擬機的記憶體日誌顯示有透過 DSM 登入外掛程式進行環境變數注入的情況，這與 CVE-2024-10441 一致，且在爆發前幾天 GitHub 上就出現了利用登入使用者名稱欄位的公開概念驗證 (PoC)。在三個有記錄的救援案例中，有兩個是在使用 DS918+ 引導程式的非原廠硬體（黑群暉）上運作，其中一台運行的是 DSM 7.2-64570 Update 3，距離修復 CVE-2024-10441 剛好只差一個更新。非原廠硬體無法輕易安裝官方更新，這使其成為最容易受攻擊的目標。

實際的結論並未改變：請更新至包含這兩份安全通報修補程式的版本，並停止將 DSM 暴露於網際網路上。但仍有一個疑問：如果漏洞早在 2024 年 12 月就已修補，為什麼會有如此多的 NAS 在 2026 年 10 月的同一兩天內遭到 C3RB3R 勒索軟體攻擊，甚至包括一些擁有者認為已經是最新版本的裝置？

提早植入，定時引爆

我們的解讀（這是我們自身的分析，而非 Synology 官方表態）是：C3RB3R 勒索軟體的入侵與加密是兩個獨立的事件。證據指向這個方向：

• 後門先被植入。 在下方的小紅書案例中，後門 shell 在任何檔案被加密之前，就已經在 NAS 上潛伏了 37 天，並以 root 權限開啟了 telnet。
• 它能在系統更新後存留。 位於下方的 cron 條目 /etc/cron.d/synot* 會自動重新建立，且至少有一名受害者發現即使在升級至最新 DSM 後，這些條目依然存在。更新堵住了漏洞，但仍將入侵者留在了系統內部。
• 引爆是同步發生的。 在不同時間、不同系統版本受害的 C3RB3R 勒索軟體受害 NAS，大約在 48 小時之內同時開始加密。

這種模式符合攻擊者的行為特徵：他們數月來在未修補漏洞的 NAS 上植入 C3RB3R 勒索軟體後門，然後選擇時機遠端引爆。他們選擇的時機正是 PHP2Shell 發布的那一週，當時每位 Synology 管理員都在忙著修補，許多 NAS 剛完成更新，擁有一種安全的錯覺。Synology 明確表示 PHP2Shell 並非入侵途徑，而是掩護。教訓是：任何曾在未修補狀態下暴露於網路的 NAS，在經過仔細檢查之前都應視為已被入侵，而這正是 Synology 檢查清單的第一步要求您做的事。

應對 C3RB3R 勒索軟體的 4 個緊急步驟

如果你現在發現 L0CK3D 檔案，接下來十分鐘的處置順序將決定是否還有可能復原。解鎖檔案的金鑰僅存在於正在執行的 C3RB3R 勒索軟體程序中。重啟機器、執行 kill -9 或重新安裝 DSM 都會將其摧毀。

步驟 2 和 3 所需的指令如下。執行任何指令前請先閱讀儲存庫說明，因為具體細節取決於您手頭上的執行檔。

# 步驟 2：尋找加密程序（其可執行檔會顯示為已刪除）

ls -l /proc/*/exe 2>/dev/null | grep deleted

# 凍結它。切勿在此處使用 kill -9。

kill -STOP <PID>	grep State /proc/<PID>/status # 應顯示 T (stopped)	# 尋找使其持續運作的排程項目	ls -l /etc/cron.d/ | grep synot
能否解密？三個 GitHub 救援案例分析	目前沒有通用的 C3RB3R 勒索軟體解密工具，任何宣稱販售解密工具的人都在憑空猜測。目前有的只是三個詳細的案例研究，能確切告訴您何時才能成功復原。	儲存庫	機器
結果	原因	儲存庫	soimy/c3rb3r-rescue
運行 GitLab 的 Proxmox VE 虛擬機中的 DSM	已復原	16 GiB 的虛擬機 RAM 副本中包含 48 位元組的工作階段金鑰。GitLab 已成功復原 80 個專案和 9,253 個 LFS 物件。	加密程式在大約 30 小時前就已經結束執行。完整的 RAM 與 Swap 記憶體掃描均未找到金鑰。

第三個儲存庫是最重要的一篇，因為它的標題本身就是一個教訓：從未重開機並不代表可以復原。真正重要的是 C3RB3R 勒索軟體程序是否仍在執行中。一旦它結束執行，就會將其金鑰緩衝區歸零，金鑰也就隨之消失。在某個受害者設備上復原的金鑰對另一個受害者來說也毫無作用，因為每次執行都會產生新的工作階段金鑰。

為什麼金鑰僅存在於記憶體中

Benjamin-zlt 的分析詳細說明了 C3RB3R 勒索軟體的檔案格式，並同時解釋了為什麼這種方法可行，以及為什麼通常不可行。

• 每個檔案都會獲得獨立且隨機的 ChaCha8 金鑰。 該金鑰使用 AES-256-CBC 與工作階段主金鑰（session master key）進行包裹，並儲存在檔案末端的 588 位元組標籤（trailer）中。
• 工作階段主金鑰長度為 48 位元組： 包含 16 位元組的 IV 與 32 位元組的 AES 金鑰。它絕不會寫入磁碟，而是由正在執行的程序內部的全域指標指向它。
• 檔案末端的標籤還包含一個由攻擊者公鑰所包裹的資料區塊（blob） (RSA-2048)，因此若沒有正在執行的程序，就只有攻擊者才能復原該工作階段金鑰。
• 並非所有檔案都被完全加密。 在 400 個檔案的樣本中，約有 56% 使用分段模式，31% 僅加密了前 1 MiB，而 13% 則是首尾完整加密。部分加密的檔案仍然無法直接讀取，但頁尾（footer）鑑別能讓您知道還剩下什麼。

因此，C3RB3R 勒索軟體的弱點非常狹窄且具有時效性：加密程式在整個工作階段期間都會將主金鑰保留在記憶體中。只要在其執行時凍結它，您就能將金鑰提取出來。一旦錯過該時機，您就只剩下公鑰資料區塊，而那是被設計為無法破解的。

受害者故事：50 TB 資料且沒有快照

使用者「柯基爱好者」於 2026 年 10 月 29 日在小紅書上發布的詳細記錄，記錄了其 NAS 社群中一名成員度過的夜晚。該成員發現了 C3RB3R 勒索軟體的勒索信，確認了 C3RB3R INSTRUCTIONS 標頭，並差點要購買比特幣，直到社群成員引導他查看 GitHub 的案例。

接著，他透過 SSH 使用 AI 程式設計助手進行調查。助手找到並凍結了加密程式，因此在那之後就沒有新的資料被加密。助手還發現一個可能的後門 shell 已經在 NAS 上潛伏了 37 天，並以 root 權限啟用了 telnet，這意味著最初的入侵與正式加密相隔了一個月以上。它撰寫了證據收集腳本，並正確地等待他確認後才以 root 身份執行任何操作。

幸運的是，C3RB3R 勒索軟體的加密速度很慢。面對超過 50 TB 需要處理的資料，加密程式才剛加密到他 2024 年的照片，而這些照片在雲端硬碟上有冷備份。他將工作資料移至較小的 NAS，並暫時停用加密儲存空間以待後續處理。他自己的總結非常直接：他沒有快照，如果有快照，這本來很容易修復。X 上的第二位受害者則從另一個角度總結了相同的教訓：RAID 6 加上三套備份，全部都在同台機器上，結果全部一起被加密了。

我們如何避免備份受到 C3RB3R 勒索軟體的侵害

上述每個資料遺失的故事都有相同的模式：備份可以從被入侵的機器存取。C3RB3R 勒索軟體會加密遭到入侵的 DSM 所能寫入的所有內容，因此解決方案是將至少一份副本存放在 DSM 完全無法寫入的地方。這就是我們為我們託管的網站所採用的做法，且符合 3-2-1-1-0 原則。

規則	意義	我們的做法
3	三份資料副本	運作中的 VM、第二台 NAS 上的副本，以及排程匯出檔案
2	兩種不同的儲存媒體	NAS 儲存空間外加外接 USB 硬碟與雲端硬碟
1	一份異地副本	透過 Cloud Sync 將匯出檔案同步至 Google Drive
1	一份離線或不可變（immutable）副本	客體機（guest）無法存取的實體主機端 VM 快照，加上拔除連線的 USB 匯出檔案
0	還原零錯誤	當我們在主機之間搬移 VM 時，我們會實際從副本進行還原並開機測試

在 Virtual DSM 內部執行 Docker，而非在實體主機上執行

我們的 WordPress 容器並非直接執行於實體 NAS 上。它們執行於 Virtual DSM 客體機內部，而該客體機則受到實體主機上的 Virtual Machine Manager 所保護。如果 C3RB3R 勒索軟體在客體機內部取得 root 權限，它只能控制該客體機，無法影響其他地方。客體機的快照儲存於實體主機儲存空間中，獨立於客體機的檔案系統之外，因此 VM 內部的勒索軟體根本看不到它們，更不用說加密或刪除了。復原只需花費數分鐘進行快照回滾（rollback）。

VMM Pro 增加了將其轉變為真正備份的功能：保護計畫會為 VM 建立快照並將其複製到叢集中的第二台 NAS，因此即使實體主機損壞也能獲得保障。我們的叢集由一台 DS1621xs+ 和一台 DS1525+ 組成，彼此互相複製。我們單獨撰寫了 排程匯出與透過 Cloud Sync 同步至 Google Drive 部分的內容，而 免費版 VMM 與 VMM Pro 的比較 則說明了哪些部分需要授權。

如果您直接在 DSM 上執行 Docker，請使用不可變快照（immutable snapshots）

並非所有人都需要 VM 層。如果您的容器直接執行在主機上，防禦 C3RB3R 勒索軟體的手段就是不可變快照。請在 Snapshot Replication 中，為存放容器資料的共用資料夾開啟此功能。這需要 DSM 7.2 或更新版本以及 Btrfs 儲存空間，且在鎖定期間內，包括被攻擊者控制的管理員帳號在內，任何人都無法刪除它們。有兩個細節會決定成敗：

• 使用綁定掛載（bind mounts）至共用資料夾 例如 /volume1/docker/app。Docker 具名卷（named volumes）位於 /volume1/@docker，這並非共用資料夾，完全無法進行快照。
• 在快照之前將資料庫傾印（dump）至檔案。 執行中 MariaDB 的快照就如同斷電時的副本。預定的 mysqldump 匯出至同一個共用資料夾，就能為您提供一個乾淨的還原點，並由快照將其鎖定。
• 選擇比攻擊者潛伏時間更長的鎖定期間。 上述受害者在檔案被加密前，後門程式已存在了 37 天。七天的不可變快照將無法追溯回乾淨的狀態。

我們的額外防禦層：Active Insight 在加密開始時自動拍攝快照

這是大多數指南忽視的防禦層。Active Insight 是 Synology 的雲端監控服務，可以監控共用資料夾中的檔案活動，一旦判斷為勒索軟體行為，就會自動做出處置。Synology 在其 NAS 安全指南中說明：當偵測到勒索軟體事件時，Active Insight 會發送事件通知並自動拍攝共用資料夾的快照；在支援的機種上，該快照為不可變快照（Immutable Snapshot）。

這對 C3RB3R 勒索軟體特別重要的原因在於：C3RB3R 勒索軟體的加密速度較慢。擁有超過 50 TB 資料的受害者在注意到時，加密程序才剛進行到他 2024 年的照片。在首次出現加密跡象時拍攝的快照，可以凍結所有尚未被竄改的檔案，這通常涵蓋了儲存空間的大部分內容。此外，它也不關心 C3RB3R 勒索軟體是如何入侵的，因為它監控的是檔案活動，而非登入頁面。在我們的 DS1621xs+ 上，檔案活動頁面將勒索軟體防護顯示為 Protected。

在依賴此功能之前，請先瞭解其限制。這些內容來自 Synology 的 檔案活動說明文件:

• 檔案活動監控預設為關閉。 請在控制台將 NAS 註冊至 Active Insight，然後在 Active Insight 入口網站中為每台主機啟用監控。
• 它需要 Snapshot Replication、 DSM 7.2 或更新版本、Active Insight 3.0.2 或更新版本、至少 1 GB 記憶體，以及指派給該 NAS 的 Active Insight 授權。
• 每個共用資料夾每天最多自動拍攝一張快照。 這是偵測後採取的安全防護網，不能替代排程的不可變快照。
• 不涵蓋的範圍： Surveillance Station 錄影資料夾與外接 USB 硬碟上的共用資料夾。
• 不可變性取決於機種。 在不支援不可變快照的機種上，擁有 root 權限的攻擊者仍可刪除自動快照，因此請配合上述不可變快照排程使用。

也想採用相同的設定嗎？ SynoPower Club 銷售這兩個核心元件的正版授權：一個 Virtual DSM (VDSM) 授權 可在隔離的客體機中執行您的 Docker 服務，以及一個 VMM Pro授權 可用於保護計畫、跨 NAS 複製與即時轉移。金鑰透過電子郵件寄送。

哪裡可以找到更多官方資源

在撰寫本文時，Synology 上的 C3RB3R 勒索軟體才公開爆發兩天，目前尚無官方影片報導，因此本節列出第一手資料來源而非操作指南。

• Synology 安全性公告 發布於 2026 年 10 月 29 日，提醒舊版 DSM 使用者立即更新並開啟自動更新；隨後於 10 月 30 日向客戶發送電子郵件，確認 SA-24:20 為唯一涉及的漏洞。
• Synology-SA-24:20 和 Synology-SA-26:13 為版本對照表。請在控制台的「更新與還原」中檢查您的組建版本，並與兩者進行比對。
• 運行 GitLab 的 Proxmox VE 虛擬機中的 DSM 是所有已知案例最佳的索引（包含此處未提及的案例），也是對記憶體取證何時失去作用解釋得最清楚的文章。
• 上述連結的三個 r/synology 討論串，特別是數位取證分析文章，其中包含按部就班的唯讀磁碟調查指令： 好吧，它終於發生了.

Synology 官方檢查清單（2026 年 10 月 30 日）

Synology 寄給客戶的電子郵件以四個步驟作結。這些步驟簡短，而且每一個步驟對於防禦 C3RB3R 勒索軟體都至關重要：

1. 檢查是否有入侵者。 C3RB3R 勒索軟體會留下排程的持久性防線，因此請執行 Security Advisor 掃描，接著在「任務排程表」中尋找非您建立的指令碼，並在「使用者與群組」中尋找非您新增的管理員帳號。若發現任何異常，請聯絡 Synology Support。
2. 更新所有項目。 前往「控制台」>「更新 & 還原」安裝最新的 DSM，然後更新「套件中心」中的每一個套件。
3. 開啟自動更新 在「更新 & 還原」中，以便未來的安全性修復程式一釋出就能立即套用。
4. 保持異地備份。 使用 Hyper Backup 和 Snapshot Replication 將副本存放在獨立的位置，並定期檢查備份任務是否確實完成。

第一步是大家最常忽略的步驟。如果您的裝置在 2024 年 12 月修復程式釋出前可從網際網路存取，C3RB3R 勒索軟體可能已經立足，而今天進行更新並無法告知您是否有人已經潛入。

為您自動執行檢查的免費工具

如果您熟悉終端機，第一步現在只需執行單一指令。synology-nas-cli 是獨立開發者 Akari Sora 於 2026 年 10 月 30 日發布的 MIT 授權開源命令列工具。它透過 Web API 登入 DSM，並針對本次攻擊活動稽核 NAS。該專案已託管於 GitHub： akari-sora/synology-nas-cli.

我們在附上連結前已詳細審閱其程式碼。它僅使用 Python 標準函式庫，並且除了您的 NAS、Synology 下載伺服器、PyPI 與 soimy 救援工具包之外，不會與任何外部伺服器連線。它不會傳送任何遙測資料，基礎稽核也僅進行唯讀檢查。以下是它的檢查項目：

• 修補程式版本。 比對您的 DSM 建置版本是否符合 Synology-SA-26:13（此修補亦涵蓋較舊的 SA-24:20 修復），以及已安裝的套件是否符合 SA-26:14。
• 暴露風險。 QuickConnect、路由器上的 UPnP 通訊埠轉發、DSM 防火牆、自動封鎖、SMB1 以及內建的 admin 帳號。
• C3RB3R 勒索軟體的痕跡。 連線紀錄中注入的登入字串、 /etc/cron.d/synot* 項目、 libgld 和 qnetd 執行檔、額外的 root 帳號、SSH 金鑰以及共享資料夾中的勒索信。
• 快照。 沒有有效快照排程的共用資料夾。

它還能修復發現的大部分問題。如果檔案目前正在被加密，其 contain 指令會使用 SIGSTOP 凍結加密程式，這與我們應變處置清單的第二步相同。接著它的 rescue 指令會驅動 soimy 工具包擷取記憶體並搜尋金鑰。

nas incident                 # 唯讀稽核

nas incident --deep # 同時搜尋植入物（單一唯讀 root 腳本）

• nas incident fix --dry-run # 列出預計進行的所有變更，但完全不修改系統 在讓它進行任何變更前，請先閱讀以下注意事項：
• 這是一個全新的工具。 此專案僅發布幾天，由單一開發者維護，未隸屬於 Synology，且很少經過外部審查。請先從唯讀稽核與模擬執行 (dry run) 開始。
• 防火牆修復可能會將您鎖在系統外。 它會將 DSM 防火牆切換為拒絕除了您指定網路以外的所有連線。請從同一區域網路 (LAN) 上的電腦執行它，並清楚 RESET 按鈕的位置。
• 它會關閉 QuickConnect。 這是更安全的設定，但如果您的家人需要透過 QuickConnect 存取 Synology Photos 或 Surveillance Station，請先設定好 VPN 或 Tailscale。
• 深度掃描 (deep)、隔離 (contain) 與救援 (rescue) 指令會以 root 權限執行。 它們是透過臨時建立的「工作排程器」任務來運作，因為這是讀取僅限 root 權限日誌與凍結處理程序的唯一方法。
• README 建議可將其交由 AI Agent 執行。 如果您這樣做，請將密碼妥善儲存在密碼管理器中，而非貼在聊天視窗內，並親自確認修復結果。

關於其他系統強化的完整細節，請參閱我們關於 在 Synology NAS 上運作公開網站 以及關於 Threat Prevention 能看到與看不到的內容 的指南（涵蓋網路層面），而 PHP2Shell 修補指南 則涵蓋了同一週發生的另一個重大安全性問題。

C3RB3R 勒索軟體限制與安全性注意事項

更新系統並不能清除既有的勒索軟體感染。 至少有一位受害者在升級到最新版 DSM 後，發現 cron 排程常駐項目仍然存在。如果您在未修補漏洞前曾暴露於風險中，請檢查 /etc/cron.d、工作排程器、開機啟動腳本以及已啟用的服務（如 telnet），然後更換所有憑證與密碼。

保持最新不等於系統乾淨。 一位 Reddit 受害者以為 DSM 已是最新，另一位受害者則是在開啟 2FA 且設有強密碼的情況下遭到入侵。在完成修補前遭到入侵的裝置，其植入的惡意程式可能會在之後的每次更新中繼續存留。請將網際網路可存取的任何 DSM 登入頁面都視為攻擊目標，包括您從未特意設定、由 UPnP 自動發布的頁面。請使用 VPN 或 Tailscale 進行遠端存取，並關閉路由器上的 UPnP。

RAID 和本機備份無法用來抵禦 C3RB3R 勒索軟體。 遭受入侵的 DSM 所能寫入的任何內容都會被加密，包括同一台 NAS 上的 Hyper Backup 目的地以及已掛載的網路共用資料夾。

在閱讀相關案例前請勿支付贖金。 支付贖金給 C3RB3R 勒索軟體營運者只會資助下一波攻擊，且無法保證能救回檔案。如果加密程式仍在運作，提取記憶體解密是您的最佳機會；如果程式已停止，唯一切合實際的做法是使用儲存在 NAS 外部的備份副本。

貼上內容至 AI 助手時請務必謹慎。 AI 工具在此處協助了數名受害者，但請勿提供密碼、已復原的金鑰、完整記憶體傾印檔或商業資料。您可以讓 AI 建議指令，並由您親自執行任何需要 root 權限的操作。

非原廠硬體承擔額外風險。 數個已記錄的受害者是在非原廠硬體上執行 DSM，這類設備通常難以或無法套用官方更新。如果您的環境屬於此類，請假設系統尚未修補漏洞，並將其完全切斷網際網路連線。

參考

• 關於 DSM 勒索軟體攻擊的 Synology 安全性公告，2026 年 10 月 29 日。
• Synology-SA-24:20 DSM (Pwn2Own 2024)，CVE-2024-10441 與已修補的 DSM 組建版本。
• Synology-SA-26:13 DSM，CVE-2026-13639 與 CVE-2026-13684，發布於 2026 年 9 月 18 日。
• Benjamin-zlt C3RB3R 勒索軟體裸機救援、檔案格式、金鑰結構與 SIGSTOP 工作流程。
• 記憶體救援僅在加密程式仍在執行時有效。這與 GitHub 上三個案例的適用規則相同。
• IT-Connect 針對 C3RB3R 攻擊行動的報導，總結了 360 的歸因分析與時間軸。
• Synology 知識中心：提升您的 Synology NAS 安全性，包含 Active Insight 在偵測到勒索軟體時如何自動對共用資料夾拍攝快照。

經常問的問題

讓下一次 C3RB3R 勒索軟體攻擊只花費您還原的時間，而不是贖金。 在 Virtual DSM 內執行您的 Docker 服務，並透過 VMM Pro 保護計劃保護整個客體機，複製備份至第二台 NAS。SynoPower Club 銷售這兩者的正版授權，並透過電子郵件寄送授權碼。