【内网横向】Kerberos认证

Kerberos认证

---

Windows的身份认证方式主要有NTLM认证和Kerberos认证两种，但是在域中，依旧采用Kerberos认证的方式（网络认证协议）。Kerberos协议在内网域渗透中可谓是必修的课程，黄金票据、白银票据以及委派攻击都离不开Kerberos协议。

下面我先介绍一下接下来要用到的一些名词，也是Kerberos协议中的必备成员以及他们的关系和作用：

缩写	含义
DC	Domain Controller 域控
KDC	Key Distribution Center 密钥分发中心
AS	Authtication Service 身份认证服务
AD	Account Database 账户数据库
TGS	Ticket Granting Service 票据发放服务
TGT	Ticket Granting Ticket 认证票据
Ticket	票据
Session Key	短期会话密钥
Krbtgt账户	每个域控制器都有的KDC服务账号

Kerberos认证由三方来完成，分别是Client、Server以及KDC。
KDC（默认安装在域控里），包含AS和TGS服务。
AS为Client生成TGT
TGT则为Client生成某个服务的Ticket
AD则是域控DC里类似本地SAM一样的数据库，里面存储所有Clint名单

先简单介绍一下认证流程吧，然后再展开细细讲讲，有利于大家理解：

Client在域中，想要访问Server就要向KDC申请可以访问Server的权限：

首先，Client先向KDC发起请求，要求获取访问Server权限，当KDC接收到请求之后，先由AS（身份认证服务）向AD（账户数据库）进行认证，询问Client是否存在AD中，若存在，则由AS将TGT返回给Client。

然后，Client带着TGT继续向KDC发起请求，继续要求获取访问Server的权限，当KDC接收到请求以后，TGS会通过TGT判断此Client是否具有访问Server的权限，若有，则将Ticket发送给Client。

最后，Client凭借着Ticket去访问所请求的Server，这个Ticket只对该Server有效，访问其他的Server需要重新申请。

通俗一点就是说：

Client想要访问Server，需要先通过KDC的允许。Client就问KDC，我能不能访问Server，KDC说：你连介绍信（TGT）都没有，凭什么访问Server。我先让我的小弟AS帮你看看你是否有资格拿到介绍信（TGT），AS就拿着AD这个名单查看Client的名字是否在AD名单中，存在，AS就将写有允许访问Server的介绍信（TGT）给了Client。Client拿到介绍信（TGT）开心坏了，赶忙又问KDC，我手上有能够访问Server的介绍信（TGT）能不能访问Server，KDC说，别着急，我让我另外一个小弟TGS帮你看看你的介绍信（TGT）都写有什么权限，TGS拿着介绍信（TGT）看了半天，说：你的介绍信（TGT）就是用来访问Server的，我来给你一张票据Ticket，你拿着这个Ticket去访问Server去吧。于是Client开心的拿着Ticket去访问Server去了。

接下来，我将详细展开讲讲整个域认证的流程：

域认证流程-第一步（AS-REQ—AS-REP阶段）

Client发送自己的身份信息给KDC，KDC验证成功后，会在本地生成一个随机的字符串Session Key，返回给Client如下两个信息：

1. 由Client提供的用户名所对应的NTLM hash对Session Key加密后得到的，AD中存储着所有域用户的账号密码等信息，当Client发送身份信息后，AS会先对AD进行请求，询问是否存在此用户，若存在，就会取出他的NTLM hash，然后对所生成的Session Key进行加密，作为返回给Client的其中一条信息

1. KDC的特定用户krbtgt（由创建域控的时候自动生成，且系统随机分配一个密码）的NTLM hash对 Session Key 和 Client所发送的用户信息进行加密后得到的，这个加密的内容就是TGT。

TGT包含：会话密钥Session Key 、Domain name\Client、Client访问的服务，TGT到期的时间

<!--返回给Client的两条信息中的Session key是相同的-->

到目前为止，Kerberos请求的第一步过程就结束了，此时已经获取到了所需要的TGT，接下来就是通过TGT来请求Ticket。

