用群晖的朋友们，最近要注意了。
从 10 月 28 日凌晨开始，国内外各大 NAS 社区陆续传出群晖（Synology）设备遭遇大规模勒索病毒攻击的消息。
不少用户在早上打开电脑时发现，群晖机箱风扇整夜高速运转，存储空间里的文档、照片、数据库乃至影视文件全部被加上了 .L0CK3D（或 .LOCK3D）后缀，每个文件夹下都多出了一份名为 read-me3.txt 的勒索信。
在海外 Reddit 的 r/synology 板块、比利时安全机构 nxtbit、科技媒体 TechRadar Pro 与 BleepingComputer，以及国内的看雪安全社区、360 反勒索团队、Solar 应急响应团队与 V2EX 论坛上，大量受灾样本与取证日志在过去 24 小时内被集中披露。
让人感到棘手的是，这波被命名为 C3RB3R 的攻击不仅打穿了开启双重验证（2FA）、修改默认端口、禁用默认 admin 账号的设备，甚至连已经升级到最新 DSM 7.4.1-90080 Update 1 的机器也出现了中招案例。
今天我们就说说事件背后的攻击链路，以及如何检查和加固你的设备。
Part 1
两分钟拿到 root 权限
在这轮集中爆发中，很多中招用户最大的困惑是：明明设了十几位的复杂密码、开了手机令牌二次验证、还打开了输错 5 次密码自动封锁 IP，为什么黑客还是像进自家后院一样把文件全锁了。
10 月 28 日，Reddit 社区 r/synology 板块的用户 u/NakamuraHwang 发布了一篇详尽的现场取证帖（Well, it finally happened. My first real ransomware incident），第一次从底层日志还原了攻击者免密破门的全过程。
▲ 受害者群晖 File Station 目录下文件被批量追加 .L0CK3D 后缀并生成 read-me3.txt
这名用户在发现自家群晖 DS918+ 出现 .L0CK3D 后缀文件时，当时就拔掉电源打断了加密进程，随后没有盲目重启或重装系统，而是把硬盘拆下来插到一台离线隔离的 Proxmox 服务器上，全程以只读模式（blockdev –setro 配合 nologreplay）挂载并提取了 /var/log/ 下的系统日志。
日志里记录的时间线非常紧凑：
1. 异常登录请求：在机器时间 13:45 左右，公网暴露的 DSM 网页登录接口收到了一条奇怪的登录请求，系统日志将其记录为一次普通的「登录失败」。
2. 环境变量注入：翻看底层认证日志可以发现，攻击者在提交的「用户名」字段里，恶意拼接了 PLUGIN_VALUE_END、LD_PRELOAD 与 LD_DEBUG_OUTPUT 等特殊字符串。
3. 植入计划任务并清理痕迹：仅仅两分钟后的 13:47，系统最高权限账户 root 自动执行了定时任务 /etc/cron.d/synot*，并在删除日志 rm.log 中留下了清理临时文件 synotade.<PID> 的痕迹。
为什么一次「密码错误」的登录失败，会在两分钟后直接变成 root 权限执行任意代码。
这其实完全吻合安全公司 Rapid7 首席安全研究员 Ryan Emmons 在 DEF CON 33 大会上公开拆解的群晖漏洞利用链 Disguise Delimit（对应 Pwn2Own 大赛上攻破群晖的 CVE-2024-10441，CVSS 满分 9.8 分）。
用大白话来解释这个机制：群晖的网页登录框就像公司前台，当你输入用户名点登录时，前台会把你填的内容打包成一张内部表单，用特定的分隔符（PLUGIN_VALUE_END）隔开各个字段，交给后台拥有 root 权限的系统插件守护进程 synotade 去处理。
问题在于，旧版系统没有检查用户在「用户名」输入框里是不是自己偷偷塞进了这个内部横线分隔符。
攻击者直接在用户名里伪造了一个结束分隔符，并在后面追加了 Linux 动态链接器的环境变量指令（LD_PRELOAD 和 LD_DEBUG_OUTPUT），诱导系统底层的 glibc 动态加载器在校验账号之前，就以 root 权限往系统的计划任务目录 /etc/cron.d/ 里强行写进了一行恶意脚本。
前脚网页界面还在礼貌地提示「登录失败」，后脚写进 /etc/cron.d/ 的恶意指令已经被系统当成合法定时任务拉起来跑了。
这也解释了为什么强密码、双重验证（2FA）和自动封锁 IP 在这类免认证远程代码执行（Unauthenticated RCE）漏洞面前会集体失效：因为恶意代码在走到密码核对与二次验证那一步之前就已经执行完毕，而且全程只需要发送一次请求，根本不会触发输错 5 次封 IP 的阈值。
更值得注意的一个跨国细节是，Reddit 用户 u/NakamuraHwang 从计划任务里解码出的 Base64 恶意指令，指向了一个存放下载脚本的服务器地址 http://46.8.78.122/xdy5.sh。
而在国内 V2EX 社区的求助帖（https://v2ex.com/t/1252735）中，另一位中招的白群晖用户翻看自家残留日志时，同样在加密开始前 8 分钟（10 月 28 日 14:46:46）抓到了完全相同的境外 IP 46.8.78.122 发起的「失败登录」。
这证实了昨天海内外集中爆发的群晖勒索案，正是同一批自动化扫描器在全球公网范围内实施的无差别收割。
▲ 部分受害者在文件被加密前收到群晖日志中心数据库 .SYNOACCOUNTDB 损坏的邮件告警
Part 2
为什么最新版 DSM 也中招了
随着更多受害者晒出系统截图，社区里出现了第二个争议焦点：国内 Solar 应急响应团队在上机排查一台受灾的群晖 RS1221+ 时发现，这台机器运行的已经是群晖在 2026 年 10 月 12 日刚刚发布的最新版本 DSM 7.4.1-90080 Update 1。
▲ Solar 应急响应团队排查发现部分受灾设备已处于最新版 DSM 7.4.1-90080 Update 1
综合美国网络安全和基础设施安全局（CISA）、新加坡网络安全局（CSA）、比利时安全机构 nxtbit 以及国内 360 反勒索团队与 Solar 团队的交叉排查，2026 年 10 月下旬针对群晖 NAS 的攻击实际上叠加了三条不同的风险脉络。
1. 9 月刚披露的 DSM 双 9.8 分高危漏洞（Synology-SA-26:13）
除了像 Reddit 受害者那样因为早年更新踩坑而关闭自动更新、停留在 DSM 7.2.1 Update 5 的老版本设备外，360 反勒索团队在采样分析本轮中招设备后确认，黑客大规模利用了群晖在今年 9 月 18 日刚刚披露的两个高危远程漏洞：CVE-2026-13639 与 CVE-2026-13684（官方安全公告编号 Synology-SA-26:13，由 Viettel Cyber Security 等机构研究员发现）。
这两个漏洞的 CVSS 3.1 危险评分同样高达 9.8 分：
1. 登录逻辑熵值不足（CVE-2026-13639）：DSM 登录逻辑在生成会话或认证凭据时随机性不足，允许未授权的远程攻击者直接预测或绕过校验并读写任意文件。
2. SCGI 输出转义缺陷（CVE-2026-13684）：DSM 的 SCGI 组件未正确转义输出内容，同样允许远程攻击者在不登录的情况下读写系统内的任意文件。
虽然群晖在 9 月底发布了修复补丁，但距今仅一个月左右，公网上仍有大量开启了端口映射（如 5000、5001 端口）但未及时安装 Update 补丁的设备，成为了这轮 1day 自动化脚本的首批猎物。
▲ 群晖针对 Synology-SA-26:13 高危漏洞发布的各分支最低安全版本号
2. PHP2Shell 漏洞（Synology-SA-26:14）
就在群晖勒索爆发的前几天（10 月 21 日），PHP 官方紧急修复了两个被统称为 PHP2Shell 的满分（CVSS 9.8）远程代码执行漏洞：CVE-2026-109618 与 CVE-2026-109619。
据 BleepingComputer 与亚马逊威胁情报团队（Amazon Threat Intelligence）报道，早在官方补丁发布前 4 天（10 月 17 日），黑客就已经在公网上利用这两个内存分配与全局请求状态残留漏洞展开扫描，美国 CISA 已于 10 月 27 日将其紧急列入「已知被利用漏洞目录（KEV）」。
科技媒体 TechRadar Pro 与比利时安全机构 nxtbit 随后专门撰文指出，PHP2Shell 对群晖、威联通（QNAP）、铁威马（TerraMaster）、绿联（Ugreen）和华芸（Asustor）等 NAS 用户构成了双重威胁：
1. 套件层面的暴露：群晖在安全公告 Synology-SA-26:14 中确认，尽管 DSM 系统内部自用的 PHP 组件不对外暴露，但凡是在套件中心安装了依赖 PHP 的对外服务，包括 Web Station、Synology Calendar、Mail Station、WordPress、phpMyAdmin、Joomla、MediaWiki、KodExplorer 以及第三方套件 IDrive，均直接暴露在 PHP2Shell 的远程代码执行风险之下。
2. PHP-FPM 架构的实锤受影响：比利时安全研究员 Raf Vandelaer 在群晖实机上测试发现，群晖的 Web Station 采用的是 PHP-FPM 模式，而 CVE-2026-109619（利用文件上传进度 session.upload_progress 触发残留内存重用）已在 PHP-FPM 环境下被证实可直接打穿。
事态严重到群晖在 10 月 22 日、28 日和 29 日连续三次追加公告，破例为已经停止生命周期支持（EOL）的 DSM 7.2、DSM 7.1、DSM 7.0 乃至老旧的 DSM 6.2 紧急推送了 PHP 安全更新包。
3. 为什么升级到最新 DSM 7.4.1 Update 1 依然会被加密
针对部分处于最新系统的设备同样中招的现象，Solar 应急响应团队与海外安全社区给出了非常克制且客观的研判：最新系统被加密，并不直接等于 DSM 本体存在未公开的 0day 漏洞。
在实际排查中，最新版 DSM 中招往往源于以下三种情况：
1. 升级前已被植入后门：设备在 9 月底或 10 月初尚未打上补丁时就已经被自动化脚本攻破并写入了计划任务或 SSH 公钥，后续虽然升级了 DSM 系统版本，但驻留的后门并未被清除，在 10 月 28 日统一触发加密。
2. 套件或 Docker 容器未同步更新：用户只升级了 DSM 操作系统，但套件中心里的 PHP 组件、Mail Station，或者在 Container Manager（Docker）里映射到公网的自建服务（如存在高危漏洞的旧版 GitLab、Confluence、自建 Web 站点）成了突破口。
3. 局域网电脑或凭据泄露：用户本地电脑感染信息窃取木马（Infostealer）导致保存的 NAS 凭据泄露，或通过局域网 SMB 挂载连带加密。
Part 3
拆解 C3RB3R 勒索样本
这次在群晖上肆虐的 C3RB3R，其实是 2016 年就已成名的老牌勒索软件家族 Cerber 针对 Linux 与 NAS 环境演化出的最新变种，采用「勒索软件即服务（RaaS）」模式运作。
▲ 受灾群晖设备中的文件被批量改名为 .L0CK3D
结合 Reddit 受害者提取的下载脚本 xdy5.sh 与 360 安全团队的样本逆向报告（样本 MD5：a1375e0f82ae86df528876c049b5a23c），可以看到这伙攻击者对群晖的底层结构非常熟悉。
1. 自动识别芯片架构
当恶意加载脚本以 root 权限跑起来后，它会依次干五件事：
1. 查杀安全进程：遍历并强行终止系统内常见的杀毒与安全监控进程。
2. 识别 CPU 架构：自动检测这台群晖是 Intel/AMD 的 x86_64 处理器还是 ARM 处理器，从而拉取对应架构的编译版勒索程序，这意味着几乎全系群晖机型都在其射程之内。
3. 建立防重运行标记：在系统目录下创建 /bin/l0ck.enc 标记文件，防止多个加密进程冲突。
4. 拉取双备份主程序：将核心加密程序下载保存为 /bin/qnetd 并赋予执行权限启动；如果失败，则自动下载备用载荷 /bin/libgld（早在 2023 年底攻击 Confluence 服务器时，该团伙就曾使用过一模一样的伪装文件名 qnetd）。
5. 自删痕迹：加密跑完后，脚本会自动把 /bin/qnetd、/etc/cron.d/ 下的计划任务以及 /bin/l0ck.enc 全部删掉，给事后溯源制造障碍。
2. 主动挑选加密目录
很多普通勒索病毒一进 Linux 系统就不管三七二十一乱加密一通，结果把系统关键库文件锁死导致机器直接宕机，连勒索信都展示不出来。
C3RB3R 为了保证群晖系统能正常开机让你看到勒索信，在代码里硬编码跳过了 /boot、/etc、/usr/syno、/var/packages 等 27 个群晖核心系统目录：
▲ C3RB3R 扫描时自动跳过的不加密系统目录列表
同时，它还会跳过 .exe、.dll、.sys、.msi、.bat 以及自身的 read-me3.txt 和 .L0CK3D 文件（这也是为什么前面受害者截图里，几十个文件全军覆没，唯独一个 rustdesk-1.4.1-x86_64.exe 安装包完好无损）：
▲ C3RB3R 扫描时跳过的文件名与扩展名列表
而在加密算法上，它采用了 ChaCha8（对每个文件单独生成 256 位密钥与 64 位 nonce）配合内置 RSA-2048 公钥的非对称加密方案，没有攻击者手里的私钥，目前在数学上无法暴力破解。
更狡猾的是它的「分级加密策略」。
因为 NAS 里动辄存着几万部高清电影和几十 TB 的大文件，如果从头到尾全量加密，可能跑上一整天都加密不完，很容易被听到风扇狂转的用户中途拔电源打断。
于是 C3RB3R 设计了一套兼顾速度与破坏力的抽样规则：
▲ C3RB3R 针对不同体积文件的分段抽样加密策略
对于大于 5MB 的普通大文件，它每隔 5MB 只加密头部的 1MB 数据，这样几秒钟就能废掉一部几十 GB 的蓝光原盘；但对于数据库、财务账套、虚拟机镜像等核心高价值资产，它在样本里内置了一份包含 187 个扩展名的「优先名单」（涵盖 .sql、.sqlite、.accdb、.mdb、.dbf、.vmdk、.qcow2、.vhdx、.iso 等），只要命中这份名单，无论文件有多大，一律不计成本执行 100% 全文件加密，彻底断绝通过数据恢复软件拼凑残余扇区的念想：
▲ C3RB3R 内置的不区分大小一律全文件加密的 187 个高价值扩展名
3. 全自动化收款
加密完成后，每个目录下都会生成一份带有 6 位专属设备识别码的 read-me3.txt 勒索信，指引受害者访问其勒索站点。
▲ C3RB3R 留在受害者目录中的 read-me3.txt 勒索信原文
Solar 应急响应团队追踪发现，这个团伙把暗网勒索页面做成了一套全自动的自助电商网站：
1. 免费试解密诱饵：网页提供「免费解密 1 个文件」的功能，允许受害者上传一个不超过 1024KB 的 .LOCK3D 小文件当场还原，以此证明他们手里确实捏着私钥。
▲ C3RB3R 暗网站点提供的单文件免费试解密页面（中文翻译）
2. 自动监控区块链放行：页面直接为每台受灾设备生成独立的比特币收款地址与二维码，赎金索要金额通常在 0.03696 BTC 至 0.085 BTC 之间（约合数千美元，且声称超过 5 天翻倍至 0.17 BTC），一旦监测到链上交易完成 6 次区块确认，网页就会自动刷出解密器的下载链接，全程几乎不需要黑客人工介入客服沟通。
▲ C3RB3R 暗网站点内置的比特币自动收款监测与解密器交付界面（中文翻译）
即便这套暗网系统看起来像模像样，国内外所有安全机构依然给出了完全一致的底线建议：绝不要支付赎金。
一方面黑客收款后给假解密器、或者拿着脱裤数据二次敲诈的案例比比皆是；另一方面，只要提前做好了正确的隔离备份，或者在发现异常的第一时间用对了处置手法，完全没有必要向犯罪团伙低头。
Part 4
几个教训
复盘这几天海内外几十位受害者的自述，有三个平时很容易被忽略的运维盲区，在这次实战中成了扩大损失的推手。
1. RAID 防不了文件被锁
不少中招用户在发现文件变成 .L0CK3D 后，第一反应是把做了 RAID 1 或 RAID 6 的硬盘拔下来插到电脑上试图读取镜像。
结果当然是徒劳的：因为勒索病毒是在操作系统文件系统层面直接改写文件，RAID 阵列不仅救不了你，反而会兢兢业业地在毫秒级时间内把被加密的乱码同步写入每一块镜像盘里，为你生成一份完美对称的加密副本。
2. 注意双向同步工具和外接挂载
一位国内受害者半夜听到群晖风扇狂转起床查看时，发现机器上的 Cloud Sync 同步套件正在高速运转，把刚刚生成的 read-me3.txt 和 .L0CK3D 加密文件源源不断地同步上传到他的多个 OneDrive 网盘里，把云端原本干净的备份挨个覆盖成了乱码。
同样，海外数据恢复机构 Recoveo 与 Reddit 网友也提到，很多用户习惯把充当备份盘的移动硬盘常年插在群晖的 USB 接口上；一旦黑客拿到 root 权限，外接 USB 盘和局域网可写挂载的目录会被一锅端掉。
3. 千万别为了防 PHP2Shell 而手欠卸载 PHP 7.4
这是比利时安全机构 nxtbit 在实机测试中发现的一个极其关键的隐藏大坑。
很多用户在看到群晖 Synology-SA-26:14 公告说旧版 PHP 存在严重漏洞且停止支持后，第一反应是打开套件中心，把里面看着很老的 PHP 7.4 直接卸载掉。
▲ 比利时安全机构 nxtbit 实测警告：卸载 PHP 7.4 会导致群晖强制连带卸载 Hyper Backup
千万不要这么干。
因为在群晖的底层依赖设计里，几乎所有个人与企业用户赖以生存的备份核心套件 Hyper Backup，都强制绑定了 PHP 7.4（仅仅用于在本地处理连接 Amazon S3 云存储的内部脚本）。
如果你强行卸载 PHP 7.4，群晖会顺带把你的 Hyper Backup 一起卸掉，导致所有定时备份任务当场停摆。
而且 nxtbit 经过抓包与源码验证确认：Hyper Backup 调用的 PHP 7.4 只在本地跑小脚本，根本不接收来自互联网的 Web 访问请求，因此即使 PHP 7.4 已经停止更新，只要你没有在 Web Station 里拿 PHP 7.4 去跑对外公开的网站，它留在机器里给 Hyper Backup 用是完全安全的。
Part 5
加固指南
无论你手头的群晖目前是否安然无恙，建议今晚抽出十分钟，对照下面两套方案完成自查。
场景 A：如果已经发现 .L0CK3D 文件或风扇狂转
万一不幸中招，请严格按以下顺序操作，切忌乱点重装：
1. 第一时间断网或关机止损：如发现文件正在被批量改名，普通用户最优先的目标是「立刻打断加密进程」，直接拔掉网线并长按电源键关机（从 Reddit 受害者的经验来看，及时关机往往能保住一大半还没来得及遍历到的共享文件夹）。
2. 拔掉外置盘并暂停云同步：立刻拔掉插在 NAS 上的所有 USB 移动硬盘，并登录你的百度网盘、OneDrive 或另一台异地 NAS，断开与这台受灾群晖的同步连接与授权，保住云端干净的历史版本。
3. 严禁重启进系统或运行磁盘修复：不要反复开关机，不要点击 DSM 的重置重装，也不要对硬盘运行 fsck 等修复工具，防止残留的日志、快照（Snapshots）或未被覆盖的文件块被二次破坏。
4. 检查 Btrfs 快照是否幸存：在这轮攻击中，多位受害者反馈 C3RB3R 的加密脚本只顾着遍历普通目录，并没有调用命令去清空 Btrfs 快照；如果你之前开启过 Snapshot Replication（哪怕只是普通本地快照），在离线安全环境下极有可能直接从快照里完整捞回全部数据。
场景 B：如果目前一切正常
对于尚未中招的用户，与其在网上焦虑讨论到底有没有 0day，不如直接把攻击面彻底关死：
1. 立刻关闭 DSM 管理端口的公网直连：登录家里或公司的路由器后台，删掉把群晖 5000、5001（或自定义管理端口）直接映射到公网的端口转发规则，同时关闭路由器的 UPnP 自动端口映射，如果非必要建议一并关闭 QuickConnect。
2. 核对并升级 DSM 与 PHP 套件底线版本：前往「控制面板 -> 更新和还原」，确保 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 以上；接着打开「套件中心」，把所有 PHP 套件、Synology Calendar、Mail Station、Web Station 全部更新到最新修复版。
3. 开启「不可变快照」与 3-2-1 离线冷备：如果你的群晖使用 Btrfs 文件系统且处于 DSM 7.2 以上，立刻打开 Snapshot Replication（快照复制）套件，为重要共享文件夹勾选「不可变快照（Immutable Snapshots，基于 WORM 一写多读技术）」，设定 7 到 14 天的锁定期，在锁定期内哪怕黑客拿到了 root 最高权限也无法删除或修改快照分毫；同时保持至少一块平时拔掉电源和网线的移动硬盘做定期冷备。
让 AI 帮你给群晖做一次安全体检
很多朋友平时很少进群晖后台翻日志，也不知道怎么查自己的机器有没有被植入过 synotade 临时文件或异常计划任务。
只要你的电脑和群晖在同一个局域网内，临时在群晖「控制面板 -> 终端机和 SNMP」里勾上 SSH 功能（查完记得随手关掉），然后打开你电脑上的 AI（比如 Claude Code、Codex 或 WorkBuddy），把下面这段提示词改一下 IP 发给它，让 AI 用只读命令帮你做一次全面体检：
我有一台局域网内的群晖 NAS（内网 IP：【填写你的群晖局域网IP】，SSH 端口：【默认22】，管理员账号：【填写你的管理员账号】，）。请通过 SSH 连接我的群晖（全程仅执行只读查询命令，不要修改或删除任何系统文件），帮我针对 2026 年 10 月爆发的 C3RB3R（.L0CK3D）勒索病毒及相关高危漏洞做一次安全体检，并输出中文排查报告：
1. 检查系统与套件版本：读取 /etc.defaults/VERSION 核对当前 DSM 版本与 buildnumber、smallfixnumber，对照 Synology-SA-24:20（CVE-2024-10441）和 Synology-SA-26:13（CVE-2026-13639 / CVE-2026-13684）判断是否已达标（如 DSM 7.2.1 需 >= 69057-12，DSM 7.4 需 >= 90075）；列出已安装的 PHP 相关套件及 Web Station、Calendar、Mail Station 版本，对照 Synology-SA-26:14（PHP2Shell）检查是否存在未更新组件。
2. 排查 C3RB3R 入侵指标（IoCs）：检查是否存在 /bin/qnetd、/bin/libgld、/bin/l0ck.enc、/tmp/log.0 等恶意残留文件；检查 /etc/cron.d/、/etc/crontab 及 /var/spool/cron/crontabs/ 下是否存在类似 synot* 或异常的 Base64 下载指令；检索 /var/log/ 下的认证与系统日志，排查是否出现过 PLUGIN_VALUE_END、LD_PRELOAD、LD_DEBUG_OUTPUT、synotade 或来自 46.8.78.122 的异常请求，以及 .SYNOACCOUNTDB.corrupt 报错。
3. 检查暴露面与快照状态：检查当前监听的网络端口、是否有公网 UPnP 映射痕迹，以及 Btrfs 存储空间是否已配置 Snapshot Replication 快照保护，最后给出具体的加固建议（检查完毕后提醒我关闭 SSH 服务）。
Part 6
最后
NAS 本来是家里最安静的一个角落，替我们存着几十年拍下的家人照片、工作文档和攒下的老电影，以及Amazing Video。
大多数人当初之所以把登录端口直接映射到公网，无非是图个出门在外掏出手机就能看眼文件的方便，或者因为某次升级踩了小坑就顺手关掉了自动更新。
把未经保护的 NAS 管理后台直接敞开在公网上，本质上就是把自家保险柜搬到大马路牙子上，指望路过的小偷恰好没带最新款的万能钥匙。
问题是，现在有了 AI 的加持，小偷越来越多，也越来越厉害了。
趁着今天机器还没事，花十分钟把公网端口关掉、把补丁打上，保个平安。
封面：Gemini
