2026 年 10 月，多起群晖 NAS 勒索事件暴露出一个共同问题：攻击者一旦获得系统写入权限，不仅能够加密共享文件，还可能破坏容器数据、套件目录和本机备份。部分受害设备出现了 .L0CK3D 文件后缀和 read-me3.txt 勒索信，业务文件与备份同时失去可用性。

这类问题需要分两步解决：先停止继续加密并找回数据，再修复系统和访问入口。安装补丁可以堵住已知漏洞，但不能把已经加密的文件变回原文。 数据恢复依赖健康备份、历史快照、匹配的解密密钥，或者仍然存在的旧数据块。

如果设备正在中招，先做三件事：切断不必要的网络连接、停止继续加密、保护健康备份。没有确认可用的备份，且 NAS 尚未重启时，先不要重启、升级或重装，以免失去内存中可能存在的解密密钥。

一、目前影响哪些设备和数据

1. 风险取决于版本、入口和权限

目前公开信息不足以给出可靠的全球受害数量。对于具体设备，更有用的判断是：软件是否存在未修补漏洞、攻击者能否访问相关服务，以及该服务能写入哪些数据。

文件被加密并不要求用户开启某一种固定的远程访问功能。只检查 SSH 或 QuickConnect 是否关闭，不能覆盖端口映射、IPv6、反向代理、容器端口和其他套件入口。

2. DSM 应至少更新到什么版本

以下版本用于核对本文涉及的已公布 DSM 漏洞修复要求。表中的版本是对应问题的修复门槛；设备有更新的适用安全版本时，应按机型支持的升级路径安装。

在 DSM 的“控制面板 → 更新和还原”查看完整版本。版本末尾的 -4、-9、-12 对应补充更新级别，不能忽略。

仍使用更旧分支、无法获得适用更新或无法正常升级的设备，应停止向公网开放管理与非必要服务，并迁移到受支持环境。已经出现加密迹象的设备，先按下文恢复数据，再安排升级和重建。

3. PHP 与相关套件需要另外处理

PHP2Shell 涉及 CVE-2026-109618、CVE-2026-109619。它属于需要同时修复的风险，不应直接等同于每一起勒索事件的实际入口。

截至本文更新日期，Hyper Backup 在该 PHP2Shell 公告中被列为不受影响。这不表示它保存的备份文件不会被其他恶意程序加密。

二、问题出在哪里：入侵、加密和备份失效

1. 攻击者可能绕过正常登录流程获得执行能力

与部分案例相关的 CVE-2024-10441 位于 DSM 系统插件处理链。其危险之处在于，外部输入经过不安全的分隔符和环境变量处理后，可能影响高权限进程的行为，进一步造成文件写入与代码执行。因此，设置复杂密码或启用多因素认证，并不能替代修补这一类未认证漏洞。

2026 年 9 月披露的 CVE-2026-13639、CVE-2026-13684 则涉及登录逻辑和 SCGI 组件，厂商公布的影响包括任意文件读写与拒绝服务。不同受害设备可能存在不同入口，实际处置应覆盖 DSM、套件和容器，避免只修复其中一层。

2. 加密程序利用合法写入能力破坏数据

获得权限以后，恶意程序可以像普通应用一样遍历目录、读取文件、写入密文和修改文件名。如果它拥有宿主机高权限，影响范围就可能跨越多个共享文件夹和容器目录。

RAID 保护的是磁盘故障下的数据可用性。恶意写入一旦被文件系统接受，阵列会照常保存这些变化。本机备份如果也允许同一账户修改，就可能同时被加密；同步任务还可能把密文或删除操作传播到其他位置。

3. 为什么有些文件能够恢复

已分析的 C3RB3R 样本使用 ChaCha8 处理文件内容，并在文件尾部保存受保护的文件级恢复材料。对于已验证的特定模式，加密进程内存中保留的 32 字节 AES 密钥与 16 字节 IV，可以用于解开相应尾部记录，再取得每个文件自己的密钥。

这就形成了两条不同的恢复路线：拿到匹配密钥后解密文件，或者绕过密文，从快照、备份及 Btrfs 旧数据块找回原始内容。下面按实际条件展开操作。

三、已经中招：按条件选择恢复方案

