最近，群晖 NAS 遭遇勒索攻击的消息引起了不少用户关注。

在 GitHub 上，陆续有受害者公开自己的设备情况和取证记录。受影响的文件出现 .L0CK3D 后缀，目录中还出现了 read-me3.txt 勒索说明文件。部分用户发现，原本保存的重要照片、视频和业务文件已经无法正常打开。

ChatGPT 图像 2026年10月30日 09_07_45-1.png

面对这种情况，很多人的第一反应是重启 NAS、重新安装系统，或者尝试使用网上找到的解密工具。

但实际上，如果 NAS 已经遭遇勒索攻击，第一时间的处理方式可能直接影响后续的数据恢复机会。

近期，一个名为 c3rb3r-rescue 的 GitHub 项目收集了多个真实受害者的恢复案例。目前已经出现了几条不同的恢复路线：

从仍在运行的勒索进程内存中提取解密密钥。
利用 Btrfs 写时复制机制找回部分原始数据。
通过历史快照和独立备份恢复文件。

下面结合这些实际案例，整理具体的处理步骤、工具和注意事项。

一、发现 NAS 被勒索，第一时间应该怎么处理？

这一步非常重要。不要急着重启 NAS，也不要直接删除加密文件。

第一步：检查勒索进程是否仍在运行

通过 SSH 登录群晖 NAS，检查是否存在已经从磁盘删除、但仍被进程引用的可执行文件：

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

如果发现可疑进程，需要进一步检查进程信息：

ps aux
cat /proc/PID/cmdline
cat /proc/PID/status
ls -l /proc/PID/exe

其中 PID 需要替换为实际检查到的进程编号。

重点确认：

进程是否属于本次勒索程序。
可执行文件是否已经被删除。
进程是否仍在执行文件加密。
是否存在多个相关进程。

注意，grep deleted 只是排查线索，并不能直接证明某个进程就是勒索程序，需要结合程序路径、哈希、命令行和线程状态判断。

第二步：根据进程状态采取不同措施

**情况 A：恶意加密进程仍然存活**

优先保留内存

不要直接 kill -9。
不要重启或关机。
由专业人员确认进程后，使用 SIGSTOP 暂停。
检查所有线程是否已经进入 T（Stopped）状态。
尽快采集进程内存及相关样本。

**情况 B：恶意加密进程已经退出**

转向其他恢复路线

保留现有内存和磁盘现场。
停止向受影响数据卷写入的服务。
不删除 .L0CK3D 文件。
检查文件系统类型。
评估 Btrfs 历史数据块恢复、快照和备份。

如果已经确认是目标勒索进程，并且具备专业取证条件，可以使用：

kill -STOP PID

然后检查：

grep State /proc/PID/status

确认进程及其线程已经暂停。

这里特别提醒：SIGSTOP 是暂停进程，不是结束进程。不要将其替换成 kill -9。

第三步：停止不必要的数据写入

如果准备尝试 Btrfs 底层数据恢复，应尽快停止会持续修改受影响数据卷的服务。

例如：

Synology Photos
Synology Drive
Cloud Sync
Download Station
Surveillance Station

群晖可以通过套件管理命令进行控制：

sudo /usr/syno/bin/synopkg stop 套件名称

具体包名需要以设备实际安装的套件为准，不要直接批量复制执行。

特别注意：不要删除加密文件，不要执行 Btrfs balance、碎片整理或空间回收，也不要把恢复结果写回原始数据卷。

二、方法一：从进程内存中提取解密密钥

已有物理 NAS 成功案例

这是 c3rb3r-rescue 项目最初验证的恢复方法。

它的核心思路是：勒索程序运行时，可能将解密所需的主密钥保存在进程内存中。如果进程还没有退出，相关材料可能仍然存在。

具体操作流程

1. 确认恶意进程

记录 PID、启动时间、可执行文件 SHA-256 和线程状态，确认目标程序与已分析的勒索样本匹配。

2. 暂停恶意进程

在确认目标进程后，通过 SIGSTOP 暂停，避免它继续加密文件，同时尽可能保留内存现场。

3. 采集进程内存

