Chen's Blog HomeArchivesTagsCategories
内网渗透之kerberos协议分析

前言

Kerberos协议是一种网络认证协议，其设计目标是通过密钥系统为客户/服务器应用程序提供强大的认证服务。在令牌窃取攻击中，该攻击的核心就是Kerberos协议。Kerberos协议要解决的实际上就是一个身份认证的问题，顾名思义，当一个客户机去访问一个服务器的某服务时，服务器如何判断该客户机是否有权限来访问本服务器上的服务，同时保证在该过程中的通讯内容即便被拦截或者被篡改也不影响整个通讯的安全性。

概念说明

先来简要说明几个主要的名词

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
(1)Client:访问服务的客户机
    
(2)Server:提供服务的服务器
    
(3)KDC(Key Distribution Center):密钥分发中心 
    
(4)KDC中分成两个部分:Authentication Service和Ticket Granting Service
    Authentication Service(AS):身份验证服务
    Ticket Granting Service(TGS):票据授予服务
    
	AS和TGS如下：
    
	Authentication Service：AS的作用就是验证Client端的身份，验证通过之后，AS就会给TGT票据(Ticket Granting Ticket)给Client.
	Ticket-granting cookie(TGC):存放用户身份认证凭证的cookie，在浏览器和CAS Server间通讯时使用，是CAS Server用来明确用户身份的凭证。TGT封装了TGC值以及此Cookie值对应的用户信息.
    Ticket-granting ticket(TGT):TGT对象的ID就是TGC的值，在服务器端，通过TGC查询TGT.


	Ticket Granting Service(TGS)：TGS的作用是通过AS发送给Client的TGT换取访问Server端的ST(Server Ticket)给Client.
	SEerver Ticket(ST):ST服务票据，由TGS服务发布.

    
(5)Active Directory(AD):活动目录
    
(6)Domain Controller(DC):域控制器
    
(7)Ticket-granting cookie(TGC):存放用户身份认证凭证的cookie，在浏览器和CAS Server间通讯时使用，是CAS Server用来明确用户身份的凭证。TGT封装了TGC值以及此Cookie值对应的用户信息.
    
(8)Ticket-granting ticket(TGT):TGT对象的ID就是TGC的值，在服务器端，通过TGC查询TGT.

认证过程

Kerberos认证的过程形象地比喻如下：

1
2
3
4
5
6
7
8
9
疫情期间，小明去拿一个重要包裹，由于包裹是来自海外的，所以需要严格登记：
（1）拿包裹的时候，为了证明自己是合法公民，小明先把身份证给工作人员
（2）快递点的身份认证系统通过身份认证后，给小明一张身份认证通过证明
（3）小明拿着身份认证通过证明，来到快递收发处等一张拿快递的号码牌
（4）售票处给了张号码牌
（5）小明拿着号码牌拿快递去了
（6）在拿快递时，小明拿出自己的身份认证材料给快递点的工作人员，工作人员向快递公司的数据管理中心发了消息，问问小明是不是有包裹要拿
（7）数据管理中心将小明的快递单号，身份信息等发了过来
（8）工作人员将数据管理中心发来的信息与小明给的材料对比，得出小明是好公民，有一个重要包裹，于是带着小明来到仓库的金库，把装有老魔杖的包裹给了小明

在Kerboeros协议认证过程中，会用到两个基础认证模块，分别是AS_REQ&AS_REP和TGS_REQ&TGS_REP，以及在认证过程中可能会使用到的S4U和PAC这两个认证模块。

使用wireshark抓包得到数据包，PS:在抓包的时候，先用mimikatz将机器中的票据清除

域控：10.10.10.10（windows server 2008 R2）

域成员：10.10.10.80（windows 7）

域用户账号密码：hunter1/1qaz@WSX

image-20200818153536014

Kerberos认证中有两个问题

1
2
3
4
（1）AS如何验证Client的身份？
	AS与Client之间的认证使用AS_REQ&AS_REP模块	
（2）Client如何获取ST？
	Client与TGS之间认证使用TGS_REQ&TGS_REP模块

因为kerberos协议的实现，需要三方的参与，分别如下：

1
2
3
4
1.client 访问服务的客户机
2.Server 提供服务的服务器
3.KDC(Key Distribution Center) 密钥分发中心 
    KDC服务会默认安装在一个域的域控中，所以可以直接理解为，AD与KDC均为域控制器,KDC服务框架中包含一个KRBTGT账户，它是在创建域时系统自动创建的一个账号。

Kerberos认证过程如下图所示

image-20200818172316365

其中：KDC中有AS认证服务与TGS认证服务

