Kerberos认证学习

在域中，网络对象可以相互访问，但是在真实情况中，需要对某些部门的计算机进行限制，例如：销售部门不能访问技术部门的服务器。这个中间就需要 Kerberos认证协议来验证网络对象间的权限

网络对象分为:用户、用户组、计算机、域、组织单位以及安全策略等等

<1> Kerberos协议简介

Kerberos 是一种网络身份认证协议，其设计目标是通过密钥系统为客户机 / 服务器应用程序提供强大的认证服务。该认证过程的实现不依赖于主机操作系统的认证，无需基于主机地址的信任，不要求网络上所有主机的物理安全，并假定网络上传送的数据包可以被任意地读取、修改和插入数据。在以上情况下， Kerberos 作为一种可信任的第三方认证服务，是通过传统的密码技术（如：共享密钥）执行认证服务的

Kerberos 主要是用在域环境下的身份认证协议

<2> Kerberos协议角色组成

kerberos是是古希腊神话中具有三个头颅的地狱看门犬，守护在地狱之外，能够识别所有路过的亡灵，防止活着的入侵者闯入地狱

神话里 kerberos 具有三个狗头，在 kerberos 协议里也存在三个角色。分别是 Client、Server、KDC

基本概念：

• Client：客户端

• Server：服务端，可能是某个计算机，也可能是某个服务

• Key Distribution Center (密钥分发中心) ：简称 KDC，默认安装在域控

  一般分为两部分：

  • Authentication Service(身份验证服务)，简称AS，认证服务器，用于 KDC 对 Client 认证 并发放用户用于访问 TGS 的TGT。
  • Ticket Grantng Service (票据授予服务)，简称TGS，用于KDC向Client和Server分发Session Key。

• Session Key：临时秘钥，用来加密网络上传输的数据，只在一段时间内有效

• Ticket Granting Ticket (票据许可)：简称 TGT

• AD（Account Database）: 存储所有client的白名单，只有存在于白名单的client才能顺利申请到ticket

KDC服务框架中包含一个KRBTGT账户，它是在创建域时系统自动创建的一个账号，可以暂时理解为他就是一个无法登陆的账号

<3> Kerberos协议认证流程

(1) 认证流程

我们可以把认证过程分为三部分：

• 1，2部分为Authentication 1，客户端向AS证明自己身份的过程。首先Client向DC请求访问Server，DC会判断Client 是否可信。怎么判断？去AD中存储的黑名单和白名单查找依次区分Client。认证成功AS会返回一个票据许可TGT（Ticket Granting Ticket）
• 3，4部分为Authentication 2，Client继续拿着 TGT 请求DC访问Server，TGS会通过 Client 消息中的TGT，判断Client是否有服务器的访问权限。如果有 TGS 则返回票据ST（Service Ticket）
• 5，6部分为Authentication 3，Client得到票据ST(该 ST 只针对这个Server)，再去访问Server，Server和Client 成功建立通信

举个生活中例子来理解：

比如现在疫情期间去公园玩，需要提前一天预约，你在网上预约后，会给你一个预约信息，第二天拿着预约信息去售票处买票，售票处会给你一张公园门票，你拿着门票去公园入口刷门票才能进入公园。

在去公园玩的流程中

1、网上预约返回给你一个预约信息这个过程就相当于client（你）去访问AS（网上预约中心），AS返回给client一个TGT（预约信息）

2、你拿着预约信息去售票处买票，售票处给你一张票这个过程就相当于client（你）使用TGT（预约信息）去访问TGS（售票处），TGS返回client一个Ticket（公园门票）

3、你拿着门票去刷票入园就相当于client（你）用ticket（公园门票）去server（公园入口），server收到ticket和KDC（检票机）进行验证，通过才能访问

4、门票的时间是一天，相当于Kerberos的允许访问时间，你进公园再出来，当天在进公园就不需要再去预约，买票了，只需要去刷票进去就行

这里再引用《内网渗透体系建设》里的一个例子：

(2) 客户端与AS通信分析(Authentication 1)

Authentication 1 即 客户端向AS证明自己身份的过程。目的是为获取票据许可 TGT(Ticket Granting Ticket)

krbtgt是 KDC的账号 名为密钥分发中心账户

首先Client要发送自己的信息向AS请求TGT票据 。**提供身份信息的数据包是 AS-REQ(AS-requests)**，身份信息包括：用户名/ID、IP、Time

AS收到 Client发送的身份信息数据包后，AS会先向AD请求，询问该Client是否可信，如果在白名单里的话，就会取出它的NTLM hash，然后生成一个随机秘钥称为AS_Session-Key（临时密钥）

AS 会发送TGT给 Client。

TGT包含两部分信息：

• 一部分是 使用Client用户hash进行加密的 Time、TGSname、TGT有效时间和随机密钥AS_Session Key
• 另一部分则是 KDC用户krbtgt 自己hash加密的Time、Client Name、Client IP、TGSname、TGT有效时间、AS_Session Key。发送TGT的数据包是AS-REP(AS-response)