第一步：停止继续加密，保护尚未受损的数据

先从路由器或防火墙关闭 NAS 的公网访问，覆盖 IPv4、IPv6 和端口映射。暂停 Cloud Sync、Drive ShareSync 等同步任务，并中止可能覆盖健康历史版本的备份任务。仅保留恢复操作需要的可信管理连接。

断网不会停止已经运行的本地加密程序。 如果确认加密由 NAS 本机进程执行，应暂停该进程；如果是电脑通过 SMB 共享写入密文，则应隔离那台电脑并阻断其共享访问。两种情况不能混用同一套处置。

对已经核实的恶意进程，可使用下面的命令。PID 必须替换为实际进程号，不能仅凭一个相似名称操作：

sudo kill -STOP PID

随后检查进程及其线程是否进入 T 状态。D 表示不可中断等待，不能视为已经暂停。不要改用 kill -9 来“保住密钥”，它会结束进程。

如果无法确定加密来源或无法制止持续破坏，应先隔离受影响设备及共享连接；仍不能控制损失时，需要在继续加密与关机丢失内存密钥之间作出取舍。不能为了等待工具，让加密一直运行。

接下来按以下条件分流：

方案 A：有快照或备份，优先恢复历史版本

这通常是最直接的办法。恢复前确认加密已经停止，并准备独立的恢复目的地，例如另一台 NAS、正常电脑或外置磁盘。不要把唯一健康备份重新接到仍在加密的系统上。

使用 Snapshot Replication：

1. 打开“Snapshot Replication → 还原 → 共享文件夹”，选择受影响的共享文件夹。
2. 点击“还原”，选择早于加密发生时间的快照。不要默认选最新一份，因为它可能已经包含密文。
3. 使用“浏览”检查几个关键文件，确认内容正常，再将需要的文件复制到独立存储。
4. 需要恢复整个共享文件夹时，可在确认安全后选择“以新名称克隆”，先验证新共享中的内容。
5. 完成验证后再决定是否恢复原目录。“还原到此快照”会覆盖快照之后的变化，不能直接对唯一原目录试操作。

加密共享文件夹或部分机型可能不支持在线浏览，应使用其支持的克隆或恢复方式验证。现在才开启快照，不能生成攻击发生前的历史版本。

使用 Hyper Backup：

1. 在干净的目标 NAS 上打开 Hyper Backup，选择“还原 → 数据 → 从现有存储库还原”。
2. 指定原来的外置盘、远端 NAS 或云端备份库，选择加密发生前的版本。
3. 先恢复需要的数据目录。受害机的系统配置、未知套件和计划任务，不要整套搬回新系统。
4. 备份启用了客户端加密时，需要原备份密码或密钥文件；缺少它们，不能直接解开备份。
5. 没有备用 NAS 时，可在正常电脑使用 Hyper Backup Explorer 打开其支持的备份库，选择历史版本并导出文件。

备份恢复后，应完整打开重要文件，并对压缩包、数据库及应用数据执行相应检查。文件名恢复正常，只说明导出完成，不代表内容一定正确。

方案 B：没有备份，但加密进程仍在

这条路线适用于与已分析样本相匹配、且仍能取得会话材料的设备。它不提供通用密钥，也不适用于所有勒索变种。恢复过程只围绕提取密钥和解密文件展开。

1. 准备工具与独立磁盘

使用 soimy/c3rb3r-rescue 项目工具。本文参数按 2026 年 10 月 30 日的 ef18b998 提交核对。请在正常电脑上获取对应源码，保持 skills/dsm-ransomware-rescue 目录完整，然后复制到独立外置磁盘。

下面约定：

• NAS 外置磁盘已实际挂载为 /volumeUSB1/usbshare，有足够空间；你的挂载路径不同时必须替换。
• 工具目录为 /volumeUSB1/usbshare/c3rb3r-rescue/skills/dsm-ransomware-rescue。
• NAS 已有 Python 3.8 或更高版本；解密使用的正常电脑具备 Python 3.11 或更高版本。
• 进程已经按前述方法暂停。不要为准备工具重启受害 NAS，也不要在受影响数据卷安装依赖。

如果 NAS 没有合适的 Python，或进程已经退出，本节命令不能直接套用。应保留现有状态，改用已验证适配该设备的内存读取工具，或转入其他恢复方案。

