前言

2026 年 10 月 28 日下午至 29 日凌晨，NAS 圈炸了锅：国内外大量群晖（Synology）NAS 用户发现存储空间里的文档、照片、数据库备份被批量加密，扩展名统一变成 .L0CK3D（部分显示为 .LOCK3D，含数字 0 和 3），每个目录里都多了一份 read-me3.txt 勒索信，内容是 C3RB3R INSTRUCTIONS 和一组 6 位设备 ID，引导受害者用 Tor 浏览器访问暗网自助站点交赎金。

这件事之所以让人慌，不只是规模大，而是它打破了很多人的安全认知：受害者里既有跑最新 DSM 7.4.1 的设备，也有开了两步验证、改了默认端口、禁了 SSH 的设备。360 反勒索团队与 Solar 应急响应团队已相继披露事件，群晖官方也已确认用户数据被加密并发布安全公告。

如果你现在正在读这篇文章、并且 NAS 里有重要数据：先看第四章「中招后的黄金一小时」，那里有一条可能让你免费恢复全部数据的自救路径——前提是千万别断电、别重启。

事件时间线

受害面从家庭相册（DS918+ 等家用型号）到企业备份服务器、私有 GitLab 代码库都有，有用户报告 8TB 至数十 TB 数据被一次性加密，同机备份目录也未能幸免。

攻击特征：你的 NAS 有没有中招

对照下面几条，任意一条命中就要立刻处理：

• 文件扩展名被追加 .L0CK3D
• 各级目录和系统根目录出现 read-me3.txt，内含 C3RB3R INSTRUCTIONS 与 6 位设备 ID
• Docker / Container Manager 被卸载或容器全部消失
• NAS 风扇异常狂转、CPU 占用拉满（加密进程在跑）
• Cloud Sync 正在疯狂同步 read-me3.txt 到异地网盘（说明加密已扩散到同步目录）
• 登录 DSM 后套件异常、大量服务不可用

勒索信里的条件是：0.085 BTC，超过 5 天未付则翻倍至 0.17 BTC。攻击者提供「上传一个小于 1024KB 的文件免费试解密」来证明自己确实持有密钥——这是标准施压话术，不代表付钱一定能拿回全部数据。

技术拆解：C3RB3R 是什么

根据 360 反勒索团队与 Solar 应急响应团队的样本分析：

• 家族归属：老牌勒索家族 Cerber 的现代 Linux 变种，被暂命名为 C3RB3R
• 投放方式：恶意的拉取脚本从远端服务器（报告披露的 IOC 之一：hxxp://46[.]8[.]78[.]122/xdy5.sh）下载对应 CPU 架构（x86_64 / aarch64 / armv7l）的 UPX 加壳 ELF 二进制
• 伪装：进程伪装成 /bin/libgld（带参数 -n 308）或 /bin/qnetd（带参数 153），混在系统进程里
• 加密行为：从根目录开始多线程遍历所有挂载的存储空间，跳过 27 个系统关键目录以免把系统搞崩导致加密中断，对 187 种常见扩展名做全文件加密
• 加密算法：为每个文件生成独立的 32 字节密钥与 8 字节 nonce，使用 ChaCha8 加密，并在文件末尾固定追加 588 字节尾部数据；这 588 字节里包含一段被 AES-256-CBC 会话主密钥加密保护的 48 字节密钥记录
• 后果：会话主密钥只存在于加密期间的运行内存里，落盘的全是密文——所以断电重启后才彻底失去免费恢复的可能

一句话总结原理：文件的密钥都在尾部 588 字节里，但解开它们的那把「总钥匙」只在内存中。 这就是为什么「不要重启」是这次事件里最重要的一条。

三个免登录入侵入口

驱动之家/快科技的溯源报道指出，这波攻击不是传统「Windows 电脑中毒 → 通过 SMB 共享感染 NAS」的路径，而是攻击者针对暴露在公网的群晖设备，利用无需登录的认证前远程代码执行漏洞做全网自动化扫描攻击。目前披露的入口主要有三类：

入口一：CVE-2024-10441（群晖官方初步指向的头号元凶）

群晖官方初步排查认为攻击者利用了 CVE-2024-10441（CVSS 9.8，2024 年 12 月已修补）。该漏洞让攻击者无需任何账号密码就能从公网直达 DSM 底层——这也解释了为什么两步验证、强密码、改端口全都拦不住。

