从Azure AD到Active Directory（通过Azure）——一条意想不到的攻击路径

背景

在2019年的大部分时间里，我深入研究了Office 365和Azure AD，作为Trimarc Microsoft云安全评估开发的一部分，该评估专注于提升客户的Microsoft Office 365和Azure AD安全状况。在检查各项功能时，我发现了一个非常有趣的特性。

2020年5月，我在一场名为“保护Office 365和Azure AD：保护您的租户”的Trimarc网络研讨会中介绍了一些Microsoft Office 365和Azure Active Directory安全主题，并包括了本文描述的利用一个鲜为人知特性的攻击路径。

虽然Azure在某些方面利用Azure Active Directory，但Azure AD角色通常不直接影响Azure（或Azure RBAC）。本文详细描述了一种已知配置（至少对那些深入研究过Azure AD配置选项的人来说），其中Azure Active Directory中的全局管理员（又名公司管理员）可以通过租户选项获得对Azure的控制。这是一种“设计如此”的“应急”选项，可用于在失去此类访问权限时（重新）获得Azure管理员权限。

在本文中，我探讨了与此选项相关的危险以及它当前的配置方式（截至2020年5月）。关键要点是，如果您不仔细保护和控制全局管理员角色成员资格及相关账户，您可能会失去对所有Azure订阅中托管系统以及Office 365服务数据的积极控制。

注意： 围绕此问题的大部分研究是在2019年8月至2019年12月期间进行的，Microsoft可能在此之后对功能和/或能力进行了更改。

攻击场景

在此场景中，Acme有一个本地Active Directory环境。Acme采用Azure基础设施即服务（IAAS）作为额外的数据中心，并为他们的本地AD部署了域控制器到Azure（作为他们的“云数据中心”）。Acme IT遵循强化建议锁定了DC，并将Azure管理限制在托管DC的VM上。Acme在Azure中的服务器上托管了其他敏感应用程序。

Acme注册了Office 365并开始了试点。所有Active Directory和Exchange管理员（以及许多其他IT管理员）被授予临时的全局管理员（又名全局管理员或GA）权限以促进试点。因此，成员数量超出了应有范围，且保护不足。

全局管理员角色提供对Azure AD的完全管理员权限，并最终对所有Office 365服务具有完全控制权。

Microsoft在线文档提供了关键信息（2020年5月26日）：https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-assign-admin-roles 注意，这里没有关于Azure能力的说明。

攻击过程

攻击者对Acme的Office 365环境进行密码喷洒，并识别出一个没有MFA（多因素认证）的全局管理员账户。由于不到10%的全局管理员配置了MFA，这是一个真实的威胁。

攻击者创建一个新的全局管理员账户（或利用现有账户）。在此示例中，Office 365全局管理员账户“AzureAdmin”被攻破。

攻击者从Office 365全局管理员转变为影子Azure订阅管理员

根据Microsoft文档，将此选项从“否”切换为“是”，会将账户添加到Azure RBAC中的用户访问管理员角色，在根范围（控制租户中的所有订阅）。此选项仅对全局管理员角色的成员账户可用。

虽然此选项在目录属性部分配置，但这实际上是一个每账户配置选项。这个“魔法按钮”提供了管理Azure角色的能力，但没有直接的Azure权利（对VM）。

下图显示了提升访问权限时发生的情况以及Azure AD和Azure之间的连接点。我最大的担忧是，对于许多组织来说，管理Azure AD和Office 365的组通常与管理Azure的组不同。这意味着某人可以提升访问权限（考虑恶意管理员），而没有人会注意到。从内部威胁的角度来看，这 potentially 是一个严重的威胁。特别是围绕此问题的检测部分，在本文末尾探讨。

我还发现了一个似乎相关的API，这意味着攻击者不需要访问Azure AD门户来执行此操作。

有趣的是，如果此选项切换为“是”，然后从全局管理员角色中移除账户，Azure RBAC角色仍然保留，不会被移除。实际上，账户无法将此选项切换回“否”，直到它再次拥有全局管理员权限。

攻击者确定Acme在Azure中有几个本地AD域控制器。为了利用此配置，攻击者决定创建一个新账户并使用该账户访问Azure。随着攻击者控制的账户（称为“hacker”，以便我不会忘记我正在使用哪个账户）启用了Azure访问管理，此账户可以登录Azure订阅管理并修改角色。您会注意到我还添加了几个其他“看起来”属于的账户。

监控根Azure RBAC组“用户访问管理员”的更改有点复杂，因为在Azure门户中似乎无法查看此信息。主要的审查方法是通过Azure CLI。

