朋友们现在只对常读和星标的公众号才展示大图推送，建议大家把“亿人安全“设为星标”，否则可能就看不到了啦

原文链接：https://xz.aliyun.com/t/14534

一、前言

Kerberos协议是一个专注于验证通信双方身份的网络协议，不同于其他网络安全协议的保证整个通信过程的传输安全，kerberos侧重于通信前双方身份的认定工作，帮助客户端和服务端解决“证明我自己是我自己”的问题，从而使得通信两端能够完全信任对方身份，在一个不安全的网络中完成一次安全的身份认证继而进行安全的通信。

1.1 什么是Kerberos协议

kerberos是一种计算机网络认证协议，他能够为网络中通信的双方提供严格的身份验证服务，确保通信双方身份的真实性和安全性。不同于其他网络服务，kerberos协议中不是所有的客户端向想要访问的网络服务
发起请求，他就能够建立连接然后进行加密通信。而是在发起服务请求后必须先进行一系列的身份认证，包括客户端和服务端两方的双向认证，只有当通信双方都认证通过对方身份之后，才可以互相建立起连接，
进行网络通信。即kerberos协议的侧重在于认证通信双方的身份，客户端需要确认即将访问的网络服务就是自己所想要访问的服务而不是一个伪造的服务器，而服务端需要确认这个客户端是一个身份真实，安全可
靠的客户端，而不是一个想要进行恶意网络攻击的用户。本文将详细概述kerberos认证原理，讲述通信双方是如何一步步确认对方身份完成认证的。

1.2 Kerberos 结构和操作

Kerberos 因协议中的三个不同参与者。

• 客户：寻求提供其身份的实体

• 应用服务器（AP）：客户端或用户想要访问的服务

• 密钥分发中心（KDC）：颁发票据的可信第三方。

几乎所有操作系统都支持 Kerberos，包括 Apple OSX/iOS 以及许多 UNIX 和 Linux 发行版。然而，Microsoft Active Directory是使用最广泛的 Kerberos 实现。它基于Kerberos 网络身份验证服务 (V5)。

在 Active Directory 中，每个域控制器充当 KDC 并提供两项核心服务：

• 身份验证服务 (AS) — 对客户端进行身份验证并向其颁发票据

• 票证授予服务 (TGS) — 接受经过身份验证的客户端并向其颁发票证以访问其他资源

门票采用对称加密技术。某些用户密码用于加密和签署特定票证，但 Kerberos 安全性的根源是只有颁发票证的受信任第三方知道的密钥。

1.3 Kerberos 身份验证过程

Kerberos 身份验证的每个步骤都采用加密技术来保护数据包不被更改或读取，并提供相互身份验证。客户端向 KDC 请求用户的票证，并使用用户的密码对请求进行加密。如果 KDC 可以使用其存储的用户密码解密请求，则它知道客户端已为用户提供了正确的密码。KDC为用户创建票证授予票证（TGT），用用户的密码对其进行加密，然后返回给客户端。如果客户端可以使用用户的密码解密该票证，则它知道 KDC 是合法的。

客户端通过提供其 TGT 和票证授予服务 (TGS) 请求（其中包括其想要访问的服务的服务主体名称）来向 KDC 请求服务票证。KDC 创建使用服务的密码哈希（TGS 密钥）加密的服务票证 (TGS)，使用共享票证授予服务会话密钥对票证和身份验证器消息进行加密，最后将 TGS 发送回客户端。

客户端通过向应用程序服务器提供从 KDC 获取的服务票证来请求访问应用程序服务器（服务），应用程序服务器使用自己的密码哈希来解密该消息。如果成功解密 TGS，应用程序服务器将授予客户端访问权限。

KRB_AS_REQ：从身份验证服务（AS）请求 TGT

客户端的请求包括用户的用户主体名称 (UPN) 和时间戳。它使用用户的密码哈希进行加密。

KRB_AS_REP：从身份验证服务接收到的 TGT

KDC 使用 UPN 在其数据库中查找客户端，并使用用户的密码哈希来尝试解密消息。

AS 生成包含客户端 ID、客户端网络地址、时间戳、生存期和会话密钥 (SK1) 的 TGT。

如果 KDC 成功解密 TGT 请求，并且时间戳在 KDC 配置的时间偏差内，则身份验证成功。

