基于Direct Send机制的Microsoft 365内部钓鱼攻击分析与防御策略

摘要

近年来，随着企业对云办公平台依赖程度的加深，攻击者不断探索利用合法云服务功能实施高级社会工程攻击的新路径。2025年，安全研究机构披露了一类针对Microsoft 365平台中Direct Send功能的新型内部钓鱼攻击。该攻击通过滥用本用于打印机或旧式应用邮件投递的Direct Send机制，在无需有效身份凭证的前提下，向目标组织内部用户投递高度仿真的钓鱼邮件，从而绕过传统邮件网关和多因素认证等安全控制措施。本文系统分析了Direct Send的技术原理、攻击链构造方式、基础设施部署特征及检测难点，并结合真实攻击样本提出多层次防御框架。通过PowerShell策略配置、邮件头日志分析、SMTP流量监控及SIEM集成等手段，构建可落地的缓解方案。实验验证表明，关闭非必要Direct Send入口并辅以复合认证失败（compauth=fail）日志告警，可显著降低此类攻击的成功率。本研究为云邮件平台的安全治理提供了技术参考与实践路径。

关键词：Microsoft 365；Direct Send；内部钓鱼；邮件伪造；云安全；SMTP中继

1 引言

Microsoft 365作为全球广泛采用的企业级协作平台，其邮件服务Exchange Online承载着海量敏感通信。为支持特定场景（如多功能打印机、遗留系统）的自动化邮件发送需求，微软设计了Direct Send功能——一种允许经授权IP地址直接向组织内部收件人投递邮件而无需通过标准SMTP认证的机制。该功能在提升兼容性的同时，也引入了信任边界模糊的风险。

2025年8月，Proofpoint等安全厂商披露了首起大规模利用Direct Send实施内部钓鱼攻击的事件。攻击者通过控制第三方邮件安全设备，伪装成合法内部发件人，向目标租户投递包含恶意链接或附件的邮件。由于邮件未经过外部网关扫描，且发件地址属于组织域名，传统反钓鱼规则难以识别，导致攻击成功率显著提升。

此类攻击凸显了“合法功能被武器化”的新型威胁范式：攻击者不再依赖漏洞利用或凭证窃取，而是利用平台设计中的信任假设，将合规接口转化为攻击通道。现有研究多聚焦于外部钓鱼或凭证填充攻击，对基于云原生功能滥用的内部欺骗行为缺乏系统性分析。本文旨在填补这一空白，从技术机理、攻击流程、检测盲区到防御策略进行闭环论述，为安全运维人员提供可操作的应对指南。

2 Direct Send机制技术原理

2.1 功能定义与设计初衷

Direct Send是Exchange Online Protection（EOP）提供的邮件投递选项之一，适用于无法支持现代认证协议（如OAuth 2.0）的设备或应用。其核心逻辑是：若发送方IP地址被列入组织的“受信任IP列表”（通常通过连接器Connector配置），则允许其直接向组织内部邮箱发送邮件，无需提供用户名/密码或访问令牌。

根据微软官方文档，启用Direct Send需满足以下条件：

发送方必须使用组织拥有的域名作为发件人地址；

发送方IP必须通过Inbound Connector显式授权；

邮件仅限投递至组织内部收件人（即不能外发）；

不支持邮件队列、重试或状态报告。

该机制本质上是一种基于IP白名单的轻量级邮件注入接口，设计目标是简化旧设备集成，而非面向通用邮件客户端。

2.2 协议交互流程

Direct Send基于标准SMTP协议实现，典型交互如下：

Client (Attacker IP) → Microsoft 365 SMTP Endpoint (e.g., *.mail.protection.outlook.com)

HELO trusted-device.corp.com

MAIL FROM:<ceo@targetcorp.com>

RCPT TO:<employee@targetcorp.com>

DATA

From: CEO <ceo@targetcorp.com>

To: Employee <employee@targetcorp.com>

Subject: Urgent: Q4 Budget Approval Required

Hi Team,

Please review the attached budget file immediately.

[Malicious Link]

QUIT

关键点在于：只要攻击者IP被误配为受信任IP（或利用第三方设备间接中继），且发件域与目标租户一致，邮件即可被接受并投递，系统不会验证MAIL FROM地址的真实性。

2.3 与标准邮件流的区别

特性 标准SMTP Auth Direct Send

身份认证 必需（OAuth/Basic） 无