入口二：2026 年 9 月披露的两个高危漏洞

360 的报告指出本轮攻击还使用了两个今年 9 月披露的漏洞（CVE-2026-13684、CVE-2026-13639，评分口径在不同来源中标注为 9.8–10.0）。相关补丁已包含在较新的 DSM 中，但没打补丁的设备仍可被直接攻破。

入口三：套件与容器

• 原生套件：群晖安全公告 Synology-SA-26:14 涉及 PHP 核心 RCE（CVE-2026-109618、CVE-2026-109619），直接影响 MailStation、Synology Calendar 等套件——只升级 DSM 系统本体、不升级套件，入口依然敞着
• 容器链路：很多人在 Container Manager 里跑 GitLab、Confluence 等自建服务并把端口映射到公网。GitLab 的未授权 RCE（CVE-2026-110264、CVE-2026-97229）被攻破后，攻击者利用高权限容器挂载目录或宿主机逃逸缺陷，把恶意拉取脚本写进 Linux 底层的 /etc/cron.d/ 定时任务里静默潜伏

破除三个安全错觉

这次事件最有价值的部分，是它逐一击碎了几个被广泛相信的「安全常识」：

错觉一：「我升到最新 DSM 7.4.1 了，肯定没事」

Solar 团队公布的受害设备中，就有运行 DSM 7.4.1-90080 Update 1 的设备。原因有两个：一是升级前就已被人植入 /etc/cron.d/ 定时任务后门，升级不会清掉它，重启后照样继续加密；二是只升了系统本体，套件中心里的 PHP、日历等高危套件没升。所以「最新系统」不等于「已修复」。

错觉二：「我开了两步验证、强密码、禁了 SSH、改了端口」

这些防的是登录，而这次利用的是认证前漏洞——请求还没走到登录环节，攻击就已经完成。2FA 在这里一点用没有。

错觉三：「我没有 IPv4 公网 IP，只开了 IPv6，应该安全」

IPv6 也是公网。 只要设备能从外网直达，攻击面就在。评论区的实际受害者里就有只开 IPv6 的。

中招后的黄金一小时

这一节请务必按顺序操作。核心原则：断外网、保电源、保内存。

第 1 步：立刻切断外网，但不要断电

• 拔掉外网网线 / 在路由器端阻断该 NAS 的所有外网连接
• 保留局域网连接和设备电源

目的是阻止脚本回传和二次破坏，同时保住内存里的密钥。

第 2 步：绝对不要做的事

• ❌ 不要重启、不要关机——内存中的会话主密钥会永久丢失
• ❌ 不要 kill -9 强杀可疑进程——同理
• ❌ 不要重装系统、不要初始化硬盘、不要删除勒索信——这些都是取证与恢复的依据

第 3 步：冻结进程、导出内存

在本地局域网 SSH 登录 NAS，用 kill -STOP <PID> 暂停（不是杀死）可疑加密进程（如 libgld、qnetd），然后导出完整的运行内存镜像。

第 4 步：从内存提取密钥、解密文件

社区开发者 @soimy（V2EX ID Mayday9421）在 LINUX DO 直播完成了这套自救：从 16GiB 内存镜像中提取出 16 字节 IV + 32 字节 AES-256-CBC 主密钥（共 48 字节会话材料），用它解开文件尾部 588 字节里的 ChaCha8 文件密钥，逐字节无损恢复了 49GiB 的 GitLab 仓库与设计文档。

他已把完整取证流程与解密脚本开源：GitHub 仓库 soimy/c3rb3r-rescue，社区里已有多个未关机的受害者借此 100% 恢复数据。

如果已经重启/关机了怎么办

内存里的主密钥已经丢失，社区路径走不通，只能：从异地备份 / Btrfs 快照恢复；保留勒索信与日志等待官方进一步方案；不建议支付赎金——没有任何付钱必然拿回数据的保证。

未中招：今晚就做的加固清单

1. 立即关闭所有公网暴露面

• 路由器上关闭端口转发、UPnP、IPv6 入站
• 停用 QuickConnect、DDNS 直连、Cloudflare Tunnel、FRP 等一切把 DSM 暴露到公网的方式
• 远程访问统一改用 VPN 组网：Tailscale、WireGuard、ZeroTier、NetBird、Headscale 任选其一——核心是「必须先授权进网络，服务本身永不暴露公网」