TGT 和 TGS 会话密钥被发送回客户端。TGS 会话密钥用于加密后续请求。

KRB_TGS_REQ：当前 TGT 和 TGS 请求

客户端提供其 TGT 以及包含其想要访问的服务的 SPN 的请求。TGS 请求使用 TGS 会话密钥进行加密。

KRB_TGS_REP：从 KDC 接收 TGS

KDC 尝试验证 TGT；如果成功，它会生成一个 TGS，其中包含有关请求者的信息，例如其 SID 和组成员身份，并使用服务的密码哈希进行加密。

TGS 和服务会话密钥使用 TGS 会话密钥加密并发回客户端。

KRB_AP_REQ：向应用程序服务器提供 TGS 进行授权

客户端将从 KDC 收到的 TGS 以及使用服务会话密钥加密的身份验证器消息发送到应用程序服务器。

KRB_AP_REP：授予客户端对服务的访问权限

客户端接收消息并使用服务会话密钥对其进行解密。

应用程序服务器从服务票证中提取权限属性证书 (PAC)，以通过域控制器验证其内容。

仅当 TGT 超过 20 分钟时才会验证票证和 PAC。

1.4 kerberos的影响因素

• 域控制器之间需要复制。
  如果部署了多个域控制器（因此也有多个 KDC），则必须启用并及时进行复制。如果复制失败或延迟，用户更改密码时身份验证可能会失败。

• 客户端和 KDC 必须使用 NetBIOS 和 DNS 名称解析。
  Kerberos 服务主体名称通常包括 NetBIOS 和 DNS 地址，这意味着 KDC 和客户端必须能够以相同的方式解析这些名称。在某些情况下，IP 地址也可以用在服务主体名称中。

• 客户端和 KDC 的时钟必须同步。
  准确测量时间对于防止重放攻击非常重要。Kerberos 支持可配置的时间偏差（默认情况下为 5 分钟），超出该时间偏差客户端身份验证将失败。

• 客户端和 KDC 必须能够在网络上进行通信。
  Kerberos 流量发生在 TCP 和 UDP 端口 88 上，所有客户端都必须能够访问该端口，并且至少有一个 KDC。

• 客户端、用户和服务必须具有唯一的名称。
  计算机、用户或服务主体名称的重复凭据可能会导致意外的 Kerberos 身份验证

1.5 Kerberos 原理

在深入了解 Kerberos 原理之前，先介绍一下 Kerberos 协议的几个大前提，帮助大家理解：

1. Kerberos 基于 Ticket 实现身份认证，而非密码。如果客户端无法利用本地密钥，解密出 KDC 返回的加密Ticket，认证将无法通过。

2. 客户端将依次与 Authentication Service, Ticket Granting Service 以及目标Service进行交互，共三次交互。

3. 客户端与其他组件交互是，都将获取到两条信息，其中一条可以通过本地密钥解密出，另外一条将无法解密出。

4. 客户端想要访问的目标服务，将不会直接与KDC交互，而是通过能否正确解密出客户端的请求来进行认证。

5. KDC Database 包含有所有 principal 对应的密码。

6. Kerberos 中信息加密方式一般是对称加密（可配置成非对称加密）。

下面，我们将以客户端访问 http 服务为例，解释整个认证过程。
Kerberos 协议是一种计算机网络授权协议，用来在非安全网络中，对个人通信以安全的手段进行身份认证。其设计目标是通过密钥系统为客户机与服务器应用程序提供强大的认证服务。该协议的认证过程的实现不依赖于主机操作系统的认证，无需基于主机地址的信任，不要求网络上所有主机的物理安全，并假定网络上传送的数据包可以被任意地读取、修改和插入数据。在以上情况下， Kerberos 作为一种可信任的第三方认证服务，是通过传统的密码技术（如：共享密钥）执行认证服务的。Kerberos 协议在在内网域渗透领域中至关重要，白银票据、黄金票据、攻击域控等都离不开 Kerberos 协议。

你需要先了解以下几个关键点：

角色：Domain Controller 域控制器，简称 DC，一台计算机，

实现用户、计算机的统一管理。

Key Distribution Center 秘钥分发中心，简称 KDC，默认安装在域控里，包括 AS 和 TGS。

Authentication Service 身份验证服务，简称 AS，用于 KDC对 Client 认证。

Ticket Grantng Service 票据授予服务，简称 TGS，用于KDC 向 Client 和 Server 分发

