windows认证机制
作者:互联网
windows认证机制
本文参考Windows认证及抓密码总结
当前windows的认证机制主要有两种,一种是ntlm认证,另一种是kerberos。还有一种成为ACCESS TOKEN也起到权限认证的作用,这个token主要是用来标识用户与程序之间的所属关系的。当用户登录后会生成一个access token,当前用户打开的每一个进程都拥有一份这个access token的拷贝,这也是为什么用户b不能处理用户a打开的进程的原因
一、NTLM认证
1.1 NTLM本地认证
当用户注销登录后,操作系统会盗用winlogon.exe程序,也就是我们看到的登录界面,当我们输入用户名密码之后,该进程会将我们的用户名密码交给lsass.exe进程,该进程会将我们的用户名密码进行hash变换得到ntlm hash,并存储一份明文密码,然后同windows的sam数据库进行对比,如果对比成功,则登录成功,否则登录失败。因为存在明文密码,所以我们可以在lsass进程中将该密文提取出来,常用的提取工具是mimikatz与msf。
ntml是怎么得到的呢,首先将我们的用户名密码进行16进制变化,然后进行unicode变换,通过md4摘要得到ntlm hash
123456 -> hex(16进制编码) = 313233343536
313233343536 -> Unicode = 610064006d0069006e00
610064006d0069006e00 -> MD4 = 209c6174da490caeb422f3fa5a7ae634
1.2 NTLM网络认证
NTLM的网络认证,设计到challenge/response机制,即协商、挑战、认证
协商: 主要确认双方的协议版本、加密等级
挑战: 服务器在收到客户端发送的协商请求后,得到里面的内容,然后确认使用的协议版本、加密等级,安全服务,并生成一个随机数返回给客户端,该随机数根据协议版本的不同,长度不同。
认证: 挑战完成后,进行认证
具体的实现过程如下:
- 首先,客户端在接受到用户输入的用户名密码之后,将其交给lsass.exe进程进行ntlm变换的到一个ntlm hash
- 然后,客户端将用户名明文发送给服务端,服务端使用该用户名生成一个16位的随机数,即challenge发还给客户端。
- 客户端收到该challege后,使用ntlm hash对该challege进行加密,然后发还给服务端,及response
- 服务端收到该response之后,会向DC发送认证请求,该请求包括用户名、原始challenge、经过ntlm has变换之后的challenge即响应。
- DC在收到该认证请求之后,会通过传过来的用户名从自己的数据库,及AD中获取该用户的ntlm hash值,然后对发送过来的原始challenge进行加密之后对比传过来的response,如果对比成功则人称通过,否则不通过。这一步的具体认证过程是我脑补的,不知道对不对,原文并没有说清楚
二、kerberos认证
这个东西有点复杂,不过找到了一篇很好的文章,终于理解了!!!Kerberos认证流程简述
2.1 kerberos解决了什么问题
简单地说,Kerberos提供了一种单点登录(SSO)的方法。考虑这样一个场景,在一个网络中有不同的服务器,比如,打印服务器、邮件服务器和文件服务器。这些服务器都有认证的需求。很自然的,不可能让每个服务器自己实现一套认证系统,而是提供一个中心认证服务器(AS-Authentication Server)供这些服务器使用。这样任何客户端就只需维护一个密码就能登录所有服务器。kerberos不仅验证客户端,也验证服务端!!
2.2 kerberos中涉及的角色
- KDC 密钥分发中心 包括as与tgs两部分 一般在域控中由DC担任
- AS 认证服务器,用于提供想tgs服务器获取ticket的入场券TGT
- TGS 票据授予服务器, 用于授予客户端ticket
- AD 账户数据库 存放在AS中,只有该数据库白名单中的用户才能申请TGT
- session key 用户与域控生成的加密密钥
- client 请求的发起方
- server 提供服务的一方
2.3 kerberos完整认证过程
先放图
这里面涉及到一个krbtgt账户,该账户时kdc的一个自建用户,不能用于登录,在域控中使用net user命令可以查看。
- 首先,客户端在接受到用户输入的用户名密码之后,将其交给lsass.exe进程进行ntlm变换的到一个ntlm hash
- 然后,客户端将用户名明文、时间戳发送给KDC,向KDC申请TGT
- KDC下给你AS服务器验证该用户,判断其是否在AD的白名单里面,如果在,AS服务器则会生成一个session key ,再从AD中查询到该用户的ntlm hash 使用该hash对该session key进行加密得到密文A;再用krbtgt的ntlm hash对session key、客户端用户信息、客户端时间戳、过期时间进行加密得到TGT;将该TGT与密文A一并发回给客户端
- 客户端收到信息后,使用自己的ntlm hash 对密文A进行解密得到session key。再用这个session key 将client info 与客户端时间戳进行加密得到密文B,再将密文B与TGT一起发送给TGS服务器
- TGS服务器收到消息后,使用krbtgt的ntlm hash对TGT进行解密得到session key、client info、时间戳,再用该session key 解密密文B 得到client info、时间戳,在对比两次解密的值,是否一致,时间戳需要在一定的误差范围内,windows是五分钟,如果一致,TGS服务器生成一个新的session key2,用它加密client info 时间戳得到密文ENC,再由server的ntlm hash 加密session key2、client info 、时间戳得到ticket,再将ticket与enc发还给客户端
- 客户端发送ticket与enc到服务端请求服务
- 服务端server 通过自己的ntlm hash 解密ticket 得到session key2、client info 、时间戳,然后通过session key2解密enc得到client info、时间戳,对比两次解密的结果,对比成功则授权访问
由于krbtgt只存在于域控中KDC中,TGT要用krbtgt的NTLM HASH解密,即TGT只能由KDC解密
所以如果krbtgt的NTLM HASH泄露出去了,那谁拿到krbtgt的NTLM HASH,谁就充当KDC,就可以伪造TGT,也就是权限维持里常说的黄金票据。。。。。。的原理,生成伪造黄金票据把票据一导入,体验一把生杀大权尽在手中的感觉。黄金票据就是域控的krbtgt用户的ntlm hash
另一方面ticket是服务账号用NTLM HASH加密得到的,如果这个服务账号的NTLM HASH泄露了,谁拿到域控中计算机服务账号的NTLM HASH,谁就充当TGS,这就是权限维持中白银票据的原理。白白银票据就是被请求服务的账户的ntlm hash。
标签:NTLM,hash,windows,ntlm,认证,服务器,机制,客户端 来源: https://blog.csdn.net/qq_32731075/article/details/118095664