群晖 NAS 中勒索病毒自救手册

—— 基于一次 170TB 真实救援的全程实录（C3RB3R / .L0CK3D）

这不是理论文章。文中每一个数字、每一条命令、每一个"坑"，都来自一次真机救援： 群晖 SA6400（DSM 7.2.1，ARPL 引导）、三块 Btrfs 卷共约 170TB、古籍扫描件为主。 2026-10-28 凌晨中招，10-30 完成止损与部分抢救。 凡文中标注 [实测] 的，均为本次真机验证过的结论；标注 [引用] 的，来自公开项目文档。

序：先记住这四句话

如果只看一段，就看这段：

1. 没重启之前，绝对不要重启。 这是你唯一能 100% 拿回全部数据的窗口。

2. 不要付赎金。 付了未必解，而且是在资助犯罪。

3. 不要删 .L0CK3D 文件。 它是未来唯一可能完整还原的希望。

4. 真正的入口在路由器，不在 NAS。 只封 NAS 是治标。

第一章 黄金 5 分钟：发现中招后立刻做什么

1.1 先确认是不是 C3RB3R（.L0CK3D）

典型特征 [实测]：

• 文件被加上后缀 .L0CK3D（如 xxx.pdf.L0CK3D）

• 每个共享文件夹根目录出现勒索信 read-me3.txt

• 勒索信内容是 Tor 暗网链接 + "每个文件可免费试解一个"的话术

ls -la /volume1/read-me3.txt
find /volume1 -maxdepth 3 -name '*.L0CK3D' | head -5

1.2 生死判定：加密进程还活着吗？

这一步决定你走哪条路，是整个救援的分水岭。