IP白名单依赖 否 是

外部发件支持 是 否（仅限内部收件人）

邮件头完整性检查 强（含DKIM/DMARC） 弱（无SPF/DKIM签名）

安全网关扫描 通常经过 可能绕过

由此可见，Direct Send牺牲了部分安全属性以换取兼容性，这为攻击者提供了可乘之机。

3 攻击链构造与基础设施分析

3.1 攻击四阶段模型

根据Proofpoint披露的攻击样本，完整攻击链可分为以下四个阶段：

阶段一：初始立足点获取

攻击者通过RDP暴力破解或漏洞利用，控制运行Windows Server 2022的虚拟主机（VPS）。该主机作为攻击跳板，具备合法Windows环境，便于后续工具部署。

阶段二：中继设备劫持

攻击者扫描互联网上配置不当的第三方邮件安全设备（如Barracuda、Mimecast代理），这些设备通常由区域IaaS提供商托管。设备暴露管理端口（8008、8010、8015），且使用自签名或过期证书，存在弱口令或未修补漏洞。一旦攻陷，设备即成为SMTP中继节点。

阶段三：邮件注入与伪造

攻击者从VPS发起SMTP连接至被控中继设备，构造伪造邮件：

MAIL FROM：使用目标组织高管邮箱（如ceo@targetcorp.com）

RCPT TO：指定内部员工邮箱

正文内容模仿紧急事务（如财务审批、IT通知）

中继设备因配置为“允许内部转发”，将邮件原样转发至Microsoft 365的Direct Send入口。

阶段四：投递与执行

Microsoft 365接收邮件后，因来源IP属于受信任连接器（实际为被滥用的中继IP），且收件人为内部用户，故直接投递。邮件头中缺失SPF/DKIM验证记录，但因属“内部邮件”，多数终端用户不会质疑其真实性。

3.2 基础设施特征

攻击基础设施呈现以下特征：

IP分布：中继IP多位于东欧、东南亚等地，规避主流威胁情报覆盖；

证书信息：中继设备使用DigiCert等正规CA签发的SSL证书，增强可信度；

协议支持：支持STARTTLS与AUTH PLAIN LOGIN，模拟合法邮件服务器行为；

日志痕迹：邮件头中可见Received-SPF: None及compauth=fail字段，后者为关键检测指标。

4 检测难点与现有防御盲区

4.1 传统安全控制失效原因

邮件网关绕过：Direct Send邮件不经过外部邮件网关（如Mimecast、Proofpoint Cloud），导致沙箱、URL重写、附件隔离等措施无效。

发件人信誉误判：因发件域与收件域相同，反钓鱼引擎常将其归类为“内部可信通信”，降低风险评分。

无认证痕迹：攻击过程不涉及账户登录，因此Azure AD登录日志、条件访问策略无法触发告警。

日志分散：攻击线索分散于网络层（VPS RDP）、应用层（中继设备日志）、邮件层（Exchange Online日志），难以关联。

4.2 用户感知局限

终端用户面对一封来自“CEO”的内部邮件，通常不会检查邮件头或SPF结果。即使邮件客户端显示“未加密”或“发件人未验证”，在高压工作环境下仍可能点击链接。社会工程心理学在此类攻击中起到决定性作用。

5 防御策略与技术实现

5.1 策略层面：禁用非必要Direct Send

微软官方建议，若组织无打印机或旧系统依赖，应全局禁用Direct Send。可通过Exchange Online PowerShell执行：

# 连接Exchange Online

Connect-ExchangeOnline -UserPrincipalName admin@targetcorp.com

# 禁用Direct Send

Set-OrganizationConfig -RejectDirectSend $true

# 验证配置

Get-OrganizationConfig | Select RejectDirectSend

执行后，所有未通过标准认证的邮件投递请求将被拒绝，从根本上消除攻击面。

注意：若确需保留Direct Send（如支持多功能打印机），应严格限制Inbound Connector的IP范围，并定期审计。

5.2 检测层面：邮件头日志分析

即使未禁用Direct Send，也可通过监控邮件头中的compauth字段识别异常。正常内部邮件应通过复合认证（Composite Authentication），而Direct Send伪造邮件会标记为失败：

Authentication-Results: spf=none (sender IP is 203.x.x.x)

smtp.mailfrom=ceo@targetcorp.com; compauth=fail reason=000