一旦识别出需要移除的账户，必须使用Azure CLI移除（因为这是一个根级别角色）。如果尝试从订阅角色中移除账户，会出现以下消息，因为它必须在根级别移除。当账户将提升访问权限从“是”切换为“否”时，它会自动从用户访问管理员中移除。

问题回顾

让我们在此暂停片刻，回顾一下目前的配置。

攻击者通过密码喷洒Acme的Office 365租户，攻破了一个全局管理员账户，并找到了一个密码不良（且无MFA）的账户。或者，因为GA在其常规用户工作站（已被攻破）上使用其Web浏览器，GA会话令牌被盗。
攻击者使用此账户进行身份验证，并利用账户权限创建另一个用于攻击的账户或使用被攻破的账户。
攻击者将“访问管理Azure资源”选项切换为“是”，这将Azure AD账户添加到Azure RBAC角色“用户访问管理员”在根级别，适用于所有订阅。
用户访问管理员提供了修改Azure中任何组成员资格的能力。
攻击者现在可以将任何Azure AD账户设置为对Azure订阅和/或Azure VM具有特权权限。

从全局管理员到（Azure）用户访问管理员再到Azure管理员（或虚拟机参与者）

攻击者攻破了组织的全局管理员账户，要么是因为他们刚刚开始使用Office 365，要么是没有意识到保护GA的风险。无论如何，GA账户没有通过PIM、条件访问或MFA进行锁定。或者，因为GA在其常规用户工作站（已被攻破）上使用其Web浏览器，GA会话令牌被盗。

攻击者大约有一小时的时间来执行这些操作。攻破账户，提升访问权限到Azure，通过Azure角色成员资格获得Azure权利，移除提升访问权限，对所有或所有订阅中的任何Azure VM执行恶意操作，然后移除Azure中的角色成员资格（或不移除）。所需总时间：仅几分钟，可能总共最多15分钟。

攻击者更新Azure角色成员资格以在Azure VM上运行命令

为此账户设置“所有者”权限是明显的（并且可能添加账户到虚拟机管理员）。这将导致攻击者控制的账户对Azure VM具有完全访问权限。

在探索各种Azure RBAC角色时，我意识到一个更隐蔽的方法是“虚拟机参与者”，这听起来相当无害。根据Azure角色描述（https://docs.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#virtual-machine-contributor）：“让您管理虚拟机，但不能访问它们，也不能访问它们连接的虚拟网络或存储账户。” [2019年9月摘录的引用]

这听起来像对Azure VM的访问非常有限，直到您考虑在VM上运行PowerShell（作为系统）的能力。此权利是Microsoft.Compute/virtualMachines/runCommand/操作，包含在虚拟机参与者中。这包括重新启用管理员账户的能力。在Azure中的域控制器上，这将是域的RID 500账户。

一旦攻击者可以在Azure VM上运行PowerShell，他们就可以作为系统执行命令。我添加了明显的“hacker”账户和一个看起来“正常”的次要账户（也许？）称为“Azure AD服务账户”。这两个都可以运行PowerShell命令。

在此示例中，我运行一个PowerShell命令来运行“net localgroup”，这会更新本地管理员组。当在域控制器上执行时，这适用于域管理员组。这将在基于Azure的DC上发生，然后复制到本地DC。

注意： 能够在Azure VM上运行命令不仅限于客户托管在Azure上的本地Active Directory DC，还包括托管在那里的其他系统。

回到本地，我然后运行Active Directory模块PowerShell命令来获取域管理员组的成员资格，我们可以看到账户被添加。

假设启用了PowerShell日志记录（并发送到SIEM），可以看到此命令执行。根据我的经验，这并不常见。

一旦攻击者可以在Azure VM上作为系统运行PowerShell，他们可以从云托管的域控制器提取任何内容，包括krbtgt密码哈希，这意味着本地Active Directory环境的完全妥协。在此示例中，攻击者运行一个一行Invoke-Mimikatz PowerShell命令，转储AD krbtgt密码哈希的密码哈希。注意，我在这里运行的方式需要互联网访问。然而，可以在企业网络（或Azure租户内）的受感染系统上混淆和托管Invoke-Mimikatz，并利用它 instead。

结论

客户在Azure云中托管本地Active Directory域控制器。客户还有Office 365，其管理员账户没有得到适当保护。攻击者密码喷洒公司的账户，并识别出Office 365全局管理员的密码。使用此账户，攻击者转向Azure，并在托管公司本地Active Directory域控制器的Azure VM上运行PowerShell。PowerShell命令可以更新Active Directory中的域管理员组，甚至转储krbtgt密码哈希，使攻击者能够离线创建Kerberos黄金票据，然后使用伪造的Kerberos TGT认证票据对抗本地AD环境以访问任何资源。

为什么此问题重要？

