服务器（非）信任帐户

通过操纵 userAccountControl 实现 Active Directory 持久性

最近我一直在研究组 Managed Service Accounts（gMSA），并为了获取一些信息而阅读 MS-SAMR 协议规范。碰巧我在 userAccountControl 部分发现了一些有趣的信息，于是我们立刻停下手头的工作去测试它：

本质上，当在计算机对象的 userAccountControl 属性中设置了 UF_SERVER_TRUST_ACCOUNT 位时，随后 Active Directory 必须将同一对象的 primaryGroupId 设置为 Domain Controllers 组的 RID。因此，只需更改 userAccountControl 即可授予计算机对象域控制器的权限。

分析其行为

我们在实验室中使用了一个 Domain Admin 帐户开始测试，首先尝试使用域控制器的默认 userAccountControl 值 0x82000（十进制 532480）。该值是用于 SERVER_TRUST_ACCOUNT（0x2000，十进制 8192）和 TRUSTED_FOR_DELEGATION（0x80000，十进制 524288）的位标志之和。

更改 userAccountControl 值之后，我们看到 primaryGroupId 更新为 516（Domain Controllers 组的 RID），而且进展非常顺利！接下来，我们想知道是否只需要 SERVER_TRUST_ACCOUNT 这一位，因此我们再次尝试将 userAccountControl 属性设置为 8192。

因此，我们确认了协议规范的准确性，并且只有 SERVER_TRUST_ACCOUNT 这一位会导致 primaryGroupId 发生变化。

研究所需权限

我们开始考虑可能的滥用途径。如果只需要能够修改 userAccountControl 属性，那么我们可能正发现一种有趣的 权限提升 技术。我们使用一个权限较低的账号开始测试，该账号仅具有修改 userAccountControl 属性的权限，但很快就遇到了“拒绝访问”的错误。

原来我们应该在 MS-SAMR 文档里再往下多读几行。userAccountControl 属性的第 5 节概述了设置某些 userAccountControl 位所需的其他权限。为了设置 userAccountControl 的 UF_SERVER_TRUST_ACCOUNT 位，执行主体必须在域对象上具有 DS-Install-Replica（“在域中添加/移除副本”）权限。

我们向权限较低的用户授予了该权限，然后再次尝试我们的测试。

在向权限较低的用户授予以下权限后：对计算机上的 userAccountControl 进行写入的权限，以及在域对象上的 DS-Install-Replica 权限，我们的测试取得了成功。

默认情况下，DS-Install-Replica 权限会授予“Domain Admins”和“Enterprise Admins”这两个组。因此，除非是在配置不当的环境中，否则这种做法并不构成特权提升（privilege escalation）的攻击路径。然而，考虑到所需权限有限，我们开始思考如何将其用于实现域持久性（domain persistence）。

用于域持久性的应用场景

在评估这是否构成一种有趣的持久性（persistence）方法时，我们考虑了几个因素：所需权限的集合非常有限；这些权限通常不会被常规审查；(objectClass=computer) 这类账户很容易创建；计算机对象很少被审查（许多组织都会在“陈旧”的计算机对象上遇到问题）；并且利用该机制很容易、痕迹也相对短暂。

配置此机制只需要几个小步骤：

1. 创建一台假计算机（fake computer）账户，或创建 MSA / gMSA 账户。也可以使用现有账户，但持久性机制的有效性将受到密码变更频率的限制。不过，现有但已过时（不再使用）的计算机账户可能会成为一个很有吸引力的目标。
2. 将“Add/remove replica in domain”权限授予已被攻陷的普通用户、组或知名实体。我们使用了“Authenticated Users”，以便攻击者能够攻陷任何普通用户账号并重新获得对域的主导权。
3. 在计算机对象上授予“Write userAccountControl”权限，授予对象与上一步相同。

使用已知密码创建计算机账号

这似乎很显而易见，但并不是所有人都熟悉使用以下命令创建带有已知密码的计算机账号的能力，例如：使用 New-ADComputer 或者 New-ADServiceAccount cmdlet，例如：

New-ADComputer “ComputerName” -AccountPassword (ConvertTo-SecureString -AsPlainText -Force “Password”)

