内网初探-Kerberos认证

很早就听说过黄金票据需要 krbtgt 的 NTLM-HASH 和白银票据需要服务器的 NTLM-HASH 才能伪造，但是一直不知道为什么。学习内网渗透怎么能够对 kerberos 通信认证协议不了解呢？

先来介绍一下 NTLM 和一些基础概念吧！

NTLM

NTLM 是 NT LAN Manager 的缩写，NTLM 是基于挑战/应答的身份验证协议，是 Windows NT 早期版本中的标准安全协议。现常用于本地认证（客户端本地进程、服务端本地会话）

基本流程

客户端在本地加密当前用户的密码成为密码散列
客户端向服务器明文发送账号
服务器端产生一个 16 位的随机数字发送给客户端，作为一个 challenge
客户端用加密后的密码散列（也就是后面要提到的 NTLM Hash）来加密 challenge，然后返回给服务器，作为 response
服务器端将用户名、challenge、response 发送给域控制器
域控制器用这个用户名在 SAM 密码管理库中找到这个用户的密码散列，然后使用这个密码散列来加密 chellenge
域控制器比较两次加密的 challenge，如果一样那么认证成功，反之认证失败

Hash

LM Hash

LM Hash(LAN Manager Hash) 是 windows 最早用的加密算法，由IBM设计。LM Hash 使用硬编码秘钥的 DES，且存在缺陷。早期的Windows 系统如 XP、Server 2003 等使用LM Hash，而后的系统默认禁用了 LM Hash 并使用 NTLM Hash。

LM Hash的计算方式为：

转换用户的密码为大写，14 字节截断
不足 14 字节则需要在其后添加 0×00 补足
将 14 字节分为两段 7 字节的密码
以 KGS!@#$% 作为秘钥对这两组数据进行 DES 加密，得到 16 字节的哈希
拼接后得到最后的 LM Hash。

NTLM Hash

为了解决 LM Hash 的安全问题，引入了 NTLM 协议

Windows 2000 / XP / 2003 在密码超过 14 位前使用 LM Hash，在密码超过 14 位后使用 NTLM Hash。而之后从 Vista 开始的版本都使用NTLM Hash。

NTLM Hash 的计算方法为：

将密码转换为16进制，进行 Unicode 编码
基于 MD4 计算哈希值

NTLM Hash 与 Net-NTLM Hash 的区别

这是一个概念上特别容易混淆的点，也是理解 NTLM Relay 的基础：

	NTLM Hash	Net-NTLM Hash
是什么	密码的哈希值，存储在 SAM/ntds.dit 中	认证过程中网络传输的 Challenge-Response
计算方式	`MD4(Unicode(Password))`	`HMAC-MD5(NTLM_Hash, Challenge + Blob)`
能否直接登录	可以（Pass The Hash）	不可以，只能离线爆破
存储位置	本地 SAM 或 ntds.dit	仅存在于网络流量中
攻击方式	直接用于 PTH 或 Relay 中的加密	捕获后离线爆破（hashcat）或 Relay 重放

关键认知：

NTLM Hash 是静态的——只要密码不变，NTLM Hash 永远不变
Net-NTLM Hash 是动态的——每次认证产生的 Response 都不同（因为 Challenge 不同）

NTLM Relay 做的是：不爆破 Net-NTLM Hash，直接重放整个 Response

NTLM 认证协议的版本：NTLMv1 与 NTLMv2

NTLM 认证协议有 NTLMv1 和 NTLMv2 两个版本。上一节讲的三条消息（Type 1 / Type 2 / Type 3）是两个版本共同的消息结构——NTLMv1 和 NTLMv2 的区别体现在 Type 3（AUTHENTICATE_MESSAGE）中 Response 的构造方式。NTLMv1 已基本淘汰（LMCompatibilityLevel >= 3 的 Windows 默认使用 NTLMv2）：

版本	加密算法	Hash 长度	MIC 保护	安全性
NTLMv1	DES + MD4	48 bytes (24+24)	无	弱，易爆破
NTLMv2	HMAC-MD5	Variable（含 Blob）	有（可选/强制）	较强

NTLMv2 Response 的内部结构

理解 NTLMv2 Response 的内部结构，是理解 Relay 攻击为何可行以及 MIC 机制如何防御的核心：

NTLMv2 Response = NTProofStr (16 bytes) + Blob (variable)