项目提供了 capture_process_memory.py，用于采集指定进程的可读取内存区域。

在经过兼容性检查的取证环境中，基本调用形式如下：

python3 capture_process_memory.py inspect --pid PID

检查完成后，再按照项目文档要求，提供进程启动标识、程序 SHA-256 和独立取证介质信息进行采集。

4. 提取密钥材料

将采集结果转移到独立分析环境，使用：

recover_process_key.py

结合对应的恶意程序样本和分析配置，定位主密钥候选。

本次项目涉及的主材料为 48 字节：

16 字节 IV。
32 字节 AES Key。

5. 验证密钥并解密副本

使用 decrypt_copy.py 对独立复制出来的加密文件进行解密。

先选择有完好原始副本的文件进行验证，确认 SHA-256 或逐字节内容一致，再考虑扩大恢复范围。

这里不能直接使用其他受害者公开的密钥。不同攻击会话可能使用不同的主密钥，文件尾部的会话标记也可能变化。

实际案例：物理群晖 DS920+ 成功恢复

GitHub Issue #14 提供了一份非常有价值的实机报告。

设备信息：

项目	配置
型号	Synology DS920+
系统	DSM 7.2.2-72806
内存	8GB
内核	Linux 4.4.302+

用户发现攻击时，勒索进程仍然存活。经过暂停进程和内存采集，最终找到了 48 字节的密钥候选。

恢复结果：

两个文件成功恢复。
两个文件的 SHA-256 均与原始文件完全一致。
覆盖 0x25 和 0x26 两种加密模式。
另一个 PDF 文件通过格式验证，但没有原始文件可进行完整对照。

这说明内存密钥恢复已经有真实物理 DSM 设备上的成功记录。

案例地址：

https://github.com/soimy/c3rb3r-rescue/issues/14

另外，还有一位受害者将这套方法应用于物理 DS918+，在进程仍然存活时提取密钥，并报告恢复约 8.45 万个文件、约 940GB 数据。

独立案例：

https://github.com/Benjamin-zlt/c3rb3r-baremetal-rescue

方法二：利用 Btrfs 写时复制恢复原始数据

已有独立恢复工具及实战报告

如果发现攻击时，勒索进程已经退出，内存中可能已经找不到解密密钥。

这时候可以进一步检查 NAS 的文件系统。

在 GitHub Issue #12 中，一位受害者没有找到有效密钥，但发现数据卷使用的是 Btrfs，于是尝试从文件系统底层恢复原始数据。

1. 先确认数据卷是否为 Btrfs

通过 SSH 检查：

mount | grep volume1

进一步检查：

btrfs filesystem show /volume1
btrfs subvolume list /volume1

确认实际挂载设备、文件系统类型和子卷结构。

如果使用的是 ext4，就不能直接套用这套 Btrfs 恢复方法。

2. 为什么 Btrfs 有机会恢复数据？

Btrfs 具有写时复制（Copy-on-Write，CoW）机制。

简单理解：

当文件被修改时，Btrfs 会为修改后的数据分配新的存储位置。原来的数据块如果仍然被其他未修改的数据引用，就不会立即释放。

因此，如果勒索程序只加密了文件的一部分，原始数据块可能仍然保留在磁盘上。

专业人员可以通过分析文件系统树和 extent 引用，定位攻击发生前的数据块，读取原始内容，再与当前文件中保留的明文部分拼接。

恢复原理示意

ChatGPT 图像 2026年10月30日 09_07_50-3.png

3. 实际操作需要哪些工具？

这个过程不是简单执行一个恢复命令，而是需要依次分析文件系统元数据。

项目公开的操作流程包括：

步骤	工具	用途
1	`collect_footers.py`	统计加密文件尾部信息及加密模式
2	`btrfs-find-root`	查找历史文件系统树节点
3	`btrfs restore`	尝试从历史树节点恢复文件
4	`walk_tree.py`	遍历当前 Btrfs 文件系统树
5	`parse_leaves.py`	分析历史叶子节点
6	`make_jobs2.py`	生成旧数据块恢复任务
7	`extract_jobs.py`	读取旧 extent 并拼接文件
8	`verify_restored.py`	检查恢复文件的基本完整性

