工作组与域环境下NTLM协议数据包分析

置顶虚构之人

已于 2023-01-25 19:55:34 修改

阅读量1.6k

点赞数 2

分类专栏：渗透域安全文章标签：网络 windows 信息安全网络安全安全

于 2023-01-25 19:40:13 首次发布

本文链接：https://blog.csdn.net/qq_18811919/article/details/128762133

版权

域安全同时被 2 个专栏收录

30 篇文章

订阅专栏

渗透

27 篇文章

订阅专栏

NTLM协议由来

早起SMB协议以明文口令形式在网络上传输,存在安全问题为了解决这个问题出现了LM协议，
因为LM协议过于简单很容易被破解,于是微软又提出了NTLM协议,以及更新的NTLM第2版。
发展过程:
    SMB ->  LM  ->  NTLM   -> NTLM v2
NTLM的作用:
    用于工作组中机器身份验证,又可用于域环境身份验证,还可为SMB、HTTP、LDAP、SMTP等上层微软应用提供身份验证。

NTLM基本概念SSPI/SSP

    SSPI是安全服务接口是Windows定义的一套接口,该接口定义了与安全有关的功能函数,包括但不限于:
        1.身份验证机制
        2.为其他协议提供会话安全可为通信提供完整性校验以及数据的加密、解密的功能。
    SSPI只是定义了一套接口函数,具体实现有SSP完成。

    SSP是SSPI的实现者,微软自己也实现了很多SSP用于提供安全功能。    
    典型的SSP实现:
        1.NTLM SSP:Windows NT 3.5中引入(msv1_0.dll)为Windows 2000之前的客户端提供服务器域和非域身份验证（SMB/CIFS)
            提供NTLM质询/响应身份验证。
        2.Kerberos SSP:Windows 2000 中引入为Windows 2000以及更高的版本中首选客户端-服务器域提供相互身份验证。    

    SSPI中定义了会话安全的API,所以上层应用利用任何SSP与远程的服务进行身份验证后,SSP都会为本次的连接生成一个随机key,这个随机key
    被称为session key,上层的应用经过身份验证后,可以选择性使用这个session key,往服务端或者接收服务端的数据进行签名或加密,SSP就是一个dll
    ,用来实现身份验证等安全功能,不同的SSP实现身份验证的方式是不一样的,比如NTLM SSP实现的是一种基于质询/响应的身份验证机制,Kerberos SSP实现
    的是基于Tick票据的身份验证机制。

LM Hash加密算法

LM身份验证使用的加密算法是LM Hash,LM Hash本质上是DES加密,尽管LM Hash比较容易破解但是微软为了兼容性只是将LM Hash禁用,
LM Hash明文被限制在14位以内,也就是说若要停止使用LM Hash,将用户密码设置为14位以上即可。
如果LM Hash的值为aad3b435b51404eeaad3b435b51404ee说明LM Hash为空或者被禁用。

NTLM Hash加密算法

为了解决LM Hash加密和身份验证方案中安全问题,微软于1993年在WindowsNT3.1中引入了NTLM Hash,从Windows Vista和Windows Server 2008开始,
默认禁用了LM Hash,只存储NTLM Hash。
加密流程:
    1.将用户密码转换为十六进制格式
    2.将ASCII编码的十六进制格式的字符串转为Unicode编码
    3.对Unicode编码的十六进制字符串进行标准MD4单向Hash加密
Python命令进行NTLM加密 
    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过程
    1.NTLM Hash存储在C:\Windows\system32\config\SAM文件中
    2.winlogon.exe显示登录界面也就是输入框,接收密码后将密码交给lsass.exe进程,lsass.exe进程中会存储一份明文密码,
        将明文密码加密成NTLM Hash与SAM数据库进行比较和认证。
    mimikatz利用:
        使用mimikatz抓取lsass.exe进程中的明文密码或者Hash密码,需要注意的是
        抓取的LM Hash值aad3b435b51404eeaad3b435b51404ee说明禁用了LM Hash。

