Windows认证机制小结
本文仅作为学习记录，如有侵权，请联系删除！
Windows认证机制：
win认证机制主要有三个：本地主机认证，网络主机认证，域内主机认证
0x01 Windows本地认证：
简单来说，本地认证过程就是我们开机后，输入密码成功进入桌面的过程。
这个过程中回涉及到几个进程：
- winlogon.exe：负责加载用户身份安全组件，提供图形化登录界面，创建用户会话
- lsass.exe：本地安全认证子系统服务，负责用户本地认证验证或远程登录验证用户身份
- %systemRoot%\system32\config\sam：通过NTLM Hash算法，储存用户密码的文件
大概过程：
1、开机后，系统会先调用Windows Logon Process（winlogon.exe）程序，它会提供一个登录交互页面，也就是输入用户名和密码界面
2、我们输入的密码后，程序将明文密码传递给lsass程序，lsass将密码加密获得NTLM-Hash值，然后lsass会去读取SAM文件已存的NTLM-Hash进行比较
3、发现相同则认证成功，立马将user SID与Group SID发送给winlogon程序，然后生成会话进入桌面
0x02 Windows网络认证：
网络认证是工作组之间主机互相访问，正常是通过SMB服务的445端口。在工作组之间主要使用NTLM-Hash验证机制进行验证，目前更新为NTLM V2和域kerberos验证体系。
大概过程：
1.客户端拿着用户名向服务器发起请求
2.服务器拿着用户名与自己的用户信息对比，确定是否为自己的合法用户
3.服务器立马生成一个16位随机字符（challenge）发给客户端，并且服务器查本地该用户的NTLM Hash，使用查到的NTLM Hash来加密Challenge，生成Net NTLM Hash
4.客户端也拿到了Challenge，用自己输入的密码生成NTLM Hash(注意这个和服务器那个逻辑上不是一个)，然后加密Challenge，生成Response发送给服务器。
5.服务器拿到了Response，与服务器生成的Net NTLM Hash进行对比，相同则通过认证
0x03 Kerberos协议：
Kerberos协议是一种基于第三方可信主机的网络认证协议，它允许两个实体之间在非安全网络环境下以一种安全的方式证明自己的身份。
A用秘密做秘钥加密文字生成密文，把密文和文字一块发送给B，B再用秘密解密得到明文，把明文和文字进行对比。若一致，则证明是A。
但是网络中，密文和文字很有可能被窃取。只要时间足够，总能破解秘钥。所以不能使用这种长期有效的秘钥。而是改用短期的临时秘钥。这个临时秘钥需要一个第三方可信任的机构来提供（KDC）
相关名词说明：
- KDC（Key Distribution Center）：密钥分发中心，默认安装在域控
- AD（Account Database）：活动目录，用于存储用户、用户组、域相关的信息，只有在白名单中的客户端才可以申请TGT
- AS（Authetication Service）：为客户端生成TGT的服务，用于KDC对Client认证
- TGT（Ticket-Granting Ticket）:发放的票据，黄金票据，AS服务发放，存储在内存，默认有效期为10小时
- TGS（Ticket Granting Service）：票据授予服务，为客户端生成某个服务的ticket/用于KDC向Client和Server分发Session Key。
- ST：ST服务票据，白银票据，由TGS服务发送
大概过程：
1.Client向KDC发起请求，KDC让AS拿着请求的用户名去问AD有没有这个人
2.AD认证通过，就会让AS服务向客户端发送一个TGT票据，TGT上有客户端信息
3.当Client想访问域内某台服务器，要拿着TGT和Client信息去请求KDC，KDC让TGS服务受理我们的请求，判断TGT的信息与Client信息是否一致，判断Client是否有访问权限
4.信息一致，则返回一个Ticket票据（ST），只能访问指定服务器，上面也有客户端信息
5.Client拿着Ticket和客户端信息，就可以访问指定服务器了
小结：
Client要访问Server，先去AS认证自己的身份。认证通过后AS返回给Client一个TGT。Client再拿着TGT在TGS中判断是否有访问Server的权限。如果有权限，TGT交换成Ticket，给Client用于和Server通信。
具体过程：
第一步：客户端认证
客户端首先向KDC的AS服务发起请求，请求内容有客户端hash加密的时间戳、客户端信息、服务器信息等内容。
AS去AD查客户端用户ID是否存在，若存在则会返回给Client两条信息，即KRB_AS_REP：
- 查找域控中储存的客户端hash，并随机生成一个session key，使用Client NTLM-hash 加密Session-key 作为一部分为内容。
- TGT（黄金票据）：使用KDC一个特定账户的NTLM-hash对Session-key、timestamp、Client-info进行的加密。这个特定账户就是krbtgt(创建域控时自动生成)
第二步：服务授权
Client收到回复KRB_AS_REP，会使用自己的NTLM-Hash，将被加密过的临时秘钥Session-Key进行解密，得到没有被加密的Session-Key，然后将其保存在本地，如果有需要访问某个服务时就可以构成TGS_REQ提交给TGS，来得到对应的ST。
在这个过程中发送的TGS_REQ中包含了使用Session-Key(AS生成的)加密的时间戳以及Client-info、Server-info 等数据，以及一些其他信息，以及使用krbtgt用户NTLM-Hash加密的TGT（TGT是用krbtgt 账户的NTLM加密的，Client无法解密）
TGS收到该请求，先去AD查找客户端发来的服务ID是否存在，存在的话用krbtgt NTLM-hash解密TGT得到Session-key 、timestamp、Client-info、Server-info。再用Session-key 解密第一部分内容，得到Client-info、timestamp。
将两部分获取到时间戳timestamp进行比较，如果时间戳和解密时间相差太久则终止验证。
TGS还会将这个Client的信息与TGT中的Client信息进行比较，如果两个相等的话，还会继续判断Client有没有权限访问Server，如果有，查找域控中储存的服务器hash、并随机生成一个server session key。
TGS返回的KRB_TGS_REP，由两部分组成：
- 用session key加密的server session key
- Ticket（ST：白银票据）：用Server NTLM-hash加密server session key、客户端信息、客户端地址、截止日期
至此，Client和KDC的通信就结束了，然后是和Server进行通信。
第三步：服务请求
Client收到KRB_TGS_REP，获得了加密的server session key以及ST。先使用刚才储存在本地的Session-key(AS生成的)对server session key(TGS生成的)进行解密，得到未加密的server session key(TGS生成的)，然后继续将其和ST一起储存在本地。
当Client需要访问Server时，Client则会发送KRB_AP_REQ。
KRB_AP_REQ包含了使用server session key(TGS生成的)加密时间戳、Client-info、Server-info等数据，以及一些其他信息，ST因为使用的是Server NTLM-hash 进行的加密，无法解密，然后再原封不动地把ST一同发送给Server。
Server 收到请求，用自身的Server NTLM解密了ST，得到server session key和客户端信息，这里也会判断截止时间是否还有效，然后使用解密出的server session key解密另一条消息，得到Client-info、timestamp。然后与ST的Client-info、timestamp进行对比。timestamp 一般时间为8小时。验证通过后，回复KRB_AP_REP，建立通信。
-
小结：
-
黄金票据：
当黑客可以获得Krbtgt用户的NTLM-Hash就代表着黑客黑客就可以伪造TGT
- 白银票据：
白银票据不同于黄金票据，白银票据的利用过程是伪造TGS，通过已知的授权服务密码生成一张可以访问该服务的 TGT。因为在票据生成过程中不需要使用 KDC，所以可以绕过域控制器，很少留下日志。而黄金票据在利用过程中由 KDC 颁发 TGT，并且在生成伪造的 TGT 得 20 分钟内，TGS不会对该 TGT 的真伪进行效验。
白银票据依赖于服务账号的密码散列值，这不同于黄金票据利用需要使用 Krbtgt 账号的密码哈希值，因此更加隐蔽。
