文章总结： 本文复盘Weax勒索病毒利用用友U8Cloud历史漏洞（Nday）入侵事件，攻击者通过匿名探测、UAP内部身份调用写入木马，53秒后投放加密器并清除日志，全程74分钟。溯源难点在于无中间件日志，通过应用日志与主机取证交叉验证还原攻击链。文章提供IOC清单及收敛暴露面、开启日志留存等防护建议。
综合评分： 88
文章分类： 应急响应,恶意软件,漏洞分析,红队,安全运营

【勒索预警】Weax勒索病毒利用阿里云服务器攻击用友系应用，无中间件日志下完成完整溯源（附IOC）

原创

州弟学安全
州弟学安全

solar应急响应团队

2026年9月28日 10:05
山东

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

写在前面

本文首发于 Solar应急响应团队-「州弟学安全、butt3rf1y」，转载请务必注明出处。

这是 Weaxor 勒索家族系列复盘的新一篇，事件发生在 2026 年 9 月 5 日晚间，被攻击的是一套通过动态域名映射到公网的用友 U8 Cloud 系统。

先说明结论：本次事件并不是 0day 攻击，而是利用公开历史漏洞的 Nday 攻击，漏洞本身并不新鲜。本次溯源真正的难点在于另一个层面，用友系的大部分应用默认不开启 Tomcat 等 Web 中间件日志，受害环境正是如此，常规的 Web 访问日志一条路直接断掉。我们最终通过上机提取应用自身产生的日志，从中匹配到关键调用特征，结合主机侧文件时间戳取证，完成了整条攻击链的还原。这个过程对同样部署用友系应用的企业有比较强的参考意义，所以整理成文。

中秋刚过，国庆将至，提前预祝各位国庆节快乐。如假期期间有应急响应、勒索处置需求，可随时拨打我们的 7×24 小时热线 400-6136-816。

国庆不停歇，安全不打烊

一、攻击过程速览

先用一张时间线把全过程讲清楚，均为北京时间。

19:33:03 与 19:33:04，两个阿里云 IP （8.130.8.29、8.148.84.114）在一秒内先后对 U8 Cloud 的外部系统接口 ExtSystemInvokeServer 发起匿名探测，均未成功。

19:41:23，攻击者通过另一个阿里云 IP （39.98.64.130）以 UAP 平台内部身份调用登录服务 ILogin2Service.writeFlag 写入登录标志，同一时刻，JSP 木马 sol.jsp 落地到 U8C 的 Web 部署目录。

19:42:16，攻击者通过木马在 C:\Windows\System32 下投放并运行 Weaxor 家族加密器 UGTfsAcga.exe，距木马落地仅 53 秒。

19:42:17 起，Windows 安全审核日志及 System、Application、PowerShell 等日志被批量清除。

19:42 至 20:47，服务器各磁盘目录文件被批量加密并追加 .weax 后缀，整个加密过程持续约 65 分钟。

先探测、后打击、即刻清日志，整套动作一气呵成，自动化工具链的特征非常明显。

二、没有中间件日志，如何锁定攻击者

正常情况下，溯源 Web 入侵首先翻 Tomcat 或中间件访问日志，但这套环境里什么都没有。我们转变思路，提取了 U8C 应用自身的服务调用日志，这类日志记录了每一次远程调用的五元组信息与方法名，价值极高。

关键记录共三条。前两条是19:33的匿名探测，调用的接口是 ExtSystemInvokeServer，userid 为 anonymous，请求耗时三百到五百毫秒，未读取或写入任何业务数据，属于典型的漏洞可用性探测。两个来源 IP 经威胁情报研判分别为北京与浙江杭州的阿里云节点，其中 8.130.89.29 有明确的漏洞利用行为历史，符合攻击者租用云主机做自动化探测的特征。

第三条是 19:41:23 的漏洞利用成功记录，也是全文最重要的一条日志。

U8 Cloud 应用日志，红框内自上而下为两条匿名探测记录与一条 writeFlag 利用成功记录

