域渗透基础 – Kerberos协议

0.前置知识

简写 全拼
DC Domain Controller 域控
KDC Key Distribution Center 密钥分发中心
AD Account Database 账户数据库
AS Authentication Service 身份验证服务
TGS Ticket Granting Service 票据授与服务
TGT Ticket Granting Ticket 票据中心授予的票据

1.什么是Kerberos

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

2.Kerberos会使用的端口

TCP和UDP的88端口:身份验证和票证授予

TCP和UDP的464端口:经典Kerberos Kpaswd(密码重设)协议

3.krbtgt账户

每个域控制器DC都有一个kebtgt的用户账户,此账户是KDC的服务账户用来创建票据授予服务(TGS)加密的密钥

4.这东西咋认证?

1 – >

Client (客户端) 会向 Kerberos 服务发起请求 与 Kerberos 服务进行对接 告知 Client 需要获取访问 server 的权限

2 – >

kerberos 收到了 client 的请求之后,会对 client 进行校验,判断 client 是否是可信任的,如果是可信任的 client ,则 kerberos (由AS—Authentication Service 身份验证服务)来完成 返回一张 TGTclient 。其中对 client 的校验使用的是白名单的方式

3 – >

client 带着获得的 TGT ,再次向 kerberos 发起请求,告诉 kerberos 想要哪个 server 的访问权限。

4 – >

kerberos 接收到 client的请求之后,client 请求中带有 TGT 且校验无误,kerberos 会授予 client 访问 server 的权限,返回 ticket (票据)

5 – >

client 带着 ticketserver 发起请求,server 接收到 client 的请求之后,验证成功后即可

注:

ticket 对应的是 client 请求的 server ,使用这张 ticket 无法登陆其他的 server

5.详细过程

1.Client – > KDC – AS

· KRB_AS_REQ (Kerberos Authentication Service Request) – 客户端执行散列运算加密一个时间戳,然后发送给身份验证服务(KDC-AS)
· client先向KDCAS发送Authenticator1,内容为通过Client密码Hash加密的时间戳、Client ID、网络地址、加密类型等内容。
· a. 客户端Client对用户口令执行散列运算转换为NTLM散列。此散列值(即用户密钥)成为客户端和KDC共享的长期密钥(long term key)。
· b. KRB_AS_REQ (Kerberos Authentication Service Request) – 客户端执行散列运算加密一个时间戳,然后发送给身份验证服务(KDC-AS)。

啥意思呢?

在第一步clientKDC的请求中包含了username等身份信息,KDC确认username均存在域中则校验成功,KDC使用client请求的username在域控中查找对应用户的NTLM,然后使用NTLM哈希加密一串KDC随机生成的字符。如果client身份伪造,那么client在得到Session Key之后用自己的NTLM无法解密出正确的随机字符,这一步也就确保了身份的真实性。

*NTLM 即加密过的windows用户密码

2.KDC – AS — > Client

KRB_AS_REP (Kerberos Authentication Service Response) –
身份验证服务(KDC-AS)会解密时间戳,若解密成功(KDC-AS检查用户的信息(登录限制.组成员身份等)并创建票据授予票据(Ticket-Granting Ticket,TGT),
并向本地LSA (Local Security Authority)请求生成一个特殊的数据PAC,表明了客户端获得某个特定用户的口令(即验证了用户的身份)。
身份验证服务(KDC-AS)向客户端回复两条信息:
a. 短期会话密钥SessionKeya-kdc,用于客户端向KDC发起后续的请求 ,该消息经客户端的长期密钥(long term key)加密。(此短期会话密钥仅适用于该客户端和KDC之间)
b. 票据授予票据(Ticket Granting Ticket,简称TGT),包含有关用户名.域名.时间和组成员资格等信息。
TGT票据使用KDC的krbtgt密钥进行加密,PAC使用krbtgt密钥进行进行签名,并且系统很少会验证PAC数据(在Windows环境中为krbtgt账户的NT-Hash)。

3.Client->KDC-TGS

KRB_TGS_REQ (Kerberos Ticket Granting Service Request) –
Client使用AS返回的”短期会话密钥”构建访问特定服务的请求,再把AS返回的”票据授予票据(TGT)”连同请求一起发送到票据授予服务TGS) 此过程叫KRB_TGS_REQ
Client-A使用AS返回的会话密钥SessionKeya-kdc构建访问特定服务的请求。客户端Client再把请求连同TGT一起发送到票据授予服务TGS。
(TGT是被KDC的krbtgt密钥加密的,所以Client无法解密)
黄金票据 – 此过程3可以伪造TGT(前提是获取krbtgt账号的口令散列值),宣称自己是域内任何账号,包括域管或者不存在的用户,这是黄金票据的原理。

4.KDC-TGS—>Client

KRB_TGS_REP (Kerberos Ticket Granting Service Response) –
票据授予服务TGS解密TGT和服务请求,然后如果请求被允许(KDC会打开票据,进行校验和检查。如果DC能够打开票据,并能通过校验和检查,那么会认为TGT为有效票据。此时TGT中的数据会被复制,以创建TGS票据ST),Server密码HASH加密sessionkey-tgs
票据授予服务TGS向客户端Client发送一个服务票据(Service Ticket,简称ST),包括两个部分:
a. 远程服务器的部分 – 包含请求用户的组成员资格、时间戳、用于客户端和远程服务器之间通信的会话密钥。使用远程服务器Server-B和KDC共享的长期密钥(long term key)加密这部分消息。
b. 客户端的部分 – 包含用于客户端和远程服务器之间通信的会话密钥SessionKeya-b。(使用步骤2中AS回复的短期会话密钥(SessionKeya-kdc)加密这部分消息生成的会话密钥SessionKeya-b。)

5.Client—>Server

RB_AP_REQ (Kerberos Application Request) –
Client把服务票据(Service Ticket)中的服务器部分和请求一起发送到Server-B(用户要访问活动目录中的主机)。
远程服务器将直接接受该服务器票据,并不需要和KDC直接通信,因为该票据是用远程服务器和KDC共享的长期密钥加密过的。
解密成功(目标服务会使用自己的NTLM密码散列打开TGS票据,并提取用户的授权数据和会话密钥SessionKeya-b。)即表明KDC已经允许了此次通信。
白银票据 – 此过程5可以伪造TGS(前提是获取服务账号的口令散列值),宣称自己是域内任何账号,例如域管,这是白银票据的原理。

6.参考

https://blog.csdn.net/weixin_40803858/article/details/91982172

https://blog.csdn.net/wy_97/article/details/87649262

https://www.jianshu.com/p/17ad0aa73755

发表评论

您的电子邮箱地址不会被公开。 必填项已用*标注

Protected with IP Blacklist CloudIP Blacklist Cloud