1
2
3
4
5
6
7
8
(1)Client向KDC的AS认证服务请求TGT票据=>AS_REQ
(2)Client通过认证后，KDC将会发放TGT票据=>AS_REP
(3)Client带上TGT票据，向TGS认证服务请求ST服务票据=>TGS_REQ
(4)Client通过了TGS认证服务后，TGS将会发放ST服务票据=>TGS_REP
(5)Client使用ST服务票据向服务端请求服务=>AP_REQ
(6)Server拿到PAC询问KDC，Client是否有权限
(7)KDC将Client的权限信息发给Server
(8)Server根据KDC返回的权限信息对比，判断Client是否有权限访问该服务，并把结果返回给Client=>AP_REP

注：（6）（7）两步不一定发生，需要将目标主机配置为验证KDC PAC验证。

image-20200816175638053

1
域中每个用户的Ticket都是由krbtgt的密码Hash来计算生成的,因此只要我们拿到了krbtgt的密码Hash,就可以随意伪造Ticket,进而使用Ticket登陆域控制器,使用krbtgt用户hash生成的票据被称为Golden Ticket,此类攻击方法被称为票据传递攻击。

先前提到两个问题，第一个问题

1
2
（1）AS如何验证Client的身份？
	AS与Client之间的认证使用AS_REQ&AS_REP模块

AS_REQ&AS_REP

分析AS-REQ的数据包

AS-REQ：当某个域用户试图访问域中的某个服务，于是输入用户名和密码，本机Kerberos服务会向KDC的AS认证服务发送一个AS-REQ认证请求。该请求包中包含：请求用户名，客户端主机名，加密类型和Autherticator(用户NTLM Hash加密的时间戳)以及一些信息。

Client向KDC发起AS_REQ请求凭据是用户hash加密的时间戳。请求凭据放在PA_DATA里面。

image-20200818205358668

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
Pvno  kerberos协议版本号：05（Hex）
5MSG-TYPE 类型 AS_REQ对应（krb-as-req）0a（Hex）
PA-DATA  预认证信息数据 一个列表，包含若干个认证消息用于认证，每个认证消息有type和value。
AS_REQ 阶段主要用到的有两个
　　1.ENC_TIMESTAMP
　　这个是预认证，就是用用户hash加密时间戳，作为value 发送给AS服务器。然后AS服务器那边有用户hash，使用用户hash进行解密，获得时间戳，如果能解密，且时间戳在一定的范围内，则证明认证通过。
　　2.PA_PAC_REQUEST
　　这个是启用PAC支持的扩展。PAC(Privilege Attribute Certificate)并不在原生的kerberos里面，是微软引进的扩展。PAC包含在AS_REQ的响应body(AS_REP)。这里的value对应的是include=true或者include=false(KDC根据include的值来判断返回的票据中是否携带PAC)。
REQ_BODY 
　　1.cname
　　PrincipalName 类型。PrincipalName包含type和value。
　　KRB_NT_PRINCIPAL = 1 means just the name of the principal 如daizhibin
　　KRB_NT_SRV_INST = 2 service and other unique instance (krbtgt) 如krbtgt，cifs
　　KRB_NT_ENTERPRISE_PRINCIPAL = 10 如 user@domain.com
　　在AS_REQ里面cname 是请求的用户,这个用户名存在和不存在，返回的包有差异，可以用于枚举域内用户名。
　　2.sname
　　PrincipalName 类型，在AS_REQ里面sname是krbtgt，类型是KRB_NT_SRV_INST
　　3.realm 域名
　　4.from 发送时间
　　5.till 到期时间，rubeus和kekeo都是20370913024805Z，这个可以作为特征来检测工具。
　　6.nonce
　　随机生成的一个数kekeo/mimikatz nonce是12381973，rubeus nonce是1818848256，这个也可以用来作为特征检测工具。
　　7.etype
　　加密类型
这个地方要注意的是如果在配置里面选择用hash(不是plaintext)的话，hash的加密类型，要跟etype一样。因为KDC是按照etype类型选择用户对应加密方式的hash，如果是选择明文(plaintext)，那么client 会按照etype里面的加密方式将明文加密成hash

image-20200818215055130

image-20200818215301634

image-20200818220025595

分析AS-REP的数据包

image-20200818222119974

AS-REP：Client发送AS_REQ，请求凭据是用户 hash加密的时间戳。请求凭据放在PA_DATA里面。当KDC中的AS认证服务收到后，在AS服务器中有用户hash，使用用户hash进行解密，获得时间戳，如果解密成功，并且时间戳在五分钟之内，那么预认证通过。接着AS认证服务将会向Client发送响应包，响应包中包括krbtgt用户的NTML hash加密后的TGT票据以及用户NTML Hash加密的Login Session key和其他信息。