$$callid= $$userid= $$ts=2026-09-05 19:33:03 $$msg=thread=http-bio-8088-exec-7; begintime=2026-09-05 19:33:02; &nbsp;costtime=515; &nbsp; userid=anonymous; &nbsp; remoteAddr=8.130.89.29:60308; &nbsp; remoteCallMethod=invokeservlet-u8cloud_extsystem-u8c.server.extsystem.ExtSystemInvokeServer; &nbsp; &nbsp;sqlcosttime=302;readresulttime=0;readrownum=0;readfromclienttime=1;writetoclienttime=0;writetoclientbytes=0;readfromclientbytes=0;notclosedconnectioncount=0
$$callid= $$userid= $$ts=2026-09-05 19:33:04 $$msg=thread=http-bio-8088-exec-12; &nbsp; &nbsp;begintime=2026-09-05 19:33:03; &nbsp;costtime=386; &nbsp; userid=anonymous; &nbsp; remoteAddr=8.148.84.114:60309; &nbsp;remoteCallMethod=invokeservlet-u8cloud_extsystem-u8c.server.extsystem.ExtSystemInvokeServer; &nbsp; &nbsp;sqlcosttime=291;readresulttime=0;readrownum=0;readfromclienttime=1;writetoclienttime=0;writetoclientbytes=0;readfromclientbytes=0;notclosedconnectioncount=0
$$callid=1785229443077-9310 $$userid=#UAP# $$ts=2026-09-05 19:41:23 $$msg=thread=http-bio-8088-exec-13; begintime=2026-09-05 19:41:23; &nbsp;costtime=8; userid=#UAP#; &nbsp; remoteAddr=39.98.64.130.60449; &nbsp;remoteCallMethod=nc.itf.uap.sf.ILogin2Service.writeFlag; &nbsp; &nbsp;sqlcosttime=0;readresulttime=0;readrownum=0;readfromclienttime=3;writetoclienttime=1;writetoclientbytes=100;readfromclientbytes=1780;notclosedconnectioncount=0

把这条日志拆开看。remoteAddr 字段给出攻击者五元组来源 39.98.64.130，端口 60449；userid 为 #UAP#，说明攻击者已经拿到 UAP 平台的内部调用身份，不再是门外的匿名访客；remoteCallMethod 指向 ILogin2Service.writeFlag，即写入登录标志；costtime 仅 8 毫秒，一次干脆利落的内部调用；最值得琢磨的是 readfromclientbytes 为 1780，这次调用从客户端读入了 1780 字节的数据，而对应的 writetoclientbytes 只有 100 字节。一读一写之间，攻击者把接近 2 KB 的东西送进了服务器，只取回一个简短的确认，这正是投递载荷的通信特征。

威胁情报查询结果，漏洞利用来源 IP 39.98.64.130 为北京阿里云节点

应用日志只能证明调用行为本身，木马上传的 HTTP 过程因为没有中间件日志而无法直接呈现，所以我们用主机侧取证做交叉验证。通过 Everything 全盘检索 JSP 文件，在 U8C 的 Web 部署目录下找到 sol.jsp，查看文件属性，其修改时间为 2026 年 9 月 5 日 19:41:23，与 writeFlag 调用记录精确到同一秒，文件大小 1393 字节，与日志中读入的 1780 字节（含编码开销）处于同一量级，两条独立证据链就此闭合。

Everything 检索结果，红框为 Web 目录下的木马 sol.jsp，修改时间 2026/9/5 19:41

sol.jsp 文件属性，修改时间 2026 年 9 月 5 日 19:41:23，与日志记录精确一致

有一处细节需要如实说明。该文件的创建时间显示为 2026 年 7 月 26 日，早于事发日期一个多月。文件时间戳可以被攻击者篡改以干扰溯源，这个创建时间的真实性存疑；但也不能完全排除 7 月 26 日前后已存在早期入侵痕迹的可能，我们已将这一时间点同步给受害单位做进一步核查。溯源工作的严谨之处就在于，证据能支撑到哪一步，结论就说到哪一步。

三、攻击入口的研判思路

很多同行关心一个问题，没有中间件日志，凭什么判断是历史漏洞而不是新的 0day。这里把排查思路完整分享一下，也是此类事件的通用方法论。

对 Java 应用发起溯源，我们的习惯是先排 Nday，再考虑 0day。原因很简单，从统计学上看，绝大多数勒索入侵用的都是已公开漏洞，0day 是少数派，先假设 0day 既不经济也容易把方向带偏。具体到一个 Java Web 应用，攻击者能拿到服务器权限的路径翻来覆去就是那几条。SQL 注入能否进一步命令执行，是否存在直接的命令执行漏洞，是否存在任意文件上传可以写入木马，又或是反序列化漏洞。排查动作就是对照这几条路径，逐一检索目标组件的公开漏洞记录，再回到日志里找匹配特征。