# ① 找"可执行文件已被删除但仍在运行"的进程 —— 勒索程序最常见的藏身方式
ls -l /proc/*/exe 2>/dev/null | grep deleted

# ② 看有没有 CPU 异常占用的进程（加密是 CPU 密集型）
ps aux --sort=-%cpu | head -15

• 有输出 / 有高 CPU 进程 → 恭喜，你还在"黄金窗口"内，有机会 100% 全量解密（见 2.2）

• 没有 → 密钥已随进程销毁，只能走"部分抢救"路线（见 2.3）

本次案例中，受害者在中招后重启过机器，密钥彻底丢失，因此只能走部分抢救。 这是最痛的一步，也是本手册反复强调"别重启"的原因。

1.3 正确做法 vs 致命错误

关于"冻结"而非"杀死"：

# 冻结（保留内存，进程暂停，密钥仍在）
kill -STOP <PID>

# 千万不要用 kill -9

第二章 四条恢复路径（按优先级排序）

2.1 路径一：快照 / 备份回滚 —— 最干净，先查这个

群晖自带的 Snapshot Replication 和 Hyper Backup 是唯一能 100% 还原（连小文件都不丢）的手段。

# 看有没有快照子卷
sudo btrfs subvolume list /volume1
# 看 @sharesnap 里有没有内容
sudo ls -la /volume1/@sharesnap

[实测]：本次案例中 @sharesnap 里只有空的目录壳和一份勒索信，subvolume list 无任何历史快照 → 这条路断了。如果你开了快照且有一个"攻击前"的快照点，直接回滚，后面的都不用看了。

⚠️ 注意：勒索软件往往会先删除快照再加密。所以"我好像开过快照"不等于"快照还在"。

2.2 路径二：内存提取会话主密钥 —— 100% 全量解密（前提是进程还活着）

原理[引用 + 交叉验证]：

勒索软件给每个文件随机生成一把 ChaCha8 密钥加密内容，再用一把**「会话主密钥」**把文件密钥包起来。这把主密钥就躺在加密进程的内存里。

• 密钥长度：48 字节

• 参考项目：Benjamin-zlt/c3rb3r-baremetal-rescue（GitHub）

• 公开案例：有受害者用 AI + SSH 权限，从 /proc/<PID>/mem 导出内存、提取主密钥，一次解开 8.45 万个文件 / 940GB

⚠️ 最关键的一点（很多人误解）：

每一轮运行都会生成一把全新的会话主密钥，且只能解开那一轮加密的文件。

打个比方：每轮加密 = 换一把新锁 + 配一把新钥匙。上一轮的钥匙在进程退出时就销毁了。

所以：

• 进程活着 → 取出本轮密钥 → 解开本轮加密的全部文件（100%）

• 进程已死 / 已重启 → 那把钥匙永远没了，重跑程序只会生成一把新钥匙，开不了旧锁

2.3 路径三：明文区雕刻 —— 无密钥也能救回大部分（本案例主力方案）

勒索软件为了速度，对大文件只加密一部分。剩下的明文原封不动留在磁盘上。

加密模式对照表[实测，来自 l0ck3d_recovery.py 源码]：

>5MB 文件的三段加密位置[实测]：

(0%, 4%)      ← 头部
(48%, 52%)    ← 中部
(96%, 100%)   ← 尾部

不同格式的实际效果[实测，本次 4 个库全量跑完的数字】：

最反直觉的一条：文件越大越容易救，文件越小越没救。 本次案例中 A002 库的 1878 个 txt/md 文章全部 ≤1MB，可救数为 0——文字内容 100% 丢失。

操作思路（供有能力的读者参考）：

1. 解析 .L0CK3D 尾部 588 字节元数据，读出原始大小 orig 和加密模式

2. 算出明文段位置

3. 在明文段内按 FFD8FF（JPEG 起始）…FFD9（结束）雕刻出完整图片

4. 把图片按 DCTDecode 直接嵌入重组为 PDF（不重压缩，画质零损失）

参考工具：hongjiahao371-pixel/L0CK3D-Recovery（l0ck3d_recovery.py）

[实测] 本案例战果：B001 科举文献库 3668 个 PDF → 救回 325,594 张页面图 → 重组 2039 本 PDF。 但每本恒定缺 2 页（中部和尾部各有一张图跨在加密段边界上被切断），数据保全率 91%。

2.4 路径四：Btrfs 旧数据块恢复 —— 理论 100%，但门槛极高

Btrfs 是写时复制（CoW）文件系统，被覆盖的旧数据块可能还残留在磁盘上。

前提条件（缺一不可）：

1. 必须先做只读块级镜像，不能在原盘上直接挖

2. 需要等同于卷总容量的空闲存储空间

3. 卷挂载参数不能带 auto_reclaim_space（否则系统一直在回收旧块）

[实测]：本案例这条路的死因

三个卷各 70TB，共约 210TB
剩余空闲：14T + 16T + 16T = 约 46TB
→ 做镜像需要 210TB，只有 46TB，差 4 倍多，硬件层面就堵死了

更要命的是，三个卷挂载参数都带 auto_reclaim_space：

mount | grep volume
# /dev/mapper/cachedev_0 on /volume3 type btrfs (rw,...,auto_reclaim_space,...)

这意味着每多开一分钟，能恢复的旧块就少一点。 如果确定要走这条路，第一件事是停机。

参考工具：crt106/c3rb3r-btrfs-recovery、新版 btrfs-progs 的 btrfs-find-root + btrfs restore

⚠️ 群晖自带的 btrfs-progs 往往是 2014 年的 v4.0，对 dm 设备跑 btrfs-find-root 没输出。 要走上这条路基本得拆盘接到新版 Linux 或找专业取证机构。

第三章 五个致命误区（很多人正在踩）

误区 1："让勒索程序再跑一次，趁它加密时抓内存拿密钥"

❌ 错。 重跑只会生成一把全新的会话主密钥，它只能解开新一轮要加密的文件，打不开上一轮已经锁死的文件。

而且后果是三重：① 拿不到能用的老密钥；② 立刻开始加密你那些还完好的文件；③ 新写入的数据覆盖 Btrfs 旧块，把未来深度恢复的可能也毁掉。

误区 2："把那个程序逆向分析一下，就能拿到私钥"

❌ 错。 它用的是标准的"非对称 + 对称"混合方案：

文件内容 ──ChaCha8 随机密钥──> 密文
随机密钥 ──攻击者内置的 RSA-2048 公钥──> 加密后存在文件尾部

你分析样本只能拿到公钥（本来就在里面）。私钥永远在攻击者手里，数学上公钥推不出私钥。

成功案例能成功，唯一原因是进程当时还活着、内存里有那一次会话的主密钥——不是破解了私钥。

误区 3："把病毒清干净了，文件是不是就能解开了？"

❌ 错。清毒 ≠ 解密。

清病毒 = 换锁防下次；解密 = 配钥匙开旧锁。

那把钥匙在加密进程退出时就被销毁了，跟病毒现在在不在、清没清，一点关系都没有。

（清毒当然要做，但目的是保护还没被加密的文件，不是为了解密。）

误区 4："网上说能救回 88%，那我所有文件都能救回 88%"

❌ 错。88% 只适用于 >5MB 的 PARTLY 模式文件。

≤1MB 的文件是 FULL 模式整体加密，救回率是 0。如果你的数据以文档、照片、小文件为主，这个数字会让你空欢喜一场。

先统计再动手：

# 按大小分档统计，判断你的数据属于哪一档
find /volume1/xxx -name '*.L0CK3D' -size +5M | wc -l    # PARTLY，可救 88%
find /volume1/xxx -name '*.L0CK3D' -size +1M -size -5M | wc -l  # HEADER，部分
find /volume1/xxx -name '*.L0CK3D' -size -1M | wc -l    # FULL，0%

误区 5："把 .L0CK3D 删了重新下载/重新整理就行"

❌ 别急着删。 历史上多个勒索家族在私钥泄露或服务器被端后，推出了官方免费解密器（GandCrab、Babuk、部分 REvil 版本）。

文件留着，那天来了就能完整还原；删了就再无可能。而且删除会写 Btrfs 元数据，可能覆盖旧数据块。

正确做法：移到隔离目录，保留观察，别直接删除。

第四章 止血：安全加固实操

以下 [实测] 命令均在本次救援中真机执行并验证过。

4.1 先排查有没有后门

# 已删除 exe 的潜伏进程
ls -l /proc/*/exe 2>/dev/null | grep deleted

