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