Kerberos

Kerberos是一种计算机网络认证协议，它允许某实体在非安全网络环境下通信，向另一个实体以一种安全的方式证明自己的身份。它也指由麻省理工实现此协议，并发布的一套免费软件。它的设计主要针对客户-服务器模型，并提供了一系列交互认证——用户和服务器都能验证对方的身份。Kerberos协议可以保护网络实体免受窃听和重复攻击。
https://zh.wikipedia.org/wiki/Kerberos

Kerberos协议概况

  1. 访问服务的client端
  2. 提供服务的server端
  3. KDC(Key Distribution Center) 密钥分发中心其中里面包含AS（Authentication Server） 认证服务器，用来认证客户端的身份并发放客户端用于访问TGS的TGTTGS（Ticket Granting Server）票据授予服务器，用来发放整个认证过程以及客户端访问服务端时所需的服务授予票据

image.png
1、KDC 服务默认会安装在一个域的域控中
2、从物理层面看，AD与KDC均为域控制器(Domain Controller)
3、AD其实是一个类似于本机SAM的一个数据库，全称叫account database，存储所有client的白名单，只有存在于白名单的client才能顺利申请到TGT
4、KDC 服务框架中包含一个 KRBTGT 账户，它是在创建域时系统自动创建的一个账号，你可以暂时理解为他就是一个无法登陆的账号，在发放票据时会使用到它的密码 HASH 值。
image.png

Kerberos认证流程

kerberos中的票据比作你购买的高铁票，那么 Client 端就是乘客，服务端就是高铁，KDC就是车站的检票系统，如果人工检测到你持着本人身份证，并且车次正确才可以上车，用一个夹子给你的车票夹一个缺口再给你。 Kerberos 中有存在两张票车票是一张
KDC中分为两个部分Authentication Service和Ticket Granting Service
Authentication Service
As的作用就是验证Client端的身份（确认是本人并且是该车次）通过验证后就会给一张TGT(Ticket Granting Ticket)票（夹过的）给Client
Ticket Granting Service
TGS的作用是通过AS发送给Client的票（TGT）换取访问Server端的票（夹过的）ST（ServiceTicket）也被称之为 TGS Ticket，为了和 TGS 区分，在这里就用 ST 来说明，所以TGS Ticket和ST的意思是一样的。
image.png

Kerberos 详解认证流程

当client想要访问Server上的某个请求时，需要先向AS证明自己的身份，然后通过as发放的TGT想server发起认证请求，
The Authentication Service Exchange：Client 与 AS 的交互，
The Ticket-Granting Service (TGS) Exchange：Client 与 TGS 的交互，
The Client/Server Authentication Exchange：Client 与 Server 的交互。
image.png

AS_REQ AS_REP

AS_REQ

client 向KDC发送AS_REQ,请求凭据是用户hash加密的时间戳。请求的凭据放到PA_DATA里面
image.png
pvno：**5 版本号

msg-type：类型，AS_REQ对应的就是KRB_AS_REQ(0x0a)

padata：存放一些认证信息，一个列表，包含若干个认证消息用于认证，我们也可以Authenticator。每个认证消息有type和value。

里面主要有两个ENC_TIMESTAMP、PA_PAC_REQUEST

ENC_TIMESTAMP

用户加密时间戳→给as服务器。as服务器用已有用户的hash进行解密，获取时间戳，如果能解密且时间戳在一定的范围内，则证明认证通过

PA_PAC_REQUEST

这是PAC支持的扩展。PAC(Privilege Attribute Certificate)没有在原生的kerberos里面，是微软引用的扩展PAC包含在AS_REQ的响应body(AS_REP)。这里的value对应的是include=true或者include=false(KDC根据include的值来判断返回的票据中是否携带PAC)。

req-body

用户名,域名，加密方式等。
image.png

AS_REP

KDC使用用户hash进行解密，如果结果返回正确用krbtgthash加密的票据，TGE里面包含PAC，PAC包含用户的sid，用户所在的组
image.png
msg-type**

AS_REQ的响应body对应的就是KRB_AS_REP(0x0b)

crealm：yum

cname：用户名

ticket：

ticket用于TGS_REQ的认证。是加密的，用户不可以读取里面内容。在AS_REQ请求里面是，是使用krbtgt的hash进行加密的，因此如果我们拥有krbtgt的hash就可以自己制作一个ticket，既黄金票据。

enc-part：

这部分是可以解密的，key是用户hash，解密后得到Encryptionkey，Encryptionkey里面最重要的字段是session key，作为下阶段的认证密钥。
image.png

TGS_REQ & TGS_REP

TGS_REQ