Session Key（临时秘钥）。Active Directory 活动目录，简称 AD，用于存储用户、用户组、域相关的信息。

角色作用：

Client 客户端，指用户。

Server 服务端，可能是某台计算机，也可能是某个服务。

打个比方：当 whoami 要和 bunny 进行通信的时候，whoami 就需要向 bunny 证明自己是 whoami，直接的方式就是 whoami 用二人之间的秘密做秘钥加密明文文字生成密文，把密文和明文文字一块发送给 bunny，bunny 再用秘密解密得到明文，把明文和明文文字进行对比，若一致，则证明对方是 whoami。但是网络中，密文和文字很有可能被窃取，并且只要时间足够，总能破解得到秘钥。所以不能使用这种长期有效的秘钥，要改为短期的临时秘钥。那么这个临时秘钥就需要一个第三方可信任的机构来提供，即 KDC（Key Distribution Center）秘钥分发中心。

1.6 Kerberos 与 LDAP区别

Kerberos 和 LDAP 通常一起使用（包括在 Microsoft Active Directory 中），以提供集中式用户目录 (LDAP) 和安全身份验证 (Kerberos) 服务。

LDAP 在中央位置存储有关用户、组和其他对象（如计算机）的信息。它还可以提供简单的身份验证；然而，与Kerberos 不同，该协议通常需要通过网络传输用户的秘密（即密码）。用户想要访问的每个资源都必须处理用户的密码并单独对目录进行用户身份验证。

与 LDAP 不同，Kerberos 提供单点登录功能。一旦用户通过 KDC 的身份验证，其他服务（如 Intranet 站点或文件共享）就不需要该用户的密码。KDC 负责颁发每个服务信任的票证。

LDAP 和 Kerberos 的组合提供了集中的用户管理和身份验证，并且在较大的网络中，Kerberos 提供了显着的安全优势。

二、Kerberos认证流程简介

在kerberos协议当中总共有三个不同的角色，客户端和服务端就不用多说了，一个是请求的发起者一个是请求的接收者，那么KDC是做什么的呢？答案是这样的~
在kerberos协议中，通信的双方在通信之前必须相互证明自己的身份是可靠并且具有访问权限的（后面会说为什么是要具有访问权限的），那么双方都要如何证明自己呢？口说无凭，客户端的请求中携带自己的身份信息直接给服务端，服务端是没有理由直接信任这段信息就是真实的信息的，同理，服务端返回自己的身份信息给客户端，客户端也同样是无法辨别该服务器是否是自己想要访问的服务器。

举个例子，A现在想要去访问B完成一个任务。但是AB两人之间是从来没有见过面的，他们只知道对方的名字叫A，B。此时如果A直接去找B告诉B我就是A，那么B是有理由不相信A的，因为即使A是一个冒充的他也分辨不清，B同理也得不到A的认可，他们陷入了一个无法证明我就是我的困境。于是他们就想到了一个办法，AB找到了一个他俩共同信任的人C，且这个C既认识A又认识B，所以只要C告诉B，这个A确实就是真正的A那么B就会信任这个A，同理B经过C的认可后，A也会相信B的身份。此后，A在访问B之前会先去找C，C会交给A一个凭证，代表此时的A已经得到了C的认证，这时A拿着凭证再去找C，便可以得到C的确认了。在上面的例子中，A，B分别是客户端和服务端，C担任的角色便是KDC，全称Key Distribution Center，中文名叫做密钥分发中心。KDC中包含一个叫做TGS（票据授予中心）的组件，我们便可以理解为他就是一个发放身份认证票据的服务中心，在KDC认证了（其实是KDC中的AS认证的）客户端的身份后，他会给客户端发放用于访问网络服务的服务授予票据（Ticket）。由于整个kerberos通信过程都采用对称加密的方式，密钥的获取也是从KDC中得到，所以KDC叫做密钥分发中心。

所以整个kerberos认证流程可以简化描述如下：
客户端在访问每个想要访问的网络服务时，他需要携带一个专门用于访问该服务并且能够证明自己身份的票据，当服务端收到了该票据他才能认定客户端身份正确，向客户端提供服务。所以整个认证流程可简化为两大步：

1. 客户端向KDC请求获取想要访问的目标服务的服务授予票据（Ticket）；

2. 客户端拿着从KDC获取的服务授予票据（Ticket）访问相应的网络服务；

