Windows域认证机制

Windows认证机制

Windows认证基础

Windows的认证包括三个部分：

• 本地认证：用户直接操作计算机登陆账户
• 网络认证：远程连接到工作组中的某个设备
• 域认证：登陆到域环境中的某个设备

本地认证

1. 用户输入密码
2. 系统收到密码后将用户输入的密码计算成NTLM Hash
3. 与sam数据库（%SystemRoot%\system32\config\sam）中该用户的哈希比对
4. 匹配则登陆成功，不匹配则登陆失败

NTLM哈希，是一种单向哈希算法，Windows将用户的密码计算成NTLM哈希之后才存储在电脑中

大致的运算流程为：

用户密码->HEX编码->Unicode编码->MD4

pip3 install passlib

>>> from passlib.hash import nthash
>>> print(nthash.hash('admin'))
209c6174da490caeb422f3fa5a7ae634

NTLM Hash的前身是LM Hash，由于存在安全缺陷已经被淘汰

本地认证中用来处理用户输入密码的进程即lsass.exe,密码会在这个进程中明文保存，供该进程将密码计算成NTLM Hash与sam进行比对，我们使用mimikatz来获取的明文密码，便是在这个进程中读取到的

网络认证

网络认证即在工作组环境下远程登陆另一台电脑所采用的认证机制

NTLM协议的认证过程分为三步，也叫挑战相应机制：

• 1.协商

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

在NTLM认证中，NTLM响应分为NTLM v1，NTLMv2，NTLM session v2三种协议，不同协议使用不同格式的Challenge和加密算法

• 2.质询

挑战（Chalenge）/响应（Response）认证机制的核心

1. 客户端向服务器端发送用户信息(用户名)请求

2. 服务器接受到请求后，判断本地用户列表是否存在客户端发送的用户名，如果没有返回认证失败，如果有，生成一个16位的随机数，被称之为"Challenge"， 然后使用登录用户名对应的NTLM Hash加密Challenge(16位随机字符)， 生成Challenge1保存在内存中。同时，生成Challenge1后，将Challenge(16位随机字符)明文发送给客户端。

3. 客户端接受到Challenge后，使用自己提供的账户的密码转换成对应的NTLM Hash，然后使用这个NTLM Hash加密Challenge生成Response，然后将Response发送至服务器端。

• 3.验证

在质询完成后，验证结果，是认证的最后一步。

服务端收到客户端发送的Response后，与之前保存在内存中的Channelge1比较，如果相等认证通过

其中，经过NTLM Hash加密Challenge的结果在网络协议中称之为Net NTLM Hash（不能直接用来进行哈希传递攻击，但可以通过暴力破解来获取明文密码）

其中的关键点在于：第二步中客户端发送的是NTLM哈希值与随机字符串加密的结果，而这个NTLM哈希是由用户输入的密码本地计算得出的，所以在这个步骤中，只要能提供正确的NTLM哈希即使不知道正确的密码也可通过认证

hashcat破解net-ntlm hash

NTLMv2的格式为：

username::domain:challenge:HMAC-MD5:blob

hashcat -m 5600 net-ntlm /tmp/password.list -o found.txt --force

-m：hash-type，5600对应NetNTLMv2
详细参数可查表：https://hashcat.net/wiki/doku.php?
-o：输出文件 字典文件为/tmp/password.list
--force：代表强制执行，测试系统不支持Intel OpenCL

域认证

域内认证即采用了Kerberos协议的认证机制，与前两者相比最大的区别是有个一个可信的第三方机构KDC的参与

参与域认证的三个角色：

• Client
• Server
• KDC(Key Distribution Center) = DC(Domain Controller) = AD（Account Database）+ AS（Authenication Service）+ TGS（Ticket Granting Service）

从物理层面看，AD与AS，TGS，KDC均为域控制器(Domain Controller)。

Kerberos认证协议的基础概念

• 票据(Ticket):

是网络对象互相访问的凭证。

• TGT(Ticket Granting Ticket):

看英文名就知道，用来生成Ticket的Ticket

• AD(Account Database):

存储域中所有用户的用户名和对应的NTLM Hash，可以理解为域中的SAM数据库，KDC可以从AD中提取域中所有用户的NTLM Hash，这是Kerberos协议能够成功实现的基础。

• KDC(Key Distribution Center):

密钥分发中心，负责管理票据、认证票据、分发票据，里面包含两个服务：AS和TGS

• AS(Authentication Server):

