一、前言
之前的文章提到过，在内网的域环境中，服务器之间默认使用的是Kerberos协议。
光了解NTLM协议是远远不够的，为了内网渗透，我后面将详细介绍Kerberos协议的原理以及漏洞的利用。
二、Kerberos协议
Kerberos是一种网络身份验证协议，它主要是给Client 或者用户提供凭证或票据去访问服务器中的相应服务。
区别于NTLM：
NTLM：起到用户登录服务器之间的验证作用
Kerberos：起到给用户提供票据访问服务器中的服务的作用
在Kerberos协议中主要是有三个角色的存在：
-
访问服务的Client(以下表述为Client 或者用户)
-
提供服务的Server(以下表述为服务)
-
KDC（Key Distribution Center）密钥分发中心
其中KDC服务默认会安装在一个域的域控中，而Client和Server为域内的用户或者是服务，如HTTP服务，SQL服务。在Kerberos中Client是否有权限访问Server端的服务由KDC发放的票据来决定。（比如说你去住酒店，酒店前台给你房卡，你拿着对应的房卡就能入住哪间房。你就是用户，酒店前台就是密钥分发中心，酒店就是服务器，房间就是服务器提供的服务）
kerberos的简化认证认证过程如下图：
-
AS_REQ: Client向KDC发起AS_REQ,请求凭据是Client hash加密的时间戳
-
AS_REP: KDC使用Client hash进行解密，如果结果正确就返回用krbtgt hash加密的TGT票据，TGT里面包含PAC,PAC包含Client的sid，Client所在的组。
-
TGS_REQ: Client凭借TGT票据向KDC发起针对特定服务的TGS_REQ请求
-
TGS_REP: KDC使用krbtgt hash进行解密，如果结果正确，就返回用服务hash 加密的TGS票据(这一步不管用户有没有访问服务的权限，只要TGT正确，就返回TGS票据)
-
AP_REQ: Client拿着TGS票据去请求服务
-
AP_REP: 服务使用自己的hash解密TGS票据。如果解密正确，就拿着PAC去KDC那边问Client有没有访问权限，域控解密PAC。获取Client的sid，以及所在的组，再根据该服务的ACL，判断Client是否有访问服务的权限。
这篇文章我们主要对AS_REQ&AS_REP进行分析：
三、AS_REQ&AS_REP
krbtgt：秘钥分发中心服务账户
四、漏洞
4.0、发包工具介绍
条件：有域内普通用户的账号密码
点击修改配置，支持明文密码以及hash
4.1、pass the hash
就是由于在进行认证的时候，是用用户hash加密时间戳，即使在使用密码进行登录的情况下，也是先把密码加密成hash，再进行认证。因此在只有用户hash，没有明文密码的情况下也是可以进行认证的。不管是rubeus还是impacket里面的相关脚本都是支持直接使用hash进行认证。
4.2、用户名枚举
看以下几种情况
用户名存在，密码错误的情况下：
用户名不存在的情况下：
通过比较error-code的值就可以写脚本改变cname的值进行用户名枚举。
4.3、密码喷洒
在已有用户名的时候，可以尝试爆破密码。
密码正确的情况下:
密码错误的情况下:
4.4、AS-REPRoasting
对于域用户，如果设置了选项”Do not require Kerberos preauthentication”，此时向域控制器的88端口发送AS_REQ请求，对收到的AS_REP内容(enc-part底下的ciper，因为这部分是使用用户hash加密session-key，我们通过进行离线爆破就可以获得用户hash)重新组合，能够拼接成”Kerberos 5 AS-REP etype 23”(18200)的格式，接下来可以使用hashcat对其破解，最终获得该用户的明文口令
4.5、黄金票据
在AS_REP里面的ticket的encpart是使用krbtgt的hash进行加密的，如果我们拥有krbtgt的hash，就可以给我们自己签发任意用户的TGT票据，这个票据也被称为黄金票据。