2026-11-04 00:53:37 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

群晖 NAS 遭遇勒索攻击：最新版本也未能幸免？从 C3RB3R 事件看 NAS 安全风险

原创

网安cs
网安cs

cs攻防

2026年11月2日 13:37
北京

去阅读

导语

近日，群晖（Synology）NAS 勒索攻击事件引起安全行业关注。

2026 年 10 月 29 日，360 反勒索团队发布安全预警，披露近期出现多起针对群晖 NAS 的勒索攻击事件。经过样本分析，攻击者使用的是老牌勒索软件家族 Cerber 的变种，名称为 C3RB3R。

本轮攻击中，被加密文件会增加 .L0CK3D 后缀，并在受影响目录中留下 read-me3.txt 勒索信。

值得注意的是，本次事件不仅涉及已经公开修复的高危漏洞，还出现了运行较新 DSM 版本的设备遭遇勒索的报告。

这也引出了一个值得思考的问题：

如果 NAS 已经升级到最新版本，为什么仍然可能遭遇勒索？攻击者究竟是利用了 0day，还是通过其他方式完成了入侵？

本文从事件背景、漏洞分析、勒索软件行为、攻击入口判断以及企业应急防护几个方面进行梳理。

一、事件回顾：群晖 NAS 遭遇 C3RB3R 勒索攻击

根据 360 反勒索团队 2026 年 10 月 29 日发布的预警，今年 10 月以来，360 陆续接到多起群晖 NAS 遭遇勒索攻击的求助。

经过对受害设备和勒索样本进行分析，360 将本轮攻击的主要勒索软件归类为 Cerber 家族的变种 C3RB3R。

本次攻击表现出以下特征：

项目相关信息


攻击目标	Synology 群晖 NAS
勒索家族	C3RB3R（Cerber 变种）
加密文件后缀	L0CK3D
勒索信名称	read-me3.txt
对称加密算法	ChaCha8
非对称加密算法	RSA2048

涉及漏洞：CVE-2026-13639、CVE-2026-13684

从攻击目标来看，本次事件与传统针对 Windows 终端的勒索攻击存在一定区别。

NAS 通常承担企业文件存储、数据库备份、虚拟机备份以及部门文件共享等工作。

对于很多企业来说，NAS 不仅保存着大量业务数据，还承担着数据恢复的重要职责。

一旦 NAS 本身遭到攻击，受影响的可能不只是共享文件，还包括企业原本用于恢复业务的备份数据。

这也是本次事件值得关注的原因之一。

二、漏洞分析：两个 CVSS 9.8 高危漏洞

根据 360 的技术分析，本轮 C3RB3R 攻击涉及两个群晖 DSM 高危漏洞：


CVE-2026-13639	9.8	登录逻辑随机性不足
CVE-2026-13684	9.8	SCGI 输出编码处理不当

两个漏洞均被群晖列入 Synology-SA-26:13 安全公告。

1. CVE-2026-13639

该漏洞涉及 DSM 登录逻辑中的随机性不足问题。

根据群晖官方公告，攻击者可能利用该漏洞实现远程任意文件读取、写入以及拒绝服务攻击。

从漏洞性质来看，这并不是简单的登录失败次数限制问题，而是涉及登录逻辑中的安全随机性设计。

2. CVE-2026-13684

该漏洞涉及 DSM 中 SCGI 组件的输出编码处理不当。

根据群晖官方公告，该漏洞可能允许远程攻击者读取或写入任意文件，以及实施拒绝服务攻击。

两个漏洞的 CVSS 评分均为 9.8，属于严重级别。

需要注意，漏洞公告描述的是漏洞可能造成的安全影响，并不代表每一起勒索事件都已经确认完整利用了相同的攻击步骤。

3. 官方修复时间

群晖于 2026 年 9 月 18 日发布 Synology-SA-26:13，对相关漏洞进行修复。

对应修复版本如下：

DSM 7.4 7.4-90075 或更高版本

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 或更高版本

从漏洞披露和攻击时间来看，360 分析的这条攻击路径具有明显的 1day 漏洞利用特征。

也就是说，厂商已经发布修复方案，但仍有设备因为没有及时更新而暴露在攻击风险之下。

官方公告：

https://www.synology.com/en-global/security/advisory/Synology\_SA\_26\_13

三、这次究竟是 0day 还是 1day？

这是本次事件中比较值得讨论的问题。

首先需要明确几个概念：

