利用Microsoft 365默认配置实现1995式邮件伪造攻击

背景介绍

我之前曾写过关于利用创建商业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租户关联，智能主机可能会有"-TLD"后缀，如company-io.mail.protection.outlook.com。

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

默认保护措施

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

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

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

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

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

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

进行研究

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

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

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

虽然可以使用telnet（是的，我说的是telnet），但PowerShell提供了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作为链接，这可能会在某些内容过滤实例中降低垃圾邮件分数。

注意：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}

测试结果

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

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

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

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

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

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

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

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

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

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

1

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

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

使用来自[email protected]的不同域电子邮件地址，我重新发送了相同的活动。

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

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

注意置信度下降到-1。

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

这些测试是使用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 "[email protected]" -Delay 15 -RetryDelay 60

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

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

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

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

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

给防御者的建议

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

结论

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