简化认证流程图：

2.1 Kerberos认证流程

上面说到了简化版的Kerberos认证流程，基本上分为两步。第一步，客户端向KDC请求获得他想要访问的服务的服务授予票据（可以想象成去动物园，想去买一张能够进入动物园的门票）。第二步，拿着这张服务授予票据（Ticket）去访问服务端的服务。
大致的过程确实可以看作这两步，但其中还存在一些问题：
问题1. KDC怎么知道你（客户端）就是真正的客户端？凭什么给你发放服务授予票据（Ticket）呢？
问题2. 服务端怎么知道你带来的服务授予票据（Ticket）就是一张真正的票据呢？
这就需要开始细节的描述一下整个Kerberos认证的过程了~
上面提到整个流程可以简化为两大步，但其实在第一步中共做了两件事，这两件事解决了上述问题中的问题1；然后第二步解决了问题2，最终结束认证过程建立通信。所以整个Kerberos认证流程可以细化为三个阶段也可以
理解为三次通信!接下来从三个阶段三次通信的角度细说认证过程。

在具体描述整个认证流程之前，我们需要知道几个Kerberos认证的前提条件：

1. kerberos协议他是一个“限权”的认证协议，kerberos中会自带一个数据库，这个数据库会由创建kerberos的运维人员提前在库中添加好整个系统中拥有使用kerberos认证权限的用户和网络服务。在后续的认证中也是根据数据库中是否存在该用户和服务来判断该对象是否能够通过认证服务的。（拿上面的例子来说就是上帝先让C在AB相识之前同时认识A和B，以便后面帮助AB互相认证）

2. 所有使用kerberos协议的用户和网络服务，在他们添加进kerberos系统中时，都会根据自己当前的密码（用户密码，人为对网络服务随机生成的密码）生成一把密钥存储在kerberos数据库中，且kerberos数据库也会同时保存用户的基本信息（例如用户名，用户IP地址等）和网络服务的基本信息（IP，Server Name）

3. kerberos中存在的三个角色，只要是发生了两两之间的通信，那么都需要先进行身份的认证

2.2 ASREQ & ASREP

该阶段是 Client 和 AS 的认证，通过认证的客户端将获得 TGT 认购权证。当域内某个客户端用户 Client 视图访问域内的某个服务，于是输入用户名和密码，此时客户端本机的 Kerberos 服务会向 KDC 的 AS 认证服务发送一个 AS_REQ 认证请求。请求的凭据是 Client 的哈希值 NTLM-Hash 加密的时间戳以及 Client-info、Server-info 等数据，以及一些其他信息。

过程如下：

① 客户端用户向KDC以明文的方式发起请求。该次请求中携带了自己的用户名，主机IP，和当前时间戳；
② KDC当中的AS（Authentication Server）接收请求（AS是KDC中专门用来认证客户端身份的认证服务器）后去kerberos认证数据库中根据用户名查找是否存在该用户，此时只会查找是否有相同用户名的用户，并不会判断身份的可靠性；
③ 如果没有该用户名，认证失败，服务结束；如果存在该用户名，则AS认证中心便认为用户存在，此时便会返回响应给客户端，其中包含两部分内容：

• 第一部分内容称为TGT，他叫做票据授予票据，客户端需要使用TGT去KDC中的TGS（票据授予中心）获取访问网络服务所需的Ticket（服务授予票据），TGT中包含的内容有kerberos数据库中存在的该客户端的Name，IP，当前时间戳，客户端
  即将访问的TGS的Name，TGT的有效时间以及一把用于客户端和TGS间进行通信的Session_key(CT_SK)。整个TGT使用TGS密钥加密，客户端是解密不了的，由于密钥从没有在网络中传输过，所以也不存在密钥被劫持破解的情况。

• 第二部分内容是使用客户端密钥加密的一段内容，其中包括用于客户端和TGS间通信的Session_key(CT_SK),客户端即将访问的TGS的Name以及TGT的有效时间，和一个当前时间戳。该部分内容使用客户端密钥加密，所以客户端在拿到该部分内容时可以通过自己的密钥解密。如果是一个假的客户端，那么他是不会拥有真正客户端的密钥的，因为该密钥也从没在网络中进行传输过。这也同时认证了客户端的身份，如果是假客户端会由于解密失败从而终端认证流程。

