吾爱破解 - 52pojie.cn

 找回密码
 注册[Register]

QQ登录

只需一步,快速开始

查看: 1670|回复: 14
上一主题 下一主题
收起左侧

[分享] 【成功案例】wman勒索病毒近期再度活跃

 关闭 [复制链接]
跳转到指定楼层
楼主
solar应急响应 发表于 2026-6-1 15:36 回帖奖励
使用论坛附件上传样本压缩包时必须使用压缩密码保护,压缩密码:52pojie,否则会导致论坛被杀毒软件等误报,论坛有权随时删除相关附件和帖子!
病毒分析分区附件样本、网址谨慎下载点击,可能对计算机产生破坏,仅供安全人员在法律允许范围内研究,禁止非法用途!
禁止求非法渗透测试、非法网络攻击、获取隐私等违法内容,即使对方是非法内容,也应向警方求助!
本帖最后由 solar应急响应 于 2026-6-1 15:47 编辑

【成功案例】wman勒索病毒近期再度活跃,一次覆盖15台服务器的完整应急响应与溯源恢复实录

.wman后缀的勒索病毒最近又出现在了多个企业的安全事件工单里。它并非一个全新的面孔,而是Rast gang家族在持续迭代中推出的新变种。早在2025年,Solar应急响应团队就已经捕获过该家族的样本,其加密器由Rust编写,保留了该团伙一贯的手动交互启动风格。到了今年,我们注意到wman的活跃态势有明显回升,客户现场反馈的文件锁定特征非常统一:原始扩展名被追加为.wman,桌面壁纸被替换为勒索提示界面,同时在桌面及各磁盘目录都会预留一份名为DECRYPTION_INFORMATION.html的勒索信。

在技术分析层面,wman还保留了一个颇具辨识度的细节:加密器运行时不会加密与其自身处于同级目录下的文件。这一特征在应急响应.com平台已有明确收录,搜索"wman"即可快速关联到Rast gang家族图谱及基础处置建议,对于一线运维人员来说,这能在第一时间缩小排查范围,避免在未知家族上消耗过多精力。

本文把近期处置的一起真实案例完整还原出来。客户现场共有15台服务器受到波及,我们从样本逆向、加密逻辑梳理,到数据恢复落地,再到攻击路径溯源与后续加固,把全流程的技术细节整理成文。希望能给正在应对类似情况的同行提供一份可直接参考的实战记录。

一、Rast gang家族画像与wman的技术渊源

在切入本次事件之前,有必要先把wman所处的家族背景理清楚。Rast gang是一个以Rust语言编写勒索软件的网络犯罪组织,自2023年12月起在国内持续活跃,我们跟踪到的政企受害单位已超过20家。与多数追求长期潜伏的团伙不同,Rast gang的运营节奏偏快,他们并不执着于在内网进行大规模的横向渗透,而是倾向于在获取边界服务器权限后,迅速通过RDP登录手动释放勒索载荷。

!


Rast gang勒索软件运行后显示的控制台界面,攻击者需手动按下Ctrl+Shift+F1热键并输入PIN码后方可启动加密流程,体现了该家族"人工现场操作"的攻击风格

这种"人工现场操作"的风格在勒索软件里并不多见。攻击者需要亲自登录到目标服务器,启动带有交互界面的加密器,经过热键唤醒、PIN码验证、加密模式选择等步骤后才能执行文件锁定。也正因如此,该家族对边界服务器的RDP暴露面与弱口令极为依赖。

在工具链方面,Rast gang的投递组件相当固定。获取权限后,通常会先释放Zapp工具停止指定进程与服务,随后删除卷影拷贝与系统日志,若遇到EDR拦截则会尝试用Revo Uninstaller强制卸载安全软件。接着投递mimikatz抓取内存凭证,再配合kportscan、netscan等扫描器探索内网可触达的目标。此外,该团伙长期将Neshta感染型病毒作为Dropper,在特定目录下释放勒索主体并启动,这一手法在2019至2021年间也曾被用于投递Buran、GlobeImposter、Phobos等老牌勒索家族。