回到本案，用友 U8 Cloud 近年来已公开披露多起无需认证即可利用的历史漏洞，包括 ServiceDispatcher 接口反序列化、多处 Servlet 反序列化以及任意文件上传等，均可在目标服务器上执行代码或写入木马。攻击者先匿名探测外部接口、再以平台内部身份写入登录标志并落地木马的行为链，与利用 U8C 历史漏洞的攻击模式完全吻合。综合证据，我们将本次攻击研判为利用 U8C 未授权接口历史漏洞实施的入侵。

需要坦诚交代一个限制。应急处置后，受害方委托厂商重新部署了系统并更新全部官方补丁，原攻击环境已不存在，我们无法在测试环境中复测具体漏洞点，因此无法断言是哪一个编号的漏洞。把能确定的讲透，把不能确定的讲明，这是对读者负责，也是对溯源工作本身负责。

用友工程师已确认打补丁，我方利用历史漏洞载荷测试未成功

四、木马 sol.jsp 是个什么东西

木马本体的技术细节这里不展开，只讲清两件事，让各位对这个威胁有正确认知。

木马 sol.jsp 文件内容，全部关键类名与方法名均以异或混淆的数组书写

第一，它做了对抗处理。木马中所有敏感字符串，包括 Unsafe、defineAnonymousClass 这类危险关键字，全部用异或运算混淆成数字数组，运行时才还原，专门规避基于明文特征的静态查杀。

第二，它本身只是个加载器。sol.jsp 从请求参数中接收攻击者动态传入的 Java 字节码，通过 Unsafe.defineAnonymousClass 在内存中直接定义匿名类执行，不落盘、不经过常规类加载。这种”传入页面上下文触发 equals”的结构，是冰蝎、哥斯拉等主流 JSP 内存马的典型特征。木马本体没有固定功能，攻击者每次连接都可以更换功能模块，这也是它能躲过常规文件扫描的原因。

五、53 秒完成投放，随后抹除痕迹

木马就位后的事态发展很快。19:42:16，加密器 UGTfsAcga.exe 在 System32 目录下运行，距木马落地 53 秒。19:42:17 起，安全审核日志（事件 ID 1102）与各系统日志文件（事件 ID 104）被批量清除，反溯源动作与加密动作几乎同步开始。

程序执行审计记录，红框为加密器 UGTfsAcga.exe 于 19:42 在 System32 下运行

Windows 事件日志，19:42:17 起安全审核日志与各日志文件被批量清除

19:42 至 20:47，全盘文件被批量加密并追加 .weax 后缀，65 分钟后收工。

Everything 检索 .weax 文件，各磁盘目录自 19:42 起被批量加密（敏感信息已打码）

最后一批 .weax 文件生成于 20:47，对应加密结束时间（敏感信息已打码）

从首次探测到加密结束，全程 74 分钟，且攻击发起时间是北京时间 19 点 33 分，晚 7 点之后。这个时间规律与我们在 Weax勒索病毒系列复盘中多次指出的特征一致，该家族的加密行动几乎全部安排在北京时间晚间，种种迹象高度指向国内人员作案。

六、IOC 清单

攻击源 IP：

| IP | 归属 | 行为 |
| — | — | — |
| 8.130.89.29 | 北京阿里云 | 9 月 5 日 19:33:03 匿名探测 ExtSystemInvokeServer 接口 |
| 8.148.84.114 | 浙江杭州阿里云 | 9 月 5 日 19:33:04 匿名探测 ExtSystemInvokeServer 接口 |
| 39.98.64.130 | 北京阿里云 | 9 月 5 日 19:41:23 调用 ILogin2Service.writeFlag，漏洞利用成功 |

主机侧与网络侧痕迹：

| 类型 | 内容 | 文件MD5 |
| — | — | — |
| 木马文件 | Web 部署目录下 sol.jsp（异或混淆 JSP 内存马加载器，参数名 java） | 2eda5374953b4ff0605c413542a3beb0 |
| 加密器 | C:\Windows\System32\UGTfsAcga.exe（Weaxor 勒索家族） | eb8a0a9edf64c5fb3870969a749a93ab |
| 加密文件特征 | 文件被追加 .weax 后缀 | / |
| 日志清除行为 | 事件 ID 1102（安全审核日志清除）、104（System 等日志清除） | / |
| 被调用接口 | u8c.server.extsystem.ExtSystemInvokeServer（探测）、nc.itf.uap.sf.ILogin2Service.writeFlag（利用） | / |