2.3 TGSREQ & TGSREP

此时的客户端收到了来自KDC（其实是AS）的响应，并获取到了其中的两部分内容。此时客户端会用自己的密钥将第二部分内容进行解密，分别获得时间戳，自己将要访问的TGS的信息，和用于与TGS通信时的密钥CT_SK。首先他会根据时间戳判断该时间戳与自己发送请求时的时间之间的差值是否大于5分钟，如果大于五分钟则认为该AS是伪造的，认证至此失败。如果时间戳合理，客户端便准备向TGS发起请求，
其次请求的主要目的是为了获取能够访问目标网络服务的服务授予票据Ticket（进入动物园需要的门票）。在第二次通信请求中，客户端将携带三部分内容交给KDc中的TGS，第二次通信过程具体如下所述：

客户端行为：
① 客户端使用CT_SK加密将自己的客户端信息发送给KDC，其中包括客户端名，IP，时间戳；
② 客户端将自己想要访问的Server服务以明文的方式发送给KDC；
③ 客户端将使用TGS密钥加密的TGT也原封不动的也携带给KDC；
TGS行为：
① 此时KDC中的TGS（票据授予服务器）收到了来自客户端的请求。他首先根据客户端明文传输过来的Server服务IP查看当前kerberos系统中是否存在可以被用户访问的该服务。如果不存在，认证失败结束，。如果存在，继续接下来的认证。
② TGS使用自己的密钥将TGT中的内容进行解密，此时他看到了经过AS认证过后并记录的用户信息，一把Session_KEY即CT_SK，还有时间戳信息，他会现根据时间戳判断此次通信是否真是可靠有无超出时延。
③ 如果时延正常，则TGS会使用CK_SK对客户端的第一部分内容进行解密（使用CT_SK加密的客户端信息），取出其中的用户信息和TGT中的用户信息进行比对，如果全部相同则认为客户端身份正确，方可继续进行下一步。
④ 此时KDC将返回响应给客户端，响应内容包括：

• 第一部分：用于客户端访问网络服务的使用Server密码加密的ST（Servre Ticket），其中包括客户端的Name，IP，需要访问的网络服务的地址Server IP，ST的有效时间，时间戳以及用于客户端和服务端之间通信的CS_SK（Session Key）。

• 第二部分：使用CT_SK加密的内容，其中包括CS_SK和时间戳，还有ST的有效时间。由于在第一次通信的过程中，AS已将CT_SK通过客户端密码加密交给了客户端，且客户端解密并缓存了CT_SK，所以该部分内容在客户端接收到时是可以自己解密的。

2.4PAC

我们在前面关于 Kerberos 认证流程的介绍中提到了 PAC（Privilege AttributeCertificate）这个东西，这是微软为了访问控制而引进的一个扩展，即特权访问证书。

在上面的认证流程中，如果没有 PAC 的访问控制作用的话，只要用户的身份验证正确，那么就可以拿到 TGT，有了 TGT，就可以拿到 ST，有了 ST ，就可以访问服务了。此时任何一个经过身份验证的用户都可以访问任何服务。像这样的认证只解决了 "Who am i?" 的问题，而没有解决 "What can I do?" 的问题。

为了解决上面的这个问题，微软引进了 PAC。即 KDC 向客户端 Client 返回 AS_REP时插入了 PAC，PAC 中包含的是用户的 SID、用户所在的组等一些信息。当最后服务端 Server 收到 Client 发来的 AP_REQ 请求后，首先会对客户端身份验证。通过客户端身份验证后，服务器 Server 会拿着 PAC 去询问 DC 该用户是否有访问权限，DC 拿到 PAC 后进行解密，然后通过 PAC 中的 SID 判断用户的用户组信息、用户权

限等信息，然后将结果返回给服务端，服务端再将此信息域用户请求的服务资源的ACL 进行对比，最后决定是否给用户提供相关的服务。但是在有些服务中并没有验证 PAC 这一步，这也是白银票据能成功的前

提，因为就算拥有用户的 Hash，可以伪造 TGS，但是也不能制作 PAC，PAC 当然也验证不成功，但是有些服务不去验证 PAC，这是白银票据成功。

PAC的结构如下图所示。

PAC整体的结构上是一个AuthorizationData的结构

AuthorizationData       ::= SEQUENCE OF SEQUENCE {
ad-type         [0] Int32,
ad-data         [1] OCTET STRING
}

