从上而下的死亡：从 Azure 到 On-Prem AD 的横向移动

Azure 攻击原语，以便更好地了解系统的工作原理、可以滥用哪些特权和权限、可能存在哪些限制以及在真实环境中存在哪些攻击路径。我一直对允许以下攻击的攻击保持警惕：

• 从本地（on-prem）设备/用户上下文横向移动到 Azure
• Azure Active Directory (AAD) 租户内的权限提升
• 从 Azure AD 横向移动到本地 AD

将解释我们如何滥用 Microsoft Endpoint Manager 从 Azure 租户横向移动到本地 AD 域。当 Windows 设备已混合加入 Azure 租户和本地 Active Directory 域时，这种滥用成为可能。请注意，混合连接的 Windows 系统不是您可以使用 Microsoft Intune 定位的唯一系统类型 - 您还可以定位连接 Azure 的 Windows 系统和 Azure 或混合连接的 macOS 系统。

Azure 为组织提供了管理用户和服务主体身份所需的所有工具，并具有承诺降低开销、提供更长的正常运行时间并简化管理的有吸引力的功能。许多组织的管理员希望使用同一系统 Azure 来管理用户登录和访问公司资源的系统。为此，Microsoft 为 Azure 管理员提供了多种工具：ConfigMgr、Intune 和 Endpoint Manager。

这些工具允许管理员在一定程度上配置端点，虽然这些系统与您可以通过组策略实现的端点的细粒度控制相比可能相形见绌，但您可以配置和控制的系统范围相当大，这要归功于混合 Azure AD 加入设备。

正如计算机可以“加入”到本地 Active Directory 域（以及这样做的所有后果），计算机也可以“加入”到 Azure Active Directory 域。将计算机加入 vanilla AD 和 AzureAD 之间存在显着的技术和实践差异，但现在非常基本的类比就足够了。不仅可以将计算机加入普通 AD 域或AzureAD 域，还可以将计算机同时加入普通 AD 域和AzureAD 域：这就是微软所说的混合 Azure AD 加入。

如果组织正在使用混合 Azure AD 加入来管理本地 Windows 系统，则控制“全局管理员”或“Intune 管理员”主体的攻击者可以作为 SYSTEM 用户在这些本地设备上执行任意 PowerShell 脚本。来自不同 Active Directory 域的本地系统可以混合加入同一个租户，这在某些情况下会导致攻击路径源自一个本地域（或可以向 Azure 进行身份验证的许多其他身份平台之一）并登陆另一个本地域，其中绝对不存在域或林信任。

让我再说一遍：从 Azure AD 租户转向本地 AD 域可以在完全不同的身份管理环境和不明确相互信任甚至相互不了解的平台之间启用攻击路径。

枚举

确定哪些系统是混合连接的再简单不过了。通过执行以下步骤，您可以在 Azure 门户中轻松查看混合连接的设备：

登录 Azure 后，单击或搜索“Azure Active Directory：”

这会将您带到租户概览页面。在左侧导航中，单击“设备：”

此页面将列出“加入”到 Azure AD 租户的所有设备，无论加入类型如何。我们只有少数设备加入了该租户，因此很容易挑选出“加入混合 Azure AD”的三台设备：

您可以通过单击“添加过滤器”，选择“加入类型”，然后选择“混合 Azure AD 加入”来过滤此列表。这只会显示那些混合连接的设备。您可以通过添加“IsCompliant”筛选器进一步筛选此列表以仅显示 Intune 成功管理设备的那些系统：

我们还可以使用 Microsoft 的 AzureAD PowerShell 模块通过 PowerShell 轻松枚举这些设备。导入模块并通过租户身份验证后，使用Get-AzureADDevice轻松列出所有加入租户的设备：

Get-AzureADDevice返回的对象比默认显示的属性多得多，您可以通过将 cmdlet 的输出通过管道传送到 Get-Member 或通过将每个对象传送到管道中的“Select *”来查看这些属性。我们对“DeviceTrustType”属性特别感兴趣：

