前言

这是一个七部分系列的最后一篇文章。查看第 1 部分 Kerberos 身份验证说明，了解其他链接。

在撰写本系列文章的过程中，我们阅读了许多有关信托的文章。其中之一是hamj0y的Not A Security Boundary: Breaking Forest Trusts，它指出一个林的管理员实际上可以破坏与它共享双向林间信任的林中的资源。正如我们在本系列的第 2 部分中所描述的，这种妥协是通过滥用无约束委托和打印机错误来实现的。

同样的harmj0y文章指出，攻击不可能通过单向信任进行：我们测试了单向林间信任场景，其中FORESTB.LOCAL –trusts–> FORESTA.LOCAL，但我们无法使攻击生效在任一方向。

然而，使用一种简单的技术，我们发现了另一种破坏受信任 (FORESTA) 域资源的方法。

简而言之，如果攻击者对信任 FORESTA 的 FORESTB 具有管理访问权限，则攻击者可以获得位于 FORESTA 中的信任帐户的凭据。此帐户通过其主要组是 FORESTA 中域用户的成员。正如我们经常看到的那样，域用户成员身份是识别和使用其他技术和攻击路径成为域管理员所必需的。

此技术不仅限于林信任，还可以在信任 -> 受信任的方向上对任何域/林单向信任起作用。信任保护（SID 过滤、禁用的 SID 历史记录和禁用的 TGT 委派）不会缓解该技术。

我们在这篇文章中包含了可能的缓解和检测。

• 信任账户攻击
• 示范
• 实验环境
• 信任账户攻击演示
• 信任帐户明文密码
• 攻击限制
• Microsoft 安全响应中心的响应
• 缓解和检测
• 循环域间信任帐户秘密
• 第七部分结论

当 Active Directory 域或林信任从域B设置到域A（B信任A）时，将在域A中创建一个名为B$的**信任帐户。当域 A 的用户为域 B 中的服务请求服务票证时，从信任帐户的密码派生的Kerberos信任密钥用于加密域间 TGT。（有关域和域间 TGT 之间的 Kerberos 身份验证的说明，**请参见第 1 部分）。

多年来人们都知道，可以使用 Mimikatz 等工具从具有管理权限的任一域中的任何 DC 获取信任密钥（B$' 明文凭据和 Kerberos 密钥）。这并不奇怪，因为秘密必须存储在两个域中，以便在域 A 中加密跨域票证并在域 B 中解密。

风险是因为启用了信任帐户 B 的主要组是域 A 的域用户，授予域用户的任何权限都适用于 B 的凭据进行身份验证域 A 使用 Kerberos 获取 Kerberos 票证，该票证被域 A 中的各种服务接受。

本质上，您可以按照与信任关系相同的方向从一个域中的域管理员升级到另一个域中的域用户，甚至是另一个林中：

域用户组默认情况下没有特权，但通常会被授予不适合其他域/林用户的权限。正如Microsoft 文档所解释的那样，域用户组包括域中的所有用户帐户，这就是为什么默认情况下不授予另一个域（可能是不受信任的域）的用户此成员资格的原因。

即使授予域用户的默认权限在某些情况下也足以使用以下技术破坏组所属的域：

• AD枚举/攻击路径发现
• 网络共享枚举
• 创建 DNS 记录
• 将计算机加入域
• 利用证书模板
• kerberoasting
• 以及更多...

为了演示攻击，我们将展示一个林中的信任（低特权）域（ext.local）如何能够通过单向林信任破坏另一个林中的受信任（高特权）域（root.local）。

实验环境

EXT DC (EXT-DC-01.ext.local) 和 root.local 的出站信任详细信息：

ROOT DC (ROOT-DC-01.root.local) 和 ext.local 的入站信任详细信息：

从 ext.local 到 root.local 的信任关系的信任帐户 (EXT$.root.local)：

因此在 root.local 和 ext.local 之间创建了单向林信任，其中 ext.local 信任 root.local 但不相反，换句话说，root.local 具有单向传入信任，而 ext.local 具有单向信任方式传出的信任。