NTLM协议认证过程

NTLM协议是一种基于Challenge/Response(质询/响应)的验证机制,由三种类型消息组成:
    Type1(协商,Negotiate)
    Type2(质询,Challenge)
    Type3(认证,Authentication)
NTLM v1和NTLM v2的不同:
    NTLM协议有NTLM v1版本和NTLM v2两个版本,目前使用最多的是NTLM v2版本,
    两个版本最大的不同是Challenge质询值不同,共同之处是都使用了NTLM Hash进行验证。

工作组认证截图

工作组认证成功截图:

在这里插入图片描述

上述截图是SMB认证的工作组环境下NTLM认证过程,查看每个数据包都可以发现GSS-API内容。

在这里插入图片描述

GSS-API:
GSS-API叫做通用安全服务应用接口是一种统一的模式,为使用者提供与机制无关、平台无关、程序语言环境无关且可以移植的安全服务。
SSPI与GSS-API的关系:	
SSPI是GSS-API的一种专有变体,进行了拓展并具有需要特定与Windows的数据类型,相当于实现了GSS-API,SSPI生成的令牌绝大多数可以与GSS-API兼容。
NTLM SSP与GSS-API的关系:
NTLM SSP实现了SSPI,SSPI是GSS-API的一种专有变体,因此相当于实现了GSS-API。
SSP实现的好处:
SSP实现了与安全功能有关的功能函数,因此上层协议比如SMB、HTTP、LDAP,在使	用身份验证等功能时候,可以不需要考虑协议细节,只需要调用相关的函数即可,认	证过程中的流量嵌入在上层协议中,不像Kerberos,既可以嵌入在上层协议中,也可以	作为独立的应用层协议。
工作组认证失败截图:

在这里插入图片描述

认证数据包分析

 1.协商:NTLM认证的前4个包

在这里插入图片描述

 前4个包是SMB协议协商的一些信息,查看Securiy mode（安全模式）,可以看到Security mode下的Signing enabled为True,而Signing required为False,表明当前客户端虽然支持签名,但是协商不签名,工作组环境下均不签名。
 2.Negotiate包分析
 Negotiate是NTLM认证中第五个包,即使Type1流程,是从客户端发送到服务器以启动	NTLM身份认证的包,他的主要目的是通过flag标识支持的选项来验证基本规则。
Type1 Negotiate包核心内容截图:

在这里插入图片描述

其中Negotiate Flages字段需要协商的flag（用于支持选项来验证基本规则）截图:

在这里插入图片描述

 3.Challenge包分析:
前4个数据包是协商数据包第5个是Negotiate包即Type1认证过程,Challenge是Type2认证过程,Challenge包是服务端发送给客户端的,包含服务端支持和同一的功能列表,下面截图是Type2包的主要消息结构体:

在这里插入图片描述

	Type2消息中包含Challenge值,在NTLM V2版本中,Challenge值是一个随机的16B的字符串,如下截图Challenge值为e691b26a1347e4da。

在这里插入图片描述

4.Authenticate包分析:

在这里插入图片描述

第7个包是Type3 Authentication消息,是客户端发给服务端的认证消息,此消息包含客户端对Type2质询消息的响应,表明客户端知道账号和密码,Authentication消息还指示身份	验证账号的身份验证目标(域和服务器名)和用户名,以及客户端工作站名。

Authentication消息的核心主要是Response消息,Response消息是用服务器密码的NTLM Hash加密Challenge值后经过一系列运算得到的,Response消息中可以提取出Net-NTLM Hash。

在Response消息中,有6种类型的响应他们使用的加密流程一样,都是Challenge/Response验证机制,不同之处在于Challenge值和加密算法不同,选择那个版本的响应由LmCompatibility-Level决定。

