External Forest Domain - One-Way (Outbound)
在此场景中 您的域 正在 信任 来自 不同域 的某些 权限。
枚举
出站信任
Trust Account Attack
当在两个域之间建立信任关系时，存在安全漏洞，这里将其称为域 A 和域 B，其中域 B 将其信任扩展到域 A。在此设置中，在域 A 中为域 B 创建了一个特殊帐户，该帐户在两个域之间的身份验证过程中发挥着关键作用。与域 B 关联的此帐户用于加密跨域访问服务的票证。
这里需要理解的关键点是，可以使用命令行工具从域 A 的域控制器中提取此特殊帐户的密码和哈希。执行此操作的命令是：
此提取之所以可能，是因为该账户名称后带有 $，处于活动状态，并且属于域 A 的“域用户”组，从而继承了与该组相关的权限。这使得个人可以使用该账户的凭据对域 A 进行身份验证。
警告： 利用这种情况以用户身份在域 A 中获得立足点是可行的，尽管权限有限。然而，这种访问足以对域 A 进行枚举。
在 ext.local 是信任域而 root.local 是被信任域的场景中，将在 root.local 中创建一个名为 EXT$ 的用户账户。通过特定工具，可以转储 Kerberos 信任密钥，从而揭示 root.local 中 EXT$ 的凭据。实现此目的的命令是：
在此之后，可以使用提取的 RC4 密钥通过另一个工具命令以 root.local\EXT$ 身份在 root.local 中进行身份验证：
此身份验证步骤打开了枚举甚至利用 root.local 中服务的可能性，例如执行 Kerberoast 攻击以提取服务帐户凭据，使用：
收集明文信任密码
在之前的流程中，使用了信任哈希而不是明文密码（该密码也被mimikatz提取）。
明文密码可以通过将mimikatz的[ CLEAR ]输出从十六进制转换并去除空字节‘\x00’来获得：
有时在创建信任关系时，用户必须输入信任的密码。在这个演示中，密钥是原始信任密码，因此是人类可读的。随着密钥的循环（30天），明文将不再是人类可读的，但在技术上仍然可以使用。
明文密码可以用作信任账户进行常规身份验证，作为使用信任账户的Kerberos密钥请求TGT的替代方案。在这里，从ext.local查询root.local的Domain Admins成员：
参考文献
Last updated