image-20200819074207581

ticket中的enc-part是由krbtgt的密码hash加密生成的。如果我们拥有krbtgt的hash，便可以自制ticket，发起黄金票据攻击

Login Session Key使用用户NTML Hash加密，作用是用于是用于确保客户端和KDC下一阶段之间通信安全，作为下一阶段的认证密钥

1
在这一阶段，Client与KDC之间的交互在于AS认证服务，主要是为了获得TGT认证票据，以及Login Session Key，经过该阶段后，Client将会使用自身密码的NTML hash解密Login Session Key得到原始的Login Session Key。然后它会在本地缓存TGT票据和原始Login Session Key

TGS_REQ&TGS_REP

先前提到两个问题，第二个问题

1
2
（2）Client如何获取ST？
	Client与TGS之间认证使用TGS_REQ&TGS_REP模块

Client在拿到TGT和Login Session Key之后，下一步的认证交互在于KDC中的TGS认证服务，主要目的是为了获取ST服务票据，因为当Client需要访问某服务器中的某服务时，需要“门票”–ST服务票据

这一阶段，微软引进了两个扩展S4U2SELF和S4U2PROXY。

TGS-REQ数据包分析

该数据包中的主要内容为：客户端信息，Authenticator(Login Session Key加密的时间戳)、TGT认证权证(padata下ap-req下的ticket)以及访问的服务名等。

image-20200819084032928

padata部分：

image-20200819083939532

在padata中有很重要的一部分叫做AP-REQ，这是TGS-REQ中必须有的数据，这部分会携带AS-REP里面获取到的TGT票据，KDC检验TGT票据，如果票据正确，返回ST票据。

image-20200819090538928

TGS-REQ请求包中的authenticator就是AS-REP响应包返回的Login Session key加密的时间戳

req-body部分：

image-20200819084011212

在req-body中

1
2
3
4
5
6
7
8
9
padding:0
kdc-options:用于与KDC约定一些选项设置
realm:域名
sname:这里是要请求的服务
till:到期时间
	rebeus和kekeo都是20370913024805Z，可用于作为特征值检验用
nonce:随机生成数 
	kekeo/mimikatz的nonce为12381973，rubeus的nonce为1818848256,可用于作为特征值检验	用
etype:加密类型

分析TGS-REP数据包

TGS-REP：当TGS收到请求后，将会检查自身是否存在客户端所请求的服务，如果服务存在，通过krbtgt用户的NTML hash解密TGT并且得到Login Session Key，通过Login Session Key解密Authenticator。

image-20200819094302206

这一系列解密成功的话，将会验证对方的身份，验证时间戳是否在范围内，并且检查TGT中的时间戳是否过期，且原始地址是否和TGT中保存的地址相同

完成认证后，TGS生成ST票据（包括客户端信息和原始Server Session key，整个ST服务票据使用该服务的NTML hash加密以及一个AS-REP返回的Login-Session-Key加密的Server Session Key。这两个将在响应包中发送给Client

image-20200819115006724

PS:在这一步中，不论用户是否有权限访问服务，只要TGT解密无误，都将返回ST服务票据。任何一个用户，只要hash正确，就可以请求域内任何一个服务的票据

ST票据通过认证访问服务

使用ST票据通过认证访问服务

image-20200819103656434

需要强调的是，这里需要使用双向验证，因为实际情况中，需要客户端和服务器互相验证

（1）服务端验证客户端：防止非法用户操作

image-20200819105333583

（2）客户端验证服务端：防止误入恶意服务

image-20200819110334182

PS:PAC并不是所有服务都开启的，这需要配置验证KDC PAC 签名。没有验证PAC，可能会导致白银票据攻击。因为开启PAC后，就算攻击者拥有用户hash，能制作ST票据后，无法通过PAC验证，还是无法访问服务。

后话

Kerberos的攻击有如下：

image-20200819111552341

参考文章：

https://www.zhihu.com/question/22177404

https://blog.csdn.net/matthewei6/article/details/50769670

http://www.secwk.com/2019/11/05/13711/

https://www.cnblogs.com/zlg666/p/12048853.html

https://mp.weixin.qq.com/s/QCyadi2Alb4CMfegxXgs1A

Author: 我是小吴啦
Link: http://yoursite.com/2020/08/16/%E5%86%85%E7%BD%91%E6%B8%97%E9%80%8F%E4%B9%8Bkerberos%E5%8D%8F%E8%AE%AE%E5%88%86%E6%9E%90/
Copyright Notice: All articles in this blog are licensed under CC BY-NC-SA 4.0 unless stating additionally.
内网渗透