NTProofStr:
  HMAC-MD5(ResponseKeyNT, ServerChallenge + Blob)
  其中 ResponseKeyNT = NTLM Hash

Blob 包含多个 AV_PAIR（Attribute-Value Pair）：
  - MsvAvTimestamp       （客户端时间戳）
  - MsvAvNbComputerName   （客户端机器名）
  - MsvAvNbDomainName     （客户端域名）
  - MsvAvDnsComputerName  （DNS 计算机名）
  - MsvAvDnsDomainName    （DNS 域名）
  - MsvAvTargetName       （目标 SPN，如 cifs/fileserver）
  - MsvAvChannelBindings  （Channel Binding Token，可选）
  - MsvAvFlags            （标志位，指示 MIC 是否存在）

关键细节：NTLMv2 规范中，客户端在 AV_PAIR 中声明的 MsvAvTargetName（SPN）由客户端自行填写。客户端以为它在和谁通信，就在这个字段里写谁的名字。但服务端是否验证这个 SPN 和自己是否匹配，是服务端的事。许多服务（尤其是 LDAP 在协商签名模式下）不严格验证这个字段——这正是跨协议中继可行的根本原因之一。

什么是 SSP：Windows 认证的可插拔架构

Windows 设计了一套名为 SSPI（Security Support Provider Interface） 的认证框架。SSPI 本身只定义接口，具体的认证协议由各个 SSP（Security Support Provider） 实现。可以理解为：SSPI 是”插座”，SSP 是”插头”——应用程序只需要调用 SSPI 的通用函数，Windows 会根据协商结果自动选择对应的 SSP 来实际处理认证。

Windows 内置了几个主要的 SSP：

SSP 名称	DLL 文件	实现的协议
NTLM SSP	`msv1_0.dll`	NTLM 认证（Challenge/Response）
Kerberos SSP	`kerberos.dll`	Kerberos 认证（Ticket-based）
Negotiate SSP	`secur32.dll`	先尝试 Kerberos，失败则回退到 NTLM
Digest SSP	`wdigest.dll`	HTTP Digest 认证
Schannel SSP	`schannel.dll`	TLS/SSL 认证

应用程序发起认证时，通常使用 Negotiate SSP——它会按照”Kerberos → NTLM”的顺序尝试，这就是为什么同一套代码既可以在域内用 Kerberos 也可以用 NTLM。

应用程序（如 SMB 服务、IIS、SQL Server）
    │
    ▼
SSPI（通用接口：AcquireCredentialsHandle / InitializeSecurityContext）
    │
    ├── Negotiate SSP（协商选择）
    │       │
    │       ├── Kerberos SSP (kerberos.dll)
    │       └── NTLM SSP (msv1_0.dll)
    │
    ▼
LSASS.exe（加载各 SSP 的 DLL）
    │
    ▼
Netlogon (netlogon.dll) —— 负责与域控通信

Netlogon：服务端与域控的桥梁

Netlogon 是 Windows 的一个核心服务（netlogon.dll，由 LSASS 加载），它负责域成员机器与域控制器之间的安全通信。在 NTLM 认证的语境中，Netlogon 承担着一个关键角色：帮助服务端向域控验证用户凭据。

当服务端收到客户端的 NTLM Type 3（AUTHENTICATE_MESSAGE）后，服务端并不在本地验证——本地没有用户的 NTLM Hash。服务端通过 Netlogon RPC 调用 NetrLogonSamLogon 方法，将 Type 1、Type 2、Type 3 全部发送给域控，由域控完成最终验证。域控知道用户的 NTLM Hash，用同样算法计算 Response 并比对，然后将验证结果返回给服务端。

客户端（Client）           服务端（Server）               域控（DC）
   │                           │                            │
   │ 1. Type 1 (Negotiate)     │                            │
   │──────────────────────────>│                            │
   │                           │                            │
   │ 2. Type 2 (Challenge)     │                            │
   │<──────────────────────────│                            │
   │                           │                            │
   │ 3. Type 3 (Authenticate)  │                            │
   │──────────────────────────>│                            │
   │                           │                            │
   │                           │ 4. Netlogon RPC            │
   │                           │    NetrLogonSamLogon       │
   │                           │    (转发 Type 1/2/3)       │
   │                           │───────────────────────────>│
   │                           │                            │
   │                           │    DC 用 NTLM Hash 计算    │
   │                           │    Response 并比对          │
   │                           │                            │
   │                           │ 5. 验证结果（通过/失败）     │
   │                           │<───────────────────────────│
   │                           │                            │
   │ 6. 认证通过，服务端         │                            │
   │    为 Client 创建会话      │                            │
   │<──────────────────────────│                            │

