kerberos协议介绍及分析

一.kerberos认证过程：

二.服务作用

KDC(key distributed center)
作用：整个安全认证过程的票据生成管理服务，其中包含两个服务，AS和TGS

AS(authentication service)
作用：为client生成TGT的服务

TGS(ticket granting service)
作用：为client生成某个服务的ticket

AD(account database)
作用：存储所有client的白名单，只有存在于白名单的client才能顺利申请到TGT

TGT(ticket-granting ticket)
作用：用于获取ticket的票据

client
想访问某个server的客户端

server
提供某种业务的服务

三.步骤详解

（AS-REQ）Client 发送用户名 Tom 到 KDC （Key Distribution Center）以向 AS （Authentication Service）请求 TGT 票据等信息。

（AS-REP）收到请求后，AS 生成随机字符串 Session Key，使用 Tom 的 NTLM Hash 对 Session Key 加密得到密文 A，再使用账号 krbtgt 的 NTLM Hash 对 Session Key 、 Client Info和 timestamp 加密得到 TGT，A 和 TGT 一起返回给 Client。

（TGS-REQ） Client 收到请求后，使用自身的 NTLM Hash 解密 A 就能得到 Session Key，然后使用 Session Key 对 Client Info 和 timestamp 加密得到 B，加上 TGT ，发送给 KDC中的 TGS。

（TGS-REP）TGS 收到请求后，使用 krbtgt 的 NTLM Hash 解密 TGT，得到 Session Key 和 timestamp 以及 Client Info，同时，使用 TGT 解密出的 Session Key 解密密文B，得到Client Info 和 timestamp。比对这两部分解密得到的内容以验证是否通过。通过后，生成一个新的随机数 Server（Sever Session key），并用它加密 client info 和 timestamp 得到密文 enc-part；使用服务器计算机的NTLM Hash 对 Server（Sever Session key）和 client info 以及 timestamp 加密得到最终的 Ticket，返回给 Client。

（AP-REQ）Client 使用 Ticket 和 enc-part 直接请求某服务。

（AP-REP）对Ticket 和 enc-part 解密后进行验证授权。

三、详细分析

AS-REQ

开始先会进行kerberos预身份认证（为了防止爆破）kerberos v4 默认不会进行预认证。

第一部分：当中pvon代表的是kerberos协议类型的版本，这里5代表是kerberos v5.因为kerberos v4的缺陷默认不会预认证，kerberos v5则加了预认证，msg-type表示了消息类型为krb--as-req

第二部分： kdc-options代表各种票证的标志及属性。客户端信息cname代表请求的用户，relalm代表派发该票据的域名称

第三部分：被请求的服务名称，这里它是windows域名，till：（到期时间，rubeus和kekeo都是20370913024805Z，这个可以作为认证来检测工具），nonce：用来防止数据包重放（随机生成的一个数kekeo/mimikatz nonce是12381973，rubeus nonce是1818848256，这个也可以用来作为特征检测工具。）

第四部分：etype加密类型，KDC通过etype中的加密类型选择用户对应的hash进行解密

AS-REQ

接着KDC相应告诉客户端它需要更多信息来证明

在AS-REQ里面cname 是请求的用户,这个用户名存在和不存在，AS-REP返回的包有差异，可以用于枚举域内用户名

AS-REQ

用户向KDC发起AS_REQ,请求凭据是用户 hash加密的时间戳。请求凭据放在PA_DATA里面

这一步骤：用户登录输入的密码经过hash作为加密算法的密钥，加密时间戳加密后的value发送给AS服务器，AS服务器会去数据库中查找用户（administrator）对应的hash去解密PA-DATA PA-ENC-TIMESTAMP（时间戳加密结果），如果能解密成功，而且时间在一定范围内，PAC requests true，KDC根据include的值来判断返回的票据中是否携带PAC。

32355402fd6aa4f403f50854886c72aeeaa8be7a764ca86bac8ed927adc2cb68bfff5a48e5aa68bfe3ab39ba57078b411008fd850e00a485就是加密后的结果。

AS-REP

KDC存有对应用户的密码 hash, 所以KDC在收到请求后会解出里面的时间戳, 如能正常解密, KDC 则会认为客户端提供的密码 hash 正确, 随后KDC会向客户端返回两个东西, 一个是用用户密码 hash 加密的会话密钥(session key),另外一个是TGT只有KDC能解密，因为用的krbtgt hash进行加密

第一部分：在AS_REQ请求里面是使用krbtgt的hash进行加密的客户端无法解密只有KDC能解密，解密出来的内容用户名、域、会话密钥、时间戳、存活周期、 PAC 数据，如果获取到了krbtgt的hash就可以自己制作一个ticket（黄金票据）

第二部分：由客户端用户密码 hash 加密, 客户端可直接解密，解密后得到Encryptionkey（会话密钥），TGS 服务名称默认 krbtgt，域，Encryptionkey（会话密钥），时间戳，Encryptionkey里面最重要的字段是session key，作为下阶段的认证密钥。两个步骤中使用的会话密钥为同一个。

TGT-REQ

当客户端用户到收到返回的会话密钥和TGT，会先用自己的密码hash解密出会话密钥，客户端无法解密TGT，客户端会把TGT存到自己缓存中备用，有了TGT接着向KDC要访问指定服务的票据，请求的内容包含TGT、身份认证信息、SPN信息。

第一部分：这个ticket用于AP_REQ的认证，使用krbtgt的hash进行加密的，而在TGS_REQ里面是使用要请求的服务的hash加密的。因此如果我们拥有服务的hash就可以自己制作一个ticket，白银票据。

第二部分：这个是可以解密使用key是上一轮AS_REP里面返回的session_key。

TGT-REP

KDC收到请求后，会用krbtgt密码hash解密TGT，获取用户名，会话密钥和时间戳，接着再用会话密钥去解密身份验证信息（authenticator）中的用户名和时间戳，将此处两个用户和时间戳进行对比，并确定TGT是否还在生命周期内，如果正常，KDC会创建个TGS，然后将TGS和另外一段会话密钥（Server Session Key）加密的数据返回给客户端，客户端和KDC通信结束。