2. 读出解密所需的进程内存

以下命令在 NAS 的受限管理终端执行。先核对外置盘确实已经挂载，避免把数据写进系统分区：

mount
df -h /volumeUSB1/usbshare

TOOL=/volumeUSB1/usbshare/c3rb3r-rescue/skills/dsm-ransomware-rescue
mkdir -m 700 /volumeUSB1/usbshare/recovery

sudo python3 "$TOOL/scripts/capture_process_memory.py" inspect --pid PID

从 inspect 输出取得 start_ticks、exe_sha256 和 readable_bytes，确认全部目标线程处于 T 状态，并确认外置盘空间足以容纳待读取内容。可执行文件必须与工具自带的样本配置匹配；名称相同不能代替这一检查。

然后查询目的目录的设备编号：

stat -c '%d' /volumeUSB1/usbshare/recovery

将下面四个大写占位符分别替换为实际 PID、启动计数、程序摘要和刚查询的设备编号：

sudo python3 "$TOOL/scripts/capture_process_memory.py" capture \
  --pid PID \
  --expected-start-ticks START_TICKS \
  --expected-exe-sha256 EXE_SHA256 \
  --expected-output-device DEVICE_NUMBER \
  --output /volumeUSB1/usbshare/recovery/process-01

process-01 必须是尚不存在的新目录。读取完成后，将整个目录复制到正常电脑；不要只复制其中一个文件。如果出现缺页或部分读取提示，仍可检查解密所需区域是否可用，但不能把部分结果当成已经获得密钥。

3. 在正常电脑提取本次会话的候选密钥

后续步骤均在正常电脑上完成。以源码根目录为当前目录，假设已把 process-01 放在这里：

python3 -m venv .venv
.venv/bin/python -m pip install -r requirements.txt

KIT=skills/dsm-ransomware-rescue
.venv/bin/python "$KIT/scripts/recover_process_key.py" \
  --capture ./process-01 \
  --profile "$KIT/assets/libgld-802ac85d.json" \
  --output ./key-01

成功时会生成 key-01/master-candidate.bin。它是需要验证的候选材料，不是“恢复成功”的证明。工具会检查程序摘要、代码布局和运行模式；若提示样本不匹配、关键页面缺失或主指针为空，应停止使用这套配置，不要删掉检查强行继续。

以上为 Linux/macOS 命令形式。Windows 的虚拟环境 Python 通常位于 .venv\Scripts\python.exe，应按实际终端调整路径。

4. 先解密一份文件副本

在正常电脑的工作目录创建 copies 和 restored 两个目录，将一份密文实际复制到 copies。不要使用硬链接、符号链接，也不要直接指向 NAS 原目录。

先检查它的尾部结构：

.venv/bin/python "$KIT/scripts/inspect_footer.py" \
  --input-copy ./copies/example.tar.L0CK3D

如果工具确认是受支持布局，记录输出中的 marker。将下面的 SESSION_MARKER 替换为该文件的 8 位十六进制标记：

.venv/bin/python "$KIT/scripts/decrypt_copy.py" \
  --copy-root ./copies \
  --input-copy ./copies/example.tar.L0CK3D \
  --master-file ./key-01/master-candidate.bin \
  --expected-marker SESSION_MARKER \
  --output ./restored/example.tar

输出文件必须尚不存在。如果手上有加密前同一版本文件的 SHA-256，可增加 --expected-sha256 原文件摘要，让工具直接核对完整结果。

首次验证至少选择几份不同类型和大小的文件。确认内容正常后，再按匹配的会话材料逐文件扩大恢复范围。不同会话可能需要不同密钥；不能因为一张图片恢复成功，就认定整台 NAS 都适用。

5. 按报错决定下一步

方案 C：拿不到密钥，检查 Btrfs 旧数据块

如果没有健康副本，也没有可用密钥，Btrfs 数据卷仍可能保留部分加密前的内容。它的写时复制机制可能把密文写到新位置，让旧数据范围继续留在磁盘上。能否恢复，取决于旧块是否仍在、引用关系是否完整，以及文件被覆盖的范围。

先在“存储管理器 → 存储空间”确认文件系统类型。此路线不适用于 ext4，也不能仅凭“用了 Btrfs”就认定有救。