六种响应版本:LM响应、NTLM v1响应、NTLM v2响应、NTLM v2会话响应、匿名响应。
可以在NTLM v2响应类型,且可以看到在NTLM v2 Response消息下的NTProofStr字段,
该字段的值时用做数据签名的Hash(HMAC-MD5)值,目的是保证数据完整性。

在这里插入图片描述

防止数据包中途被篡改,使用exportedSessionKey加密3个NTLM消息来保证数据包的完	整性,而由于exportedSessionKey进队启动认证的账户和目标服务器已知,因此有了MIC,就无法中途篡改NTLM认证数据包了。

在这里插入图片描述

在第七个包中的Session Key字段是用来进行协商加密秘钥的,客户端和服务端通过Session Key协商密钥的过程如下:
1.客户端会随机生成一个exportedSessionKey,后续使用来加解密流量,因为是客户生	成的因此服务端并不知道。
2.客户端使用keyExchangeKey作为Key,用RC4加密算法加密exportedSessionKey,得到上述流量中看到的Session Key,服务端拿到流量后使用用户密码和Challenge值经过运算生成keyExchangeKey,然后使用Session Key和KeyExchangeKey一起计算得到exportedSessionKey,最后使用exportedSessionKey加解密流量,对于攻击者来说没有			用户的密码,因此无法生成keyExchangeKey,所以攻击者即使拿到流量也无法计算出exportedSessionKey自然无法解密流量。
第8个数据包是返回结果是否成功或失败
成功数据包:

在这里插入图片描述

失败数据包:

在这里插入图片描述

Net-NTLM v2 Hash计算

NTLMV2和Response消息生成步骤如下:
1.将大写的User name与Domain name区分大小写拼接在一起进行十六进制转换,
然后双字节Unicode编码得到data,接着使用16B NTLM哈希值作为密钥key,
用data	和key进行HMAC-MD5加密得到NTLM v2 Hash。
2.构建一个blob信息。
3.使用16字节NTLM v2 Hash作为密钥,将HMAC-MD5消息认证代码算法加密一个值
(来自Type2的Challenge与blob拼接在一起),得到一个16BNTProofStr(HMAC-MD5).
4.将NTProofStr与blob拼接起来得到Response,使用Responder工具抓取
NTLM Response消息的时候抓取的都是Net-NTLM Hash格式的数据。
Net-NTLM v2 Hash格式如下:
username:domain:challenge:HMAC-MD5:blob
含义:
username						要访问服务器的用户名
domain							域信息
challenge						数据包6中的服务器返回的challenge值
HMAC-MD5						数据包7中的NTProofStr
blob							对应数据包7中NTLM v2 Response去掉NTProofStr的后半部分
NTLM v2 Hash和NTProofStr的计算公式如下:
NTLMv2Hash= 					HMAC-MD5(unicode(hex(upper(UserName)+DomainName))),NTLM Hash)
NTProofStr=HMAC-MD5(challenge+blob,NTLM v2 Hash)

域环境下的NTLM认证数据包分析

实验环境如下图:

在这里插入图片描述

认证成功截图:

在这里插入图片描述

认证失败截图:

在这里插入图片描述

NTLM域认证简述

1.客户端发送Type1 NTLMSSP_NEGOTATE消息,包含服务用户和其他需要协商的信息。
2.服务端发送Type2 NTLMSSP_CHALLENGE消息,其中包含16位的随机Challenge值。
3.客户端发送Type3 NTLMSSP_AUTH消息,其中包括Response消息。
4.服务端通过Netlogon协议将验证消息发送给域控
5.域控根据自身计算出的Net-NTLM Hash与服务端发过来的Net-NTLM Hash做比较,然后根据结果返回成功与否。

NTLM v1和NTLM v2的区别