0day：漏洞在厂商尚未提供有效修复方案时，已经被攻击者利用。

1day：漏洞修复方案已经公开，攻击者利用尚未安装补丁的设备进行攻击。

N-day：漏洞公开并修复一段时间后，攻击者仍然利用未修复设备实施攻击。

从 360 披露的信息来看，CVE-2026-13639 和 CVE-2026-13684 已于 2026 年 9 月 18 日发布修复方案，而相关勒索攻击在 10 月被披露。

因此：

针对 360 分析的这条攻击路径，更符合 1day 漏洞利用场景，而不是 0day。

但是，本次事件还有一个值得注意的情况。

2026 年 10 月 29 日，群晖方面也发布了相关攻击警示，指出攻击者正在利用此前已经修复的漏洞攻击旧版本 DSM，并引导用户查看 Synology-SA-24:20。

这与 360 对其分析样本的漏洞归因并不完全一致。

因此，目前不能简单认为所有受害设备都使用了同一漏洞入口，也不能将两份安全信息直接拼接成一条完整攻击链。

从现有公开资料来看，比较严谨的判断是：

360 分析的 C3RB3R 攻击样本涉及两个已经修复的高危漏洞，属于 1day 利用场景。

群晖另外指出存在针对旧版 DSM 已修复漏洞的攻击活动。

不同受害设备的实际入侵路径，仍然需要结合设备日志和样本进一步确认。

四、值得关注的异常：最新版本为什么也会被勒索？

如果说前面的漏洞利用还属于常规安全事件，那么本次事件中另一个现象就更值得关注了。

根据 10 月 29 日公开的相关受害案例，有安全团队披露，一台遭遇勒索的群晖设备运行的是：

DSM 7.4.1-90080 Update 1

这一版本已经高于 360 所列出的 DSM 7.4-90075 修复版本。

这意味着，至少在公开报告层面，已经出现了较新版本设备遭遇勒索的情况。

那么，问题来了：

既然已经修复相关漏洞，为什么设备还是被加密了？

从应急响应角度来看，不能直接认定这是新的 0day，需要考虑多种可能性。

1. 设备可能在升级之前就已经被入侵

这是最容易被忽略的一种情况。

假设攻击者在 9 月利用漏洞进入 NAS，并且已经完成了恶意程序部署或者持久化操作。

管理员在 10 月升级 DSM。

升级之后，原有漏洞可能已经修复，但攻击者之前留下的恶意程序、异常账户或者计划任务不一定会被清除。

例如：

攻击者创建了新的管理员账户。

攻击者植入了恶意脚本。

攻击者创建了异常计划任务。

攻击者窃取了管理员凭据。

攻击者已经在设备中部署了后续执行程序。

这时，即使 DSM 已经更新到修复版本，攻击者仍然可能继续执行后续操作。

补丁修复的是漏洞，不是已经发生的入侵。

2. NAS 可能不是最初的攻击入口

这一点尤其值得企业应急响应人员关注。

在企业环境中，NAS 通常通过 SMB、NFS 等协议向其他服务器和办公终端提供文件共享服务。

假设企业内部有一台 Windows 业务服务器被勒索软件入侵。

攻击者获取了该服务器中保存的 NAS 共享访问凭据，并且该账户拥有共享目录的写入权限。

那么攻击者就可能通过 SMB 对 NAS 中的文件实施批量加密。

整个过程可能是：

Windows 业务服务器被入侵 | v 获取 NAS 共享访问凭据 | v 通过 SMB 访问共享目录 | v 批量加密 NAS 中的文件 | v NAS 文件出现勒索后缀

在这种情况下，NAS 可能只是最终的数据加密目标，而不是最初的入侵入口。

DSM 即使已经升级到最新版本，也不能阻止一个拥有合法文件写入权限的恶意进程修改共享文件。

3. 管理员账户或访问凭据可能泄露

如果 NAS 管理员账号密码泄露，攻击者可能通过正常的管理功能执行恶意操作。

例如：

利用被盗账户登录管理后台。

修改共享文件夹权限。

创建异常用户。

修改计划任务。

安装或运行恶意套件。

因此，排查时不能只关注漏洞，还需要检查账户登录记录、权限变更记录和管理操作记录。

4. 第三方套件、容器和其他服务可能存在风险

群晖 NAS 并不只是 DSM 系统本身。

在实际使用中，管理员可能安装各种第三方套件、Docker 容器以及其他网络服务。

