跨域理论

当我们最终接管了当前域，接下来要做的便是占领更多的域，主要通过利用域信任以及其他的不当配置来实现。在那之前，我们需要熟悉一些跨域理论相关的名词，因为跨域理论较为复杂，涉及到的理论知识比较多。

 

概念与名词

域信任

正如字面意思所言，域与域之间可以存在信任，而并且因为信任的存在，可以决定资源的访问。但是，信任与资源访问的方向是相反的，如图所示，blue.local 域信任 red.local 域，但是 red.local 域能访问 blue.local 的资源，例如对其进行信息枚举（PowerView的那些查询）、资源与服务的访问等等。当然，这里所说的是单向的信任，单向信任只发生在不同森林之间。

white-bird 域与 raven-med 域双向信任可以是双向的，即因此彼此可以能互相访问对方域中的资源。raven-med 域与 prod 域是父子域关系，其中 raven-med 域为森林根域，父子域的信任总是双向的信任可以发生在同一森林之间，也可以是不同森林之间。同一森林之间的域总是互相信任的，而不同森林之间的资源访问则根据配置而定。但即便方向也是同一森林之间，情况也可能变得略微复杂，因为没有人规定 child1.red.local 不能有子域。在这种情况下，森林内之间的域的访问存在多条路径，，因如此快捷信任被建立，即 child2.red.local 与 right.child1.red.local 之间。虽然更多情况下，企业会考虑将这些域分布在不同森林里以划分职责与部门，但是我们至少要知道如果面对这种情况，该怎么利用我们的理论知识。

信任链

信任可以分为单向信任、双向信任，还可以根据传递性分为可传递信任与非传递信任。传递性确立了域信任是否可以被串联起来，例如，如果域 A 信任域 B，域 B 信任 域 C，那么域 A 信任域 C。在同一森林内，任意域都是双向信任和可传递的。但在森林之间，则默认不成立，例如 森林 A 信任森林 B，森林 B 信任 森林 C，但森林 A 不信任 森林 C，森林 A 甚至不知道森林 C 的存在。但是，互相信任的森林各自之中的子域则可以互相访问，例如 child1.sec.local 与 child1.red.local。

域管理员与企业管理员

对于单这是 AD 中的两个域内，尤其是子域高特权分组，域管理员，即 DA 仅对整个其特定域具有最高管理权限，然而对于域外却没有这样的特权。而跟域特有的企业管理员，即 EA，对整个森林中所有域具有最高管理访问权限。下图分别是 PROD 与 RAVEN-MED 中 administrator 的信息，我们发现只有 RAVEN-MED\Administrator 属于企业管理员分组。

 

外部安全主体

Active Directory 中的外部主体对象表示来自受目标域所信任的外部（外部）域的安全主体。 这用于将受信任域中的用户或组添加到信任域中的安全主体（组。

 

SID 历史

SID history 是一个适用于迁移场景的属性，当用户、组）可被或其他安全主体对象从一个域移动到另一个域时，会为该对象分配一个新的 SID，但旧的 SID 会存储在 SID History 属性中，这允许成为目标安全主体在迁移后通过添加他们以前的 SID 来保持对以前域中资源的组成员访问。

 

额外 SID

在 TGT中，存储用户登录信息以及权限的 KERB_VALIDATION_INFO 结构体 (https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-pac/69e86ccc-85e3-41b9-b514-7d969cd0ed73?redirectedfrom=MSDN) 中有一个属性为 ExtraSids，该属性可以为我们在另一个域中获得访问。用于攻击的话，我们可以将该属性值设置为根域中企业管理员的 SID，那么我们可以在另一个域中获得企业管理员的权限。如果是实际中合理的用途的话，即 prod.company.local 中的员工想要访问 company.local 中 devops 域组所能访问的SMB 共享目录资源。

也称为附加 SID，它是域中用户、组或其他安全主体对象的辅助标识符，这可能发生在域迁移期间或使用 SID 历史功能时。

信任密钥 (跨域密钥)

我们刚才说了 ExtraSids，而其技术实现则是通过信任密钥，即 trust key。2个域中，因为都有各自的 krbtgt 账户及对应的 NTLM 哈希，这 2 个域互相不知道对方域中的密码哈希，因此域 B 无法解密来自域 A 的 TGT，因此信任密钥应运而生，域 A 与域 B 需要共同的密钥。而实现方法则是，以上图的 red.local 以及 child1.red.local 为例，域 red.local 中存在 child1$的 的主机账号（虽然这样的主机并不存在），而 child1.red.local 中存在 red$ 的主机账号。这 2 个主机账号实为信任帐号，并且它们的哈希是一致的。我们可以通过 dcsync 获得它们的哈希，更详细的利用方法在下文继续。

跨域 TGT

在

Kerberos

SID 历史

SID是一个适用于身份认证的上下文中，当一个域中的用户从一个域被转移到了需要访问另一个域中的情景服务时的属性，将使用跨域 TGT (Inter-realm TGT)。当用户的所在域发生了改变，他们会得到一个新的 SID，而为了依旧保留对之前与服务所在域的资源访问，之前的共享该跨域 SID 则被添加到了 SID 历史。如果是森林之间，可TGT，以是企业 A 收购了企业 B。实际情景的话，可以是某公司的一员工从 IT 部门转移到了 开发部门：it.company.local -> dev.company.local。而 SID 历史可以协助我们在森林内允许对用户进行特权提升身份验证。

SID 过滤器

在森林之间的信任中，存在着 SID 过滤器的概念。因此，上文提到的 Extrasids 在森林之间的信任中被过滤了，组成员归属不再被盲目信任。例如，来自 red.local 的 TGT 在到达 sec.local 的时候，ExtraSids 会被移除。启用 SID 历史可以一定程度缓解 SID 过滤器的作用，但是无论如何，任何 RID 小于 1000 的 SID 都会被无条件过滤，而无论是域管理员还是企业管理员，其 RID 都是 500+，因此我们无法从森林 A 的 DC 直接移动到森林 B 的 DC。但是，如果我们具有一定特权的自定义的域组，那么会是我们转移到另一个森林的突破口。举个实际例子，森林 B 中的域组 "Server Admin" 显然是自定义的组，该组成员可以以本地管理员权限访问森林 B 中的所有服务器主机，那么我们可以以 Server Admin 组的 SID 作为 ExtraSids。

跨域理论

AS-REQ - 向当前域的域控制器请求 TGT。
AS-REP - TGT 返回给认证用户
TGS-REQ - 请求访问目标域中某服务的 TGS
TGS-REP - 当前域没有目标域 krbtgt 的密钥，因此返回的是使用跨域密钥加密的跨域 TGT。
TGS-REQ - 跨域 TGT 被传递到目标域，请求特定服务
TGS-REP - 跨域 TGT 被跨域密钥解密和验证，然后 TGS 被返回。