利用1995年手法对Microsoft 365进行邮件伪造攻击的技术分析

| Steve Borosh

我之前曾写过一篇关于利用创建商业365 Exchange Online实例时默认启用的直接发送功能来伪造Microsoft 365的博客（https://www.blackhillsinfosec.com/spoofing-microsoft-365-like-its-1995/）。使用直接发送功能，可能"按设计"从组织内部或外部向租户中的其他用户发送电子邮件。默认的Exchange Online实例会创建一个"智能主机"，地址为"company.mail.protection.outlook.com"。快速执行nslookup company.mail.protection.outlook.com将显示智能主机的IP地址（如果存在）。如果TLD与Azure租户关联，智能主机可能会有类似company-io.mail.protection.outlook.com的"-TLD"后缀。

在这篇博客文章中，我将介绍Microsoft提供的一些默认保护措施，展示我的研究方法，将一些伪造的设备代码钓鱼邮件投递到默认租户收件箱，并讨论缓解措施。

默认保护措施

根据此处文档：https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/anti-spam-protection-about?view=o365-worldwide#default-anti-spam-policy，从一开始就应用了一些默认保护措施。

根据Microsoft的文档：每个组织都有一个名为Default的内置反垃圾邮件策略，具有以下属性：

该策略是默认策略（IsDefault属性值为True），无法删除默认策略
该策略自动应用于组织中的所有收件人，无法关闭
该策略始终最后应用（优先级值为Lowest且无法更改）

Exchange Online Protection（EOP）使用专有的垃圾邮件过滤（也称为内容过滤）来帮助减少垃圾邮件。EOP尝试从已知的垃圾邮件和钓鱼威胁中学习以保护最终用户。

EOP的欺骗智能尝试检测电子邮件是否被伪造，并将其发送到垃圾邮件（仍会进入用户的邮箱）或发送到隔离区。

图1 – 欺骗智能

Exchange Online管理员可以创建高于默认策略的策略，但可能无法禁用它们。最严格的策略首先应用。

进行研究

预先声明：在整个研究过程中，由于Microsoft电子邮件保护的专有性质，结果各不相同。来自某个域的"发件人"地址的电子邮件可能会进入具有默认保护的租户的收件箱，但不会进入应用了未识别过滤器标签的另一个租户。对具有Exchange Online和第三方电子邮件网关的域进行实际测试导致了成功的欺骗，以及不在"允许"列表中的各种域。

组织应遵循类似程序来测试反欺骗和垃圾邮件过滤器的有效性。

为了评估针对*.onmicrosoft.com商业租户的默认垃圾邮件保护，我使用Azure Cloud33 shell通过SMTP通过目标组织的直接发送智能主机".mail.protection.outlook.com"发送消息。

虽然可以使用telnet（是的，我说的是telnet），但PowerShell提供了Send-MailMessage命令，可以为您包装连接。

图2 – Send-MailMessage

您可以使用html格式的文件作为模板。请注意，"-Body"标志采用字符串格式。将html文件转换为字符串，如下所示：

1

$email = Get-Content ./email.html | Out-String

为了简化研究过程，我编写了一个PowerShell脚本，将Send-Mail消息包装成一个易于使用的电子邮件防御效果测试工具：https://github.com/rvrsh3ll/FindIngressEmail。

我使用了一个非常简单的设备代码html模板，如下所示。如果您的目标使用Outlook桌面客户端应用程序，该应用程序将显示非"href"标签URL作为链接，这可能会在某些内容过滤实例中降低垃圾邮件分数。

图3 – 设备代码模板

注意：Azure控制台在20分钟不活动后会超时。我建议使用"Start-Job"将命令置于后台。然后，使用"watch ls"保持终端活动。

如果您测试单个目标域，可能会使用如下命令：

1

Start-Job -name asciiDeviceCode -ScriptBlock { Import-Module /home/rev/FindIngressEmails.ps1; Invoke-FindIngressEmail -smtpServer "<insert target domain>.mail.protection.outlook.com" -Subject "Microsoft 365 Session Sync Required" -bodyFile /home/rev/DeviceCodePhish.html -fromFile /home/rev/from_domains.txt -toEmail $_ -Delay 10 -Encoding ascii}

第一个测试是从noreply@globo.com伪造发送到三个独立的默认保护的Microsoft 365租户，例如"bydesign[@]REDACTED.onmicrosoft.com"。

图4 – 目标用户示例图5 – 发送Ascii设备代码钓鱼邮件

结果开始进入垃圾文件夹，如下所示。

图6 – Ascii设备代码钓鱼结果

ascii编码的电子邮件进入了三个邮箱中的两个垃圾文件夹。它没有进入"bydesign@“邮箱。奇怪的是，它也没有进入隔离区。

图7 – 隔离区