七、防护建议

第一，收敛暴露面，这是最有效的一条。本案的 U8 Cloud 通过动态域名直接映射到公网，等于把核心 ERP 摆在了攻击者的扫描器面前。ERP、财务、OA 这类系统原则上不应直接暴露公网，必须远程访问的，改为 VPN 或网关白名单，并对外部系统接口实施访问控制。该家族如今越来越倾向于 0day 攻击，偶尔穿插 Nday，补丁无法覆盖所有风险，收缩入口才是根本。

第二，把日志开起来，这是本案最直接的教训。如果受害环境开启了 Tomcat 访问日志并做了集中留存，溯源会顺利得多。建议开启 Web 中间件访问日志并异地留存 180 天以上，同时对事件 ID 1102、104 这类日志清除行为建立实时告警，攻击者抹痕迹的那一刻，就是你收到告警的那一刻。

第三，及时跟进官方补丁，确认核心数据有离线备份。用友官方对历史漏洞均有补丁，本案受害方事后已完成全量更新。备份仍是底线，这里不再展开。

八、写在最后

我们对 Weaxor 勒索家族的跟踪已经持续近一年以上，从攻击入口、家族定性到数据恢复均有公开复盘，部分经典文章整理如下。

【全网首发】Weax与Sorry勒索病毒席卷全国中小企业，深度还原全链路攻击，疑似黑客利用AI挖掘管家婆0day漏洞

【勒索预警】警惕！Weax勒索病毒改用国内IP发起0day攻击，某地产ERP遭加密，完整溯源复盘（附IOC）

【勒索预警】某ERP曝0day漏洞致Weax勒索病毒在国内爆发，波及资产近4万台（合并修订版）

最后同步一个情况。本文案例发生在 9 月 5 日，而就在最近几天，Weax勒索病毒再度爆发，这一轮集中指向某邦 ERP，仅近三天我们就接报并排查了 50 起左右的相关求助。该 ERP 此前曾出现任意文件上传漏洞，我们发布过对应复盘（当时应厂商要求做了脱敏处理，即上面第四篇）。本轮集中爆发的详细案例我们将在节后整理发布，建议关注本公众号，如有最新情况会第一时间同步。

如企业发现 .weax 后缀的加密文件，请第一时间断网隔离受害主机，不要重装系统，不要删除加密文件与勒索信，保留现场后随时联系 Solar 应急响应团队，7×24 小时热线 400-6136-816，或通过应急响应.cn、应急响应.com 发起求助。

也请把这篇文章转发给身边使用用友系应用的朋友，多一次排查，少一起假期里的应急。

文章撰写与优化：州弟学安全

参与应急人员：州弟学安全、butt3rf1y

排版优化：超级油麦

在企业日常的安全运维中，突发勒索病毒往往让人措手不及。遇到这种情况，正确的应急响应流程能够最大程度控制影响范围、降低数据损失。

这里为大家准备了一张完整的《勒索病毒应急处置指南》长图，建议各位安全从业者和IT运维人员收藏备用。如遇突发情况，请保持冷静，参考本图进行快速、规范的处置

附加资料下载：防御与响应同样重要。扫描图末的二维码，还可以直接获取完整的《2025年勒索病毒年报》、《2026年勒索病毒上半年报》以及《勒索处置一体化》等专业文件，帮助大家深入了解当前的威胁趋势，提前做好防御规划。

安全无小事，掌握科学的处置流程，是我们应对突发安全事件最有效的武器。

以下是solar安全团队近期处理过的常见勒索病毒后缀：

勒索攻击作为成熟的攻击手段，很多勒索家族已经形成了一套完整的商业体系，并且衍生了多个分支团队，导致勒索病毒迭代了多个版本。而每个家族擅用的攻击手法皆有不同，TellYouThePass勒索软件家族常常利用系统漏洞进行攻击；Phobos勒索软件家族通过RDP暴力破解进行勒索；Mallox勒索软件家族利用数据库漏洞，如(mssql命令执行)及暴力破解进行加密，攻击手法极多防不胜防。

| | |
| — | — |
| 收录时间 | 相关文章 |
| 2024/12/12 | 【攻击手法分析】勒索病毒如何轻松绕过安全设备防线：第二篇-流量致盲，无声突破 |
| 2024/12/11 | 【攻击手法分析】勒索病毒如何轻松绕过安全设备防线：第一篇-驱动漏洞一击致命 |

