章节13：支配域与森林
DCSync
DCSync 是一项通过 MS-DRSR 协议复制 AD信息以及哈希的技术。DCSync 权限意味着持有对象对域具有 DS-Replication-Get-Changes，Replicating Directory Changes All 和 Replicating Directory Changes In Filtered Set 特权。通常来说，只有域控制器自身、域管理员、企业管理员才具备 DCSync 权限，在配置失误的情况下，其他对象也会被赋予 DCSync 权限，使得我们不需要到达域控制器或者拿到域管理员帐号也能提取域内任何帐号的哈希。
至于对 Dcsync 权限的滥用，我们可以使用 Mimikatz 进行本地导出，也可以使用 Impacket 中的 secretdump.py 远程导出。在之前的内容里，我们发现 PROD 域里的 backup_operator 被配置了 Dcsync 特权，因此我们可以切换至该用户，然后使用 CobaltStrike 内置的 dcsync 快捷命令导出目标用户的凭证。
在 Linux 端，使用 secretsdump 脚本从 NTDS.DIT 中导出凭证：
python3 secretsdump.py <域fqdb>/<用户>:<密码>@<DC IP> -just-dc
黄金票据
此时，我们已经拿到了域管理员的身份，并且可以随意地查询到任何用户的凭证，那么怎么进行之后的利用呢？
黄金票据
回顾一下 Kerberos 的认证流程，当用户申请 TGT 的时候，DC使用 krbtgt 的 NTLM 哈希加密了 TGT。当然了，krbtgt 的 NTLM 哈希仅对域控制器所知。正因为如此，如果我们得到了 krbtgt 的密码哈希，那么我们可以用来任意地创建 TGT 票据。我们会在下文也提到白银票据，相比伪造一张服务票据，伪造 TGT 的优势在于可以以模仿的用户访问域内任何主机任何资源。
获得 krbtgt 的哈希也很简单，因为在制作黄金票据的时候，我们往往已经拿下了整个域，因此可以是通过 DCSync 获取 krbtgt 的哈希，可以在域控制器上从 Lsass.exe 进程中提取。
有了 krbtgt 的哈希后，我们还需要指定要模仿的用户、域的 FQDN、以及域的 SID。最终，我们可以使用 Rubeus 来制作黄金票据：
Rubeus.exe golden /aes256:8d253b4d7db4f28ccbb653ba5dfc3ba878bd376d99ab4859d575201935d79157 /user:administrator /domain:prod.raven-med.local /sid:S-1-5-21-1674258736-4167122442-1078531953 /nowrap
制作之后，可以将票据保存为 kirbi 文件，然后通过 CobaltStrike 的 kerberos_ticket_use 命令导入从而访问任意资源。
KB5008380 补丁
随着 KB5008380 补丁的下发，Kerberos 票据中 PAC 部分增加了额外的校验以及请求票据的用户信息。可以通过修改注册键 PACRequestorEnforcement 来决定想要的 PAC 校验行为：支持旧的 PAC、新旧 PAC 都兼容、只支持新 PAC。
PAC 数据负责用户授权，它包含访问不同服务的权限。 PAC 数据是通过 Kerberos 身份验证和授权流程从一张票据复制到另一张票据。当用户首次成功通过 KDC (AS_REQ) 的身份验证时，用户会收到一个包含用户加密 PAC 数据的 TGT 作为响应 (AS_REP)，TGT 中的 PAC 包含授权数据 ，即用户组归属列表。之后，当用户请求 TGS 访问特定服务 (TGS_REQ) 时，PAC 按原样从 TGT 被复制到 TGS (下面的第三步和第四步)。 当 TGS 用于访问服务 (AP_REQ) 时，服务会检查 PAC 以验证用户的访问权限。
PAC 授权数据位于 KERB_VALIDATION_INFO 结构体中的 GroupIds 属性。
该补丁在 PAC 中提供了一个新的结构体，其中包含用户安全标识符 (SID)。 SID 由 KDC 验证 (上图中的第三步)，票证中的用户名 (cname) 被解析为 SID 并与新的 PAC_REQUESTOR 值进行比较。
也因为这个更改，增加了新的安全事件：票据没有请求者、请求者不一致。那么在强制执行新 PAC 结构的环境里，对于黄金票据攻击，我们需要指定新的 PAC 结构以及存在的域用户，一些安全工具也相应进行了更新 (https://github.com/gentilkiwi/mimikatz/pull/380)。
白银票据
伪造的服务票据则是使用了特定主机的 AES256 密钥或者 NTLM 签名所伪造的白银票据，有了白银票据，我们可以模仿任何用户访问该主机上的任何服务，对于中短期的持久化较有帮助。虽然白银票据支持 AES256 密钥以及 NTLM 哈希，但是依旧更建议使用 AES256 密钥，原因在密钥传递小节哪里说过。我们依旧可以使用 Rubeus 来制作白银票据。我们需要以下参数：
要模仿的用户
域的FQDN
目标主机及服务
主机帐号的AES256密钥
域的SID如果要制作一张访问 File01 主机上服务的白银票据，命令如下：
rubeus.exe silver /service:cifs/file01.prod.raven-med.local /aes256:c9e598cd2a9b08fe31936f2c1846a8365d85147f75b8000cbc90e3c9de50fcc7 /user:administrator /domain:prod.raven-med.local /sid:S-1-5-21-1674258736-4167122442-1078531953 /nowrap
将创建的白银票据保存在本地，然后导入到牺牲会话中，发现得以成功访问目标服务了。
为了根据我们的需要创建白银票据，我们可以参考如下列表来指定要维持访问的权限：
| 访问类型 | 服务 |
| PsExec | CIFS |
| WMI | HOST, RPCSS |
| WinRM | HOST, HTTP |
| 计划任务 | HOST |
| DCSync | LDAP (仅在域控制器上) |
钻石票据
类似于黄金票据，钻石票是一种 TGT，可以以任何用户身份来访问任何服务。黄金票据是完全离线伪造的，用该域的 krbtgt 哈希加密，然后传递到登录会话中以供使用。因为域控制器不追踪它发布的有效 TGT，所以它会接受使用自己的 krbtgt 哈希加密的 TGT。
因此，检测黄金票据使用的一种可行策略是查找没有相应 AS-REQ 的 TGS-REQ。 钻石票据是通过修改域控制器签发的有效 TGT 的字段来制作的。这是通过请求 TGT，使用域的 krbtgt 哈希对其进行解密，修改票据的所需字段，然后再重新加密来实现的。这克服了之前提到的黄金票据的缺点，即任何 TGS-REQ 都会有一个前置的 AS-REQ。
我们可以使用 Rubeus 制作钻石票据，需要以下这些参数：
/tgtdeleg：使用kerberos gss-api获取有效的 TGT，并且不需要知道当前用户的任何凭证
/ticketuser：要模仿的用户
/ticketuserid：要模仿的用户的域 RID
/groups：组RID，域管理员的为512
/krbkey：krbtgt的AES256 密钥最终命令如下：
rubeus.exe diamong /tgtdeleg /ticketuser:administrator /ticketuserid:500 /groups:512 /krbkey:8d253b4d7db4f28ccbb653ba5dfc3ba878bd376d99ab4859d575201935d79157 /nowrap
之后，我们导入票据即可。
跨域理论
当我们最终接管了当前域，接下来要做的便是占领更多的域，主要通过利用域信任以及其他的不当配置来实现。在那之前，我们需要熟悉一些跨域理论相关的名词，因为跨域理论较为复杂，涉及到的理论知识比较多。
概念与名词
域信任
域信任是 AD 的一个关键组件，它使一个域中的用户能够对另一个域中的系统和资源进行身份验证和访问。理解域信任的几个方面很重要，包括信任的方向和对资源的访问。信任的方向可以是单向的，也可以是双向的。单向信任是在两个域之间创建的单向身份认证路径，如果域 A 信任域 B，则域 B 中的用户可以访问域 A 中的资源。但是，域 A 中的用户不能访问域 B 中的资源，单向信任发生在不同的森林之间。双向信任是相互的信任，每个域中的用户都可以访问另一个域中的资源。因此，如果域 A 和域 B 之间存在双向信任，则域 A 中的用户可以访问域 B 中的资源，反之亦然。双向信任必定建立在在同一片森林里，可能建立在不同的森林间。尽管信任决定着资源访问的方向，但在建立信任后，域信任不会自动授予来自受信任域的用户访问信任域中所有资源的权限，对资源的实际访问受权限和组成员身份以及特权有关。
信任还可以根据传递性进行分类。传递信任则是，如果域 A 信任域 B，域 B 信任域 C，则域 A 信任域 C。
那么非传递信任 (单向或双向) 仅限于信任关系中的两个域。在同一森林内，任意域都是双向信任和可传递的。但在森林之间，则默认不成立，例如 森林 A 信任森林 B，森林 B 信任 森林 C，但森林 A 不信任 森林 C，森林 A 甚至不知道森林 C 的存在。
例如，在我们靶场里，white-bird 域与 raven-med 域相互信任，med-factory 域信任 raven-med 域，但是 med-factory 的信任不能间接延续到 white-bird 域。但是，互相信任的森林各自之中的子域则可以互相访问，因为 prod 域是 raven-med 的子域，因此 white-bird 域与 prod 域也是互相信任，med-factory 域也单向信任 prod 域。
域管理员与企业管理员
这是 AD 中的两个高特权分组，域管理员仅对其特定域具有管理权限，而企业管理员对森林中所有域具有管理访问权限。下图分别是 PROD 与 RAVEN-MED 中 administrator 的信息，我们发现只有 RAVEN-MED\Administrator 属于企业管理员分组。
外部安全主体
AD 中的外部主体对象表示来自受信任的外部域的安全主体，这用于将受信任域中的用户或组添加到信任域中的安全组。例如在 Med-factory 域中 (Med-factory 信任 Raven-med)，Administrators 组内有个外部成员，该成员为 Raven-med 中的 ExtAdmin 组。
SID 历史
SID History/ExtraSids 是一个适用于迁移场景的属性，当用户、组或其他安全主体对象从一个域移动到另一个域时，会为该对象分配一个新的 SID，但旧的 SID 会存储在 SID History 属性中，这允许安全主体在迁移后通过添加他们以前的 SID 来保持对以前域中资源的访问。
信任密钥 (跨域密钥)
信任密钥本质上是在创建信任关系时在两个域之间建立的密钥，信任密钥用于保护两个域之间的通信并确保域彼此的真实性。例如 prod 域与 raven-med 域互相信任，因此在 raven-med 域中存在着 prod$ 的信任账户，在 prod 域中存在着 raven-med$ 的信任账户，信任账户是特殊的账户类型，在用户管理工具中不可见，但的确存在。下图分别是 Dc01 与 Dc02 上的视角，我们可以看到同一个信任方向 (例如都是从 PROD 到 RAVEN-MED) 的密钥在 2 个域中是相同的。
跨域 TGT
在 Kerberos 身份认证的上下文中，当一个域中的用户需要访问另一个域中的服务时，将使用跨域 TGT (Inter-realm TGT)。用户所在域与服务所在域共享该跨域 TGT，以允许对用户进行身份验证。
SID 过滤器
森林是域信任的安全边界，而 SID 过滤器是 AD 信任关系中使用的一项安全功能，域在建立信任后，通常会默认启用 SID 过滤器，以提供一定程度的保护，以防止试图使用 SID 历史获得对资源的未授权访问，即不再盲目 SID 组归属了。域中的每个帐户和组都有一个 SID，其中包括域中所有 SID 都相同的域前缀，以及域中唯一的 RID。Windows 为新建的用户、主机。群组赋予高于或等于 1000 的 RID，这意味着如果 SID 包含小于 1000 的 RID，则 SID 对应于内置安全主体，例如认证用户 、所有人，或域管理员。
通过过滤掉 RID 小于 1000 的 SID，有助于防止用户授予自己不应有的特权。例如，域 A 中的攻击者设法将域 B 中的域管理员组的 SID 添加到他们自己的访问令牌中，如果没有 SID 过滤器来过滤掉该 SID，那么该攻击者将能够获得对域 B 的域管理员权限。值得注意的是，是可以在域信任上禁用 SID 过滤器的。
跨域理论
有了对上述概念的理解，让我们来了解一下跨域访问服务的过程吧。从本质上讲，域信任所做的只是将两个域的身份验证系统链接起来，并允许身份验证通信通过引用系统在它们之间流动。如果用户请求访问位于所在域之外的资源的 SPN，则他们的域控制器将返回指向外部域 KDC 的引用票据。
用户的 TGT 包含在此 TGS-REP 引用票据中，并且此票证使用域信任密钥加密/签名的，而不是第一个域的 krbtgt 帐户的密钥。 此票据通常称为跨域 TGT。然后，外部域通过信任密钥对其进行解密来验证/解密引用票据中包含的 TGT，然后继续正常 Kerberos 流程的其余部分。流程图如下所示：
AS-REQ：用户向当前域的域控制器请求 TGT
AS-REP：KDC 将 TGT 返回给认证用户
TGS-REQ：用户向 KDC 请求访问目标域中某服务的 TGS
TGS-REP：当前域没有目标域 krbtgt 的密钥，因此返回的是使用跨域密钥加密的跨域 TGT
TGS-REQ：跨域 TGT 被传递到目标域，请求特定服务
TGS-REP：跨域 TGT 被跨域密钥解密和验证，然后 TGS 被返回给用户
有了对跨域认证和访问的理解后，我们接下来讨论各种情况下的跨域利用。
双向信任
有了上一小节的理论基础，我们来利用双向信任实现域间的移动。因为双向信任既可以发生于森林之内，也可以发生于森林之间，因此我们分别讨论。
森林之内
森林之内的横向移动是最简单的情形，因为信任是相互的，例如从子域移动到父域。我们有 2 种方式在森林之内移动，分别是利用 krbtgt 以及信任密钥，我们在 Dc01 上进行利用。
krbtgt
由于信任在 AD 森林中的作用方式，sidHistory 属性 (PAC 中的 ExtraSids) 在森林的域中是起作用的，因为这些 SID 不会在跨域引用中被 SID 过滤器过滤掉。因此，将 sidHistory/ExtraSids 设置为根域中的企业管理员的 SID 能够奏效，就好像他们真的是是企业管理员一样。Microsoft 已经知道这是一个问题，因此 sidHistory 是一个受保护的属性，很难修改，在以前对其的利用也是相当复杂的。
现在，有了 Mimikatz/Rubeus 的黄金票据模块，攻击者可以为伪造的票据设置 KERB_VALIDATION_INFO 结构体 (该结构定义了 DC 提供的用户登录和授权信息) 中的 ExtraSids 部分，ExtraSids 被描述为指向 KERB_SID_AND_ATTRIBUTES 结构体列表的指针，该结构包含与主体所属域以外的域中的组相对应的 SID 列表。
因此，如果攻击者在森林中的任何子域中能有权限检索子域的 krbtgt 哈希，将根域的企业管理员的 SID 添加到 Mimikatz/Rubeus 伪造的黄金票据中，便可以接管整片森林。
但，这仅适用于在森林内的双向信任，由于 SID 过滤，这不适用于森林之间的双向信任。我们来看看利用的过程：
获得子域的 krbtgt 密钥：
将 ExtraSids 设置为企业管理员的 SID
Rubeus.exe golden /aes256:8d253b4d7db4f28ccbb653ba5dfc3ba878bd376d99ab4859d575201935d79157 /user:Administrator /domain:prod.raven-med.local /sid:S-1-5-21-1674258736-4167122442-1078531953 /sids:S-1-5-21-3775014555-2484002919-2799327105-512 /nowrap 
创建牺牲会话、导入票据以及验证访问。
信任密钥
跨域访问服务的过程我们已经讨论过了，首先我们需要得到信任密钥，通过下述命令之一获得：
mimikatz lsadump::dcsync /domain:prod.raven-med.local /user:raven-med$
mimikatz lsadump::trust /patch 如下图所示，得到的密钥是一致的。如果用的后者，寻找 [In] 信任密钥。
使用跨域密钥申请跨域 TGT：
Rubeus.exe golden /rc4:7a93230db5144ccd92ac1fa086f46e49 /user:Administrator /domain:prod.raven-med.local /sid:S-1-5-21-1674258736-4167122442-1078531953 /sids:S-1-5-21-3775014555-2484002919-2799327105-512 /nowrap
使用跨域 TGT 申请 TGS：
Rubeus.exe asktgs /ticket:<...> /service:cifs/dc02.raven-med.local /dc:dc02.raven-med.local /nowrap
创建牺牲会话、导入票据以及验证访问。
森林之间
请记住，森林是 AD 中安全的边界，而域不是，因此利用森林之间的双向信任我们会遇到其他的限制。我们在 Dc02 上试图通过利用森林间的双向信任移动到 White-bird 域中。
为了缓解 SID 过滤器的限制，我们需要在 Dc05 上开启 SID 历史
netdom trust white-bird.local /d:raven-med.local /enablesidhistory:yes
再来查看域信任，我们发现增加了 TREAT_AS_EXTERNAL 的信任属性。
对于具有双向信任的森林之间的移动，步骤整体相似，但是在上一小节我们提到了 SID 过滤器，因此我们需要寻找出 RID ≥1000 的组。White-bird 域中，Server Admin 满足，虽然并不能让我们直接获得对域控制器的访问，但给予了我们一个立足空间。
入口信任
入口信任，即目标域信任当前域，当前域可以访问目标域中的资源。要想从当前域移动到信任我们的目标域，我们有以下步骤需要完成：
寻找外部组/成员。
既然我们可以访问目标域中的资源，自然可以使用 PowerView 等工具对目标域进行枚举。让我们来查找目标域中包含域外用户的分组：
Get-DomainForeignGroupMember -domain <目标域>
我们发现 Raven-med 域中的 ExtAdmin 分组在 Med-factory 域中是 Administrators 组的外部成员，即 ExtAdmin 中的用户在 Med-factory 中具有域管理员特权。考虑到我们已经在 raven-med 域中获得了管理员权限，那么模仿任何 ExtAdmin 中的成员是简单的。
请求跨域 TGT
我们先为目标用户 michael 申请一张 TGT。
rubeus.exe asktgt /user:michael /domain:raven-med.local /aes256:8d71c60bd250034b4c5dec618bf951c82761d17e451f8d53ef26784b3c5c6e09 /nowrap
然后用这张 TGT 请求跨域 TGT：
rubeus.exe asktgs /service:krbtgt/med-factory.local /domain:raven-med.local /dc:dc02.raven-med.local /ticket:<...> /nowrap
请求 TGS
我们用这张跨域票据请求目标域中的 TGS，这里，我们请求的是 CIFS 服务的票据。
rubeus.exe asktgs /service:cifs/dc03.med-factory.local /domain:med-factory.local /dc:dc03.med-factory.local /ticket:<...> /nowrap
访问资源
创建一个牺牲会话，导入 TGS 票据，访问 Dc03 的资源。
出口信任
相比于入口信任与双向信任，出口信任的利用途径则少了许多，因为我们无法直接对目标域进行枚举和访问。如图所示，white-bird 域信任 med-deal 域，因此在 white-bird 域里，我们并不能枚举到 med-deal 域中的信息。
信任密钥利用
在存在信任关系的 2 个域之中，都会分别存储着信任账户，它们的 NTLM 值相同以作为跨域密钥。虽然信任账户不存在特权，但能允许我们以目标域的上下文进行信息枚举。
我们可以通过 Mimikatz 的 lsadump::trust /patch 命令导出信任密钥，也可以通过 DCSync 的方式提取。
如果使用 DCSync 的方式，我们需要首先获得受信域对象的 GUID。
我们能看到，值是相同的。因为该密钥每 30 天更换，所以我们往往选择 [Out] 中的。以 Dc04 的视角，我们也能看到跨域密钥是一致的。
然后，我们使用 Rubeus 为目标域的信任账户申请 TGT，信任账户的名称形式为对方域 (也就是我们当前所在的域)的域名 (非 FQDN)，并以 $ 结尾，看起来像主机账号。
rubeus.exe asktgt /user:white-bird$ /domain:med-deal.local /rc4:6dc6bd04edfb6b7298b9679531c9e2ca /nowrap
我们可以看到 TGT 请求成功了。创建一个牺牲会话，导入票据，便可以对目标域进行枚举了。
其他
除了信任密钥外，还有一些更加通用的跨域方法，包含但不局限于利用 SQL 链接、窃取正在访问当前域的目标域用户的令牌等。在 MSSQL 利用的内容中，我们知道 Med-deal 中 Srv02 部署的 MSSQL 实例与 Web02 所部署的 MSSQL 实例存在 SQL 链接关系。
AdminSDHolder
当我们支配了整个域甚至森林之后，我们想要在域内维持高特权。我们可以通过多种技术实现域内访问持久化，有些技术在之前内容已经涉及过了，例如对高特权的主机 (例如配置非约束委派的) 实现本地持久化、对高特权的主体施加 ACL (例如 GenericAll) 等。接下来，我们介绍一些尚未讨论过的域持久化技术。
AdminSDHolder 是一个具有一些默认安全权限的特殊 AD 容器，用作受保护的帐户和组 (如域管理员、企业管理员等) 的模板，以防止它们被有意或无意的修改，并确保他们的安全。
Account Operators
Backup Operators
Server Operators
Print Operators
Domain Admins
Replicator
Enterprise Admins
Domain Controllers
Read-only Domain Controllers
Scheme Admins
Administrators这样做的目的是确保高权限帐户具有更强的安全描述符，以防止非特权帐户更改他们的权限。称为安全描述符传播器 (SDProp) 的进程每小时运行一次，以强制将 AdminSDHolder 安全描述符应用到所有受保护的组及其成员。例如，我们赋予一用户对 Domain Admins 组 Full Control 的 DACL，大概在 60 分钟后，该 ACE 会消失。但是 AdminSDHolder 本身不被保护，因此如果我们修改对它的 DACL，这些更改将被复制到后续对象。因此，即使管理员在域管理员等特权群组上看到了恶意的 DACL 并将其删除，在 AdminSDHolder 的作用下，恶意 DACL 也会再次被还原以及重新应用。
万能钥匙
万能钥匙 (Skeleton key) 是一种持久化技术，只适用于域控制器，通过补丁域控制器上的 Lsass.exe 进程以劫持 NTLM 和 Kerberos 认证流程，以允许任何用户以一个相同的密码 mimikatz 进行认证，当然用户原本的密码也依旧有效。
在域控制上运行mimikatz
mimikatz misc::skeleton
然后，我们可以用任何账户以及密码 mimikatz 进行认证了。
恶意认证包
在之前的内容里，我们知道 AP/SSP 通过分析登陆数据来认证 Windows 用户，不同的 AP/SSP 对多种登陆过程以及认证协议提供支持。AP/SSP 以 DLL 形式存在，被 LSA 所加载和使用。常见的 AP/SSP 有 NTLM，Kerberos，WDigest，Credman 等。Mimikatz 提供恶意的SSP文件 mimilib.dll，此 SSP 在目标服务器上以明文形式记录本地登录、服务帐户和计算机帐户密码。我们可以通过自动和手动的方式来利用自定义SSP实现持久化。
自动
在 Cobalt Strike 上使用 mimikatz 命令及 misc::memssp 子选项实现植入后门 SSP。
mimikatz misc::memssp
之后可以在 C:\Windows\system32\mimilsa.log 查看明文登陆日志。
黄金证书攻击
背景
在具有 ADCS 的环境里，CA 的私钥在 CA 服务器上受到 DPAPI 或硬件解决方案 (HSM/TPM) 的保护。 此外，证书被发布在 NTAuthCertificates 森林对象，该对象定义了启用 AD 身份验证的 CA 证书。
总之，证书存在于 NTAuthCertificates 中的 CA 使用其私钥签署来自请求客户端的 CSR。
CA 私钥的安全性至关重要，如果私钥不受 TPM 或 HSM 等硬件解决方案的保护，则密钥将使用 DPAPI 加密并存储在 CA 服务器的文件系统中。如果攻击者能够对 CA 服务器实现提升特权下的代码执行，他们可以使用 Mimikatz 或 SharpDPAPI 等工具提取任何不受硬件保护的 CA 证书的私钥。因为用于签署已颁发证书的唯一密钥物件是 CA 的私钥，如果攻击者窃取这样的密钥，他们可以伪造能够进行身份认证的证书，这些伪造的证书可以用于域中的任何主体，并且只要 CA 证书有效，证书就会一直有效。此外，由于这些证书不是正常颁发过程的产物，因此 CA 不知道它们的创建，所以伪造的证书不能被撤销。
另外，在大型组织中，AD CS 服务可能被安装在单独的服务器上，而不是域控制器上。并且通常CA 服务器没有得到域控制器那样的高度安全性重视。因此，虽然只有域管理员可以访问与管理域控制器，但服务器管理员等权限略低一些的角色却可以访问 CA。虽然这可以看作是一种特权提升，但也是域持久化的一种方法。
利用
在我们的靶场里，Med-factory 域存在 ADCS 服务。因此，在 CA 上，也就是 Dc03 上，使用工具 SharpDPAPI (https://github.com/GhostPack/SharpDPAPI)来提取 CA 的私钥：
将私钥连同证书一起保存为 pem 格式文件，然后使用下面的 openssl 命令将其转换为 pfx 格式。
然后，我们使用工具 ForgeCert (https://github.com/GhostPack/ForgeCert) 来伪造证书，其中用户名需要是域内存在的。
ForgeCert.exe --CaCertPath C:\windows\tasks\cert.pfx --CaCertPassword 123123 --Subject "CN=User" --SubjectAltName "administrator@med-factory.local" --NewCertPath c:\windows\tasks\fake.pfx --NewCertPassword 123123
最后，使用 Rubeus 通过证书的方式请求用户的 TGT。
这样，我们可以通过窃取的私钥来伪造证书，从而获得特权用户的 TGT。
VS 黄金票据
黄金票据，即伪造的 TGT，与黄金证书，即伪造的证书，它们之间存在着明显的相似之处。以下几点是一些相似以及对比：
1：krbtgt 密钥和 CA 私钥都是对 AD 环境的安全至关重要的密码学物件，两者都可被滥用于模仿任意用户。
2：我们可以通过 DCSync 远程提取 krbtgt 密钥，但只有在 CA 服务器上获得提升特权的代码执行才可提取 CA 私钥。。
3：krbtgt 密钥可以相对容易地轮换，而轮换 CA 私钥则要困难得多。
第13章课后作业
练习
1：回顾一下，从黑盒的角度，我们是怎么一步步利用并最终攻陷 back_operator 用户的？
2：尝试制作其他服务的白银票据，并验证是否得到了对应的访问
3：用 Mimikatz 制作黄金票据与白银票据
4：在其他域制作一张钻石票据
5：理解跨域理论的内容
6：使用钻石票据的方法获得对 Dc02 的访问
7：无论使用 krbtgt 的方法还是信任密钥的方法，看看能否最终从 Dc02 移动到 white-bird 域的任意主机上？
8：复现入口信任以及出口信任的利用
9：复现黄金证书攻击