Ghost-Sender：超50% Exchange Online配置存在邮件伪造漏洞微软称不是产品问题

导语：伪造一封来自微软官方的账单邮件，或者冒充CEO给财务发指令——你需要什么？只需要一个Exchange Online租户域名，一台能联网的电脑，然后把这个域名填进发件人字段。这就是Ghost-Sender（幽灵发件人），一个让全球数万企业邮箱门户洞开的系统性配置缺陷。超过50%的相关环境没有做任何缓解配置，而且已经有证据表明攻击者正在利用它。

---

一、漏洞概述

Ghost-Sender是安全研究机构InfoGuard Labs（信息卫队实验室）发现的一种针对微软Exchange Online的大规模系统性配置缺陷。其核心问题是：当企业使用第三方邮件安全网关（如Cloudflare、Barracuda、Mailgun等）作为MX记录指向的邮件过滤层时，Exchange Online默认会信任直接投递到其公开SMTP终结点的邮件——即使这些邮件完全绕过了MX记录指向的第三方网关，SPF/DKIM/DMARC验证也被直接绕过。

这意味着，攻击者无需劫持任何邮件服务器，只需直接向.mail.protection.outlook.com这个公开可访问的终结点发送伪造邮件，就能把任意发件人地址（包括内部域名）的邮件直接塞进目标用户的收件箱。

关键数据：

• 使用第三方网关+Exchange Online组合的企业中：超过50%未做任何缓解配置
• 在各大漏洞赏金项目中：约20%的目标域名对该攻击手法免疫失效
• 微软支持团队证实：2026年4月21日前后已存在大规模邮件伪造活动

---

二、正常邮件链路 vs Ghost-Sender攻击链路

正常邮件投递链路（已部署第三方网关）

攻击者 → MX记录指向第三方网关 → 第三方网关（过滤） → Exchange Online → 用户收件箱

当企业配置了第三方邮件安全网关（如Cloudflare Email Security、Barracuda、Mailgun）时，所有外部邮件按规定都应先经过网关过滤，再投递到Exchange Online。SPF/DKIM/DMARC验证在网关层完成。

Ghost-Sender攻击链路

攻击者 → 直接投递 Exchange Online 公开终结点（绕过MX网关） → 用户收件箱

致命之处在于：Exchange Online为每个租户都暴露了一个公开可访问的SMTP终结点（.mail.protection.outlook.com），攻击者可以直接向这个终结点发送邮件，MX记录指向的网关完全被绕过。

攻击效果实况（来自InfoGuard Labs在真实租户上的测试）：

Authentication-Results: spf=fail (sender IP is redacted)
  smtp.mailfrom=microsoft.com; dkim=none (message not signed)
  header.d=none; dmarc=fail action=oreject
  header.from=microsoft.com; compauth=none reason=451
Received-SPF: Fail (protection.outlook.com: domain of microsoft.com
  does not designate redacted as permitted sender)

SPF失败、DKIM未签名、DMARC验证失败——按规则这封邮件应该被拒绝或隔离。然而，它直接进入了用户收件箱，没有任何警告。

更讽刺的是：如果攻击者伪造内部员工邮箱，Outlook甚至会解析出该员工的企业头像，让邮件看起来完全可信。

---

三、为什么传统邮件安全防线全部失效

SPF（发件人策略框架）

SPF验证发送服务器IP是否在域名DNS记录授权列表内。Ghost-Sender攻击绕过了所有第三方网关，直接到达Exchange Online终结点——发件服务器IP根本不在SPF授权列表内，SPF理应失败。但Exchange Online对直接投递的邮件根本不执行这个检查。

DKIM（域名密钥识别邮件）

DKIM要求发送方在邮件头添加加密签名。攻击者没有目标的私钥，无法生成有效签名。但同样，直接投递的邮件被Exchange Online直接放行，DKIM验证被绕过。

DMARC（基于域名的消息认证报告一致性的协议）

DMARC是SPF和DKIM的政策执行层。microsoft.com配置了完整的DMARC策略（p=reject），理论上任何未通过验证的邮件都应被拒绝。但Ghost-Sender邮件直接进入收件箱，DMARC检查”被跳过”。

根本原因：Exchange Online的设计逻辑是”MX记录指向我的邮件我默认信任”，但当MX记录实际指向第三方网关时，这个默认信任就变成了安全漏洞。微软文档中确实存在相关的安全配置说明，但散落在不同页面，没有统一警告，实际部署中管理员极易遗漏。

---

四、谁在裸泳：影响范围测绘

InfoGuard Labs对使用第三方邮件网关+Exchange Online组合的企业环境进行了扫描测绘：

环境类型	存在Ghost-Sender漏洞的比例
所有使用外部MX+Exchange Online的企业	>50%
Bug Bounty平台目标域名	约20%
配置了Partner Organization连接器且有效的	约25%

即便是启用了微软”标准保护”和”严格保护”预设安全策略的租户，Ghost-Sender攻击同样有效——所有预设策略都无法阻止直接投递的伪造邮件。

InfoGuard Labs还测试了以下常见”自以为安全”的配置，它们全部无效：

• ❌ “Your organization’s email server”连接器（IP/证书认证）
• ❌ 启用Enhanced Filtering for Connectors
• ❌ 预设安全策略（Standard/Strict Protection）
• ❌ 自定义反钓鱼/反垃圾邮件策略（Honor DMARC）
• ❌ MX记录指向Exchange Online但使用了Direct Send功能

---

五、微软定性：不是产品漏洞，是配置问题