知道明文密码有几个好处。最重要的是，我们可以使用 ConvertTo-NTHash 和 ConvertTo-KerberosKey 这些 Michael Grafnetter 的 DSInternals PowerShell 模块中的 cmdlet 来计算 NTLM、AES-128 和 AES-256 哈希。当对手选择利用该后门时，他们需要以计算机帐户进行认证以使用其权限，并会通过 overpass-the-hash 技术来完成。指定 NTLM 和 AES 哈希可绕过大多数 overpass-the-hash 检测。

重新夺回域控制权

在布置账户和权限之后，如果对手失去了对其管理员凭据的访问权限，或被从网络中踢出，他们只需攻破任何普通用户，就能重新夺回域控制权。

使用任何用户帐户，攻击者只需要将其已布置的计算机的 userAccountControl 属性修改为 0x2000（8192）。此修改还会 causes 触发立即复制，这意味着攻击者无需针对特定的域控制器。一旦 userAccountControl 完成，攻击者就可以使用其域控制器权限来攻破整个域。

例如，对手可以使用计算机帐户执行 DCSync 并攻破 krbtgt 密码哈希。因为复制看起来像是来自域控制器，大多数 DCSync 威胁检测都不会发现该活动。一旦他们复制了 krbtgt 的密钥，他们只需将 userAccountControl 再切回 0x1000（4096），该计算机帐户就会显示为普通计算机帐户。

自动化该技术

为帮助展示该方法的潜在有效性，我创建了两个新的 PowerShell 函数，它们可在 GitHub 上获取。

第一个函数 Add-ServerUntrustAccount 会自动化三个配置步骤——使用已知密码创建一个假计算机帐户，并授予 “Authenticated Users” “Add/remove replica in domain” 和 “Write userAccountControl” 权限。

第二个函数 Invoke-ServerUntrustAccount 用于自动化对后门的利用，并设计为由非特权用户运行。该函数将 userAccountControl 属性设置为 0x2000（8192），然后使用 pass-the-hash 以假计算机帐户进行认证，执行对 krbtgt 哈希的 DCSync，最后将 userAccountControl 再次设置回 0x1000（4096）。

机制发现与利用检测

要发现这一点以及其他类似机制，组织应当定期审计敏感的 Active Directory 权限。实时监控（甚至阻止）敏感权限变更（例如“Add/remove replica in domain”）也很有帮助。我们测试了几款广受欢迎的开源 Active Directory 权限审计工具，只有 AD ACL Scanner 能够正确地将对手（adversary）的权限标记为令人担忧。

Active Directory 事件日志——也就是事件 ID 5136 和 4662——用于实现对 ACL 变更的基础实时监控，并可用于检测域级别的“Add/remove replica in domain”权限。不过，对这些事件的分析流程并不直观（不够直接）。

此外，查找并移除已经过期（stale）的计算机账户（以及 MSA 和 gMSA 账户），或与网络中实际机器不匹配的账户也很重要。例如，你可以使用 PowerShell 快速查找过期或未使用的计算机账户（将“ -90 ”替换为域中计算机账户的最长有效期/最长存续时间）：

$Date = [DateTime]::Today.AddDays(-90); Get-ADComputer -Filter ‘(Enabled -eq $true) -and (PasswordLastSet -le $Date)’ | Select Name

检测漏洞利用（exploitation）

检测对手使用此技术，关键在于监控对 userAccountControl 属性的变更。事件 ID 4742 – Computer Account Management 可用于监控 userAccountControl 值的变化。任何对 userAccountControl 的修改，且在预期的域控制器升级(promotion)之外将 0x2000 这一位设为置位状态，都会令人担忧。

总结

尽管显然不如关键漏洞那样严重，这类技术在企业环境中却经常被漏检，并可能让事件响应人员的工作变得更加困难。考虑到我们测试的 Active Directory 审计工具中的检测率较低，我们认为这是一种有趣的技术：它滥用那些鲜为人知、很容易被忽略的行为。我们欢迎您的评论和问题，如果不把您引向我们的 Attack Catalog ，那将是我们的失职——在这里您可以了解某些攻击是如何运作的。