标签：TGS 06 TGT 03 Server KDC Client 2021 认证
第四天：域渗透-横向移动(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，即可伪造黄金票据）。
2.2：第二步：Client与TGS交互
标签：TGS,06,TGT,03,Server,KDC,Client,2021,认证 来源： https://blog.csdn.net/m0_47599604/article/details/117511416
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。