AuthorizationData结构的ad-type主要有以下几个

AD-IF-RELEVANT                     1
AD-INTENDED-FOR-SERVER             2
AD-INTENDED-FOR-APPLICATION-CLASS  3
AD-KDC-ISSUED                      4
AD-AND-OR                          5
AD-MANDATORY-TICKET-EXTENSIONS     6
AD-IN-TICKET-EXTENSIONS            7
AD-MANDATORY-FOR-KDC               8
Reserved values                 9-63
OSF-DCE                           64
SESAME                            65
AD-OSF-DCE-PKI-CERTID             66 
AD-WIN2K-PAC                     128 
AD-ETYPE-NEGOTIATION             129

2.5 AP-REQ & AP-REP

此时的客户端收到了来自KDC（TGS）的响应，并使用缓存在本地的CT_SK解密了第二部分内容（第一部分内容中的ST是由Server密码加密的，客户端无法解密），检查时间戳无误后取出其中的CS_SK准备向服务端发起最后的请求。

客户端：
① 客户端使用CK_SK将自己的主机信息和时间戳进行加密作为交给服务端的第一部分内容，然后将ST（服务授予票据）作为第二部分内容都发送给服务端。
服务端：
① 服务器此时收到了来自客户端的请求，他会使用自己的密钥，即Server密钥将客户端第二部分内容进行解密，核对时间戳之后将其中的CS_SK取出，使用CS_SK将客户端发来的第一部分内容进行解密，从而获得经过TGS认证过后的客户端信息，此时他将这部分信息和客户端第二部分内容带来的自己的信息进行比对，最终确认该客户端就是经过了KDC认证的具有真实身份的客户端，是他可以提供服务的客户端。此时服务端返回一段使用CT_SK加密的表示接收请求的响应给客户端，在客户端收到请求之后，使用缓存在本地的CS_ST解密之后也确定了服务端的身份（其实服务端在通信的过程中还会使用数字证书证明自己身份）。

至此，第三次通信完成。此时也代表着整个kerberos认证的完成，通信的双方都确认了对方的身份，此时便可以放心的进行整个网络通信了。

三、Kerberos  认证中的安全问题

Kerberos 认证并不是天衣无缝的，这其中也会有各种漏洞能够被我们利用，比如我们常说的 MS14-068、黄金票据、白银票据等就是基于 Kerberos 协议进行攻击的。

3.1 黄金、白银票据

在 Windows 的 kerberos 认证过程中，Client 将自己的信息发送给 KDC，然后 KDC使用 Krbtgt 用户的 NTLM-Hash 作为密钥进行加密，生成 TGT。那么如果获取到了Krbtgt 的 NTLM-Hash 值，不就可以伪造任意的 TGT 了吗。因为 Krbtgt 只有域控制器上面才有，所以使用黄金凭据意味着你之前拿到过域控制器的权限，黄金凭据可以理解为一个后门。

先假设这么一种情况，原先已拿到的域内所有的账户 Hash，包括 Krbtgt 这个账户，由于有些原因导致你对域管权限丢失，但好在你还有一个普通域用户权限，碰巧管理员在域内加固时忘记重置 Krbtgt 密码，基于此条件，我们还能利用该票据重新获得域管理员权限。利用 Krbtgt 的 Hash 值可以伪造生成任意的 TGT，能够绕

过对任意用户的账号策略，让用户成为任意组的成员，可用于 Kerberos 认证的任何服务。

白银票据（Silver ticket ）

白银票据不同于黄金票据，白银票据的利用过程是伪造 TGS，通过已知的授权服务密码生成一张可以访问该服务的 TGT。因为在票据生成过程中不需要使用KDC，所以可以绕过域控制器，很少留下日志。而黄金票据在利用过程中由 KDC颁发 TGT，并且在生成伪造的 TGT 得 20 分钟内，TGS 不会对该 TGT 的真伪进行检验。白银票据依赖于服务账号的密码散列值，这不同于黄金票据利用需要使用 Krbtgt账号的密码哈希值，因此更加隐蔽。

3.2 MS14-068

