写在前面
本文首发于Solar应急响应团队-「州弟学安全（徐龙州）」，转载请务必注明出处。
Solar应急响应团队由思而听（山东）网络科技有限公司组建，长期专注勒索病毒应急响应、攻击溯源与数据恢复，为遭遇突发勒索事件的企业提供7×24小时突发危机干预通道。如企业正在遭受勒索攻击，可通过应急响应.cn(https://solarsecurity.cn/)、 或 应急响应.com(https://www.solarert.com/) 联系我们。
应急响应.cn平台Weaxor勒索家族特征查询，标注家族名称、加密后缀、勒索信样式等关键字段
应急响应.com平台Weaxor勒索家族特征查询，标注家族名称、加密后缀、勒索信样式等关键字段
先交代一下这起事件的背景。Weaxor勒索家族（Rox、Weax、Roxeaw）的攻击目标非常明确，就是国内中小型企业。截至目前，在我们累计处置的近700起勒索应急案例中，中小型企业占比约八成，其中相当一部分与Weaxor家族有关。这类企业的共同点是防护能力薄弱、安全投入有限、业务系统直接暴露公网，对攻击者而言是投入产出比最高的猎物。
我们一直在持续跟进该家族的攻击事件。六月底，我们发布了Weaxor与TellYouThePass两大家族借管家婆软件攻击国内中小企业的全链路复盘《【全网首发】Weax与Sorry勒索病毒席卷全国中小企业，深度还原全链路攻击，疑似黑客利用AI挖掘管家婆0day漏洞》，随后又发布了《【勒索预警】某ERP曝0day漏洞致Weax勒索病毒在国内爆发，波及资产近4万台（合并修订版）》。上周，我们发布了该家族改用国内IP发起0day攻击、某地产ERP遭加密的完整复盘《【勒索预警】警惕！Weax勒索病毒改用国内IP发起0day攻击，某地产ERP遭加密，完整溯源复盘（附IOC） 》。本文是这一系列的最新一起勒索攻击案例。
梳理该家族近一年的攻击轨迹，可以看到一条清晰的分界线。从开始活跃到2026年6月，其攻击入口几乎全部来自护网期间流出的1day、Nday漏洞；进入7月以后，入口开始转向应用系统的0day，且从软件公开可获取到漏洞投入实战的周期被压缩得极短。这些0day从何而来，是AI辅助挖掘、漏洞交易购买，还是源码泄露后的定向审计，目前没有定论，我们会继续跟踪。结合攻击时段、国内代理池的使用方式与作案流程的熟练程度，我们判断该家族背后大概率为国内人员在操作。关于Weaxor家族的加密后缀、勒索信样式等更多细节，可以在应急响应.com上直接查询，此处不再展开。
还需要说明一点。本周正值国家网络安全宣传周，各行业都在开展安全意识宣贯，而该家族对国内企业的攻击并未收敛，反而在这个时间节点保持高频出手，本文披露的案例正是我们近期处置的一起。选择现在公开完整溯源过程，一是提醒仍在使用同类系统的企业尽快自查，二是把攻击者如何绕过官方防护的手法讲透，让防守方看清自己的防线为什么会失效。
阅读说明
按照惯例，本文对受害企业名称、受害资产地址及ERP厂商名称做脱敏处理，配图中的敏感信息已打码。为避免攻击代码扩散，本文不公开完整的可利用载荷，仅展示无害探针与防护验证过程，技术细节以讲清原理为限。
先看影响面。通过资产测绘平台对该ERP相关指纹进行检索，命中资产超过十万条，独立IP四万七千余个。对一款承载财务与核心业务数据的ERP而言，这个暴露面意味着任何一次0day的实战化，波及范围都不会小。
资产测绘平台对该ERP相关指纹的检索结果，命中100,993条，独立IP 47,514个（敏感信息已打码）
一、攻击时间线还原
1.1 时区换算说明
受害站点的IIS访问日志默认使用UTC时区，Windows系统日志使用UTC+8本地时间。下文凡涉及IIS日志与系统日志对照之处，均按"IIS日志UTC时间加8小时等于本地时间"进行换算。
1.2 事发前的持续扫描探测（8月22日至8月29日）
勒索事发前一周，多个浙江杭州代理IP对受害站点发起针对性的反序列化漏洞扫描。从IIS日志看，扫描请求集中指向SaveReport.common.kdsvc接口，请求的User-Agent均为WindowsPowerShell/5.1.26100.8655，请求之间间隔数小时至一天不等，期间未伴随加密器落地等实际入侵行为，判断为自动化脚本的漏洞探测，攻击者在确认目标可利用后才投放加密器。逐条记录如下。
2026年8月22日 19:23:00（本地时间，对应IIS日志UTC时间11:23:00），攻击者IP 36.137.66.81 对受害站点8013端口发起反序列化漏洞扫描。
8013站点IIS访问日志，2026-08-22 11:23:00（UTC）36.137.66.81对SaveReport.common.kdsvc接口的扫描请求（高亮行），User-Agent为WindowsPowerShell/5.1.26100.8655
2026年8月22日 19:45:06（本地时间，对应IIS日志UTC时间11:45:06），攻击者IP 36.137.66.31 对受害站点发起反序列化漏洞扫描。
8013站点IIS访问日志，2026-08-22 11:45:06（UTC）36.137.66.31的扫描请求（高亮行）
2026年8月22日 20:00:36（本地时间，对应IIS日志UTC时间12:00:36），攻击者IP 36.134.184.170 对受害站点发起反序列化漏洞扫描。
8013站点IIS访问日志，2026-08-22 12:00:36（UTC）36.134.184.170的扫描请求（高亮行）
2026年8月23日 19:36:17（本地时间，对应IIS日志UTC时间11:36:17），攻击者IP 36.137.66.114 对受害站点发起反序列化漏洞扫描。
8013站点IIS访问日志，2026-08-23 11:36:17（UTC）36.137.66.114的扫描请求（高亮行）
2026年8月24日 19:18:29（本地时间，对应IIS日志UTC时间11:18:29），攻击者IP 36.137.66.249 对受害站点发起反序列化漏洞扫描。
8013站点IIS访问日志，2026-08-24 11:18:29（UTC）36.137.66.249的扫描请求（高亮行）
2026年8月24日 20:10:31（本地时间，对应IIS日志UTC时间12:10:31），攻击者IP 36.137.66.245 对受害站点发起反序列化漏洞扫描。
8013站点IIS访问日志，2026-08-24 12:10:31（UTC）36.137.66.245的扫描请求（高亮行）
2026年8月25日 19:57:03（本地时间，对应IIS日志UTC时间11:57:03），攻击者IP 36.137.66.108 对受害站点发起反序列化漏洞扫描。
8013站点IIS访问日志，2026-08-25 11:57:03（UTC）36.137.66.108的扫描请求（高亮行）
2026年8月25日 20:20:04（本地时间，对应IIS日志UTC时间12:20:04），攻击者IP 36.137.66.81 再次对受害站点发起反序列化漏洞扫描。
8013站点IIS访问日志，2026-08-25 12:20:04（UTC）36.137.66.81的扫描请求（高亮行）
2026年8月25日 20:49:18（本地时间，对应IIS日志UTC时间12:49:18），攻击者IP 36.137.66.114 再次对受害站点发起反序列化漏洞扫描。
8013站点IIS访问日志，2026-08-25 12:49:18（UTC）36.137.66.114的扫描请求（高亮行）
2026年8月26日 20:16:26（本地时间，对应IIS日志UTC时间12:16:26），攻击者IP 36.134.184.90 对受害站点发起反序列化漏洞扫描。
8013站点IIS访问日志，2026-08-26 12:16:26（UTC）36.134.184.90的扫描请求（高亮行）
2026年8月26日 20:36:28（本地时间，对应IIS日志UTC时间12:36:28），攻击者IP 36.137.66.70 对受害站点发起反序列化漏洞扫描。
8013站点IIS访问日志，2026-08-26 12:36:28（UTC）36.137.66.70的扫描请求（高亮行）
2026年8月27日 19:37:08（本地时间，对应IIS日志UTC时间11:37:08），攻击者IP 36.137.66.70 再次对受害站点发起反序列化漏洞扫描。
8013站点IIS访问日志，2026-08-27 11:37:08（UTC）36.137.66.70的扫描请求（高亮行）
2026年8月27日 20:53:32（本地时间，对应IIS日志UTC时间12:53:32），攻击者IP 36.137.66.229 对受害站点发起反序列化漏洞扫描。
8013站点IIS访问日志，2026-08-27 12:53:32（UTC）36.137.66.229的扫描请求（高亮行）
2026年8月29日 20:13:12（本地时间，对应IIS日志UTC时间12:13:12），攻击者IP 36.134.184.170 再次对受害站点发起反序列化漏洞扫描。
8013站点IIS访问日志，2026-08-29 12:13:12（UTC）36.134.184.170的扫描请求（高亮行）
综合以上日志可以推断，攻击者疑似使用浙江杭州代理池IP段36.137.66.* 与36.134.184.* ，以自动化脚本对互联网上该ERP资产进行反序列化漏洞探测，扫描时间、请求特征与既往Weaxor勒索家族案例一致。该家族的作业模式为先探测、后打击，一旦确认漏洞可利用，即投放勒索加密器执行加密。
1.3 首次漏洞利用成功，加密器落地（8月30日 21:14:23）
2026年8月30日 21:14:23（本地时间，对应IIS日志UTC时间13:14:23），攻击者IP 36.137.66.31 对受害站点发起反序列化漏洞攻击，本次漏洞利用成功，请求返回HTTP 200，耗时585毫秒。
8013站点IIS访问日志，2026-08-30 13:14:23（UTC）36.137.66.31对SaveReport.common.kdsvc接口的攻击请求（高亮行），返回200，耗时585毫秒
对应系统日志显示，2026年8月30日 21:14:24，系统记录Known Folders错误，日志内容为"验证路径为C:\Windows\system32\config\systemprofile\Documents的已知文件夹{fdd39ad0-238f-46af-adb4-6c85480369c7}时发生错误0x80070002"。该时间点与攻击请求仅相隔1秒，对应攻击者通过漏洞获得代码执行能力后以SYSTEM身份触发的环境初始化行为。
Windows事件日志，2026-08-30 21:14:24 Known Folders错误事件（事件ID 1002，错误代码0x80070002，高亮行）
对应系统中，攻击者于21:19将勒索病毒加密器vjGXLhjdx.exe写入（或远程拉取至）C:\Windows\System32\ 目录。
Everything检索C:\Windows\System32目录，勒索加密器vjGXLhjdx.exe（669 KB）写入时间为2026-08-30 21:19（高亮行），同目录可见weax.txt与随后写入的FLBPSzJgq.exe
本次加密器执行疑似出现问题，只完成部分文件加密，并伴随循环清除日志的对抗行为。系统日志显示，2026-08-30 21:19:47.773 安全审核日志被清除（事件 ID 1102，操作账户为 SYSTEM），自 21:19:50 起 System、Application、Windows PowerShell 等日志文件被批量清除（事件 ID 104）。
Windows事件日志，2026-08-30 21:19:47起审核日志及各日志文件被批量清除（事件ID 1102、104，高亮行为安全日志清除事件）
1.4 第二次漏洞利用成功，正式加密（8月30日 21:29:55）
2026年8月30日 21:29:55（本地时间，对应IIS日志UTC时间13:29:55），攻击者IP 36.137.66.81 再次对受害站点发起反序列化漏洞攻击，本次漏洞利用成功，请求返回HTTP 200，耗时9681毫秒。
8013站点IIS访问日志，2026-08-30 13:29:55（UTC）36.137.66.81对SaveReport.common.kdsvc接口的攻击请求（高亮行），返回200，耗时9681毫秒
本次攻击后系统数据文件被正式加密。系统日志显示，21:30攻击者向C:\Windows\System32\ 写入第二个加密器FLBPSzJgq.exe；21:40:22 Application Experience服务进入停止状态，21:45:47该ERP应用服务意外停止，业务随之中断。
Everything检索C:\Windows\System32目录，第二个勒索加密器FLBPSzJgq.exe（669 KB）写入时间为2026-08-30 21:30（高亮行）
Windows事件日志，2026-08-30 21:40:22 Application Experience服务停止、21:45:47该ERP应用服务意外停止（红框标注）
加密完成后，磁盘各目录下生成勒索信RECOVERY INFORMATION.txt。文件修改时间自2026年8月30日 21:19起，与两次攻击的时间节点一一对应。
Everything检索勒索信RECOVERY INFORMATION.txt，D盘各目录下批量生成，修改时间集中于2026-08-30 21:19至21:23
1.5 攻击时间线总览
从事发前一周的十四次探测，到8月30日晚两次利用成功、半小时内完成加密，作案节奏与上一篇复盘中披露的过程高度一致。真正值得追问的是另一个问题，攻击者为什么能一次命中。
二、历史漏洞复核：公开PoC为什么全部失效
应急响应过程中，我们使用该接口曾公开的历史反序列化漏洞PoC（ViewState载荷、CloseForm接口）对目标进行复测，全部无法复现成功，请求被防护组件拦截并返回HTTP 406。复核所用公开PoC请求如下（载荷过长，此处截断）。
POST /k3cloud/Kingdee.BOS.ServiceFacade.ServicesStub.DynamicForm.DynamicFormService.CloseForm.common.kdsvc HTTP/1.1
Host: [受害资产已脱敏]:8013
User-Agent: Mozilla/5.0 (Windows NT 4.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2049.0 Safari/537.36
Connection: close
Accept: */*
Accept-Language: en
Content-Type: text/json
xxxxx: dir
Accept-Encoding: gzip, deflate
Content-Length: 15909
{"ap0": "AAEAAAD/////AQAAAAAAAAAMAgAAAFdTeXN0ZW0uV2luZG93cy5Gb3Jtcy……（公开PoC载荷过长，此处截断）"}
Burp Suite重放公开PoC（CloseForm.common.kdsvc，ViewState回显载荷），目标返回HTTP 406 Not Acceptable，漏洞无法复现
到这里存在两种可能：其一，攻击者所利用的漏洞在我们应急进场前已由该ERP官方打补丁修复，公开PoC因此失效，攻击者用的其实是Nday。其二，该接口存在其他可利用的未知漏洞，即0day。
这两种可能必须分清楚，定性完全不同。我们与客户核实了该ERP的维护情况，客户反馈厂商人员曾于2026年9月4日远程上机。如果9月4日的远程操作包含打补丁动作，那么补丁文件的修改时间应当落在9月4日。我们随即检查了该ERP站点全部程序文件的修改时间，结果为全量DLL的最晚修改时间停留在2026年9月3日13时18分，9月4日没有任何程序文件被更新。也就是说，9月4日的远程上机并未执行补丁操作。
受害服务器该ERP站点程序目录全量DLL修改时间检索，最晚修改时间为2026年9月3日13时18分，9月4日厂商远程上机未更新任何程序文件（截图已打码）
更关键的是后一步。我们在当前环境上完成了后续复现验证，防护组件仍然在线，公开PoC依旧被拦截，而绕过路径依然可以打通。这证明无论是攻击发生的8月30日，还是我们复现验证的当下，官方现有防护对该利用路径均无拦截能力。两种可能中，第一种被排除，本次攻击定性为0day，准确说是对已知历史漏洞官方防护的绕过型0day。
为查明公开PoC失效的原因与攻击者实际利用路径，我们对目标站点同版本全套程序集开展代码审计，过程如下。
三、代码审计：防护是怎么被绕过的
3.1 审计目标与审计材料
攻击特征来自IIS日志原文（受害资产地址已脱敏）。
2026-08-30 13:14:23 192.168.*.* POST /k*****/K*****.BOS.ServiceFacade.ServicesStub.DevReportService.SaveReport.common.kdsvc - 8013 - 36.137.66.31 Mozilla/5.0+(Windows+NT;+Windows+NT+10.0;+zh-CN)+WindowsPowerShell/5.1.26100.8655 - 200 0 0 585
初步排查发现两个矛盾点。
使用公开的Nday PoC（ViewState载荷、CloseForm接口）对该目标复测，全部失败（HTTP 406）。 该ERP官方近期未发布新补丁，但攻击者一次命中并成功执行。
因此本次审计目标确定为，查明该目标上公开漏洞失效的原因、攻击者实际利用路径，并评估当前防护体系的真实有效性。
审计材料为同版本站点全套 DLL 反编译源码（ilspycmd 导出），重点覆盖 Kingdee.BOS.ServiceFacade.KDServiceFx、Kingdee.BOS.ServiceFacade.Common、BINAttBlocking 三类程序集。
3.2 审计步骤1：请求路由与免认证机制
路径导航，站点Web.config → system.webServer → handlers节。
<add name="kdsvc" path="*.kdsvc" verb="*"
type="Kingdee.BOS.ServiceFacade.KDServiceFx.KDServiceHandler,Kingdee.BOS.ServiceFacade.KDServiceFx" />
站点Web.config handlers节，kdsvc处理器注册项，全部*.kdsvc请求由KDServiceHandler接管（高亮行）
路径导航：Kingdee.BOS.ServiceFacade.KDServiceFx →UriUtils.cs第 17 行
if (appRelativeUrl.EndsWith("common.kdsvc"))
{
string text = Path.GetDirectoryName(appRelativeUrl).Trim('~');
value = ((string.IsNullOrEmpty(text) || StringUtils.EqualsIgnoreCase(text, "\a")) ? true : false);
}
dnSpy反编译UriUtils.cs，URL以common.kdsvc结尾即免认证放行的判定逻辑（红框标注）
审计发现 1：URL 以 .common.kdsvc 结尾即免认证放行。该设计导致 ServicesStub 下全部服务方法可匿名调用，SaveReport 仅为其中之一，与攻击日志吻合。
3.3 审计步骤2：反序列化格式由客户端任意指定
路径导航：Kingdee.BOS.ServiceFacade.KDServiceFx → RequestExtractor.cs 第 83 行
public MessageFormats Format
{
get { return ExtractForm("format", MessageFormats.Json); }
}
dnSpy 反编译 RequestExtractor.cs，Format 属性直接取自客户端提交的 format 参数（红框标注）
路径导航：Kingdee.BOS.ServiceFacade.Common → MessageFormats.cs
public enum MessageFormats
{
Xml,
Json,
Atom,
[Obsolete("Binary will be discarded for security reasons. Please use KingdeeXml format instead.")]
Binary,
KingdeeXml
}
dnSpy 反编译 MessageFormats.cs，Binary 枚举项已被标注 Obsolete 废弃，但仍保留在枚举中
Binary（format=3）已被官方标注废弃，但启用开关默认为开。
路径导航：Kingdee.BOS.ServiceFacade.Common → SerializerManager.cs（InitCfg 方法）
EnabledBinary = !"false".Equals(GetConfigItemValue("EnabledKDSVCBinary"), StringComparison.OrdinalIgnoreCase);
dnSpy 反编译 SerializerManager.cs InitCfg 方法，EnabledBinary 开关的默认启用逻辑（红框标注）
审计发现 2：未显式配置 EnabledKDSVCBinary=false时，Binary 反序列化通道即为启用状态，且序列化格式由客户端通过 format 参数任意指定。
3.4 审计步骤3：反序列化执行点（漏洞本体）
路径导航：Kingdee.BOS.ServiceFacade.Common → BinaryFormatterProxy.cs 第 79 至 91 行
public object Deserialize(string content, Type type)
{
BinaryFormatter binaryFormatter = new BinaryFormatter();
byte[] array = encoder.Decoding(content);
...
using (MemoryStream serializationStream = new MemoryStream(array))
{
return binaryFormatter.Deserialize(serializationStream);
}
}
dnSpy 反编译 BinaryFormatterProxy.cs，Deserialize 方法直接调用无类型限制的 BinaryFormatter.Deserialize（红框标注）
审计发现 3：调用链为 ExecuteServiceModule.OnProcess（第 36 行构造序列化器）→ ServiceExecutor.DeserializeParameters（第 82 行传入客户端参数原串）→ 上述 Deserialize。全程无 SerializationBinder、无类型白名单，客户端可控数据直达反序列化执行点。
3.5 审计步骤4：官方防护组件分析，特征硬编码
路径导航：站点 Web.config → system.webServer → modules 节
<add name="BINAttBlockingModule" type="BINAttBlocking.BINAttBlockingModule,BINAttBlocking" />
站点 Web.config modules 节，官方防护组件 BINAttBlockingModule 的注册项（高亮行）
路径导航：BINAttBlocking →BINAttBlockingModule.cs
private static string principleStr =
"[['Response','Write'],[', Version=',', Culture=','AAEAAAD/////AQAAAAAAAAAMAgAAA'],['Diagnostics.Process']]";
dnSpy 反编译 BINAttBlockingModule.cs，硬编码的三组载荷特征检测规则 principleStr（红框标注）
审计发现4：防护组件将公开PoC的载荷特征硬编码为三组检测规则，组内全部命中、组间命中其一即拦截。
命中任意一组即返回HTTP 406。此机制即为公开Nday PoC全部失效的直接原因，实测试证见复现验证第2节。
检查逻辑中另存在鲁棒性缺陷（第62至77行），参数值Base64解码失败时异常被空catch吞掉、直接跳过检查，该缺陷本身即构成检测绕过面的一部分。
3.6 审计步骤5：绕过路径，框架自带HexEncoder通道
路径导航：Kingdee.BOS.ServiceFacade.Common → BinaryFormatterProxy.cs 构造函数
if (urlform_encode)
{
encoder = new HexEncoder(encoding); // 十六进制解码器
}
else
{
encoder = new Base64Encoder(encoding);
}
dnSpy 反编译 BinaryFormatterProxy.cs 构造函数，urlform_encode 为真时编码器切换为 HexEncoder（红框标注）
路径导航：Kingdee.BOS.ServiceFacade.KDServiceFx →FormRequestExtractor.cs第 12 行
if (request.ContentType.StartsWith("application/x-www-form-urlencoded"))
{
base.UrlForm_Encode = true;
}
dnSpy 反编译 FormRequestExtractor.cs，Content-Type 为 form 表单时 UrlForm_Encode 置为真的判定逻辑
审计发现5（绕过原理）：当请求Content-Type为form表单时，框架自动切换为十六进制编解码。十六进制字符串（纯0-9a-f字符）经BINAttBlocking的Base64解码后为乱码，三组特征全部无法命中，请求放行；服务端HexEncoder按十六进制正确还原出BinaryFormatter序列化流并执行反序列化。特征黑名单在此传输方式下完全失去检测对象，无论载荷内容包含何种已知特征。
3.7 审计结论
漏洞根因未修复。kdsvc框架format=3（Binary）参数反序列化路径调用无类型限制的BinaryFormatter，该问题为2023年起公开披露的历史漏洞（影响6.2.1012.4至8.1.0.20221110），代码中虽已标记Obsolete但默认仍处于启用状态。 官方现有防护为特征黑名单机制，且检测规则直接硬编码公开PoC的载荷特征。防护组件BINAttBlocking对参数值进行Base64解码后匹配三组固定字符串，该机制是公开Nday失效的直接原因。 防护可被完整绕过（本次实测确认）。利用框架自带的HexEncoder编码通道（Content-Type为application/x-www-form-urlencoded时自动启用），攻击载荷以十六进制传输，特征黑名单完全失效，反序列化执行点照常可达。 结论定性。该漏洞构成"已知漏洞的防护绕过"，在已部署官方防护组件的版本上依然可被未授权远程代码执行。
四、复现验证（授权环境实测记录）
以下全部请求在目标环境实测通过。为避免攻击代码扩散，本节仅展示无害探针与防护验证过程，不含可直接利用的攻击载荷。
验证1：接口匿名可达性验证
POST /k*****/K*****.BOS.ServiceFacade.ServicesStub.DevReportService.SaveReport.common.kdsvc HTTP/1.1
Host: [受害资产已脱敏]:8013
Content-Type: text/json
Content-Length: 25
{"parameters":[],"format":"1"}
Burp Suite实测，未携带任何凭据请求SaveReport.common.kdsvc接口，返回HTTP 200及False
实测结果：HTTP 200，返回False。接口免认证可达。
验证2：防护机制在线性验证（特征探针）
构造合法Base64且解码后同时包含三组特征的探针参数。
POST /k*****/K*****.BOS.ServiceFacade.ServicesStub.DevReportService.SaveReport.common.kdsvc HTTP/1.1
Host: [受害资产已脱敏]:8013
Content-Type: text/json
Content-Length: xxx
{"parameters":["LyBWZXJzaW9uPTQuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgQUFFQUFBRC8vLy8vQVFBQUFBQUFBQUFNQWdBQUFELCBTeXN0ZW0uRGlhZ25vc3RpY3MuUHJvY2VzcywgUmVzcG9uc2UuV3JpdGU="],"format":"3"}
Burp Suite实测，发送同时包含三组特征的Base64探针参数，目标返回HTTP 406 Not Acceptable
（该Base64解码内容为 , Version=4.0.0.0, Culture=neutral, AAEAAAD/////AQAAAAAAAAAMAgAAA, System.Diagnostics.Process, Response.Write）
实测结果：HTTP 406。确认BINAttBlocking特征黑名单在线，公开Nday PoC失效原因成立。
验证3：Binary反序列化通道存活验证
POST /k*****/K*****.BOS.ServiceFacade.ServicesStub.DevReportService.SaveReport.common.kdsvc HTTP/1.1
Host: [受害资产已脱敏]:8013
Content-Type: text/json
Content-Length: 33
{"parameters":["AAAAbbbb"],"format":"3"}
Burp Suite实测，format=3请求返回HTTP 200，响应体为BinaryFormatter序列化的异常对象（以AAEAAAD开头）
实测结果：HTTP 200。响应体为服务端BinaryFormatter序列化的异常对象（以AAEAAAD开头），解码后包含完整调用栈（ServiceExecutor.Execute → DeserializeParameters）与组件版本号8.0.319.1。异常回显本身即为反序列化执行点存活的直接证据。
验证4：完整利用链路验证
在上述绕过路径基础上，我们使用内部开发利用工具完成完整利用链路验证，漏洞利用成功。为避免攻击代码扩散，此处仅展示验证结果截图，不公开载荷细节。
内部开发利用工具验证漏洞利用成功（载荷细节不公开）
至此，攻击路径全部闭环。攻击者利用该ERP的kdsvc接口BinaryFormatter反序列化漏洞，经HexEncoder编码通道绕过官方特征黑名单防护，在服务器上以SYSTEM权限执行命令并投放勒索加密器完成加密。
五、修复建议
第一（根治，优先执行），关闭Binary格式反序列化总开关
在站点Web.config的appSettings节增加官方配置项。
<add key="EnabledKDSVCBinary" value="false" />
配置后服务端将直接拒绝format=3请求，Base64与Hex通道同时失效，本文全部利用路径均被阻断。修改后需重启站点应用程序池。需要注意的是，仍依赖二进制通道的旧版客户端及部分二次开发程序需同步升级改造，变更前建议在测试环境评估兼容性。该项亦为该ERP官方临时补丁的核心内容，但大量环境仅部署了特征拦截组件而未关闭Binary总闸，属于当前防护失效的最主要原因。
第二（版本升级，消除根因），升级至官方彻底修复版本
升级至Binary格式真正移除的版本。执行顺序需遵循官方知识库要求，先安装全量补丁、再安装临时补丁，顺序颠倒会导致临时补丁安装失败。升级完成后使用本文复现验证第4节的Hex探针复测，返回非200方可确认修复。
目前Solar应急响应团队已将此漏洞提交至国家信息安全漏洞平台并已审核通过。
第三（暴露面收敛与纵深防御）
.common.kdsvc免认证通道收敛。该机制由框架硬编码实现，无法通过配置关闭，应在边界层控制，管理中心及业务端口原则上不暴露公网，确需暴露的通过WAF或网关白名单限制可访问的服务路径。 特征规则加固（过渡措施）。可增加行为特征规则，如Content-Type为form-urlencoded且format=3且参数值为超长连续十六进制字符串（建议阈值大于1000字符）。需要明确，特征黑名单为追赶式防护，本文的绕过方式即证明其局限性，仅可作为升级完成前的过渡措施。 监控与审计。对kdsvc全部format=3请求实施审计留痕，框架日志会记录方法名与参数值，十六进制长串本身即为检测线索。对406告警进行叠加分析，特征拦截命中数下降不代表攻击消失，需结合反序列化执行点的行为综合研判。
六、IOC清单
攻击源IP（均为中国浙江杭州，疑似代理池）
提醒各企业安全团队，建议直接加黑36.137.66.0/24与36.134.184.0/24两个网段。经核实，这两个网段内IP几乎全部为代理池地址，正常业务来自该网段的概率极低，加黑的误伤风险可控。
主机侧痕迹
网络侧特征
七、写在最后
本次事件为一起典型的"先探测、后打击"勒索攻击。攻击者自8月22日起对受害站点持续扫描一周，8月30日晚两次利用成功，半小时内完成加密并批量清除系统日志对抗溯源。
回看整个过程，最值得防守方记住的一点：告警在线不等于防护有效。本案中官方防护组件始终在线，公开PoC也确实被全部拦截，但攻击者换了一种编码方式就穿了过去。防护有效性的验证，应当以反序列化执行点的行为为准，而不是以拦截层的告警为准。如果你的企业正在使用同类系统，请按第五节的顺序立即执行修复，不要等。
思而听防勒索AI疫苗（SAR）目前已支持Weaxor勒索家族相关病毒的密钥捕获。SAR的核心思路是在勒索软件启动加密行为的瞬间，从内存中捕获加密密钥并留存，让数据恢复不必完全依赖攻击者"守信"。截至2026年上半年，SAR已支持69个勒索家族、87种加密后缀的密钥捕获，累计输出47份专项解密方案。
SAR捕获勒索家族密钥的后台日志（示意图）
Solar勒索解密工具使用捕获的密钥完成恢复，6个被加密文件全部解密成功
如遇突发勒索事件，可通过应急响应.cn(https://solarsecurity.cn/)、 或 应急响应.com(https://www.solarert.com/) 联系我们，7×24小时突发危机干预通道保持在线。
文章撰写与优化：州弟学安全（徐龙州）
参与应急人员：州弟学安全、月华
排版优化：超级油麦
在企业日常的安全运维中，突发勒索病毒往往让人措手不及。遇到这种情况，正确的应急响应流程能够最大程度控制影响范围、降低数据损失。
这里为大家准备了一张完整的《勒索病毒应急处置指南》长图，建议各位安全从业者和IT运维人员收藏备用。如遇突发情况，请保持冷静，参考本图进行快速、规范的处置
附加资料下载： 防御与响应同样重要。扫描图末的二维码，还可以直接获取完整的《2025年勒索病毒年报》、《2026年勒索病毒上半年报》以及《勒索处置一体化》等专业文件，帮助大家深入了解当前的威胁趋势，提前做好防御规划。
安全无小事，掌握科学的处置流程，是我们应对突发安全事件最有效的武器。
相关文章 | |
相关文章 | |
| 【教程分享】勒索病毒来袭！教你如何做好数据防护 | |
案例介绍篇聚焦于真实的攻击事件，还原病毒家族的攻击路径和策略，为用户提供详细的溯源分析和防护启示；
相关文章 | |
| 【案例介绍】赎金提高，防御失效：某上市企业两年内两度陷入同一勒索团伙之手 | |
| 【成功案例】某集团公司的Phobos最新变种勒索病毒jopanaxye解密恢复项目 | |
| 【成功案例】某集团公司的Phobos最新变种勒索病毒2700解密恢复项目 | |
| 【成功案例】间隔数月双团伙先后利用某ERP0day实施入侵和勒索的解密恢复项目 | |
| 【成功案例】利用多款国产内网渗透工具勒索数十台虚拟机的babyk解密恢复项目 | |
| 【成功案例】RDP暴露引发的蝴蝶效应：LockBit组织利用MSF工具及永恒之蓝漏洞进行勒索入侵 | |
| 【成功案例】lockbit家族百万赎金不必付！技术手段修复被加密的数据库，附溯源分析报告 | |
相关文章 | |
相关文章 | |
| 【应急响应工具教程】取证工具-Volatility安装与使用 | |
| 【应急响应工具教程】流量嗅探工具-Tcpdump | |
| 【应急响应工具教程】一款精准搜索文件夹内容的工具--FileSeek | |
| 【应急响应工具教程】一款自动化分析网络安全应急响应工具--FindAll | |
全国热线| 400-613-6816
更多资讯| 扫码加入群组交流