实际执行时，需要先确认 Btrfs 底层逻辑卷、子卷 ID、节点大小、chunk 映射及 RAID 布局。

例如，项目案例中，直接对已挂载的 cachedev 设备运行 btrfs restore 会被拒绝，最终改为对底层逻辑卷进行只读分析。

恢复文件则统一写入另一个存储卷。

完整命令、参数和操作顺序可以参考独立恢复项目的操作手册：

https://github.com/sunkangbo121-ship-it/c3rb3r-btrfs-extent-rescue/blob/main/docs/00-runbook.md

注意：这是一套针对特定 DSM/Btrfs 存储布局验证的研究工具，不支持所有 Btrfs RAID 类型。普通用户不应直接将其中的设备路径和命令复制到自己的 NAS 上执行。

4. 实际案例：没有密钥，最终恢复约 274GB 数据

这次独立案例的设备是使用 Btrfs 的黑群晖实体机。

用户发现攻击时，勒索进程已经退出。整机内存采集后仍然没有找到密钥。

但通过分析文件尾部的加密模式，发现大量文件实际上只进行了部分加密。

最终恢复报告：

项目	数量
受影响文件	24,142 个
完整恢复文件	17,893 个
恢复比例	74.1%
恢复数据量	约 274GiB
原始目标数据	约 375GiB

其中，前段加密和分段加密的文件恢复效果较好，而整文件加密的小文件大部分无法恢复。

另一位受害者也在 Issue #12 中补充了自己的照片恢复结果：

处理 684 张照片。
完整恢复 386 张。
未恢复 298 张。
恢复数据约 1.32GB。
386 张照片通过完整 JPEG 解码。

其中一张照片还找到了原始文件作为对照，解码像素逐个一致。

需要注意，上述照片案例和 274GiB 案例是不同用户的报告，不能将两组数据合并。

案例地址：

https://github.com/soimy/c3rb3r-rescue/issues/12

独立恢复工具：

https://github.com/sunkangbo121-ship-it/c3rb3r-btrfs-extent-rescue

方法三：利用历史快照和独立备份

如果没有找到密钥，也不满足 Btrfs 底层恢复条件，仍然需要检查现有快照和备份。

具体可以按照以下顺序：

1. 检查历史快照

查看攻击发生之前的快照时间点，尝试读取其中的照片、视频和文档。

2. 检查快照是否受到影响

不要只看快照列表是否存在，还要实际读取文件，确认内容是否正常。

3. 检查其他备份设备

例如：

其他 NAS 上的备份。
USB 外接备份硬盘。
云端历史版本。
其他独立存储设备。

4. 恢复到独立存储位置

不要直接覆盖原始受灾数据。先将可用数据恢复到其他设备，再进行完整性检查。

这里还有一个实际案例值得关注。

Issue #6 中，一台 DS1821+ 遭遇勒索攻击时，勒索程序因为内存耗尽被 Linux OOM Killer 终止，最终留下了部分加密的文件。

由于攻击程序没有继续运行，原有快照也没有被这次加密过程破坏，用户最终通过快照恢复了数据。

案例：

https://github.com/soimy/c3rb3r-rescue/issues/6

恢复过程中需要特别注意什么？

结合这些受害者的真实反馈，以下几点尤其重要。

1. 没有重启，不代表一定能恢复内存密钥。

Issue #9 中，一台 NAS 连续运行了 149 天，攻击期间也没有重启，但由于发现时加密进程已经退出，最终扫描约 13.5GiB 内存仍然没有找到密钥。

真正重要的是恶意进程是否还存活，以及密钥是否仍然存在于内存中。

2. 不要使用其他受害者的公开密钥直接解密。

Issue #5 中，用户使用公开候选尝试解密三个文件，全部失败。

不同攻击会话可能使用不同的密钥和标记，即使文件后缀相同，也不代表密钥通用。

3. 不要删除 .L0CK3D 原始文件。

尤其是 Btrfs 恢复路线，原始文件可能仍然保留着指向旧数据块的引用。删除文件可能进一步破坏恢复条件。

