微软内部账户滥用检测：Direct Send 攻击原理与企业防护实践

攻击面概述

Microsoft 365 的 Direct Send 功能本为简化内部通信而设计，允许打印机、扫描仪及第三方应用无需认证即可向组织内用户发送邮件。然而，这一便利特性正成为攻击者绕过邮件安全边界的关键通道。攻击者仅需获取目标组织的域名和有效收件人地址，即可通过微软基础设施发送看似来自内部的钓鱼邮件，无需任何账户凭证或身份验证。

Mimecast 威胁研究团队持续监测到利用此技术的恶意邮件活动。与传统邮件欺骗不同，Direct Send 滥用的邮件确实流经微软可信基础设施，在收件箱中显示为内部路由消息，天然获得用户的信任优势。

Direct Send 技术机制与滥用原理

Direct Send 的核心设计允许设备通过特定 SMTP 端点直接向 Exchange Online 用户邮箱投递邮件。其工作流程包含三个关键环节：

1. 目标侦察 攻击者通过公开信息或前期侦察获取目标组织的域名结构及有效邮箱地址列表。Proofpoint 2024 年的研究发现，攻击者常使用随机命名的 M365 租户（如 23gdfs56gsd.onmicrosoft.com）作为发送源。

2. 邮件构造与投递 攻击者连接 Microsoft 365 的 SMTP 端点，构造模仿内部发件人（如 IT 部门、人力资源）的邮件内容。由于 Direct Send 不验证发件人身份，攻击者可冒充任意内部用户。

3. 基础设施信任传递 邮件通过微软数据中心路由，在邮件头中显示为内部流转。当企业配置了出站邮件中继时，Proofpoint 观察到攻击者甚至能让邮件获得 DKIM 签名，进一步提升可信度。

攻击者通常租赁 VPS 并轮换 IP 地址，在短时间内批量发送数千封邮件，利用自动化工具生成 PDF 和 DOCX 附件，配合钓鱼链接或二维码实施凭证窃取。

传统防护失效的原因

Direct Send 攻击对传统邮件安全体系构成独特挑战：

SPF/DKIM/DMARC 的局限性 由于邮件确实源自微软基础设施，SPF 检查通常通过。在某些配置下，邮件中继过程甚至会为攻击邮件附加合法的 DKIM 签名。DMARC 策略对此类邮件的拦截效果有限，因为邮件通过了基础认证检查。

边界安全设备的盲区 传统邮件网关部署在组织边界，针对外部入站流量进行过滤。Direct Send 邮件通过微软内部基础设施直接投递至用户邮箱，绕过企业控制的邮件安全层。

用户心理盲区 内部邮件标签显著降低用户警惕性。Mimecast 分析显示，伪装成 "员工手册更新"" 薪酬调整通知 " 等主题的钓鱼邮件点击率远高于外部来源邮件。

企业级防护配置

Exchange 管理中心设置

在 Exchange Admin Center 中启用 Reject Direct Send 设置是首要防护措施：

# 检查当前 Direct Send 配置
Get-ReceiveConnector | Where-Object {$_.Name -like "*Direct Send*"} | Select-Object Name, Enabled

# 禁用 Direct Send（如业务允许）
Set-ReceiveConnector -Identity "Direct Send Connector" -Enabled $false

若业务依赖 Direct Send（如遗留打印机、扫描仪），应实施以下替代方案：

1. 迁移至 SMTP 中继：配置经过认证的 SMTP 中继，要求设备使用服务主体名称（SPN）或应用密码
2. IP 白名单限制：在连接器配置中限定允许使用 Direct Send 的源 IP 范围
3. 租户级过滤：如 Proofpoint 实施的方案，明确指定允许中继的 M365 租户，默认拒绝其他租户

DNS 记录强化

即使 Direct Send 邮件可能通过 SPF 检查，严格的 DMARC 策略仍能提供一定防护：

# 建议的 DMARC 记录配置
_dmarc.example.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100; adkim=s; aspf=s"

关键参数说明：

• p=reject：对未通过认证的邮件执行拒绝策略
• aspf=s：启用严格 SPF 对齐检查
• adkim=s：启用严格 DKIM 对齐检查

邮件流规则配置

在 Exchange Online 中创建传输规则检测异常 Direct Send 流量：

New-TransportRule -Name "Detect Suspicious Direct Send" `
    -FromScope NotInOrganization `
    -SentToScope InOrganization `
    -HeaderContainsMessageHeader "Received" `
    -HeaderContainsWords "direct-send", "protection.outlook.com" `
    -SetSCL 9 `
    -Quarantine $true

异常行为检测与监控

关键监控指标

建立针对 Direct Send 滥用的专项监控：

日志分析查询示例

在 Microsoft Defender for Office 365 或 SIEM 平台中实施以下检测规则：

// 检测可疑 Direct Send 活动
EmailEvents
| where DeliveryLocation == "Inbox" 
| where EmailDirection == "Intra-org"
| where SenderFromAddress contains "@" and SenderFromAddress !contains "@example.com"
| where InternetMessageId contains "protection.outlook.com"
| summarize Count = count() by SenderFromAddress, SenderIPv4, bin(TimeGenerated, 1h)
| where Count > 50

用户报告与响应流程

建立快速响应机制：

1. 钓鱼报告按钮：部署 Outlook 插件，允许用户一键标记可疑内部邮件
2. 自动隔离：对报告邮件执行自动隔离并提取附件哈希
3. 租户黑名单：将确认的恶意 .onmicrosoft.com 租户加入阻止列表
4. 事件关联：关联同一攻击活动的多封邮件，识别受影响用户范围

遗留系统迁移策略

禁用 Direct Send 前需完成依赖系统审计：

审计清单

• 网络打印机 / 多功能设备的扫描到邮件功能
• 遗留业务应用的邮件通知模块
• 监控系统的告警邮件发送配置
• 内部服务台的自动回复机制

迁移路径

1. 短期：为必须保留 Direct Send 的设备配置独立连接器，限制源 IP 和发送频率
2. 中期：升级设备固件支持现代认证（OAuth 2.0 / 应用密码）
3. 长期：迁移至 Microsoft Graph API 或经过认证的 SMTP 提交

总结与建议

Direct Send 滥用代表了云原生邮件基础设施的新型攻击面。防护的核心在于理解 "内部" 标签不再等同于 "可信"。企业应采取分层防御策略：

立即行动：评估 Direct Send 业务必要性，如非必需则立即禁用；如必需则严格限制源 IP 和发送范围。

中期加固：实施严格的 DMARC 策略，配置传输规则标记可疑内部邮件，建立 Direct Send 流量基线监控。

长期演进：推动遗留系统向现代认证迁移，将邮件安全检测能力延伸至云原生层，建立针对内部账户滥用的专项响应预案。

攻击者持续寻找信任边界中的缝隙。Direct Send 滥用提醒我们：在云时代，基础设施的便利性往往伴随着安全权衡，持续的配置审计与行为监控是维护邮件安全的关键。

资料来源

• Proofpoint: Microsoft 365 Abuse Leads to onmicrosoft.com Spam
• Mimecast: Microsoft 365 Direct Send Abuse

security