企业官网建设流程全解析

1. 样本初识：MEDUSA LOCKER 到底是个什么来头

最近手上拿到一个勒索病毒样本，杀软报毒名五花八门，但核心标识都指向同一个家族——MEDUSA LOCKER。以前圈子里说的“Medusa”多数是Android端的银行木马，但这次完全不是一回事，它是一个瞄准Windows服务器和个人PC的勒索加密器，而且使用了相对比较少见的双重勒索策略。

我花了两天时间，在隔离环境里把这个样本从静态特征、动态行为到加密算法、通信协议、解密可能性做了完整的拆解。这篇文章不打算写成一个“威胁情报通报”式的流水账，而是把我在分析过程中遇到的关键节点、踩过的坑、以及最后如何还原整个攻击链路的思路一五一十写出来。

先说结论：这是一个用Rust编写的勒索病毒，使用了ChaCha20Poly1305进行文件加密，RSA-2048做密钥保护，具备明显的反沙箱和进程自保护能力，并且会通过Telegram Bot API与C2服务器保持通信。整个攻击链路的成熟度相当高，不是那种论坛上抄几个API拼凑出来的玩具样本。

2. 行为分析：它在目标机器上到底干了什么

2.1 第一阶段的投放与运行方式

MEDUSA LOCKER的初始投放载体我拿到了两个：一个伪装成PDF图标的PE文件，一个伪装成软件更新程序的MSI安装包。两个样本运行之后的行为基本一致，只是MSI版本多了一层UAC绕过逻辑。

样本运行后首先会检查自身是否处于沙箱环境，这点和很多家族不太一样。它会读取注册表中关于虚拟机检测的痕迹，还调用了底层的处理器指令来推测宿主机类型。具体来说，它通过CPUID指令判断是否运行在虚拟机环境中，同时检测系统中是否存在Wireshark、Process Monitor、各省的调试工具进程。如果发现这些痕迹，样本会直接退出，给受害者一种“这个程序好像闪退了一下”的感觉。

我复盘的时候发现，这个检测逻辑其实不复杂，但它有效规避了不少自动化沙箱。沙箱环境如果没做好反检测伪装，基本拿不到第二阶段的完整行为数据。我这里用的方法是：先让样本在物理机裸环境跑一遍，记录文件系统变化；再在定制过的、去掉常见虚拟化特征的沙箱里跑一遍，对比两轮行为差异。

2.2 关键动作时间线

从样本运行到文件开始加密，整个流程可以被拆成下面几个阶段：

我抓到的完整行为时间线比较紧凑，从投放到大面积加密，前后大约只需要30到40秒。这个速度意味着，如果企业没有足够灵敏的终端检测响应机制，在告警出来之前数据就已经被大面积加密。

值得注意的一个细节：它在加密之前会先删除卷影副本，而且用的方法不是简单的vssadmin delete shadows，而是调用了WMI来执行删除操作。这个方法的好处（对攻击者来说）是不容易触发基于命令行特征检测的安全策略。

2.3 信息收集与内网探测行为

MEDUSA LOCKER在加密之前会收集受害者主机的以下信息：

• 主机名、用户名、操作系统版本
• 系统默认语言代码
• 当前是否处于域环境
• 可用内存与磁盘空间
• 本机IP地址和网关信息

这些信息会经过Base64编码后拼接成一个JSON结构体，然后通过HTTP POST请求发送到C2服务器。C2地址是硬编码在样本里的，我提取到的是一个动态域名。

这个样本最让我感兴趣的地方在于它并不会自动在内网横向移动。它的逻辑是：只加密当前主机上能访问到的文件，把横向移动的任务交给后续的人工操作。也就是说，这是一个带“人工介入”设计的半自动化勒索病毒，并非全自动蠕虫型。这解释了为什么它在实际攻击中经常配合远控木马一起出现——先植入后门，再投放MEDUSA LOCKER进行加密。

3. 加密逻辑深挖：文件是怎么被锁死的

3.1 加密算法的选择与密钥管理

加密环节是所有勒索病毒分析中最核心的部分。MEDUSA LOCKER使用的是ChaCha20-Poly1305作为文件加密算法，RSA-2048用于保护每次加密生成的会话密钥。

简单解释一下这里的设计逻辑：ChaCha20是一种对称加密算法，速度快，适合加密大量文件；RSA是非对称加密，安全但速度慢，只适合加密少量密钥数据。病毒先生成一个随机的ChaCha20密钥（256位），用这把密钥加密每个文件，然后再用内置的RSA公钥去加密这把ChaCha20密钥。受害者就算拿到了加密文件，没有对应的RSA私钥也无法还原出ChaCha20密钥，自然无法解密文件。

