一個沒有開放數據庫端口的內網，一個密碼足夠復雜的數據庫賬號，一臺沒有任何Web漏洞的服務器——卻在一夜之間被勒索病毒加密了全部文件。
更詭異的是，所有日志干干凈凈，沒有任何入侵痕跡。仿佛黑客是“隔空取物”。
這不是電影情節。過去幾個月，Solar應急響應團隊連續處置了多起.weax（Weaxor家族）和.sorry（Tellyouthepass家族）勒索事件。受害者有一個驚人的共同點：他們都部署了“管家婆”系列管理軟件。
經過深度逆向分析與靶場驗證，我們最終把入口鎖定在一個被絕大多數運維忽視的211端口上——一個無需任何口令、無需加密狗、無需客戶端即可觸發的未授權遠程代碼執行（RCE）漏洞。
一、線索匯聚：兩起案例指向同一個入口
案例A：Tellyouthepass家族（加密后綴.sorry）
第一起案例是一家制造業公司被.sorry加密。在其磁盤鏡像里提取到了服務端程序包，解壓后發現關鍵文件ScktSrvr.exe（680960字節）。這臺機器對公網開放的端口里，211端口（TCP）處于監聽狀態且加密發生后仍存活，而1433（SQL Server）并未對公網放行。
案例B：Weaxor家族（加密后綴.weax）
第二起案例的SQL Server默認追蹤日志（log_*.trc）中有一條鐵證級記錄：
攻擊者在加密前一天，用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。
完整的數據流路徑：
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的運行參數讀自注冊表 HKLM\SOFTWARE\WOW6432Node\Borland\Socket Server。Delphi的Socket Server設計上支持一個叫InterceptGUID的“鑒權攔截器”——如果配置了這個GUID，每條連接都會先經過COM攔截器做認證。
經查證：InterceptGUID為空。意味著沒有任何鑒權攔截器被插入連接流程。任何人TCP連上211，都能直接進入MIDAS協議層。這是整個漏洞的根。
3.2 協議主循環：分發器 sub_48B820
握手成功后，連接進入解釋器主循環。地址0x48B820的函數讀取1字節action，按switch分發：
3.3 方法調用入口：Invoke解釋器 sub_48C050
action=2進入方法調用解釋器（0x48C050），它連續讀取6個“變體（Variant）”，然后直接調用AppServer的IDispatch：：Invoke——COM里的通用方法調用接口：
關鍵發現：從“握手成功”到“IDispatch：：Invoke被調用”之間，沒有任何權限校驗——沒有“未登錄返回錯誤”、沒有“權限不足”、沒有黑名單。握手能過，AppServer暴露的任意方法都可被自由調用。
3.4 變體的網絡編碼格式
變體讀取器（0x48A89C）揭示了數據在網絡上的編碼方式：
值得注意的是，變體類型大小表word_491354只有20個有效條目（type 0-19），type≥0x14時會越界讀到指針碎片，這是個真實的內存安全缺陷代碼模式（后文會討論其可利用性）。
四、MITM抓包：拿到協議的“地面真相”
逆向告訴我們“協議的零件長什么樣”，但沒告訴我們“零件怎么組裝成完整數據包”。我們在IDA里推斷的包頭格式反復失敗——服務器總是返回Invalid variant type。
最穩的辦法：搭建中間人（MITM），讓真實的管家婆客戶端從中間過一遍，把真實數據包字節抓下來對照。
抓包方案
客戶端登錄一次，我們抓到了880條消息的完整雙向字節流。第一條客戶端握手包（92字節）揭示了包結構：
關鍵糾錯：動作類型在簽名里，不在載荷里
繼續分析后續消息：
這就是我們之前反復踩坑的原因——數據包的“動作類型”藏在簽名的第一個字節里，而不是載荷內部。差一個字節的位置，卡了很久。抓包一對照，豁然開朗。
還原出的完整方法調用序列
這條序列給了最后兩塊拼圖：方法名→dispid是動態查的（ACT3），所以跨版本通用；真正執行SQL的是OpenSQL + AS_GetRecords這一對組合。
五、構造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命令
會話初始化完成后，攻擊鏈和真實客戶端一致：
AS_GetRecords一旦觸發，GraspSvr就以sa身份將SQL送入SQL Server；xp_cmdshell把命令交給操作系統。在我們靶機上，SQL Server服務以LocalSystem運行，攻擊者獲得的是NT AUTHORITY\SYSTEM權限——Windows用戶態最高權限。
注意：并非所有部署的SQL服務都是LocalSystem，不同安裝方式可能使用更低權限的服務賬戶（如NETWORK SERVICE、NT SERVICE\MSSQLSERVER），此時OS命令權限會相應降低。但“未授權以sa執行任意SQL”這個核心漏洞不受影響。
六、落地驗證與取證
我們在靶場上完成了兩項物證級驗證：
物證一：OS命令執行 + SYSTEM權限確認
經xp_cmdshell在靶機C：\寫下標記文件，經驗證文件所有者為NT AUTHORITY\SYSTEM。攻擊者由此可裝勒索、停服務、清日志，橫向移動到其它主機則通常還需進一步竊取/復用憑據（非一步到位）。
物證二：未授權DDL執行（持久表）
經同一條無憑據鏈路執行DDL：
表持久存在于數據庫中，是“未授權→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分支存在確鑿的棧溢出代碼模式：
但在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。用我們的工具去連，全部返回：
說明它們是別的Delphi MIDAS應用（不同CLSID），管家婆的“鑰匙”開不了它們的鎖。但攻擊者手里有一本“CLSID字典”——逆向多種應用客戶端提取各自AppServer的CLSID，掃描器先用04 da探針確認“這是MIDAS服務”，再逐個試字典中的CLSID，命中后套對應方法集攻擊。
結論：任何“Delphi MIDAS socket應用 + scktsrvr無認證 + AppServer有SQL/命令執行能力”的組合都中招。管家婆只是暴露量最大的一類。
九、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命令。
P2 - 監控補盲：讓“隱身通道”可見
●在211流量上部署協議級監測，識別04 da / 04 db MIDAS握手、異常ACT3/Invoke調用。傳統Web/登錄日志對它無效。
●SQL默認trace/擴展事件重點監控：sp_configure變更、sp_OACreate調用、xp_cmdshell執行。
P3 - 恢復前必做：防止二次打擊
●一旦被加密，恢復前務必清除所有持久化后門：
●- 計劃任務 / Windows服務 / 注冊表Run鍵
●- WMI事件訂閱 / 啟動文件夾
●- System32目錄下的可疑exe
●封堵211端口后再恢復業務。否則恢復即等于重新把靶子立起來——攻擊者可二次、三次再來。
寫在最后
在我們處置的案例中，沒有一家企業的運維人員知道211端口意味著什么。他們做了該做的一切——復雜密碼、關閉數據庫端口、部署防火墻——但還是被“隔空”打穿了。
安全的敵人不是疏忽，是盲區。
如果你的公司或者你客戶的公司在用管家婆，或者在用任何基于Delphi開發的C/S架構軟件，請把這篇文章轉給負責安全和運維的同事。封一個端口，5分鐘的操作，可能避免一次讓公司停擺數周的勒索事件。
— — — — — — — — — — — — — — —
本文基于思而聽安全 | Solar應急響應團隊
多起實戰案例與逆向研究
所有結論經靶場驗證，技術細節供安全同行復測參考，完整PoC不公開發布
關注思而聽，獲取更多一線安全情報與防御指南
轉自：中國財富網
【版權及免責聲明】凡本網所屬版權作品，轉載時須獲得授權并注明來源“中國產業經濟信息網”，違者本網將保留追究其相關法律責任的權力。凡轉載文章及企業宣傳資訊，僅代表作者個人觀點，不代表本網觀點和立場。版權事宜請聯系：010-65363056。
延伸閱讀
