Windows口令的认证机制

soarcloud · 2016-7-4 16:54

Windows系统之间使用NTLM身份认证机制来达成身份验证的目的，那么假如我们获取了NTLM的值，又该如何获取口令呢，本帖就是围绕这一问题而展开的。
首先，让我们来看一个NTLM值到底是什么样的。
admin:7196:C23413A8A1E7665FAAD3B435B51404EE::32ED87BDB5FDC5E9CBA88547376818D4:::
其中第一段是用户名，第二段我也不是很清楚，感觉和用户ID号有关系，第三段为LM值，第四段为NT值
LM值和NT值都是又口令本身产生的，存在LM值得原因是为了兼容windows98之前的系统。
如何从明文口令生成LM Hash
假设明文口令是"Welcome"，首先全部转换成大写，再做如下变换
"WELCOME" -> 57454C434F4D4500000000000000
也就是说在明文口令不足14字节的情况下，后面添加0x00补足14字节。然后切割成两组7字节的数据，分别经str_to_key()函数处理得到两组8字节数据
57454C434F4D45 -str_to_key()-> 56A25288347A348A
00000000000000 -str_to_key()-> 0000000000000000
这两组8字节数据将做为DESKEY对魔术字符串"[email protected]#$%"进行标准DES加密
"[email protected]#$%" -> 4B47532140232425
用56A25288347A348A -对4B47532140232425进行标准DES加密-> C23413A8A1E7665F
用0000000000000000 -对4B47532140232425进行标准DES加密-> AAD3B435B51404EE
将加密后的这两组数据简单拼接，就得到了最后的LM Hash
LM Hash: C23413A8A1E7665FAAD3B435B51404EE

如何从明文口令生成NT Hash
假设明文口令是"123456"，首先转换成Unicode字符串，与LM Hash算法不同，这次不需要添加0x00补足14字节
"123456" -> 310032003300340035003600
从ASCII串转换成Unicode串时，使用little-endian序，微软在设计整个SMB协议时就没考虑过big-endian序，0x80之前的标准ASCII码转换成Unicode码，就是简单地从0x??变成0x00??。此类标准ASCII串按little-endian序转换成Unicode串，就是简单地在原有每个字节之后添加0x00。
对所获取的Unicode串进行标准MD4单向哈希，无论数据源有多少字节，MD4固定产生 128-bit的哈希值，16字节 310032003300340035003600 -进行标准MD4单向哈希-> 32ED87BDB5FDC5E9CBA88547376818D4
就得到了最后的NT Hash
NT Hash: 32ED87BDB5FDC5E9CBA88547376818D4
求口令值只要获取这两者之一即可通过穷尽大法搞定了。

[# 加密解密] Windows口令的认证机制

相关帖子

评分

评分

评分

管理员

赞助会员