Windows口令的认证机制 |
|
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对魔术字符串"KGS!@#$%"进行标准DES加密 "KGS!@#$%" -> 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 求口令值只要获取这两者之一即可通过穷尽大法搞定了。
帖子热度 2万 ℃
soarcloud在路边丢垃圾被发现，被罚款1 个 金币.
|
|
|
「龙战于野」
2016-7-4 16:54
变色卡
|
至于是否用Windows，这个就不是你说的高手就不用了。Windows的服务器版本也不少，一些公司，企业，甚至政府机关部门用的都是Windows呢。当然这个是我们国家而言，但是国外也不是就都是Linux和Mac的天下。用Windows和高不高手没有必然联系。
|
|
我就喜欢这种刚发的帖子，如果火了就是个前排 ，还可以混个脸熟；就算这帖子没人回复了，沉贴了。也感觉是我弄沉的 ，特有 成就感！还不耽搁咱捞经验
|
古黑论管理员，在论坛上有什么问题都可以找他。