【勒索预警】用友 BIP 高级版疑似0day已被rox勒索病毒利用（附IOC）

solar应急响应

写在前面

自今年6月以来，我们持续跟进weax勒索病毒在国内的多起攻击事件。近期，该家族已将加密文件后缀改为 .rox。在此前发布的畅捷通T+案例中，我们已对这一变化作出预警。

围绕tellyouthepass（sorry勒索病毒）、weaxor等相关勒索家族，我们也持续发布过溯源分析。建议结合往期文章阅读，了解其攻击手法的延续与变化。

本次案例的入侵入口指向用友 BIP 高级版 sprmonitorservlet 接口的Java原生反序列化漏洞。

通过日志分析，10月17日，攻击者利用该漏洞上传第一枚WebShell；18日早上8点，再次上传一枚采用加密通信的木马；18日20时起，我们处置和接到的相关案例中，互联网暴露的用友 BIP 高级版陆续出现勒索中招情况。

此前，我们曾推测勒索家族可能借助AI辅助挖掘0day。本案呈现出先打点、再验证、后加密的时间衔接，且前后使用了两套攻击基础设施，使“漏洞详情或已控目标权限在不同人员之间流转”的可能性进一步上升。但这一判断仍属推测，后文会列明依据和证据边界。

阅读说明：按照惯例，本文不公开受害单位信息，只分享主服务器的溯源过程与攻击者思路。为避免攻击代码被滥用，本文不公开完整PoC及可直接利用的载荷，相关技术细节以说明原理和辅助排查为限。

一、事件概述

2026年10月18日20时36分，某企业用友 BIP 高级版主服务器开始被批量加密，共150,411个文件被追加 .rox 后缀，业务中断。加密器落地前，主服务器已分别于10月17日凌晨和10月18日上午出现两轮漏洞利用与WebShell落地记录。

用友 BIP 高级版运行于Java环境，正常情况下主要留下应用日志。本次现场未部署安全设备，也没有中间件访问日志，应用日志又只记录异常堆栈，不记录请求URI、来源IP和POST请求体，因此无法直接还原完整攻击请求。

本次分析以应用日志中的异常时间为起点，与Windows PowerShell事件日志、文件时间和系统痕迹逐条对齐，最终还原出三轮漏洞利用、两枚WebShell落地及勒索加密的过程。下文仅围绕主服务器展开，时间均为北京时间。

二、详细溯源过程

2.1 10月17日05:02，首次异常与漏洞试探

10月17日05:02:59，主服务器 fw-log.log 首次记录 ####sprmonitorServlet Exception，异常类型为 java.io.EOFException，调用位置位于 ObjectInputStream 读取序列化流头阶段。

这类异常说明接口收到了不完整或不符合预期的序列化数据。结合38秒后出现的完整利用异常判断，该请求更符合正式利用前的试探特征。

主服务器首次出现 sprmonitorServlet 异常，时间为10月17日05:02:59

2.2 10月17日05:03，第一枚WebShell落地

05:03:37，应用日志出现 ####requestEntry Exception。堆栈显示，Hashtable 在原生反序列化过程中触发 JtaTransactionManager.readObject，随后向 rmi://8.130.77.216:1099/x 发起JNDI查找，对端返回 javax.el.ELProcessor 对象。

应用日志记录JNDI回连地址及 ELProcessor 返回对象，与后续命令执行时间相接

仅1秒后，Windows事件日志记录PowerShell执行。命令先从Java进程路径推导应用目录，失败时再遍历多组常见安装路径，随后从 8.130.77.216:18888 下载 ncsync.jsp，写入 webapps/nc_web 目录，并将落地结果编码后回传。

10月17日05:03:38，主服务器执行PowerShell，下载并落地 ncsync.jsp

对 ncsync.jsp 分析发现，该文件通过自定义 ClassLoader 加载内嵌的Base64类字节码，再反射注册 /ncsync 内存Servlet。其字节码包含密码验证、Windows与Linux命令执行分支，属于跨平台命令执行型WebShell。

