这篇文章旨在强调 GMSA 可以做什么，以及如果没有得到适当保护，攻击者可以做什么。当我们在 Trimarc 执行 Active Directory 安全评估时，我们发现在 AD 环境中组托管服务帐户的使用有限。应尽可能使用 GMSA 将用户帐户替换为服务帐户，因为密码将自动轮换。
组管理服务帐户 (GMSA) 创建用作服务帐户的用户帐户很少更改其密码。组托管服务帐户 (GMSA)提供了一种更好的方法（从 Windows 2012 时间框架开始）。密码由 AD 管理并自动更改。这意味着 GMSA 必须明确委派安全主体才能访问明文密码。与授权控制访问 ( LAPS )的其他领域非常相似，需要仔细考虑确定谁应该被授权访问。
组管理服务帐户 (GMSA) 的要点：
- 由 AD 管理的 GMSA 密码。
- 托管 GMSA 服务帐户的计算机从 Active Directory 请求当前密码以启动服务。
- 配置 GMSA 以允许计算机帐户访问密码。
- 如果攻击者使用 GMSA 破坏计算机托管服务，则 GMSA 受到破坏。
- 如果攻击者破坏了有权请求 GMSA 密码的帐户，则 GMSA 被破坏。
组托管服务帐户具有对象类“ msDS-GroupManagedServiceAccount ”和特定于 GMSA 的关联属性。这些属性包括：
- msDS-GroupMSAMembership (PrincipalsAllowedToRetrieveManagedPassword) – 存储可以访问 GMSA 密码的安全主体。
- msds-ManagedPassword – 此属性包含一个带有组管理服务帐户密码信息的 BLOB。
- msDS-ManagedPasswordId – 此构造属性包含组 MSA 的当前托管密码数据的密钥标识符。
- msDS-ManagedPasswordInterval – 此属性用于检索自动更改组 MSA 的托管密码之前的天数。
运行 AD PowerShell cmdlet Get-ADServiceAccount，我们可以检索有关 GMSA 的信息，包括特定的 GMSA 属性。此 GMSA 是域管理员组的成员，该组对域具有完全的 AD 和 DC 管理员权限。屏幕截图显示密码最近更改了，几周内不会更改 - 更改于 2020 年 5 月 11 日，并配置为每 30 天更改一次。这意味着，如果我们可以获取此帐户的密码，我们有将近一个月的时间来使用帐户凭据，然后才会更改。我们还可以识别一个可以检索密码数据的组。我们来看看这个有点。
获得访问服务器上运行的服务作为一个集团的托管服务有分牛逼 一旦我们得到了我们有一些选择的简版的上下文中运行的服务的服务器/服务器上。让我们来看看…
我们可以识别出 LCNSQL01 服务器在 GMSA 上注册为服务主体名称 (SPN)，并且我们看到该服务器位于 Servers OU 中。 如果我们可以破坏具有服务器 OU 权限的帐户，或通过 GPO 受限组或类似方式委派管理员权限，或者能够修改链接到此 OU 的 GPO，我们可以在 LCN 服务器上获得管理员权限
在获得与 GMSA 关联的服务器的管理员权限后，我们可以看到有一个服务在 GMSA 的上下文下运行（我在这里作弊并配置了 Windows License Manager Service 以使用此帐户启动）。
由于有一个服务在一个帐户的上下文下运行，我们可以得到与该服务帐户关联的密码数据。在这里，我们使用Mimikatz使用 sekurlsa::logonpasswords 转储 LSASS。 有趣的是，密码看起来有点不寻常：“_SA_{262E99C9-6160-4871-ACEC-4E61736B6F21}” 这不是标准密码（实际上不是与帐户关联的密码）。更重要的是，这个密码哈希是不正确的。Microsoft 将 GMSA 凭证加载到 LSASS 中，但似乎没有使用它。
为了获得正确的 NT 密码散列，我们需要使用Mimikatz命令“Sekurlsa::ekeys”，该命令用于获取 Kerberos 票证。
运行这个 Mimikatz 命令后，我们可以看到密码哈希。使用此密码哈希，我们可以通过哈希 (PTH) 来破坏 AD。
但是，如果我们无法访问服务器本身怎么办？ 使用 GMSA 密码访问入侵帐户 我们知道有一个组配置了获取 GMSA 密码的权限，让我们来看看。
所述的msDS-GroupMSAMembership（PrincipalsAllowedToRetrieveManagedPassword）属性包含一个称为“SVC-LAB-GMSA1组”组。此属性控制谁可以请求和接收明文密码。 枚举组“SVC-LAB-GMSA1 Group”的成员身份时，有计算机、用户和另一个组（“Server Admins”），因此让我们检查该组的成员。
现在我们有了一个可以获取 GMSA 明文密码的所有帐户的列表。有 11 个用户帐户具有该功能，其中 9 个看起来像普通用户帐户（提示：它们是！）。这是个大问题。 破坏其中一个，GMSA 帐户就会受到破坏，并且由于它是域中管理员组的成员，因此我们拥有该域。
一旦我们破坏了能够提取明文密码的用户（或计算机！）帐户。(PrincipalsAllowedToRetriveManagedPassword)，我们可以请求使用 Microsoft PowerShell cmdlet Get-ADServiceAccount。 我们可以利用 PowerShell cmdlet Get-ADServiceAccount 来获取 GMSA 的明文密码数据（属性 msds-ManagedPassword）。使用DSInternals 模块 (ConvertTo-NTHash)，我们可以将明文密码 blob 转换为 NT 哈希。
如果我们能够破解的帐户是计算机帐户，我们需要在计算机上以 SYSTEM 身份运行这些命令。如果我们能够在有权获取 GMSA 密码的服务器上获得管理员/系统权限，但 GMSA 没有在服务的上下文中运行（因此运行 Mimikatz 没有帮助，因为 GMSA信用不在内存中）。
在这里，我使用 PSEXEC 生成在本地 SYSTEM 帐户的上下文下运行的命令 shell。一旦以 SYSTEM 身份运行，我们就可以执行如上所示的相同操作。计算机帐户有权提取密码，但不是该计算机上的用户，因此我提升到 SYSTEM，然后作为关联的 AD 计算机帐户与 AD 交互。现在我可以得到 GMSA 密码了。
我在实验室中执行的下一步是确认 DSInternals 提供的 NT 密码散列与 Active Directory 中的匹配。 我使用DSInternals命令 Get-ADReplAccount 来获取 AD 密码哈希，并且可以确认从 GMSA 提取的密码哈希与从 AD 收集的密码哈希相同。
减轻
- 确定实际需要的权利，并确保只有所需的有限权利适用于 GMSA。
- 不要添加到 AD 特权组，除非使用 GMSA 的服务器仅限于第 0 层（域控制器）。
- 限制 GMSA 访问和位置（特别是如果有特权）。
