AS_REQ
cipher 是客户端用自身密码 NTLM 哈希加密的时间戳，cname 是请求的⽤户，其存在与否会导致返回包差异，可⽤于枚举域内⽤户名。
AS_REP
KDC 存储域中所有⽤户的密码 HASH，AS 接收到客户端请求后，会根据 KDC 中存储的密码来解密。验证成功后返回由 Client 密码 Hash 加密的 sessionkey-as 和用 KRBTGT HASH 加密的 TGT（含 sessionkey-as、TimeStamp 等）。
ticket：使⽤ krbtgt hash 加密，包含⽤户名/会话密钥和到期时间等信息.
enc-part：使⽤⽤户 hash 加密，包含会话密钥/TGT 到期时间和随机数（防重放）ticket ⽤于 TGS_REQ 的认证。是加密的，⽤户不可读取里面的内容。
黄金票据
AS_REP 中 ticket 的 enc-part ⽤ krbtgt 的 hash 加密，如果拥有 krbtgt 的 hash，就可以签发任意⽤户的 TGT 票据，即黄金票据，常用作权限维持。
当我们获得域控的控制权限后，有可能获取域内所有用户的 hash，和 krbtgt 的 hash。这时，由于⼀些原因导致失去对⽬标的控制权，但我们还有普通⽤户的权限，且 krbtgt 密码没有更改，可以利用 krbtgt ⽤户的 ntlm hash 制作黄金票据伪造 TGT，重新获取域控的管理权限。
黄金票据的条件要求：
1.域名称[AD PowerShell模块：（GetADDomain）.DNSRoot]
2.域的SID值[AD PowerShell模块：（GetADDomain）.DomainSID.Value]
3.域的KRBTGT账户NTLM密码哈希
4.伪造用户名（获取域的SID和KRBTGT账号的NTLM HASH的前提是已经拿到了域的权限）
TGS_REQ
客户端用用户 hash 解密 AS_REP 中的 enc-part 获得会话密钥，将用户名/时间戳进行加密，⽣成 authenticator 和 TGT 发送给 TGS。
ticket：实质上就是⼀张 TGT，客户端没有 krbtgt hash，故无法解密 TGT。
TGS_REP
TGS 收到 KRB_TGS_REQ 请求后，使用 krbtgt hash 解密 ticket 获取会话密钥，然后使⽤会话密钥解密 authenticator 获取⽤户名和时间戳进行身份验证。确认信息后，创建服务会话密钥（Service Session key）。
ticket：⽤对应服务密钥进⾏加密，包含服务会话密钥/⽤户名/到期时间等信息，本质上就是 ST。
enc-part：使⽤会话密钥加密的服务会话密钥
白银票据
TGS_REP 里的 ticket 的 encpart 使用服务的 hash 进行加密，如果我们拥有服务的 hash，就可以给我们自己签发任意用户的 TGS 票据，即白银票据。
相较于黄金票据，白银票据使用要访问服务的 hash，而不是 krbtgt 的 hash，由于⽣成的是 TGS 票据，不需要跟域控打交道，但是白银票据只能访问特定服务。
但是要注意的⼀点是，伪造的白银票据没有带有有效 KDC 签名的 PAC。如果将目标主机配置为验证 KDC PAC 签名，则银票将不起作用。
如果说黄金票据是伪造的 TGT，那么白银票据就是伪造的 ST。只需要知道 Server 用户的 Hash 就可以伪造出⼀个 ST，且不会经过 KDC，但是伪造的门票只对部分服务起作用。
白银票据的条件要求：
1.域名
2.域sid
3.目标服务器名
4.可利⽤的服务
5.服务账号的NTML HASH
6.需要伪造的用户名
金票和银票的区别
1.获取的权限不同金票：伪造的TGT，可以获取任意Kerberos的访问权限 银票：伪造的ST，只能访问指定的服务，如CIFS
2.认证流程不同金票：同KDC交互，但不同AS交互 银票：不同KDC交互，直接访问Server
3.加密方式不同金票：由krbtgt NTLM Hash加密银票：由服务账号NTLM Hash加密
两个扩展
在 TGS_REQ & TGS_REP 阶段，⽤户通过 AS_REP 拿到的 TGT 票据，去向 KDC 申请特定服务的访问权限，KDC 校验 TGT 票据，如果校验通过，会向⽤户发送⼀个 TGS 票据，之后用户再拿着 TGS 去访问特定的服务。这⼀阶段，微软引进了两个扩展 S4U2SELF 和 S4U2PROXY，是 TGS 的子协议
S4U2Self（Service-for-User-to-Self）
核心作用
允许服务代表⽤户向 KDC 申请⼀个针对服务自身的 TGS 票据，无需用户密码或哈希。
场景：用户通过非 Kerberos 方式（如表单登录、NTLM）验证到服务，但服务需用 Kerberos 协议代表⽤户操作。
流程
1.⽤户通过非Kerberos方式（如HTTP表单）登录服务。
2.服务以⾃身身份向KDC发起TGS_REQ请求，包含两个关键参数：
sname : 服务自身的SPN（如 HTTP/web-server.contoso.com ）
additional_ticket : 空（因⽤户未提供 Kerberos 凭据）。
特殊标识：KERB_KDCOPTION_CNAME_IN_ADDL_TKT标志，声明"代表用户申请票据"。
3.KDC 验证服务身份后：
生成⼀张⽤户授权票据（TGS）：
加密密钥：服务自身的密码哈希。
票据内容：包含目标用户的身份信息。
4.服务收到此TGS后，可代表用户执行后续操作（如调用S4U2Proxy）。
关键特性
- 无需用户凭证：仅需用户名（服务从非 Kerberos 登录中获取）。
- 票据用途受限：该 TGS 仅⽤于向本服务证明⽤户身份（不能直接访问其他服务）。
- 可转发性：票据需被标记为可转发（由 KDC 策略决定），才能用于 S4U2Proxy。
S4U2Proxy（Service-for-User-to-Proxy）
核心作用
允许服务 1 使用 S4U2Self 获得的用户 TGS，向 KDC 申请访问另⼀个服务（服务 2）的 TGS 票据，并代表⽤户访问服务 2。
场景：服务 1 需代表⽤户访问后端服务（如 SQL 数据库），但⽤户未直接向服务 2 认证。
流程
1.⽤户通过非Kerberos方式（如HTTP表单）登录服务。
2.服务以⾃身身份向KDC发起TGS_REQ请求，包含两个关键参数：
sname : 服务自身的SPN（如 HTTP/web-server.contoso.com ）
additional_ticket : 空（因⽤户未提供 Kerberos 凭据）。
特殊标识：KERB_KDCOPTION_CNAME_IN_ADDL_TKT标志，声明"代表用户申请票据"。3.KDC 验证服务身份后：
生成⼀张⽤户授权票据（TGS）：
加密密钥：服务自身的密码哈希。
票据内容：包含目标用户的身份信息。4.服务收到此TGS后，可代表用户执行后续操作（如调用S4U2Proxy）。
关键特性
无需用户凭证：仅需用户名（服务从非Kerberos登录中获取）。
票据用途受限：该TGS仅⽤于向本服务证明⽤户身份（不能直接访问其他服务）。
可转发性：票据需被标记为可转发（由KDC策略决定），才能用于S4U2Proxy。S4U 扩展完整工作流示例（IIS→SQL Server）
1.用户登录IIS：通过浏览器表单提交账号密码（非Kerberos）。
2.IIS调⽤S4U2Self：
以自身身份向KDC申请用户访问IIS的TGS（票据A）。3.IIS 调用S4U2Proxy：
使⽤票据A向KDC申请用户访问SQL Server的TGS（票据B）。4.IIS 访问SQL Server：
将票据B发送给SQL Server，SQL Server通过PA 验证⽤户权限并返回数据。安全与风险
提权风险：
若攻击者控制服务1，可伪造任意⽤户身份访问服务2（如域管理员访问域控）。
防御措施：
严格限制约束委派权限（仅允许必要服务）。
定期审计具备委派权限的服务账户。
漏洞利用：
MS14-068：通过篡改PAC提升权限（即使⽆委派权限）。
无约束委派（Unconstrained Delegation）：旧模式允许服务1获取用户TGT，风险更⾼。为何需要 S4U 扩展？
协议局限性：原⽣ Kerberos 要求⽤户主动发起认证，但在多层服务架构中，后端服务需代表前端⽤户认证。
现实需求：Web应用（IIS）、中间件等服务需⽆缝代理⽤户访问数据库、文件服务等资源。通过S4U2Self和S4U2Proxy，微软实现了非交互式委派认证，在维持 Kerberos安全性的前提下解决了服务链式调用问题。
PAC
Kerberos 的流程说明了如何证明 Client 是 Client 而不是由其他⼈冒充，但是没有声明 Client 有没有访问 Server 服务的权限，因为域中不同权限的⽤户能访问的资源是有区别的。所以微软为了结局这个问题在实现 Kerberos 时加⼊了 PAC 的概念，Privilege Attribute Certificate(特权属性证书)。
PAC 的本质与作用
是什么：PAC 是嵌入在 Kerberos 票据（TGT/ST）中的安全凭证，包含用户身份及权限信息：
用户 SID（唯⼀安全标识符），所属组 SID（用户组权限），登录时间、票据有效期等元数据
双重数字签名（防篡改核心）
为什么需要：服务端（Service）需验证⽤户的实际权限（而非仅认证身份），但自身无法解密 TGT（由 krbtgt 密钥保护）。 PAC 作为“权限说明书”，由 KDC 签名后传递给服务端用于最终授权决策。PAC 的安全设计精髓
双重签名机制：
PAC_SERVER_CHECKSUM → 防止服务端密钥泄露后伪造 PAC。
PAC_PRIVSVR_CHECKSUM → 防止 KDC 密钥泄露后伪造 PAC（需同时攻破两者）。
分层加密保护：
TGT 中的 PAC → 由 krbtgt 密钥保护。
ST 中的 PAC → 由服务端密钥保护（隔离不同服务权限）。
服务端零信任验证：即使解密 ST 成功，服务端仍要求 KDC 二次验证 PAC（防御中间人篡改）。攻击面与漏洞
MS14-068(CVE-2014-6324)：攻击者伪造 PAC 中的组 SID（如添加到域管理员组），因 KDC 未严格验证 PAC 签名导致权限提升。
补丁后：KDC 强制验证 PAC 签名完整性。
黄金票据攻击：获取 krbtgt 哈希后，可签发含任意 PAC 的 TGT（但需绕过服务端⼆次验证）。