ncsync.jsp 内嵌Base64类字节码，运行时加载并注册内存Servlet

文件检索结果与事件日志相互印证，ncsync.jsp 的修改时间为10月17日05:03，大小为7 KB。

文件检索确认 ncsync.jsp 已落入应用目录，时间为10月17日05:03。

2.3 第一阶段基础设施

8.130.77.216 归属内蒙古乌兰察布阿里云数据中心。在本次攻击中，该地址的1099端口承担RMI服务，18888端口用于分发WebShell和接收落地回执。

8.130.77.216 的归属查询结果

资产测绘显示，该地址的8000、8080端口曾分别出现 SimpleHTTPServer 与 BaseHTTPServer 服务特征，均为Python 3.12.3。这类轻量服务与攻击中直接下载文件、接收落地回执的方式相吻合。

该IP部分端口呈现Python HTTP服务特征

2.4 10月18日08:15，第二枚WebShell落地

距首次利用约27小时后，服务器于08:15:34再次出现同型异常。JNDI回连地址仍为 rmi://8.130.77.216:1099/x，说明同一基础设施再次通过该漏洞执行了攻击载荷。

10月18日08:15:34，同一RMI地址再次出现在应用日志中

08:15:35，主服务器再次执行落地命令。脚本逻辑与前一日基本一致，仅将下载文件替换为 gzms.jsp。

主服务器于10月18日08:15:35执行 gzms.jsp 落地命令

文件检索显示，gzms.jsp 的修改时间为08:15，大小为22 KB。

文件检索确认 gzms.jsp 的落地时间与事件日志一致

第二枚WebShell沿用相同的类加载骨架，但内嵌类为 AES_BASE64，注册路径为 /gzsync，通信内容经AES加密后再进行Base64编码。两枚WebShell共用连接密码 ncw3b2026，由同一地址分发，落地脚本也高度一致，可以确认前两轮利用属于同一套自动化工具链。

gzms.jsp 采用加密通信，结构较第一枚WebShell更为复杂

2.5 10月18日20:34，漏洞入口再次出现

20:34:59，应用日志第三次出现同型反序列化异常，但RMI地址变为 rmi://192.151.233.247:1099/x。漏洞入口和利用链未变，攻击基础设施已经切换。

20:34:59，RMI回连地址切换为 192.151.233.247

20:35:00，主服务器执行一段混淆PowerShell。还原后可见两组关键处理：一组整数逐字节减129，恢复以IEX开头的下载执行内容；另一组整数减23，恢复 System.Management.Automation.ScriptBlock，再调用 ScriptBlock.Create 在内存中执行脚本块。

主服务器于20:35:00执行混淆PowerShell，事件ID为4104

脚本还使用 Update service mesh routing table 作为注释，并将变量命名为 $Timestamp、$LogFile、$ConfigPath 等常见运维名称，以增加人工识别难度。还原后的下载地址指向 192.151.233.246:20469。

威胁情报显示，192.151.233.246 位于中国香港，带有恶意及漏洞利用相关标记。该地址与本轮RMI服务器 192.151.233.247 处于同一网段，分别承担载荷分发和漏洞利用回连。

192.151.233.246 的威胁情报记录

2.6 10月18日20:36，加密与日志清除

20:36，加密器 ugaqGrklG.exe 落地至主服务器 C:\Windows\System32\ 并执行，AppCompatCache中保留了相应记录。

AppCompatCache记录 ugaqGrklG.exe 于20:36执行

随后，主服务器文件被批量追加 .rox 后缀。文件检索共命中150,411个对象，修改时间集中在20:36至20:37。20:36:53，主服务器安全日志被清除，攻击者开始清理现场痕迹。

主服务器共检索到150,411个 .rox 文件，修改时间集中在20:36至20:37

结合 .rox 后缀、随机文件名加密器及清除日志等特征，本次加密器归属weaxor勒索家族。