信任账户攻击演示

我们将演示 ext.local 中的域管理员如何以信任帐户 root.local\EXT$ 的身份获取会话，然后演示 root.local 中域管理员的成员 Kerberoast root.local\svc_SQL-01。

因为 root.local 不信任 ext.local，所以对于任何 ext.local 用户或组成员身份，都无法从 ext.local 查询 root.local：

我们也无法为 Kerberoasting 请求 root.local 服务票证。

作为 EXT-DC-01.ext.local 上的 ext.local\Administrator，我们可以做的是使用 Mimikatz 转储传出信任密钥：

我们得到 [Out] 和 [Out-1]，它们分别是 TDO（Trusted Domain Object）的NewPassword属性和OldPassword属性，它们是用于跨域 TGT 的键。

TDO 不是 EXT$，而是 ext.local 中的一个 'trustedDomain' 对象类型：*CN=root.local,CN=System,DC=ext,DC=local*。在 root.local 中存在一个对应的 TDO：*CN=ext.local,CN=System,DC=root,DC=local*。在双方，信任密钥是相同的。TDO 存在于两个域中，但仅在受信任域中创建信任帐户以实现单向信任。

'NewPassword' 和 'OldPassword' 是相同的，因为我们实验室中的信任是最近创建的，并且信任密钥尚未更改。如 [MS-ADTS] 第 6.1.6.9.6.1 节所述，密钥每约 30 天自动循环一次。

如第 1 部分Kerberos 身份验证解释部分AD 信任中所述，信任密钥（存储在 TDO 中）源自信任帐户的密码。实际上，NewPassword明文信任密钥是信任帐户的当前密码，OldPassword明文信任密钥是以前的密码（或某些情况下的当前密码）。

这意味着，我们将 root.local\EXT$ 的当前明文密码和 Kerberos 密钥作为信任密钥存储在 ext.local 的 root.local 的 TDO 中 *CN=root.local,CN=System,DC=ext,DC=本地。root.local\EXT 对 root.local 进行身份验证。

使用 RC4 信任密钥，我们使用以下命令从 root.local 请求 TGT：

使用此票证，我们可以获得到 ROOT-DC-01.root.local 的有效服务票证，查询服务帐户，并对其进行 Kerberoast：

现在可以破解密码哈希以获得root.local的Domain Admin。

我们可以确认我们确实以 EXT$（和一个额外的 TGT）获得了 LDAP 服务：

信任帐户明文密码

Mimikatz 还将明文中的信任密钥转储为十六进制，再次考虑相同的转储：

可以通过将标记为红色的 [CLEAR] 输出从十六进制转换并删除空字节 '\x00' 来获得明文密码：

有时在创建信任关系时，用户必须为信任输入密码。在此演示中，密钥是原始信任密码，因此是人类可读的。作为关键周期（30 天），明文将不是人类可读的，但在技术上仍然可用。

明文密码可用于作为信任帐户执行常规身份验证，这是使用信任帐户的 Kerberos 密钥请求 TGT 的替代方法。在这里，从 ext.local 中查询 root.local 以获得域管理员的成员：

使用信任帐户无法进行以下登录：

非网络登录

某些登录类型是不允许的，例如 RUNAS、控制台登录和 RDP 登录（交互式和 RemoteInteractive 登录类型）。

唯一被确认接受的登录类型是网络。尚未评估 NewCredentials、Batch、Service 和 NetworkCleartext 登录类型。

NTLM 身份验证

NTLM 登录被阻止并返回STATUS_NOLOGON_INTERDOMAIN_TRUST_ACCOUNT代码，并显示消息使用的帐户是域间信任帐户。使用您的全局用户帐户或本地用户帐户访问此服务器。以下是拒绝访问的示例：

失败的 NTLM 身份验证将在受信任的域 (root.local) 中生成登录失败的安全事件：

向 Microsoft 报告了信任帐户攻击，Microsoft 将其回应为低严重性，他们将考虑在 Windows 的下一个完整版本中进行缓解：

