10月28日，一些群晖用户打开共享文件夹，发现文件名后面多了七个字符：.L0CK3D。每个目录里还躺着一封 read-me3.txt。
硬盘没坏，文件也都在，只是打不开了。
群晖10月29日发布安全提醒：攻击者利用一个此前已经修复的漏洞，目标仍是运行旧版 DSM 的设备。群晖
360 的通报指向另一处。今年9月披露的两个高危漏洞，CVSS 评分 9.8，对应公告 Synology-SA-26:13，补丁9月18日就发了。
Solar 应急响应团队检查的一台受害机器，跑的是10月12日发布的 DSM 7.4.1-90080 Update 1，当时的最新版。入侵入口还在溯源，不能据此认定最新版有 0day。知乎
几份说法没对齐，能确认的只有两件事：补丁发了一个多月，还是有人没装；最新版中招，不等于最新版有洞。
攻击者也可能从套件、泄露的凭据或别的暴露服务进来。这一轮里，改端口、换强密码、开二次验证，也未必拦得住。入口如果在登录之前，密码再长也排在后面。
更值得看的是另一条线：有人没交赎金，把文件解了。
一位开发者的 DSM 跑在 PVE 虚拟机里。他从整机内存镜像中取出 48 字节会话密钥，恢复了 GitLab 业务。
另一位受害者的机器是物理黑群晖 DS918+，DSM 7.2，没有虚拟化层。
他在加密进程还活着时用 kill -STOP 把它冻住，从 /proc/PID/mem 导出内存，取出同一把 48 字节密钥。
84,500 个文件、940GB，全部解开，抽样逐字节一致。 两个项目都开源：soimy/c3rb3r-rescue 和 Benjamin-zlt/c3rb3r-baremetal-rescue。GitHub
这也解释了应急指南的第一条为什么总是：别重启，别关机，别 kill -9。密钥只在内存里，进程一退、机器一重启，这条路就断了。先断网，最后才重启。
但内存不是万能钥匙。工具只针对已分析的样本和加密格式，每个人的会话密钥也不同。重启过的机器，只能回头找快照和离线副本。GitHub
比恢复更该改的是备份的位置。
RAID 防的是硬盘坏，不防有人拿着 root 删你的文件。同一台 NAS 上的普通快照，管理员权限到手后也能一起清掉；开了不可变保护期的快照，才挡得住这一步。
云同步更糟：它会把加密后的版本同步上去，等于帮你扩散。
能救命的副本得满足两个条件：物理上拔得掉，账号上不相干。移动硬盘备份完就断线；重要资料再留一份在另一个地方、另一套账号里。
入口也一样。开了 DDNS 和端口映射，把 DSM 的 5000、5001 端口送到公网，就是把管理后台挂在门外。 要远程就走 VPN 或 Tailscale；IPv6 防火墙也别漏。知乎
NAS 厂商把它包装成家电，插上电、连上 App 就能用。可接上宽带后，它是一台 24 小时在线的服务器。家电不用你打补丁，服务器要。
这次被锁住的，不只是 84,500 个文件。还有很多人心里那句“我有 NAS，所以数据是安全的”。
数据的安全感，不该来自它一直在转，而该来自某一天你能把它整个拔掉，回头一看，东西还在。