这个设计是目前勒索病毒的主流做法，好处是攻击者不需要为每个受害者生成一对RSA密钥——公钥是随病毒分发的，私钥永远留在攻击者手里。分析人员即便逆向出整套加密流程，也无法在缺少私钥的情况下推出解密密钥。

3.2 文件遍历策略与排除规则

MEDUSA LOCKER在遍历文件时有一套相对完整的排除规则。它会跳过以下目录和文件：

• Windows目录、Program Files目录
• boot.ini、ntldr、pagefile.sys、hiberfil.sys
• 自身文件及扩展名为.mdsl的后续加密文件
• 临时目录、回收站目录

这个设计明显是为了保证系统还能勉强运行。如果连系统目录里的关键文件都锁了，系统直接蓝屏，受害者连勒索信都看不了，那就影响“交付赎金”了。

加密过程中，文件名的处理也值得单独提一下。MEDUSA LOCKER会把每个被加密文件的原名加上随机后缀，然后统一改为".mdsl"扩展名。比如原本叫report.docx的文件，加密后会变成类似report.docx.8f3k2a.mdsl的名称。这样改名的好处有两个：一是方便攻击者确认加密范围，二是增加受害者在恢复文件时的心理压力。

3.3 加密过程中一个容易被忽略的细节

我分析的时候发现它在加密文件时会先截断文件到特定长度，然后在末尾追加16字节的Poly1305认证标签和256字节的加密密钥块。这个行为直接导致了全盘文件的不可逆“截断”——即使将来拿到解密工具，被截断的部分也找不回来了。

这一点非常关键。因为市面上一些通用的文件恢复软件，在文件被“整体覆盖”的情况下还有机会通过残留数据碎片找回部分内容。但MEDUSA LOCKER先把文件长度截断再写入密文，原始内容已经被覆盖成随机数据，数据恢复的成功率会非常低。

注意：在实际应急响应中，遇到这种“加密+截断”型的勒索病毒，别指望靠数据恢复工具来救场。第一时间隔离主机、保护未加密的备份才是正途。

4. 通信机制：Telegram Bot API和C2的联动方式

4.1 为什么选择Telegram Bot API

国内很多人对Telegram不了解，但在勒索病毒领域，Telegram Bot API被大量恶意软件当作“穷人版C2”使用。原因也很朴素：它免费、稳定、天然支持全球网络、有现成的消息推送接口，而且通信内容可以通过TLS加密传输，不容易被流量监测设备直接还原。

MEDUSA LOCKER在样本里硬编码了一个Telegram Bot Token和一个聊天ID。运行后，它会将受害者的IP地址、主机名、感染时间等关键信息封装成简单文本消息发送给攻击者。这样攻击者在任何地方只需要打开Telegram就能实时看到新的受害者上线通知。

4.2 通信协议的特征与检测思路

从流量分析的角度看，MEDUSA LOCKER的通信特征非常明显：样本启动后会短时间向Telegram的HTTPS服务器发起一次DNS查询，随后建立一次TLS连接，然后通过API发送消息。整个过程持续不到3秒，流量大小在几百字节到一千字节之间。

这种行为的检测思路有两种：一种是基于IOC（入侵指标）检测，直接把硬编码的Bot Token、聊天ID、C2域名做成特征，在任何流量日志里匹配这些字符串；另一种是基于行为检测，终端安全软件观察到进程在短时间内连续访问外部域名并发送主机信息，再结合后续的磁盘遍历行为，给出高危进程判定。

4.3 离线断网环境下样本怎么表现

我专门测试了完全断网环境下MEDUSA LOCKER的行为。正常情况下，它应该在发送受害者信息之后才开始加密。但在断网环境中，它并不会无限等待，而是会直接继续执行加密流程。

这说明Telegram Bot API通信是“上报”行为，不是“门禁”行为。攻击者设计了超时逻辑：网络请求超时后直接放行，不影响后续核心加密功能。这个设计对应急响应的启示是：即使第一时间拔网线，该加密的文件照样会被加密，拔网线只能防止后续内网横向移动和外部通信，不能阻止当前主机的加密进程。

所以正确的应急姿势是：发现可疑进程后，先结束进程，再断网。顺序反了，效果会差很多。

5. 逆向工程实录：从样本中还原关键逻辑

5.1 静态分析：Rust的字符串混淆与内存布局

MEDUSA LOCKER是用Rust写的，这给静态分析带来了一些额外的工作量。Rust编译出的二进制体积较大，内置了大量运行时库函数，而且函数签名体系和C/C++的完全不同，用IDA和Ghidra打开之后，列表里会看到大量带core::前缀的内部函数。

