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

写在前面 自今年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 脚本还使用 Upd