客户端收到来自AS的响应，获取到其中两部分内容。客户端会对里面的内容进行解密，分别获得时间戳，自己将要访问的TGS的信息，和用于与TGS通信时的密钥CT_SK。首先会根据时间戳判断该时间戳与自己发送请求时间如果大于五分钟，就被认定为伪造的，如果合理客户端就会想TGS发起请求。
image.png
image.png
在padata中有很重要的一部分叫做AP-REQ，这是TGS-REQ中必须有的数据，这部分会携带AS-REP里面获取到的TGT票据，KDC检验TGT票据，如果票据正确，返回ST票据。
image.png
TGS-REQ请求包中的authenticator就是AS-REP响应包返回的Login Session key加密的时间戳
image.png
padding:0
kdc-options:用于与KDC约定一些选项设置
realm:域名
sname:这里是要请求的服务
till:到期时间
rebeus和kekeo都是20370913024805Z，可用于作为特征值检验用
nonce:随机生成数
kekeo/mimikatz的nonce为12381973，rubeus的nonce为1818848256,可用于作为特征值检验 用
etype:加密类型

TGS-REP

image.png
将会验证对方的身份，验证时间戳是否在范围内，并且检查TG中的时间戳是否过期，且原始地址是否和TGT中保存的地址相同
完成认证后，TGS生成ST票据（包括客户端信息和原始Server Session key，整个ST服务票据使用该服务的NTML hash加密以及一个AS-REP返回的Login-Session-Key加密的Server Session Key。这两个将在响应包中发送给Client
image.png
PS:在这一步中，不论用户是否有权限访问服务，只要TGT解密无误，都将返回ST服务票据。任何一个用户，只要hash正确，就可以请求域内任何一个服务的票据

AP-REQ AP-REP

AP-REQ

本地的wireshark也抓不到包，客户端收到服务端返回的ST与enc-part,使用缓存的login session key解密enc-part获得service session key，本地缓存server session key与ST，请求服务时将ST和service session key加密后的时间戳信息发送给server

AP-REP

server收到相关数据，使用service key解密TGS的ticket的enc-part，获得service session key，使用service session key解密authentication后对authenticator进行验证，通过后返回新的时间戳，客户端通过service session key解密返回的时间戳，进行验证，通过则证明客户端可信赖服务器，并发送服务请求，服务器对客户端提供相应服务

总结

客户端 1.客户端向AS请求TGT →AS验证用户身份→2.AS返回TGT
3.客户端携带TGT访问TGS请求获取Server TIcket→检查TGT内用户身份和请求用户是不是相符→4.TGS返回用于访问服务的Server Ticket
5.客户端根据Server Ticket访问想要访问的服务→服务器查看是否有用户所请求的serverIP，检查ticket 与客户端身份→同意请求，建立连接。

相关安全问题

PTH/PTK/PTT

在认证的时候不仅支持明文认证同时允许使用hash认证
明文登录：明文→加密成hash→认证
hash登录：hash→认证
如果 hash 是 ntlm hash ，然后加密方式是 rc4 ，这种就算做是 pass the hash
如果 hash 是 aes key(使用sekurlsa::ekeys导出来) ，就算是 pass the key
在很多地方，不支持rc4加密方式的时候，使用pass the key不失为一种好方法。
PTT
Kerbreos 除了第一步AS_ERQ是使用时间戳加密用户hash验证之外，其他的步骤的验证都是通过票据，这个票据 可以是TGT票据或者TGS票据。因为票据里面的内容主要是session_key和ticket(使用服务hash加密的，服务包括krbtgt)，拿到票据之后。我们就可以用这个票据来作为下阶段的验证了。

用户名枚举

密码错误：
image.png
用户名不存在:
image.png
在域内没有域账号的情况下进行用户名枚举,通过这个比较就可以写脚本改变cname的值进行用户名枚举。
如果有账号的情况可以通过ldap来查询

AS-REPRoasting

如果域用户，设置了“不要求Kerberos 预身份验证”此时向域控制器的88端口发送AS_REQ请求，对收到的AS_REP内容(enc-part底下的ciper，因为这部分是使用用户hash加密session-key，我们通过进行离线爆破就可以获得用户hash)重新组合，能够拼接成”Kerberos 5 AS-REP etype 23”(18200)的格式，接下来可以使用hashcat对其破解，最终获得该用户的明文口令

密码暴力破解

这种针对所有用户的自动密码猜测通常是为了避免帐户被锁定，因为针对同一个用户的连续密码猜测会导致帐户被锁定。所以只有对所有用户同时执行特定的密码登录尝试，才能增加破解的概率，消除帐户被锁定的概率。普通的爆破就是用户名固定，爆破密码，但是密码喷洒，是用固定的密码去跑用户名。

黄金票据

在AS_REP里面的ticket的encpart是使用krbtgt的hash进行加密的，如果我们拥有krbtgt的hash，就可以给我们自己签发任意用户的TGT票据，这个票据也被称为黄金票据。

kerberosting

白银票据

在TGS_REP里面的ticket的encpart是使用服务的hash进行加密的，如果我们拥有服务的hash，就可以给我们自己签发任意用户的TGS票据，这个票据也被称为白银票据。相较于黄金票据，白银票据使用要访问服务的hash，而不是krbtgt的hash，由于生成的是tgs票据，不需要跟域控打交道，但是白银票票据只能访问特定服务。

约束委派

非约束委派攻击

基于资源的约束委派攻击

漏洞利用

参考

https://daiker.gitbook.io/windows-protocol/kerberos/1#5.-enc_part