Rast gang典型投递组件清单,涵盖进程管理、日志清理、安全软件卸载、凭证窃取及内网扫描等多类工具

从数据库层面来看,Rast gang早期版本通过FTP回传受害者信息,后期改为连接远程MySQL数据库记录计算机名、联系邮箱及随机生成的company_id。我们对脱取攻击者的数据库记录进行分析后发现,受害机器命名中涉及ERP、MES、DC、ECM、Veeam、Jenkin、Hikvision等业务关键词,说明该家族对制造业、安防监控及企业信息化系统的兴趣较高。


基于数据库中受害机器名提取的业务类型分布,涵盖ERP、MES、域控、企业内容管理、虚拟化平台及安防监控等方向

wman作为Rast gang的变种,完整继承了上述家族基因。本次捕获的样本manager.exe同样由Rust编译,保留了手动交互启动的逻辑,加密后追加.wman后缀,并通过DECRYPTION_INFORMATION.html与受害者建立联系。理解这些家族共性,是后续制定恢复与溯源策略的重要前提。

二、事件现场与应急响应启动

2026年5月中旬,Solar应急响应团队接到客户求助,其内部业务集群遭遇大规模加密。初步清点后有15台服务器受到影响,文件后缀被统一修改为.wman,桌面壁纸被替换为黑客自定义的勒索界面,各磁盘目录均出现了DECRYPTION_INFORMATION.html勒索信。从影响范围来看,攻击者显然已经完成了一定程度的内网横向移动,这也说明本次攻击者获取的初始权限具备较高的内网可达性。


服务器内被加密后的文件状态,正常扩展名被追加为.wman后缀,文件名结构为原始名称.标识符.邮箱.wman

我们在平台对wman进行了快速检索,确认其归属于Rast gang家族,且该平台显示.peng等同类后缀也可直接处置。这一信息帮助我们快速排除了未知家族的风险,将精力集中在已知的加密逻辑分析与数据恢复路径上。


勒索病毒检测查询

现场处置的第一步是隔离止血。我们将受影响的15台服务器从生产网络中剥离,阻断攻击者可能存在的持续访问通道,同时保留内存与磁盘镜像作为后续分析素材。随后开始并行推进两条线:

1.对捕获的加密器样本进行逆向分析,梳理其加密机制以评估数据恢复可行性

2.对未受影响的边界设备与跳板机进行日志筛查,为后续溯源做准备

三、加密器逆向与行为分析

本次捕获的加密器样本为manager.exe,文件大小约788 KiB,经思而听沙箱初步分析后确认其为32位Windows可执行程序,由Rust语言编译。样本的加密后缀格式为.[[随机标识符]].[[联系邮箱]].wman,本次事件中出现的联系邮箱为yatesnet@cock.li


manager.exe在沙箱中的静态分析结果,显示文件类型、大小、哈希值及操作系统适配信息

3.1 加密算法与密钥管理逻辑

通过逆向分析,我们梳理出wman的加密体系采用"RSA + ChaCha20_Poly1305"的混合加密结构。程序内置了硬编码的RSA公钥,用于保护后续生成的对称加密密钥;而实际的文件加密则由ChaCha20_Poly1305流密码完成。

在密钥生成阶段,样本调用BCryptGenRandomSystemFunction036两套API初始化随机数池,再通过Produce_Random_Data函数派生出32字节的ChaCha20密钥与12字节的Nonce。从代码逻辑来看,加密器在启动后的模式选择入口会统一完成全部密钥的初始化工作,随后将加密上下文传递给各文件加密线程。


wman加密器主执行流程,涵盖入口模式选择、密钥统一生成、线程分配、目录扫描及文件加密等阶段

