前言

Kerberos协议是内网中经常使用的认证协议，之前学习的Windows认证算是基础，接下来是Kerberos域认证。

0x01 Kerberos协议

Kerberos是一种计算机网络认证协议，它允许某实体在非安全网络环境下通信，向另一个实体以一种安全的方式证明自己的身份。它也指由麻省理工实现此协议，并发布的一套免费软件。它的设计主要针对客户-服务器模型，并提供了一系列交互认证——用户和服务器都能验证对方的身份。Kerberos协议可以保护网络实体免受窃听和重复攻击。

在网络的各种认证中随时都有可能存在中间人攻击的情况，Kerberos协议设计之初便考虑到了这个问题，所以Kerberos协议的整个认证过程实现不依赖于主机操作系统的认证，无需基于主机地址的信任，不要求整个网络中每台主机都是安全的，并假定网络上传送的数据包可以被任意地读取、修改和插入数据。在以上情况下， Kerberos作为一种可信任的第三方认证服务，是通过传统的密码技术（如：共享密钥）执行认证服务的。

在这种方式下让Kerberos的整个认证过程中不用担心受到中间人攻击。

0x02 常用术语

在刚开始学习Kerberos认证时，经常看到像AD，TGT，TGS等等这种字母组合，但是他们究竟是什么，在Kerberos认证过程中他们的作用又是什么，下面来总结一下。

2.1 DC

DC（Domain Controller）：域控制器，是域中一台拥有最高管理权限的计算机，一个域内可以有多台域控制器，每一个域控制器的地位几乎是平等的，有几乎相同的数据库，如果有多台域控制器，当在其中一台域控制器添加一个用户账号，其他域控制器也会自动同步添加。

域控制器管理着整个域中所有主机，当域内主机需要互相通信必须经过域控制器审核通过才行。

通常情况下域控制器会和DNS服务器部署在同一台主机上，在内网渗透中可以通过DNS服务器来定位域控。

2.2 AD

AD（Active Directory）：活动目录是Windows Server的目录服务。

在庞大的网络环境中存在着各种资源，网络中的各种对象：用户、用户组、计算机、域、组织单位以及安全策略等等，肯定需要存在到一个合理的位置便于管理，这个位置就是活动目录数据库，也就是AD。有了AD存储网络对象的信息，管理员和用户能够轻松地查找和使用这些信息。

活动目录AD主要提供的功能如下：

①服务器及客户端计算机管理：管理服务器及客户端计算机账户，所有服务器及客户端计算机加入域管理并实施组策略。
②用户服务：管理用户域账户、用户信息、企业通讯录（与电子邮件系统集成）、用户组管理、用户身份认证、用户授权管理等，按省实施组管理策略。
③资源管理：管理打印机、文件共享服务等网络资源。
④桌面配置：系统管理员可以集中的配置各种桌面配置策略，如：用户使用域中资源权限限制、界面功能的限制、应用程序执行特征限制、网络连接限制、安全配置限制等。
⑤应用系统支撑：支持财务、人事、电子邮件、企业信息门户、办公自动化)、补丁管理、防病毒系统等各种应用系统。

Kerberos认证中就需要通过查询AD中数据来判断发出请求的客户端是否合法。

这个存储了这么多数据的数据库肯定需要部署到域内的一台主机上，这台主机就是DC（域控制器），所以在一般情况下如果一台主机安装了AD，那么它就是DC。

2.3 KDC

KDC（Key Distribution Center）：秘钥分发中心是一种运行在物理安全服务器上的服务，是负责颁发凭证的Kerberos组件，这些凭证是使用KDC数据库中存储的信息创建的。KDC也是默认安装在域控中。

KDC中又包含了AS和TGS。

诸多服务都安装在域控中，在内网渗透中的目标也是拿下域控，进而获取整个域的控制权。

2.4 AS & TGS

• AS（Authentication Service）：身份验证服务，为Client生成TGT的服务。

• TGS（Ticket Grantng Service）：票据授予服务，为Client生成某个服务的Ticket。

2.5 Ticket & TGT

• Ticket ：票据，是网络对象互相访问的凭证。

• TGT（Ticket Granting Ticket）：票据授权票据，通过票据授权票据可以获得一个票据，类似临时凭证。

0x03 Kerberos认证流程

Kerberos认证整个过程大致可以分为6个步骤，过程如下图：

