2025年11月11日，我（州弟）接到了一起紧急勒索病毒排查任务。客户现场情况比较危急，核心业务系统瘫痪。

图1 正常流程排查

在获取客户授权并建立远程连接后，我对受灾机器进行了初步的信息收集与定性：

• 操作系统：Windows Server 2008 R2
• 加密量级：20万+ 文件
• 涉及业务：某系统ERP + 某财务软件 + SQL SERVER数据库
• 对外开放端口：RDP（远程桌面）、ERP端口、IIS目录服务

本次事件的特殊之处在于，它不仅仅是一次常规的加密，还包含了一次**"二次加密"**事故：由于在未溯源完毕和加固的情况下客户急于恢复生产，自行恢复生产环境，导致刚恢复的环境再次沦陷。

这篇文章将完整复盘此次事件的溯源与恢复全过程，希望其中涉及的排查思路和知识点能对大家有所帮助。

图2 最终交付报告

应急响应的第一步是确认对手是谁。通过提取客户被加密的文件样本和勒索信，结合特征分析，确认此次攻击源自Makop 勒索家族。

1. 勒索信特征

勒索信文件名为README-WARNING+.txt，内容具有该家族的典型话术风格。

图3 勒索信内容

2. 加密文件特征

被加密文件后缀被修改为：.[8位随机字符].[邮箱地址].AIR。例如：xls.[xxxxxx].[[email protected]].AIR。

图4 被加密文件特征

3. 特征确认

通过访问http://应急响应.com/，上述特征（后缀、邮箱、勒索信）均与 Makop 家族完全匹配。

图5 Solar应急响应官网

在确定勒索家族后，为了保障客户业务尽快上线，我第一时间将样本同步给了后端的病毒分析工程师进行研判。

得益于团队完善的样本库和技术储备，我们很快制定了针对性的恢复方案。在与客户约定的时间内，通过专业技术手段成功完成了数据库恢复工作。

数据虽然恢复了，但门没关上，危险就依然存在。按照标准流程，我立即对恢复后的环境进行了全盘镜像备份，防止原始日志丢失或二次破坏，随即展开溯源。

图6 数据备份工作

1. Web 与 数据库日志排查（排除法）

首先排查对外开放的 Web 服务。客户开放了 IIS 目录浏览和 ERP 接口。

• IIS 目录：虽然暴露了 web.config 等文件，其中可能包含数据库账号密码，但直接访问往往是 404，利用难度较大。
• ERP 接口：发现一个 ComQueryWs.asmx 接口，这类 WebService 接口常存在 SQL 注入或 XXE 漏洞。

图7 IIS目录 图8 webservice接口 图9 相关接口测试

我着重检查了近一个月的 Web 日志和 SQL Server 日志。虽然发现了不少来自互联网的扫描流量（如 Nmap 扫描、目录爆破、UEditor 漏洞探测等），但均未发现利用成功的痕迹。SQL 日志中也无 xp_cmdshell 等敏感操作记录。

图10 目录扫描攻击 图11 Ueditor漏洞攻击 图12 SQL日志溯源

2. RDP 日志排查（突破口）

结合Solar威胁情报中心查询 Makop 家族的 TTPs（战术、技术、过程），该家族更倾向于利用RDP 爆破或RDP 漏洞进行传播，而非复杂的 Web 渗透。

向客户确认后得知，虽然内网端口是 3389，但通过端口转发映射到了公网的 28801 端口。我随即重点排查系统安全日志（Security.evtx）。

2.1 异常的 Guest 登录

在排查日志时，发现了一个关键时间点：2025年11月10日 15:13，服务器开始收到大量 RDP 连接请求。

图13 RDP连接爆破

经过约半小时的暴力破解，在15:48，攻击者使用 IP 45.x.x.60（归属地：荷兰）成功爆破了Guest账号。

图14 荷兰IP爆破成功 图15 荷兰IP威胁情报

**这里引入一个重要的知识点：**默认情况下，Windows 的 Guest 账户是禁用的。为什么攻击者能爆破成功？通过分析审核失败的日志，我们可以看到差异：

• Guest 未禁用时：登录失败会提示 0xC000006D（未知用户名或密码错误）。
• Guest 已禁用时：登录失败会提示 0xC000006E（账户当前已禁用）。

图16 未禁用时登录失败日志 图17 禁用时登录失败日志

由此推断，客户服务器的 Guest 账户此前处于开启状态，这给了攻击者可乘之机。

2.2 提权与工具投放

攻击者通过荷兰 IP 爆破成功后迅速退出（典型的自动化脚本行为）。随后在18:26，一个 IP 为 117.x.x.89（归属地：江苏苏州，推测为跳板机/肉鸡）的地址登录了 Guest 账户。紧接着在18:37，该 IP 成功提权并登录了Administrator账户。

图18 江苏苏州IP登录成功 图19 江苏苏州IP威胁情报 图20 江苏苏州IP提权登录成功

18:39，攻击者为了隐藏踪迹，清除了安全日志（Event ID 1102），这是 Makop 家族的惯用伎俩。

图21 痕迹清理成功