# 计划任务（群晖用这个，不是 crontab -l）
sudo /usr/syno/bin/synoschedtask --get

# crontab
sudo crontab -l
sudo ls -la /etc/cron.d

# SSH 后门公钥
sudo ls -la /root/.ssh

# 开机自启
ls -la /usr/local/etc/rc.d/  /etc/rc.local

# 异常外连
sudo netstat -tunp | grep -v '127.0.0.1'

# 排查 10/27-10/29 有没有新增的可执行文件（改日期为你自己的）
sudo find /usr/bin /usr/sbin /bin /sbin -type f -newermt '2026-10-27' ! -newermt '2026-10-30' | head -20

[实测] 本次结果：加密进程已不在、无 deleted exe 进程、计划任务干净、/root/.ssh 不存在、rc.d 全空、近期无新增系统可执行文件。病毒本体已自我销毁。 磁盘上只剩勒索信（纯文本，无害）。

我没有删勒索信——删文件会写 Btrfs 元数据，留作证据更安全。

4.2 关闭 telnet（23 端口）

[实测]：本次发现 23 端口（telnet）被 4 个 inetd 兄弟进程共享监听开着，而群晖默认 telnet 是关闭的——这是残留的可疑入口，还完好的十几万文件都暴露在它面前。

# 终止全部 inetd
sudo sh -c 'for p in $(ps -e | grep inetd | awk "{print \$1}"); do kill -9 $p 2>/dev/null; done'

# 验证
sudo netstat -tlnp | grep ':23 ' || echo "✓ 23端口已关闭"

4.3 启用防火墙（黑群晖特别注意！）

[实测] 最大的坑：ARPL 等黑群晖的内核默认没加载 netfilter 模块，iptables 形同虚设（执行报 iptables who?）。要先手动加载：

sudo modprobe ip_tables
sudo modprobe iptable_filter

# 验证
sudo iptables -L -n

然后加规则（群晖真正的 INPUT 链名是 DEFAULT_INPUT）：

# 允许内网
sudo iptables -A DEFAULT_INPUT -s 192.168.10.0/24 -j ACCEPT
# 拒绝外网访问管理端口
sudo iptables -A DEFAULT_INPUT -p tcp --dport 22   -j DROP
sudo iptables -A DEFAULT_INPUT -p tcp --dport 23   -j DROP
sudo iptables -A DEFAULT_INPUT -p tcp --dport 5000 -j DROP
sudo iptables -A DEFAULT_INPUT -p tcp --dport 5001 -j DROP
sudo iptables -A DEFAULT_INPUT -p tcp --dport 445  -j DROP
sudo iptables -A DEFAULT_INPUT -p tcp --dport 139  -j DROP