1、2：Client向DC发出访问Server的请求，DC收到请求后AS通过AD来判断Client是否可信；当验证通过，AS生成TGT返回给Client。
3、4：Client拥有了TGT，继续向DC发出访问Server的请求（带有TGT），此时TGS通过TGT判断Client具有访问权限，TGS将具有访问Server权限的Ticket发送给Client。
5、6：Client拥有了Ticket，可以访问Server，但是整个Ticket只针对找这一个Server有效，Client与Server建立连接开始通信。

0x04 Kerberos认证分析

通过上面的Kerberos认证流程可发现，Kerberos认证过程可以大致分为三个阶段：

1. AS_REQ & AS_REP

2. TGS_REQ & TGS_REP

3. AP-REQ & AP-REP

详情见官方文档：https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-sfu/4a624fb5-a078-4d30-8ad1-e9ab71e0bc47#gt_7c881e2e-85a0-45e1-bd2c-5aab42bb2deb

下面利用Wireshark抓包具体分析一下每一个阶段：

测试环境：

域用户：admin
域名：axpmyw

在域成员主机上登录域用户admin，然后再利用Wireshark抓包。

4.1 AS_REQ & AS_REP

AS_REQ的数据包：

其中包括了Kerberos的版本，这里使用的是Kerberos V5；消息类型这里是krb-as-req。

这里使用了用户Hash（NTLM Hash）加密时间戳，在进行认证时，KDC中的AS服务收到请求，首先使用对应用户的Hash解密时间戳，如果不超过5分钟，那么说明数据包有效预认证通过。

这里启用了PAC，PAC的存在会使认证更加安全。

AS_REP的数据包：

返回的数据除了一些客户端信息、和服务端信息外，还ticket和enc-part。

当预认证成功之后，AS会生成一个随机字符串，叫Session Key，然后使用客户端用户的Hash（NTLM Hash）加密Session Key。

KDC使用特定账户（krbtgt）的Hash（NTLM Hash）对Session Key、时间戳、客户端的信息进行加密生成TGT就是这里的ticket。

enc-part由krbtgt的Hash加密生成的，这里如果可以得到krbtgt的hash就可以伪造TGT，也就是伪造黄金票据。

Kerberos认证的第一阶段完成，总结一下第一阶段：

客服端某个用户想要访问域内某个服务，客户端的Kerberos 服务向DC的ADC发出AS_REQ认证请求，请求内容包括使用用户的NTLM-Hash加密的时间戳，客户端信息和服务端信息等。

当KDC收到请求，AS会请求AD验证此用户是否合法（是否在AD目录中），验证不通过认证失败；验证通过之后使用该用户的NTLM-Hash解密时间戳，如果时间戳超过5分钟，则认证失败，如果在5分钟以内，AS会生成一个Session Key并使用用户的NTLM-Hash加密Session Key。

同时会使用特定账户krbtgt账户的NTLM-Hash加密Session Key、时间戳、客户端的信息作为TGT，然后TGT和Session Key一并发送给客户端。TGT的到期时间为8小时，如果超过了8小时，不能之间进入下一步获取Ticket，想要进入下一阶段必须重新申请TGT。

4.2 TGS_REQ & TGS_REP

第一阶段中，使用用户的NTLM-Hash加密Session Key发送到客户端后，客户端可以使用对应的NTLM-Hash解密获得Session Key并缓存本地；TGT客户端是无法解密的，但是客户端可以和TGS通信。

TGS_REQ的数据包：

数据包中有第一阶段收到的TGT，这个TGT就是AS-REP里面获取到的TGT。Authenticator是使用Session key加密的客户端信息、服务端信息和时间戳。

这里的到期时间rebeus和kekeo都是20370913024805Z，可用于作为特征值检验用。

TGS_REP的数据包：

当TGS收到请求后，首先解密TGT，从TGT中获得Session Key，再使用Session Key解密Authenticator，然后通过解密的信息验证来自客户端的请求是否可信。

通过验证之后，TGS生成Server Session Key主要用于第三阶段和服务器进行通信；同时TGS生成Ticket，Ticket是使用该服务的NTML hash加密的Server Session Key、客户端信息、时间戳。

将Server Session Key使用Session Key加密然后和Ticket一起发送给客户端。

Kerberos认证的第二阶段完成，总结一下第二阶段：