client用户hash client自己知道。因此 Client会获得一个无法解密的TGT和 一个 AS_Session Key。

注：如果设置了PAC，TGT里也会包含 PAC的相关权限信息。PAC(Privilege Attribute Certificate，特权属证书)，PAC包含Client 相关权限信息，如 SID、所属组等等，简单理解的话，PAC就是用于验证用户权限的，只有KDC可以查看和制作PAC

(3) 客户端和TGS通信分析(Authentication 2)

Authentication 2，即 Client 和 TGS的认证

Client收到KRB_AS_REP后，先用自己的Client NTLM-hash 解密TGT得到AS_Session Key，并使用 AS_Session Key 加密数据(Time、Name、IP)作为一部分，与 krbtgt 账户的NTLM hash加密的另一部分，重新封装成TGT 凭借TGT 针对所需要访问的服务像TGS 发送 TGS_REQ请求

TGS收到该请求，用krbtgt NTLM-hash 先解密TGT 得到 AS_Session Key、时间戳、TGT有效周期、Client Name、Client IP等等，然后再用解密得到的 AS_Session Key 解密第一部分内容，得到 Client Name、Client IP和时间戳 。

TGS会将两部分获取到时间戳timestamp进行比较，如果时间戳跟当前时间相差太久，就需要重新认证

TGS还会将这个Client的信息与TGT中的Client信息进行比较，结果没问题的话，TGS会生成一个TGS_Session Key(随机密钥)

然后TGS会返回ST(也叫Ticket)，并带上PAC 。

注：无论用户有没有访问服务的权限，只要TGT正确无误，就会给它返回 ST

返回包包含两部分信息：

• 一部分是 使用 AS_Session Key 进行加密的 时间戳、ST有效时间 和 随机密钥TGS_Session Key
• 另一部分则是 使用Server hash(服务的NTLM hash) 进行加密的 时间戳、Client Name、Client IP、Server IP、ST有效时间、TGS_Session key的ST票据 。发送ST 的数据包是TGS-REP(TGS-response)

至此，Client和KDC的通信就结束了，然后是 Client 和Server进行通信

(4) 客户端和服务端通信分析(Authentication 3)

客户端收到 TGS发送的 ST之后，对其进行解密

Client收到KRB_TGS_REP，先使用 AS_Session Key 解密出了 TGS_Session Key

再使用解出来的 TGS_Session Key 加密 时间戳、ST有效时间、Client Name、Client IP 作为一部分内容，加上ST里Server hash加密的另一部分 重新封装成新的 ST 然后利用ST去向 server 请求服务 ，即发送 KRB_AP_REQ

Server 收到 KRB_AP_REQ ,用自身的Server NTLM hash解密了 ST，得到TGS_Session Key、时间戳等等。再解密另一部分 得到 Client Name、Client-IP、时间戳和 ST有效时间 再与第一部分的 时间戳、Client信息进行对比，timestamp 一般时间为8小时。

验证通过后，会将其中的PAC交给 KDC解密，KDC会由此判断 用户是否有访问该服务的权限。当然如果没有设置的话就不会去KDC求证。 这也是 后面白银票据成功的原因

认证成功后，回复KRB_AP_REP，建立通信

其实整个Kerberos认证的流程就是不断交换密钥，使用对称加密算法，解密验证身份和时间戳，最后达到认证的效果

<4> Kerberos协议认证数据包分析

(1) AS-REQ和AS-REP数据包分析

利用 kekeo 工具申请票据，wireshark抓包分析

tgt::ask /user:1vxyz /domain:hack.com /password:密码

申请一下 1vxyz用户的票据

AS-REQ 包含了用户的一些信息，是客户端发送给AS的数据包，里面有几个重要信息：

1. PA-DATA pA-ENC-TIMESTAMP：使用用户的hash 或者 AESkey 加密时间戳生成的 value

   PA-DATA pA-PAC-REQUEST，是否包含PAC

2. kdc-options

3. cname：请求的用户名

4. realm：域名

5. sname：请求的服务

AS-REP：当KDC收到 AES-REQ 之后解密 PA-DATA pA-ENC-TIMESTAMP 成功 则回发TGT给客户端

TGT 有两部分信息：

1. enc-part：TGT中 用户hash加密的部分
2. enc-part：TGT中 krbtgt hash加密的部分

(2) TGS-REQ和TGS-REP数据包分析

还是利用kekeo工具

以 1vxyz的身份申请一张 访问 DC.hack.com的cifs服务的票

# 首先申请TGT票据
tgt::ask /user:1vxyz /domain:hack.com /password:密码
# 拿着第一步申请到的TGT票据  申请ST
tgs::ask /tgt:TGT_1vxyz@HACK.COM_krbtgt~hack.com@HACK.COM.kirbi /service:cifs/DC.hack.com

