Solar应急响应团队丨AI 正在改写漏洞战争：从管家婆 211 端口 RCE 看自动化勒索攻击链

2026-07-09 来源：互联网

一个没有开放数据库端口的内网，一个密码足够复杂的数据库账号，一台没有任何Web漏洞的服务器——却在一夜之间被勒索病毒加密了全部文件。

更诡异的是，所有日志干干净净，没有任何入侵痕迹。仿佛黑客是"隔空取物"。

这不是电影情节。过去几个月，Solar应急响应团队连续处置了多起.weax（Weaxor家族）和.sorry（Tellyouthepass家族）勒索事件。受害者有一个惊人的共同点：他们都部署了"管家婆"系列管理软件。

经过深度逆向分析与靶场验证，我们最终把入口锁定在一个被绝大多数运维忽视的211端口上——一个无需任何口令、无需加密狗、无需客户端即可触发的未授权远程代码执行（RCE）漏洞。

图片1.png

一、线索汇聚：两起案例指向同一个入口

案例A：Tellyouthepass家族（加密后缀.sorry）

第一起案例是一家制造业公司被.sorry加密。在其磁盘镜像里提取到了服务端程序包，解压后发现关键文件ScktSrvr.exe（680960字节）。这台机器对公网开放的端口里，211端口（TCP）处于监听状态且加密发生后仍存活，而1433（SQL Server）并未对公网放行。

案例B：Weaxor家族（加密后缀.weax）

第二起案例的SQL Server默认追踪日志（log_*.trc）中有一条铁证级记录：

图片2.png

攻击者在加密前一天，用sa身份开启了OLE Automation Procedures（执行OS命令的前置动作）。但问题是：sa是怎么被拿到的？1433又没开。

共同点收敛

两起案例并排对比，线索全部指向同一个东西：那个开着的211端口。它不是Web端口、不是数据库端口，而是管家婆客户端连服务端用的应用层socket端口。在1433不暴露的前提下，唯一能让sa在本地被执行的路径，就是经211端口——借管家婆应用自身的sa连接，绕过数据库端口的封堵。

二、211端口的真身：Delphi MIDAS Socket Server

管家婆是典型的C/S两层半架构。客户端（GraspNet.EXE）并不直接连数据库，而是先连到服务端的"中间件"scktsrvr.exe，它再转交给业务程序GraspSvr.exe，业务程序最终以sa身份连接SQL Server。

完整的数据流路径：

图片3.png

scktsrvr.exe来自Borland/Delphi技术体系，正式名称叫Borland Socket Server，是MIDAS/DataSnap架构中专门搬运数据的socket传输层程序。它用的是MIDAS私有二进制协议（不是HTTP），这决定了两个致命后果：

●它不是Web漏洞。WAF、Web日志、URL审计统统看不到它——它根本不在Web管道里。

●它默认不产生登录日志。连接建立阶段没有应用层认证，握手成功也不写登录记录。攻击者全程在日志里留不下痕迹。

这就完美解释了之前的悖论：受害者环境没有痕迹，不是因为没被打，是因为这条管道压根不记日志。

三、逆向分析：从零认证到任意方法调用

3.1 握手阶段：没有任何认证

我们将靶机上的scktsrvr.exe（版本7.0.4.453）放入IDA Pro进行逆向。

scktsrvr的运行参数读自注册表 HKLMSOFTWAREWOW6432NodeBorlandSocket Server。Delphi的Socket Server设计上支持一个叫InterceptGUID的"鉴权拦截器"——如果配置了这个GUID，每条连接都会先经过COM拦截器做认证。

经查证：InterceptGUID为空。意味着没有任何鉴权拦截器被插入连接流程。任何人TCP连上211，都能直接进入MIDAS协议层。这是整个漏洞的根。

3.2 协议主循环：分发器 sub_48B820

握手成功后，连接进入解释器主循环。地址0x48B820的函数读取1字节action，按switch分发：

图片4.png

3.3 方法调用入口：Invoke解释器 sub_48C050

action=2进入方法调用解释器（0x48C050），它连续读取6个"变体（Variant）"，然后直接调用AppServer的IDispatch::Invoke——COM里的通用方法调用接口：

图片5.png

关键发现：从"握手成功"到"IDispatch::Invoke被调用"之间，没有任何权限校验——没有"未登录返回错误"、没有"权限不足"、没有黑名单。握手能过，AppServer暴露的任意方法都可被自由调用。

