WEB安全--内网渗透--LM&NTLM基础

一、前言

LM Hash 和NTLM Hash是Windows系统中的两种加密算法，不过LM Hash加密算法存在缺陷，在Windows Vista 和 Windows Server 2008开始，默认情况下只存储NTLM Hash，LM Hash将不再存在。所以我们会着重分析NTLM Hash。

在我们内网渗透的过程中，有通过抓取Windows服务器内部的hash值登录到域环境中的其他服务器进行横向渗透这一方式。

Windows（登录）的认证方式有两种：

1.1、本地认证

本地认证指操作系统运行winlogon进程 显示登录界面，接收用户的输入，然后将输入的密码交给lsass进程 ，这个进程执行两个操作：①使用动态秘钥对称加密(mimikatz可以解密 )的方式在内存中缓存一份"明文密码" ②将密码转换成NTLM Hash ，然后会将NTLM Hash与本地的SAM数据库中存储的密码进行比对，如果一致则通过验证。

补充：

windows内部是不保存明文密码的，只保存密码的hash。其中本机用户的密码hash是放在本地的SAM文件里面，域内用户的密码hash是存在域控的NTDS.DIT文件里面。

1.2、网络认证

内网中的网络环境可以分为工作组环境 和域环境，它们使用的加密协议：

**工作组环境：**NTLM Hash（默认） || LM Hash（被淘汰）

**域环境：**Kerberos（默认） || NTLM Hash（不满足Kerberos条件）

所以在某些情况下，域环境中的服务器也可以使用NTLM Hash加密算法。

用户在内网中服务器之间的登录操作是基于这些协议加密算法来建立安全的连接的，具体的实现请看下面的解析。

二、SSPI&SSP

在学习NTLM协议之前，我们需先了解两个概念：SSPI&SSP

2.1、SSPI

SSPI是Windows定义的一套接口，该接口定义了与安全有关的功能函数，如：

1、身份验证机制

2、为其他协议提供的Session Security机制（会话安全机制），为通讯提供数据完整性校验以及数据的加、解密功能

该接口只是定义了一套接口函数，但是并没有实现具体的内容。

2.2、SSP

SSP是SSPI的具体实现，微软自己实现了如下的SSP，用于提供安全功能，如：

1、NTLM SSP：为Windows 2000之前的客户端-服务器域和非身份域验证（SMB/CIFS）提供NTLM质询/响应身份验证

2、Kerberos SSP：Windows2000及更高版本中首选的客户端-服务器域相互身份验证

3、Digest SSP

4、Negotiate SSP

5、Cred SSP

6、Schannel SSP

......

三、NTLM身份认证

NTLM协议是一种网络协议认证，采用一种质询/应答（Challenge/Response）的信息交换模式。

认证流程：

1、协商：确定双方协议版本、加密等级

2、质询：质询/应答（Challenge/Response）信息交换的过程

3、认证：验证结果

3.1、质询过程

在工作组环境下：

①：用户通过密码登录客户端电脑

②：(type 1)客户端向服务器发送type 1(协商)消息,它主要包含客户端支持和服务器请求的功能列表，如设备信息、密码信息等

③：接收请求，生成Challenge。加密Challenge，生成Net-NTLM Hash

④：(type 2)服务器用type 2消息(质询)进行响应，这包含服务器支持和同意的功能列表。但是，最重要的是，它包含服务器产生的Challenge

⑤：接收到Challenge后，使用将要登录到账户对应的NTLM Hash加密Challenge生成Response

⑥：(type 3)客户端用type 3消息(身份验证)回复质询。将response,username,challenge发给服务器。消息中的response是最关键的部分，因为它们向服务器证明客户端用户已经知道帐户密码

⑦：比对Server生成的Net-NTLM Hash与Response是否相等

⑧：验证成功

3.2、数据包信息

NTLM只是底层的认证协议，其必须镶嵌在上层应用协议里面，消息的传输依赖于使用NTLM的上层协议，如SMB、HTTP等。

数据包的关键信息如下：

协商（type1）：

Negotiate Flags具体内容如下：

质询（type2）：

其中最主要的信息是challenge，如下：

认证（type3）：

这里的Challenge不同于type2 的Challenge，这里的Challenge是一个随机的客户端nonce。

数据包内容如下：

可以看到type3 Response响应消息数据包中的是NTLMv2响应。那NTLMv2响应是怎样构建出type3 Response的呢？

请看下面介绍：

3.3、NTLMv2响应

在type3中的响应，有六种类型的响应：

LM(LAN Manager)响应 - 由大多数较早的客户端发送，这是"原始"响应类型。
NTLMv1响应 - 这是由基于NT的客户端发送的，包括Windows 2000和XP。
NTLMv2响应 - 在Windows NT Service Pack 4中引入的一种较新的响应类型。它替换启用了 NTLM版本2的系统上的NTLM响应。
LMv2响应 - 替代NTLM版本2系统上的LM响应。
NTLM2会话响应 - 用于在没有NTLMv2身份验证的情况下协商NTLM2会话安全性时，此方案会更改LM NTLM响应的语义。
匿名响应 - 当匿名上下文正在建立时使用; 没有提供实际的证书，也没有真正的身份验证。"存根"字段显示在类型3消息中。

NTLMv2加密算法

Net-ntlm hash v2的格式为：

复制代码

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

type3中Response的构成方式：

①将Unicode后的大写用户名与Unicode后的身份验证目标（在Type 3消息的"TargetName"字段中指定的域或服务器名称）拼在一起；

②构建一个blob信息；

③使用16字节NTLMv2哈希作为密钥，将HMAC-MD5消息认证代码算法加密一个值(来自type 2的Challenge与Blob拼接在一起)，得到一个16字节的NTProofStr；

复制代码

NTLMv2 Hash = HMAC-MD5(unicode(hex((upper(UserName)+DomainName))),NTLM Hash)

NTProofStr = HMAC-MD5(challenge+blob,NTLMv2 Hash)

④将NTProofStr与Blob拼接起来形成得到response。

3.4、MIC

MIC是校验和，设计MIC主要是为了防止这个包中途被修改。

计算公式：

MIC = HMAC_MD5(exportedSessionKey,NEGOTIATE_MESSAGE+CHALLENGE_MESSAGE+AUTHENTICATE_MESSAGE)

关于exportedSessionKey，请看下面

3.5、签名

keyExchangeKey是使用用户password和severChallenge经过一定运算得到

SessionKey是由keyExchangeKey和exportedSessionKey经过一定运算得到

SessionKey是在要求进行签名的时候用的，用来进行协商加密密钥。

首先，客户端会生成一个随机数exportedSessionKey，后续都是使用这个exportedSessionKey来加解密流量。由于exportedSessionKey是客户端生成的，服务端并不知道，那么是通过什么手段进行协商的呢？

客户端使用keyExchangeKey做为Key,RC4加密算法加密exportedSessionKey，得到我们流量中看到的SessionKey。服务端拿到流量后，使用用户密码和质询值Challenge经过运算生成keyExchangeKey，然后使用SessionKey跟keyExchangeKey一起运算(解密)得到exportedSessionKey，然后使用exportedSessionKey进行加解密流量。对于攻击者来说，由于没有用户的密码，无法生成keyExchangeKey。因此，攻击者即使在拿到流量后，也无法计算出exportedSessionKey，自然也就无法解密流量了。