2026-11-01 01:34:22 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

群晖NAS勒索风暴：LOCK3D一夜席卷全网，最新版DSM也中招

原创

赤霄攻防实验室
赤霄攻防实验室

赤霄攻防实验室

2026年10月30日 09:15
河北

去阅读

群晖 NAS LOCK3D 勒索事件预警 · 2026-10-29

TL;DR 四行速览

是什么｜2026 年 10 月 28 日起，群晖 NAS 用户集中遭遇勒索攻击：全盘文件被追加 .LOCK3D 后缀并投递 read-me3.txt 勒索信，家族被暂命名为 C3RB3R，正在活跃期。

影响谁｜公网暴露的群晖 NAS（含黑群）。已确认多起处置案例，受害者中有人开着 2FA、改过端口、禁了 SSH 仍被加密；最新版 DSM 7.4.1 也有中招报告。

入口确认了吗｜没有。官方与应急团队均未定性，DSM 本体 0day、旧洞未修（SA-26:13/26:14）、老 0day 复用（Pwn2Own 2024 的 CVE-2024-10441）、凭据与套件四条路径都还在台面上。

现在做什么｜立刻收敛公网暴露面、补齐 DSM 与套件更新、检查账号与备份。已中招：断网但别关机，密钥可能在内存里。

发生了什么：一夜之间的集体中招

10 月 28 日开始，B 站、小红书、V2EX、linux.do 上群晖用户的求助帖突然刷屏，症状高度一致：NAS 整夜异响，登录上去发现磁盘可用空间归零，所有文件末尾多了一串 .LOCK3D（或 .L0CK3D）后缀，每个目录里躺着一份名为 read-me3.txt 的勒索信。有 DS720+ 用户两块 8T 盘做了 RAID1，把盘拔下来插到电脑上同样读不出来——几十年的照片和资料一夜之间全部变成打不开的密文。

看雪安全社区发布的现场处置报告显示，Solar 应急响应团队近日处置了多起同类事件，根据勒索信与暗网站点信息将该家族暂命名为 C3RB3R。这不是零星的个体倒霉：多家群晖经销商已经向客户发出「关闭外网访问」的紧急通知，群晖官方也在 10 月 28 日 18:31 发布预警，建议用户尽可能关闭外网访问——这是事件级别的响应动作，而非例行提醒。ID Ransomware（BleepingComputer 旗下勒索家族识别库）已在 10 月 28 日收录该家族，标注「仍在分析中」，从侧面印证这是一次正在演进的新爆发。

把已知事实压成一张卡片：

事件信息卡（截至 2026-10-29）

家族命名｜C3RB3R（社区俗称 LOCK3D / L0CK3D）

识别特征｜文件追加 .LOCK3D / .L0CK3D 后缀；每目录投放 read-me3.txt 勒索信

勒索站点｜Tor 暗网站点，全流程自动化：单文件免费试解密（≤1024KB）、自动生成钱包与支付状态监测、6 次确认后自动交付解密器

受害分布｜DSM 7.2.1 与 7.4.x 均有报告，ARM 机型暂未见；黑群（Redpill）用户同样中招

官方状态｜未发布定性安全公告，10-28 仅预警关闭外网访问

入侵入口｜未确认——这是本次事件最大的不确定性

风险有多高：三个关键问题

最新版也中招，等于最新版有 0day 吗？

不等于，这是本次信息传播里最容易被带偏的一步。Solar 团队处置的受害设备确实运行着 DSM 7.4.1-90080 Update 1——10 月 12 日刚发布的当前最新版。但应急响应的常识是：设备「现在的版本」和「被入侵当天的版本」未必相同，受害者可能在被入侵之后才补的更新；即便真是在最新版上被入侵，入口也可能是第三方套件、容器、泄露的凭据或内网横向，而非 DSM 本体。在日志和现场痕迹闭环之前，「最新版有 0day」只能作为待验证假设保留。反过来说，那些宣称「升级到最新版就安全」的结论同样不成立——两边都是在证据不足时下的判断。真正可靠的动作是收敛暴露面，而不是赌版本号。