需要注意的是，返回的两个内容中，第一个Client hash，Client可以通过自己的NTLM hash解密，得到其中的Session Key，但Client是没有krbtgt的hash的，也就是Client不知道krbtgt的密码，无法解密TGT中的具体内容，我们可以使用前面解密到的Session Key继续和TGS进行通信

域认证流程-第二步（TGS-REQ—TGS-REP阶段）

首先Client会传输第一步获取到的TGT以及通过自己的NTLM hash解密出来的Session Key以此来加密Client的信息、时间戳（timestamp），还有Client和Server的信息，Client将这三块信息一同发送给TGS。

TGS接收到Client发送过来的三块信息，因为TGS本身就属于KDC，因此他拥有krbtgt的NTLM hash，所以先对TGT进行解密，这样TGS就能获取到他本没有的Session Key，以此来接着解密Client加密的Client信息和时间戳timestamp。获取到的时间戳timestamp与当前时间相差太久的话，认证就需要重新请求新的TGT。

TGS从解密出来的Client信息还能和Client发送的第三部分的信息进行比较，如果两个相等的话，还会继续判断此Client有没有权限访问Server，如果都没问题的话，就认证成功，将Ticket发送给Client。

在这次传输的时候，包含如下两条信息

1. 首先会在本地再生成一个随机的字符串Server Sesson Key，使用之前的Session Key将新生成的Server Session Key加密得到的第一个字符串，这里的Server Session Key主要用于后面在Client与Server的认证过程中。

1. 第二个内容就是Ticket，KDC会先通过前面所获得的Server信息，在AD中找到对应的NTLM hash，然后通过此NTLM hash去加密TIcket，最后一并返回给Client。

在给到Client之后，Client将拥有的Session Key解密获得Server Session Key，但是服务端没有Server hash，所以无法解密得到Ticket。

Ticket包含的内容：

会话密钥Server Session Key、Domain name\Client 、Ticket到期时间

到此为止，与KDC的通信就结束了，接下来就是拿着Ticket与Server进行通信

域认证流程-第三步（AP-REQ—AP-REP阶段）

Client向Server发送一个krb-ap-req请求，其中第一块就是Ticket，因为Client是不能对其解密的，然后第二个内容就是解密出来的Server session key，通过解密出来的Server Session Key加密Client信息和时间戳，最后一并发送给Server。

Server在收到数据包之后，使用自己的hash将Ticket揭秘出来，从而获取Server session key，然后将krb-ap-req中的Client信息与时间戳解密出来，然后与Ticket中的信息进行对比，将这里的时间戳与Ticket的end time进行比较，如果超过了这个时间，就说明Ticket已经失效了，需要重新认证。

到此，域渗透流程就结束了。

整个Kerberos认证流程中，TGT和Ticket的结构是一样的，不同的是TGT是Session Key，Ticket中的是Server Session Key，Session Key是由AS给Client的，Server Session Key是由TGS给Client的。
Session Key 和 Server Session Key 都是随机生产的一串字符串。
其实整个Kerberos认证的流程就是不断交换密钥，使用对称加密算法，解密验证身份和时间戳，最后达到认证的目的。
Ticket用Server NTLM hash加密，每个Server的密码不一样，所以Ticket只能对应一个服务。

我们最后再来理一下整个流程：

第一个Session Key AS用Client NTLM hash加密，传输给Client，Client解密后获取Session Key，接着用Session Key加密自己的信息和时间戳，TGS获取后，通过krbtgt的NTLM hash进行解密TGT，获取Session Key，用这个Session Key解密Client发来的身份信息以及时间戳，验证成功后，TGS随机生成Server Session Key，用Session Key加密发送给Client，Client已经拥有了Session Key，所以能够解密获得Server Session Key，将自己的信息用Server Sesson Key加密，以及Ticket一起发送给Server。Server用自己的NTLM hash解密Ticket，Ticket中含有Server Session Key，再用Ticket中的Server Session Key解密出Client的个人信息，与Ticket的信息对比，如果信息一致且时间戳也没问题，则允许访问。