一夜沦陷，当群晖 NAS 风扇狂转且所有文件变成 .L0CK3D
2026 年 10 月 28 日下午至 29 日凌晨，国内外各大技术社区突然涌现大量群晖 NAS 用户的受灾求助。无论是个人家庭相册、企业备份服务器，还是运行了数年的私有代码库，都在毫无征兆的情况下被批量加密锁定。
在 LINUX DO 社区的预警讨论帖中，有用户深夜听到床边的 DS918+ 风扇异常狂转，打开后台才发现 Cloud Sync 正在向异地网盘疯狂同步名为 read-me3.txt 的文件。还有用户发现 NAS 里的 Docker（Container Manager）被直接卸载，8TB 乃至数十 TB 的文档、照片与同机备份全部被追加了 .L0CK3D（部分显示为 .LOCK3D，含数字 0 和 3）扩展名。
根据 360 反勒索团队与 Solar 应急响应团队的样本分析，本次肆虐的真凶是老牌勒索软件家族 Cerber 的现代 Linux 变种 C3RB3R。每个被加密目录下生成的 read-me3.txt 勒索信中均带有 C3RB3R INSTRUCTIONS 标识与 6 位专属设备 ID，引导受害者通过 Tor 浏览器访问暗网自助站点。
该暗网站点已实现高度自动化运营，允许受害者免费上传 1 个小于 1024 KB 的 .L0CK3D 文件进行试解密，以此证明攻击者手握解密能力。页面会自动生成专属比特币收款地址，索要赎金 0.085 BTC（若超过 5 天未支付则翻倍至 0.17 BTC），并宣称在区块链交易完成 6 次确认后即可刷新下载解密器。
黄金一小时自救，如果刚中招千万不要慌乱拔电源
在以往的勒索病毒处置中，许多人的第一反应是“立刻拔掉电源线或强制关机”。但在本次群晖 C3RB3R 事件中，盲目断电重启反而会亲手毁掉唯一免费恢复全部数据的机会。
根据受灾现场的只读取证，攻击脚本会从 hxxp://46[.]8[.]78[.]122/xdy5.sh 拉取针对不同 CPU 架构（支持 x86_64、aarch64、armv7l）的 UPX 加壳 ELF 二进制程序。程序通常伪装成 /bin/libgld（带参数 -n 308 启动）或 /bin/qnetd（带参数 153 启动），并在扫描时跳过 27 个系统关键目录以防系统崩溃中断加密，对 187 种常见扩展名实施全文件加密。
逆向工程显示，C3RB3R 对每个文件生成独立的 32 字节密钥与 8 字节 nonce 进行 ChaCha8 对称加密，并在文件末尾固定追加 588 字节的尾部数据（Footer）。这 588 字节中包含一段 48 字节的密钥记录，它是由当前加密会话生成的 AES-256-CBC 主密钥加密保护的，而这把最关键的会话主密钥在加密过程中就明文驻留在系统内存（RAM）里。
来自 LINUX DO 社区的开发者 @soimy（V2EX ID Mayday9421）在群晖 DSM+GitLab CE 救灾直播贴中完成了一场教科书级的绝地自救。他在发现 PVE 虚拟机中的群晖遭遇加密后，第一时间切断公网但没有关机，而是通过本地 SSH 挂起（暂停）了正在运行的 libgld 加密进程，并导出了 16 GiB 的完整内存镜像（RAM Dump）。
随后他借助 AI 辅助与 Ghidra 反编译，顺着虚拟地址 0x5427f8 指向的 0x130fa00 内存区域，成功提取出 16 字节 IV 与 32 字节 AES-256-CBC 主密钥（共 48 字节会话材料）。利用这把从内存中抢救出的主密钥，他直接解开了文件尾部 588 字节里的 ChaCha8 文件密钥，100% 逐字节无损恢复了过去 5 年积累的 49 GiB GitLab 代码仓库备份与设计文档。
目前 @soimy 已将完整的取证流程、AI 提示词与解密脚本开源至 GitHub 仓库 soimy/c3rb3r-rescue，在 LINUX DO 社区与 GitHub Issues 中已有其他未关机的受害者（如 @xkkk_er、Benajaminzm）借此成功解开数据。如果你发现设备正在被加密或刚刚加密完成，请严格按照以下顺序操作：
- 立刻拔掉外网网线或在路由器端阻断该 NAS 的所有外网连接，防止脚本回传或二次破坏，但务必保留局域网连接与设备电源。
- 切勿重启、切勿关机、切勿直接
kill -9杀死可疑进程，一旦进程终止或断电，内存中的易失性密钥将永久丢失。 - 打开本地 SSH 登录群晖，使用
kill -STOP <PID>冻结可疑加密进程（如libgld或qnetd），阻止其继续加密剩余文件并锁死进程内存空间。 - 立即导出内存与二进制样本：虚拟机用户可直接在宿主机（如 PVE / ESXi）对虚拟机执行内存转储，物理机用户可通过
/proc/<pid>/mem、AVML 或 LiME 采集进程与整机内存，再参照 soimy/c3rb3r-rescue 提取密钥。
如果设备已经不幸断电重启，内存密钥路径便已失效，此时请立即停机避免任何磁盘写入或数据擦除（Data Scrubbing）。用户可尝试将硬盘挂载为只读模式，检查是否有残存的 Btrfs 历史快照，或寻求专业救援机构尝试通过 Btrfs 写时复制（CoW）历史元数据树（B-Tree）扫描未被覆盖的旧数据块。
深度溯源，黑客到底是怎么进来的
围绕本次大规模攻击的入侵入口，安全厂商与一线极客给出了不同维度的分析，综合多方取证事实来看，这是一场利用多漏洞武器库（Exploit Kit）对公网暴露群晖进行的无差别收割。
入口一，CVE-2024-10441（底层日志证实的头号元凶）
尽管这是一个 2024 年底修补、2025 年 3 月公开细节的漏洞（详见官方公告 Synology-SA-24:20），但它在本次事件中被证实遭到了最广泛的自动化利用。包括 LINUX DO 社区的 @soimy、V2EX 受灾用户以及海外 Reddit /r/synology 用户 u/NakamuraHwang 在对残留的 /var/log/auth.log.L0CK3D 与内存日志取证时，均发现了完全一致的攻击痕迹。
该漏洞（CVSS 评分 9.8 分）存在于 DSM 系统插件守护进程 synoplugind 中，属于无需登录认证的远程代码执行漏洞。攻击者只需向群晖 WebAPI 登录接口（/webapi/entry.cgi）发送一条包含 PLUGIN_VALUE_END、LD_PRELOAD 与 LD_DEBUG_OUTPUT 环境变量注入的恶意登录请求。
哪怕页面返回“密码错误、登录失败”，注入的指令依然会以 root 权限在后台被解析执行，直接向 /etc/cron.d/ 写入形如 synotade.<PID> 的恶意计划任务。大量长期不更新系统的 Redpill“黑群晖”用户，以及停留在旧版 DSM 6.2、7.1、7.2 的正版用户，只要将 Web 界面暴露在公网，就会被瞬间秒杀。
入口二，CVE-2026-13684 与 CVE-2026-13639（2026 年 9 月高危漏洞）
360 反勒索团队与蓝点网的预警报告指出，攻击者还利用了群晖于 2026 年 9 月 18 日在 Synology-SA-26:13 中披露的两个满分（CVSS 9.8）远程漏洞。其中 CVE-2026-13684 涉及 DSM SCGI 组件输出编码或转义不当，CVE-2026-13639 涉及登录逻辑中随机数熵不足。
这两个漏洞同样不需要任何账号密码认证，即可允许远程攻击者直接读取或写入系统任意文件。由于群晖 DSM 的自动更新采用分阶段推送（Staged Rollout）机制，不少白群晖用户在过去一个月内并未收到自动升级推送，从而沦为 1day 漏洞的受害者。
入口三，PHP2Shell 套件漏洞与容器潜伏
就在本次事件爆发前夕的 2026 年 10 月 22 日，群晖刚刚发布了 Synology-SA-26:14 "PHP2Shell" 安全公告，修复了 PHP 内存分配远程代码执行漏洞 CVE-2026-109618 和 CVE-2026-109619（CVSS 9.8 分）。虽然 DSM 底层内置 PHP 不对外暴露，但安装了 Web Station、Synology Calendar、Mail Station、phpMyAdmin、WordPress 及 PHP 7.4–8.4 套件的设备若未更新套件，同样面临未授权远程代码执行风险。
此外，部分用户在高权限 Docker 容器中运行了存在漏洞的服务（如未及时更新的 GitLab CE 19.3 或开放注册的 Gitea）。攻击者通过容器突破后将恶意拉取脚本写入宿主机的 /etc/crontab 定时任务中，最后在 10 月 28 日统一触发加密并卸载 Docker 毁灭证据。
破除三大安全错觉，为何最新 DSM 7.4.1 和开两步验证也中招
在蓝点网公众号评论区与 LINUX DO 社区中，最让用户感到恐慌的是“为什么有人升到了最新的 DSM 7.4.1、开了两步验证（2FA）、改了 5000/5001 端口，依然被加密了？”。结合 Solar 应急响应团队的现场排查与一线取证记录，我们可以清晰还原背后的真相。
错觉一，“我已经升到了最新 DSM 7.4.1，肯定是因为有未公开 0day”
Solar 团队确实排查到一台受灾设备运行着 2026 年 10 月 12 日发布的最新版 DSM 7.4.1-90080 Update 1，但安全团队明确强调，最新版中招不等于 DSM 7.4.1 存在 0day 漏洞。最核心的原因在于入侵时间（Time-of-Compromise）与加密时间（Time-of-Encryption）存在时间差。
许多设备在升级到最新版本之前，就已经通过旧版本漏洞或容器漏洞被攻击者植入了 /etc/crontab 或 /etc/cron.d/ 计划任务后门。升级 DSM 系统版本或更新 Docker 容器镜像，并不会清除系统计划任务里的恶意脚本，一旦到了预设时间，潜伏的后门依然会拉取加密载荷完成收割。
同时，许多用户只升级了 DSM 系统，却忽略了“套件中心”里待更新的 PHP、Calendar 等高危套件，或者内网 Windows 电脑中毒后通过挂载的管理员权限 SMB 共享将 NAS 连坐加密。
错觉二，“我开了两步验证（2FA）、强密码、禁了 SSH、改了默认端口”
在本次受灾名单中，大量技术玩家都配置了 20 位复杂密码、开启了 OTP 两步验证、关闭了 SSH，并将默认的 5000/5001 端口改成了五位数的冷门端口。然而面对 CVE-2024-10441 和 CVE-2026-13684 这类认证前（Pre-auth）漏洞，密码强度与两步验证形同虚设。
因为漏洞触发点位于身份校验完成之前，攻击者根本不需要知道你的密码，更不需要走到输入两步验证码的那一步，只要能访问到登录接口就能直接拿走 root 权限。至于修改默认端口，如今全网自动化资产测绘引擎（如 Shodan、Censys、FOFA）与高频扫描器可以在几分钟内扫遍全端口并识别出群晖 WebUI 指纹，改端口早已无法实现隐身。
错觉三，“我没有 IPv4 公网，只开了 IPv6，应该很安全”
不少移动或电信宽带用户认为自己没有 IPv4 公网 IP，便放心大胆地开启了 IPv6 DDNS 外网访问。事实上，V2EX 与 LINUX DO 社区的多位受灾用户通过排查日志确认，攻击者正是顺着暴露在公网的 IPv6 地址完成扫描与漏洞注入的。
一旦你的 IPv6 域名绑定过公开的证书透明度日志（CT Logs，如申请过 Let's Encrypt 证书）或存在 DNS 解析记录，黑客扫描器就能精准定位你的 IPv6 地址与端口。
群晖 NAS 紧急自查与防御加固清单（白群与黑群必看）
无论你的群晖目前是否正常，只要曾连接过互联网，建议今晚立即按照以下四步完成自查与加固。
第一步，立即切断所有公网暴露面，改用虚拟局域网
- 登录路由器后台，立即删除所有指向群晖 NAS 的端口转发（Port Forwarding）规则，关闭路由器的 UPnP 与 DMZ 功能。
- 如果开启了 IPv6，请在路由器防火墙中开启 IPv6 入站阻断，或在群晖“控制面板 -> 网络 -> 网络界面”中暂时关闭 IPv6，切勿将 DSM 的 HTTP/HTTPS 端口直接暴露在公网。
- 将远程访问方式全面切换为 Tailscale、WireGuard 或 ZeroTier 等内网组网工具，实现“端口零暴露”的安全远程访问。
第二步，排查系统是否存在潜伏的恶意计划任务
对于曾经暴露在公网、近期才更新系统或关闭端口的用户，务必通过本地 SSH 登录群晖排查是否有潜伏后门：
- 检查
/etc/crontab以及/etc/cron.d/目录下是否存在未知的定时任务（重点排查带有synot*前缀或包含curl、wget、sh、陌生 IP 的异常条目）。 - 检查
/bin/目录下是否存在/bin/l0ck.enc、/bin/libgld、/bin/qnetd等异常文件。 - 打开群晖内置的“日志中心”，查看近期是否有异常的外部 IP 登录失败记录或
root权限配置变更记录。
第三步，核对并手动安装最新安全补丁
不要盲目相信 DSM 控制面板里的“您的 DSM 版本已是最新”，由于分阶段推送机制，许多设备需前往群晖官方下载中心手动下载 .pat 补丁包升级。请确保你的 DSM 版本不低于以下修复基线（参考 SA-26:13 与 SA-24:20）：
- DSM 7.4 分支：需升级至
7.4-90075或最新的7.4.1-90080 Update 1及以上。 - DSM 7.3 分支：需升级至
7.3.2-86009-4及以上。 - DSM 7.2.2 分支：需升级至
7.2.2-72806-9及以上。 - DSM 7.2.1 分支：需升级至
7.2.1-69057-12及以上。 - DSM 7.1 / 7.0 / 6.2 旧分支：需确保已安装
7.1.1-42962-7/6.2.4-25556-8补丁，并在“套件中心”更新群晖于 2026 年 10 月 28 日至 29 日专门为 EOL 旧系统下发的 PHP 安全更新。 - 套件全面升级：立即打开套件中心，将
Synology Calendar（升至3.0.4-21435+）、Mail Station、Web Station及所有PHP 7.4–8.4套件升至最新，已停更的PHP 7.3建议直接卸载。
第四步，重构“防勒索”备份体系
本次事件中，有用户配置了 RAID 6 阵列加每日同机备份，结果所有本机备份与原文件被一锅端；还有用户开启了网盘双向同步，差点用加密后的 .L0CK3D 文件把云端正常文件全部覆盖。真正能抵御勒索软件的备份策略必须满足以下条件：
- 启用 Btrfs 不可变快照（Immutable Snapshots）：在群晖 Snapshot Replication 套件中开启基于 WORM（一次写入，多次读取）技术的不可变快照，设定 7 至 14 天的锁定期，在此期间即便是获取了
root权限的黑客也无法删除或加密快照数据。 - 网盘同步开启“单向”或“历史版本”：使用 Cloud Sync 同步至 OneDrive 或公有云时，务必确认云端开启了文件历史版本控制（Versioning），或改用 Hyper Backup 进行带多版本保留的加密备份。
- 严格落实冷备份（离线备份）：重要核心数据定期备份至外置移动硬盘，备份完成后物理拔除电源与数据线（或使用智能插座仅在定时备份窗口通电），实现彻底的物理隔离。
常见问题解答（FAQ）
Q1，发现中招时已经把群晖关机或重启了，还能用 GitHub 上的开源工具解密吗？
基本无法直接通过该工具恢复。因为 soimy/c3rb3r-rescue 的原理是从尚未断电的运行内存（RAM）中提取 48 字节的 AES-256-CBC 会话主密钥，一旦关机、重启或重装固件，内存中的易失性数据便已清空，且目前在断电后的 Swap 交换分区中也未能找到残留密钥。已重启的用户建议立即停机保护磁盘现场，优先检查是否残留 Btrfs 快照，或尝试通过专业数据恢复软件（如 UFS Explorer）及 Btrfs 底层元数据扫描抢救未被覆盖的文件块。
Q2，我的设备停留在 DSM 6.2、7.0 或 7.1（或使用黑群晖），受这次漏洞影响吗？
受严重影响，而且是本次被攻破的重灾区。本次被证实遭大规模利用的 CVE-2024-10441 以及近期爆发的 PHP2Shell（SA-26:14） 均明确影响 DSM 6.2、7.0 和 7.1。群晖官方已于 2026 年 10 月 28 日至 29 日破例为已结束生命周期（EOL）的 DSM 7.2、7.1、7.0 和 6.2 推送了 PHP 安全补丁，无法升级最新系统的黑群晖或老机型用户绝对不要将 NAS 暴露在公网。
Q3，不映射公网端口，只开 QuickConnect（QC）、Cloudflare Tunnel 或 FRP 内网穿透安全吗？
任何将群晖 Web 登录界面直接暴露给外部未授权访问的通道都存在风险。如果你通过 FRP 或 Cloudflare Tunnel 将群晖的 5000/5001 端口映射到了公网域名，且没有在隧道前端加装额外的访问鉴权（如 Cloudflare Access 零信任验证），攻击者同样可以通过域名直接触发 DSM 的未授权漏洞。至于 QuickConnect，虽然目前尚无底层证据表明 QC 协议本身被直接攻破，但社区中有个别自称仅开启 QC 的用户中招（不排除路由器开启了 UPnP 或遗漏了 IPv6），在官方完成全面归因前建议暂时关闭 QC，优先使用 Tailscale 等 VPN 访问。
Q4，在群晖前面挂了雷池（SafeLine）等 WAF，或者用 Lucky 反向代理能防住吗？
不能保证 100% 防御。通用 WAF 的默认规则主要针对常见 Web 攻击（如 SQL 注入、常规 XSS），未必能精准识别针对群晖私有 WebAPI（如 /webapi/entry.cgi 插件分隔符注入或 SCGI 协议）的特制载荷，海外 Reddit 也有配置了多层反向代理与防火墙规则依然被攻破的案例。如果必须使用反向代理对外提供服务，建议开启严格的客户端证书校验（mTLS）或前置 HTTP Basic Auth 认证，避免让外部流量直接触达群晖原生登录接口。
Q5，如果数据极其重要且已经重启，向黑客支付 0.085 BTC 赎金能拿回数据吗？
网络安全机构与社区强烈建议不要支付赎金。一方面，支付高昂的比特币赎金无法获得任何商业信誉保障，存在付款后拿不到解密器、解密器损坏大体积文件或遭遇二次敲诈的风险；另一方面，即便解密成功，设备底层也已被植入后门，必须在导出数据后彻底格式化重装系统。
参考来源与延伸阅读
- Synology Security Advisory Synology-SA-26:13 DSM（CVE-2026-13684 / CVE-2026-13639 官方安全公告）
- Synology Security Advisory Synology-SA-24:20 DSM（Pwn2Own 2024 CVE-2024-10441 官方安全公告）
- Synology Security Advisory Synology-SA-26:14 PHP2Shell（CVE-2026-109618 / CVE-2026-109619 套件安全公告）
- 360 反勒索团队《Cerber 勒索攻击群晖 NAS 事件预警》
- 看雪安全社区 Solar 应急响应团队《【勒索预警】群晖 NAS 最新版遭勒索病毒攻击，疑似涉及 0day 漏洞》
- GitHub 开源救援仓库 soimy/c3rb3r-rescue（Evidence-based DSM ransomware recovery）
- LINUX DO 社区《群晖 DSM+GitLab CE 遭 C3RB3R 勒索软件攻击！救灾直播贴》
- LINUX DO 社区《【勒索预警】群晖 NAS 最新版遭勒索病毒攻击，疑似涉及 0day 漏洞！》
- Reddit /r/synology 一线日志取证分析《Well, it finally happened. My first real ransomware incident.》
