微软把漏洞风险评为"中等"，卡巴斯基却说这是架构级灾难。同一批技术细节，两家巨头得出完全相反的结论——到底谁对？
2026年4月24日，Black Hat Asia。卡巴斯基应用安全专家Haidar Kabibo扔出一枚炸弹：PhantomRPC，一个藏在Windows远程过程调用（RPC）里的设计缺陷，能让攻击者从低权限账户直接跳到系统最高权限。更麻烦的是，它影响"every version of Windows"——从服务器到桌面，全线中招。
这不是普通的内存溢出或代码逻辑错误。PhantomRPC玩的是架构层面的"李代桃僵"：当高权限进程向一个离线的RPC服务器发起调用时，Windows的运行时库（rpcrt4.dll）根本不验证回应者是不是正主。
攻击路径：五把钥匙开同一扇门
Kabibo团队挖出了五种具体的利用方式。核心机制高度一致：攻击者先以一个低权限服务账户（比如NT AUTHORITY\NETWORK SERVICE）运行恶意程序，注册一个伪装的RPC服务器端点。当系统进程——往往带着SYSTEM或管理员权限——试图连接那个本应在线、实则离线的合法服务时，恶意服务器截获请求。
关键一步在RpcImpersonateClient（客户端模拟接口）。恶意服务器调用这个API，直接把高权限客户端的安全上下文"穿"到自己身上。权限跃迁完成：从NETWORK SERVICE到SYSTEM，中间没有任何密码破解、没有漏洞利用链，只有Windows自己埋下的信任漏洞。
五种场景的区别在于被冒充的服务对象不同，但底层机制完全一致。卡巴斯基把这形容为"不是单个组件的bug，是整个RPC连接模型的设计盲区"。
正方：微软为什么说是"中等风险"
2025年9月19日，卡巴斯基向微软安全响应中心（MSRC）提交报告。20天后，微软回复：风险等级，中等。
核心理由只有一个：攻击需要SeImpersonatePrivilege（客户端模拟特权）。而这个权限，NETWORK SERVICE和Local Service账户默认就有。微软的潜台词是——攻击者先得攻破一个服务账户，才能启动后续操作。
这个判断有它的技术逻辑。在微软的风险模型里，"需要先获取一定权限"的漏洞通常降级处理。没有CVE编号，没有排期修复，案子直接关了。
微软的沉默本身也是一种立场：现有安全边界未被突破，问题属于"权限滥用"而非"权限突破"。
反方：卡巴斯基为什么说这是架构灾难
卡巴斯基的反驳直指微软评估的前提假设。
首先，"默认持有"不等于"难以获取"。IIS、SQL Server、Exchange——大量Windows服务以NETWORK SERVICE身份运行。一个Web漏洞、一个配置失误，攻击者就能拿到这把钥匙。微软的评估把"获取初始权限"当成了高难度动作，但现实攻击链里这往往是起点而非终点。
其次，PhantomRPC的杀伤力在于"提权确定性"。传统内核漏洞需要对抗ASLR、DEP、CFG，成功率看运气；PhantomRPC是设计层面的协议欺骗，一旦初始权限到手，提权路径100%可复现。Kabibo在演讲里强调：这不是利用代码的稳定性，是架构缺陷的必然性。
第三，影响面被严重低估。"Every version of Windows"意味着企业过去二十年部署的域控、文件服务器、终端管理节点全部在射程内。微软的"中等"评级没有区分场景——一台边缘Web服务器和一台域控器被攻破，后果完全不同。
卡巴斯基选择公开全部工具：GitHub上的PhantomRPC仓库开放了研究框架，让企业能自查哪些RPC调用模式存在被冒充风险。这个动作本身是对微软"无需修复"立场的公开反驳。
我的判断：微软在赌，但赌的是用户的运气
双方的技术事实没有分歧，分歧在于"风险"的定义权。
微软把PhantomRPC框定在"权限提升"的子类别里，用既有评估模板套出了一个中等评级。这个做法在流程上合规，但在威胁语境里失真——它忽略了现代攻击链的常态：初始立足点越来越廉价，横向移动和权限提升才是决定危害规模的关键。
卡巴斯基的激进披露策略也有代价。工具开源意味着防御方可以自查，也意味着攻击者拿到了武器化蓝图。但在微软拒绝修复的前提下，这是打破僵局唯一有效的手段。
真正的问题在于修复的结构性困难。RPC运行时（rpcrt4.dll）是Windows的神经系统，数十年的向后兼容承诺让它成为修改禁区。加一个服务器身份验证步骤？可能打断无数 legacy 系统的正常通信。微软的"不修复"背后，是技术债务的复利压力。
对企业来说，微软的评级是误导性的安慰剂。NETWORK SERVICE不是"高价值目标"，而是"高可达目标"——攻击路径成熟，自动化工具泛滥。PhantomRPC把这条路径的终点从"服务账户权限"直接延伸到"完全系统控制"，中间没有额外的检测点。
卡巴斯基给出的缓解方案值得立即执行：限制服务账户的SeImpersonatePrivilege、监控异常的RPC端点注册、审计高权限进程对外部服务的调用模式。这些动作不依赖微软补丁，但需要安全团队把RPC流量纳入可见性范围——而多数企业还没做到这一点。
这件事的深层信号是：操作系统级别的安全模型正在遭遇架构性疲劳。RPC的设计假设诞生于信任边界清晰的年代，而现代攻击者的核心能力就是制造信任混淆。PhantomRPC不是最后一个这类漏洞，它是模板——更多"设计即缺陷"的案例正在排队。
如果你负责Windows环境的防御，现在该做的不是等微软改主意，而是用卡巴斯基的开源工具跑一遍自查。评级是微软的，风险是你的。
热门跟贴