kerberos协议分析

前言

最近打渗透的时候发现一个问题，内网渗透的知识点太多、太杂了，不看wp基本都没什么思路，只会用fscan一把梭或者当脚本小子（如果扫不出来漏洞就卡住了），所以我打算从内网协议出发，先了解协议的基本原理，再学习其中的漏洞。

kerberos

Kerberos是一种计算机网络授权协议，用来在非安全网络中，对个人通信以安全的手段进行身份认证。软件设计上采用客户端/服务器结构，并且能够进行相互认证，即客户端和服务器端均可对对方进行身份认证。可以用于防止窃听、防止重放攻击、保护数据完整性等场合，是一种应用对称密钥体制进行密钥管理的系统。Kerberos的扩展产品也使用公开密钥加密方法进行认证。

再kerberos协议中存在三个角色

Client，客户端
Server，服务端
KDC（Key Distribution Center）密钥分发中心，而密钥分发中心一般又分为两部分：

AS（Authentication Server）：认证服务器，专门用来认证客户端的身份并发放客户用于访问 TGS的TGT（票据授予票据)

TGS（Ticket Granting Ticket）：票据授予服务器，用来发放整个认证过程以及客户端访问服务端时所需的服务授予票据（Ticket）

kerberos认证过程

分为三个阶段:

AS_REQ&AS_REP
TGS_REQ&TGS_REP
AP_REQ&AP_REP

AS请求分析

这里我用kekeo生成kerberos认证流量，抓取流量来分析

AS_REQ&AS_REP

这是 Kerberos 协议第一步请求报文：客户端向 KDC 的 AS 服务，申请 TGT 票据。

简单来说这一步就是验证身份，验证账号是否存在、预认证是否正确。

Tgt::ask /user:administrator /domain:test.local /password:admin@123456

具体流程是这样，当域内某个用户Client想访问某个服务，于是输入用户名和密码，此时客户端本机的 Kerberos 服务会向 KDC 的 AS 认证服务发送一个 AS_REQ 认证请求。请求的凭据是 Client 的哈希值 NTLM-Hash 加密的时间戳以及 Client-info、Server-info 等数据，以及一些其他信息。

这里cipher就是加密后的内容

当 Client 发送身份信息给 AS 后，AS 会先向活动目录 AD 请求，询问是否有此 Client 用户，如果有的话，就会取出它的 NTLM-Hash，并对 AS_REQ 请求中加密的时间戳进行解密，如果解密成功，则证明客户端提供的密码正确，如果时间戳在五分钟之内，则预认证成功。然后 AS 会生成一个临时秘钥 Session-Key AS，并使用客户端 Client 的 NTLM-Hash 加密 Session-key AS 作为响应包的一部分内容。此 Session-key AS 用于确保客户端和 KGS 之间的通信安全。

还有一部分内容也就是TGT。使用 KDC 一个特定账户krbtgt的 NTLM-Hash 对 Session-key AS、时间戳、Client-info 进行的加密。这个特定账户就是创建域控时自动生成的 Krbtgt 用户，然后将这两部分以及 PAC 等信息回复给 Client，即 AS_REP 。PAC 中包含的是用户的 SID、用户所在的组等一些信息。

ticket 中的 enc‑part 字段就是用krbtgt的hash加密后的TGT。

enc‑part是用用户的hash加密的，所以client收到rep后只能解密这一部分。

TGS_REQ&TGS_REP

tgs::ask /tgt:TGT_le001@TEST.LOCAL_krbtgt~test.local@TEST.LOCAL.kirbi /service:cifs/DC.test.local /ptt

Client接收到AS_REP之后，用自己的NTLM Hash对加密后的Session Key AS进行解密之后得到Session Key AS，并且缓存到本地，此时需要发起服务请求的话，进行下一步，Client使用Session Key AS对Client info、Server info、时间戳进行加密，连同TGT票据构成TGS_REQ一起发给KDC的TGS

ticket 就是我们之前 AS‑REP 拿到的TGT 票据

authenticator 是用TGT 对应的 Session‑Key 加密。

TGS得到TGS_REQ之后，用krbtgt的hash值对TGT凭据进行解密，得到Seesion Key AS、时间戳、Client info，之后对TGS_REQ用Session Key AS加密的部分进行解密，得到时间戳，如果两部分时间戳相差不多的话(时效一般是20分钟)，进行TGS_REP的构造，用Session Key AS对Session Key TGS进行加密作为第一部分，用Server的hash对Client info、时间戳、Session Key TGS进行加密作为第二部分，两部分构成了TGS票据（ST）发给Client

这里ticket字段存放的是用serverhash加密后的ST

enc-part 是 KDC 用 TGT 的 Session‑Key 加密出来的响应体

AP_REQ&AP_REP

dir \\DC.test.local\c$

跟TGS_REQ&TGS_REP流程类似，Client拿到TGS_REP,用Session Key AS解密TGS_REP第一部分，得到Session Key TGS缓存本地，然后用Session Key TGS加密时间戳、Client info，连同ST(被Server hash加密的部分)构成AP_REQ一起发送给Server

Server拿到AP_REP之后用Server Hash对ST进行解密，得到Client info、时间戳、Serssion Key TGS，然后用Session Key TGS对第一部分进行解密，得到时间戳，两部分时间戳进行比对，相差不大的话进行下一步。时间戳有效时间一般时间为8小时。

这里的ticket就是TGS返回的ST