文章总结： 本文详细记录了一次Makop勒索病毒攻击的应急响应与溯源过程。攻击者通过RDP爆破未禁用的Guest账户进入系统，利用ProcessHacker工具对抗防护，投放加密器导致20万+文件被加密。文章还描述了因未彻底溯源加固导致的二次加密事件，并提供了完整的时间线分析和攻击链路图。关键建议包括：禁用Guest账户、设置强密码策略、避免密码复用、及时更新系统补丁、在恢复前完成全盘溯源等防御措施。
综合评分： 85
文章分类： 应急响应,勒索病毒,内网渗透,漏洞分析,威胁情报
【应急实战】近期的一次勒索病毒真实溯源过程
银遁安全团队
2025年12月10日 08:01
广东
以下文章来源于州弟学安全
，作者爱州
州弟学安全
.
太极生两仪 非黑即白 正义之道，注重从基础理论到实战的每一步，小白-有经验只需要这些就够了。
本篇文章共 5000字，完全阅读全篇约5分钟 州弟学安全，只学有用的知识
前言
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应急响应官网
数据恢复
在确定勒索家族后，为了保障客户业务尽快上线，我第一时间将样本同步给了后端的病毒分析工程师进行研判。
得益于团队完善的样本库和技术储备，我们很快制定了针对性的恢复方案。在与客户约定的时间内，通过专业技术手段成功完成了数据库恢复工作。关于此家族加密器的逆向分析细节，感兴趣的朋友可以参考我们团队之前的技术文章：【病毒分析】揭秘.mkp后缀勒索病毒！Makop家族变种如何进行可视化加密？
深度溯源：黑客是如何进来的？
数据虽然恢复了，但门没关上，危险就依然存在。按照标准流程，我立即对恢复后的环境进行了全盘镜像备份，防止原始日志丢失或二次破坏，随即展开溯源。
图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 等高版本系统。
总结与 IOCs
本次事件是一起典型的弱口令爆破 + 内网横向勒索攻击。攻击者利用对外开放的 RDP 端口和未禁用的 Guest 账户作为突破口，通过安装 Process Hacker 对抗防护，最终投放 AIR 勒索病毒。而后的二次加密，则是由于忽视了内网横向移动风险和密码复用问题导致的。
攻击者画像与攻击链路图
图35 攻击者攻击路线图
威胁情报 (IOCs)
| 类型 | 值 | 备注 |
| — | — | — |
| IP | 45.x.x.60 (荷兰) | 暴力破解源 |
| IP | 117.x.x.89 (江苏苏州) | 跳板机/投放加密器 |
| IP | 36.x.x.179 (北京) | 跳板机/登录查看 |
| File | svchost.exe.exe | 加密器 payload |
| File | kprocesshacker.sys | 对抗工具驱动 |
| Email | [email protected] | 勒索联系邮箱 |
结语
勒索病毒的对抗不仅仅是数据的恢复，更是一场与黑客在时间、技术上的博弈。希望通过这次 Makop 家族的溯源复盘，能让大家对勒索攻击的路径有更直观的认识。
坦白说，本次的溯源记录我自己感觉还是相对基础和简单的。如果您对更具挑战性、剧情更跌宕起伏的实战案例感兴趣，强烈推荐移步阅读我们团队最近发布的另一篇硬核记录。那个案例的过程经历非常刺激，包含了“黑客黑吃黑”、深度逆向分析、无密钥技术修复数据、全链路溯源及安全加固等全过程，干货满满：【成功案例】揭秘盗版LockBit 5.0连环骗局：黑客诈骗、中介跑路，我们如何逆风翻盘成功拯救企业数据？
最后，特别感谢协同作战的同事们：moje、HWC、Sumail、樱桃白、体重下降ing等。
如果您在日常工作中不幸遭遇勒索病毒，欢迎联系“州弟学安全”进行技术交流与处置，切勿病急乱投医。
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：银遁安全团队 《【应急实战】近期的一次勒索病毒真实溯源过程》