可通过Microsoft Purview合规门户创建日志查询：

// KQL查询：检测compauth=fail的内部邮件

EmailEvents

| where ActionType == "Delivered"

| where SenderFromAddress endswith "@targetcorp.com"

| where RecipientEmailAddress endswith "@targetcorp.com"

| where EmailHeaders has "compauth=fail"

| project Timestamp, SenderFromAddress, RecipientEmailAddress, Subject, NetworkMessageId

该查询可集成至Microsoft Sentinel，触发实时告警。

5.3 网络层面：SMTP流量监控

在企业边界防火墙或代理设备上，可设置规则监控异常SMTP连接：

目标端口为25、587、2525；

源IP不属于已知邮件服务器；

连接频率突增。

示例Suricata规则：

alert tcp any any -> $OFFICE365_SMTP_NETS [25,587,2525] \

(msg:"Potential Direct Send Abuse - Unusual SMTP to M365"; \

flow:to_server,established; \

content:"MAIL FROM:<"; depth:20; \

pcre:"/^MAIL FROM:<[^@]+@targetcorp\.com>/Hi"; \

threshold:type both, track by_src, count 5, seconds 60; \

sid:1000001; rev:1;)

5.4 架构层面：最小权限原则

细化连接器权限：每个Inbound Connector仅授权单一设备IP，避免CIDR宽泛授权；

启用邮件流规则（Transport Rule）：对来自Direct Send通道的邮件强制添加警告横幅；

部署DMARC策略：即使内部邮件不验证SPF，也可通过p=quarantine策略捕获异常外发尝试。

示例Transport Rule（PowerShell）：

New-TransportRule -Name "Warn DirectSend Emails" \

-HeaderMatchesMessageHeader "Authentication-Results" \

-HeaderMatchesPatterns "compauth=fail" \

-ApplyHtmlDisclaimerLocation Prepend \

-ApplyHtmlDisclaimerText "<div style='background-color:#ffe6e6;padding:10px;border:1px solid red;'>WARNING: This email bypassed standard authentication. Verify sender before clicking links.</div>"

6 实验验证与效果评估

为验证防御措施有效性，我们在测试租户中复现攻击场景：

环境：Microsoft 365 E5租户，启用Audit Log与Purview；

攻击模拟：使用Python smtplib从非受信IP发送伪造内部邮件；

对照组A：默认配置（Direct Send启用）；

实验组B：执行Set-OrganizationConfig -RejectDirectSend $true；

实验组C：保留Direct Send但部署compauth告警规则。

结果：

对照组A：邮件成功投递，无告警；

实验组B：邮件被拒绝，返回550 5.7.1错误；

实验组C：邮件投递但触发Sentinel告警，响应时间<2分钟。

数据表明，策略禁用是最彻底的解决方案，而日志监控可作为过渡期补充手段。

7 讨论：云服务功能安全治理启示

Direct Send滥用事件揭示了云安全的一个深层矛盾：便利性与安全性之间的权衡。平台提供商为兼容历史系统而保留的“后门式”功能，往往成为攻击者的首选入口。企业安全团队需建立“功能审计”机制：

定期审查连接器配置：确保无冗余或过度授权的Inbound/Outbound Connector；

实施零信任邮件架构：默认拒绝所有未经强认证的邮件注入；

推动设备现代化：淘汰依赖Direct Send的旧设备，迁移至支持OAuth的应用；

加强跨层日志关联：将网络、身份、邮件日志统一分析，打破数据孤岛。

此外，微软亦应考虑改进Direct Send设计，例如强制要求SPF记录匹配或引入一次性令牌机制，而非完全依赖IP信任。

8 结语

本文系统剖析了基于Microsoft 365 Direct Send功能的内部钓鱼攻击，从技术机理、攻击链、检测盲区到防御策略形成完整闭环。研究表明，此类攻击的成功并非源于技术漏洞，而是对平台信任模型的巧妙滥用。防御的关键在于重新审视“内部即安全”的假设，通过策略收紧、日志监控与架构优化，将合法功能的滥用风险降至最低。随着云服务功能日益复杂，安全治理必须从“外围防御”转向“内生安全”，确保每一项便利功能都在可控边界内运行。未来工作可探索基于机器学习的邮件行为基线建模，进一步提升对异常内部通信的识别能力。

编辑：芦笛（公共互联网反网络钓鱼工作组）