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

写在前面 先向各位读者说明一件事：上周，我们先后发布了两篇关于某国产 ERP 系统漏洞的分析文章。发布后，出于内容严谨性与合规表达的考虑，我们主动对文章做了下架处理，并就相关内容与相关方完成了沟通。目前问题已妥善处理，现将两篇文章合并修订后重新发布：漏洞结论与防护建议保持不变，部分内容做了进一步脱敏。给本周等待更新的读者说一声抱歉，也感谢大家的理解。 回到正题。六月底，我们发布了 Weaxor 与 TellYouThePass 两大家族借管家婆软件攻击国内中小企业的全链路复盘；七月的 JADEPUFFER 复盘中，我们又跟踪了全球首个 AI 自主完成的勒索攻击。两篇文章留下过同一个判断： 勒索组织的漏洞武器化速度正在发生质变，0day 正在取代 Nday 成为主攻方向。 这个判断的第三次验证，来得比我们预想的更快。 7 月底至今，Solar 应急响应团队接连处置了多起 .weax 勒索事件，这一次中招的是 某国产 ERP 系统 的用户。经过历史漏洞逐一排除、本地代码审计与授权环境下的实测复现，我们最终确认：攻击者使用的是该系统一个 此前从未公开过的前台任意文件上传 0day 漏洞 。第一轮研判中，我们认为攻击者依赖的是该系统广泛存活的 出厂默认密码 ；而就在受害客户改完密码之后，同一攻击者再次完成加密，迫使我们重新回到代码，挖出了门槛更低的第二条路： 身份伪造，无需任何账号密码即可上传 webshell 。漏洞定性随之从“已认证任意文件上传”升级为“ 未授权任意文件上传 ”，CVSS 3.1 评分由 8.8（High）升至 9.8（Critical） 。 通过资产测绘，全网约有 3.8 万个资产 部署了该系统，其中超过 99% 位于国内。本文依旧从案发现场讲起，完整还原排查、审计、复现、升级研判的全过程。代码审计部分只讲清漏洞逻辑，不公开漏洞点的具体位置与完整利用方式，相关截图均做打码处理，供同行参考，也防止被直接滥用。相关分析已按流程同步相关方。 一、案发现场：一台被加密的 ERP 服务器 1.1 客户找上门时，局面是这样的 8 月 7 日，一家中小企业联系到我们：公司的 ERP 服务器被勒索，业务文件、数据库备份全部变成了 .weax 后缀的乱码文件，勒索信要求联系攻击者邮箱付费解密。 这台服务器承载着公司整套进销存业务。为了方便外勤人员访问，企业通过边界设备把 ERP 的 Web 服务映射到了公网一个非标准端口上。这是国内中小企业 ERP 极其典型的一种部署方式，也是整起事件的入口前提。 受害服务器上被加密的文件，后缀统一为.weax 从文件系统的加密痕迹看，全盘加密在 7 月 29 日 21:42 结束，大量系统目录、数据库目录下的文件时间戳整齐地停在这一刻。 文件时间戳显示，加密于7月29日21:42结束 1.2 两个可疑的 aspx 文件 取证过程中，我们在 ERP 安装目录的上传文件夹里发现了两个不属于系统的 aspx 文件： D:\...\SYSA\Edit\fNet\billuploadfield\U1\Y2026\M7\202607291947273599.aspx D:\...\SYSA\Edit\fNet\billuploadfield\U1\Y2026\M7\202607291957127978.aspx 这是两个 webshell 。它们存在于服务器只有两种可能：要么攻击者先拿到了服务器权限再手动放进去，要么 系统本身就存在一条可以上传任意文件的通道 。前者在排查中被排除，后者最终被实锤，这是后话。 取证现场发现的webshell文件及其落地路径 先记住这两个文件名的结构，它会在后面的代码审计环节成为关键证据： 1.3 攻击时间线还原 把文件时间戳、残留日志、加密器落盘记录拼在一起，整个作案过程可以还原到分钟级： 时间（7月29日） 动作 19:47 第一个 webshell 经上传通道落盘 19:57 第二个 webshell 落盘；同一秒内大量“日志已被清除”记录出现 21:42 全盘加密结束，业务停摆 三个值得注意的细节： 从 webshell 落地到加密结束，全程不到两个小时 ，中间还包含一次加密器执行失败后的重来。作案节奏干净利落，没有多余试探，说明攻击者对这套流程已经非常熟练； 19:57 这一秒，事件查看器留下大量“日志已被清除”的记录，攻击者在作案过程中 自动化清除了 Windows 关键日志 ，这是 Weaxor 加密器升级后的新能力，后文细说； 当我们想调取 IIS 的 Web 访问日志还原攻击者的 HTTP 请求时，发现 被加密当天的 IIS 日志处于加密状态，无法读取 。这同样不是巧合，也放到后文展开。 二、排查：历史漏洞全部排除，方向收敛到上传通道 溯源的第一步永远是假设排除。这套 ERP 在国内中小企业中装机量不小，公开渠道能查到的历史漏洞主要是 SQL 注入类 。我们把这些已知漏洞点逐一在受害环境上做了验证，结论是： 全部不成立 。 数据库层面也没有异常：没有爆破痕迹，没有可疑的异地登录，ERP 自带的业务日志里找不到攻击者的操作记录。 但 webshell 就在机器上，文件还是 新生成 的，名字完全符合“系统上传功能自动重命名”的风格。到这里，排查方向已经收敛： 系统里一定存在一个文件上传功能的缺陷，让攻击者能把 aspx 文件写进 Web 目录。而公开渠道从未有过这类漏洞的披露，这意味着它是一个 0day。 剩下的问题只有两个：这个上传通道藏在哪段代码里，以及攻击者用什么身份走进了这条通道。 三、代码审计：一条零校验的上传链路 3.1 审计策略：顺着 webshell 的名字往回找 该 ERP 是 .NET 架构，服务端代码编译在几个核心业务 DLL 里，我们对程序集做静态审计。审计不是大海捞针，webshell 本身给了两条极有价值的线索： 文件名结构 ： 202607291957127978.aspx 明显是“时间戳＋随机数＋扩展名”的程序化命名，找到生成这种文件名的代码，就找到了上传逻辑； 落盘路径结构 ： U1\Y2026\M7 明显是“用户 ID＋年＋月”的逐级目录，找到拼接这种路径的代码，就能和受害现场交叉验证。 3.2 入口点审计 系统的 Web 层存在一个通用的文件上传处理逻辑，对外通过一个处理程序接收请求，并按请求中的 cmd 参数分发动作： cmd 参数为空时执行文件上传，命令为删除指令时执行文件删除。 上传和删除共用同一个入口，这种设计本身没有问题，问题出在它对后续参数的完全信任。 代码中上传入口分发逻辑 3.3 客户端传参决定文件落盘位置 跟进上传分支后可以看到， 文件最终写到哪个业务目录，是由客户端请求里的一个目录参数决定的 。代码对参数取值做了简单的映射判断：命中特定取值就写入对应业务目录，其余取值统一落入一个 Web 可访问的业务上传目录。 代码中目录参数映射逻辑 3.4 路径拼接：与受害现场一一对应 继续往下，是落盘路径的逐级拼接逻辑。代码按固定子目录、用户 ID、当前年份、当前月份一层层拼接出最终目录，目录不存在则逐级创建： 代码拼接规则： fNet\billuploadfield\ U{Us