有效的预防方法包括针对自身业务进行定期的基线加固、补丁更新及数据备份，在其基础上加强公司安全人员意识。

| | |
| — | — |
| 收录时间 | 相关文章 |
| 2024/06/27 | 【教程分享】勒索病毒来袭！教你如何做好数据防护 |
| 2024/06/24 | 【教程分享】服务器数据文件备份教程 |

案例介绍篇聚焦于真实的攻击事件，还原病毒家族的攻击路径和策略，为用户提供详细的溯源分析和防护启示；

| | |
| — | — |
| 收录时间 | 相关文章 |
| 2024/06/27 | 【案例介绍】赎金提高，防御失效：某上市企业两年内两度陷入同一勒索团伙之手 |
| 2024/01/26 | 【成功案例】某集团公司的Phobos最新变种勒索病毒jopanaxye解密恢复项目 |
| 2024/03/13 | 【成功案例】某集团公司的Phobos最新变种勒索病毒2700解密恢复项目 |
| 2024/04/01 | 【成功案例】间隔数月双团伙先后利用某ERP0day实施入侵和勒索的解密恢复项目 |
| 2024/04/26 | 【成功案例】利用多款国产内网渗透工具勒索数十台虚拟机的babyk解密恢复项目 |
| 2024/05/17 | 【成功案例】RDP暴露引发的蝴蝶效应：LockBit组织利用MSF工具及永恒之蓝漏洞进行勒索入侵 |
| 2024/11/28 | 【成功案例】lockbit家族百万赎金不必付！技术手段修复被加密的数据库，附溯源分析报告 |
| 2025/10/23 | 【成功案例】成功挫败 888 勒索家族历时半年的百万赎金勒索，应急处置全流程高效修复，避免千万损失并获客户赠送锦旗 |

漏洞与预防篇侧重于技术层面的防御手段，针对病毒利用的漏洞和安全弱点，提出操作性强的应对方案：

| | |
| — | — |
| 收录时间 | 相关文章 |
| 2025/01/08 | 【漏洞与预防】RDP弱口令漏洞预防 |
| 2025/01/21 | 【漏洞与预防】MSSQL数据库弱口令漏洞预防 |
| 2025/02/18 | 【漏洞与预防】远程代码执行漏洞预防 |
| 2025/04/10 | 【漏洞与预防】Atlassian Confluence存在远程代码执行漏洞 |
| 2025/04/17 | 【漏洞与预防】畅捷通文件上传漏洞预防 |
| 2025/05/27 | 【漏洞与预防】Microsoft Windows 文件资源管理器欺骗漏洞预防 |
| 2025/09/02 | 【漏洞与预防】Redis CVE-2025-32023 RCE漏洞验证与预防 |

应急响应工具教程篇重点分享应急响应过程中常用工具的安装、配置与使用说明，旨在帮助读者快速掌握这些工具的操作流程与技巧，提高其在实际应急场景中的应用熟练度与效率。

如果您想了解有关勒索病毒的最新发展情况，或者需要获取相关帮助，请关注“Solar应急响应团队”。

全国热线| 400-613-6816

更多资讯| 扫码加入群组交流

喜欢此内容的人还喜欢

Solar应急响应团队

【病毒分析】新版勒索病毒MEDUSA LOCKER 首发深度分析

Solar应急响应团队

【成功案例】成功挫败 888 勒索家族历时半年的百万赎金勒索，应急处置全流程高效修复，避免千万损失并获客户赠送锦旗 Solar应急响应团队

免责声明：

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

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

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

本文转载自：solar应急响应团队州弟学安全
州弟学安全《【勒索预警】Weax勒索病毒利用阿里云服务器攻击用友系应用，无中间件日志下完成完整溯源（附IOC）》

Tags: 安全运营应急响应恶意软件漏洞分析红队

你可能错过

AgentTeams Dashboard v1.2.4.9 发布：一条命令拉起你的 Agent 集群控制台

紧急预警｜.ths勒索软件活动升温多用户文件遭批量加密

F5 修复了 BIG-IP APM 的关键零日漏洞，该漏洞已被远程代码执行攻击利用

朝鲜 TraderTraitor 黑客利用伪造的 Terraform 作业测试部署 macOS 后门