入口到底有哪几种可能？

把目前社区与官方信息里的候选路径整理成一张对照表，按「已证实 / 待证实」区分采信度：

入侵入口四个候选假设：A DSM 本体 0day / B 旧洞未修 / C 老 0day 复用 / D 凭据·套件·横向

四条路径里最有实锤支撑的是 B 和 C 的组合拳。群晖今年 9 月 18 日修复的 SA-26:13 包含多个 Critical 级漏洞，社区口径为两个 9.8 分的未授权任意文件读写；10 月 22 日又修复了波及 PHP 生态的 PHP2Shell（SA-26:14）——两个补丁分别只「满月」和「一周」，大量设备根本没装。更耐人寻味的是 C：linux.do 一篇救灾直播贴把其中一起案例的入侵根因指向 CVE-2024-10441，那是 Pwn2Own 2024 比赛上被打出的 DSM 0day（SA-24:20，9.8 分未授权 RCE），正版用户早就修了，但黑群用户常驻老版本、没有正规更新通道，等于把两年前的比赛 0day 一直裸露在公网上。黑群受害与正版受害可能是两批人、两条路径，混在一个话题里讲，就会得出「最新版也有 0day」的错误结论。

加密之后还发生了什么？

现场痕迹显示这不是「加密完就跑」的一锤子买卖。有受害者发现 Docker 套件被卸载——攻击者在加密前清理运行环境，减少干扰；同一局域网里的小米摄像头在加密发生后随之掉线，提示加密后还存在横向感染的动作。而勒索运营侧的工业化程度更值得警惕：C3RB3R 的暗网站点把试解密、FAQ、收款、交付做成了全自动流水线——受害者上传一个不超过 1024KB 的加密文件可免费试解密一个，页面自动生成钱包地址与二维码并监测支付状态，交易 6 次确认后刷新即可拿到解密器。整套流程几乎没有人工介入，这个成熟度在针对消费级 NAS 的勒索里是罕见的。

熟悉 NAS 安全史的人看到这里会想起 2022 年的 DeadBolt：它感染了公网上数以千计的 QNAP 与 ASUSTOR 设备，单台赎金 0.03 BTC，还给厂商开出了「5 BTC 买漏洞情报、50 BTC 买全局主密钥」的勒索菜单；直到荷兰警方介入放出部分密钥，事件才逐步平息。C3RB3R 的自动化程度比 DeadBolt 更高，而 NAS 「存全家数据 + 长期公网裸奔 + 用户不更新」的目标画像一个都没变。攻击者在回到这条被验证过的商业路径。

现在就做：自查与响应

四步自查 + 三步应急，按优先级从上往下执行

最优先的一件事永远是收敛暴露面：关掉路由器上的端口映射，让 DSM 管理界面从公网上消失。自查方法很简单——断开家里 WiFi，用手机流量访问「你的公网 IP:NAS 端口」，能看到登录页就是裸奔。远程访问需求改走 VPN、Tailscale 或 ZeroTier 组网，这是本次事件里中招与未中招用户之间最显著的一条分界线。其次把 DSM 和全部套件升到最新修复版，逐条核对下文漏洞账本里的 SA-24:20、SA-26:13、SA-26:14 是否都已覆盖；再禁用不用的账号与服务，给保留账号上强密码和 2FA。

备份环节要强调三遍：RAID 不是备份。病毒加密文件时，RAID 会把密文忠实地同步到每一块盘上，上文那位 RAID1 用户两块盘同时变砖就是活例。合格的备份要有三道闸：Btrfs 不可变只读快照、单向备份（双向同步会把密文写回健康备份）、以及一份离线副本——移动硬盘拔线进抽屉，才是勒索软件够不到的地方。

