写在前面

本文首发于Solar应急响应团队「州弟学安全（徐龙州）、CHQ」，转载请务必注明出处。

Solar应急响应团队由思而听（山东）网络科技有限公司组建，长期专注勒索病毒应急响应、攻击溯源与数据恢复，为遭遇突发勒索事件的企业提供7×24小时突发危机干预通道。

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.确认样本与文件特征

本文分析样本的主要特征如下：

仅凭后缀相同不能确认属于同一样本。其他架构、其他变种或尾部结构不同的文件，不能直接套用本工具。

2.确认加密器仍在运行

只有加密器仍在运行，且待恢复文件属于同一运行环境时，内存中的会话材料才可能有恢复价值。不要为了验证工具而再次运行勒索程序。

3.确认具备操作权限与备份条件

实时读取进程内存需要root权限。操作前应将加密文件和勒索信备份到独立存储，提取后的密钥材料也应单独备份。首次恢复必须使用 --keep-source 保留源文件。

需要先说明时间窗口：团队实际测试中，该加密器的加密速度可达约2至3GB/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必须来自加密这些文件的同一次运行环境。不同会话的材料不能混用，填入后也应先进行单文件验证。

四、工具下载

工具将通过以下两个官方页面发布，可在工具中心搜索L0CK3D，具体名称、版本和更新说明以页面实际上架内容为准：

https://应急响应.com/tools
https://应急响应.cn/tools.html

应急响应.com工具中心提供勒索病毒恢复工具下载入口

应急响应.cn工具中心可按工具名称检索并下载

页面公布的下载文件解压密码为solarsecurity。如果暂未检索到本工具，可稍后刷新页面或通过文末方式联系团队，不要下载来源不明的同名程序。

五、关于入侵入口的信息更新

除恢复方法外，大家同样关心攻击者究竟通过哪个漏洞进入设备。

群晖官方近日发布群晖提醒尽快更新 DSM，防范旧版本面临安全威胁，说明恶意攻击者正在利用2024年12月已完成修复的安全弱点，攻击仍运行旧DSM版本的设备。

这份官方信息为排查提供了重要方向，但没有指明本轮事件对应的具体CVE，也不能证明所有受害现场都由同一入口造成。假设按照官方说法，那么此前网传将CVE-2026-13639、CVE-2026-13684作为本轮统一入口的说法，则不一致，不应继续作为结论传播。

我们此前根据初期集中受害反馈，将事件表述为“疑似0day”。随着官方说明发布，当前判断也需要相应调整：应优先排查Synology-SA-24:20涉及的旧漏洞、设备实际补丁状态和入侵时间，不再用“疑似0day”概括全部事件。

根据团队接到的数十起事件反馈，DSM7.2.1至7.2.2占比最高，7.4.0至7.4.1占比较低。该统计仅来自团队已经接触的反馈样本，不代表整体受害分布。其中还需排除黑群晖、部分组件未同步更新、升级时间晚于实际入侵等情况，版本大项也不能代替具体补丁号。

目前，团队仍在对受灾版本的日志和源码进行对比。若后续确认更具体的入侵入口或影响范围，我们会继续同步更新。

写在最后

本文工具解决的是特定样本、特定运行状态下的数据恢复问题，不是通用解密工具，也不能替代备份。操作时请始终保留原始加密文件，先单文件验证，再批量恢复。

数据恢复也不等于事件处置已经结束。文件恢复后，仍需继续排查入侵入口、异常计划任务、持久化项和账号凭据，避免设备再次被攻击。如果设备仍在加密，或无法判断样本是否适配，建议先隔离网络并保护现场，可联系Solar应急响应团队协助。

文章撰写与优化：州弟学安全（徐龙州）

逆向分析与工具开发：CHQ

排版优化：超级油麦

在企业日常的安全运维中，突发勒索病毒往往让人措手不及。遇到这种情况，正确的应急响应流程能够最大程度控制影响范围、降低数据损失。

这里为大家准备了一张完整的《勒索病毒应急处置指南》长图，建议各位安全从业者和IT运维人员收藏备用。如遇突发情况，请保持冷静，参考本图进行快速、规范的处置

附加资料下载：防御与响应同样重要。扫描图末的二维码，还可以直接获取完整的《2025年勒索病毒年报》、《2026年勒索病毒上半年报》以及《勒索处置一体化》等专业文件，帮助大家深入了解当前的威胁趋势，提前做好防御规划。

安全无小事，掌握科学的处置流程，是我们应对突发安全事件最有效的武器。