最近看了下教学，感觉有点迷，做个笔记

Windows 3大认证机制

Note：一定要记住NTLM Hash，因为它在Windows认证机制中经常出现
NTLN Hash大致计算方式：用户密码->HEX编码->Unicode编码->MD4

Python计算NTLM Hash

from passlib.hash import nthash
print(nthash.hash((密码))

本地认证

用户输入用户名和密码，Windows收到用户输入的认证信息之后将密码计算成NTLM Hash再与SAM数据库中的给定用户名的Hash相比对，能匹配上则登陆成功，否则登陆失败
本地认证中用来处理用户输入密码的进程即lsass.exe，密码会在这个进程中明文保存，供该进程将密码计算成NTLM Hash与sam进行比对。在使用mimikatz来获取的明文密码过程中，就是在这个进程中读取到的

域认证：Kerberos

域认证即采用了Kerberos协议的认证机制，其中有域控制器（DC：Domain Controller）的参与，物理上的域控制器在认证中同时扮演以下角色：KDC (Key Distribution Centre)、DC (Domain Controller) 和AD(Account Database) + AS (Authenication Service) + TGS(Ticket Granting Service)
AD (Account Database)储存了域中所有用户的用户名和其对应的NTLM Hash，即为域中的SAM数据库，KDC可以从AD中提取所有用户的NTLM Hash，这是Kerberos协议的实现基础

Kerberos协议的基本概念

票据 (Ticket): 访问网络上的对象的凭据
TGT (Ticket Granting Ticket): 用于生成凭据的凭据
KDC (Key Distribution Centre): 密钥分发中心，负责管理、认证、分发票据；KDC由以下服务组成：AS (Authentication Service): 身份验证服务 和 TGS (Ticket Granting Service) 票据授予服务；其中AS是负责为用户生成TGT的服务，TGS是负责为用户生成对某个服务访问的票据(Ticket)，也就是用户从AS处取得TGT后，再带着TGT来到TGS这里申请对某个服务/服务器/资源的访问票据，只有获取到这个票据，用户才有相应的权限来访问对应的服务/服务器/资源

Kerberos认证流程

• 1. 用户向KDC的AS服务请求开具身份证明。
• 2. AS服务认证成功后返回给用户认证权证（TGT，黄金票据攻击需要伪造的票据）
• 3. 用户拿着TGT到KDC的TGS服务申请票据
• 4. TGS认证成功后返回给用户服务授予票据（Service Ticket，ST）
• 5. 用户拿着ST去访问服务
• 6. 服务向DC核实，返回相应的服务资源

图例

网络认证：Net NTLM

这个认证机制就是在工作组环境下远程访问服务/服务器/资源所采用的认证机制
该机制的认证过程有3步：1.协商 --> 2. 质询 --> 3. 验证

协商

双方确定使用的协议版本，NTLM存在V1和V2两个版本，具体区别就是加密方式不同

质询

挑战(Chalenge)/响应(Response)认证机制的核心

• 第1步. 用户向服务器发送给验证请求(只带有用户名/登录名)
• 第2步. 服务器收到请求后，判断本地用户列表是否存在客户端发送的用户名，如果没有返回认证失败，如果有，生成一个16位的随机数，称之为“Challenge”，然后使用登录用户名对应的NTLM Hash加密Challenge(16位随机字符)，生成Challenge1保存在内存中。同时，在生成Challenge1后，将Challenge(16位随机字符)发送给用户
• 第3步. 用户收到服务器返回的Challenge(16位随机字符)之后会使用自己输入的密码成成的NTLM Hash对Challenge进行加密，再用加密结果生成响应包，最后把该响应包发回到服务器

验证

这一步在质询完成后进行，是认证的最后一步：服务器在收到用户发送的响应包后，把用户生成的加密结果和先前保存在内存中的Challenge1相比对，如果匹配则认证通过，否则认证失败
在这里，经过NTLM Hash加密的Challenge的结果，在这个认证机制中称之为Net NTLM Hash，这个Hash不能用于进行Hash传递攻击，但是可以通过暴力破解来获得明文密码

博主的思考

在这个认证机制中，关键点在于用户发送的响应包数据和服务器自身储存的认证数据，因为两者都是用NTML Hash加密同一随机字符串的结果来进行验证：也就是说，只需要得到正确的NTLM Hash即可通过认证。
注意：在工作组环境和域环境下Net NTLM认证过程因为有DC（域控制器）的参与，以致流程略有差异，不过这不会给哈希传递攻击造成影响

Kerberos认证流程详解

域验证采用的是Kerberos协议，搞域渗透那就一定要详细了解Kerberos认证的流程
在Kerberos认证的流程中，必定有3个角色：用户、服务器和KDC，其中KDC包含了AS和TGS

相关概念

下面这几个概念/术语上文已经有提到，这里就不厌其烦再提一次

• KDC(Key Distribution Centre): 密钥分发中心，包含AS和TGS
• AS(Authentication Server): 身份认证服务，是KDC中专门用来认证客户端身份的认证服务器
• TGS(Ticket Granting Server): 票据授予服务，该服务提供的票据也称为TGS或者叫白银票据
• TGT(Ticket Granting Ticket): 由身份认证服务授予的票据，票据授予票据，别称黄金票据(Golden Ticket)，用于身份认证，存储在服务器的内存，默认有效期为10小时

需要记住的一些关键点

• 对应用户名的NTLM Hash就是：用户密钥、TGS密钥、Service密钥，都是同一个东西
• TGS密钥、KDC Hash、krbtgt用户的Hash都是同一个东西
• Server和Service可以看作是同一个东西，就是用户要访问的资源/服务/服务器

Kerberos认证的三次通信

第一次

为了获得能够访问服务/服务器/资源的票据，用户首先要访问KDC以获得服务授予票据。因为这是用户第一次访问KDC，KDC现在也不能够确定用户身份，因此第一通信的目的是让KDC能够认证用户的身份、确认用户是可靠的并且有KDC的访问权限。过程如下：

• 1. 用户向KDC发起请求，请求中的信息为明文，其中包含用户名、IP地址、当前时间戳
• 2. KDS中的AS(Authentication Server)在接收到请求之后，就会在Kerberos认证数据库(域控的SAM数据库)中来查找由用户提供的用户名是否存在，这个过程并不会去判断用户身份的可靠性
• 3. 如果数据库中没有该用户名，认证失败，结束；如果该用户名存在，AS则会响应该请求，该响应包含2部分
  • 1. 这部分称之为TGT(票据授予票据)，用户需要带上该TGT访问KDC的TGS以获取访问服务/服务器/资源所需要的Ticket(服务授予票据)。该TGT中包含Kerber数据库中与用户所提供一致的用户名、用户的IP、当前时间戳、用户即将访问的TGS的名字、TGT的有效期、用户与TGS通讯的Session Key(SK1)。整个TGT使用TGS密钥进行加密，用户是无法解密TGT的，又因为TGT密钥从未在网络中进行过传输，所以也不存在TGT密钥被劫持破解的情况
  • 2. 第二部分内容是用Kerberos数据库中对应用户名的NTLM Hash加密的内容，其中包含用户与TGS通讯的Session Key(SK1)、用户即将访问的TGS的名字、TGT的有效期、当前的时间戳。如果用户不能够用自己所提供的密码的NTLM Hash解密该部分的内容，身份认证失败，认证流程终止

图例

第二次

这个时候用户收到了KDC的响应包(实际上是AS的)并且获取到了响应包中的2部分内容，用户会用自己所提供的密码的NTLM Hash对第二部分进行解密并获得该部分的内容(与TGS通讯的Session Key(SK1)、用户即将访问的TGS的名字、TGT的有效期、TGT的时间戳)。首先用户会根据TGT的时间戳判断请求和相应之间的时间差是否大于5分钟，如果时间差大于5分钟，则判定该AS是伪造的，认证失败；否则用户则准备向TGS发起请求
查实这一次的请求的只要目的是用户要获取到能够访问相应服务/服务器/资源的Ticket(服务授予票据)。

在本次的通信中，用户将以下3部分内容发送到KDC中的TGS

• 1. 用户用SK1将自己的IP地址、当前时间戳、名字(计算机名？用户名？目前理解为能标识用户的计算机的标识符)加密
• 2. 想要访问的服务/服务器/资源的IP地址 (这部分是明文)
• 3. TGS密钥加密过的TGT (原封不动)

TGS在收到来自用户的这个请求后

• 1. 根据请求中要求访问的IP地址来查询Kerberos中是否存在可以被用户访问的服务/服务器/资源。如不存在，认证失败，结束；否则继续进行认证
• 2. TGS用TGS密钥解密TGT，此时TGS能看到经过AS认证后的用户信息(用户名、用户的IP、生成TGT的时间戳、用户即将访问的TGS的名字、TGT的有效期、用户与TGS通讯的Session Key(SK1))
• 3. 如果时间差在允许的范围之内，TGS会用SK1解密经用户使用SK1加密的内容，把其中的信息和TGT的信息相比对，如果全部相同则认为用户的身份正确，进行下一步
• 4. 此时KDC响应用户，响应内容包括
  • 1. 用Server密钥(服务器的NTLM Hash)加密的用于用户访问服务/服务器/资源的Server Ticket(ST，服务授予票据)；ST中包含名字、用户的IP、用户想要访问的服务/服务器/资源的IP地址、ST的有效期、当前时间戳、用于用户和服务器之间加密通讯的Session Key(SK2)
  • 2. 这部分用SK1加密，内容包括：SK2、当前时间戳、ST的有效期。(注意：由于在第一次通信过程中，用户处已经保存了SK1，所以这一部分用户是可以自行解密的)

图例

第三次

在用户收到来自KDC(TGS)的响应后，用SK1解密响应数据包的第二部分，检查时间戳无误后，取出SK2准备向服务器发起最后的请求

用户向服务器发起请求，请求包含以下2部分内容

• 1. 用SK2加密的名字、用户的IP、当前时间戳、ST的有效期
• 2. ST

服务器在收到来自用户的请求后，会使用Server密钥解密ST，核对时间戳后将SK2取出，用SK2解密数据包的第一部分，在ST解密后的信息和SK2加密后的信息比对通过后，服务器最终确认该用户就是KDC人认证的具有真实身份的用户，是可以向其提供服务的用户，此时服务器响应请求，响应数据包被服务器用SK2加密。用户收到响应后，使用SK2解密响应包后也确定了服务器的身份。(注：服务器在通讯过程中其实还会使用数字证书证明自己的身份)

图例

3次通讯结束

3次通信的完成代表着整个Kerberos的认证的完成，用户和服务器都确认了对方的身份，此时就可以开始网络通信了

小结

整个Kerber认证过程比较复杂，每一次通信都使用了不同种类的密钥，这样能够保证整个Kerberos的认证过程具有较高的安全性。

Kerberos认证整体流程图

Kerberos认证时序图