我们在逆向过程中注意到一个特殊的技术细节:该样本在文件加密时,几乎所有线程都复用了同一个加密上下文。这意味着同一轮攻击中,所有被加密文件实际上处于相同的ChaCha20密钥流保护之下。此外,wman在加密范围上做了明显限制:单文件最多仅加密前512KB数据,超出部分保持原始状态不变。同时,加密器会跳过与自身处于同级目录的文件,这一特征在现场排查时得到了充分验证。



原始文件与加密文件的十六进制对比,可见加密操作仅作用于文件头部特定区域,后续数据保持明文结构

3.2 逆向分析对恢复工作的价值

上述逆向结论为数据恢复工作提供了关键的技术依据。由于ChaCha20_Poly1305在本次样本实现中未启用tag验证,且存在"同一密钥流复用""仅加密前512KB"两大特征,这为我们后续通过技术手段还原文件创造了条件。

在表达上,我们避免透露具体的密钥推导与文件还原手法,但可以明确的是,逆向分析所揭示的加密逻辑特征,是本次能够在不支付赎金前提下完成大规模数据恢复的核心技术基础

四、数据恢复实施

基于逆向阶段梳理出的加密逻辑,我们制定了针对性的恢复方案。现场15台服务器涉及的业务数据量较大,且文件类型分散,涵盖数据库文件、文档、日志及配置文件等。如果采用常规的备份恢复方式,客户将面临数天的业务中断与数据补录成本;而支付赎金不仅无法保证解密成功,还会助长攻击者的后续活动。

在实际恢复过程中,我们利用推导出的密钥流构造了批量恢复工具。该工具针对wman的加密特征做了专门适配:


基于逆向分析结果构造的批量恢复工具运行界面,正在对15台服务器中的加密文件进行自动化还原

整个恢复工作持续了3天。时间安排如下:

天数 工作内容
第一天 密钥推导与恢复工具的开发验证
第二天 批量部署至各台服务器执行解密
第三天 数据完整性校验与业务系统联调

最终15台服务器中的加密文件恢复成功率达到99%,丢失的1%主要集中在攻击者加密过程中被异常中断损坏的极个别文件上。客户核心业务系统在较短时间内重新上线,避免了因长期停服带来的连锁损失。

五、攻击路径溯源与加固建议

数据恢复完成后,我们将重心转向攻击路径的还原与现场加固。溯源工作基于客户提供的系统日志、安全设备告警及我们在现场提取的残留攻击工具展开。以下时间线与IP信息已按客户要求做脱敏处理,仅保留技术特征用于分析参考。

5.1 初始入侵与权限流转

梳理RDP登录日志后,我们发现攻击者的首次成功登录发生在2026年3月13日15时28分,来源IP归属于摩洛哥马拉喀什地区。此后同一账号在当天17时38分再次从瑞士苏黎世登录,两个月后的5月19日与20日,又分别出现了来自德国法兰克福与俄罗斯格罗兹尼的登录记录。


Windows安全日志中记录的首次异常RDP登录成功事件,时间戳为2026年3月13日,来源IP经脱敏处理


对首次登录来源IP的威胁情报关联查询结果,显示该IP位于摩洛哥马拉喀什地区,属于境外高风险资产


Windows安全日志中记录的第二次异常RDP登录成功事件,时间戳为2026年3月13日,来源IP经脱敏处理


对第二次登录来源IP的威胁情报关联查询结果,显示该IP位于瑞士 苏黎世州 苏黎世地区,属于境外高风险资产


Windows安全日志中记录的第三次异常RDP登录成功事件,时间戳为2026年5月19日,来源IP经脱敏处理


对第三次登录来源IP的威胁情报关联查询结果,显示该IP位于德国 黑森州地区


Windows安全日志中记录的第四次异常RDP登录成功事件,时间戳为2026年5月19日,来源IP经脱敏处理


对第四次登录来源IP的威胁情报关联查询结果,显示该IP位于俄罗斯 车臣共和国 地区,属于境外高风险资产