3.4 变体的网络编码格式

变体读取器（0x48A89C）揭示了数据在网络上的编码方式：

图片6.png

值得注意的是，变体类型大小表word_491354只有20个有效条目（type 0-19），type≥0x14时会越界读到指针碎片，这是个真实的内存安全缺陷代码模式（后文会讨论其可利用性）。

四、MITM抓包：拿到协议的"地面真相"

逆向告诉我们"协议的零件长什么样"，但没告诉我们"零件怎么组装成完整数据包"。我们在IDA里推断的包头格式反复失败——服务器总是返回Invalid variant type。

最稳的办法：搭建中间人（MITM），让真实的管家婆客户端从中间过一遍，把真实数据包字节抓下来对照。

抓包方案

图片7.png

客户端登录一次，我们抓到了880条消息的完整双向字节流。第一条客户端握手包（92字节）揭示了包结构：

图片8.png

关键纠错：动作类型在签名里，不在载荷里

继续分析后续消息：

图片9.png

这就是我们之前反复踩坑的原因——数据包的"动作类型"藏在签名的第一个字节里，而不是载荷内部。差一个字节的位置，卡了很久。抓包一对照，豁然开朗。

还原出的完整方法调用序列

这条序列给了最后两块拼图：方法名→dispid是动态查的（ACT3），所以跨版本通用；真正执行SQL的是OpenSQL + AS_GetRecords这一对组合。

图片10.png

五、构造PoC：从无凭据握手到SYSTEM

5.1 无凭据握手

按还原出的字节布局构造握手包，直接建立连接——无需任何凭据。

5.2 必须先初始化会话

握手成功后直接发OpenSQL会收到"Provider not exported"错误。对照抓包序列才明白：必须先调ConnectDb注册客户端，再调ChangeDb选择账套。

这里有一个让攻击"零先验知识"的关键点：

ChangeDb选的账套名"hherpmaster"是管家婆的默认系统主账套，每套管家婆装好就有、名字固定。攻击者不需要事先知道受害者的业务账套叫什么。而且xp_cmdshell是SQL Server服务器级功能，不依赖具体业务账套。

如果攻击者还想精准打击某个业务账套，甚至可以连上后直接 select name from master.sys.databases 把所有账套列出来——实测一条SQL就能枚举完毕。

5.3 执行任意SQL → OS命令

图片11.png

会话初始化完成后，攻击链和真实客户端一致：

AS_GetRecords一旦触发，GraspSvr就以sa身份将SQL送入SQL Server；xp_cmdshell把命令交给操作系统。在我们靶机上，SQL Server服务以LocalSystem运行，攻击者获得的是NT AUTHORITYSYSTEM权限——Windows用户态最高权限。

注意：并非所有部署的SQL服务都是LocalSystem，不同安装方式可能使用更低权限的服务账户（如NETWORK SERVICE、NT SERVICEMSSQLSERVER），此时OS命令权限会相应降低。但"未授权以sa执行任意SQL"这个核心漏洞不受影响。

六、落地验证与取证

我们在靶场上完成了两项物证级验证：

物证一：OS命令执行 + SYSTEM权限确认

经xp_cmdshell在靶机C:写下标记文件，经验证文件所有者为NT AUTHORITYSYSTEM。攻击者由此可装勒索、停服务、清日志，横向移动到其它主机则通常还需进一步窃取/复用凭据（非一步到位）。

物证二：未授权DDL执行（持久表）

经同一条无凭据链路执行DDL：

图片12.png

表持久存在于数据库中，是"未授权→sa任意SQL"的铁证。最终在客户授权下进行实网测试，全流程闭环确认。

回溯悖论的完整解释

到这里，最初的悖论彻底解开：

●不产生登录日志：MIDAS握手无认证、不记录"谁连进来了"

●不触发登录失败告警：根本没用口令，没有"失败"可言

●不经过Web：WAF / Web日志完全看不到

●借用应用自身的sa连接：1433没开也无所谓，命令是从应用内部发出去的

●唯一痕迹只在SQL默认trace里（且默认trace并非所有部署都保留/被检查）

所以受害者环境看起来没有痕迹——不是没被打，是这条管道天生不留常规脚印。

七、缓冲区溢出：有缺陷代码，但被异常机制中和

除了应用层RCE，我们还调查了协议解析层是否存在内存破坏漏洞。

