@H_
801_18@Windows中有几种不同类型的哈希值,它们可能非常混乱。 可以
在这两篇@L_
674_1@《LM,NTLM,Net-NTLMv2,oh my!》和《LM Hash and NT Hash 》找到一些解释,但首先阅读下面这段
内容:
@H_
801_18@如果Windows的hash没有加盐,那么两组hash将可能产出相同的明文。Windows哈希分为两组--LMhash和NTLMhash。 比如: te
stuser:29418:aad3b435b51
404eeaad3b435b51
404ee:58a478135a93ac3bf
058a5ea0e8fdb71
@H_
801_18@
内容的构成:
username : unique_identifier : LMhash : NThash
@H_
801_18@LM - LM哈希用于存储密码。 但要注意在W7及以上版本中LM是禁用的。 但是,当密码少于15个字符的时候,就在内存中启用LM。 这也是为什么
管理员帐户的所有建议都是15个字符的原因。 LM已经过时了,它基于MD4,很容易破解。 它之所以依旧采用MD4,
是因为Windows域需要较快的解密速度,但这也使得它的安全性变得很差。
NT - NT哈希根据
用户输入的整个密码计算哈希值。 LM哈希将密码拆分为两个7个字符的块,如果有缺省则进行填充。
NTLM - NTLM哈希用于域中主机上的本地身份验证。 如上所示,它是由LM和NT哈希组合而成。
NetNTLMv1/2 - 有时候在网络进行身份验证的时候(比如SMB),有时候也会提到NTLMv2,但是请不要把它和NTLM hash搞混了,他俩是不同的概念。
在Windows中,哈希存储在内存中以用于单点
登录。 每次
用户点击网络共享时,信用凭证都会通过网络传递。 我们可以利
用这个特性在传输过程中或在计算机上
获取这些凭据。 另一种
方法是始终向
用户询问凭据,这在Windows环境中很少发生。
@H_
801_18@在对Windows机器进行身份验证时,NTLM哈希与明文凭证
效果是一样的。因此如果你无法
获取明文凭据的时候,并不要认为这是什么大问题。 其实,我的意思就是可以通过哈希传递来通过身份验证,而不需要明文密码本身。
@H_
801_18@破解哈希可以很有趣,而且由于大多数
用户密码都很糟糕/不复杂,因此很容易秒破。 想象一下,如果域名的密码重置策略为90天。
但是你在两小时内就破解了
用户的凭据,那这对他们来说是
一个很大的失误。 如果你可以在两小时甚至几天内破解域
管理员的凭证,那么它们也就离玩儿完不远了。 当然,我们可以利用中继来重用凭证,而不需破解哈希。
@H_
801_18@Windows中的身份验证
在Windows系统中有许多验证身份的
方法。
@H_
801_18@密码 - 也就是密码本身了
Hashes - Windows可以使用哈希进行身份验证。 因此我们可以使用重传hash等攻击来进行身份验证,完全不需要帐户密码。
Tokens - 令牌属于身份验证的概念。 当
用户或服务
登录系统时,系统会验证一次其身份,并
生成一个令牌,将该令牌将传递给该
用户/服务并作
为其身份。 例如,每当程序打开
文件时,系统就不需要验证身份。 这基本上确保了身份验证(证明
用户/服务是他们所说的人)和授权(确定
用户/服务是否可以访问某些资源)之
间的清晰分离。
Tickets - 通常指Kerberos票据,详见下文。
Kerberos
Kerberos是Windows中基于_tickets_的身份验证协议,允许通过非安全网络进行通信的计算机以安全的方式相互提供其身份。 Kerberos建立在对称密钥加密之上,需要受信任的第三方参与,并且可选则在身份验证的某些阶段使用公钥加密。 Kerberos
默认使用UDP端口88。
@H_
801_18@多年来,已有多个Kerberos漏洞被发现:
@H_
801_18
@mS14-068
Windows
名称解析
Windows中有一些不同的
名称解析协议和
名称:
@H_
801_18@FQDN - 完全限定域名(Fully Qualified Domain
Name) WINS - Windows 网络
名称服务(Windows Internet Name
servic
E) NBT-NS - (NetBIOS Name
servic
E) - 通常称为 NetBIOS
LLMNR - 链路本地多播
名称解析(Link-Local Multicast Name Resolution)
WPAD - Web代理
自动发现协议(Web Proxy Auto-Discovery Protocol)
如果
名称是FQDN,这意味着
包括域名的全名,例如test.lab.local,它
查询hosts
文件,然后
查询DNS服务器以进行
名称解析。
@H_
801_18@如果
名称是非限定
名称,如\ fileshare,则尝试使用以下
名称解析来查找该
文件共享位置:
@H_
801_18@LLMNR - 使用多播来为相邻计算机的
名称执行
名称解析,而无需
DNS服务器。 NetBIOS -
查询WINS服务器以
获取解决方案(如果存在)。 如果没有,它使用广播来解析邻近计算机的
名称。 由于FQDN查找在
文件共享时并不常用,并且
默认情况下未启用,因此它会检查LLMNR,然后检查NetBIOS。 在企业界,
DNS服务器可用于查找资源,在家庭环境中它不太能行,因此如果您想在两台主机之间共享
内容,LLMNR和NetBIOS则成为不二之选。 但是,
用户通常不会在资源管理器的地址字段中键入share.hacklab.net,因此
名称解析将由LLMNR和NetBIOS来完成。