在上一篇浅谈windows认证原理中,我们介绍了windows认证的基本流程和加密的hash原理。本文我们将通过抓包分析,进一步了解windows网络认证相关的知识。
NTLM 是一种网络认证协议,以 NTLM Hash 作为凭证进行认证。NTLM Hash 长度为32位,由数字和字母组成,采用挑战/响应(Challenge/Response)的消息交换模式,
这个协议只支持 Windows.
NTLM 协议的认证过程分为三步:
详细过程
下面抓包进行分析
192.168.141.1(WIN10)——>192.168.141.139(WIN2008)
这个过程是客户端向服务器发送 type 1(协商)消息,它主要包含客户端支持和服务器请求的功能列表。
主要包含以下结构
![](https://gitee.com/asdasdasd123123/pic/raw/master/img/19/4.png)
![](https://gitee.com/asdasdasd123123/pic/raw/master/img/19/5.png)
这个过程是服务器用 type 2 消息(质询)进行响应,这包含服务器支持和同意的功能列表。但是,最重要的是,它包含服务器产生的 Challenge。
主要包含以下结构
![](https://gitee.com/asdasdasd123123/pic/raw/master/img/19/6.png)
其中最主要的信息是 challenge。后面加密验证依赖于 challenge
![](https://gitee.com/asdasdasd123123/pic/raw/master/img/19/7.png)
这个过程客户端接收到 challenge 之后,使用用户 hash 与 challenge 进行加密运算得到 response,将 response,username,challenge 发给服务器。消息中的 response 是最关键的部分,因为它向服务器证明客户端用户已经知道帐户密码。
主要包含以下结构
![](https://gitee.com/asdasdasd123123/pic/raw/master/img/19/8.png)
这里的 Challeng 不同于 type2 的 Challenge,这里的 Challenge 是一个随机的客户端 nonce。
MIC 是校验和,设计 MIC 主要是为了防止这个包中途被修改
sessionkey 是在要求进行签名的时候用的,用来进行协商加密密钥,可能有些文章会说 sessionkey 就是加密密钥,需要拥有用户 hash 才能计算出来,因此攻击者算不出来,就无法加解密包。但是想想就不可能,这个 session_key 已经在流量里面明文传输,那攻击者拿到之后不就可以直接加解密包了。
![](https://gitee.com/asdasdasd123123/pic/raw/master/img/19/9.png)
注意点:
NTLMv1 和 NTLMv2 的加密因素都是 NTLM Hash,而最显著的区别就是 Challenge 和加密算法不同,共同点就是加密的原料都是 NTLM Hash。
设置系统使用 LM 还是 NTLM 还是 NTLMv2,需要修改 Local Security Policy 中的 LmCompatibilityLevel 选项
在 type3 中的响应,有六种类型的响应
这六种使用的加密流程一样,都是 Challenge/Response 验证机制,区别在 Challenge 和加密算法不同。
在以上流程中,登录用户的密码 hash 即 NTLM hash。其中,经过 NTLM Hash 加密 Challenge 的结果在网络协议中称之为 Net NTLM Hash,response 中包含 Net-NTLM hash.
在 NTLM 认证中,NTLM 响应分为 NTLM v1,NTLMv2,NTLM session v2 三种协议,不同协议使用不同格式的 Challenge 和加密算法.所以也就存在不同协议的 Net-NTLM hash,即 Net-NTLM v1 hash,Net-NTLM v2 hash
Net-NTLM v1 hash
v1 是将 16字节的 NTLM hash 空填充为 21 个字节,然后分成三组,每组7比特,作为 3DES 加密算法的三组密钥,加密 Server 发来的 Challenge。 将这三个密文值连接起来得到 response。
Net-NTLM v2 hash
v2 将 Unicode 后的大写用户名与 Unicode 后的身份验证目标(在 Type 3 消息的”TargetName”字段中指定的域或服务器名称)拼在一起。请注意,用户名将转换为大写,而身份验证目标区分大小写,并且必须与“TargetName”字段中显示的大小写匹配。使用 16 字节 NTLM 哈希作为密钥,得到一个值。
建一个 blob 信息
使用 16 字节 NTLMv2 哈希作为密钥,将 HMAC-MD5 消息认证代码算法加密一个值(来自 type 2 的 Challenge 与 Blob 拼接在一起)。得到一个 16 字节的 NTProofStr。
将 NTProofStr 与 Blob 拼接起来形成得到 response。至于选择哪个版本的响应由 LmCompatibilityLevel 决定。
Challenge/Response 验证机制里面 type3 response 里面包含 Net-ntlm hash,NTLM v1 响应和 NTLMv2 响应对应的就是 Net-ntlm hash 分为 Net-ntlm hash v1 和 Net-ntlm hash v2。
Net-ntlm hash v1 的格式为:
username::hostname:LM response:NTLM response:challenge
Net-ntlm hash v2 的格式为:
username::domain:challenge:HMAC-MD5:blob
下面演示从 response 里面提取 NTLMv2
这里的 challenge 是 type2 服务器返回的 challenge 不是 type3 流量包里面的 client Challenge
就是 18f77b6fe9f8d876
HMAC-MD5 对应数据包中的 NTProofSt : 0ecfccd87d3bdb81713dc8c07e6705b6
blob 就是 response 减去 NTProofStr。(因为在计算 response 的时候,response 就是由 NTProofStr 加上 blob)
所以最后,Net-NTLM v2 Hash 值为:
Administrator::DESKTOP-QKM4NK7:18f77b6fe9f8d876:0ecfccd87d3bdb81713dc8c07e6705b6:01010000000000002a470d3bc233d6017eb1f527b5e7bd4d0000000002001e00570049004e002d0041003500470050004400430050004a0037004f00540001001e00570049004e002d0041003500470050004400430050004a0037004f00540004001e00570049004e002d0041003500470050004400430050004a0037004f00540003001e00570049004e002d0041003500470050004400430050004a0037004f005400070008002a470d3bc233d601060004000200000008003000300000000000000001000000002000003737fbe7dbcbd2c8e5d7a030f44586c91423d9c5202f827f3f6cf26f69adbfe80a001000000000000000000000000000000000000900280063006900660073002f003100390032002e003100360038002e003100340031002e003100330039000000000000000000
上面的 Net-NTLM v2 Hash 值若使用 hashcat 爆破应为 Abcd1234
LM 与 NTLM 协议的认证机制相同,但是加密算法不同。目前大多数的 Windows 都采用 NTLM 协议认证,LM 协议已经基本淘汰了。
本文通过抓包分析讲解了ntlm的协商、质询、身份验证等过程,演示了从 response 里面提取 NTLMv2的 Net-NTLM hash。由于篇幅所限,windows域认证kerberos过程将在下一篇文章中讲解。
本文作者 r0fus0d
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。