从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的控制。这是一个“按设计”的“应急”（break-glass）选项，可用于在失去此类访问权限时（重新）获得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管理员）被授予临时的全局管理员（又名Global Admin或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能力的内容。

一旦我们访问了Azure AD门户（默认情况下通常是所有Azure AD用户），我们可以查看Azure Active Directory的几个不同配置设置，这些设置控制着Office 365的许多方面。

此页面显示了目录属性，现在包括新的管理安全默认值。 towards the bottom is “Access management for Azure resources” toggle. That’s interesting…

攻击过程

攻击者通过密码喷洒攻击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会话令牌被盗。
攻击者使用此账户进行身份验证，并利用账户权限创建另一个用于攻击的账户或使用被攻破的账户。
攻击者将“Access management for Azure resources”选项切换为“是”，这将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/ action，包含在虚拟机参与者中。这包括重新启用管理员账户的能力。在Azure中的域控制器上，这将是域的RID 500账户。

一旦攻击者可以在Azure VM上运行PowerShell，他们就可以作为系统执行命令。我添加了明显的“hacker”账户和一个看起来“正常”的次要账户（也许？）称为“Azure AD Service Account”。这两个都可以运行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认证票据 against 本地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角色中删除攻击者账户，日志记录 minimal，Azure AD中没有明确标识“Access management for Azure resources”为账户修改，Azure没有默认日志记录警报到此。一旦设置了“Access management for Azure resources”位，它会保持设置，直到后来将设置切换为“是”的账户将其更改为“否”。从全局管理员中删除账户也不会删除此访问权限。

日志记录和检测

截至2020年初，无法检查具有此“Access management for Azure resources”位设置的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账户设置了此位（“Access management for Azure resources”）。没有审计日志记录明确标识此更改。核心目录、DirectoryManagement“设置公司信息”日志显示租户名称和执行它的账户的成功。然而，这仅标识了与“公司信息”相关的某些东西发生了变化 - 除了“设置公司信息”之外没有记录详细信息，在事件中，修改的属性部分为空， stating “No modified properties”。在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角色组的成员，那么您只需要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告知我，他们正在研究重新设计此功能以解决我识别的一些缺点。