这对 Relay 攻击的意义：

服务端在整个认证过程中只是一个”转发者”——它自己不持有用户的密钥，只负责把 Type 1/2/3 传给域控验证。攻击者截获了 Client 发给 Server-A 的 Type 3 之后，可以把它提交给 Server-B。Server-B 同样会通过 Netlogon 把这些数据发给域控，域控同样会验证——因为它看到的是一个合法的（只是本应发给 Server-A 的）认证请求。Netlogon 不检查”这个认证请求原本是发给谁的”——这恰恰是中继攻击能够成功的深层原因之一。

Kerberos

Kerberos 是一种基于加密 Ticket 的身份认证协议

有一些概念还是要先记住的，不然后面看不懂：

Key Distribution Center: 简称 KDC，密钥分发中心，默认安装在域控。

Authentication Service: 身份验证服务，简称 AS，用于 KDC 对 Client 的认证

Ticket Granting Service: 票据授予服务，简称 TGS 用于 KDC 向 Client 和 Server 分发 Session Key

Session Key【AS|TGS】: 对应服务产生的临时密钥

PAC ：PAC（Privilege Attribute Certificate）特权访问证书。包含的是用户的 SID、用户所在的组等一些信息。kerberos 认证协议解决了 “Who am I?” 的问题，但是没有解决 “What can I do?” 的问题。于是就引入了 PAC 来解决 “What can I do?” 的问题

TGT：由 KDC 使用 krbtgt 账户的长期密钥加密生成，内部包含 Session-Key AS、Client-info、PAC、票据生命周期等信息，用于后续向 TGS 申请服务票据。

ST：Service Ticket，服务票据。对于特定的服务有特定的票据。一张服务票据只对一类服务有效。客户机只有拥有服务票据才能够与对应的服务器进行通信

三个阶段

这里提到用 NTLM HASH 做加密验证是 RC4 的场景，下面会提到

认证过程主要有三个阶段，下面这张图就比较清晰的展示了主要流程

AS_REQ & AS_REP

此阶段是 Client 和 AS 的认证获得 TGT

AS_REQ:

当域内的某个客户机试图访问域内的某个服务，需要输入用户名和密码，此时客户端本机的 Kerberos 服务会向 KDC 的 AS 认证服务发送一个 AS_REQ 认证请求。凭证是客户机的哈希值 NTLM HASH 加密时间戳、Client-info（用户名）、Server-info 等信息

AS_REP：

AS 收到后先向 AD 请求，查询是否有这个客户，有的话就取出它的 NTLM-Hash, 并对 AS_REQ 中的加密时间戳进行解密，如果解密成功，则证明客户端的密码是正确的，如果时间戳在 5 分钟内，则预认证成功。然后 AS 会产生一个临时的 Session-Key AS(临时密钥)，并使用客户端 Client 的 NTLM-Hash 加密 Session-Key AS 作为响应包的一部分，此 Session-Key 用来保证客户端和 KDS 之间通信的安全，另外一部分内容就是 TGT。

我们来整理一下客户收到的响应包：客户自己 NTLM-HASH 加密的 Session-Key AS、TGT(包含了 Krbtgt NTLM-HASH 加密的 Session-Key AS、时间戳、Client-info、PAC)

TGS_REQ & TGS_REP

此阶段是客户端与 TGS 进行认证，获得 ST

TGS_REQ:

客户端收到 AS_REP 后会用自己的 NTLM-Hash 恢复 Session-Key AS，然后本地缓存此 TGT 和 Session-Key AS。

如果 Client 需要访问某台服务器上的服务，它需要向 TGS 发送 TGS_REQ 请求获得对应的 ST

TGS_REQ 包含这些内容：用 Session-Key AS 加密当前的时间戳、Client-info、Server-info，TGT

TGS_REP:

TGS 收到请求后会用 krbtgt 用户的 NTLM-Hash 解密 TGT 中的内容，得到 Session-key AS、时间戳、Client-info 。然后先比较两次的时间戳，如果时间相隔太久，就需要重新进行 AS 认证。还会将两部分的 Clinet-info 如果两者相等的话，再判断有无访问服务的权限。最后认证成功 TGS 会生成一个 Session-Key TGS，并用 Session-key AS 加密 Session-key TGS 作为相应的一部分。另一部分就是使用 Server 的 NTLM-Hash 加密 Session-key TGS、以及 Client-info 等数据生成 ST。