这种跨越多国、跨度长达两个月的登录模式,与典型的单一攻击者直接控制特征不符。我们更倾向于认为,攻击者所持有的远控权限曾在地下黑市中进行过流转,不同阶段的登录者可能是购买了同一批访问权限的不同代理人员。Rast gang本身并不以高级APT式的0day利用著称,其入侵入口多为RDP爆破或历史漏洞组合,获取权限后在暗网中转售也符合该类犯罪团伙的常见变现路径。


来源思而听勒索病毒防护PPT:访问代理权限售卖介绍

5.2 权限维持与内网横向

在5月20日凌晨,日志中出现了一个名为"Support"的账号成功登录的记录。经客户确认,该账号并非业务部门创建,属于攻击者植入的后门用户。该账号随后被用于执行一系列内网探测与加密准备操作。


Windows安全日志中发现的异常本地账号"Support"登录记录,该账号为攻击者创建的后门账户

攻击者在获取Support账号权限后,迅速投放了多套内网渗透工具。我们在现场提取到的残留工具包括:

  • NLbrute:RDP暴力破解工具
  • Mimikatz:凭证读取工具
  • NetScan:网络服务扫描工具

这些工具的组合使用,说明攻击者在加密前进行了系统性的内网资产探测与权限收集。


在跳板机中提取到的攻击者残留工具集,涵盖RDP爆破、凭证窃取及网络扫描三类功能

以下为攻击者在内网横向扫描的结果,相关内容将进行脱敏处理


NLbrute工具生成的内网RDP爆破结果记录,显示攻击者对网段内多主机进行了批量协议探测


Mimikatz内存凭证提取后的输出片段,攻击者通过该工具获取了多台服务器的横向移动凭据

攻击者在操作过程中表现出一定的反溯源意识。我们在日志中发现了明确的安全日志清理痕迹,部分早期的RDP爆破记录已被删除,这给完整还原初始入侵路径带来了一定困难。好在Windows日志的残留片段与威胁情报平台的IP关联,仍足以支撑起上述时间线的重建。

5.3 加密执行与收尾

2026年5月20日凌晨,攻击者在完成内网扫描与权限收集后,开始批量释放wman加密器。其执行策略是以当前控制的跳板机为起点,先向内部14台服务器推送加密载荷并执行,最后才对跳板机本身进行加密并退出远程连接。这种"先横向、后本地"的加密顺序,与Rast gang家族"获取权限后立即释放"的常规打法一致,只是本次由于前期已获取大量内网凭据,横向范围从单台扩大到了15台。


其中一台服务器上被加密文件的目录清单,可见文件后缀已被统一修改为.wman格式

5.4 加固措施

针对上述攻击路径,我们协助客户完成了以下重点加固:

1.入口收敛:全面梳理互联网侧RDP暴露面,关闭非必要端口,将远程维护入口收缩至VPN或零信任网关之后

2.认证强化:对所有服务器及管理账号启用多因素认证,强制更换弱口令,禁用默认Administrator账号的直接登录

3.权限清理:删除Support等异常账号,核查近三个月内新增的所有本地与域账号,收紧普通用户的本地管理员权限

4.日志留存:部署集中化日志采集平台,确保安全事件日志至少保留180天,并开启日志防篡改保护

5.内网分段:按业务维度划分VLAN,限制服务器之间的横向访问,特别是RDP、SMB等高风险协议的跨段流动

六、闭环运营与长效防护

完成"处置—恢复—加固"三步后,本次应急响应在技术上已经形成了闭环。但客户也意识到,单次事件的处理并不能解决长期面临的勒索威胁。经过评估,客户选择部署SAR**防勒索AI疫苗**产品,作为终端侧的最后一道防线。

SAR(Security AI Response)是一款面向企业级场景的防勒索解决方案,核心思路不是依赖传统的特征库比对,而是在终端侧通过AI行为预测模型实时分析文件操作流。当加密勒索行为出现时,系统能够在毫秒级完成识别,并通过密钥捕获技术自动备份加密密钥。一旦确认攻击,SAR可基于捕获的密钥在30分钟内完成数据还原,将业务中断时间压缩到最低。

