文章目录
Windows Hash
首先明确一点,Windows Hash
是不加盐的
windows hash
被截成两部分,LMhash
和NTLMhash
具体格式为:
username:RID:LMhash:NThash
RID是用户的唯一标识
windows
下LM hash
生成的原理:
比如我们现在有的明文:welcome
,首先windows
会把它转换为WELCOME
,之后将口令转换为二进制形式,长度为14个字节,不足补零,之后分为两组7
字节的数据块,然后经函数str_to_key
处理得到两组8
字节数据
然后这两组8
字节数据会作为DES
加密的KEY
对一个特定的字符串KGS!@#$%
进行加密,它的16
进制形式为4B47532140232425
,然后分别使用上面得到的两组8
字节数据对该数据进行DES
加密,将加密后的两组密文直接进行拼接,就得到了LM hash
Windows
下NTLM hash
的生成方法
现假设明文口令为123456
,首先进行Unicode
编码,而且不需要对编码结果进行填0
补足14
字节,之后对unicode
编码进行MD4
单向hash
,产生128
比特的哈希值,这个hash
值就会作为最后的NTLM hash
与LM hash
相比,NTLM hash
对大小写敏感,并摆脱了对魔术字符串的依赖
NTLM
是LM
和NT
的结合,用于本地用户身份认证
NetNTLMv1/2
网络上的身份认证(SMB)
这是windows
独有的一种认证协议:鉴权协议,又名挑战-认证协议 challenge and response protoco
l
在windows
中,这些hash
存储在内存中用于身份认证,我们可以在它们被传输时抓包获取,也可以直接在本机上获取
对于NTLM hash
,我们可以直接拿来进行认证,不需要破解出它所对应的明文
Windows中的身份认证
密码身份认证
通过某种手法,直接使用hash
进行身份认证
Token
认证,当用户登陆到某一系统时,系统对其身份进行验证,然后给其分配一个token
,这样就不必每次都进行身份认证了
This basically ensures a clean separation between authentication (proving a user/service is who they say they are) and authorization (determining whether a user/service can access some resource)
Tickets - usually refers to Kerberos tickets, see below
Kerberos
Kerberos
是windows
中的一种认证协议,它基于tickets
在不安全的网络环境中为主机间的通信提供一个安全的认证机制
Kerberos
基于对称密钥加密,并且要求有第三方的参与,而且在认证过程中的某些特定阶段可能还会使用到公钥
,Kerberos
默认使用UDP
的88
端口
相关RCE
:MS14-068
Windows 域名解析
以下是中的几种解析协议
- FQDN - Fully Qualified Domain Name 使用DNS服务器来进行域名解析
- WINS - Windows Internet Name Service
- NBT-NS - (NetBIOS Name Service) - commonly referred to as NetBIOS
- LLMNR - Link-Local Multicast Name Resolution
- WPAD - Web Proxy Auto-Discovery Protocol
If the name is an unqualified name like \\fileshare
, the following name resolutions are attempted to find the that fileshare:
- LLMNR - uses multicast to perform name resolution for the names of neighboring computers without requiring a DNS server.
- NetBIOS - queries a WINS-server for resolution if present. If not, it uses broadcast to resolve the name from neighboring computers.
小型局域网一般不使用FQDN(不使用DNS服务器),主要使用的协议是LLMNR、NetBIOS.
Because FQDN lookup is not common for fileshares and isn’t enabled by default it checks LLMNR and then NetBIOS. In the corporate world a DNS server is available to look up resources, in a home environment it’s less likely so if you want to share content between two hosts, LLMNR and NetBIOS is how it’s done. However, users don’t usually type in share.hacklab.net
in the address field in explorer, so the name resolution resorts to LLMNR and NetBIOS.