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服务账号

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

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去了。

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

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

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

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

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

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

首先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。

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

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

第二个内容就是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进行通信

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已经失效了，需要重新认证。

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

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

第一个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的信息对比，如果信息一致且时间戳也没问题，则允许访问。