文章总结： 本文详细解析了Kerberos认证协议的三个核心阶段，包括ASREQ与ASREP的TGT获取、TGSREQ与TGSREP的服务票据申请以及AP-REQ与AP-REP的双向身份验证流程。文章阐述了客户端、KDC和应用服务器之间的密钥交换机制，强调了票据加密与时间戳验证在安全认证中的关键作用，为理解内网渗透中的票据传递攻击提供了理论基础。建议安全人员掌握此协议原理以进行有效的攻防实践。 综合评分： 78 文章分类： 内网渗透,红队,渗透测试,安全建设,实战经验

【内网渗透】票据传递基础-1

原创

d0n9x1e d0n9x1e

蝉SEC

2026年1月30日 00:25 江苏

Kerberos协议

#

kerberos是一种计算机网络认证协议，他能够为网络中通信的双方提供严格的身份验证服务，确保通信双方身份的真实性和安全性。不同于其他网络服务，kerberos协议中不是所有的客户端向想要访问的网络服务发起请求，他就能够建立连接然后进行加密通信。而是在发起服务请求后必须先进行一系列的身份认证，包括客户端和服务端两方的双向认证，只有当通信双方都认证通过对方身份之后，才可以互相建立起连接，进行网络通信。即kerberos协议的侧重在于认证通信双方的身份，客户端需要确认即将访问的网络服务就是自己所想要访问的服务而不是一个伪造的服务器，而服务端需要确认这个客户端是一个身份真实，安全可靠的客户端，而不是一个想要进行恶意网络攻击的用户。

kerberos协议中三个不同的参与者

客户：寻求提供其身份的实体
应用服务器（AP）：客户端或用户想要访问的服务
密钥分发中心（KDC）：颁发票据的可信第三方

几乎所有操作系统都支持 Kerberos，包括 Apple OSX/iOS 以及许多 UNIX 和 Linux 发行版。然而，Microsoft Active Directory是使用最广泛的 Kerberos 实现。

在 Active Directory 中，每个域控制器充当 KDC 并提供两项核心服务：

身份验证服务 (AS) — 对客户端进行身份验证并向其颁发票据
票证授予服务 (TGS) — 接受经过身份验证的客户端并向其颁发票证以访问其他资源，门票采用对称加密技术。某些用户密码用于加密和签署特定票证，但 Kerberos 安全性的根源是只有颁发票证的受信任第三方知道的密钥。

kerberos认证的流程

kerberos中存在的三个角色，只要是发生了两两之间的通信，那么都需要先进行身份的认证

ASREQ & ASREP

该阶段是 Client 和 AS 的认证，通过认证的客户端将获得 TGT 认购权证。当域内某个客户端用户 Client 视图访问域内的某个服务，于是输入用户名和密码，此时客户端本机的
Kerberos 服务会向 KDC 的 AS 认证服务发送一个 AS_REQ 认证请求。请求的凭据是 Client 的哈希值 NTLM-Hash 加密的时间戳以及 Client-info、Server-info 等数据，
以及一些其他信息。

① 客户端用户向KDC以明文的方式发起请求。该次请求中携带了自己的用户名，主机IP，和当前时间戳；

② KDC当中的AS（Authentication Server）接收请求（AS是KDC中专门用来认证客户端身份的认证服务器）后去kerberos认证数据库中根据用户名查找是否存在该用户，此时只会查找是否有相同用户名的用户，并不会判断身份的可靠性；

③ 如果没有该用户名，认证失败，服务结束；如果存在该用户名，则AS认证中心便认为用户存在，此时便会返回响应给客户端，其中包含两部分内容：

第一部分内容称为TGT，他叫做票据授予票据，客户端需要使用TGT去KDC中的TGS（票据授予中心）获取访问网络服务所需的Ticket（服务授予票据），TGT中包含的内容有kerberos数据库中存在的该客户端的Name，IP，当前时间戳，客户端即将访问的TGS的Name，TGT的有效时间以及一把用于客户端和TGS间进行通信的Session_key(CT_SK)。整个TGT使用TGS密钥加密，使用 KDC 一个特定账户的 NTLM-Hash 对 Session-keyAS、时间戳、Client-info 进行的加密。这个特定账户就是创建域控时自动生成的Krbtgt 用户，然后将这两部分以及 PAC 等信息回复给 Client，即 AS_REP。