4.4 加固 SSH

[实测] 两个坑：

• 群晖的 sshd 二进制在 /usr/bin/sshd（不是 /usr/sbin/sshd），路径写错会导致配置校验失败

• 全局参数必须插到文件开头（sed -i '1i ...'），追加到末尾会落进 Match 块而失效

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

sudo sed -i '1i PermitRootLogin no'          /etc/ssh/sshd_config
sudo sed -i '1i PermitEmptyPasswords no'     /etc/ssh/sshd_config
sudo sed -i '1i MaxAuthTries 3'              /etc/ssh/sshd_config
sudo sed -i '1i LoginGraceTime 30'           /etc/ssh/sshd_config
sudo sed -i '1i X11Forwarding no'            /etc/ssh/sshd_config

# 校验（必须先校验，否则可能把自己锁在外面）
sudo /usr/bin/sshd -t

# 平滑重载（不断开当前连接）
sudo kill -HUP $(pidof sshd | awk '{print $1}')

4.5 让加固重启后仍生效

把上面的动作写成脚本 /usr/local/etc/rc.d/security_harden.sh（关 telnet + modprobe + 恢复规则 + 重启监控），并加一条 crontab 兜底：

@reboot root /bin/sh /volume3/rescue/security_backup/boot_harden.sh

4.6 部署实时监控（防止二次加密）

写个守护脚本，每 15 秒扫一次：一旦发现隐藏进程或新增 .L0CK3D，立刻 kill -STOP 冻结并记日志。

提醒：监控抓到的新一轮密钥，只能解新一轮的文件。它的价值是止损，不是恢复旧数据。

4.7 ⚠️ 最关键的一步：路由器

[实测]：本次日志里没有任何暴力破解痕迹——说明对方是拿着凭据直接进来的。

NAS 是内网 IP（192.168.10.28），公网能访问它，全靠路由器的端口映射/UPnP/DMZ。

只封 NAS 不够，映射不关，攻击者照样敲门。

必须做：

1. 路由器关闭端口映射（虚拟服务器）

2. 关闭 UPnP

3. 关闭 DMZ

4. 验证：手机关 WiFi 走 4G，访问你原来的外网地址，打不开才算封住

5. DSM 开启两步验证（2FA）

6. 所有账号改密码（中招期间用过的密码一律视为已泄露）

7. 关闭 QuickConnect（如不需要）

长期隐患：黑群晖收不到官方 DSM 安全补丁。数据处置完后，建议重做官方系统或彻底禁止公网访问。

第五章 抢救实操要点（写给要动手的人）

5.1 三条铁律

1. 产出绝对不要写回中毒卷（会覆盖可恢复的旧块）→ 写到另一块盘，或至少写到独立卷

2. 先小样本验证，再全量跑 → 我第一次全量跑就因为格式判断错误白跑了半小时

3. 先看文件类型再选方法 → 用 JPEG 雕刻的方法去处理单张 JPG，结果接近 0

5.2 先做格式分诊（不要一上来就全量跑）

# 类型分布
find /volume2/xxx -name '*.L0CK3D' | sed 's/\.L0CK3D$//' | awk -F. '{print tolower($NF)}' | sort | uniq -c | sort -rn | head

# 大小分档
find /volume2/xxx -name '*.L0CK3D' -size +5M | wc -l
find /volume2/xxx -name '*.L0CK3D' -size -1M | wc -l

5.3 效果自查（避免白跑）

跑完对一下产出大小 / 原始占用。本次四个库的真实救回率：

5.4 让成果可见（群晖特有大坑）

[实测]：产出写在 /volume3/_rescue 这种卷根目录下的普通目录时，DSM 的 File Station 和 Windows 网上邻居里根本看不到——它们只显示"共享文件夹"。

必须注册为共享文件夹：