这些组件同样属于设备的攻击面。

如果相关服务存在漏洞、错误配置或者直接暴露公网，即使 DSM 已经更新，也不能排除攻击者通过其他入口进入设备。

不排除存在尚未公开的漏洞

当然，也不能完全排除攻击者利用了尚未公开的漏洞。

如果设备已经安装对应安全补丁，经过检查没有发现历史入侵痕迹，也没有发现其他明显的入口，那么就需要进一步调查是否存在其他漏洞利用行为。

但是：

最新版本遭遇勒索，并不等于已经证实出现了新的 0day。

要确认这一点，仍然需要结合设备日志、网络流量、恶意样本、漏洞利用痕迹和完整攻击时间线进行分析。

对于目前公开的最新版本受害案例，实际入侵原因仍未得到充分确认。

五、C3RB3R 勒索软件行为分析

根据 360 对样本的分析，C3RB3R 进入受害设备后，主要执行文件扫描、文件加密和勒索信息投放等操作。

1. 文件扫描

勒索软件会对设备中的文件目录进行递归扫描。

在扫描过程中，样本会跳过部分系统目录和指定类型的文件，以降低加密系统关键文件导致自身执行中断的风险。

对于符合加密条件的文件，则继续进行处理。

这种行为的主要目的是尽可能扩大数据加密范围。

2. 文件加密

本次样本使用 ChaCha8 + RSA2048 组合加密方案。

可以将其理解为：

ChaCha8 负责加密文件内容，RSA2048 负责保护文件加密密钥。

根据公开样本分析：

为待加密文件生成独立的 256 位密钥。

生成对应的 64 位 nonce。

使用 ChaCha8 对文件内容进行加密。

使用样本内置的 RSA 公钥加密相关密钥及元数据。

将相关加密信息附加到文件数据中。

修改文件扩展名，追加 .L0CK3D。

由于文件密钥受到 RSA 公钥保护，单纯修改文件扩展名无法恢复原始文件。

3. 勒索信投放

完成文件加密后，样本会在受影响的目录中留下：

read-me3.txt

同时，被加密文件会出现类似以下形式：

database.db.L0CK3D report.xlsx.L0CK3D backup.zip.L0CK3D

如果在群晖设备中发现大量 .L0CK3D 文件，并且多个目录出现 read-me3.txt，应当高度怀疑设备已经遭遇相关勒索攻击。

需要注意，这些特征可以用于初步检测，但不能单独作为最终家族归因依据。

六、企业应该如何防护？

针对本次群晖 NAS 勒索事件，建议从系统补丁、网络边界、账户权限、备份保护以及日志监控几个方面进行安全加固。

1. 及时更新 DSM 系统

首先，企业应当全面盘点内部所有群晖 NAS 设备。

重点检查：

DSM 系统版本。

是否安装 Synology-SA-26:13 对应补丁。

是否存在其他未修复的安全公告。

是否存在长期未更新的第三方套件。

对于涉及本次漏洞的设备，应升级到对应分支的修复版本或更高版本。

同时，不能只检查主站点设备，还要关注分支机构、实验室以及长期无人维护的 NAS。

2. 不要直接将 DSM 管理端口暴露公网

建议：

关闭不必要的公网端口映射。

不直接开放 DSM 管理后台。

远程管理优先使用 VPN。

对管理端口配置可信 IP 白名单。

开启 NAS 自带防火墙。

仅允许必要的业务网段访问。

对于确实需要远程访问的场景，应优先采用受控的远程接入方式，而不是直接将管理后台暴露在公网。

3. 加强账户和权限管理

建议：

禁用默认 admin 账户。

为不同管理人员建立独立账户。

设置高强度且唯一的密码。

开启双因素认证。

开启自动 IP 封锁。

删除长期不使用的账户。

定期审计管理员权限。

避免 NAS 与其他服务器共用管理员密码。

同时，普通业务用户不应拥有不必要的管理权限。

对于 SMB 共享目录，应按照业务部门和实际工作需求分配访问权限，避免所有用户都拥有广泛的写入权限。

4. 建立独立的备份体系

这是本次事件给企业带来的另一个重要提醒。

很多企业虽然部署了 NAS 备份，但生产环境和备份环境实际上并没有真正隔离。

建议建立多层备份体系：

第一层：本地快照

开启共享文件夹快照功能，在设备支持的情况下启用快照防篡改保护。

第二层：异地备份

将重要数据备份到另一台独立设备或者异地存储环境。