SAR产品在终端上的运行状态界面,显示实时行为监控、威胁识别及密钥捕获等核心模块的工作情况

从技术架构上看,SAR底层融合了深度学习、LLM辅助研判、熵值判断及BART序列分析等能力,覆盖超过3000种已知勒索样本的行为特征库,同时支持轻量化部署,资源占用控制在10%以内,对业务系统性能影响极小。对于已经具备基础安全体系的企业,SAR可以作为现有EDR、SOC架构的有效补充,而非替代。

七、总结与实战建议

回顾这次wman勒索病毒的处置全过程,有几个层面的经验值得拿出来与同行分享。

第一,快速定性的价值。 勒索病毒应急响应中,最宝贵的是前几个小时。通过应急响应.com等平台快速关联家族归属,能让我们在第一时间排除"未知家族"的恐慌,将资源投入到已知的加密逻辑分析与恢复路径上。wman虽然是Rast gang的新变种,但其家族基因明确,这一定性直接决定了后续逆向分析的方向。

第二,逆向分析是数据恢复的基石。 很多团队在遭遇勒索后的第一反应是"有没有通用解密器",但实际上,对于像wman这样采用标准算法且存在逻辑缺陷的样本,深入的逆向分析往往比盲目搜索解密工具更有效。理解其密钥生成方式、加密范围及线程模型,是制定针对性恢复方案的前提。

第三,溯源不能止于"找到入口"。 本次攻击的初始入侵发生在两个月前,权限经历了多轮流转,如果仅仅修复最初的那台跳板机,很可能遗漏其他潜伏的后门。完整的溯源必须覆盖账号生命周期、工具投放痕迹、日志异常及内网横向路径,才能真正降低二次被攻的风险。

第四,技术恢复与产品运营需要形成闭环。 单次事件的应急处置再漂亮,也替代不了常态化的防护能力。SAR这类产品的意义不在于"万能免疫",而在于将"事前预警、事中拦截、事后快速恢复"的能力固化到日常运营中,让企业在面对下一次威胁时,拥有更从容的响应底气。

勒索攻击的对抗是一场持久战。攻击者的工具在迭代,权限获取与流转的方式在变化,但防守方的核心逻辑始终清晰:收敛暴露面、保留证据链、提升响应速度、建立恢复能力。希望这次案例能为正在建设自身勒索防护体系的企业和同行,提供一份有实际操作价值的参考。

本文案例由应急响应团队共同完成。

现场应急与全文输出:州弟学安全

参与应急排查与数据恢复实施:ZC、E、moje

主导加密器逆向分析与恢复方案设计:G0fl1er

免费评分

参与人数 11吾爱币 +11 热心值 +10 收起 理由
mocatante + 1 + 1 热心回复!
AguaA + 1 + 1 欢迎分析讨论交流,吾爱破解论坛有你更精彩!
lalicorne + 1 我很赞同!
theSwan + 1 + 1 谢谢@Thanks!
allspark + 1 + 1 用心讨论,共获提升!
ParllelShifterX + 1 + 1 用心讨论,共获提升!
人间值得 + 1 + 1 用心讨论,共获提升!
唐小样儿 + 1 + 1 我很赞同!
SunShuai520901 + 1 + 1 用心讨论,共获提升!
leechjia + 1 + 1 谢谢@Thanks!
ioyr5995 + 1 + 1 热心回复!

查看全部评分

发帖前要善用论坛搜索功能,那里可能会有你要找的答案或者已经有人发布过相同内容了,请勿重复发帖。

推荐
 楼主| solar应急响应 发表于 2026-6-2 13:25 |楼主