当“DeviceTrustType”属性的属性为“ServerAd”时，此设备为“已加入混合 Azure AD”，这意味着它已加入本地 Active Directory 域和 Azure AD 租户。我们可以使用 PowerShell 的管道和过滤器轻松列出具有此连接类型的所有设备，并显示我们关心的每个设备的最相关信息：

目前似乎没有办法确定这些设备加入到哪些本地域，至少从 Azure 租户身份验证用户的角度来看是这样。其他 Azure 对象（例如用户和组）具有“OnPremSecurityIdentifier”属性，其中列出了对象的本地 SID，但该信息似乎不适用于设备。

执行

任何经过 Azure 租户身份验证的用户都可以枚举上述信息——无需特殊权限或角色。滥用三个端点管理系统之一在混合连接的设备上执行 PowerShell 脚本需要“全局管理员”或“Intune 管理员”角色。

Microsoft 已表示他们正在将所有当前端点管理系统整合到一个名为 Microsoft Endpoint Manager 的统一工具下，因此我们将在本文中重点介绍该工具。

首先，准备好您的 PowerShell 脚本并将其保存为 PS1 文件。此时采取所有必要的操作安全性 (opsec) 和 AMSI 绕过步骤，请记住，除非您另有指定，否则脚本将以SYSTEM用户身份运行。另请记住，脚本将被写入磁盘，因此也请采取您需要的任何 AV 绕过措施。

接下来，以激活“全局管理员”或“Intune 管理员”角色的用户身份登录 Azure Web 门户（我们将在稍后的帖子中讨论如何升级到这些角色。）通过身份验证后，通过https访问 Endpoint Manager ://endpoint.microsoft.com：

单击左侧的“设备”，不出所料，您将进入设备概览：

在这里，您可以查看有关 Endpoint Manager 管理的设备的基本统计信息。请记住，由于这些系统（ConfigMgr、Intune、Endpoint Manager）正在一个统一工具 Endpoint Manager 下迁移；您在此处看到的信息可能具有误导性。您可能拥有比您在此界面中看到的更多的租户的混合连接设备。

点击“Policy”部分下的“Scripts”，进入脚本管理页面：

在这里，我们将添加新的 PowerShell 脚本。单击“添加”，然后单击“Windows 10：”

这将带您进入“添加 Powershell 脚本”页面。在第一页上，您将输入脚本的名称和简要说明。根据您的目标，您可能希望在此处选择一个不会引起怀疑的名称。为了一个简单的演示，我们现在将坚持使用“Hello World”脚本：

在下一页上，单击文件夹，然后从常用对话窗口中选择您的 PS1。您现在可以配置三个选项，但可以将它们全部保留在默认的“否”位置。最有趣的是，将第一个选项保持为“否”将导致脚本以 SYSTEM 用户身份运行：

单击下一步，您将看到允许您确定此脚本将针对哪些系统和用户执行的页面：

您可以选择将脚本分配给“所有设备”、“所有用户”或“所有用户和设备”。如果您将“分配给”下拉菜单保留为“选定组”的默认选择，您可以将脚本限定为仅在系统上执行或为属于某些安全组的用户执行。您可以选择：在每个可能的系统上运行脚本，或者通过将脚本限定为现有安全组或将特定设备或用户添加到新安全组来将其限制为仅在某些系统上运行。

单击“下一步”，您将看到评论页面，让您了解您将要做什么：

单击“添加”，Azure 将开始注册脚本。

此时，脚本现在已准备好在您的目标系统上运行。此过程的工作方式与组策略类似，因为在每个设备上运行的 Intune 代理会定期使用 Intune/Endpoint Manager 签入（默认情况下是每小时一次），以查看是否有 PowerShell 脚本可以运行，因此您需要等待您的目标系统最多需要一个小时才能真正拉下脚本并运行它：

预防

在我们讨论如何检测这种攻击发生之前，让我们先谈谈如何防止它发生。回想一下，这种攻击需要访问 Azure 中的特权身份——一个有权将 PowerShell 脚本添加到 Microsoft Endpoint Manager 的身份。