身份认证服务，为Client生成TGT的服务，也用来完成对Client的身份验证

• TGS(Ticket Granting Server):

票据授予服务,为Client生成允许对某个服务访问的ticket，就是Client从AS那里拿到TGT之后，来TGS这里再申请对某个特定服务或服务器访问的Ticket，只有获取到这个Ticket，Client才有权限去访问对应的服务，该服务提供的票据也称为 TGS 或者叫白银票据

• TGT(Ticket Granting Ticket):

由身份认证服务授予的票据(黄金票据)，用于身份认证，存储在内存，默认有效期为10小时

注意：

Client 密钥 TGS密钥 和 Service 密钥 均为对应用户的NTLM Hash

TGS密钥 == KDC Hash == krbtgt用户的NTLM Hash

Server 和 Service可以当作一个东西，就是Client想要访问的服务器或者服务
S
Client/(TGS/Server) Sessionkey 可以看作客户端与TGS服务和尝试登陆的Server之间会话时用来加密的密钥，而(Client/TGS/Service)密钥(上面提到的三个实际为NTLM Hash的密钥)是用来加密会话密钥的密钥，为了保证会话密钥的传输安全，这些加密方式均为对称加密

参与认证的三个角色的NTLM Hash是三个密钥，这三个NTLM Hash的唯一作用是确保会话密钥Sessionkey的安全传输

Kerbreros认证流程

Client向KDC发起服务请求，希望获取访问Server的权限。 KDC得到了这个消息，首先得判断Client是否是可信赖的， 也就是从AD数据库中寻找该用户是否可用来登录。这就是AS服务完成的工作，成功后，AS返回TGT给Client。

Client得到了TGT后，继续向KDC请求，希望获取访问Server的权限。KDC又得到了这个消息，这时候通过Client 消息中的TGT，判断出了Client拥有了这个权限，给了Client访问Server的权限Ticket。（TGS服务的任务）

Client得到Ticket后便可以使用这个Ticket成功访问Server。但是这个Ticket只能用来访问这个Server，如果要访问其他Server需要向KDC重新申请。

1. 用户登录

• 用户输入 [用户名] 和 [密码] 信息
• 在客户端，用户输入的 [密码] 通过计算生成NTLM哈希作做为 [CLIENT密钥]

2. 请求身份认证

2.1 客户端向AS(身份认证服务)发送认证请求

• 客户端向AS发送认证请求，请求中带有明文的 [用户名] 信息

此时并未发送[密码]或[密钥]信息

2.2 AS确认Client端登录者用户身份

1. AS收到用户认证请求之后，根据请求中的 用户名 信息，从数据库中查找该用户名是否存在。
2. 如果 用户名 存在，则根据该用户名提取NTLM Hash做为AS生成的CLIENT 密钥，如果第1步中用户提供的 密码 信息正确，该秘钥与用户登录中的 CLIENT密钥 是相等的。
3. AS为Client响应如下消息：
   • Msg A 使用 KDC生成的CLIENT密钥 加密的CLIENT/TGS SESSIONKEY
   • Msg B 使用 TGS密钥 加密的TGT(TICKET-GRANTING-TICKET)，客户端没有KDC NTLM Hash因此Client无法解密TGT。
   • TGT中包含如下信息：
     • [Client/TGS SessionKey]
     • Client ID
     • Ticket有效时间
     • CLient 地址
4. Client收到AS的响应消息以后，利用自身的 CLIENT密钥 可以对Msg A进行解密，这样可以获取到 CLIENT/TGS SESSIONKEY 。但由于Msg B是使用 TGS密钥 加密的，Client无法对其解密。

• AS响应的消息中有一条是属于Client的，但另外一条却属于TGS。
• Client/TGS SessionKey出现了两个Copy，一个给Client端，一个给TGS端。
• 认证过程中的加密除哈希外均采用的是对称加密算法。

3. 请求服务授权

3.1 客户端向TGS发送请求服务授权请求

客户端发送的请求中包含如下两个消息：

• Msg C
  • 要请求的服务ID, 即[Service ID]
  • 上一步2.2中由AS为Client提供的TGT。
• Msg D
  • 使用 CLIENT/TGS SESSIONKEY 加密的Authenticator 1 {Client ID, Timestamp}。