TGS_REP 包括：Session-Key AS 加密的 Session-key TGS、ST（包含 Server 的 NTLM-Hash 加密的 Session-key TGS、Client-info 等）

SE_REQ & SE_REP

此阶段是 Client 和 Server 的认证

SE_REQ:

客户端 Client 收到 TGS_PEP，用缓存的 Session-Key AS 将 Session-key TGS 解密出来，然后使用 Session-key TGS 加密 Client-info、时间戳等信息作为一部分内容。然后将 ST 一起发送给 Server

SE_REQ发送内容：Session-Key TGS 加密的 Client-info 和时间戳、ST

SE_REP:

服务端用自身的 NTLM-Hash 将 ST 解密，得到 Session-key TGS, 然后用 Session-key TGS 解密得到 Client-info 、时间戳等信息，比对这些信息。时间戳有效时间一般为 8 小时。服务器使用自身密钥解密 ST，得到 Session-Key TGS 和其中包含的 PAC。PAC 实际上由 KDC 在签发 TGT 时生成，并会被复制到 Service Ticket 中。服务器可以直接验证 PAC 的签名，也可以通过 Netlogon RPC 向域控制器请求 PAC 验证。验证成功后，服务器根据 PAC 中包含的用户 SID、组 SID、SIDHistory 等信息构建访问令牌（Access Token），再与目标资源的 ACL 进行比较，从而决定是否允许访问。

但是在有些服务中并没有验证 PAC 这一步，这也是白银票据能成功的前提，因为就算拥有用户的 Hash，可以伪造 TGS，但是也不能制作 PAC，PAC 当然也验证不成功

Kerberos 加密类型

Kerberos 支持多种加密算法，KDC 和客户端会协商使用双方都支持的最高强度加密类型：

用户密码（明文）
    │
    ├── MD4(Unicode(password)) ──────→ RC4-HMAC 密钥（= NTLM Hash）
    │
    ├── PBKDF2(HMAC-SHA1, password, salt, 4096) → AES128-CTS-HMAC-SHA1-96
    │
    └── PBKDF2(HMAC-SHA1, password, salt, 4096) → AES256-CTS-HMAC-SHA1-96

加密类型	密钥长度	EType 编号	现状
DES-CBC-CRC	56 bit	1	已禁用（Windows 7 / 2008 R2 起默认禁用）
DES-CBC-MD5	56 bit	3	已禁用
RC4-HMAC	128 bit	23	仍广泛使用，但现代环境优先 AES
AES128-CTS-HMAC-SHA1-96	128 bit	17	支持
AES256-CTS-HMAC-SHA1-96	256 bit	18	推荐，现代域控默认优先使用

关键事实：

RC4 密钥在数值上等于 NTLM Hash：MD4(Unicode(Password))。这是 OverPass The Hash 和 Pass The Key（RC4 变体）能够工作的核心原因。
AES 密钥需要从明文密码派生：无法从 NTLM Hash 推导出 AES Key。如果攻击者只拿到了 NTLM Hash，只能用 RC4 加密类型申请 TGT。
现代域控默认优先选择 AES：KDC 收到 AS-REQ 时，如果请求的加密类型同时包含 RC4 和 AES，会优先用 AES 加密 TGT 的 Session Key。
使用 RC4 产生的流量不是”隐形”的：在 AES 优先的环境中，单独的 RC4 认证请求本身就是异常信号，可能被检测系统标记。

这也是为什么拿到 NTLM Hash 后，直接用 RC4 做 OverPass The Hash 虽然能用，但在蓝队眼中不等于隐形。Pass The Key 使用 AES Key 更隐蔽，但需要先拿到 AES Key（途径更少，通常只有 sekurlsa::ekeys 或 ntds.dit）。

黄金票据

