欢迎关注我的微信公众号《壳中之魂》
Kerberos 是一种由 MIT（麻省理工大学）提出的一种网络身份验证协议。它旨在通过使用密钥加密技术为客户端/服务器应用程序提供强身份验证。
Kerberos 主要是用在域环境下的身份认证协议。
名词解释
DC(Domain Controller)：域控制器，简称DC，一台计算机，实现用户、计算机的统一管理。
KDC(Key Distribution Center)：秘钥分发中心，简称KDC，默认安装在域控里，包括AS和TGS。
AS(Authentication Service)：身份验证服务，简称AS，用于KDC对Client认证。
TGS(Ticket Grantng Service)：票据授予服务，简称TGS，用于KDC向Client和Server分发Session Key（临时秘钥）。
TGT(Ticket Granting Ticket)：认证票据，用于验证Client的身份
ST(Server Ticket)：服务票据
AD(Active Directory)：活动目录，简称AD，用于存储用户、用户组、域相关的信息。
Client：用户
Server：可以是某台计算机，也可以是某个域内服务
krbtgt用户：创建域控时自动生成的用户
认证过程
1、首先Client要通过AS验证，获得TGT
当某个Client要访问某个Server时，需要AS来进行认证，Client输入用户和密码，并且向KDC发送一个AS_REQ，这个AS_REQ里包含了使用Client的NTLM-Hash加密的时间戳以及Client-info、Server-info等数据，以及一些其他信息。
AS接收到Client发送的AS_REQ，首先向AD询问是否有此用户，有的话则用此用户的NTLM-Hash来对AS_REQ进行解密，如果可以成功解密，且解密后得到的时间戳和和当时时间在5分钟内则为认证成功。需要认证时间的原因是为了保障此AS_REQ的安全，在传输AS_REQ的过程中，AS_REQ有被黑客截获的风险，黑客截获后如果想要骗取身份则需要重放攻击，这个过程中会花费一定的时间，所以要是时间戳和解密的时间偏差较大则可能遭遇攻击所以不会继续认证。
在这一个过程经历了两个验证，一是Client对AS的验证：如何AS是否为真，所以使用Client的NTLM-Hash进行加密，如果AS为真则可以正常解密AS_REQ；
二是AS如何判断此Client为真，问题仍然在AS_REQ这里，如果Client为真，则AS那Client的NTLM-Hash解密时是可以正确解密出来的。
然后AS会生成一个AS_REP，AS_REP包含两个部分
第一部分AS生成的临时密钥Session-key，然后使用Client的NTLM-Hash加密，用于Client和KDC进行安全通信。
另一部分就是TGT，内容是使用特定用户Krbtgt的NTLM-Hash加密的Session-key(AS生成的)、时间戳以及一些用户信息
2、然后Client要和TGS认证，获得ST服务票据
当Client收到了AS发回来的AS_REQ时，会使用自己的NTLM-Hash，将被加密过的临时秘钥Session-Key进行解密，得到没有被加密的Session-Key，然后将其保存在本地，如果有需要访问某个服务时就可以构成TGS_REQ提交给TGS，来得到对应的ST。
在这个过程中发送的TGS_REQ中包含了使用Session-Key(AS生成的)加密的时间戳以及Client-info、Server-info 等数据，以及一些其他信息，以及使用krbtgt用户NTLM-Hash加密的TGT
当TGS收到TGS_REQ后会首先对使用krbtgt用户NTLM-Hash加密的TGT进行解密，目的是得到Session-Key(AS生成的)、时间戳以及Client-info、Server-info等数据，同理，如果时间戳和解密时间相差太久则终止验证，同时TGS会使用TGT里的Client信息和当前Client的信息进行比较来判断是否为同一人，判断无误后则会判断此Client是否有访问此Server的权限，如果有，则返回一个TGS_REP，由两部分组成。
在这一个过程经历了一个验证：一是TGS如何判断Client为真，所以使用了Session-Key(AS生成的)，这个Session-Key除了DC就只有Client知道。
第一部分为TGS生成的新的Session-key，然后再使用第一个过程AS生成的Session-key进行加密。
第二部分为使用Server的NTLM-Hash加密的Session-key(TGS生成的)、时间戳以及一些用户信息，这个部分就是ST
3、Client和Server通信
Client收到了TGS_REP，获得了加密的Session-key以及ST，和上面的操作一样，先使用刚才储存在本地的Session-key(AS生成的)对Session-key(TGS生成的)进行解密，得到未加密的Session-key(TGS生成的)，然后继续将其和ST一起储存在本地。
在这一个过程经历了一个验证：一是Client如何判断TGS为真，所以使用了Session-Key(AS生成的)，这个Session-Key除了DC就只有Client知道。
当Client需要访问Server时，Client则会发送AP_REQ
AP_REQ包含了使用Session-key(TGS生成的)加密时间戳、Client-info、Server-info等数据，以及一些其他信息，然后再把ST一同发送给Server。
Server收到AP_REQ后会使用自己的NTLM-Hash对ST进行解密，拿到到Session-Key(TGS生成的)，时间戳、Client-info等数据，根据ST内的时间戳和解密时的时间戳进行对比，如果时间超过8小时则为验证失败，然后Server询问DC该用户是否有访问权限，来决定Client是否有权限访问Server。
总结
从这个过程中可以看出，整个认证过程其实最主要就是两部分
一是DC需要知道提交内容的人是否是Cilent；二是Client需要知道发放内容的人是否是DC，这个过程有点像CSRF的防御，都需要一个黑客无法伪造的内容，然而，这个内容并非完全安全，所以Kerberos协议才会有利用的点
比如黄金票据（Golden ticket）
当黑客可以获得Krbtgt用户的NTLM-Hash就代表着黑客黑客就可以伪造TGT
又或者是白银票据（Silver ticket）
白银票据不同于黄金票据，白银票据的利用过程是伪造TGS，通过已知的授权服务密码生成一张可以访问该服务的 TGT。因为在票据生成过程中不需要使用 KDC，所以可以绕过域控制器，很少留下日志。而黄金票据在利用过程中由 KDC 颁发 TGT，并且在生成伪造的 TGT 得 20 分钟内，TGS不会对该 TGT 的真伪进行效验。
白银票据依赖于服务账号的密码散列值，这不同于黄金票据利用需要使用 Krbtgt 账号的密码哈希值，因此更加隐蔽。