TGS-REQ：客户端发送给TGS的 带有用户解密后重新封装的TGT 数据包，其中包含：

1. authenticator：使用 AS_Session Key加密的Client_info、TGS_Name等等
2. ticket：krbtgt用户hash加密的TGT，AS-REP 里原封不动的ticket
3. cname：请求的用户名
4. sname：请求的服务名称

TGS-REP：TGS发送给客户端的 ST 数据包。内容包含：

1. ticket里enc-part：Server hash加密的信息
2. enc-part：AS_Session Key加密的信息

(3) AP-REQ和AP-REP数据包分析

AP-REQ 是 客户端发送 重新封装好的 ST 到服务端的数据包

我们使用kekeo工具申请一张域管的票据 高权限的 然后wireshark抓包分析

# 首先申请TGT票据
tgt::ask /user:administrator /domain:hack.com /password:密码
# 拿着第一步申请到的TGT票据  申请ST并注入内存
tgs::ask /tgt:TGT名称 /service:服务名/域名地址 /ptt 

tgs::ask /tgt:TGT_administrator@HACK.COM_krbtgt~hack.com@HACK.COM.kirbi /service:cifs/DC.hack.com /ptt
klist # 查看内存中的票证

申请到administrator的票据后注入内存中，成功访问 域控的C盘目录

这里就不是 KRB5类型的包了 走的smb

类似于 NTLM认证时协商、质询的数据包。但是这里 Session Setup Request里 放的不是challenge，而是Kerberos的东西。 发送的 ST包含两部分

1. ticket里enc-part：Server hash加密的信息
2. authenticator：TGS_Session Key加密的信息

AP-REP 是 服务端发送到客户端的数据

<5> Kerberos协议认证中存在的安全问题

(1) 一些概念

黄金票据

krbtgt 的NTLM Hash如果泄露了，那么TGT就能被解密甚至伪造。伪造的TGT叫做黄金票据

白银票据

ST(Ticket )是由Server的NTLM Hash进行加密的，如果该Hash泄露，那么就可以解密甚至伪造Ticket。伪造的Ticket 叫做白银票据

哪个更容易伪造一些？ 答案是黄金票据，白银票据需要知道Server hash，访问每个服务都需要一个Server hash去伪造ST。而黄金票据需要知道 krbtgt hash即可

PAC
Privilege Attribute Certificate (特权属性证书)，简称PAC，为了增加了认证过程中的权限认证。PAC会被放在TGT里发送给Client，然后由Client发送给TGS

ms14-068 漏洞，就是基于PAC认证的错误，从而导致域内普通用户可以伪造凭据，提权到管理员权限

(2) Authentication 1-AS_REQ请求阶段

在这一阶段，

可能存在如下漏洞：

• PTH 哈希传递

  当域内client某个用户识图访问域中的某个服务时，该阶段client会用用户的NTLM hash去对 时间戳、client信息 进行加密，也就是数据包里的 authenticator字段，然后发送给AS 所以造成了hash传递

• 域内用户枚举

  此阶段client向AS证明自己的身份的过程，AS检查cname，当用户不存在，返回包提示错误。

  使用kerbrute进行错误枚举的原理就是kerberos有这样四种错误代码：

  • KDC_ERR_PREAUTH_REQUIRED-需要额外的预认证（启用）
  • KDC_ERR_CLIENT_REVOKED-客户端凭证已被吊销（禁用）
  • KDC_ERR_C_PRINCIPAL_UNKNOWN-在Kerberos数据库中找不到客户端（不存在）
  • KDC_ERR_PREAUTH_FAILED (用户存在但密码错误)

  

• 喷洒攻击(密码枚举)

  比如已知域内用户名称，可以使用不同的hash加密这里内容

  

  密码正确和错误返回的包是不相同的。原理同 域内用户枚举

(3) Authentication 1-AS_REP请求阶段

AS_REP数据包中enc-part里面最重要的字段就是AS_session key，作为下阶段的认证密钥

AS-REP中最核心的东西就是AS_session-key 和 krbtgt hash 加密的 ticket。正常我们用工具生成的凭据是.ccache和.kirbi后缀的，用mimikatz，kekeo，rebeus生成的凭据是.kirbi后缀的，impacket生成的凭据是.ccache，两种票据主要包含的都是Login session-key 和加密的 ticket，因此可以相互转换

这一阶段存在黄金票据、Roasting

(4) Authentication 2-TGS_REP请求阶段

TGS-REP中最核心的东西就是TGS_session-key 和 Server hash 加密的 ticket

存在 白银票据、Kerberoasting

Kerberos扩展协议：委派、Kerberos bronze bit

参考：https://www.jianshu.com/p/13758c310242

具体的漏洞攻击方式，请看下文：https://1vxyz.github.io/2023/10/06/Kerberos%E5%8D%8F%E8%AE%AE%E6%BC%8F%E6%B4%9E%E6%94%BB%E5%87%BB/