最近两天，NAS 用户群里刷得最多的一句话，是「文件全变成 .LOCK3D 了」。
从 10/28 晚上起，到 10/29 白天，求助帖集中冒出来。有人 DS720+ 上两块盘做的 RAID1，文件被追加了 .LOCK3D 后缀，同目录里多出一封 read-me3.txt；有人把盘拆下来插到电脑上照样读不出——加密是在文件系统那一层做的，盘没坏，只是盘上躺的是一份加密得相当完整的副本。赎金开价 0.085 BTC，说五天不付翻倍到 0.17，还留了句「免费帮你解一个文件先看看」。
有个前提得先说清楚：这事不能当成 0day 写。做应急的 Solar 团队上机看过一台设备，跑的是当时最新的 DSM 7.4.1-90080 Update 1，他们的结论是「不能认定 DSM 本体存在 0day，也不能排除套件、插件或凭据被利用」。360 那边的反勒索团队方向更具体，把主入口指向 9 月就已经披露、也已经修过的两个洞——CVE-2026-13639（登录逻辑）和 CVE-2026-13684（SCGI 组件），都是 9.8 分，远程未认证就能读写任意文件。Synology 的公告号是 SA-26-13，9 月 18 日发的，没有缓解措施，只能升级。
所以「最新版也中招」这句话本身没错，但它的意思不是「升级白升了」，而是：光升 DSM 本体，不够。
真正难受的是「该做的都做了」这四个字。有用户说 2FA 开了、端口改了、SSH 也关了，最后还是中招。回头看，这几层防护其实各守着一个门：
RAID 不等于备份。 加密发生在文件系统层，RAID1 做的事，只是把「同一份被加密的文件」老老实实同步到两块盘上。它保的是盘的物理故障，保不了数据被人改写。
2FA、改端口、关 SSH，守的是 DSM 那道登录门。 如果攻击者压根不走登录这条路——先拿下同网段一台终端，用上面存着的凭据走 SMB 过去——门就不在这条线上。Solar 那句「不能排除凭据被利用」，分量就在这里。
Cloud Sync 会替病毒打工。 有用户发现，加密完成后，那封勒索信正被 Cloud Sync 同步到 OneDrive。云备份要是没开版本锁定或者不可变快照，删的是它、传的也是它，等于帮着把副本擦掉；最后救了人的，往往是另开了一份、没被覆盖的那个副本。
影响版本 / 修复版本（DSM，Synology SA-26-13）：
| 分支 | 受影响 | 修复 |
|---|---|---|
| 7.4 | < 7.4-90075 | 7.4-90075 及以后 |
| 7.3 | < 7.3.2-86009-4 | 7.3.2-86009-4 及以后 |
| 7.2.2 | < 7.2.2-72806-9 | 7.2.2-72806-9 及以后 |
| 7.2.1 | < 7.2.1-69057-12 | 7.2.1-69057-12 及以后 |
一条自查：
find /volume* -maxdepth 3 \( -name "read-me3.txt" -o -name "*.LOCK3D" \) 2>/dev/null | head有输出，就是已经中招了。版本在「控制面板 → 信息中心」里看；顺手再回一句：管理面、QuickConnect、DDNS 直连后台，是不是还开在公网上。
真中了，顺序也别乱：先拔网线隔离，再保留现场——系统日志、套件日志、登录记录、那封勒索信都别动，别急着重装，重装等于把唯一的证据抹掉。想救数据就别再往原盘上写；有团队是先把虚拟机内存保住，从里面把会话密钥 dump 出来的。至于赎金付不付，那是另一个问题——先把「怎么进来的」查清，不然清完还会再来一次。
勒索这类事我们写过两次，套路都差不多：IDCF Cloud 那次是7 分钟加密 3.6PB，运维 7 小时还在重启，输在没看见；还有那次删库，问题出在 token 一开始就给多了。这回群晖这波，落点不太一样：不是没做防护，是防护都做在了「登录」这件事上，而攻击面早就不是只有登录了。
Synology 官方公告：https://www.synology.com/en-br/security/advisory/Synology_SA_26_13
评论