一、Kerberos 协议完整流程
Kerberos 是 Active Directory 默认的认证协议，核心思想是用一个可信第三方（KDC，密钥分发中心，通常由域控上的 lsass.exe 承载）向客户端签发票据，服务端不直接与 KDC 通信，仅凭票据内容即可完成授权判断。整个协议由三次交换组成。
1.1 三次交换
Client KDC (AS + TGS) Service
| | |
|==== (1) AS-REQ (预认证) ========>| |
| [主体名 + 时间戳(用用户哈希加密)] | |
|<== (1) AS-REP ===================| |
| [TGT + 会话密钥] | |
| TGT 用 KRBTGT 账户密钥加密 | |
| | |
|==== (2) TGS-REQ (TGT + 认证符) ==>| |
|<== (2) TGS-REP ===================| |
| [服务票据 ST + 服务会话密钥] | |
| ST 用目标服务账户密钥加密 | |
| | |
|==== (3) AP-REQ (ST + 认证符) =====|=============================>|
|<== (3) AP-REP (双向认证) =========|<=============================|
| | |
- AS 交换（AS-REQ / AS-REP）：客户端用自身密码哈希加密一个时间戳完成预认证，KDC 验证通过后返回 TGT（Ticket Granting Ticket）。TGT 用
KRBTGT账户密钥加密，客户端无法解密其内容，只能原样持有并向 TGS 出示。 - TGS 交换（TGS-REQ / TGS-REP）：客户端将 TGT 连同一个用会话密钥加密的认证符（Authenticator，含时间戳）发给 KDC 的 TGS 部分，换取访问特定服务的服务票据（ST）。ST 用目标服务账户的密钥加密，因此只有该服务能解密。
- AP 交换（AP-REQ / AP-REP）：客户端向服务出示 ST 与认证符，服务用自身密钥解密 ST 校验合法性，可选返回 AP-REP 完成双向认证。
关键票据属性：默认 TGT 有效期 10 小时，可续期至 7 天；服务票据有效期由策略决定，通常较短。所有票据中的 EncTicketPart（加密前的票据本体）包含授权数据——这正是 PAC 的载体。
1.2 密钥类型与加密降级风险
Kerberos 支持多种加密类型（etype），其中两种在 AD 环境中最常见，且安全性差异巨大：
| 加密类型 | etype | 密钥推导方式 | Salt | 安全性 |
|---|---|---|---|---|
| RC4-HMAC | 23 | 密钥 = NT 哈希（MD4） | 无 salt | 弱，离线爆破可行 |
| AES-256-CTS-HMAC-SHA1-96 | 18 | PBKDF2-SHA1，4096 次迭代 | 有 salt（域名+用户名） | 强，抗爆破 |
RC4 的致命缺陷在于密钥即 NT 哈希，且无 salt 保护。攻击者通过 DCSync 拿到 krbtgt 的 NT 哈希后可直接用于伪造 RC4 金票；AES-256 则引入 salt 与高迭代次数，显著提高伪造门槛。这也是微软推动默认加密从 RC4 切换到 AES 的根本原因（详见 CVE-2022-37966）。
二、PAC（Privilege Attribute Certificate）详解
PAC 是微软对 Kerberos 的私有扩展（规范 MS-PAC），用于在票据内携带 Windows 授权数据。标准 Kerberos 票据只有身份标识，没有组与特权信息；AD 依赖 PAC 判断用户属于哪些组、拥有哪些权限。PAC 是票据伪造攻击的核心篡改目标。
2.1 PAC 缓冲区结构
+======================================================+
| PAC 结构 |
+------------------------------------------------------+
| LOGON_INFO | 用户SID、组RID列表、域SID、 |
| (KERB_VALIDATION) | ExtraSids、用户ID、账号标志 |
+---------------------+--------------------------------+
| CLIENT_INFO | 客户端账户名 + 签发时间戳 |
+---------------------+--------------------------------+
| UPN_DNS_INFO | UPN + DNS域名 (CVE-2021-42287 |
| | 后扩展为含 PAC_REQUESTOR) |
+---------------------+--------------------------------+
| SERVER_CHECKSUM | 整个PAC的签名(HMAC,KeyUsage=17)|
| | 签名Key = 服务账户密钥 |
+---------------------+--------------------------------+
| KDC_CHECKSUM | SERVER_CHECKSUM的签名 |
| | 签名Key = KRBTGT密钥 |
+---------------------+--------------------------------+
| PAC_ATTRIBUTES_INFO | 票据请求标志 (CVE-2021-42287) |
+---------------------+--------------------------------+
| PAC_REQUESTOR | 请求者SID (CVE-2021-42287) |
+======================================================+
七个必需缓冲区中，LOGON_INFO 携带实际授权数据（组 RID），而两个校验和缓冲区构成签名链：
- SERVER_CHECKSUM：对整个 PAC（除签名字段本身）计算 HMAC，使用的密钥是目标服务账户密钥。
- KDC_CHECKSUM：对 SERVER_CHECKSUM 的值再计算一次 HMAC，使用的密钥是 KRBTGT 密钥。
两层签名的 KeyUsage 均为 17。这种设计的目的是：服务只能用自身密钥验证 SERVER_CHECKSUM，但无法伪造 KDC_CHECKSUM（因为不知道 krbtgt 密钥），从而保证 PAC 由 KDC 签发且未被篡改。
2.2 不同票据类型的签名密钥映射
这是理解四种票据伪造的关键：
- Golden Ticket（TGT）：Server Key = KDC Key = KRBTGT 密钥。攻击者拥有 krbtgt 密钥即可同时伪造两个签名。
- Silver Ticket（TGS 服务票据）：Server Key = KDC Key = 目标服务账户密钥。攻击者只需服务账户哈希即可伪造完整签名链，无需 krbtgt。
这一差异直接决定了银票不需要 krbtgt 密钥，但只能针对单一服务。
三、四种票据类型详解
3.1 Golden Ticket（金票）— T1558.001
金票是最经典的票据伪造技术。攻击者通过 DCSync 等手段获取 KRBTGT 账户哈希后，完全离线伪造 TGT，将 PAC 中的组 SID 设为 Domain Admins（RID 512）等高权限组。
攻击者(持有krbtgt哈希)
|
| 1.离线构造EncTicketPart
| - 填入任意用户名/SID
| - PAC中添加Domain Admins(512)等高权限组
| - 有效期设为10年
|
| 2.用krbtgt密钥加密EncTicketPart -> 伪造TGT
| 用krbtgt密钥重签SERVER_CHECKSUM + KDC_CHECKSUM
|
| 3.PTT(票据传递)注入当前会话
|
v
任意服务(收到TGT后向TGS换ST)
* DC全程无AS-REQ记录,无票据签发日志
* 完全绕过KDC
OPSEC 特征：DC 上没有任何 AS-REQ/AS-REP 记录，票据有效期通常异常长（可达 10 年），PAC 与 AD 实际组成员关系不一致。
mimikatz 命令（RC4）：
mimikatz # kerberos::golden /domain:corp.local /sid:S-1-5-21-xxx \
/rc4:<krbtgt_ntlm_hash> /user:Administrator /id:500 /ptt
Rubeus 命令（AES-256）：
Rubeus.exe golden /krbkey:<aes256_key> /user:Administrator /domain:corp.local \
/sid:S-1-5-21-xxx /aes256 /ptt
3.2 Silver Ticket（银票）— T1558.002
银票针对服务票据（TGS）。攻击者获取某个服务账户（如 MSSQLSvc、CIFS、HTTP 对应的计算机账户或服务账户）的哈希后，直接伪造该服务的 ST。由于 ST 用服务账户密钥加密，而服务本身信任票据内容，因此不需要与 DC 通信，也不在 DC 留下任何票据请求日志。
攻击者(持有服务账户哈希)
|
| 1.离线构造EncTicketPart(服务票据本体)
| - 用服务账户哈希加密
| - PAC完全伪造(高权限组)
| - 用服务账户哈希签SERVER_CHECKSUM + KDC_CHECKSUM
|
| 2.直接向目标服务发起AP-REQ
| (跳过AS交换与TGS交换)
|
v
目标服务(用自身密钥解密ST,验证通过)
* DC无任何记录
* 仅对该特定服务有效
mimikatz 命令：
mimikatz # kerberos::golden /user:webuser /domain:corp.local \
/sid:S-1-5-21-xxx /target:sqlsrv.corp.local:1433 /service:mssql \
/rc4:<service_account_ntlm> /ptt
银票的局限是作用域单一（仅一个 SPN），但隐蔽性高——它在 DC 上是隐形的，只在目标服务侧留下访问痕迹。
3.3 Diamond Ticket（钻石票）
钻石票是金票的进化版，核心思路是基于合法 TGT 修改而非从零伪造。攻击者先通过正常 AS-REQ 获取一张合法 TGT，再用 krbtgt 密钥解密它，提取 PAC，向其中添加高权限组（Domain Admins RID 512）后重新签名、重新加密。
攻击者(持有krbtgt哈希 + 普通用户凭据)
|
| 1.正常AS-REQ -> 获取合法TGT (DC有AS-REQ/AS-REP记录!)
|
| 2.用krbtgt密钥解密TGT -> 提取EncTicketPart + PAC
|
| 3.修改PAC: 添加Domain Admins(512)等高权限组
|
| 4.用krbtgt密钥重签SERVER_CHECKSUM + KDC_CHECKSUM
|
| 5.重新加密EncTicketPart -> 新TGT
|
| 6.PTT注入
|
v
对域内任意服务有效
* DC上有"合法"的AS-REQ/AS-REP记录
* 票据结构完全合法,保留原始签名格式
与金票的核心区别：金票完全离线伪造，DC 无记录；钻石票基于一次真实的 AS-REQ 交换，DC 日志中存在看似正常的 TGT 请求记录。这使它在事件日志层面更难被发现。
Rubeus 命令：
Rubeus.exe diamond /krbkey:<aes256_key> /user:normaluser \
/password:Pass123 /enctype:aes /domain:corp.local /dc:dc01.corp.local \
/ticketuser:Administrator /ticketuserid:500 /nowrap
已知 PoC 局限（IoC）：当前公开实现将 PAC 组设为预定义的默认值组合 (520, 512, 513, 519, 518)。这组 RID 是一个稳定的特征码，防御方可直接据此检测——合法高权限用户的组成员关系通常不会精确等于这五个固定值。
3.4 Sapphire Ticket（蓝宝石票）
蓝宝石票是目前最隐蔽的变体。它不伪造 PAC，而是通过 S4U2Self + User-to-User（U2U）机制从 KDC 获取一个真实高权限用户的合法 PAC，再将其替换进攻击者持有的 TGT 中。
攻击者(持有krbtgt哈希 + 普通用户凭据)
|
| 1.正常AS-REQ -> 获取自己(低权限)的合法TGT
|
| 2.S4U2Self + U2U:
| 以"domainadmin"为目标,用自身TGT请求TGS
| KDC返回domainadmin的合法服务票据(含合法PAC!)
|
| 3.从domainadmin的服务票据中提取合法PAC
|
| 4.用krbtgt密钥解密自己的TGT -> 提取EncTicketPart
|
| 5.用domainadmin的合法PAC替换原TGT的PAC
|
| 6.用krbtgt密钥重签 + 重新加密 -> 新TGT
|
| 7.PTT注入
|
v
PAC与AD实际组成员关系完全一致
* 最难检测的变体
优势：PAC 不是伪造的，而是 KDC 真实签发的，与 AD 中该高权限用户的实际组成员关系一致。钻石票的固定组 IoC 在这里不适用。
Impacket 构造命令：
ticketer.py -request -impersonate 'domainadmin' \
-domain 'corp.local' -user 'normaluser' -password 'Pass123' \
-nthash <user_ntlm> -aesKey <aes256_key> \
-user-id 500 -domain-sid 'S-1-5-21-xxx' 'baduser'
四、四种票据对比表
| 特性 | Golden | Silver | Diamond | Sapphire |
|---|---|---|---|---|
| 伪造对象 | TGT | TGS（服务票据） | TGT（修改合法TGT） | TGT（替换PAC） |
| 所需密钥 | krbtgt 哈希 | 服务账户哈希 | krbtgt 哈希 + 用户凭据 | krbtgt 哈希 + 用户凭据 |
| 是否与 DC 通信 | 否 | 否 | 是（AS-REQ） | 是（AS-REQ + S4U2Self） |
| DC 日志 | 无记录 | 无记录 | 有 TGT 请求日志 | 有 TGT 请求日志 |
| PAC 来源 | 完全伪造 | 完全伪造 | 修改合法 PAC | 替换为合法 PAC |
| PAC 与 AD 一致性 | 不一致 | 不一致 | 不一致（默认组 IoC） | 一致（最难检测） |
| 作用域 | 全域任意服务 | 单一服务 | 全域任意服务 | 全域任意服务 |
| 隐蔽性 | 低 | 中 | 高 | 极高 |
从 Golden 到 Sapphire，攻击者付出的代价（所需凭据、所需与 DC 交互）递增，但隐蔽性也递增。这条演进线本质上是攻击者在与检测规则博弈：让伪造的票据越来越像合法票据。
五、检测方法
票据伪造检测的核心矛盾在于：金票和银票在 DC 上完全无日志，必须从服务端、关联异常与票据属性入手；而钻石票与蓝宝石票虽然有 AS-REQ 记录，但需要深入 PAC 层面比对才能识别。
5.1 关键 Windows 事件日志
| 事件 ID | 含义 | 异常信号 |
|---|---|---|
| 4768 | TGT 请求成功 | 异常 IP/时间、RC4 加密类型（0x17） |
| 4769 | 服务票据请求 | 异常 SPN、RC4 降级、敏感账户 |
| 4624 | 登录成功 | Kerberos 登录出现在敏感服务器 |
| 4672 | 特殊权限分配 | 特权用户从非 PAW 端点登录 |
| 4771 | TGT 请求失败（预认证失败） | 暴力枚举、Kerberoasting 前兆 |
5.2 高信号检测模式
+-------------------+ +-------------------+ +-------------------+
| 模式1: 4769无前置 | | 模式2: 票据有效期 | | 模式3: 不可能账户 |
| 4768 (金票离线) | | 异常(金票超长) | | 票据中账户AD不存在 |
+-------------------+ +-------------------+ +-------------------+
| | |
v v v
+-------------------+ +-------------------+ +-------------------+
| 模式4: 加密降级 | | 模式5: 权限不匹配 | | 模式6: 钻石票 |
| RC4突然出现 | | PAC组与AD实际不符 | | 固定组(520,512, |
| (0x17 etype) | | | | 513,519,518)IoC |
+-------------------+ +-------------------+ +-------------------+
- "4769 无前置 4768" 关联：服务票据请求（4769）出现，但此前短时间内同账户无 TGT 请求（4768）记录。这是金票离线伪造的最强信号——DC 从未签发过对应 TGT，却出现了使用该票据的访问。
- 票据有效期异常：金票常设为 10 年等超长有效期，远超默认 10 小时 + 7 天续期上限。
- 不存在或"不可能"的账户：票据中的账户在 AD 中不存在，或已禁用/删除的账户仍产生 Kerberos 访问。
- 加密降级异常：环境已强制 AES，却突然出现 RC4（etype 0x17）流量。
- 权限不匹配：PAC 中的组与 AD 中该账户实际组成员关系不符。
- 钻石票固定组 IoC：PAC 组精确等于
(520, 512, 513, 519, 518)。
5.3 PowerShell 检测脚本：4768/4769 关联
以下脚本关联 TGT 请求（4768）与服务票据请求（4769），找出无对应 TGT 记录的可疑服务票据使用，用于初步筛查金票离线伪造：
# Kerberos-GoldenTicket-Detect.ps1
# 检测模式1: 出现4769(服务票据请求)但无前置4768(TGT请求)的可疑访问
# 需在域控或集中日志服务器上运行,需管理员权限
param(
[int]$WindowMinutes = 30, # 关联时间窗口(分钟)
[int]$ResultLimit = 50 # 返回结果上限
)
$Start = (Get-Date).AddMinutes(-$WindowMinutes)
$FilterHash = @{
LogName = 'Security'
StartTime = $Start
}
# 收集4768(TGT签发)与4769(服务票据请求)事件
$TgtEvents = Get-WinEvent -FilterHashtable (@{
$FilterHash; Id = 4768
}) -ErrorAction SilentlyContinue
$StEvents = Get-WinEvent -FilterHashtable (@{
$FilterHash; Id = 4769
}) -ErrorAction SilentlyContinue
# 构建已签发TGT的账户集合(目标账户名)
$TgtAccounts = @{}
foreach ($evt in $TgtEvents) {
$acct = ($evt.Properties[0].Value).ToString()
if (-not $TgtAccounts.ContainsKey($acct)) {
$TgtAccounts[$acct] = $evt.TimeCreated
}
}
# 遍历4769,找出无前置4768的可疑请求
$Suspicious = foreach ($evt in $StEvents) {
$acct = ($evt.Properties[0].Value).ToString()
$spn = ($evt.Properties[5].Value).ToString()
$encType = [Convert]::ToInt32($evt.Properties[8].Value)
# RC4加密类型为0x17(23),AES为0x12(18)/0x11(17)
$isRc4 = ($encType -eq 23)
if (-not $TgtAccounts.ContainsKey($acct)) {
[PSCustomObject]@{
TimeCreated = $evt.TimeCreated
Account = $acct
ServiceSPN = $spn
ClientAddress = ($evt.Properties[6].Value).ToString()
EncType = if ($isRc4) { 'RC4-HMAC(降级!)' } else { "0x$($encType.ToString('x'))" }
EventId = 4769
Reason = '无前置4768 TGT签发记录'
}
}
}
if ($Suspicious) {
Write-Warning "发现 $($Suspicious.Count) 条可疑服务票据请求(可能为金票离线伪造):"
$Suspicious | Select-Object -First $ResultLimit |
Format-Table TimeCreated, Account, ServiceSPN, ClientAddress, EncType, Reason -AutoSize
} else {
Write-Output "[$(Get-Date)] 时间窗口内未发现4769无前置4768的可疑记录。"
}
脚本说明：它将时间窗口内所有 4768 事件的目标账户建成哈希表，再遍历 4769 事件，凡账户未出现在 TGT 签发集合中的即视为可疑。同时标注 RC4 降级（etype 23）。实际生产中应结合 SIEM（Splunk/ELK）做全量关联，并排除机器账户、跨域信任等正常场景。
5.4 钻石票检测要点
钻石票的检测需深入 PAC 层面：
- 比对票据 PAC 中的组 RID 与 AD 中该账户实际
memberOf是否一致；重点关注组 RID 是否精确等于(520, 519, 512, 513, 518)这一已知 PoC 默认值组合。 - 蓝宝石票因 PAC 来自真实高权限用户，上述方法失效，需结合行为分析（如低权限账户突然访问 Tier 0 资源）。
六、防御方案（按优先级排序）
优先级 实施难度 控制措施 核心作用
=================================================================
P1 低 KRBTGT密钥轮换 使泄露的旧哈希失效
P1 中 Credential Guard 凭据VBS隔离,防Mimikatz提取
P2 低 Protected Users组 禁用NTLM/DES/RC4,TGT 4h不可续
P2 低 AES强制执行 消除RC4降级攻击面
P2 高 分层管理模型 Tier0/1/2物理逻辑隔离
P3 中 gMSA 服务账户240位随机密码+自动轮换
P3 低 SPN清理 Domain Admins永不应有SPN
P3 低 蜜罐账户 检测Kerberoasting侦察
P3 中 PAC验证增强 Server2022+ FULL_PAC_SIGNATURE
6.1 KRBTGT 密钥轮换（P1）
入侵后重置 krbtgt 密钥两次可使所有已签发的金票/钻石票失效（第一次重置后旧密钥仍可用于续期，第二次重置才彻底废弃旧密钥）。常规轮换周期建议至少 180 天。重置后，所有已签发的 TGT 失效，用户需重新认证。
# 重置krbtgt账户密码(需Domain Admin + 在域控执行)
Set-ADAccountPassword -Identity krbtgt -Reset `
-NewPassword (ConvertTo-SecureString -AsPlainText -Force `
"$(New-Guid)$(Get-Random -Maximum 99999)")
# 注意: 重置后所有现有TGT失效, 建议在维护窗口执行, 至少重置两次
6.2 Credential Guard（P1）
Credential Guard 利用基于虚拟化的安全（VBS）将 LSA 机密隔离在一个独立的受保护进程（LSAIso）中。即使攻击者拿到 SYSTEM 权限，Mimikatz 也无法从 lsass.exe 内存中提取 NT 哈希与 Kerberos 票据，从源头切断票据伪造所需的凭据获取环节。
6.3 Protected Users 安全组（P2）
将高权限账户加入 Protected Users 全局组后，该账户的 Kerberos 行为被严格限制：
- 禁止 NTLM、DES、RC4 认证。
- TGT 有效期缩短至 4 小时且不可续期。
- 禁止使用摘要认证与 CredSSP 委派。
这直接压缩了金票的可利用窗口，并消除 RC4 降级路径。
6.4 AES 强制执行（P2）
在域功能级别与账户属性层面强制 AES：
# 为服务账户设置仅支持AES-256 + AES-128 (0x18 = 24 = 0x10|0x08)
Set-ADUser -Identity svc_sql -Replace @{
'msDS-SupportedEncryptionTypes' = 24
}
# 域级别: 确保域功能级别 >= 2012 R2, 并通过组策略禁用"允许旧版加密类型"
将 msDS-SupportedEncryptionTypes 设为 0x18（仅 AES-128 + AES-256），从协议层消除 RC4 降级可能。
6.5 分层管理模型（P2）
按 Tier 0（域控/ krbtgt / Domain Admins）、Tier 1（服务器）、Tier 2（工作站）实施物理与逻辑隔离：管理员账户不可跨层登录，Tier 0 管理员绝不登录 Tier 2 工作站。这样即使工作站被攻陷，也无法直接窃取 Tier 0 凭据，从而阻断票据伪造的凭据来源。
6.6 gMSA 与 SPN 治理（P3）
- gMSA：组托管服务账户使用 240 字符随机密码、30 天自动轮换、默认 AES，从源头消除服务账户弱口令与 Kerberoasting 风险。
- SPN 清理：
Domain Admins成员永远不应注册 SPN。任何 DA 的 SPN 都意味着其哈希可被 Kerberoasting 离线爆破，进而直接用于银票或更深层攻击。
# 检查Domain Admins中是否存在注册了SPN的账户(高危!)
Get-ADGroupMember -Identity "Domain Admins" | ForEach-Object {
$u = Get-ADUser $_.SamAccountName -Properties servicePrincipalName
if ($u.servicePrincipalName) {
Write-Warning "高危: DA账户 $($u.SamAccountName) 注册了SPN: $($u.servicePrincipalName)"
}
}
6.7 蜜罐账户与 PAC 验证增强（P3）
- 蜜罐账户：部署无业务用途、注册 SPN 的虚假账户并监控其 4769 事件，用于早期发现 Kerberoasting 侦察。
- PAC 验证增强：Windows Server 2022 及以上支持
FULL_PAC_SIGNATURE，强制 KDC 与服务对完整 PAC 进行签名验证，增加伪造 PAC 的难度。
七、工具对比
| 功能 | mimikatz | Rubeus | Impacket |
|---|---|---|---|
| Golden Ticket | 支持 | 支持 | 支持 |
| Silver Ticket | 支持 | 支持 | 支持 |
| Diamond Ticket | 不支持 | 支持 | 不支持 |
| Sapphire Ticket | 不支持 | 不支持 | 支持 |
| DCSync | 支持 | 不支持 | 支持 |
| LDAP 辅助 | 不支持 | 支持 | 不支持 |
| 平台 | Windows | Windows | 跨平台（Python） |
选型要点：mimikatz 适合在已获取 SYSTEM 的 Windows 主机上做票据注入与凭据提取；Rubeus 在 C#/.NET 生态下集成更友好，是钻石票的主要实现；Impacket 凭借跨平台特性，是蓝宝石票与离线票据操作的首选，常用于从 Linux 跳板发起攻击。
八、关键 CVE 时间线
票据伪造攻防的演进与微软补丁紧密相关，以下 CVE 勾勒出协议加固的历史脉络：
| 时间 | CVE / 编号 | 影响 |
|---|---|---|
| 2014 | MS14-068 | 允许普通用户伪造 PAC 提权至 Domain Admin，是 PAC 安全史上的里程碑漏洞 |
| 2021 | CVE-2021-42287 | 引入 PAC_REQUESTOR 与 PAC_ATTRIBUTES_INFO 缓冲区，KDC 可验证票据请求者身份，遏制匿名伪造 |
| 2022 | CVE-2022-37966 | Kerberos 默认加密从 RC4 切换为 AES， krbtgt 密钥迁移至 AES-256，大幅提高金票伪造门槛 |
| 2024 | CVE-2024-29056 | 调整 PAC 验证逻辑，进一步收紧 PAC 签名校验 |
| 2026 Q2（计划） | RC4 默认禁用 | 彻底关闭 RC4-HMAC etype 23，消除降级攻击面 |
从 MS14-068 到 RC4 默认禁用，可以看到一条清晰的趋势：微软正逐步关闭 PAC 伪造与加密降级的所有旁路，迫使攻击者走向钻石票、蓝宝石票这类更复杂、更依赖合法交互的变体——而后者也更易被行为分析捕获。
结语
Kerberos 票据伪造攻防是一场围绕"信任边界"的持续博弈。金票与银票代表"离线伪造、不留痕迹"的经典范式，检测重心在服务端与关联异常；钻石票与蓝宝石票代表"伪装合法、混入正常流量"的新一代范式，迫使防御者深入 PAC 层面比对成员关系。攻防双方都在向 AES、合法交互、PAC 一致性方向收敛。对防御方而言没有单一银弹——唯有 KRBTGT 轮换、Credential Guard、分层管理、AES 强制与行为关联检测的组合纵深，才能压缩票据伪造的生存空间。
免责声明
本文仅供网络安全技术研究、教学与授权渗透测试参考。文中涉及的所有攻击技术、命令示例与检测脚本仅应用于已获得书面授权的测试环境或自有环境。未经授权对任何真实生产系统、第三方网络或他人资产实施上述攻击行为，均可能违反《中华人民共和国网络安全法》《刑法》第二百八十五条（非法侵入计算机信息系统罪）及相关法律法规，作者不承担任何由此引发的直接或间接法律责任。读者应在严格遵守适用法律与组织安全政策的前提下使用本文内容。文中涉及的商标、产品名称归各自所有者所有。
浙公网安备 33010602011771号