文章总结： 本文记录了一次针对AIR勒索病毒的应急响应与溯源过程，确认攻击源自Makop勒索家族，通过RDP爆破未禁用的Guest账户进入系统，提权后投放勒索软件。由于客户未完成彻底溯源就恢复生产，导致二次加密，展示了攻击者AIP爆破BIP加密的战术。内网横向通过密码复用实现，系统还存在BlueKeep漏洞未修复。建议禁用Guest账户、修复系统漏洞、避免密码复用等安全措施。
综合评分： 90
文章分类： 应急响应,恶意软件,内网渗透,漏洞分析

---

应急响应|记一次针对AIR勒索病毒的溯源过程

原创

爱州

州弟学安全

2025年12月8日 09:20
山东

本篇文章共 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 等高版本系统。

# 客户机器上已安装补丁未发现CVE-2019-0708相关补丁
[01]: KB981391
[02]: KB981392
[03]: KB977236
[04]: KB981111
[05]: KB977238
[06]: KB977239
[07]: KB981390
[08]: KB2506014
[09]: KB2506212
[10]: KB2506928
[11]: KB2509553
[12]: KB2511455
[13]: KB2536275
[14]: KB2544893
[15]: KB2545698
[16]: KB2547666
[17]: KB2552343
[18]: KB2560656
[19]: KB2563227
[20]: KB2564958
[21]: KB2570947
[22]: KB2585542
[23]: KB2598845
[24]: KB2603229
[25]: KB2604115
[26]: KB2607047
[27]: KB2608658
[28]: KB2620704
[29]: KB2621440
[30]: KB2631813
[31]: KB2640148
[32]: KB2643719
[33]: KB2653956
[34]: KB2654428
[35]: KB2656356
[36]: KB2660075
[37]: KB2667402
[38]: KB2676562
[39]: KB2685811
[40]: KB2685813
[41]: KB2685939
[42]: KB2690533
[43]: KB2698365
[44]: KB2705219
[45]: KB2706045
[46]: KB2712808
[47]: KB2718704
[48]: KB2719857
[49]: KB2726535
[50]: KB2729094
[51]: KB2729452
[52]: KB2732059
[53]: KB2736422
[54]: KB2742599
[55]: KB2750841
[56]: KB2758857
[57]: KB2761217
[58]: KB2763523
[59]: KB2765809
[60]: KB2770660
[61]: KB2786081
[62]: KB2789645
[63]: KB2791765
[64]: KB2798162
[65]: KB2800095
[66]: KB2807986
[67]: KB2808679
[68]: KB2813430
[69]: KB2834140
[70]: KB2836942
[71]: KB2836943
[72]: KB2839894
[73]: KB2840149
[74]: KB2840631
[75]: KB2843630
[76]: KB2852386
[77]: KB2853952
[78]: KB2861698
[79]: KB2862152
[80]: KB2862330
[81]: KB2862335
[82]: KB2864202
[83]: KB2868038
[84]: KB2868116
[85]: KB2868626
[86]: KB2871997
[87]: KB2884256
[88]: KB2888049
[89]: KB2891804
[90]: KB2892074
[91]: KB2893294
[92]: KB2893519
[93]: KB2894844
[94]: KB2900986
[95]: KB2908783
[96]: KB2911501
[97]: KB2919469
[98]: KB2929733
[99]: KB2931356
[100]: KB2937610
[101]: KB2943357
[102]: KB2957189
[103]: KB2966583
[104]: KB2968294
[105]: KB2972100
[106]: KB2972211
[107]: KB2973112
[108]: KB2973201
[109]: KB2973351
[110]: KB2977292
[111]: KB2978120
[112]: KB2984972
[113]: KB2985461
[114]: KB2991963
[115]: KB2992611
[116]: KB2993651
[117]: KB3003743
[118]: KB3004361
[119]: KB3004375
[120]: KB3005607
[121]: KB3006137
[122]: KB3006625
[123]: KB3010788
[124]: KB3011780
[125]: KB3018238
[126]: KB3019978
[127]: KB3020369
[128]: KB3020370
[129]: KB3021674
[130]: KB3022777
[131]: KB3023215
[132]: KB3030377
[133]: KB3031432
[134]: KB3033889
[135]: KB3033929
[136]: KB3035126
[137]: KB3035132
[138]: KB3037574
[139]: KB3040272
[140]: KB3042553
[141]: KB3045685
[142]: KB3046017
[143]: KB3046269
[144]: KB3054205
[145]: KB3054476
[146]: KB3055642
[147]: KB3059317
[148]: KB3060716
[149]: KB3068457
[150]: KB3068708
[151]: KB3071756
[152]: KB3072305
[153]: KB3072630
[154]: KB3074543
[155]: KB3075220
[156]: KB3076895
[157]: KB3078601
[158]: KB3078667
[159]: KB3080149
[160]: KB3080446
[161]: KB3084135
[162]: KB3086255
[163]: KB3087039
[164]: KB3092601
[165]: KB3092627
[166]: KB3097989
[167]: KB3101722
[168]: KB3107998
[169]: KB3108371
[170]: KB3108381
[171]: KB3108664
[172]: KB3108670
[173]: KB3109094
[174]: KB3109103
[175]: KB3109560
[176]: KB3110329
[177]: KB3118401
[178]: KB3121255
[179]: KB3122648
[180]: KB3123479
[181]: KB3124275
[182]: KB3126587
[183]: KB3127220
[184]: KB3133043
[185]: KB3133977
[186]: KB3135983
[187]: KB3137061
[188]: KB3138612
[189]: KB3138901
[190]: KB3139398
[191]: KB3139914
[192]: KB3139923
[193]: KB3139940
[194]: KB3140245
[195]: KB3142024
[196]: KB3142042
[197]: KB3145739
[198]: KB3146706
[199]: KB3146963
[200]: KB3147071
[201]: KB3149090
[202]: KB3153171
[203]: KB3156016
[204]: KB3156017
[205]: KB3156019
[206]: KB3159398
[207]: KB3161561
[208]: KB3161664
[209]: KB3161949
[210]: KB3161958
[211]: KB3162835
[212]: KB3164033
[213]: KB3164035
[214]: KB4012212
[215]: KB4014573
[216]: KB4014579
[217]: KB4019990
[218]: KB4040966
[219]: KB4054176
[220]: KB4095514
[221]: KB4338612
[222]: KB4344177
[223]: KB4470600
[224]: KB4474419
[225]: KB4483483
[226]: KB4488662
[227]: KB4495612
[228]: KB4506976
[229]: KB958488
[230]: KB976902

总结与 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 家族的溯源复盘，能让大家对勒索攻击的路径有更直观的认识。

图36 客户感谢信

坦白说，本次的溯源记录我自己感觉还是相对基础和简单的。如果您对更具挑战性、剧情更跌宕起伏的实战案例感兴趣，强烈推荐移步阅读我们团队最近发布的另一篇硬核记录。那个案例的过程经历非常刺激，包含了“黑客黑吃黑”、深度逆向分析、无密钥技术修复数据、全链路溯源及安全加固等全过程，干货满满：【成功案例】揭秘盗版LockBit 5.0连环骗局：黑客诈骗、中介跑路，我们如何逆风翻盘成功拯救企业数据？

最后，特别感谢协同作战的同事们：moje、HWC、Sumail、樱桃白、体重下降ing等。

如果您在日常工作中不幸遭遇勒索病毒，欢迎联系“州弟学安全”进行技术交流与处置，切勿病急乱投医。

图37 州弟联系方式

---

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：州弟学安全 爱州《应急响应|记一次针对AIR勒索病毒的溯源过程》