写在前面
10月28日，我们发布了【勒索预警】群晖NAS最新版遭勒索病毒攻击，疑似涉及0day漏洞。文章发布后，团队持续跟进相关样本和受害反馈，并对L0CK3D勒索病毒程序的加密流程、密钥生成和内存残留进行了进一步分析。
目前可以确认的是：针对本文分析的勒索病毒程序样本，在加密器仍在运行、能够提取同一会话的密钥材料并保留完整加密文件等特定条件下，存在技术恢复数据的可能。 基于样本分析和互联网公开恢复思路，团队进行了实际测试，并开发了对应的密钥提取与解密工具。
需要先强调，这不是通用解密方案，也不代表所有 .L0CK3D 文件都能恢复。比如加密器退出、设备重启、样本不同或会话材料已被清除时，本文工具可能无法使用。 请先在隔离环境中备份并测试，不要直接对唯一一份加密数据批量操作。
一、为什么特定条件下可以恢复
本次分析对象为64位Linux ELF勒索载荷。样本使用ChaCha8加密文件正文，每个文件都有独立的32字节文件密钥和8字节nonce，并在加密文件末尾写入588字节数据。
这588字节尾部的前48字节，保存着由AES-256-CBC加密的文件密钥材料。用于加密这一密钥块的会话AES key和IV，在加密器运行期间保存在进程内存中，同一次运行环境处理的所有文件共用这一组会话材料。
因此，恢复过程并不是破解ChaCha8或RSA，而是在加密器仍运行时取得会话AES key和IV，再依次完成以下过程：
获取AES key和IV流程
勒索程序样本分析还显示，加密进程结束后相关内存会被操作系统回收。因此，本文工具的在线扫描方式以加密器仍在运行为前提。加密进程退出或设备重启后，通常不能再通过该方式直接提取密钥。
互联网公开案例中，也有受害者在发现加密后暂停进程、转储内存，并从内存中分析密钥材料，最终恢复部分文件。该个案与本次样本分析所指向的恢复条件相符，但仍只能作为特定场景下的参考。
公开案例展示了加密过程中转储内存并恢复部分文件的思路，相关讨论也受到关注
考虑到内存转储、密钥定位和文件尾部解析对操作经验有一定要求，团队将样本适配、会话密钥扫描、密钥块解析和正文恢复整合到 c3rb3r_memscan.sys 工具中，尽量减少手工操作。工具用于降低恢复门槛，不改变其适用条件。
二、使用前必须确认的条件
1.确认样本与文件特征
本文分析样本的主要特征如下：
| 项目 |
值 |
| 加密后缀 |
.L0CK3D，其中 L 后为数字 0 |
| 勒索信 |
read-me3.txt |
| 样本平台 |
64位Linux，x86_64 |
| 样本SHA256 |
802AC85D19DC6DB2B1849BB3499877280544D04A0AE94D4C408B6C321669903D |
仅凭后缀相同不能确认属于同一样本。其他架构、其他变种或尾部结构不同的文件，不能直接套用本工具。
2.确认加密器仍在运行
只有加密器仍在运行，且待恢复文件属于同一运行环境时，内存中的会话材料才可能有恢复价值。不要为了验证工具而再次运行勒索程序。
3.确认具备操作权限与备份条件
实时读取进程内存需要root权限。操作前应将加密文件和勒索信备份到独立存储，提取后的密钥材料也应单独备份。首次恢复必须使用 --keep-source 保留源文件。
需要先说明时间窗口：团队实际测试中，该加密器的加密速度可达约2至3 GB/s，实际速度受NAS性能、磁盘状态、文件类型和线程数量影响。该数据仅来自当前测试环境与样本，不代表所有设备。数据量较小时，往往很难在加密过程中及时发现；数据量较大且发现及时，才更可能保留事中恢复条件。
如果加密早已结束、设备已经重启，建议保留现场并寻求其他恢复路径，不要对本文在线扫描方式抱有过高预期。
三、详细使用方法
1.隔离设备并保护现场
发现文件正在或已经被加密后，先隔离NAS网络，阻止攻击者继续连接，也不要让其他业务继续向设备写入数据。
不要贸然关机、重启或终止相关进程，这些操作可能破坏内存中的恢复条件。不要直接重装系统，不要删除加密文件、勒索信和可疑进程文件。
条件允许时，以只读方式克隆存储，或将加密文件复制到独立介质后再测试。后续恢复应优先在独立副本上进行，不要覆盖唯一一份原始数据。
2.检查勒索进程是否仍在运行
在终端执行：
pgrep -af 'MATCH_802ac85d19dc6db2|L0CK3D|init-rsysd' || echo "勒索进程未运行"
测试环境中，pgrep 匹配到分析样本进程并返回对应PID。
如果返回相关进程信息，说明仍存在匹配进程，应尽快在保护现场的前提下继续操作。如果只输出 勒索进程未运行，表示没有匹配到相关进程，通常已不满足在线内存提取条件。
该命令只匹配本文样本的常见名称。攻击者可能修改进程名，因此没有输出不等于绝对未运行，有输出也不等于一定能够提取有效密钥，仍需结合进程路径和内存扫描结果判断。
3.提取会话AES key和IV
从团队官方工具中心获取工具后，将其放入一个独立工作目录，不要放在待恢复数据目录中。经分析，本文涉及的加密程序样本默认不加密处理.sys 后缀，因此工具使用 c3rb3r_memscan.sys 作为文件名。
进入工具所在目录，执行：
chmod 755 c3rb3r_memscan.sys
sudo ./c3rb3r_memscan.sys
工具会扫描进程PID，在适配样本的固定地址 0x5427F8 读取全局会话指针，定位由16字节IV和32字节AES key组成的48字节会话对象。成功提取后，程序会输出key和IV，并在工具所在目录生成 key.sys。
测试环境中，工具输出会话key和IV并生成 key.sys
key.sys 包含敏感密钥材料，应妥善备份并限制访问，不要对外公开。出现 UNVERIFIED_POINTER 时，表示指针结果尚未通过验证文件确认，不等于密钥一定正确，必须先进行单文件测试。
如果出现以下报错，通常与工具目录写权限不足有关，应使用 sudo 执行，并确认当前账号可以向工具所在目录写入文件：
key file error: cannot create /path/to/tool/key.sys
4.先解密一个文件进行验证
生成 key.sys 后，选择一个已经备份的非核心 .L0CK3D 文件进行测试：
sudo ./c3rb3r_memscan.sys --decrypt /path/file.db.L0CK3D --keep-source
解密一个文件进行测试（状态成功）
工具默认会在解密成功后删除源 .L0CK3D 文件。首次处理重要数据时必须添加 --keep-source**，不要直接使用默认模式批量操作。**
解密完成后，应实际打开输出文件，核对文件内容、大小和可用性，不能只看终端是否返回成功。数据库、虚拟机和压缩文件还应进行相应的完整性检查。
如果目标位置已经存在同名输出文件，例如同时存在 1.txt.L0CK3D 和 1.txt，工具默认不会覆盖，并会返回失败。此时应先核对同名文件，将其移至独立备份目录后再测试，不要为了继续执行而直接删除数据。
5.单文件验证通过后再批量恢复
确认测试文件可以正常使用后，再处理目标目录：
sudo ./c3rb3r_memscan.sys --decrypt /path/to/encrypted/files --keep-source
目录模式只处理以 .L0CK3D 结尾的文件。使用 --keep-source 时，工具会保留原始加密文件，并生成去掉 .L0CK3D 后缀的恢复文件。
测试输出显示21个文件成功、1个失败，提取密钥后仍需逐文件核对恢复结果。
实测恢复NAS中被L0CK3D加密的数据文件（状态成功）
成功提取密钥不等于所有文件都能恢复。文件被截断、尾部被改写、来自不同运行会话或正文已被篡改时，仍可能失败。正文没有认证标签，工具可以验证密钥块和处理流程，但不能证明正文从未被篡改。
批量处理后，应保留终端日志和失败文件清单，不要反复对同一原始文件写入。恢复完成后，还需逐项检查重要业务文件是否真实可用。
6.已有key和IV时的使用方法
如果已经通过其他取证方式取得同一会话的key和IV，可以不重新扫描内存，直接传入参数：
sudo ./c3rb3r_memscan.sys \
--decrypt /path/to/files \
--aes-key <64个十六进制字符> \
--aes-iv <32个十六进制字符>
已有key和IV时的使用方法图示
key和IV必须来自加密这些文件的同一次运行环境。不同会话的材料不能混用，填入后也应先进行单文件验证。
四、工具下载
工具附件：
c3rb3r_memscan.zip
(286.45 KB, 下载次数: 26)
解压密码：solarsecurity
本次工具已附在附件中，直接下载即可。
五、关于入侵入口的信息更新
除恢复方法外，大家同样关心攻击者究竟通过哪个漏洞进入设备。
群晖官方近日发布群晖提醒尽快更新 DSM，防范旧版本面临安全威胁，说明恶意攻击者正在利用2024年12月已完成修复的安全弱点，攻击仍运行旧DSM版本的设备。
这份官方信息为排查提供了重要方向，但没有指明本轮事件对应的具体CVE，也不能证明所有受害现场都由同一入口造成。假设按照官方说法，那么此前网传将CVE-2026-13639、CVE-2026-13684作为本轮统一入口的说法，则不一致，不应继续作为结论传播。
我们此前根据初期集中受害反馈，将事件表述为“疑似0day”。随着官方说明发布，当前判断也需要相应调整：应优先排查Synology-SA-24:20涉及的旧漏洞、设备实际补丁状态和入侵时间，不再用“疑似0day”概括全部事件。
根据团队接到的数十起事件反馈，DSM 7.2.1至7.2.2占比最高，7.4.0至7.4.1占比较低。该统计仅来自团队已经接触的反馈样本，不代表整体受害分布。 其中还需排除黑群晖、部分组件未同步更新、升级时间晚于实际入侵等情况，版本大项也不能代替具体补丁号。
目前，团队仍在对受灾版本的日志和源码进行对比。若后续确认更具体的入侵入口或影响范围，我们会继续同步更新。
写在最后
本文工具解决的是特定样本、特定运行状态下的数据恢复问题，不是通用解密工具，也不能替代备份。操作时请始终保留原始加密文件，先单文件验证，再批量恢复。
数据恢复也不等于事件处置已经结束。文件恢复后，仍需继续排查入侵入口、异常计划任务、持久化项和账号凭据，避免设备再次被攻击。如果设备仍在加密，或无法判断样本是否适配，建议先隔离网络并保护现场，可联系专业团队协助。
[复制链接]
发表于 2026-11-2 16:42
分享到朋友圈