学习了上面的 Kerberos 认证，我们仔细思考就会发现，如果我们能够获取 Krbtgt 的 NTLM-Hash，那么我们可以伪造 TGT，要记得 TGT 是用 Krbtgt 的 NTLM-Hash 加密了 Session-Key AS、时间戳、Client-info。虽然我们并不知道 Session-Key AS 是什么，但这并不重要，因为 Session-Key AS 是一个临时生成的密钥，我们也可以给个随机的内容，在后面认证过程中并不需要。而 Client-info 便是我们要伪造的内容。在 Kerberos 认证的第二阶段过程中我们发送的是 Session-Key AS 加密当前的时间戳、Client-info、Server-info，Session Key 并不需要担心，而 TGT 也已经让我们伪造好了。也就达成了够绕过对任意用户的账号策略（还记得第一阶段的认证吗？需要我们输入用户名和密码，返回的是对应用户的 TGT），让用户成为任意组的成员，可用于 Kerberos 认证的任何服务。

黄金票据可以当做一个安装在普通域成员主机上的连接到域控的后门

伪造黄金票据还需要以下信息：

需要伪造域管理员用户名
完整的域名
域 SID
krbtgt 的 NTLM HASH

可以使用 msf 的 meterpreter 中的 kiwi

首先导入 kiwi

meterpreter > load kiwi

然后输入

golden_ticket_create -d whoamianony.org -k 6be58bfcc0a164af2408d1d3bd313c2a -s S-1-5-21-1315137663-3706837544-1429009142 -u administrator -t /root/krbtgt.ticket
# golden_ticket_create -d 域名 -k krbtgt用户的Hash -s 域sid -u 需要伪造的域管理员用户名 -t /root/krbtgt.ticket

kerberos_ticket_list # 查看本地储存的票据
kerberos_ticket_use /root/krbtgt.ticket # 将票据注入内存

白银票据

我们只需要知道对应的 Server 用户的 NTLM Hash 就可以伪造出 ST。Server 的 NTLM-Hash 加密的 Session-key TGS、Client-info 等，虽然我们并不知道 Session-key TGS，这个临时密钥，但也不重要，我们可以自己创造一个 Session-key TGS，填好 Client-info，就可以伪造出 ST。把 ST 和自己创造的 Session-Key TGS 加密的 Client-info 和时间戳提供给服务器。就可以访问了。

制作白银票据需要以下信息：

域名
域 SID
目标服务器的 FQDN （全限定域名，同时带有计算机名和域名）
可利用的服务
服务账号的 NTLM 哈希值
要伪造的用户名

Mimikatz

kerberos::golden /domain:域名 /sid:域sid /target:全限定域名 /service:服务名 /rc4:服务账号的NTLM-HASH /user:伪造的用户名 /ptt

NTLM Hash 与 Kerberos Key 的关系

理解这个关系是理解后续各种 Pass-the-X 攻击的关键。

从同一个密码派生出不同的密钥

Windows 并不会把用户密码直接存在某个地方，而是从密码派生出多种形式的密钥，用于不同的认证场景：

用户密码（明文）
    │
    ├─── MD4(Unicode(password)) ──────────────→ NTLM Hash
    │                                              │
    │                                              ├── 用于 NTLM 认证
    │                                              │
    │                                              └── 可直接作为 Kerberos RC4 密钥
    │
    └─── PBKDF2 / 其他 KDF ──────────────────→ Kerberos Long-term Keys
                                                   │
                                                   ├── RC4-HMAC  （= NTLM Hash，相同值）
                                                   ├── AES128-CTS-HMAC-SHA1-96
                                                   └── AES256-CTS-HMAC-SHA1-96

关键结论：

NTLM Hash 和 Kerberos RC4 Key 在数值上完全相同，都等于 MD4(Unicode(password))
区别仅在用途：前者用于 NTLM 的 Challenge-Response，后者用于 Kerberos 的 AS-REQ 加密时间戳
AES Key 则通过不同的密钥派生函数从明文密码计算，无法从 NTLM Hash 直接得到

这意味着：拿到 NTLM Hash 就等于同时拿到了 Kerberos RC4 Key，可以直接参与 Kerberos 认证流程。

Windows 存储的密钥形式

域控上的 ntds.dit 以及本地机器的 SAM 数据库中，为每个用户存储了多种密钥：

密钥类型	存储位置	用途
NTLM Hash	SAM / ntds.dit	NTLM 认证、Kerberos RC4
Kerberos AES-128 Key	ntds.dit	Kerberos AES 加密
Kerberos AES-256 Key	ntds.dit	Kerberos AES 加密（优先）

本地机器（非域控）的 SAM 只存储 NTLM Hash，没有 AES Key——因为本地账户不参与 Kerberos 认证。

Pass-the-X 技术族