客户通常不期望Office 365全局管理员有能力通过翻转账户上的一个选项（在所有地方的目录属性下）来控制Azure角色成员资格。Microsoft将全局管理员记录为“Office 365管理员”，而不是Office 365和Azure管理员（或至少具有该能力）。Office 365（Azure AD）全局管理员可以通过切换单个开关获得Azure订阅角色管理访问权限。Azure没有很好的细粒度控制谁可以在敏感的Azure VM上运行命令，如Azure托管的域控制器（或托管在客户Azure VM上的其他应用程序）。攻击者可以攻破Office 365全局管理员，切换此选项成为Azure IAM“用户访问管理员”，然后添加任何账户到订阅中的另一个Azure IAM角色，然后切换选项回“否”，并从用户访问管理员IAM角色中移除攻击者账户，日志记录最少，Azure AD中没有明确标识“访问管理Azure资源”为账户修改，Azure没有默认日志记录警报到此。一旦“访问管理Azure资源”位被设置，它会保持设置，直到后来将设置切换为“是”的账户将其更改为“否”。从全局管理员中移除账户也不会移除此访问权限。

日志记录和检测

截至2020年初，无法检查具有此“访问管理Azure资源”位设置的Azure AD账户（通过Azure AD门户或以编程方式）。此外，即使可以在另一个账户上检测到此设置，作为Azure AD全局管理员也无法移除它。只有设置它的账户可以移除它。在我遍历此攻击链时，似乎没有此活动的清晰日志记录（在Office 365、Azure AD或Azure日志中）。无法在Azure AD中检测到此配置——没有属性可查询账户。我能识别的唯一清晰检测是通过监控Azure RBAC组“用户访问管理员”成员资格以查找意外账户。您必须运行Azure CLI命令来检查Azure中的角色组成员资格。当我遍历Azure AD到Azure访问提升时，我试图识别一个可以警报的清晰事件，但未能成功。核心目录、DirectoryManagement“设置公司信息”日志注意到某些内容发生了变化，但没有说明是什么。Azure AD全局管理员的能力是“设计如此”；然而，在阅读关于Azure AD全局管理员能做什么时，不被期望且Microsoft没有很好地记录。此外，我担心这是一个Microsoft云客户无法检测、无法修复、最终无法预防的场景，因为如果Azure AD全局管理员账户暴露，没有真正的门可以锁定。对此的唯一好答案是用Azure AD PIM管理全局管理员组。尽管即使这样也不能阻止恶意管理员。

检测关键点：

无法使用PowerShell、门户或其他方法检测Azure AD用户账户上的此设置。
没有我能找到的Office 365/Azure AD日志记录说明Azure AD账户设置了此位（“访问管理Azure资源”）。
没有审计日志记录明确标识此更改。
核心目录、DirectoryManagement“设置公司信息”日志显示租户名称和执行它的账户的成功。然而，这仅标识了与“公司信息”相关的某些内容发生了变化——除了“设置公司信息”外没有记录详细信息，并且在事件中修改属性部分为空，说明“没有修改属性”。
在Azure中将此账户添加到VM参与者角色后，没有默认的Azure日志记录。

Azure AD到Azure缓解：

监控Azure AD角色“全局管理员”的成员资格变化。
对所有全局管理员角色中的账户强制执行MFA。
用Azure AD特权身份管理器（PIM）控制全局管理员角色。虽然PIM需要Azure AD Premium 2（AAD P2），但这些许可证仅适用于使用PIM的账户，因此仅适用于您的管理员账户；不是所有Azure AD账户。如果您有10个将成为Azure AD角色组成员的admin账户，那么您只需要10个Azure AD P2许可证。这是保护全局管理员的最佳方式。
确保全局管理员仅使用管理员工作站或至少安全的Web浏览器配置。
监控Azure RBAC角色“用户访问管理员”的成员资格变化。
确保敏感系统如Azure中的域控制器尽可能隔离和保护。理想情况下，为敏感系统使用单独的租户。

MSRC报告时间线：

2019年9月向Microsoft报告。MSRC在2019年10月初回应：“基于[内部]对话，这似乎是设计如此，文档正在更新。”
在2019年10月中旬经过一天的测试检测和潜在日志记录后，向MSRC发送了额外信息。
MSRC回应“您的大部分内容是准确的”
2020年1月下旬向MSRC发送更新，让他们知道我将将此作为更大演示的一部分提交给Black Hat USA和DEF CON。（2020年）。
MSRC确认。
向MSRC发送通知，我将在此博客中分享此信息。
截至2020年5月，MSRC安全事件仍然开放。在我与MSRC的互动中，Microsoft告知我，他们正在研究重新设计此功能以解决我识别的一些缺点。

（访问38,607次，今日3次访问）