域认证体系 - Kerberos
Kerberos 是一种网络认证协议，其设计目标是通过密钥系统为客户机 / 服务器应用程序提供强大的认证服务。该认证过程的实现不依赖于主机操作系统的认证，无需基于主机地址的信任，不要求网络上所有主机的物理安全，并假定网络上传送的数据包可以被任意地读取、修改和插入数据。
在以上情况下， Kerberos 作为一 种可信任的第三方认证服务，是通过传统的密码技术(如:共享密钥)执行认证服务的。
Kerberos 主要是用在域环境下的身份认证协议。
域认证所参与的角色 (三只狗头)
Kerberos的标志是三只狗头，狗头分别代表以下角色：
1.Client客户端。
2.Server服务端。
3.KDC(Key Distribution Center) = DC(Domain Controller)，其中包含了AS（Authentication Service）和TGS（Ticket Granting Service）。
其中KDC默认安装在域控上，负责管理票据、认证票据、分发票据。其中AS负责为client生成TGT的服务，TGS负责为client生成某个服务的ticket。
另外还需要介绍一个类似于本机SAM的一个数据库：AD，全称叫account database，存储所有client的白名单，只有存在于白名单的client才能顺利申请到TGT。此AD并非活动目录AD（Active Directory）。
域认证粗略流程
kerberos认证其实就是客户端与服务端无法识别对方身份，而KDC起到了这个中间人的作用，客户端向KDC发起请求，KDC认证通过后，会发给客户端票据，客户端使用票据即可成功访问服务端资源。此过程大致可以分为3个部分。
1.client向kerberos服务请求，希望获取访问server的权限。 kerberos得到了这个消息，首先得判断client是否是可信赖的， 也就是白名单黑名单的说法。这就是AS服务完成的工作，通过 在AD中存储黑名单和白名单来区分client。成功后，返回AS返 回TGT给client。
2. client得到了TGT后，继续向kerberos请求，希望获取访问 server的权限。kerberos又得到了这个消息，这时候通过client 消息中的TGT，判断出了client拥有了这个权限，给了client访 问server的权限ticket。
3. client得到ticket后，终于可以成功访问server。这个ticket只是 针对这个server，其他server需要向TGS申请。
Kerberos认证流程
上面说到了简化版的Kerberos认证流程，基本上分为两步。第一步，客户端向KDC请求获得他想要访问的服务的服务授予票据（可以想象成去动物园，想去买一张能够进入动物园的门票）。第二步，拿着这张服务授予票据（Ticket）去访问服务端的服务。大致的过程确实可以看作这两步，但其中还存在一些问题：问题1. KDC怎么知道你（客户端）就是真正的客户端？凭什么给你发放服务授予票据（Ticket）呢？问题2. 服务端怎么知道你带来的服务授予票据（Ticket）就是一张真正的票据呢？
这就需要开始细节的描述一下整个Kerberos认证的过程了。
第一次通信
由于客户端是第一次访问KDC，此时KDC也不确定该客户端的身份，所以第一次通信的目的为KDC认证客户端身份，确认客户端是一个可靠且拥有访问KDC权限的客户端。
① 客户端用户向KDC以明文的方式发起请求。该次请求中携带了自己的用户名，主机IP，和当前时间戳；
② KDC当中的AS（Authentication Server）接收请求（AS是KDC中专门用来认证客户端身份的认证服务器）后去kerberos认证数据库中根据用户名查找是否存在该用户，此时只会查找是否有相同用户名的用户，并不会判断身份的可靠性；
③ 如果没有该用户名，认证失败，服务结束；如果存在该用户名，则AS认证中心便认为用户存在，此时便会返回响应给客户端，其中包含两部分内容：
1.TGT，使用KDC中的krbtgt用户的NTLM hash加密session key和客户端的信息。KRBTGT 账户，它是在创建域时系统自动创建的一个账号，你可以暂时理解为他就是一个无法登陆的账号，在发放票据时会使用到它的密码 HASH 值，只有DC才能知道该用户的密码hash值。
2.AS（Session_key,客户端即将访问的TGS的Name以及TGT的有效时间（一般为8小时），和一个当前时间戳）。其中Session Key是AS随机生成的秘钥，并且使用client的NTLM hash进行加密。
当client收到AS和TGT之后，因为TGT是使用krbtgt用户的NTML hash进行加密，所以client无法进行解密TGT。client会解密用自己的NTLM hash加密的AS数据，得到Session Key，TGS信息和时间戳。首先他会根据时间戳判断该时间戳与自己发送请求时的时间之间的差值是否大于5分钟，如果大于五分钟则认为该AS是伪造的，认证至此失败。
如果是一个假的客户端，那么他是不会拥有真正客户端的密钥的，也就无法解密AS，认证失败。
第二次通信
client得到Session Key之后，用Session Key加密自己的客户端信息，ip，时间戳发送给TGS，同时也发送了原封不动的TGT和想要访问的server服务。
客户端行为：
① 客户端使用Session Key加密将自己的客户端信息发送给KDC，其中包括客户端名，IP，时间戳；
② 客户端将自己想要访问的Server服务以明文的方式发送给KDC；
③ 客户端将使用TGS密钥加密的TGT也原封不动的也携带给KDC；
TGS行为：
① 此时KDC中的TGS（票据授予服务器）收到了来自客户端的请求。他首先根据客户端明文传输过来的Server服务IP查看当前kerberos系统中是否存在可以被用户访问的该服务。如果不存在，认证失败结束。如果存在，继续接下来的认证。
② TGS使用krbtgt用户的的密钥将TGT中的内容进行解密，此时他看到了经过AS认证过后并记录的用户信息，一把Session_KEY即CT_SK，还有时间戳信息，他会现根据时间戳判断此次通信是否真是可靠有无超出时延。
③ 如果时延正常，则TGS会使用Session_KEY对客户端的第一部分内容进行解密（使用Session_KEY加密的客户端信息），取出其中的用户信息和TGT中的用户信息进行比对，如果全部相同则认为客户端身份正确，方可继续进行下一步。
④ 此时KDC将返回响应给客户端，包括用server NTML hash加密的Server Ticket，其中包括客户端的Name，IP，需要访问的网络服务的地址Server IP，Server Ticket的有效时间，时间戳以及用于客户端和服务端之间通信的 Server Session Key。
第三次通信
Server Ticket客户端无法解密，因为使用server服务端的NTLM hash进行加密的，客户端通过将server ticket发送给服务端，服务端用自己的hash解密Server Ticke和Server Session Key去对比信息和时间长度。
最终确认该客户端就是经过了KDC认证的具有真实身份的客户端，是他可以提供服务的客户端。此时服务端返回一段使用CT_SK加密的表示接收请求的响应给客户端，在客户端收到请求之后，使用缓存在本地的CS_ST解密之后也确定了服务端的身份。
至此，第三次通信完成。此时也代表着整个kerberos认证的完成，通信的双方都确认了对方的身份，此时便可以放心的进行整个网络通信了。
白银票据(Silver Tickets)
白银票据特点:
1.不需要与KDC进行交互
2.需要目标服务的NTLM Hash
在第三步认证中的Ticket的组成:
Ticket=Server Hash(Server Session Key+Client info+End Time)
当拥有Server Hash时，我们就可以伪造一个不经过KDC认证的一个Ticket。
PS:Server Session Key在未发送Ticket之前，服务器是不知道Server Session Key是什么的。所以，一切凭据都来源于Server Hash。
伪造白银票据(Silver Tickets)
首先需要导出Server Hash：
1 C:\files>mimikatz.exe "privilege::debug” "sekurlsa::logonpasswords" "exit" > log.txt伪造票据:
1 mimikatz “kerberos::golden /domain:<域名> /sid:<域 SID> /target:<目标服务器主机名> /service:<服务类型> /rc4:<NTLM Hash> /user:<用户名> /ptt" exitOther：
由于白银票据需要目标服务器的Hash，所以没办法生成对应域内 所有服务器的票据，也不能通过TGT申请。因此只能针对服务器 上的某些服务去伪造。
白银票据(Silver Tickets)防御
1.尽量保证服务器凭证不被窃取
2.开启PAC (Privileged Attribute Certifificate) 特权属性证书保护 功能，PAC主要是规定服务器将票据发送给kerberos服务，由 kerberos服务验证票据是否有效。
开启方式：将注册表中 HKEY_LOCAL_MACHINE\SYSTEM \ CurrentControlSet\Control\Lsa\Kerberos\Parameters 中的 ValidateKdcPacSignature 设置为1。
黄金票据(Golden Tickets)
黄金票据特点:
1.需要与DC通信
2.需要krbtgt用户的hash
PS:这里的krbtgt hash就是之前讲的KDC Hash
黄金票据(Golden Tickets) - 伪造
伪造票据：
1 mimikatz “kerberos::golden /domain:<域名> /sid:<域SID> /rc4:<KRBTGT NTLM Hash> /user:<任意用户名> /ptt" exitTickets 总结
黄金票据：从攻击面来看，获取krbtgt用户的hash后，可以在域中进行持久性的隐藏，并且日志无法溯源，但是需要拿到DC权限， 使用黄金票据能够在一个域环境中长时间控制整个域。从防御角度来看，需要经常更新krbtgt的密码，才能够使得原有的票据失效。最根本的办法是不允许域管账户登录其他服务器。
白银票据:从攻击面来看，伪造白银票据的难度比伪造黄金票据的难度较小，因为一个域中的服务器如果对外的话，非常容易被入侵， 并且容易被转储Server。从防御角度来看，需要开启PAC认证，但这会降低认证效率，增加 DC的负担，最根本的还是要加固服务器本身对外的服务。