三、漏洞确认与无害化验证

三轮利用的异常堆栈结构一致，关键调用关系如下：

异常堆栈关键调用关系图

入口位于 /servlet/~uapfw/sprmonitorservlet。请求进入 SprMonitorServlet 后，服务端直接对请求体进行Java原生反序列化。JtaTransactionManager.readObject 在反序列化过程中触发JNDI查找，随后利用应用环境中的 ELProcessor 完成代码执行。

这里需要特别区分，本现场属于Java原生序列化流，不是fastjson反序列化链路。日志中的 JtaTransactionManager.readObject、JNDI location [rmi:// 和 javax.el.ELProcessor，共同构成了识别本轮攻击的关键特征。

由于现场没有中间件访问日志，无法仅凭应用日志恢复原始POST请求。我们通过威胁狩猎平台捕获到相关PoC，将其对象结构与现场异常堆栈对照，确认了漏洞类型和利用链。随后，在客户授权下开展DNSLOG无害化验证：仅将载荷中的RMI地址改为团队控制的DNSLOG域名，不执行恶意代码，也不向目标写入文件。

重放后，DNSLOG平台收到来自目标服务器出口的解析记录，应用日志同时新增同型 JtaTransactionManager.readObject 异常。两项结果相互印证，确认该漏洞在受害环境中真实存在且可被远程触发。

DNSLOG解析记录与新增应用异常相互印证，验证过程未执行恶意代码

四、为何暂定为未公开漏洞

本次捕获PoC所针对的路由，在2024年HW期间曾曝出0day。截至本文撰写时，我们尚未在互联网公开渠道检索到该路由的可利用PoC，因此无法确认本轮攻击使用的是全新漏洞、新的未授权绕过方式，还是2024年同一漏洞的再次利用。

基于现有证据，标题使用“疑似0day”，正文暂将该问题定性为 未公开漏洞。这一表述只说明我们尚未发现公开可利用细节，不代表厂商从未掌握或修复该问题。受影响版本、补丁状态及准确漏洞编号，仍需以用友官方核实结果为准。

五、攻击者思路与归因边界

本案最值得关注的，不只是漏洞本身，还有三轮攻击之间的衔接：

时间	主要动作	攻击基础设施
10月17日05:03	首次利用，落地明文命令执行型WebShell	8.130.77.216
10月18日08:15	再次利用，落地加密通信型WebShell	8.130.77.216
10月18日20:34起	再次利用同一漏洞，下载并执行加密器	192.151.233.246、192.151.233.247

前两轮可以依据相同C2、相同WebShell密码和高度一致的落地脚本，判断为同一套自动化工具链。第三轮与前两轮使用相同漏洞入口，时间紧接第二次WebShell落地，但C2已经切换，PowerShell载荷形态也不同。

由此形成的一种合理推测是，前期人员先利用漏洞批量打点并验证目标可用性，之后漏洞详情或已控目标权限发生流转，勒索实施者再复用同一入口完成加密。与单纯由勒索家族借助AI挖掘0day的假设相比，本案使国内人员参与漏洞或权限售卖的可疑性有所上升。

但需要强调，可疑性上升不等于交易事实成立。同一团队主动切换基础设施、共用攻击工具或不同环节临时更换C2，也能解释部分现象。目前没有双方通信、资金往来或样本同源证据，不能据此认定存在漏洞交易，更不能仅凭IP地理位置判断攻击者国籍。后续仍需结合云服务商注册信息、更多受害现场及样本同源分析进一步核实。

六、排查建议

正在使用用友 BIP 高级版或包含相关NC Cloud组件的单位，建议尽快开展以下排查：

1. 检查应用日志。 在各节点 fw-log.log 中检索 sprmonitorServlet、JtaTransactionManager、JNDI location [rmi://、ELProcessor 和 readObject。出现异常不代表必然失陷，但应结合相邻时间的系统事件继续核查。
2. 检查Web目录与内存马。 排查 webapps/nc_web 下是否存在 ncsync.jsp、gzms.jsp，同时检查 /ncsync、/gzsync 路由。仅删除JSP文件不一定能清除已注册的内存Servlet，处置后需重启应用并复查。
3. 检查PowerShell日志。 重点检索事件ID 4104，关注整数数组减固定值后拼接、ScriptBlock.Create、IEX下载及 Update service mesh routing table 等特征。
4. 检查加密器与加密文件。 排查 C:\Windows\System32\ugaqGrklG.exe 及 .rox 后缀文件。随机文件名可能随目标变化，不能仅按本案文件名判断。
5. 检查网络连接。 回溯与本文所列IP及端口的历史连接，同时排查同网段其他用友 BIP 资产，避免只处置单台服务器。
6. 保全现场。 如发现相关痕迹，不要直接重装或清理全部文件，应先保留应用日志、Windows事件日志、内存信息和可疑样本，再开展隔离与处置。

七、IOC与排查线索

类型	值	说明
漏洞入口	/servlet/~uapfw/sprmonitorservlet	Java原生反序列化漏洞入口
第一阶段C2	8.130.77.216:1099	JNDI回连RMI服务
第一阶段文件服务	8.130.77.216:18888	WebShell分发与落地回执接收
勒索阶段C2	192.151.233.247:1099	JNDI回连RMI服务
勒索载荷分发	192.151.233.246:20469	加密器载荷下载
WebShell文件	ncsync.jsp、gzms.jsp	位于 webapps/nc_web 应用目录
内存Servlet路由	/ncsync、/gzsync	删除JSP后仍需检查内存残留
WebShell连接密码	ncw3b2026	两枚WebShell共用，可用于同源关联
加密器	C:\Windows\System32\ugaqGrklG.exe 53b9e395a0cd220baeb6c761f6521858（MD5）	本案主服务器加密器路径
加密后缀	.rox	weaxor勒索家族近期使用的后缀
日志特征	JtaTransactionManager.readObject、JNDI location [rmi://、javax.el.ELProcessor	建议结合同一时间窗口综合判断
PowerShell特征	ScriptBlock.Create、Update service mesh routing table	勒索阶段混淆下载执行脚本

以上IOC用于排查本案相关痕迹，不建议脱离时间和日志上下文单独作为封禁或失陷判定依据。

八、修复与加固建议

1. 尽快联系用友官方。 核实当前版本是否受影响，并获取对应补丁或升级方案。在官方修复到位前，可在边界设备限制 /servlet/~uapfw/sprmonitorservlet 路径的外部访问，操作前需评估业务影响。
2. 收敛互联网暴露面。 承载财务和核心业务数据的系统应尽量部署在内网。确需远程访问时，通过VPN、访问白名单和强认证限制来源。
3. 完整清除后门。 删除恶意JSP后重启应用，复查内存Servlet、异常计划任务、新增账户及其他持久化项，并更换相关服务账户和服务器管理口令。
4. 加强日志集中留存。 保留中间件访问日志、应用日志、PowerShell日志和边界设备日志，并同步至独立日志平台，避免本机日志被清除后失去溯源依据。
5. 排查同类资产。 对同版本、同网段及同一集群节点同步检查，确认没有遗留WebShell或其他入侵痕迹。
6. 规范应急处置。 已出现 .rox 文件或相关业务中断时，应先隔离受影响主机并保护现场，再联系专业团队开展溯源、清除与恢复工作。

如果我是DJ？

传统的ERP软件在现在确实漏洞百出，特别是AI出现后，攻击门槛降低，探索漏洞也更方便了

lidada0627

厉害 厉害 防不胜防

Cleverwwh

IOC 列得很具体，建议同时排查对外暴露的 BIP 端口和数据库账号权限，这类 0day 要尽快打补丁。

无奈的地刺王

感谢分享，确实要注意了