19:06，系统服务日志显示攻击者安装了名为 KProcessHacker3 的服务。这是一个强大的内核级进程管理工具（Process Hacker），常被黑客用于对抗杀毒软件。

图22 黑客上传进程管理工具 图23 相关工具页面

随后，攻击者将加密器svchost.exe.exe（注意双后缀伪装）上传至C:Users\Guest\Desktop目录。

图24 黑客上传加密器成功

19:14，应用日志显示加密器运行报错，但这并未阻止加密进程，随后系统文件被大规模加密。

图25 黑客加密器报错

19:59，日志显示另一个北京 IP 36.x.x.179 登录成功。经确认非客户员工，推测可能是攻击者使用的另一个跳板机进行检查加密进度。

图26 跳板机二次登录检查加密进度

在第一轮数据恢复完成后，由于客户业务停摆压力巨大，急于投入生产。在尚未完成彻底溯源和系统重装的情况下，客户自行找了一台新服务器（Windows Server 2008），试图通过**"站库分离"**的方式来规避风险：

• Web 服务器（192.168.1.2）：即刚恢复数据但未重装的原中毒机器，依旧映射在公网。
• DB 服务器（192.168.1.100）：新搭建的数据库服务器，未映射公网，仅内网互通。

客户本以为做了分离就安全了，但意外还是发生了。次日早上10点，客户打来电话：机器又被加密了！而且这次是两台全军覆没。

这让我必须重新审视整个攻击链。

1. 突破口溯源：192.168.1.2 的再次沦陷

我首先排查了对外映射的 Web 服务器（1.2）。这里出现了一个非常诡异的现象。

我非常确定，在二次加密发生的前一天（11月17日），配合我溯源的同事已经对该机器的Guest账户进行了禁用操作，系统日志中也能查到明确的禁用记录。

图27 Guest用户已禁用 图28 Guest用户禁用日志

然而，在查阅次日（11月18日）的日志时，我惊讶地发现：Guest 账户竟然在 9:34 分再次登录成功了！

图29 Guest用户登录成功

这说明要么是人为重新开启了，要么是系统存在更底层的提权漏洞被利用。紧接着，我在日志中捕获到了攻击者的踪迹：

• 暴力破解（A组）：9:34，一个来自**俄罗斯（45.x.x.143）**的 IP 成功爆破进入系统。该 IP 在登录成功后立即注销退出，具有极其明显的自动化脚本特征。

图30 俄罗斯IP爆破成功 图31 俄罗斯IP威胁情报

投放加密（B组）：紧随其后，9:43，一个来自**江苏苏州（117.x.x.89）**的 IP 登录了进来。这个 IP 正是第一次勒索事件中投放加密器的 IP！

图32 江苏苏州IP登录成功

溯源结论：这展示了 Makop 家族典型的**"A IP爆破，B IP加密"**战术。攻击者利用国外的机器进行暴力破解扫描，得手后利用国内的肉鸡（苏州 IP）作为跳板进行登录操作，以规避地理位置告警并提高连接速度。

2. 内网横向：192.168.1.100 是如何瘫痪的？

搞清楚了入口，还要弄清内网的那台数据库服务器（1.100）是怎么被加密的。它没有公网端口，只能是内网横向移动。

排查 1.100 的安全日志，我还原了横向攻击的时间线：

• 9:58：1.100 遭到来自内网的 Guest 账户爆破攻击。万幸的是，这台新机器的 Guest 是禁用的，且策略生效触发了账户锁定（0xC0000234）。

图33 Guest默认禁用状态

但仅仅两分钟后，10:00，日志显示 192.168.1.2（即原中毒机器）直接使用Administrator账户成功登录了 1.100。

图34 管理员账户直接登录成功

原因复盘：我询问了客户，得知两台服务器设置了相同的管理员密码。攻击者控制了 1.2 后（Server 2008 系统），极有可能通过 Mimikatz 等工具抓取了内存中的明文密码或 Hash，配合密码复用，可以直接完成内网横向移动。

漏洞检查补充

关于 Guest 账户为何最初是开启的，除了人为因素，我们还排查了系统漏洞。使用Solar 应急脚本检查发现，该 Server 2008 R2 系统缺失**BlueKeep (CVE-2019-0708)**的关键补丁（KB4499175 或 KB4499164）。虽然此次攻击主要通过弱口令爆破，但老旧系统的漏洞风险极高，建议客户迁移至 Server 2016/2019 等高版本系统。

本次事件是一起典型的弱口令爆破 + 内网横向勒索攻击。攻击者利用对外开放的 RDP 端口和未禁用的 Guest 账户作为突破口，通过安装 Process Hacker 对抗防护，最终投放 AIR 勒索病毒。而后的二次加密，则是由于忽视了内网横向移动风险和密码复用问题导致的。

攻击者画像与攻击链路图

图35 攻击者攻击路线图

威胁情报 (IOCs)

勒索病毒的对抗不仅仅是数据的恢复，更是一场与黑客在时间、技术上的博弈。希望通过这次 Makop 家族的溯源复盘，能让大家对勒索攻击的路径有更直观的认识。