客户端收到第一阶段的数据之后，使用对应的NTLM-Hash解密获得Session Key，然后将TGT和Session Key存入内存中，当需要访问服务时使用TGT来获取Ticket。

在第二阶段中，客户端将收到的TGT和使用Session Key加密的客户端信息、时间戳等数据一并发送给TGS。

这里存在的安全问题，如果此时的数据被攻击者窃取，因为有加密短时间内攻击者无法破解数据，时间戳的存在可以让KDC验证数据是否可信。

KDC收到TGT和其他数据后，首先解密TGT（只有KDC才能解密TGT），解密完成获得Session Key，再使用Session Key解密其他数据，然后将解密出来的数据和TGT解密出来的数据进行比较，从而验证数据是否可信。当验证通过，TGS会生成Server Session Key，然后使用Session Key加密Server Session Key。

同时使用该服务的NTML hash加密的Server Session Key、客户端信息、时间戳生成最后的Ticket。KDC会将使用Session Key加密Server Session Key和Ticket一并发送给客户端。客户端收到数据之后就可以和服务端通信了。

4.3 AP-REQ & AP-REP

第三阶段客户端开始和服务端进行通信。

客户端收到Ticket和其他数据后首先解密Session Key加密的Server Session Key得到Server Session Key并缓存本地，客户端无法解密Ticket，但是可以使用这个Ticket。

为了安全考虑，Kerberos协议还支持双向验证，即只有客户端和服务端互相都认证通过，确认对方身份之后才会建立起通信连接。实际进行访问时，如果客户端需要认证访问的服务端是否可信，客户端可以在发送的请求中设置是否需要双向认证的标志位。

这里的认证过程是双向认证：

1、服务端验证客户端：防止非法用户操作

当需要访问服务时，客户端将Ticket和使用Server Session Key加密的客户端信息和时间戳发送给服务端。

服务端收到客户端的请求，使用该服务的NTML hash解密Ticket，得到Server Session Key，再使用Server Session Key解密其他数据，然后将解密出来的数据和Ticket解密出来的数据进行比较，验证通过后，因为启用了PAC，服务端会将PAC发送给DC询问此用户是否有访问权限。DC收到PAC后会解密PAC，然后通过PAC中的SID判断用户信息、用户权限等，最后将结果返回到服务端。这里如果设置了ACL，服务端还会判断ACL有没有限制用户请求的服务，全部通过后服务端成功验证客户端。

2、客户端验证服务端：防止误入恶意服务

服务端将使用Server Session Key加密的客户端信息和时间戳（这里的时间戳是第三阶段客服端发送给服务端的时间戳）发送给客户端，客户端使用Server Session Key解密数据，解密成功之后客户端将时间戳和原来发送的时间戳进行对比，如果一致则客户端成功认证服务端。

Kerberos认证的第三阶段完成，Kerberos认证完成，客户端和服务端建立通信。

0x05 PAC

在上面我们提到了PAC，什么是PAC，为什么要有PAC？

当没有使用PAC时，通过Kerberos的认证过程可以知，在第三阶段服务端成功解密Ticket，认证成功就会允许客户端开始访问服务端。

虽然看起来整个过程没有什么问题，但是因为没有PAC也就是服务端不会再次向DC确认用户是否有访问权限。这里就存在了一个安全问题，任何一个用户只要有了Ticket就可以访问服务。

微软为了解决这个问题就引入了PAC，改进了Kerberos认证过程。

在第一阶段，KDC发送给客户端的TGT中就包含了PAC，PAC中有用户的SID、用户所在的组。
在第三阶段，服务端解密Ticket验证通过后，还会将PAC发送给DC询问此用户是否有访问权限。

并且PAC在整个认证过程是不可见的，只有KDC可以制作和查看PAC，可见有了PAC的存在，使整个认证过程更加安全。

如果有些服务没有验证PAC，就说明只要用户拥有了Ticket，就可访问服务，这就是白银票据可以成功的前题。

0x06 参考链接

• https://www.secpulse.com/archives/94848.html

• https://www.freebuf.com/articles/network/273725.html

• https://xz.aliyun.com/t/8187#toc-4

• https://daiker.gitbook.io/windows-protocol/kerberos

• http://www.h3c.com/cn/d_201309/922101_30005_0.htm

• https://loong716.top/posts/Kerberos/#0x01-kerberos%E6%95%B0%E6%8D%AE%E5%8C%85%E5%88%86%E6%9E%90