第二部分内容是使用客户端密钥加密的一段内容，其中包括用于客户端和TGS间通信的Session_key(CT_SK),客户端即将访问的TGS的Name以及TGT的有效时间，和一个当前时间戳。该部分内容使用客户端密钥加密，所以客户端在拿到该部分内容时可以通过自己的密钥解密。如果是一个假的客户端，那么他是不会拥有真正客户端的密钥的，因为该密钥也从没在网络中进行传输过。这也同时认证了客户端的身份，如果是假客户端会由于解密失败从而终端认证流程。

TGSREQ & TGSREP

此时的客户端收到了来自KDC（其实是AS）的响应，并获取到了其中的两部分内容。此时客户端会用自己的密钥将第二部分内容进行解密，分别获得时间戳，自己将要访问的TGS的信息，和用于与TGS通信时的密钥CT_SK。首先他会根据时间戳判断该时间戳与自己发送请求时的时间之间的差值是否大于5分钟，如果大于五分钟则认为该AS是伪造的，认证至此失败。如果时间戳合理，客户端便准备向TGS发起请求。

其次请求的主要目的是为了获取能够访问目标网络服务的服务授予票据Ticket（进入动物园需要的门票）。 在第二次通信请求中，客户端将携带三部分内容交给KDc中的TGS，第二次通信过程具体如下所述

客户端行为：

① 客户端使用CT_SK加密将自己的客户端信息发送给KDC，其中包括客户端名，IP，时间戳； ② 客户端将自己想要访问的Server服务以明文的方式发送给KDC； ③ 客户端将使用TGS密钥加密的TGT也原封不动的也携带给KDC；

TGS行为： ① 此时KDC中的TGS（票据授予服务器）收到了来自客户端的请求。他首先根据客户端明文传输过来的Server服务IP查看当前kerberos系统中是否存在可以被用户访问的该服务。如果不存在，认证失败结束，。如果存在，继续接下来的认证。 ② TGS使用自己的密钥将TGT中的内容进行解密，此时他看到了经过AS认证过后并记录的用户信息，一把Session_KEY即CT_SK，还有时间戳信息，他会现根据时间戳判断此次通信是否真是可靠有无超出时延。 ③ 如果时延正常，则TGS会使用CK_SK对客户端的第一部分内容进行解密（使用CT_SK加密的客户端信息），取出其中的用户信息和TGT中的用户信息进行比对，如果全部相同则认为客户端身份正确，方可继续进行下一步。 ④ 此时KDC将返回响应给客户端，响应内容包括： 第一部分：用于客户端访问网络服务的使用Server密码加密的ST（Servre  Ticket），其中包括客户端的Name，IP，需要访问的网络服务的地址Server  IP，ST的有效时间，时间戳以及用于客户端和服务端之间通信的CS_SK（Session Key）。 第二部分：使用CT_SK加密的内容，其中包括CS_SK和时间戳，还有ST的有效时间。由于在第一次通信的过程中，AS已将CT_SK通过客户端密码加密交给了客户端，且客户端解密并缓存了CT_SK，所以该部分内容在客户端接收到时是可以自己解密的。

AP-REQ & AP-REP

此时的客户端收到了来自KDC（TGS）的响应，并使用缓存在本地的CT_SK解密了第二部分内容（第一部分内容中的ST是由Server密码加密的，客户端无法解密），检查时间戳无误后取出其中的CS_SK准备向服务端发起最后的请求。

客户端： ① 客户端使用CK_SK将自己的主机信息和时间戳进行加密作为交给服务端的第一部分内容，然后将ST（服务授予票据）作为第二部分内容都发送给服务端。 服务端： ①  服务器此时收到了来自客户端的请求，他会使用自己的密钥，即Server密钥将客户端第二部分内容进行解密，核对时间戳之后将其中的CS_SK取出，使用CS_SK将客户端发来的第一部分内容进行解密，从而获得经过TGS认证过后的客户端信息，此时他将这部分信息和客户端第二部分内容带来的自己的信息进行比对，最终确认该客户端就是经过了KDC认证的具有真实身份的客户端，是他可以提供服务的客户端。此时服务端返回一段使用CT_SK加密的表示接收请求的响应给客户端，在客户端收到请求之后，使用缓存在本地的CS_ST解密之后也确定了服务端的身份（其实服务端在通信的过程中还会使用数字证书证明自己身份）。 至此，第三次通信完成。此时也代表着整个kerberos认证的完成，通信的双方都确认了对方的身份，此时便可以放心的进行整个网络通信了。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：蝉SEC d0n9x1e d0n9x1e《【内网渗透】票据传递基础-1》