受害者日志中的崩溃证据

案例A受害者的Application.evtx中有30条ScktSrvr.exe的AppCrash记录（两组不同WER哈希）。崩溃点0x4041d9经反汇编确认落在Delphi运行时的SEH链代码（mov fs:[0], eax），这是SEH链被破坏的强签名——栈溢出覆盖SEH后，异常处理二次崩溃的典型落点。

严格来讲，要坐实"可控SEH覆盖"还需要崩溃转储来观察被覆盖的SEH记录；目前仅有崩溃日志，未取得dump，故此处为"高度可疑的栈/SEH破坏"。

管家婆7.0上的实测结论

变体读取器的default分支存在确凿的栈溢出代码模式：

图片13.png

但在7.0上实测：发type 0x14（各种长度payload），服务器全部优雅返回"Invalid variant type"，进程PID不变。原因是Delphi在用到被破坏的返回地址之前，就先抛了EVariantError，被外层分发器的SEH兜住。内存写确实发生，但崩不出来、控不了执行流。

诚实结论：真正被勒索利用的是"未授权MIDAS→SQL→RCE"的应用层路径，不是缓冲区溢出。但11.0版本（案例A）的崩溃记录表明更高版本可能存在可利用的内存破坏——有待后续验证。

八、这不是一个产品的问题，而是一类漏洞

研究过程中有两个发现让我们意识到问题的广度：

同源架构

案例A的XXXServer.rar中也有ScktSrvr.exe（版本11.0.2804.9245，产品名"CodeGear Socket Server"），和管家婆同源。其业务程序XXXServerZz.exe实现了标准的Delphi IAppServer接口（含标准类型库GUID {1AEFCC20-...}、AS_Execute、AS_GetProviderNames，以及关键属性poAllowCommandText），攻击路径是AS_Execute(provider, CommandText=任意SQL)直接执行。底层入口完全一样：211端口、scktsrvr、无认证。

网段扫描验证

对靶机所在网段做211端口扫描，一次发现4台不同应用开放211。用我们的工具去连，全部返回：

图片14.png

说明它们是别的Delphi MIDAS应用（不同CLSID），管家婆的"钥匙"开不了它们的锁。但攻击者手里有一本"CLSID字典"——逆向多种应用客户端提取各自AppServer的CLSID，扫描器先用04 da探针确认"这是MIDAS服务"，再逐个试字典中的CLSID，命中后套对应方法集攻击。

结论：任何"Delphi MIDAS socket应用 + scktsrvr无认证 + AppServer有SQL/命令执行能力"的组合都中招。管家婆只是暴露量最大的一类。

图片15.png

九、AI驱动的漏洞武器化：一个严肃的假设

截至本文发布时，Weaxor和Tellyouthepass的攻击目标正在快速扩展。此前两个家族主要利用护网期间的1day和Nday漏洞，但近期态势明显变化——开始将矛头指向管家婆物联通、管家婆ERP等更多产品线，且基本都是以0day漏洞作为突破口。这种攻击面的快速转移和武器化速度，与以往的攻击模式形成了强烈反差。

管家婆系列软件在互联网上可直接下载安装包，任何人都能轻易获取目标程序。从公开下载到漏洞被武器化投入实战，周期被压缩得极短。

严肃假设：勒索组织可能正在借助AI辅助进行自动化漏洞审计，大幅缩短了从"发现漏洞"到"勒索变现"的时间线。这不再是传统的"漏洞挖掘→分析利用→传播攻击"线性流程，而可能演变成AI驱动的批量审计、快速武器化、精准投放的闭环模式。

十、防御建议（按优先级）

P0 - 立即执行：收敛暴露面

●211端口禁止对公网开放。安全组/防火墙仅放行业务必需的可信IP。

●这是性价比最高的一步——漏洞再严重，连不上就打不了。

●缺点：一旦客户端IP有变化，需要再加白新的客户端IP。

P1 - 应用层加固：堵住协议层漏洞

●为scktsrvr配置InterceptGUID鉴权拦截器（若产品支持），或在211前置VPN/反向代理做强制认证。

●管家婆官方已在内部发布修复版本的scktsrvr.exe，请联系厂商获取。

●收紧数据库权限：禁用或严格限制xp_cmdshell、Ole Automation Procedures。

●AppServer不应以sa连库，改用最小权限账号——即使被未授权调用，也执行不了OS命令。