理解你的心情,数据被锁了肯定着急。关于解密工具,目前确实只有极少数安全团队在跟进逆向,这背后有几个现实因素。
一是勒索病毒的逆向成本极高,不是简单的"写个程序"就能解决,需要持续投入大量人力去对抗代码混淆、反调试和自定义加密算法;二是安全行业有个基本共识,解密工具一旦公开,攻击者会第一时间逆向分析补丁逻辑,反过来加固他们的加密方案,结果就是后面的受害者彻底失去恢复机会,这其实是害了更多人。
我们作为应急响应方,核心职责是帮客户溯源止血、加固防线,以及通过正规渠道配合警方、CNVD 或安全厂商,为已受害的单位争取恢复窗口。公开叫卖解密器既不专业,也不负责任,更不符合我们这类团队的做事原则。真到了能安全释放解密能力的时候,走的也一定是官方协作通道,而不是论坛交易。
沙发
leechjia 发表于 2026-6-2 06:24
3#
mawen4699 发表于 2026-6-2 08:40
4#
「逝者如川」 发表于 2026-6-2 09:31
就喜欢这种过程性的分析,看着很爽,很有成就感。
5#
Nevvb1e251111 发表于 2026-6-2 09:51
leechjia 发表于 2026-6-2 06:24
菜鸟没看懂,是不是有内鬼才可以勒索成功?

受害者开了RDP 远程桌面连接 而且他们这个端口应该是在公网上的 黑客有那种不间断的扫描工具 扫到后要么弱口令爆破要么利用RDP的历史漏洞 就能登录进去 然后就可以干他们想干的了
6#
leechjia 发表于 2026-6-2 09:56
Nevvb1e251111 发表于 2026-6-2 09:51
受害者开了RDP 远程桌面连接 而且他们这个端口应该是在公网上的 黑客有那种不间断的扫描工具 扫到后要么 ...

我的远程服务器一直开着远程桌面,也在公网上,虽然改了端口。用强密码能不能防御得住?
7#
Nevvb1e251111 发表于 2026-6-2 10:05
leechjia 发表于 2026-6-2 09:56
我的远程服务器一直开着远程桌面,也在公网上,虽然改了端口。用强密码能不能防御得住?

改一下规则 密码错误三次拉黑IP 或者直接白名单 只允许你的IP地址登录  不想搞的话把密码设置的复杂点 想折腾也可以试试威屁恩+内网RDP 搞防火墙 更新服务器补丁 以防历史漏洞 有钱的话直接找安全厂商买防火墙和防御服务
8#
阿林不是阿狸 发表于 2026-6-2 10:33
leechjia 发表于 2026-6-2 09:56
我的远程服务器一直开着远程桌面,也在公网上,虽然改了端口。用强密码能不能防御得住?

有钱上企业安全产品及防御服务,没有那就强密码及安全策略
9#
 楼主| solar应急响应 发表于 2026-6-2 13:24 |楼主
leechjia 发表于 2026-6-2 06:24
菜鸟没看懂,是不是有内鬼才可以勒索成功?

感谢关注。内鬼作案确实是勒索攻击中不可忽视的维度,我们历史上也处置过因内部人员权限滥用导致的大规模加密事件,那种场景下的溯源特征和本次完全不同。
但回到这个案例,完整的证据链已经写清楚了:根因是业务服务器的 RDP 端口暴露在公网,且使用了弱口令/具有特征性的口令,被外部攻击者直接远程登录成功。后续我们观察到同一批资产在短时间内被多次转手登录,这更符合黑市上"卖权限"的黑产组织行为特征:他们先打入口,再把远程桌面权限打包出售给下游的勒索团伙,形成一条接力链。
所以这一次不是内鬼,而是入口暴露后引来了黑产接力。把入口守住,比猜谁动了手更重要。
您需要登录后才可以回帖 登录 | 注册[Register]

本版积分规则

返回列表

RSS订阅|小黑屋|处罚记录|联系我们|吾爱破解 - 52pojie.cn ( 京ICP备16042023号 | 京公网安备 11010502030087号 )

GMT+8, 2026-6-18 00:22

Powered by Discuz!

Copyright © 2001-2020, Tencent Cloud.

快速回复 返回顶部 返回列表