理解了密钥派生关系之后，各种 Pass-the-X 技术的本质就很清晰了：它们都是用不同形式的凭据绕过需要输入明文密码的步骤，直接完成认证。

技术	传递的凭据	认证协议	最终目的
Pass The Password	明文密码	任意	正常登录
Pass The Hash	NTLM Hash	NTLM	以目标账户身份访问资源
OverPass The Hash	NTLM Hash（充当 RC4 Key）	Kerberos	申请 TGT，转入 Kerberos 体系
Pass The Key	Kerberos AES/RC4 Key	Kerberos	申请 TGT，转入 Kerberos 体系
Pass The Ticket	TGT 或 ST	Kerberos	使用已有票据直接访问服务
Pass The Certificate	证书 + 私钥	PKINIT	通过证书预认证申请 TGT

Pass The Hash（PTH）

原理：NTLM 认证的 Challenge-Response 阶段，客户端用 NTLM Hash 对 Challenge 加密。只要有 Hash，不需要明文密码即可完成这一步。

使用场景：目标服务回退到 NTLM 认证时（IP 访问、非域成员、跨域等）。

局限：只能用于 NTLM 认证，对强制要求 Kerberos 的服务无效。

OverPass The Hash（也叫 Pass The Key / RC4 变体）

原理：NTLM Hash 与 Kerberos RC4 Key 数值相同。将 NTLM Hash 直接送入 AS-REQ 的预认证字段（用它加密时间戳），KDC 用同样的值解密验证，从而申请到 TGT。

效果：得到 TGT 之后整个认证流程转入 Kerberos，后续可以申请任意服务票据，不再依赖 NTLM。

与 PTH 的核心区别：

PTH           → Hash → NTLM Challenge-Response → 访问单个目标服务
OverPTH/PTK   → Hash/AES Key → Kerberos AS-REQ → 申请 TGT → 访问任意服务

Pass The Key（PTK）

与 OverPass The Hash 目的完全相同，区别在于使用的是 AES-256/AES-128 Key 而不是 RC4（NTLM Hash）。

优势：现代域环境中域控默认优先使用 AES 加密，PTK 使用 AES Key 产生的流量与正常认证流量完全一致，NTLM Hash 作为 RC4 Key 使用时在日志中仍然可见（RC4 在现代环境中本身就是异常信号）。

获取 AES Key：需要从 ntds.dit 或通过 mimikatz sekurlsa::ekeys 提取。

Pass The Ticket（PTT）

原理：不需要任何密钥，直接将内存中导出的 TGT 或 ST 注入当前会话。

两种票据的区别：

票据类型	适用范围	有效期（默认）
TGT	可申请任意服务的 ST	10 小时
ST	只能访问特定服务	10 小时

黄金票据和白银票据是这个技术的特殊形式——不是导出真实票据，而是用掌握的长期密钥（krbtgt Hash 或服务账户 Hash）伪造票据后注入。

Pass The Certificate（PTC）

原理：Kerberos 支持 PKINIT 扩展，允许用证书代替密码完成预认证。客户端用私钥对请求签名，KDC 用证书中的公钥验签，通过后颁发 TGT。

使用场景：在 ADCS（Active Directory Certificate Services）攻击中，攻击者通过 ESC 系列漏洞申请到目标账户的证书，再用 PTC 将证书兑换成 TGT。

特点：只要证书有效期内，即使目标账户改了密码，证书仍然可以申请 TGT。

从协议层面看，PTC 可以理解为「Pass The Private Key」更准确，因为真正起身份认证作用的是证书对应的私钥，证书只是公钥和身份信息的载体。攻击者只拿到 .cer（只有公钥）是没用的，必须拿到包含私钥的 .pfx/.p12 或能够使用私钥完成签名。

以上六种技术的关系可以用密钥形式来理解：

明文密码
  │
  ├── 直接使用 ──────────────────────────────→ Pass The Password
  │
  ├── MD4 → NTLM Hash
  │             │
  │             ├── NTLM 协议使用 ───────────→ Pass The Hash
  │             │
  │             └── 作为 RC4 Key → Kerberos → OverPass The Hash
  │
  ├── KDF → AES Key
  │             │
  │             └── Kerberos 预认证 ─────────→ Pass The Key
  │
  ├── 已有 TGT / ST
  │             │
  │             └── 直接注入会话 ────────────→ Pass The Ticket
  │
  └── 证书 + 私钥
                │
                └── PKINIT 预认证 ───────────→ Pass The Certificate