Kerberos协议分析及域服务器配置以及黄金白银票据攻击复现

一、实验目的与内容

根据参考资料搭建kerberos认证环境，并验证至少一个以下安全威胁：

Credential Caching

AS-REP Roasting

Kerberoasting

黄金票据攻击

白银票据攻击

委派攻击

二、实验原理与背景

（一）kerberos认证

一、关键名词 

（1）域控制器（Domain Controller，DC）：在域中至少有一台服务器负责每一台联入网络的电脑和用户的验证工作，相当于一个单位的门卫一样。 

（2）密钥分发中心（Key Distribution Center，KDC）：KDC维护着域中所有安全主体（SecurityPrincipal）账户信息数据库，负责管理票据、认证票据、分发票据。 

（3）帐户数据库（Account Database，AD）：一个类似于 Windows本机SAM的数据库，存储了域内所有网络对象的凭证，也存储所有Client的白名单，在白名单中的 Client才可以申请到TGT。 

（4）身份验证服务（Authentication Service，AS）：用于生成TGT的服务。 

（5）票据发放服务（Ticket Granting Service，TGS）：用于生成某个服务的ticket。

（6）认证票据（Ticket Granting Ticket，TGT）：可以理解为入场券，通过入场券能够获得票据，是一种临时凭证的存在。 

（7）票据（Ticket）：网络对象互相访问的凭证。 

（8）Master Key ：长期密钥（被 Hash加密的用户密钥），这里指 NTLM Hash，简单理解就是Windows加密过的密码口令。 

（9）Session Key ：短期会话密钥。

（10）krbtgt 账户：每个域控制器都有一个 krbtgt的用户账户，是 KDC的服务账户，用来创建票据授予服务(TGS)加密的密钥。

二、Kerberos认证中的三个角色

Client 

Server

KDC (DC) ：在Windows域环境中，KDC的角色由DC承担。

三、认证过程 

认证的大致过程：

Client向KDC的AS服务发送请求，希望获取访问Server的权限。KDC收到请求后，通过在帐户数据库AD中存储黑名单和白名单来区分Client是否可信。确认成功后，AS返回TGT给Client。 

Client得到了TGT后，继续向KDC的TGS服务发送请求，希望获取访问 Server的权限。KDC通过客户端请求信息中的TGT判断客户端是否拥有权限，确认成功返回访问Server的权限ticket。

Client得到ticket后，Client与Server二者进行相互验证，成功后，Client就可以访问Server的资源。

详细认证过程如下：

（1）Client 发送 AS Request 给 AS 。

AS Request 大致内容：

Pre-authentication data ：一个使用 Client 的 Master key加密过的 Timestamp（时间戳），用于证明自己是所发送用户名对应的那个用户。 

Client name & realm：Domain name\Client name ，Client标识，用于 KDC 从 AD 中查找Client 的 Master key 。 

Server Name ：KDC TGS 的 Server Name 。

（2）AS 接收到 Client 的请求信息，需要验证发送方是否为本人，而AS 只需从 AD 中获取 Client 对应的 Master Key 对 Pre-authentication data 进行解密验证其是否为合法的 Timestamp，若验证合格，则说明发送方在 AD 中且其密钥正确。但是当 Timestamp 比当前的时间偏差过多或者 Timestamp 早于上次认证时间点，AS 会直接拒绝。 

验证通过后，AS 将 AS Response 发送给 Client。主要包括请求 Client 的 Master Key加密过的Session Key 和被 KDC用户（krbtgt 帐户）使用其自己的 NTLM Hash 加密的 TGT 。TGT 的大致内容如下：

Session Key ：KDC 生成的一个随机字符串，用于后续 Client与TGS 服务之间的通信。

Client name & realm ：Domain name\Client 。

Server name & realm: 简单地说就是 Domain name\Server ， Client 访问的 Server 。

End Time ：TGT 到期时间。

（3）Client 使用自己的Master Key 可以将 AS返回的加密过后的 Session Key 解密，得到SessionKey。而后发送TGS Request 给 TGS ，请求Ticket。 

TGS Request 大致内容如下：

Authenticator ：使用 Session Key加密的Clien info（Client标识等信息）和 Timestamp（时间戳）。

TGT

Client info ：Domain name/ Client 。

Server info ：Client 要访问的 Server 的信息。

Timestamp ：时间戳 。

（4）TGS 收到TGS Request ，通过自己的 Master Key（NTLM Hash） 对 TGS Request 中的 TGT 进行解密，得到Session Key ，而后使用Session Key 解密 Authenticator 进行相关验证，验证成功后 TGS向 Client 发送 TGS Response 。TGS Response 主要包括两个部分，使用Session Key（KDC-Client）加密过的用于 Client 和 Server 通信的Session Key （Server-Client ）与使用 Server 的 Master Key 进行加密的Ticket 。

Ticket大致内容如下：

Session Key ：用于 Client 和 Server 通信的Session Key 。

Client name & realm : Domain name\Client 。

End time : Ticket的到期时间。

（5）Client 通过Session Key（KDC-Client）进行解密将 TGS Response 中用于与Server通信的SessionKey （Server-Client ）获取到。而后 Client 向 Server请求服务，发送Request其中包含Ticket，ServerSession Key加密的Client info与Timestamp，还包含一个 Flag 用于表示 Client 是否需要进行双向验证。 

（6）Server通过使用自己的 Master Key 解密用户请求中的 Ticket 得到 Session Key（Server-Client），使用 Session Key（Server-Client ）解密Client加密后的信息（Client info与Timestamp）进行验证，验证成功后，让 Client 访问需要访问的资源。若Client 需要进行双向验证，验证成功后，返回给 Client 使用 Session Key（Server-Client ）得到新时间戳并验证其是否正确。验证通过的话则Client可以信任该Server，可以发送服务请求。 

校验通过后，该票据会一直存在Client的内存中。

（二）白银票据

在请求票据发放过程中，Client 与 TGS 通信获取 Ticket，拥有 Ticket 就可以访问对应 服务器资源。而当攻击者拥有Server NTLM Hash时，就可以伪造一个 Ticket，直接与 Serve