第四天：域渗透-横向移动(PTT)
一：Kerberos域认证简述
Kerberos是一种认证机制。目的是通过密钥系统为客户端/服务器应用程序提供强大的可信任的第三方认证服务：保护服务器防止错误的用户使用，同时保护它的用户使用正确的服务器，即支持双向验证。kerberos最初由MIT麻省理工开发，微软从Windows 2000开始支持Kerberos认证机制，将kerberos作为域环境下的主要身份认证机制，理解kerberos认证协议是域渗透的基础。
1.1：Kerberos认证框架
- kerberos机制中主要包含三个角色：
Client、Server、KDC(Key Distribution Center)密钥分发中心。 - Client代表用户，用户有自己的密码，Server上运行的服务也有自己的密码，KDC是受信任的三方认证中心，它拥有用户和服务的密码信息。
- KDC服务默认会安装在域控中，Client想要访问Server的服务（xxx service），前提是通过KDC认证，再由KDC发放的票据决定Client是否有权限访问Server的服务。
- KDC 服务框架中包含一个 KRBTGT 账户，它是在创建域时系统自动创建的一个账号，你可以暂时理解为他就是一个无法登陆的账号，在发放票据时会使用到它的密码 HASH 值。
1.2：名词解析
- KDC(Key Distribution center)：密钥分发中心，在域环境中，KDC服务默认会安装在域控中。
- AS(Authentication Service)：认证服务，验证client的credential(身份认证信息)，发放TGT。
- TGT(Ticket Granting ticket)：票据授权票据，由KDC的AS发放，客户端获取到该票据后，以后申请其他应用的服务票据(ST)时，就不需要向KDC的AS提交身份认证信息(credential)，TGT具有一定的有效期。由 KBRTGT HASH 加密的 sessionkey-as 和 Timestamp 等信息。TGT=KBRTGT HASH（）
- TGS(Ticket Granting Service)：票据授权服务，验证TGT，发放ST。
- ST(Service Ticket)：服务票据，由KDC的TGS发放，是客户端应用程序访问Server某个服务的凭证，Server端验证通过则完成Client与Server端信任关系的建立。
- Session key:用来加密client和TGS之间传输的数据。
- Server session key:用来加密client和server之间传输的数据。
1.3：简单认证流程
首先Client想要访问Server的某个服务，就需要通过KDC的认证，获取到服务票据（ST），服务会验证服务票据（ST）来判断Client是否通过了KDC认证。为了避免Client每次访问Server的服务都要向KDC认证(输入密码)，KDC设计时分成了两个部分，一个是AS，另一个是TGS;AS接收Client的认证信息，认证通过后给Client发放一个可重复使用的票据TGT，后续Client使用这个TGT向TGS请求ST即可。
二：Kerberos认证流程
| The Authentication Service Exchange（认证服务器）--> |
Client 与 AS 的交互AS_REQ•AS_REP |
| Ticket-Granting Service (TGS) Exchange（票据授予服务器）--> |
Client 与 TGS 的交互 TGS_REQ•TGS_REP |
| The Client/Server Authentication Exchange（pc和要访问的服务）--> |
Client 与 Server 的交互 AP_REQ•AP_REP |
2.1：第一步：Client与AS交互
用户登录阶段，通常由用户(admin)输入[用户名][密码]信息，在客户端侧，用户输入的密码信息被一个单向 Hash 函数生成 Client 密钥，即 admin 的 NTLM Hash：
- Pre-authentication data:就是用client对应的master key加密了一个timestamp。
- Client info:client用户信息
- Server info:这里并不是Client真正要访问的Server的名称，实际上是KDC的Ticket Granting Service的Server Name。
AS_REQ（请求）：
KDC端收到该请求后，Authentication service用client info部分信息，在AD（account database）中查询该client name对应的master key，并对pre-authentication data数据进行解密，如果可以提取出一个合法的时间戳，那就说明该用户是合法的，验证通过，并回复KRB_AS_REP给client。
AS_REP（返回）：
AS 收到用户认证请求后，AS 根据请求中的 用户名 AA 信息，从数据库中查找用户名是否存在。如果 用户名 AA 存在，则从 KDC 中可以获取 用户 AA 的密码，使用单向函数为该密码生成一个 Client 密钥（即NTLM Hash）。AS 生成随机字符串 Client/TGS Session Key，使用 Client 密钥(用户 AA 的密码 NTLM Hash)对 Client/TGS Session Key 加密得到 sessionkey_as；
再使用 TGS 密钥(krbtgt 用户的 NTLM Hash)对 Client/TGS Session Key 、 Client Info 和 Timestamp 加密,得到 TGT（TGT票据）。
将 sessionkey_as 和 TGT 一起返回给 Client。
Client 收到 AS 的响应消息后，利用自身的 Client 密钥（AA 的 NTLM Hash）对sessionkey_as 解密，这样就获取到 Client/TGS Session Key。
在 KDC 中存储了域中所有用户的密码 hash，当 AS 接受到 Client 的请求后会根据 AD 中存储的密码来解密，解密成功并且验证信息。验证成功后返回给 Client 由 Client 密码 hash 加密的 sessionkey-as 和 TGT。
总体来说，KRB_AS_REP分为两部分：
- 用client master key对session key进行加密后的值。Session key是KDC随机生成的UUID，用于client和TGS服务之间的数据加密、认证。
- 用KDC master key值对
Client/TGS Session Key进行加密。这部分client解不了。由此处也可以看出，TGT包括三个部分，分别是session key、client name、end time。（当响应信息里面有KDC Hash，即可伪造黄金票据）。