具体处理顺序是：

1. 停止对受影响存储池的非必要写入。不要清空回收站、删除密文、删除快照或执行磁盘整理。
2. 准备容量足够的独立输出磁盘；同一存储池上的另一文件夹或另一卷不算独立目标。
3. 使用匹配环境的 Btrfs 恢复工具，对一份文件先做文件布局与旧块映射检查。社区工具 crt106/c3rb3r-btrfs-recovery 提供此类能力，但要核对其支持的阵列、压缩与文件处理模式。
4. 只导出能够建立有效映射的候选文件，再做完整内容检查。有正常原件的文件，优先用来验证恢复结果。
5. 小范围结果可靠后再扩大处理，始终把输出写到独立磁盘。

这条路线不是运行 btrfs check --repair。结构修复不能解开勒索密文，盲目修改文件系统反而可能减少可恢复内容。不同 DSM 的 SHR、LVM 和缓存布局不同，不能随意选择一个底层磁盘设备执行通用命令。

如果旧数据块已经被重用、覆盖或丢弃，同时也没有密钥和其他副本，现有条件下就没有可靠的通用恢复办法。 此时应保留尚存密文，继续寻找电脑、手机、云盘历史版本及离线磁盘上的原件；代码项目还可以从开发机的本地仓库找回已存在的提交。

四、数据恢复以后，怎样修复系统并避免再次被加密

恢复文件与恢复服务之间，还需要完成以下工作。否则，刚找回的文件可能再次被破坏。

1. 在干净环境重新部署服务

优先使用另一台设备或新的系统环境安装 DSM 与必要套件，并将版本更新到适用的安全版本。旧系统里的未知脚本、计划任务、可执行程序和完整配置，不要直接复制回来。

只有在恢复结果验证通过、且已经有独立副本后，才安排原设备的重装或重新初始化。不要把格式化存储池当作恢复数据的第一步。

如果只能使用原 NAS，应先把恢复出的数据转移到独立存储，再按机型支持的重建方式处理系统。仅删除勒索信或一个可疑文件，无法确认系统已经清理干净。

2. 更新密码、令牌和访问权限

从正常电脑修改 NAS 管理密码，撤销不再需要的会话、SSH 公钥、API 令牌和备份访问凭据。日常文件访问与系统管理应使用不同账户，容器只挂载它真正需要的目录。

应用内部用于解开历史业务数据的密钥，需要按应用要求保留或迁移，不能直接当作普通登录密码删除。例如 GitLab 恢复仍需要原有 secrets，随后才能处理相关凭据。

3. 应用数据按完整业务恢复

以 GitLab 为例，应先在隔离的新实例安装与备份完全相同的版本和 CE/EE 类型，恢复必要 secrets，再导入备份并检查项目、仓库、LFS、附件和制品。

恢复过程中先停用邮件、Webhook 和 Runner，避免测试实例发出通知或执行生产任务。完成真实登录、clone 和关键文件读取后，再按支持的升级路径更新，最后恢复对外服务。

4. 用明确标准验收结果

五、尚未中招的设备，立即完成这些加固

更新分三层做。 在“控制面板 → 更新和还原”更新 DSM；在“套件中心”分别更新 PHP、Mail Station、Calendar 等套件；容器应用则更新其镜像和内部依赖。宿主机升级不会自动替换容器里的旧软件。

收紧实际入口。 删除不必要的路由器端口映射，关闭不需要的 UPnP 自动映射，核对 IPv6 防火墙，并检查反向代理与隧道入口。DSM 管理、SSH 和文件共享应限制到可信网络或受控远程访问通道。多因素认证用于降低账户被盗风险，不能替代漏洞修复。

让备份保留独立恢复能力。 生产数据之外，至少保留两个备份副本，采用不同存储介质，并将其中一份放到异地。针对勒索，应进一步使用离线轮换或适用的不可变保留策略，同时隔离删除权限。设备支持不可变快照时，还要确认锁定期和保留策略真正生效。

定期实际恢复一次。 在新目录或新设备上恢复指定日期的数据，确认文件、数据库和必要密钥都能使用。备份任务显示“成功”，只说明任务完成；恢复演练才能证明这些数据在需要时确实可用。