KDC接收到TGT与其他内容后，会首先使用KDC 的NTLM Hash解密TGT，只有KDC可以解密TGT，从TGT中提取到 CLIENT/TGS SESSIONKEY ，再使用 CLIENT/TGS SESSIONKEY 解密Authenticator 1，获取到{Client ID, Timestamp} 并与通过解密TGT获取到的{Client ID, 有效时间}进行对比

3.2 TGS为Client响应服务授权票据

TGS为Client响应的消息包括：

• Msg E 使用 SERVICE密钥(服务器的NTLMHASH) 加密的 CLIENT-TO-SERVER TICKET , 该Ticket中包含了如下信息:
  • [Client/Server SessionKey]
  • Client网络地址
  • Ticket有效时间
  • Client ID
• Msg F 使用 CLIENT/TGS SESSIONKEY 加密的 CLIENT/SERVER SESSIONKEY 。

Msg F使用了 CLIENT/TGS SESSIONKEY 加密，因此，该消息对Client可见。Client对其解密以后可获取到 CLIENT/SERVER SESSIONKEY 。

而Msg E使用了 [SERVICE密钥] 加密，该消息可视作是TGS给Service Server的消息，只不过由Client一起携带发送给Service Server

4.发送服务请求

4.1 Client向Service Server发送服务请求

发送的消息中包括：

• Msg E 上一步3.2中，TGS为Client响应的消息Msg E。该消息可以理解为由Client携带的消息。
• Msg G 由[Client/Server SessionKey]加密的Authenticator 2，包含{Client ID, Timestamp}信息。

1. CLIENT/SERVER SESSIONKEY 并非直接传输，而是被包含在使用[Service密钥]加密的Msg E中。
2. 既然 [CLIENT/SERVER SESSIONKEY] 并不直接明文传输， Client需要向Service Server证明自己拥有正确的 CLIENT/SERVER SESSIONKEY ，所以，Authenticator 2使用了 CLIENT/SERVER SESSIONKEY 加密。

4.2 SS响应Client

SS收到客户端的服务请求之后，先利用自身的 [SERVICE密钥] 对Msg E进行解密，提取出Client-To-Server Ticket, 在3.2步骤中，提到了该Ticket中包含了 CLIENT/SERVER SESSIONKEY 以及Client ID信息。

SS使用 CLIENT/SERVER SESSIONKEY 解密Msg G，提取Client ID信息，而后将该Client ID与Client-To-Server Ticket中的Client ID进行比对，如果匹配则说明Client拥有正确的 CLIENT/SERVER SESSIONKEY 。

而后，SS向Client响应Msg H(包含使用 CLIENT/SERVER SESSIONKEY 加密的Timestamp信息)。

Client收到SS的响应消息Msg H之后，再使用 CLIENT/SERVER SESSIONKEY 对其解密，提取Timestamp信息，然后确认该信息与Client发送的Authenticator 2中的Timestamp信息一致。

如上信息可以看出来，该交互过程起到了Client与SS之间的“双向认证”作用。

票据伪造的原理

• 2.2 AS确认Client端登录者用户身份

  • KDC返回的Msg B：使用 TGS密钥(KDCHASH/KRBTGT用户NTLMHASH) 加密的TGT(Ticket-Granting-Ticket)，当我们获取到krbtgt用户的NTLM哈希后，便可主动使用krbtgt用户的NTLM哈希做为TGS密钥来生成TGT发送给KDC，这样KDC如果通过解密伪造TGT获取到伪造的 [CLIENT/TGS SESSIONKEY] 可以成功解密 Authenticator 1 并完成与TGT中的数据进行比对，便成功骗过了KDC，也就是成功伪造了黄金票据

• 4.1 Client向SS(Service Server)发送服务请求

  • 客户端向服务器发送的为使用 SERVICE密钥(服务器的NTLMHASH) 加密的 CLIENT-TO-SERVER TICKET Ticket中包含用来供服务器解密Authenticator 2的 CLIENT/SERVER SESSIONKEY 。如果获取到了Service Server的NTLM Hash，便可伪造Ticket，和Authenticator 2 ，Service Server在接收到Ticket和Authenticator 2后可以使用自己的NTLM Hash正常解密完成比对，也就是成功伪造了白银票据

关于Service Hash，Service Hash其实是目标中一个用户名与hostname相同的用户的Hash
如hostname为PC-WIN7的服务器，对应的Hash就是Username : PC-WIN7$的哈希

参考

Windows下的密码hash——NTLM hash和Net-NTLM hash介绍

彻底理解Windows认证 - 议题解读 « 倾旋的博客