序

Kerberos认证过程之前学过、看过、抓包分析过很多遍，在很长时间不打AD之后又忘的差不多了，重新看起来又要花费不少的时间。我相信不止我一个人有这方面的烦恼，于是该篇结合一些个人思路，拿生活中的案例举例，让大家更好的理解和记忆住Kerberos的完整认证过程。

注：本文仅分析了大致的交互过程，PAC等未涉及

0x01 Kerberos基本概念

Kerberos是一套安全认证协议，他的出现主要为了解决“证明你是你”的问题，让客户端和服务端建立信任机制。

如果让互不认识的甲乙互相见面，双方怎么知道对方真的是本人呢？一般的解决办法都是一个证件或者信物，证明他们自己的身份，来保证信任关系。

Kerberos协议涉及了一个第三方角色KDC来分别确认双方的身份。

在完整的Kerberos协议模型中主要包含三个角色概念：

• 客户端：发起服务请求的角色

• 服务端：提供服务访问的角色

• 密钥分发中心（Key Distribution Center 简称KDC），KDC作为活动目录域服务ADDS的一部分运行在每个域控制器上。而KDC又分为两部分：

  1.认证服务（Authentication Service 简称AS）：主要做客户端的认证

  2.票据授予服务（Ticket Granting Service 简称TGS）: 主要做凭证生成

大致过程如下：

在讲解具体的认证过程前，需要先明确Kerberos着重解决了什么问题：

1. 密码安全传输问题：采用加密的票据（ticket）和会话密钥（session key），用户的密码在认证过程中不会在网络上以明文形式传输，防止密码泄露和中间人攻击。
2. 重放攻击和身份伪造问题：使用时间戳和一次性的认证器（Authenticator），结合加密的会话密钥，来防止重放攻击。即使攻击者截获了身份凭证或票据，由于这些凭证是一次性的并带有时间限制，攻击者无法重复使用。
3. 中心化和统一身份验证：实现了单点登录（SSO，Single Sign-On），用户只需进行一次身份验证，就可以获取用于访问多个服务的票据，而不需要每次访问服务都重新输入密码。这极大简化了用户体验，并通过中心化的认证服务器统一管理身份验证过程。
4. 重复密码验证的麻烦：通过引入 TGT（票据授予票据）和服务票据，使得用户只需一次登录认证，随后可以在整个会话中使用票据与多个服务进行安全通信，而不需要重复输入密码。

0x02 大厦访客管理系统

作为乙方去客户现场，走了太多次访客流程。

一个完整的访客流程大概是：

1. 提前在访客系统提交申请。
2. 进入前台，前台验证访客信息
3. 办理门禁卡
4. 刷门禁卡进入客户办公楼

对应着上面Kerberos，这套流程有着不少问题：

1. 门禁卡过期，就要重新验证访客信息，重复验证很麻烦，如果一个项目持续很久，每次你进客户大厦都严格的一项一项验证访客信息就变得及其麻烦。

2. 门禁卡遗失后，捡到的人依然可以使用。

3. 第一个问题，我们在验证完访客信息后，可以考虑生成一个访客证，过期时候还可以使用这个访客证重新申请门禁卡。（当然这个访客证也要考虑丢失的问题）

4. 第二个问题，在每次验证时，可以在传输的凭证里面保存一些信息，同时这部分信息可以在申请凭证时获得，这样就能保证捡到的人无法直接使用凭证做下一步验证。（因为他们不知道这部分信息）

0x03Kerberos认证过程

在联系到大厦访客系统前，先要重点明确几点，这样在后续的案例对应的时候，举例子能更清晰：

• Kerberos具备着防窃听、防重放的特性。

我们可以先设计一个简易的访客系统，想象如果有近源的攻击者在附近。如果近源攻击者窃听、重放（复制）了获取的数据，能否可以进行伪造身份，如果可以，我们考虑一点一点优化，最后优化了问题，这个访客系统就是Kerberos的实际案例了。

因为我们上面提出了这个访客系统的两个问题，我们优先解决第一个问题，那就是增加访客证的办理，这样就把前台拆成了两部分。

访客证办理处（AS）、门禁卡办理处（TGS）。

1.AS请求过程（办理访客证）

现实办理访客证

在我们生活中如何办理访客证呢？可能是如下的步骤：

• 先表明自己身份
• 前台查看是否进行了预约
• 验证身份
• 办理访客证（TGT）

