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。
ntlm是怎么得到的呢，首先将我们的用户名密码进行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、时间戳，对比两次解密的结果，对比成功则授权访问
可以看到无论是客户端还是服务端在这个过程中都没有拥有过对方的用户名与密码，所以可以确保自己的身份信息的安全，但同时因为所有的认证都是在KDC完成，一旦krgtgt的ntlm hash泄露，那么真个系统也就变的不安全了，存在网络雪崩式瓦解的风险。
由于krbtgt只存在于域控中KDC中，TGT要用krbtgt的NTLM HASH解密，即TGT只能由KDC解密
所以如果krbtgt的NTLM HASH泄露出去了，那谁拿到krbtgt的NTLM HASH，谁就充当KDC，就可以伪造TGT，也就是权限维持里常说的黄金票据。。。。。。的原理。黄金票据就是域控的krbtgt用户的ntlm hash。因为掌握了krbtgt的ntlm hash之后，就可以冒充AS服务器与TGS服务器对所有的用户访问所有的服务进行授权，几乎整个局域网都沦陷了，危害极其巨大，所以被称为黄金票据。
另一方面ticket是服务账号用NTLM HASH加密得到的，如果这个服务账号的NTLM HASH泄露了，谁拿到域控中计算机服务账号的NTLM HASH，谁就充当TGS，这就是权限维持中白银票据的原理。白白银票据就是被请求服务的账户的ntlm hash。因为只是单台服务器的ntlm hash泄露，攻击者只能攻击这一台服务器，危害比较有限，故称作白银票据。