有两个租户级角色具有将 PowerShell 脚本添加到 Endpoint Manager 的明确能力：“全局管理员”和“Intune 管理员”。您可以通过 Azure 门户审核谁激活了这些角色，或者您可以使用 Powershell AzureAD 模块枚举当前激活了这些角色的人。例如，要列出激活了“全局管理员”角色的主体：

您是否信任所有这些用户/主体在您的混合连接、Endpoint Management 注册的系统上以 SYSTEM 身份执行代码？

我们还可以列出所有激活了“Intune Admin”角色的主体：

但是，也有可以在租户“角色和管理员”页面或通过 Microsoft Privileged Identity Management (MS-PIM) 控制的合格角色分配。您当前需要使用 Web GUI 在这两个位置列出符合条件的角色分配。

更复杂的是，具有其他角色的委托人可以授予自己或其他人这两个角色之一，但是，如前所述，我们将在以后的博客文章中更多地讨论这些类型的攻击。

此外，您可能希望了解和审核您的本地域中的哪些系统由 Intune 管理。有几种方法可以做到这一点，具体取决于您可以访问的信息或遥测数据类型：

1. 查找安装了 Intune 代理服务的所有系统。

• 服务短名称：IntuneManagementExtension
• 服务显示名称：“Microsoft Intune 管理扩展”
• 二进制文件：C:\Program Files (x86)\Microsoft Intune Management Extension\Microsoft.Management.Services.IntuneWindowsAgent.exe

2. 查找所有已解析 Intune MDM 注册 URL 的系统。默认情况下，这些 URL 是：

• https://portal.manage.microsoft.com/TermsofUse.aspx
• https://enrollment.manage.microsoft.com/enrollmentserver/discovery.svc
• https://portal.manage.microsoft.com/?portalAction=Compliance

3. 查找存在 Intune 服务日志文件夹/文件的所有系统。这些文件位于 C:\ProgramData\Microsoft\IntuneManagementExtension\Logs 中，该文件夹中可能存在三个文件：

• AgentExecutor.txt
• ClientHealth.txt
• IntuneManagementExtension.txt

检测

当 Intune 代理下拉并执行 PowerShell 脚本时，会在端点上创建许多工件——一些是永久性的，一些是短暂的。让我们先把这些短暂的文物排除在外。

在以下位置执行 PowerShell 脚本时，会在端点上创建两个文件：

• C:\Program 文件 (x86)\Microsoft Intune 管理扩展\Policies\Scripts
• C:\Program 文件 (x86)\Microsoft Intune 管理扩展\Policies\Results。

“Scripts”文件夹下的文件将是存储在 Azure 中的 PS1 的本地副本，“Results”文件夹下的文件将是 PS1 的输出；但是，一旦脚本完成运行，这两个文件都会自动删除。

还有一些永久性的文物遗留下来（假设攻击者没有篡改它们）。首先，可以在此日志文件中找到 PS1 内容的完整副本：

• C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\_IntuneManagementExtension.txt

例如，这是我们在上面的演示中使用的“Hello World”脚本，记录为脚本的“Policy Body”：

您在那里看到的哈希值也记录在注册表中的以下项下：

• HKLM\Software\Microsoft\IntuneManagementExtension\Policies\<用户 GUID>\PolicyHash

收集这些工件可能有助于检测或响应攻击者通过滥用 Endpoint Manager 在设备上执行的攻击。

结论

滥用 Microsoft Endpoint Manager 为攻击者提供了一种以 SYSTEM 用户身份在混合加入 Azure 租户的设备上执行代码的方法。它还可以在仅加入租户的设备上执行，只要这些设备由 ConfigMgr/Intune/Endpoint Manager 管理。这是迄今为止我们发现的第一个攻击向量，它允许将对 Azure 租户的控制转变为在本地域内执行代码，而无需重置本地用户密码。随着微软继续推出更多模糊云和本地之间界限的管理功能，我们预计会出现更多这种性质的攻击原语。