# 注意：① rw 位要填 na（填空串会报 Share path is invalid）
#      ② 目标目录必须不存在，让群晖自建（已存在报 0xE700）
#      ③ 目录名不能以下划线开头（_rescue 会被拒）
sudo /usr/syno/sbin/synoshare --add rescue "抢救成果" /volume3/rescue na "" "" 1 0

# 授权
sudo /usr/syno/sbin/synoshare --setuser rescue RW = 你的用户名

# ⚠️ synoshare --build 会把目录权限重置为 000，之后必须修回
sudo chmod 777 /volume3/rescue

# 重载 SMB（是 systemctl，不是 synoservice）
sudo systemctl reload pkg-synosamba-smbd.service

访问：\\你的NAS内网IP\rescue

另注：SMB 共享不写在/etc/samba/smb.conf（该文件只有 [global]），别据此判断失败。

第六章 事后决策框架：等解密器，还是重新获取？

很多人纠结"要不要关机等官方解密器"。我的建议是分三类处理，不要一刀切：

类别 A：你自己生产的、无法重新下载的数据

（个人相片、家族族谱、自己整理的档案、扫描件、工作文档）

→ 不要等。 现在立刻找副本：手机相册、相机内存卡、电脑本地、微信聊天记录里的原图、网盘、其他同步过的设备。这类数据丢了就是永久没了，解密器来了也未必轮得到你。

类别 B：从公开来源抓取/下载的数据

（公开数字图书馆、政府开放数据、公开数据库）

→ 直接重新下载。 这是 100% 完整的路，比任何抢救都干净，也不用赌解密器。 你的目录名里往往就写着来源（如 www.loc.gov、digital.bodleian.ox.ac.uk、eap.bl.uk）。

类别 C：既无副本、也无法重下的部分

→ 关机封存，等待解密器。 关机能停掉 auto_reclaim_space，保住 Btrfs 旧块。

• .L0CK3D 是静态文件，关机不影响将来解密，有了解密器开机就能解

• 硬盘防潮防震，每半年通电一次

• 关注渠道：No More Ransom、Emsisoft、卡巴斯基 NoRansom、Avast

关于等待的期望值，说句实话：历史上大约只有 10–15% 的勒索家族最终出了免费解密器，时间完全不可预期（几个月到永远不来）。不要把全部希望押在这里。

本次救援最值得反思的一点：我花最大力气抢救的 B001 科举文献库，恰恰是最容易重新下载的那一类； 而真正不可替代的个人相片、族谱档案，反而一个都还没碰。动手之前，先按"能不能重新获取"给数据排个序——这比任何技术都重要。

附录 A：命令速查表

# ── 生死判定 ──────────────────────────────
ls -l /proc/*/exe 2>/dev/null | grep deleted   # 找潜伏的加密进程
ps aux --sort=-%cpu | head -15                  # 找高 CPU 进程
kill -STOP <PID>                                # 冻结（不是杀死！）

# ── 快照排查 ──────────────────────────────
sudo btrfs subvolume list /volume1
sudo ls -la /volume1/@sharesnap

# ── 文件系统与空间 ────────────────────────
df -hT
mount | grep volume          # 看有没有 auto_reclaim_space
sudo btrfs filesystem show

# ── 数据分诊 ──────────────────────────────
find /volumeX/库名 -name '*.L0CK3D' | wc -l
find /volumeX/库名 -name '*.L0CK3D' -size +5M | wc -l
find /volumeX/库名 -name '*.L0CK3D' -size -1M | wc -l

# ── 后门排查 ──────────────────────────────
sudo /usr/syno/bin/synoschedtask --get
sudo crontab -l
sudo ls -la /root/.ssh
sudo netstat -tunp | grep -v '127.0.0.1'

# ── 加固 ──────────────────────────────────
sudo sh -c 'for p in $(ps -e | grep inetd | awk "{print \$1}"); do kill -9 $p; done'
sudo modprobe ip_tables && sudo modprobe iptable_filter
sudo /usr/bin/sshd -t && sudo kill -HUP $(pidof sshd | awk '{print $1}')

附录 B：资源链接

附录 C：本次事件时间线

最后：如果只能记住一件事

发现中招的第一反应，决定了你能拿回多少。

别重启、断网、找快照、冻结进程。

然后才轮到技术。

阅读原文：点击这里​