这里便用到了我们之前所讲到的 PAC 这个东西，PAC 是用来验证 Client 的访问权限的，它会被放在 TGT 里发送给 Client，然后由 Client 发送给 TGS。但也恰恰是这个 PAC 造成了 MS14-068 这个漏洞。该漏洞是位于 kdcsvc.dll 域控制器的密钥分发中心（KDC）服务中的 Windows 漏洞，它允许经过身份验证的用户在其获得的票证 TGT 中插入任意的 PAC 。普通用户可以通过呈现具有改变了 PAC 的 TGT 来伪造票据获得管理员权限。

3.3 密码喷洒攻击

在实际渗透中，许多渗透测试人员和攻击者通常都会使用一种被称为 “密码喷洒”（Password Spraying）的技术来进行测试和攻击。对密码进行喷洒式的攻击，这个叫法很形象，因为它属于自动化密码猜测的一种。这种针对所有用户的自动密码猜测通常是为了避免帐户被锁定，因为针对同一个用户的连续密码猜测会导致帐户被锁定。所以只有对所有用户同时执行特定的密码登录尝试，才能增加破解的概率，消除帐户被锁定的概率。普通的爆破就是用户名固定，爆破密码，但是密码喷洒，是用固定的密码去跑用户名。

3.4 AS-REP Roasting

我们前文说过，ASREQ & ASREP 认证的过程是 Kerberos 身份认证的第一步，该过程又被称为预身份验证。预身份验证主要是为了防止密码脱机爆破。而如果域用户设置了选项 "Do not require Kerberos preauthentication"（该选项默认没有开启）关闭了预身份验证的话，攻击者可以使用指定的用户去请求票据，向

域控制器发送 AS_REQ 请求，此时域控会不作任何验证便将 TGT 票据和加密的Session-key 等信息返回。因此攻击者就可以对获取到的加密 Session-key 进行离线破解，如果爆破成功，就能得到该指定用户的明文密码。

这种攻击方式被称作 AS-REP Roasting 攻击。

四、利用工具：

1.kekeo

地址：https://github.com/gentilkiwi/kekeo

2.impacket

地址：https://github.com/fortra/impacket

Impacket 是用于处理网络协议的 Python 类的集合。

以太网，Linux“Cooked”捕获。
IP、TCP、UDP、ICMP、IGMP、ARP。
IPv4 和 IPv6 支持。
NMB 和 SMB1、SMB2 和 SMB3（高级实现）。
MSRPC 版本 5，通过不同的传输：TCP、SMB/TCP、SMB/NetBIOS 和 HTTP。
使用密码/哈希/票证/密钥进行普通、NTLM 和 Kerberos 身份验证。
以下 MSRPC 接口的部分/完整实现：EPM、DTYPES、LSAD、LSAT、NRPC、RRP、SAMR、SRVS、WKST、SCMR、BKRP、DHCPM、EVEN6、MGMT、SASEC、TSCH、DCOM、WMI、OXABREF、NSPI、 OXNSPI。
TDS (MSSQL) 和 LDAP 协议实现的部分内容。

3.msf

kali里面自带。Metasploit Framework(MSF)是一款开源安全漏洞检测工具，附带数千个已知的软件漏洞，并保持持续更新。Metasploit可以用来信息收集、漏洞探测、漏洞利用等渗透测试的全流程，被安全社区冠以“可以黑掉整个宇宙”之名。刚开始的Metasploit是采用Perl语言编写的。

4.pykek

项目地址：https://github.com/mubix/pykek

5.Rubeus

项目地址：https://github.com/GhostPack/Rubeus

Rubeus 是一个用于原始 Kerberos 交互和滥用的 C# 工具集。

五、Kerberos 的好处：

整个kerberos认证的过程较为复杂，三次通信中都使用了密钥，且密钥的种类一直在变化，并且为了防止网络拦截密钥，这些密钥都是临时生成的Session Key，即他们只在一次Session会话中起作用，即使密钥被劫持，等到密钥被破解可能这次会话都早已结束。

优势：

1. 密码无需进行网络传输。基于 Ticket 实现身份认证，保障密钥安全性。

2. 双向认证。整个认证过程中，不仅需要客户端进行认证，待访问的服务也需要进行身份认证。

3. 高性能。一旦Client获得用过访问某个Server的Ticket，该Server就能根据这个Ticket实现对Client的验证，而无须KDC的再次参与。

REF:

https://www.anquanke.com/post/id/192810

https://zhuanlan.zhihu.com/p/266491528

https://www.fortinet.com/tw/resources/cyberglossary/kerberos-authentication