InfoGuard Labs于2026年4月21日向微软安全响应中心（MSRC）报告了该问题。

MSRC的回应是：这不是安全漏洞（Not a Vulnerability），属于”非MSRC案例”（Non-MSRC Case），建议作为普通技术支持问题报告。

微软一般支持团队的回复更为明确（2026年5月29日）：

“这不属于产品漏洞，而是已知的架构限制。建议：将MX记录改为直接指向M365，或在转发的邮件中添加额外头部信息。”

也就是说，微软不会为此发布CVE补丁，需要管理员手动在Exchange Online中配置缓解规则。

有意思的是：2026年4月22日，当InfoGuard Labs向微软一般支持团队反馈时，客服透露了一个惊人信息——一个大规模邮件伪造活动已于4月21日开始活跃，微软随即在4月22日修复了内部发件人伪造问题，但外部发件人伪造仍然有效。直到4月27日，微软认为问题已解决，但InfoGuard Labs验证Ghost-Sender仍然可用。

---

六、红队视角：如何利用Ghost-Sender

对于红队成员，Ghost-Sender是一个低成本高回报的社工利器。

利用前提：

• 目标域名（任何使用了外部MX+Exchange Online的组织）
• 猜测目标的<domain>.mail.protection.outlook.com终结点（通常可通过DNS反查）
• 一个SMTP客户端（一行PowerShell命令即可）

一行命令实现伪造：

Send-MailMessage -SmtpServer <target>-com.mail.protection.outlook.com `
  -To <victim@target.com> `
  -From <spoofed@anydomain.com> `
  -Subject "Urgent: Invoice Payment Required" `
  -BodyAsHTML "<h1>Payment Required</h1>..." `
  -Credential (Get-Credential)

高价值攻击场景：

• 钓鱼攻击：冒充IT部门发送密码重置邮件
• BEC（商业电子邮件欺诈）：冒充CEO/CFO向财务下达转账指令
• 供应链攻击：冒充合作伙伴发送带毒附件
• 凭据收割：伪造微软/谷歌等平台登录提醒

关键优势：邮件直接进入收件箱，无任何警告标签，用户天然信任。

---

七、修复方案：两种有效缓解措施

微软官方推荐两种缓解方案，管理员需二选一实施：

方案一：Partner Organization连接器（推荐）

创建”合作伙伴组织”类型连接器，限制只有特定IP或证书的邮件才能投递：

1. 在Exchange Admin Center创建”合作伙伴组织”类型连接器
2. 配置域名为通配符*（匹配所有发件域）
3. 设置IP或证书限制，拒绝非授权来源的直接投递
4. 确保配置不会阻断来自内部邮件服务器的合法转发邮件

正确配置后，Exchange Online会返回：

5.7.51 TenantInboundAttribution; Rejecting.

方案二：传输规则（邮件流程规则）

创建高优先级（0）规则，隔离所有非内部认证来源的邮件：

• 适用条件：X-MS-Exchange-Organization-AuthAs头部不包含Internal，且发件IP不在授权范围内
• 执行动作：将邮件投送至托管隔离区，停止处理后续规则
• 注意：此方案无法被ghost-sender.com工具直接检测，需手动发送测试邮件验证

额外建议：禁用Direct Send功能，防止攻击者利用Direct Send路径进行内部发件人伪造。

---

八、在线检测工具

Ghost-Sender检测工具（InfoGuard Labs官方发布）： 👉 https://ghost-sender.com/

使用方法：

1. 访问ghost-sender.com/tester
2. 输入待检测的域名列表（每行一个）
3. 工具自动完成：MX记录解析 → Exchange Online终结点识别 → SMTP探测
4. 查看每个域名的漏洞判定结果

工具会依次执行：

• MX记录解析，判断是否使用了外部网关
• 识别Exchange Online租户入口主机名
• 发起SMTP探测（EHLO/MAIL FROM/RCPT TO）
• 若服务器接受RCPT TO命令，说明该域名存在Ghost-Sender漏洞

温馨提醒：InfoGuard Labs同时提供了直接发送测试伪造邮件的功能，管理员可用此验证缓解措施是否生效。

---

九、检测挑战与溯源难点

传统意义上，Ghost-Sender没有明确的网络层IoC（妥协指标）。InfoGuard Labs评估了Exchange Admin Center和Defender for Office 365中所有可用的日志字段，无法找到在所有租户配置下都能明确标识Ghost-Sender伪造邮件的可靠来源。

唯一可行的检测方式：检查所有入站邮件头部，对比邮件流向是否符合MX记录配置的网关路径。若攻击者要伪造这个信息，需要知道组织邮件路径上所有内部设备的特定IP和主机名——这本身就构成了较高的情报门槛。

---

十、总结

Ghost-Sender的本质是一道”门”——微软在架构设计上给Exchange Online留了一扇不需要认证就能投递邮件的侧门，而当企业用第三方网关封住正门时，这扇侧门仍然敞开着。

超过一半的相关企业在这扇侧门前没有任何路障，而且攻击者已经在用了。

对于防御者而言，当务之急是：

1. 登录 https://ghost-sender.com/ 检测自己是否在裸泳
2. 立即部署Partner Organization连接器或传输规则
3. 考虑将MX记录直接指向Exchange Online Protection
4. 假设这个攻击手法已经在被使用，保持警惕

对于红队而言，这是一把社工钓鱼的趁手武器——发件人想填什么就填什么，邮件直接进收件箱，用户还以为是同事发的。

版权声明：本文由华盟网原创发布，保留所有权利。配图由华盟网授权使用。