Solar应急响应团队：一次管家婆漏洞事件，揭开 AI 自动化漏洞审计与勒索攻击的新趋势

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

           更诡异的是，所有日志干干净净，没有任何入侵痕迹。

           仿佛黑客是“隔空取物”。

           这不是电影情节。过去几个月，Solar安全应急响应团队连续处置了多起这样的“幽灵入侵”事件。受害者有一个惊人的共同点：他们都装了管家婆。

           一、一个被所有人忽视的端口

           管家婆系列软件（辉煌Ⅱ、TOP+、ERP等）是国内中小企业最常用的进销存管理工具之一。装机量巨大，几乎覆盖了制造业、零售业、批发业的半壁江山。

           我们在多起案例中发现：受害企业的服务器上，都有一个211端口默默对外开放。

           这个端口不是网站，不是数据库，而是管家婆客户端连接服务端的“数据中转站”——一个基于Delphi MIDAS协议的Socket通信服务。

           绝大多数运维人员根本不知道它的存在，更不会想到要封它。

           但黑客知道。

           二、无需密码，无需客户端，直达最高权限

           211端口上的服务没有任何认证机制。任何人只要能TCP连上这个端口，就能直接调用服务端的核心方法——包括执行任意SQL语句。

           更具体地说：

           ·不需要用户名密码（连接阶段没有鉴权）

           ·不需要管家婆客户端（用一段Python脚本即可）

           ·不需要知道数据库密码（借用管家婆自己的sa连接）

           ·不需要数据库端口开放（命令从应用内部发出）

           攻击者只需连上211端口，经过简单的握手协议，就能以数据库最高权限（sa）执行系统命令，最终获得Windows SYSTEM权限——这是操作系统的最高权限。

           从连接到完全控制，全程不产生任何登录日志。

           三、为什么传统安全设备全部失灵

           这个漏洞之所以“完美”，是因为它精准地避开了所有常规检测手段：

           不是没被攻击，是这条路天生不留脚印。

           四、更可怕的趋势：AI正在帮黑客批量挖洞

           让我们真正担忧的不只是这一个漏洞，而是背后的趋势。

           管家婆系列软件的安装包在互联网上可以公开下载。我们观察到，Weaxor和Tellyouthepass两个勒索家族正在快速横向扩展攻击目标——从管家婆辉煌到物联通，再到ERP，几乎都是以0day（官方未修复的全新漏洞）作为突破口。

           从下载安装包到漏洞被武器化投入实战，这个周期被压缩到了令人不安的程度。

           我们不得不做出一个严肃判断：勒索组织可能已经在用AI进行自动化漏洞审计。

           这意味着，过去需要高水平黑客花数周完成的漏洞挖掘，现在可能只需要几天甚至几小时。“下载软件→AI审计→发现漏洞→武器化→批量投放”的闭环正在形成。

           五、这不只是管家婆的问题

           在研究过程中，我们对同网段做了211端口扫描，一次就发现4台不同的应用服务器暴露了同样的MIDAS服务。它们来自不同的厂商、不同的产品线，但底层都用了同一套Delphi Socket Server架构。

           结论：任何使用“Delphi MIDAS + scktsrvr + 无认证”架构的应用，都可能存在同类漏洞。管家婆只是冰山一角——它暴露量最大，所以最先被盯上。

           攻击者手里已经有了一本“CLSID字典”，能精准识别211端口背后是什么应用，然后对号入座地打。

           六、你现在应该做什么

           今天就做：

           ·检查你的服务器是否有211端口对公网开放（netstat -an | findstr 211）

           ·如果有，立即在防火墙/安全组封掉211的公网访问，仅允许内网可信IP

           本周内做：

           ·联系管家婆官方获取修复版本的scktsrvr.exe

           ·禁用SQL Server的xp_cmdshell和Ole Automation Procedures

           ·检查SQL Server服务账户权限，不要用LocalSystem运行

           持续做：

           ·在211端口流量上部署协议级监测

           ·关注SQL Server的sp_configure变更事件

           ·如果已经被加密过一次，恢复前务必彻底清除后门并封堵211——否则攻击者会再来

           七、写在最后

           这篇文章的目的不是制造恐慌，而是填补一个信息差。

           在我们处置的案例中，没有一家企业的运维人员知道211端口意味着什么。他们做了该做的一切——复杂密码、关闭数据库端口、部署防火墙——但还是被“隔空”打穿了。

           安全的敌人不是疏忽，是盲区。

           如果你的公司或者你客户的公司在用管家婆，或者在用任何基于Delphi开发的C/S架构软件，请把这篇文章转给负责IT的同事。5分钟的操作，可能避免一次让公司停摆的勒索事件。

 

本文基于思而听安全 | Solar应急响应团队

实战案例与逆向研究

所有结论经靶场验证，技术细节供安全同行复测参考

关注思而听，获取更多一线安全情报与防御指南