这个过程中，如果有近源的攻击者会发生什么？

• 攻击者在第3步你输入个人信息和短信验证码时，偷听和偷看。（窃听）
• 攻击者在第4步你拿到访客证时候，把访客证偷走或偷偷复制一张一样的，这里假设访客证是最普通的那种NFC的了。（重放）

防止窃听很简单，我们和前台歪比巴卜（加密通话）就可以了，加密通话总要有规律（密钥），这个规律（密钥）怎么让双方都已知，而且不被窃听呢？

• 使用预约记录的信息做规律就可以了，这样就避免了密钥传输的安全性问题，防止被窃听。

如何防止访客证被偷或者被复制呢？

• 利用上面的思路，我们可以要求在使用访客证办理门禁卡的时候，必须和门禁卡办理人员加密通话（说明这张访客证是谁的）才能用。

加密通话真的就安全吗？

回到上面的案例：第3步我们和前台”歪比歪比、歪比巴卜“认证信息。攻击者在我们旁边，偷偷把对话录下来，虽然他不知道”歪比歪比、歪比巴卜“具体是什么，但是肯定代表了你的认证信息，这样他就可以用一样的语言，申请到访客证，同时使用加密通话使用访客证。怎么解决这个问题呢？

• 我们在每次加密通话时，带上说话的时间就可以了，这样每次加密通话的内容都会不一样，就算被复制，前台也可以通过解密知道这句话的时间完全对不上。

如何处理和门禁卡办理人员的加密通话呢？

上面分析了，和访客前台加密通话的规律（密钥）是从预约信息中获取的，但是门禁卡的人员是不知道的。

• 我们可以在生成访客证的时候，把这个规律放在访客证里面，同时前台把这个规律通过之前的加密方式，在办理访客证的时候同时告知。这样就完成了和门禁卡办理人员的加密通话问题。

优化后的办理流程

整理一下现在的办理流程：

1. 用户向前台表明身份
2. 前台查询预约信息
3. 加密通话认证信息
4. 办理访客证+和后续门禁卡办理人员的加密通话密钥

再分析一下步骤，我们没必要等着前台回复是否查到预约记录，直接把1，3步骤整合在一起。

前台通过查询我们的预约信息，发现可以成功解密“加密通话”，那其实也就证明了我们的身份。

那我们第3步的加密通话应该说什么呢？

上面我们分析了，一定要防止别人偷听，也就是每次的加密通话都要不一样，我们可以采取“当前时间”的方式。

我们的密钥也要传递进去吗？

不需要，因为我们本身加密通话就是使用规律（密钥）加密的，已经证明了我们的身份，没必要使用密钥去加密密钥传递过去。

最终优化好的办理流程如下：

与Kerberos协议的对比

用户密钥：预约系统的用户信息（这里的预约系统实际对应了AD的NTDS.dit数据库）

TGT：访客证（因为门禁卡办理处要读取访客证，因此访客证的加密方式一定是门禁卡办理处也要知道的，对应的加密使用了KDC的用户密钥）

看回Kerberos的AS请求和响应过程，是不是就变得清晰很多了呢：（直接拿谢公子的图来说了，暂时没找到其他看的清晰的图，自己也懒得画，见谅）

1. AS-REQ 请求包

   本机向KDC的AS服务（访客证办理处）发送一个认证请求。该请求包中包含如下信息：

   · 请求的用户名(cname)。（访客名称，我是张三）

   · Authenticator：这里是用户密钥加密的时间戳，防止重放攻击。（加密通话，歪比歪比）

   · 域名(realm)。

   · 请求的服务名(sname)：AS-REQ这个阶段请求的服务都是krbtgt。

   · 加密类型(etype)。

   · 以及一些其他信息：如版本号，消息类型，票据有效时间，是否包含PAC，协商选项等。