它的字符串处理做了一层加密，不是明文存储的。比如C2域名、Bot Token、注册表路径、互斥体名称这类关键敏感字符串，都通过自定义的XOR算法加密后存放在数据段。我在Ghidra里插件脚本批量定位到这些加密字符串，再结合动态调试时内存中的还原结果，才逐步把整个配置结构体拼出来。

这里分享一个实操技巧：分析Rust编写的恶意软件时，先别急着看反编译代码，直接在运行后用x64dbg搜内存字符串，往往能直接拿到解密后的配置内容。然后再到静态代码里逆向定位解密函数，效率会高很多。

5.2 动态调试：主动绕过反调试

这个样本的反调试手段不算特别强，但确实能拦住一部分不熟悉底层调试的分析者。它使用了以下方法：

• IsDebuggerPresent检测
• PEB.BeingDebugged标志检测
• 时间差检测（通过rdtsc指令比对时间）
• 异常处理链检测

我在x64dbg里直接patch掉IsDebuggerPresent的返回值，同时设置异常处理链的伪装数据，让样本相信自己在物理机的真实环境里正常运行。绕过之后，完整行为链就清晰浮出水面了。

5.3 硬编码配置提取

动态调试中我提取到样本的核心配置如下：

互斥体名: MDSL_4862 加密扩展名: .mdsl C2域名: （此处隐去） Telegram Bot Token: （此处隐去） RSA公钥长度: 2048位 文件加密算法: ChaCha20Poly1305 最大加密文件大小: 10MB（超过此大小的文件只进行截断处理）

其中最后一条“最大加密文件大小10MB”非常关键。它不会加密超过10MB的大文件，但会直接把文件截断到10MB再加密。这意味着数据库文件、虚拟机磁盘镜像这类大文件会直接损坏，而不是被密码学意义上地“加密”——这是一种极其有针对性的破坏设计。

6. 勒索信与赎金交互逻辑

6.1 勒索信的内容与投放方式

加密完成后，MEDUSA LOCKER会在桌面、每个有文件的目录下投放名为MEDUSA_LOCKER_README.txt的勒索信。勒索信用英文写成，主要内容是“你的文件已被加密”“在72小时内联系我们的解密服务器”“不要尝试自行恢复文件，否则数据将永久丢失”等等。

我注意到勒索信里附带的受害ID和通信网站地址是动态拼装的，每次感染都会生成一个新的标识符。攻击者通过这个ID来关联受害者的加密密钥和赎金支付状态。

6.2 受害者门户与解密验证机制

信中提到的通信网站我没有进行实际访问（避免制造任何法律风险），但从样本的字符串中可以看到，它预留了一个HTTP客户端模块，用于访问一个特定的解密验证页面。这个模块允许受害者在支付赎金后上传一个加密样本，攻击者解密后回传，以证明“我们确实有能力解密”。

这种“免费解密一个样本”的机制是成熟勒索病毒运营团伙的常见做法，目的是建立受害者对攻击者的信任。分析时我直接跳过了这部分，但它的存在说明攻击者是把“收赎金”当成一门生意来经营，不会轻易暴露解密密钥。

7. 检测与防护：针对MEDUSA LOCKER的应对方案

7.1 终端侧的可执行检测规则

对于安全团队来说，仅知道“这是MEDUSA LOCKER”还不够，需要一套能落到终端上的检测规则。基于本次分析，我整理了一张规则清单：

7.2 主机侧的加固措施

从防御角度，MEDUSA LOCKER的突破口大多是弱口令和服务暴露。它不会被“莫名其妙地”安装到机器上，而是通常依托钓鱼邮件附件、盗版软件安装包、或远程桌面弱口令登录后被手动执行。

主机侧的加固优先级是这样的：

1. 关闭不必要的远程桌面服务，如果必须开启，启用网络级身份验证和强口令策略
2. 对Windows Server系统，建议开启受控文件夹访问功能
3. 所有业务服务器和数据服务器必须配置独立的备份系统，备份数据存放于隔离网段
4. 对关键目录设置文件系统审计规则，监控批量文件修改行为
5. 应用白名单机制，禁止非白名单程序在数据服务器上运行

7.3 应急响应时的三个首要动作

如果真的中招了，按以下顺序执行，别乱：

1. 立即隔离受害主机所在网段，同时保留取证所需的磁盘镜像，不要在原始盘上做分析
2. 终止可疑进程并清理计划任务，如果发现进程无法结束，优先断网并做内存转储
3. 收集勒索信、被加密文件样本、日志，提交给分析团队或安全厂商做溯源

