利用微软服务中的MFA不一致性
概述
在渗透测试和红队评估等进攻性任务中，我观察到多因素认证（MFA）在不同微软服务中的应用存在不一致性。微软365和Azure拥有多个端点，这些端点可以在不同的条件访问策略设置下配置，有时会导致MFA应用方式的变化。试图防止单因素访问电子邮件和/或Azure的组织可能需要仔细检查其配置，以确保在所有访问门户上强制执行MFA。
为了帮助进攻操作者和防御者检查账户的MFA覆盖情况，我编写了一个名为MFASweep的工具，该工具尝试使用提供的凭据登录各种微软服务，以识别是否启用了MFA。直接跳转到工具请点击：https://github.com/dafthack/MFASweep
微软MFA
微软365和Azure内置了MFA选项。即使是免费的微软账户也可以使用MFA功能。越来越多的组织正在跨账户实施MFA。微软MFA有几种不同的验证选项：
- Microsoft Authenticator应用
- OAUTH硬件令牌
- 短信
- 语音呼叫
在进攻性任务中，我们通常执行密码攻击，如密码喷洒或基于凭据的网络钓鱼。通常，如果我们成功入侵凭据，MFA可以阻止任何进一步的活动。然而，正如本博客文章所示，管理员在如何应用MFA以及在哪里应用方面有很多选项需要考虑。这可能导致MFA覆盖的配置错误和不一致性。
安全默认值
当组织注册微软365时，它使用Azure AD作为用户的目录。Azure AD有一个默认启用的设置，称为“安全默认值”。安全默认值通过以下方式帮助保护微软账户：
- 要求所有用户注册Azure多因素认证（用户默认有14天时间通过Authenticator应用注册）。
- 要求管理员执行多因素认证。
- 阻止旧式身份验证协议（EWS、IMAP、SMTP或POP3等）。
- 在必要时要求用户执行多因素认证。
- 保护特权活动，如访问Azure门户。
这些设置极大地帮助保护账户访问。当此设置被禁用时，可能会出现配置错误……那么为什么要禁用它呢？事实证明，如果您同时使用条件访问策略，则无法启用“安全默认值”。
条件访问策略
条件访问策略是对用户如何被授予资源访问权限的细粒度控制。这些策略还可以控制MFA的应用时间和地点。条件访问策略可以围绕多种不同场景构建，例如进行身份验证的用户、他们来自的位置、他们使用的设备、他们的“实时风险”级别等。
例如，我测试过一些组织，它们利用条件访问策略允许从其IP空间单因素访问微软365，但在其他地方要求MFA。
在设置条件访问策略时，管理员有许多不同的选项需要考虑。用户是否需要向旧式协议进行身份验证，或者他们只会使用现代身份验证？他们会从手机、桌面设备还是两者进行身份验证？允许他们从家中连接还是仅限本地连接？管理员允许或阻止某些协议的能力是不同组织之间MFA实施差异的常见之处。我评估过的一些组织允许向所有常见门户进行身份验证，而其他组织则严格锁定访问权限。
我见过单因素认证潜入的较常见领域之一是旧式身份验证协议。微软将以下列表定义为“旧式”：
- 认证SMTP – 由POP和IMAP客户端用于发送电子邮件消息。
- Exchange ActiveSync (EAS) – 用于连接到Exchange Online中的邮箱。
- Autodiscover – 由Outlook和EAS客户端用于查找和连接到Exchange Online中的邮箱。
- Exchange Online PowerShell – 用于通过远程PowerShell连接到Exchange Online。如果阻止Exchange Online PowerShell的基本身份验证，则需要使用Exchange Online PowerShell模块进行连接。有关说明，请参阅使用多因素认证连接到Exchange Online PowerShell。
- Exchange Web Services (EWS) – 由Outlook、Outlook for Mac和第三方应用使用的编程接口。
- IMAP4 – 由IMAP电子邮件客户端使用。
- MAPI over HTTP (MAPI/HTTP) – 由Outlook 2010及更高版本使用。
- 离线地址簿 (OAB) – 地址列表集合的副本，由Outlook下载和使用。
- Outlook Anywhere (RPC over HTTP) – 由Outlook 2016及更早版本使用。
- Outlook服务 – 由Windows 10的邮件和日历应用使用。
- POP3 – 由POP电子邮件客户端使用。
- 报告Web服务 – 用于在Exchange Online中检索报告数据。
- 其他客户端 – 被识别为使用旧式身份验证的其他协议。
可以通过应用于“客户端应用”设置中的“旧式身份验证客户端”的条件访问策略来阻止对这些协议的访问。
旧式身份验证的生命周期结束
好消息是微软计划禁用旧式身份验证。坏消息是由于COVID-19，禁用日期已推迟到2021年下半年。因此，看起来我们还需要检查旧式身份验证一段时间。 https://techcommunity.microsoft.com/t5/exchange-team-blog/basic-authentication-and-exchange-online-april-2020-update/ba-p/1275508
MFASweep
由于我在不同组织的微软服务MFA设置中看到的差异，我编写了一个工具来自动化对一些不同协议的身份验证。MFASweep是一个PowerShell脚本，尝试使用提供的凭据登录各种微软服务，并尝试识别是否启用了MFA。根据条件访问策略和其他多因素认证设置的配置方式，某些协议可能最终是单因素的（这将告诉您哪些是）。它还有一个额外的ADFS配置检查，如果检测到，可以尝试登录本地ADFS服务器。
目前，MFASweep能够登录以下服务：
- Microsoft Graph API
- Azure服务管理API
- Microsoft 365 Exchange Web Services
- Microsoft 365 Web门户
- 使用移动用户代理的Microsoft 365 Web门户
- Microsoft 365 Active Sync
- ADFS
您只需要一组有效的凭据和脚本。将脚本导入PowerShell会话，然后运行以下命令之一。
警告：此脚本尝试登录提供的账户六（6）次（如果包括ADFS，则为七次）。如果您输入错误的密码，可能会锁定账户。
此命令将使用提供的凭据并尝试向Microsoft Graph API、Azure服务管理API、Microsoft 365 Exchange Web Services、Microsoft 365 Web门户（桌面和移动浏览器）以及Microsoft 365 Active Sync进行身份验证。
|
|
此命令使用默认身份验证方法运行，并检查ADFS。
|
|
如果您运行MFASweep并发现可以访问某个微软协议，您可能想知道可以用该访问权限做什么。接下来的几节简要概述了您可能能够做的事情。
Microsoft Graph API
使用Graph API的最佳方法之一是使用MSOnline PowerShell模块。Graph API主要与Azure AD绑定。这允许您查看目录中的信息，如用户和组。要使用MSOnline进行身份验证，导入MSOnline PowerShell模块，然后运行Connect-MsolService。这将打开内置的PowerShell浏览器进行身份验证。
|
|
或者……尝试首先将凭据传递给PowerShell变量，然后使用Connect-MsolService的-Credential标志。我见过通过此方法进行身份验证绕过了某些MFA限制。
|
|
有关身份验证后可以运行的一些命令列表，请参阅我的云渗透测试备忘单：https://github.com/dafthack/CloudPentestCheatsheets
ROADTools在这里也应该工作：https://github.com/dirkjanm/ROADtools
Azure服务管理API
如果用户有与其账户绑定的订阅，您可以利用Azure服务管理API在订阅内执行操作。为此，您可以使用“Az”PowerShell模块。您可以导入它并使用命令Connect-AzAccount进行身份验证。
|
|
与MSOnline模块类似，您也可以使用PowerShell变量并将其传递给Connect-AzAccount与-Credential标志。Microsoft Graph部分中提到的云渗透测试备忘单在这里也应该有用。
Microsoft Exchange Web Services (EWS)
访问EWS允许读取用户的电子邮件、获取全局地址列表、将电子邮件地址转换为内部AD用户名等。您可以使用MailSniper执行这些操作：https://github.com/dafthack/MailSniper。在Microsoft 365上使用MailSniper与EWS时，请确保使用-Remote标志，如以下命令所示进行身份验证。
|
|
Microsoft 365 Web门户
在https://outlook.office365.com或https://portal.azure.com使用浏览器登录。
通过移动设备访问Microsoft 365 Web门户
我见过组织使用的一种条件访问策略允许用户使用移动设备单因素认证访问O365，但在桌面客户端尝试时需要MFA。这是使用“设备平台”作为条件设置的。正如微软文档所述，设备平台通过用户代理识别，因此只需将用户代理更改为常见移动设备即可触发此策略。
在下面的屏幕截图中，我尝试通过桌面Web浏览器登录一个账户，该账户有一个条件访问策略，只允许移动设备，因此需要MFA。
在下一个屏幕截图中，我使用Chrome的内置开发者工具功能将用户代理更改为模拟Android设备后，尝试登录同一账户。这次，不需要MFA。
向Nikhil Mittal致敬，感谢他关于此的推文：https://twitter.com/nikhil_mitt/status/1287049649363144705
Microsoft 365 ActiveSync
ActiveSync在条件访问策略中被视为单独的“客户端应用”，而不是与其他旧式协议（如IMAP、EWS等）混在一起。因此，有可能EWS等旧式协议被阻止，但允许访问ActiveSync。Windows 10有一个内置的邮件应用程序，支持ActiveSync。要执行此操作，在Windows 10中打开邮件并添加账户。点击“高级设置”。
然后，点击“Exchange ActiveSync”。
填写如下屏幕截图所示的信息，然后点击“登录”。这应该设置ActiveSync开始与用户账户同步电子邮件。
ADFS
Active Directory Federation Services是我们看到的另一种常见的用户身份验证方法。使用ADFS，凭据不存储在Azure中。当用户尝试向Microsoft Online服务（如Microsoft 365）进行身份验证时，会发生重定向到组织托管的系统，在那里可以进行身份验证。检查组织是否设置了ADFS的一种快速方法是向以下URL发送Web请求，将“targetuser@targetdomain.com”替换为您正在测试的域中的任何电子邮件地址（用户账户是否存在无关紧要，只需域）：
https://login.microsoftonline.com/getuserrealm.srf?login=targetuser@targetdomain.com&xml=1
我在MFASweep中添加了对此的检查。脚本自动提示询问您是否要检查域的ADFS，或者您可以指定-Recon标志来强制它。
脚本还可以尝试登录ADFS服务器，让您知道是否在那里配置了MFA。
结论
在我发布此工具之前，我在一些真实世界的任务中使用了它，并发现了MFA部署中的不一致性，这些不一致性使我能够访问本应受保护的信息。我认为红队和蓝队都可以使用此工具来更好地了解部署到账户的MFA覆盖情况。请记住，这些不是唯一可能的条件。通过条件访问，还有其他可能的配置方式，并且可以组合多个选项以创建更复杂的规则。我在MFASweep中包含的检查是我在任务中看到的一些更常见场景，但未来可能会添加更多。如果您希望在MFASweep中看到任何其他检查，请在Twitter上给我发送DM并告诉我！
在此获取MFASweep：https://github.com/dafthack/MFASweep