2. AS-REP 响应包

   当KDC的AS服务（访客证办理处）到客户端发来的请求后，从活动目录数据库中取出该用户的密钥（从访客记录中寻找张三登录的信息作为规律），然后用该密钥（规律）对请求包中的Authenticator部分（加密通话）进行解密，如果解密成功，并且时间戳在有效的范围内，则证明请求者提供的用户密钥正确。

   KDC的AS认证服务在成功认证客户端的身份之后，发送AS-REP响应包给客户端。AS-REP响应包中主要包括如下信息：

   · TGT认购权证：包含明文的版本号，域名，请求的服务名，以及加密部分enc-part。加密部分用krbtgt密钥加密。加密部分包含Logon Session Key、用户名、域名、认证时间、认证到期时间和authorization-data。authorization-data中包含最重要的PAC特权属性证书，包含用户的RID，用户所在组的RID等。（TGT作为访客证，因为访客证在后面的门禁卡办理处需要读取，因此使用对应密码加密）

   · enc_Logon Session Key：使用用户密钥加密Logon Session Key后的值，其作用是用于确保客户端和KDC下阶段之间通信安全。也就是AS-REP中最外层的enc-part。（使用和张三交流的规律，加密新的规律，用于和门禁卡办理处的加密通话）

   · 请求的用户名(cname)。

   · 域名(crealm)。

   · 以及一些其他信息：如版本号，消息类型等。

2.TGS请求过程（办理门禁卡）

和上面的方式类似，只不过我们加密通话的规律（密钥），从个人信息变成了从访客证办理处（AS）获取的。

优化后的办理流程

• 把访客证（TGT）递交给门禁卡办理处（TGS），因为访客证（TGT）不能单独使用，需要玛卡巴卡阿卡哇卡（全新的加密通话）。

• 因为加密通话的规律（密钥）存储在访客证（TGT）中，因此门禁卡办理处（TGS）可以获取，也就可以听懂加密通话。（加密通话的内容，我们上面也分析过，只需要说“当前时间”即可。）

• 门禁卡办理处（TGS）使用访客证（TGT）中的信息解密我们发出玛卡巴卡阿卡哇卡（加密通话），发现可以成功解密，验证了身份，同时发现”当前时间“也对得上，可以验证通过。

• 正常发放门禁卡（ST）+与公司门禁保安的加密通话。加密通话的规律也保存在门禁卡（ST）中，保证门禁卡（ST）不会被捡到的人直接使用。

与Kerberos协议的对比

1. TGS-REQ 请求

客户端拿着上一步获得的TGT（访客证）认购权证发起请求，向TGS（门禁卡办理处）购买针对指定服务的ST（门禁卡）服务票据，该请求主要包含如下信息：

· TGT认购权证。（访客证）

· Authenticator：这里使用Logon Session Key加密的时间戳，防止重放攻击。（加密通话，玛卡巴卡）

· 请求的服务名(sname)。（客户名）

· 域名(realm)。

· 加密类型(etype)。

· 以及一些其他信息：如版本号，消息类型，协商选项，票据到期时间等

1. TGS-REP 响应

TGS服务（门禁卡办理处）接收到请求之后。首先使用krbtgt密钥解密TGT认购权证中加密部分得到Logon Session key等信息（生成访客证的时候，把规律加密写入了里面，所以门禁卡办理处可以直接读取规律），如果能解密成功则说明该TGT认购权证是KDC颁发的（说明访客证有效）。然后使用Logon Session Key解密Authenticator得到时间戳等信息，如果能够解密成功，并且票据时间在范围内，则验证了会话的安全性。（使用规律成功解密发起的加密通话玛卡巴卡，且验证了时间）在完成上述的检测后，KDC的TGS服务完成了对客户端的认证，TGS服务发送响应包给客户端。响应包中主要包括如下信息：

· ST服务票据：包含明文的版本号，域名，请求的服务名，以及加密部分enc-part，加密部分用服务密钥加密。加密部分包含用户名、域名、认证时间、认证到期时间、Service Session key和authorization-data。authorization-data中包含最重要的PAC特权属性证书，包含用户的RID，用户所在的组的RDI 等。（门禁卡）

· enc_Service Session key：使用Logon Session key加密的Service Session key，其作用是用于确保客户端和KDC下阶段之间通信安全。（使用和访客证的规律，加密新的规律，用于和刷卡处保安的加密通话）

· 请求的用户名(cname)

· 域名(crealm)

· 以及一些其他信息：如版本号、消息类型等。

3.Server请求过程（门禁刷卡）

与Kerberos协议的对比

1. AP-REQ 请求

客户端接收到KDC的TGS回复后，通过缓存的Logon Session Key解密enc_Service Session key得到Service Session Key，（通过从访客证办理处获取的规律，拿到新的规律）同时它也拿到了ST(门禁卡)服务票据。Serivce Session Key 和 ST服务票据会被客户端缓存。