2. 排查系统是否已被潜伏

检查这些位置有没有你不认识的条目：

1
2
3

/etc/cron.d/
/etc/crontab
/var/spool/cron/crontabs/

同时检查 DSM 里的「计划任务」、未知管理员账号、异常登录记录。发现可疑条目先记录证据再处理。

3. 更新系统与套件（两者都要）

• DSM 升到官方建议的最低安全版本（见下表）
• 套件中心里的所有套件（尤其 PHP、MailStation、Calendar、Synology Drive）全部升级
• Container Manager 里的容器镜像也要更新，别再让 GitLab 之类服务裸奔在公网

4. 停掉同步类任务，避免污染备份

确认安全之前，暂停 Hyper Backup、Cloud Sync、Synology Drive 等同步作业——勒索文件一旦同步上去，会把云端健康备份覆盖掉。

5. 重构备份体系（这次最痛的教训）

同机备份目录在本次事件中被一并加密，等于没有备份。正确姿势：

• Btrfs 不可变快照：快照要开、要锁，让加密进程改不动
• 异地 + 离线冷备：至少一份不联网、不同物理位置的备份
• 遵循 3-2-1 原则：3 份数据、2 种介质、1 份异地

官方回应与补丁版本表

群晖已确认用户数据被加密并发布安全公告，给出了各分支的最低安全版本：

注意：有用户反馈版本高于官方建议仍然中招，Solar 团队也表示入侵入口仍在分析、不排除存在未知漏洞。所以**「达标」只是必要条件，不等于安全**——关闭公网暴露才是根本。

常见问题

Q：只开 QuickConnect、不开端口映射，安全吗？
不算安全。QuickConnect 的实际链路仍可能把服务暴露到公网，本次事件中就有通过此类方式中招的讨论。最稳的方案是 VPN 组网。

Q：前面挂了 WAF / 反向代理能防住吗？
防不住认证前 RCE。WAF 拦的是已知特征，而漏洞利用请求对代理来说就是一条正常 HTTP 请求。

Q：黑群晖受影响吗？
受影响。漏洞在 DSM 本体与套件里，和硬件来源无关；而且黑群晖往往无法及时拿到官方补丁，风险更高。

Q：付 0.085 BTC 能拿回数据吗？
不建议。没有任何保证，且会助长攻击；未关机的情况下优先走内存提密钥的免费路径。

Q：已经关了 NAS 两天，还有希望吗？
先确认有没有 Btrfs 快照或异地备份；同时关注官方与社区后续是否公布新的恢复方案。

小结

这次事件给所有自建服务的人上了一课，结论其实很朴素：

1. NAS 不该以任何形式暴露在公网——不是改端口、不是 2FA、不是 WAF，而是根本不暴露，用 VPN 组网
2. 漏洞修补要连套件一起打，容器镜像同样要维护，「系统最新」是错觉
3. 同机备份等于没有备份，必须有不可变快照和离线异地副本
4. 真中招了先保电源保内存，那 48 字节可能是你唯一的免费出路

群晖官方公告、社区救援工具都还在更新，事态没有完全收敛。我把这次事件整理成文，希望帮到正在自查或刚中招的人——尤其是那句最容易被忽略的提醒：别急着拔电源。

参考

• Cerber 勒索攻击群晖 NAS 事件预警（360 安全资讯）
• 群晖 NAS 遭勒索病毒攻击：最新 DSM 版本也有受害报告（小众软件）
• 速速自查！群晖 NAS 惊爆大规模勒索攻击：官方证实呼吁立即更新（腾讯新闻/快科技）
• 群晖 NAS 突发 .L0CK3D 勒索病毒，内存提取密钥自救与加固全指南（AFeng Blog）
• 【勒索预警】群晖 NAS 最新版遭勒索病毒攻击（知乎·Solar 应急响应团队）
• 群晖疑出现 0day 漏洞，28-29 日凌晨大量 NAS 用户集体中招（LINUX DO）
• soimy/c3rb3r-rescue：社区开源自救工具（GitHub）

推荐链接

• 大佬CM博客
• 大佬周润发博客
• 大佬青云志博客