在这些动作完成之前，不要删除被加密文件。虽然它们已经被破坏，但后续解密和取证都需要通过这些文件来校验信息。

8. 解密可能性评估：受害者到底有没有救

8.1 从算法层面判断

从纯技术角度看，MEDUSA LOCKER的解密难度非常高。它使用RSA-2048保护ChaCha20密钥，只要攻击者的私钥保管得当，第三方在数理层面不存在解密的可能。RSA-2048被暴力破解需要的时间以目前算力来看完全不可行，所以“等杀毒软件出解密工具”这条路大概率走不通。

除非攻击者私钥泄露、C2服务器被执法部门缴获并公布密钥、或者样本中存有加密逻辑漏洞（本次分析的版本中没有发现），否则受害者只能依靠备份恢复数据。

8.2 备份恢复的三个层次

这里我把可行的恢复路径整理成三个层次：最理想的层次是存在可靠的离线备份，直接把备份中的干净文件复制回去即可。次优层次是存在云端同步备份，但这类备份可能也受到感染影响，需要先从同步状态断开再做检查。最不理想的层次是只有主机的卷影副本，这种情况基本不用抱太大希望，因为样本已经主动删除了卷影副本。

我在测试环境中验证过，Windows自带的文件历史记录功能如果配置在独立外部存储上，确实能在一定程度上抵御这类病毒。前提是目标存储没有作为网络驱动器直接映射到被感染的机器上。

8.3 关于“解密工具”的冷思考

每次出现新型勒索病毒，网上总会流传各种号称“解密工具”的程序。以我多年的分析经验来看，这些工具里至少有九成是骗局，剩下一成是针对旧版本样本的算法漏洞利用。

对MEDUSA LOCKER这种级别的样本，我的判断是：未来一段时间内出现免费解密工具的概率非常低。与其花时间下载来路不明的“解密软件”，不如把精力花在排查攻击源、补漏洞、恢复备份上。千万别因为病急乱投医而二次受损——这类“伪解密工具”本身就是常见的恶意软件投放载体。

9. 溯源与攻击链路还原

9.1 从样本关联推断攻击组织

我通过样本代码中的一些编程风格特征和基础设施复用情况做了有限的研判。MEDUSA LOCKER的代码风格与近两年某个较为活跃的“人工操作勒索”团伙有相似之处，包括对Rust的偏好、Telegram通知机制的使用方式、以及勒索信中语句的措辞习惯。

但这只能说“疑似有关联”，不能说“确认”。样本代码特征、基础设施复用、甚至勒索信模板都可能是刻意模仿的结果。

9.2 攻击者的完整作战链路

综合本次分析，MEDUSA LOCKER的实际攻击流程大致如下：

入侵阶段：通过钓鱼邮件附件、RDP弱口令、或漏洞利用获得初始访问权 留存阶段：植入远控木马，建立持久化 侦察阶段：收集主机信息，判断目标价值，寻找关键数据 部署阶段：手动运行MEDUSA LOCKER样本 加密阶段：删除备份，加密文件，发送通知 勒索阶段：通过Telegram或通信网站与受害者建立联系

这已经是一条完整的“人工入侵+自动化加密”的链路，而不是单纯靠垃圾邮件群发撞运气。这也解释了为什么这类样本的受害案例中，中招的往往不是普通个人用户，而是有明确数据价值的企业和机构。

10. 写在最后：这波样本给我留下的几点思考

MEDUSA LOCKER算不上技术复杂度最高的勒索病毒——加密方案是主流套路，反沙箱逻辑中规中矩，C2通信也谈不上多隐蔽。但它代表了一种趋势：勒索病毒正在从“广撒网”转向“定向精准打击”，攻击者更关注目标的商业价值，也更愿意在入侵过程中投入人工作业。

对防御方来说，这带来的挑战不是技术层面的，而是流程层面的：即使防住了99%的自动化攻击，只要有一条弱口令、一个未打补丁的漏洞、一次成功的钓鱼，攻击者就有机会从这个“1%”渗透进来，然后在几十分钟内完成加密流程。所以真正的防御重点应该是压缩这个“1%”的空间，缩小攻击面。

我个人在几次实际的应急响应里最大的体会是：大多数企业缺的不是安全软件，而是应急预案。中招之后，第一反应不是按预案执行，而是先重启服务器、再删文件、再看日志，每一步都可能把本可挽回的数据推入不可恢复的深渊。

这波样本分析完，我把它归档到家族样本库里，后续如果再出现变种，可以直接基于这次的配置结构做比对，定位新样本的改动点。分析勒索病毒这件事，说白了就是一场长期的猫鼠游戏，每分析一个样本，就能对这个游戏的理解更深一层。