客户端访问指定服务时，将发起AP-REQ请求，该请求主要包含如下的内容：

· ST服务票据（门禁卡）

· Authenticator：这里指Serivce Session Key加密的时间戳。（加密通话，妈咪妈咪哄）

· 以及一些其他信息：如版本号、消息类型，协商选项等

1. 服务端解码ST，使用其中的sessionKey解码时间戳，发现时间戳没有问题，成功通过验证。

0x04 票据攻击

通过我们上面的模型分析，对于黄金票据和白银票据就很好理解了：

黄金票据

• 黄金票据就是在访客证办理处出现了内鬼，导致可以伪造出一个完整的访客证，同时也能解决加密通话的问题，导致可以随便申请门禁卡，想去哪就去哪。（访客证的加密是使用了门禁卡办理处的密码，因为门禁卡办理处要解密识别）

具体伪造需要什么呢，其实就是TGT（访客证）包含的东西：

1、域名称(shell net config workstation )
2、域的SID值(shell whoami /user)
3、域的KRBTGT账号的HASH （门禁卡办理处的密码）
4、任意用户名

白银票据

• 白银票据就是在门禁卡办理处出现了内鬼，导致伪造出一个完整的门禁卡，同时也能解决加密通话问题，伪造的门禁卡可以刷卡指定公司的门禁。（门禁卡的加密是使用了指定公司的密码，因为公司处要解密识别）

伪造ST（门禁卡）需要：

1.域名称(shell net config workstation )
2.域的SID值(shell whoami /user)
3.目标服务器名
4.可利用的服务
5.服务账号的NTML HASH（指定公司的密码）
6.需要伪造的用户名

为什么伪造的ST（门禁卡）叫做白银票据呢？因为我们发现，伪造的ST（门禁卡）的用途有限，只能对指定服务（公司）使用，而伪造TGT（访客证）却可以申请到任意服务（公司）的门禁卡。白银比黄金差一些

0x05 认证流程攻击

AS_REQ（请求办理访客证）

• PTH

这个就不举实例了，这个很好理解，就是在整个验证的时候使用的不是明文，而是Hash，或者说是Hash和处理过的Hash（处理过的Hash就是上面说的加密通话的规律），获取用户的hash就可以进行认证利用，而不是完整明文。

• 域内用户枚举

回到实例，我们在办理访客证时会说明身份，但是如果未在预约信息中，前台肯定会给出提醒，说我们没有做预约（找不到规律去解密加密通话），我们就可以利用这个特性来测试谁预约过了。（域内是否存在某用户）

• 密码喷洒攻击

我们如果偶然间获取了某位用户的加密通话规律，但是不知道具体是谁的。显然可以去前台说出大量用户名进行批量尝试。

AS_REP（访客证攻击）

• 黄金票据

上面分析过

• AS-REP Roasting攻击

域用户有一个"Do not require Kerberos preauthentication”不需要预认证选项（默认不开启）

在实例中可以理解为，不验证用户发出的加密通话。这样就可以直接拿到TGT（访客证）和下次加密通话的规律（但是这个规律也是拿用户Hash做加密的）

我们可以对这个"下次加密通话的规律"使用字典尝试破解，因为是对称加密，所以尝试破解，这样可以尝试拿到用户的明文密码。

TGS_REP（门禁卡攻击）

• 白银票据

上面分析过

• Kerberosasting 攻击

我们知道ST（门禁卡）是使用对应服务（公司）的密码加密的，因为是对称加密，所以可以使用字典爆破。尝试破解获取服务Hash（公司密码）。

这个攻击能进行的原因也有：用户使用TGT可以申请任意服务的ST，因为这个步骤没有对用户是否可以访问该服务做验证。

这样我们拿到某个域用户的凭证后，即可考虑向所有服务请求ST，然后进行破解。

上面我们能爆破用户和服务的密码，为什么不能爆破KDC的密码呢？

因为krbtgt的密码是随机生成的，爆破不出来。

参考链接

https://cloud.tencent.com/developer/article/2227940#:~:text=%E7%A4%BE%E5%8C%BA%E9%A6%96%E9%A1%B5%20%3E%20%E4%B8%93

https://xz.aliyun.com/t/15367?time__1311=GqjxnD2DyDRDcDRx05DKg%2BEb2xqQu00pD#toc-6