第三层：离线备份

至少保留一份与生产环境隔离的离线备份。

需要注意：

快照不等于独立备份。如果攻击者取得足够高的 NAS 管理权限，仍可能破坏快照及相关备份任务。

因此，备份系统应尽量使用独立账户、独立权限和独立管理边界，并定期进行恢复演练。

5. 加强日志监控

建议定期检查 DSM 日志中心，重点关注：

排查项目

重点内容

登录日志

异常公网 IP、陌生管理员登录

用户信息

陌生账户、权限变更

SSH 服务

异常登录、认证失败

计划任务

陌生任务、异常执行命令

套件中心

陌生套件、异常安装记录

网络连接

异常外联、陌生监听端口

文件系统

大量文件修改、删除、重命名

备份任务

异常中断、快照删除、备份失败

特别需要关注短时间内大量文件被修改或重命名的情况。

如果发现异常，应及时进行安全调查。

七、如果已经遭遇勒索，应该如何应急？

如果企业 NAS 已经出现批量文件加密，不建议第一时间重装系统或者恢复出厂设置。

建议按照以下步骤进行处置。

第一步：立即隔离设备

如果确认正在发生加密行为：

立即隔离 NAS 与外部网络的连接。

阻断其他业务主机对 NAS 共享目录的访问。

避免其他主机继续写入受影响目录。

保留设备当前状态和相关日志。

隔离过程中应注意保留必要的证据，避免盲目断电导致易失性信息丢失。

第二步：保留现场证据

建议采集以下信息：

系统信息 DSM 版本、设备型号、运行时间

登录记录登录 IP、登录时间、登录账户

用户信息用户、用户组、权限变化

系统日志 DSM 系统日志、认证日志

SSH 日志 SSH 登录、认证失败记录

计划任务定时任务、异常执行记录

套件信息已安装套件及近期变更

文件证据勒索信、加密文件、文件时间戳

网络信息监听端口、异常连接、外联记录

备份信息快照、Hyper Backup、异地备份状态

同时，对可疑样本计算 SHA256，保留原始文件及采集时间。

第三步：排查真实攻击入口

不要只检查群晖设备本身。

还应当检查：

路由器及防火墙公网访问日志。

NAS 管理后台访问记录。

是否存在异常管理员账户。

是否存在异常计划任务和启动项。

是否有其他服务器通过 SMB 访问 NAS。

是否存在凭据泄露或弱口令问题。

第三方套件和容器是否存在异常行为。

尤其需要判断：

究竟是攻击者直接控制了 NAS，还是其他已经失陷的服务器利用合法共享权限对 NAS 文件进行加密。

这一步直接关系到后续的攻击溯源和影响范围判断。

第四步：恢复业务

在确认攻击入口、排除持续入侵风险后：

检查快照及备份数据是否完整。

优先从可信的离线或异地备份恢复。

对恢复的数据进行安全检查。

修改 NAS 及关联业务系统的凭据。

重新配置网络访问控制。

恢复后持续监控异常文件操作。

不建议在没有确认恢复条件的情况下直接支付赎金。

八、总结：NAS 不是绝对安全的数据保险箱

本次群晖 NAS 勒索事件，再次提醒企业关注一个长期容易被忽视的问题：

NAS 虽然承担着企业数据存储和备份任务，但它本身同样是一套需要持续维护和安全运营的系统。

从本次事件可以看到，已公开修复的漏洞仍可能被攻击者利用，而最新版本设备出现受害报告，也说明仅凭系统版本无法完整判断设备是否安全。

对于应急响应人员来说，真正需要调查的不只是设备有没有打补丁，还包括：

设备是否在补丁发布之前就已经被入侵？

是否存在异常账户、计划任务和恶意程序？

是否有其他失陷主机通过 SMB 等协议加密 NAS 文件？

是否存在第三方套件、容器或其他服务的安全问题？

备份数据是否受到影响，能否独立恢复？

至于本次最新版本受害案例是否涉及新的 0day，目前仍需要更多证据才能确认。

补丁管理解决的是已知漏洞问题，而安全运营需要解决的是整个设备的持续安全问题。

不要把 NAS 当成绝对安全的存储设备，也不要把与生产环境处于同一信任边界的唯一一份备份，当成企业最后的安全保障。

附：本次事件 IOC 与排查参考

已公开 IOC：

类型

内容

勒索家族

C3RB3R

文件后缀

.L0CK3D

勒索信