我们尚未测试针对此攻击的缓解措施，但实施以下措施应该可以防止这种攻击。然而，由于它没有经过测试，我们不能确定在生产环境中这样做的后果是什么，因此应该小心应用它，因为它可能会破坏东西。

缓解这种攻击可能是以下之一：

• 将信任帐户的主组更改为权限低于域用户的组
• 禁用信任帐户
• 拒绝登录信任帐户

我们在多个生产 AD 森林中搜索了信任帐户的活动（在事件日志和 LastLogon 属性中），但没有发现它执行登录。如果其他人继续进行缓解研究，我们将不胜感激。

通过监视受信任 (root.local) 域中的信任帐户的任何登录尝试，可以检测到这种攻击。

在演示的攻击中，将发送一个 TGT 请求，可以在受信任域的 (root.local) 安全日志中检测到与信任帐户名称相关的 TGT 请求：

以及来自信任帐户的任何成功登录事件：

票证加密类型将为 0x17，称为 RC4_HMAC_MD5。这是因为使用 '/rc4' 参数调用 Rubeus。其他加密类型是可能的，但默认配置不支持，因为信任帐户的msDS-SupportedEncryptionTypes属性将为空白，这意味着只允许使用 RC4。

循环域间信任帐户秘密

在信任域 (ext.local) 受到威胁后，应手动循环信任密钥以防止持久性，但只有在再次获得信任域 (ext.local) 的信任之后。

对于此 Microsoft 的过程，可以使用在信任的一侧重置信任密码。在演示林中，我们从受信任的域 (root.local) 运行以下内容：

netdom trust root.local /domain:ext.local /resetOneSide /passwordT:7EPj5yZhHwa7UShB /userO:administrator /passwordO:*

然后从信任域的 (ext.local) PDC 模拟器运行以下命令：

netdom trust ext.local /domain:root.local /resetOneSide /passwordT:7EPj5yZhHwa7UShB /userO:administrator /passwordO:*

此后防止使用任何旧密钥的信任帐户攻击。如果不循环密钥，持久性将持续 60 天（两个 30 天的信任密钥重置周期）。对所有域控制器的授权应在一天内完成。

如第 1 部分Kerberos 身份验证解释AD 信任部分所述，信任帐户的单个密码更改不会使当前跨领域 TGT 无效，因为存在回退到以前的信任密钥（TDO 的 OldPassword）。但是，netdom trust /resetOneSide会覆盖当前和以前的信任密钥，如 Microsoft 所述：仅运行一次此命令（与 netdom resetpwd 命令不同），因为它会自动重置密码两次。该命令仅重置 EXT$ 密码一次，但 TDO 对象的OldPassword和NewPassword属性都被从新密码派生的相同密钥覆盖。这反映在我们在执行netdom trust /resetOneSide后转储 EXT$ 的凭据时，其中以前的密码哈希标记为红色：

这可能导致NTLM 网络身份验证在密码更改后最多 60 分钟内仍接受以前的密码，但如限制中所述：信任帐户不允许 NTLM 身份验证，因此我们找不到 EXT 的第二次密码更改$ 必要的。

我们已经展示了传入信任（域或林）如何允许攻击者获得域用户访问权限并对受信任域构成风险。

在基于Active Directory Red Forest Design aka Enhanced Security Administrative Environment (ESAE) 构建的环境中，一种从生产林到管理林（红色林）的单向传出林信任的设计，此攻击将允许攻击者已破坏生产林以获得红色林中的域用户访问权限。同样，如果从 DMZ 林到生产林存在单向林信任，则可以使用该攻击从 DMZ 进一步跳转到 IT 环境。

译文申明

• 文章来源为近期阅读文章，质量尚可的，大部分较新，但也可能有老文章。
• 开卷有益，不求甚解，不需面面俱到，能学到一个小技巧就赚了。
• 译文仅供参考，具体内容表达以及含义, 以原文为准 (译文来自自动翻译)
• 如英文不错的，尽量阅读原文。(点击原文跳转)
• 每日早读基本自动化发布(不定期删除)，这是一项测试

最新动态: Follow Me

微信/微博：red4blue

公众号/知乎：blueteams