如果已经中招，两条铁律：断网，但不要关机。拔网线阻止扩散，但保持开机状态——加密密钥可能还留在内存里，取证团队有机会从内存 dump 中逆出主密钥，关机等于亲手销毁最后的恢复线索。同时停用 Cloud Sync 等同步套件，避免密文和勒索信被同步到云端污染备份。然后保护现场：截图勒索信全文，导出系统日志、登录记录与套件日志，不要重装、不要格式化、不要写入大量数据。关于赎金：DeadBolt 时代有受害者付了两次仍未拿到解密器的先例，而荷兰警方后来免费放出了部分主密钥——执法渠道的翻盘是真实发生过的，付款不是。先报警，再找专业应急团队。

漏洞账本：DSM 这两年欠了什么

从 Pwn2Own 比赛 0day 到本次勒索爆发的修复时间线

把时间线摊开看，会发现「修复」和「免疫」之间隔着一条巨大的鸿沟。2024 年 11 月，Pwn2Own 比赛上被打出的 DSM 0day 以 SA-24:20 修复；2026 年 9 月的 SA-26:13 修掉了多个 Critical 级未授权读写；10 月 12 日发布的 DSM 7.4.1-90080 U1，官方说明里只有一句「修正了安全性弱点」，没有编号、没有组件、没有细节；10 月 22 日 SA-26:14 修复 PHP2Shell 波及的组件——六天后勒索爆发。每一次官方修复都发布在了通告页上，但大量设备从未安装，黑群更是根本没有更新通道。攻击者不需要 0day，把两年内公开修过的旧洞挨个打一遍，就足以支撑一轮勒索 campaign。

另一个值得记进账本的是「修复透明度」问题。10 月 12 日那个「修正了安全性弱点」的更新，没有公开任何漏洞编号与受影响组件，防御方既无法评估自己是否受影响，也无法在事件爆发时快速对齐「官方修过什么」。对安全团队来说，含糊的修复说明等于把资产核对变成盲盒。这在本次事件溯源困难里，是官方层面的一个客观减分项。

本次事件现场通告（信源）

看雪安全社区：Solar 应急响应团队处置报告原文（2026-10-29）

上图为本次事件最重要的一手信源：看雪安全社区发布的 Solar 应急响应团队处置报告。报告给出了受害设备的 DSM 版本截图、勒索信样张与暗网勒索站点界面，并明确说明「入侵入口尚未确认，现阶段不能认定 DSM 本体存在 0day」——这也是本篇所有判断的基线：在官方定性之前，任何「确认是 XX 漏洞」的说法都值得存疑。

本篇的观点与教训

第一，消费级 NAS 是勒索软件性价比最高的目标之一：数据密度高（一个盘位装下一个家庭十年的照片）、安全投入低（默认配置长期不更新）、赎金承受意愿强（数据无价且无替代品）。DeadBolt 验证过这条商业模型，C3RB3R 正在用更高的自动化程度复跑它。只要「管理界面直接映射公网」的用法还存在，这类爆发就不会是最后一次。

第二，事件发酵期的信息纪律。这两天社群里流传着各种确定性话术——「确认是 DSM 0day」「升级最新版就安全」「只有黑群才中招」——它们彼此矛盾，且都缺乏闭环证据。本篇把四个假设按采信度分层列出，就是想说明：入口归因需要日志、时间线与样本三方对齐，转发一个结论之前，先看它有没有证据链。对防御决策而言，「收敛暴露面 + 补版本 + 验备份」在四种假设下全部有效，是唯一不需要赌方向的动作。

第三，把备份当成安全控件而不是存储功能。快照要不可变、同步要单向、离线副本要真的离线。这次受害者的 RAID1 教训说明，多数人对「备份」的理解还停留在「多一块盘」，而勒索软件攻击的恰恰是「所有可写副本」。若本次事件后续官方定性、样本逆出或主密钥披露，本号会第一时间跟进更新。