4. 不要在原始卷上进行恢复写入。

内存取证、文件系统分析和恢复结果保存应尽可能分离。恢复结果写入其他存储设备，原始密文保留。

5. 不要把文件能够打开当成完整恢复。

尽可能使用历史 SHA-256 对比；没有原始摘要时，也要进行完整格式解码、归档校验及实际应用验证，并明确标注恢复等级。

6. 数据恢复成功不代表 NAS 已经安全。

恢复数据后，还需要重新检查账号、计划任务、启动项、SSH 密钥、异常服务和外部访问入口。必要时在可信环境中重建系统并轮换凭据。

QNAP 用户应该如何预防？

虽然这次公开的 C3RB3R 勒索事件主要涉及群晖设备，但 QNAP 用户同样需要注意。

不同系统的文件系统和安全机制有所区别：

系统	常见文件系统	Btrfs extent 恢复能否直接使用
QTS	ext4	不适用
QuTS hero	ZFS	不适用
群晖部分数据卷	Btrfs	满足条件时可以研究

因此，QNAP 用户不能直接照搬上述 Btrfs 恢复脚本，日常防护才是重点。

ChatGPT 图像 2026年10月30日 09_07_51-4.png

1. 减少公网暴露

不要将 NAS 管理界面、SMB 等服务直接开放到互联网。

检查路由器端口映射和 UPnP，关闭不必要的公网入口。需要异地访问时，优先使用 VPN 等受控方式。

2. 做好快照和版本管理

根据业务数据的重要程度设置快照计划及保留周期。

支持快照的设备，可以结合快照保护和 HBS 3，将重要数据备份到其他 NAS、外部存储设备或云端。

特别注意：不要把所有备份都放在生产 NAS 上，尽量保留独立、离线或不可变的备份副本。

3. 注意 Docker 容器权限

对于使用 Container Station 的用户，不要随意开启 privileged 特权模式。

同时谨慎配置宿主机目录映射，尤其是：

宿主机根目录。
Docker Socket。
系统配置目录。
包含重要业务数据的目录。

容器并不是绝对安全的隔离环境。如果容器内的应用被攻破，过高的运行权限可能进一步扩大影响范围。

4. 及时更新系统及应用

定期检查 QTS / QuTS hero 固件更新，以及 App Center 中已安装应用的更新情况。

第三方 Docker 镜像也需要关注上游安全更新，不能只更新 NAS 系统而忽略容器内部的软件组件。

5. 不要只依赖 NAS 本机日志

有针对性的攻击者可能会清理本机日志、计划任务和恶意程序。

对于重要业务环境，可以将日志发送到独立设备进行保存，并定期检查异常登录、账号权限和系统服务。

最后，定期进行备份恢复测试，确认数据真的可以恢复，而不是仅仅看到备份任务显示成功。

项目及案例资料

如果希望进一步研究这次勒索事件，可以参考以下公开资料：

主项目：
https://github.com/soimy/c3rb3r-rescue

物理群晖 DS920+ 内存恢复案例：
https://github.com/soimy/c3rb3r-rescue/issues/14

Btrfs 无密钥恢复案例：
https://github.com/soimy/c3rb3r-rescue/issues/12

Btrfs 独立恢复工具：
https://github.com/sunkangbo121-ship-it/c3rb3r-btrfs-extent-rescue

物理机内存恢复案例：
https://github.com/Benjamin-zlt/c3rb3r-baremetal-rescue

写在最后

这次公开的受害者案例说明，NAS 遭遇勒索攻击后，并不意味着所有数据都已经彻底无法恢复。

如果恶意进程仍然存活，可以尝试保留进程内存并寻找解密材料；如果使用 Btrfs 且原始数据块仍然保留，也可能通过文件系统底层恢复部分数据；此外，历史快照和独立备份仍然是重要的恢复渠道。

但这些方法都有严格的适用条件，不能保证每次攻击都能成功。

目录CONTENT

全网群晖NAS被勒索中招。千万别乱动，也许还有救！

高速稳定 · 海外专线