虽然 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) 作为附加数据中心，并将域控制器部署到 Azure 以用于其本地 AD（作为他们的“云数据中心”）。Acme IT 根据强化建议锁定了 DC，并将 Azure 管理限制在托管 DC 的 VM 上。Acme 在 Azure 的服务器上托管了其他敏感应用程序。 Acme 注册了 Office 365 并开始了试点。所有 Active Directory 和 Exchange 管理员（以及许多其他 IT 管理员）都被授予临时全局管理员（又名全局管理员或 GA）权限，以促进试点。因此，应该有更多的东西并且没有得到很好的保护。 全局管理员角色提供对 Azure AD 以及最终所有 Office 365 服务的完全管理员权限。 Microsoft 在线文档提供了关键信息 (5/26/2020)：https ://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-assign-admin-roles 请注意这里没有任何关于 Azure 功能的说明。
一旦我们可以访问 Azure AD 门户（默认情况下通常是所有 Azure AD 用户）。 我们可以查看控制 Office 365 许多方面的 Azure Active Directory 的几个不同配置设置。 此页面显示目录属性，现在包括新的管理安全默认值 。底部是“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 的组不同。这意味着有人可以提升访问权限（想想流氓管理员）而没有人会注意到。从内部威胁的角度来看，这可能是一个严重的威胁。尤其是在本文末尾探讨的这个问题的检测部分。
我还发现了一个似乎相关的 API，这意味着攻击者无需访问 Azure AD 门户即可执行此操作。
有趣的是，如果将此选项切换为“是”，即从全局管理员角色中删除该帐户，则 Azure RBAC 角色将保留并且不会被删除。事实上，该帐户在再次拥有全局管理员权限之前无法将此选项切换回“否”。
攻击者确定 Acme 在 Azure 中有一些本地 AD 域控制器。为了利用此配置，攻击者决定创建一个新帐户并使用该帐户访问 Azure。 为攻击者控制的帐户（称为“黑客”，所以我不会忘记我使用的是哪个帐户）启用 Azure 访问管理后，此帐户可以登录到 Azure 订阅管理并修改角色。 你会注意到我还添加了一些“看起来”像他们所属的其他人。
监视对根 Azure RBAC 组“用户访问管理员”的更改有点复杂，因为似乎没有任何方法可以在 Azure 门户中查看它。查看的主要方法是通过 Azure CLI。
确定需要删除的帐户后，必须使用 Azure CLI 将其删除（因为这是根级别角色）。 如果尝试从订阅角色中删除帐户，则会出现以下消息，因为它必须在根级别删除。 当帐户将提升访问权限从是切换到否时，它会自动从用户访问管理员中删除。
问题回顾 让我们在这里暂停片刻，回顾一下目前的配置。 1. 攻击者通过对 Acme 的 Office 365 租户进行密码喷射来破坏全局管理员帐户，并找到一个密码错误（且没有 MFA）的帐户。或者 GA 会话令牌被盗，因为 GA 在其常规用户工作站上使用其 Web 浏览器（已被盗用）。 2. 攻击者使用此帐户进行身份验证，并利用帐户权限创建另一个用于攻击的帐户或使用受感染的帐户。 3. 攻击者将“Azure 资源的访问管理”选项切换为“是”，这会将 Azure AD 帐户添加到适用于所有订阅的根级别的 Azure RBAC 角色“用户访问管理员”。 4. 用户访问管理员提供修改 Azure 中任何组成员身份的能力。 5. 攻击者现在可以将任何 Azure AD 帐户设置为拥有 Azure 订阅和/或 Azure VM 的特权。
从全局管理员到 (Azure) 用户访问管理员再到 Azure 管理员（或虚拟机参与者）。 攻击者会破坏组织的全局管理员帐户，因为他们刚刚开始使用 Office 365，或者没有意识到保护 GA 的风险。无论哪种方式，GA 帐户都没有被 PIM、条件访问或 MFA 锁定。或者 GA 会话令牌被盗，因为 GA 在其常规用户工作站上使用其 Web 浏览器（已被盗用）。 攻击者有大约一个小时的时间来执行这些操作。 破坏帐户，提升对 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月的报价]
在您考虑在 VM 上运行 PowerShell（作为系统）的能力之前，这听起来对 Azure VM 的访问非常有限。此权限是 Microsoft.Compute/virtualMachines/runCommand/ 操作，包含在 Virtual Machine Contributor 中。 这包括重新启用管理员帐户的能力。在 Azure 中的域控制器上，这将是域的 RID 500 帐户。
一旦攻击者可以在 Azure VM 上运行 PowerShell，他们就可以作为系统执行命令。 我添加了一个明显的“黑客”帐户和一个看起来“正常”（也许？）的辅助帐户，称为“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，并加以利用。
结论： 客户在 Azure 云中托管本地 Active Directory 域控制器。客户还拥有 Office 365，其管理员帐户未得到适当保护。 攻击者密码会喷洒公司的帐户并识别 Office 365 全局管理员的密码。使用此帐户，攻击者转向 Azure 并在托管公司本地 Active Directory 域控制器的 Azure VM 上运行 PowerShell。PowerShell 命令可以更新 Active Directory 中的域管理员组或事件转储 krbtgt 密码哈希，这使攻击者能够离线创建 Kerberos Golden Tickets，然后针对本地 AD 环境使用伪造的 Kerberos TGT 身份验证票证来访问任何资源。
为什么这个问题很重要？
- 客户通常不期望 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 资源的访问管理”）。
- 没有明确标识此更改的审核日志记录。
- 核心目录、目录管理“设置公司信息”日志显示租户名称和执行它的帐户是否成功。但是，这仅表明与“公司信息”相关的某些更改 - 除了“设置公司信息”之外没有记录任何详细信息，并且如果“修改的属性”部分为空，则说明“没有修改的属性”。
- 将此帐户添加到 Azure 中的 VM 参与者角色后，没有默认的 Azure 日志记录。
Azure AD 到 Azure 缓解：
- 监视 Azure AD 角色“全局管理员”的成员资格更改。
- 对具有全局管理员角色的所有帐户实施 MFA。
- 使用Azure AD Privileged Identity Manager (PIM)控制全局管理员角色。虽然 PIM 需要 Azure AD Premium 2 (AAD P2)，但只有使用 PIM 的帐户才需要这些许可证，因此只有您的管理员帐户；并非所有 Azure AD 帐户。如果您有 10 个将成为 Azure AD 角色组成员的管理员帐户，那么您只需要 10 个 Azure AD P2 许可证。 这是保护全局管理员的最佳方式。
- 确保全局管理员仅使用管理员工作站或至少使用安全的 Web 浏览器配置。
- 监视 Azure RBAC 角色“用户访问管理员”的成员资格更改。
- 确保尽可能隔离和保护 Azure 中的域控制器等敏感系统。理想情况下，为敏感系统使用单独的租户。