我尝试从相同的IP地址和Cloud Shell主机名再次发送相同的电子邮件。这次使用UTF32编码。

图8 – 发送UTF32编码的钓鱼邮件

这次，电子邮件进入了所有三个邮箱的垃圾文件夹。

图9 – UTF32编码的钓鱼邮件在垃圾邮件-1中图10 – UTF32编码的钓鱼邮件在垃圾邮件-2中

接下来，为了测试Cloud Shell IP范围是否有任何可见影响，我重新启动了shell以获取新的IP地址并重新发送电子邮件。

图11 – UTF32编码的钓鱼邮件在垃圾邮件-2中

接下来，我更改了电子邮件的主题并重新发送。

图12 – 主题更改

这些电子邮件也进入了垃圾文件夹。

我将编码更改为UTF7，并观察到结果也进入了垃圾文件夹。

图13 – UTF7钓鱼邮件图14 – UTF7编码的电子邮件在垃圾邮件中

为了更深入地了解为什么这进入了垃圾文件夹，我使用了https://mha.azurewebsites.net来解析标头。

图15 – 分析utf-7电子邮件标头

接下来，我使用这个脚本——https://github.com/mgeeky/decode-spam-headers——进一步分析标头。它可以输出一个方便的html文件供审查。

1

python .\decode-spam-headers.py .\globo_header.txt -f html -o report.html

该脚本将识别垃圾邮件标头。

图16 – Globo.com垃圾邮件标头

使用来自noreply@eircom.net的不同域电子邮件地址，我重新发送了相同的活动。

图17 – 来自EIRCOM的Ascii编码电子邮件在收件箱中

这次相同的电子邮件模板电子邮件进入了所有三个收件箱。这表明"发件人"域的电子邮件授权设置，如SPF、DKIM和DMARC，可能在Microsoft确定垃圾邮件置信度方面发挥重要作用。

图18 – 分析Ascii标头

然后我用python脚本解析了这些标头，以显示与globo.com标头的差异。

图19 – Eircom.net垃圾邮件标头

请注意置信度降至-1。

电子邮件包含"X-EOPTenantAttributedMessage"标头。我注意到此标头没有识别我发送消息的远程租户。它识别了接收租户ID。

图20 – 租户归属

这些测试是使用Exchange Online Protection中的默认租户设置进行的。针对Black Hills Information Security（BHIS）ANTISOC客户进行了额外测试，使用了混合的附加过滤器、传输规则和第三方电子邮件网关。在所有智能主机允许向组织发送电子邮件的情况下，BHIS成功将设备代码钓鱼邮件投递到组织的收件箱。包括使用"已知不良"模板，如原始的TokenTactics设备代码钓鱼模板。https://github.com/rvrsh3ll/TokenTactics/blob/main/resources/example_phish.html。

为了测试大量发送域，FindIngressEmails.ps1脚本将接受一个电子邮件地址列表，每行一个。

1
2


Import-Module ./FindIngressEmails.ps1
Invoke-FindIngressEmail -smtpServer "yourclientorg.mail.protection.outlok.com" -Subject "Device Reset" -bodyFile ./emailTemplate.html -toEmail "test.user@yourclientorg.com" -Delay 15 -RetryDelay 60

最后，我同时向三个租户发送了几百个这样的钓鱼邮件。

图21 – 133封收件箱

第一个账户收到了133封收件箱和207封垃圾邮件。

图22 – 41封收件箱

下一个邮箱有41封在收件箱，174封在垃圾邮件。

图23 – 5封收件箱

快速查看https://security.microsoft.com/quarantine显示一些也进入了隔离区。

图24 – 隔离的电子邮件

结果在租户之间非常不一致，然而测试表明相同的模板针对各种专有的Microsoft规则被不同地解释。

对于防御者

不幸的是，我还没有找到完全禁用Exchange Online上智能主机的方法。自从发布关于伪造Microsoft 365的原始博客以来，我遇到的唯一有效解决方案（怀疑是否详尽）是通过限制向组织发送电子邮件的IP地址或证书来保护智能主机。

结束语

我希望这篇博客文章能突出Exchange Online管理员持续测试其入站电子邮件控制有效性并从允许任意未经身份验证的用户向组织发送伪造电子邮件中保护直接发送智能主机的必要性。

参考文献

https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/anti-spam-protection-about?view=o365-worldwide#default-anti-spam-policy ↩︎ https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/preset-security-policies?view=o365-worldwide#order-of-precedence-for-preset-security-policies-and-other-policies ↩︎ https://learn.microsoft.com/en-us/azure/cloud-shell/overview ↩︎ https://www.blackhillsinfosec.com/spoofing-microsoft-365-like-its-1995/ ↩︎ https://learn.microsoft.com/en-us/exchange/troubleshoot/email-delivery/office-365-notice ↩︎