NTLM v1和NTLM v2是NTLM身份认证协议的不同版本,目前使用最多的是NTLM v2版本,
NTLM v1和NTLM v2最显著的区别是Challenge值与加密算法不同,共同之处是都使用了
NTLM Hash进行加密。
区别:
1.Challenge值
1)NTLM v1:8B
2)NTLM v2:16B
2.Net-NTLM Hash使用的加密算法不同
1)NTLM v1:DES加密算法
2)NTLM v2:HMAC-MD5加密算法
NTLM v1 Response消息生成过程:
1.将16B的NTLM Hash填充为21B
2.分成三组密码对服务端发来的Challenge值进行DES解密
3.分别利用三组密码对服务端发来的Challenge值进行DES加密
4.这三个密文值连接起来得到Response
Net-NTLM v1格式如下:
username:hostname:LM response:NTLM response:challenge

LmCompatibilityLevel验证协议:

此选项会影响客户端使用的身份验证协议的等级、协商的会话安全的等级以及服务器接	受的身份验证等级,LmCompatibilityLevel总共分为6个等级。
0:	
客户端使用LM和NTLM身份验证,但从不使用NTLM v2会话安全性,域控制器接受	
LM、NTLM、NTLM v2身份验证。
1:
客户端使用LM和NTLM身份验证,如果服务器支持NTLM v2会话安全性,则使用	
NTLM v2会话安全性,域控制器接受LM、NTLM、和NTLM v2身份验证。
2:
客户端仅使用NTLM身份验证,如何服务端支持NTLM v2会话安全性,则使用
NTLM 	v2会话安全性,域控制器接受LM、NTLM、和NTLM v2身份验证。
3:
客户端仅使用NTLM v2身份验证,如果服务器支持NTLM v2会话安全,则使用
NTLM 	v2会话安全性,域控制器接受LM、NTLM和NTLM v2身份验证。
4：
客户端仅使用NTLM v2身份验证,如果服务器支持NTLM v2会话安全性,则使用	
NTLM v2会话安全性,域控制器拒绝LM身份验证,但接受NTLM和NTLM v2身份验	证。
5:
客户端仅使用NTLM v2会话验证、如果服务器支持NTLM v2会话安全性,则使用	
NTLM v2会话安全性,域控制器拒接LM和NTLM身份验证,但接受NTLM v2身份验	证。	
设置LmCompatibilityLevel:
1.本地安全策略->安全设置->本地策略->安全选项->网络安全:LAN管理者身份验证级别,默认值没有定义。
2.修改HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Imcompatibilitylevel字段修改响应的类型。
3.通过命令行修改为2 :reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa\ /v imcompatibilitylevel /t REG_DOWD /d 2 /f

问答小环节

问答:
问题1:NTLM域认证和工作组NTLM认证有什么区别
答:
协商、质询、过程是类似的都是与服务端进行通讯,区别在于认证响应,
NTLM域认证响应是服务端接收客户端的NTLMSSP_AUTH认证消息之
后通过Netlogon协议与域控建立安全通讯将消息发送给域控,域控验证
其中的Net-NTLM Hash,是否与域控计算的相等以此判断客户端密码是
否正确,工作组NTLM认证响应这一过程是在服务端完成的。
问题2:NTLM Hash、Net-NTLM Hash、Challenge之间的关系是什么
答:
明文密码通过加密计算的到NTLM Hash,Challenge位于质询过程中生成,
NTLM Hash与Challenge加密计算得到Net-NTLM Hash。
问题3:明文密码是怎么样变成NTLM Hash的
答:
首先将用户密码转换为十六进制格式,将ASCII编码的十六进制格式的字符串	
转为Unicode编码,对Unicode编码的十六进制字符串进行标准MD4单向Hash加密得到NTLM Hash。
问题4:如何区别NTLM v1协议和NTLM v2协议
可以通过Challenge值和Net-NTLM Hash加密算法区别,
NTLM v1 Challenge值时8B,NTLM v2 Challenge值时16B,
v1使用DES加密v2使用HMAC-MD5算法加密。