kerberos身份验证原理Windows密码存储格式NTLM(NTLANmanager ) hash本地身份验证进程挑战(Challenge ) /响应) NTLM挑战/响应身份验证机制NTLM协议巴
Windows密码存储格式
在理解kerberos协议之前，必须了解Windows系统的密码存储在名为% systemroot %system32configSam的路径中。 登录系统后，系统会自动将Sam文件中的NTLMdzdbd值与输入密码的dzdbd值进行匹配，并成功进行相同的认证
NTLMwindowsntLANmanager是一种挑战-响应验证协议，用于验证活动目录域中资源的客户端。 当客户端请求访问与域相关联的服务时，服务器向客户端发送质询，请求客户端使用验证令牌执行数学运算，并将操作结果返回给服务器。 服务可以验证结果，并将其发送到域控制器(DC )进行验证。 如果服务器或DC确认客户端响应正确，则服务器将授予对客户端的访问权限。
NTLM(NTLANmanager ) hash NTLM Hash是支持Net NTLM身份验证协议和本地身份验证过程的重要参与者，长度为32位，由数字和字符组成。 当前的Windows基本上使用的是名为NTLMv2的协议版本。
本地认证过程Windows Logon Process是Windows NT用户登录程序，用于管理用户的登录和注销。 LSASS用于微软Windows系统的安全机制。 用于本地安全和登录策略。 以下是本地认证的流程图
挑战(challenge response )的第一步是在两台操作系统之间首先进行协商。 旧版本的系统(如Windows Server2003和xp )只支持LM协议，不支持NTLM协议，因此，首先要验证服务器的协议版本是v1还是v2。
第二步是提问。 客户端向服务器发送用户信息请求，服务器收到请求后，生成一个称为Challenge的16位随机字符，使用与登录用户名对应的NTLM Hash对Challenge进行加密，将Challenge1 还生成了Challenge1后，将Challenge发送到客户端。 总的来说netNTLMhash=NTLMhash(challenge )。
然后，当客户端接收到Challenge时，它使用登录到帐户的NTLM Hash加密Challenge生成的响应，并将该响应发送到服务器端。 当服务器接收到来自客户端的Response时，它会核对Challenge1和Response是否相等，如果相等，则通过认证。
NTLM挑战/响应验证机制根据下图说明了NTLM的身份验证进程
Server在收到从Client发送的用户名时，会确定本地帐户列表中是否存在用户名share_user，如果没有，则会返回认证失败。 在某些情况下，生成Challenge，从本地查找与share_user对应的NTLM Hash，使用NTLM Hash对Challenge进行加密，生成Net-NTLM Hash存在于内存中。 客户端收到Challenge后，将自己提供的share_user密码转换为NTLM Hash，并使用NTLM Hash对Challenge进行加密。 结果称为响应，表示形式为Net-NTLM Hash，最后将响应发送到servense，服务器接收客户端发送的响应，并将响应与以前的Net-NTLM Hash进行比较注意： Challenge是Server生成的16字节随机数，每个认证都不一样。 Response表示为Net-NTLM Hash，是客户端提供的密码Hash加密服务器返回的Challenge的结果。 NTLM协议版本的差异NTLM v1和NTLM v2最明显的区别在于Challenge与加密算法不同，共同点是加密的原料都是NTLM Hash。
Challenge：NTLM v1的Challenge为8比特，NTLM v2的Challenge为16比特。
Net-NTLM Hash：NTLM v1的主要加密算法是DES，NTLM v2的主要加密算法是HMAC-MD5
Pass The Hash和必要条件Pass The Hash
内部网渗透经常需要获得管理员密码，NTLM Hash。 通过收集这些信息，将有助于扩大战果，特别是在域环境中。
dzdbd分发是不需要账户的明文密码就能够完成认证的技术。
dzdbd分发解决了我们在渗透中无法获得明文密码，无法解密NTLM Hash，扩大战果的问题。
ong>必要条件 dzdbd传递需要被认证的主机能够访问到服务器dzdbd传递需要被传递认证的用户名dzdbd传递需要被传递认证用户的NTLM Hash Kerberos所参与的角色 ClientServerKDC(Key Distribution Center) = DC 什么是KDC DC(account database)：存储所有client的白名单，只有存在于白名单的client才能顺利申请到TGT票据。Authentication Service：为client生成TGT的服务。Ticket Granting Service：为client生成某个服务的ticket。KDC：KDC其实是一种服务框架，框架中包含一个 KRBTGT 账户，它是在创建域时系统自动创建的一个账号，你可以暂时理解为他就是一个无法登陆的账号，在发放票据时会使用到它的密码 HASH 值。AD：AD其实是一个类似于本机SAM的一个数据库，全称叫account database。 域认证粗略流程 client向kerberos服务请求，希望获取访问server的权限。kerberos得到这个消息，首先判断client是否是可信赖的，也就是白名单黑名单的说法。这就是AS服务器完成的工作，通过在AD中存储黑名单和白名单来区分client。成功后，返回AS，返回TGT给client。client得到了TGT后，继续向kerberos请求，希望获取访问server的权限。kerberos又得到这个消息，这时候通过client消息中的TGT，判断出了client拥有了这个权限，给了client访问server的权限，也就是ticket票据。client得到ticket后，终于可以成功访问server。这个ticket只是针对这个server，其它server需要向TGS申请。 Kerberos域认证体系kerberos是一种网络认证协议，其设计目标是通过密钥系统为客户机 / 服务器应用程序提供强大的认证服务。该认证过程的实现不依赖于主机操作系统的认证，无需基于主机地址的信任，不要求网络上所有主机的物理安全，并假定网络上传送的数据包可以被任意地读取、修改和插入数据。在以上情况下，kerberos作为一种可信任的第三方认证服务，是通过传统的密码技术(共享密钥)执行认证服务的。
域认证详细流程第一步：Session Key与Ticket Granting Ticket
首先我们的客户端先向KDC域控发送我们的身份信息，里面包含着账户名和计算机名。然后发送过去之后，KDC要验证发送的用户名和计算机名是否在自己的AD里。倘若认证通过，KDC就会返回两个hash值，一个是客户端登陆username的NTLM Hash加密一个session key(KDC 随机生成的字符)，另一个是TGT(KDC的hash加密一个客户端和session key的信息)，KDC Hash是AD某个特殊的用户(krbtgt)对应的hash。详细剖析包含内容
首先客户端会向KDC发送一个KRB_AS_REQ这样一个请求，这个请求中就包含了三个内容。第一个是被客户端dzdbd加密的一个时间戳，用于KDC验证客户端身份的；第二个是客户端的一些基本信息，如用户名、计算机名、地址之类的信息，KDC以此来查找客户端的hash值；第三个是请求服务端的TGS相关的信息。最后打包好一并发送给KDC进行验证。
下面我们来看看回应的过程
在验证后，KDC会返回一个KRB_AS_REP回应，里面包含了两个内容，一个是Client Hash，是被Client Hash加密的Session Key，用于后续与TGS服务通信，这个是由AS返回的；另一个是我们的TGT(用于向TGS申请票据的凭证)。TGT包含了Session Key、客户端名(域名、域客户端)、到期时间(时间戳)。当这个KRB_AS_REP发送到客户端时，客户端能够解密Client Hash，但是没有KDC的hash，所以不能解密TGT，但是它依然能和TGS通信，那将进入域认证的第二步。
第二步：Session Key与Ticket
在第一步中客户端自己解密出来的Session Key加密客户端的信息和时间戳信息，还有部分的服务端信息，然后发送给KDC，接着KDC的TGS进行认证，然后TGS根据KDC的hash解密TGT。这里解释下为什么首先解密TGT，因为KDC里没有session Key，而TGT里有session key，它通过自己的TGT Hash解密出来session key，然后通过session key解密客户端包装的信息，解密出来时间戳，比对这个时间戳是否跟当时时间相差太久，若是，则认为不安全并且重新认证，因为kerberos认为如时间相差太久，这个数据包就有可能是攻击者伪造出来的。当TGS解密出来的session key里的客户端信息与前面第一步中的session key里的客户端信息进行比对，若相等，则认证通过。与此同时TGS还要判断客户端是否具有权限访问服务端对应的某个服务。
认证通过后又会返回一个数据包给客户端，首先它会返回一个一直在使用的session key去加密某个server session key，这个server session key是KDC又生成了一个随机字符，这个随机字符和session key在表现形式上一样，但是生成的结果不同，因为是在不同的时间生成的随机数，这个server session key是客户端和服务端用于通信的重要的一个session key，若没有，则无法进行下面的认证。接着KDC会提取server info的信息，里面包含了服务器的计算机名，KDC根据计算机名去提取对应的hash值去加密这个ticket。
以下为Ticket的结构内容
其实这个过程中和我们刚才AS返回的TGT的结构是相同的，唯一不同的是Ticket里面的是Server Session Key而TGT里面的是Session Key。当客户端获得这个数据包后，因为客户端有Session Key，所以它能够解密出Server Session Key，但是不能解密出Ticket。
第三步：Server Session Key与Ticket
最后客户端要发送一个KRB_AP_REQ数据包和Server进行通信，客户端无法解密Ticket，但是有Session Key，能够解密出Server Session Key，因此开启构造数据包，使用Server Session Key加密客户端信息和时间戳发送给服务端。那么当数据包到达服务端后，服务端有自己的hash，所以首先解密Ticket，而Ticket里包含了我们的Server Session Key，然后再通过Server Session Key能够解密出客户端和时间戳，然后进行校验来源的客户端和Ticket的客户端是否相等。同时它还要判断时间戳是否大于阈值，还有要判断Ticket的到期时间。
其实整个Kerberos认证的流程中，TGT和Ticket的结构是相同的，只是Server Session Key和Session Key是不同的，而Session Key是AS给客户端的，Server Session Key是TGS给客户端的。整个认证流程的本质是不停地交换密钥，然后采用对称加密算法，不停地校验时间戳和身份来完成的一个安全认证。
参考文章https://blog.csdn.net/sky_jiangcheng/article/details/81070240