域渗透学习笔记四：域认证机制Kerbroes刨析

基础知识

Active Directory 活动目录，可以将其理解就是域服务。

负责域内机器管理，用户管理，资源管理，桌面配置，应用支撑等等。

Kerbroes的特点：

  • 不依赖于主机认证。
  • 不怕中间人攻击。
  • 使用密钥系统提供认证服务。

参与的角色

  • Client

  • Server

  • KDC（Key Distribution Center 密钥分发中心）

    (小结：性质类似于Web中的session)

细分KDC中的角色：

  • AD: account database的缩写，其储存了Client白名单，只有在白名单内的Client才能申请TGT
  • AS：Authentication Service的缩写，验证Client端的身份并为Client生成TGT的服务器
  • TGS：Ticket Cranting Service的缩写，为Client生成指定服务ticket。

物理层面AD和KDC都是域控

Kerbroes认证分析

从KDC的参与角色中可以了解到认证分为三块六小步，即一发一收的三个来回。

  • 1.Client请求Kerberos服务(请求中包含了Client Name 也就是用户名)，如果主机名存在于ad中，就放回TGT给Client
  • 2.Client拿着TGT去向Kerbroes发起请求说需要指定服务的权限，AS返回Ticket给Client。
  • 3.Client拿着Ticket去请求登录服务，服务那边又会去问Kerbroes这个ticket是否是真实的，是就给通过，认证完成。

引用一张其他师傅画好的比喻图

个人的理解是这样

将Kerbroes比作购票APP。认证流程比作买票。

  • 1.首先你使用身份证(Client name)去购票APP进行注册，购票APP需要核实你是我国公民。不是就直接拒绝(Client Name没再AD白名单中)，没有后续，是公民，但是上了征信黑名单也拒绝。(Client在AD中，但是是在黑名单中)，正常通过后就发放一个账号给你（TGT）
    1. 使用账号(TGT)发起买去xxxx的票的请求，买完APP返回了一张去xxxx的票给你(访问指定server的TGS)
  • 拿到票后去车站坐车，乘务员会对你的票进行检验，查看是否为真实的票据。

抓包分析

以下为域用户登录认证包

TGT获取

  • AS-REQ：

Client向KDC发起AS_REQ,请求凭据是Client hash加密的时间戳

AS-REP

KDC使用Client hash进行解密，如果结果正确就返回用krbtgt hash加密的TGT票据

TGS获取

TGS-REQ

请求访问指定服务

TGT-REP

返回Ticket。(这里没分析清楚)

TGS登录服务

涉及字段比较多，每个字段得含义分析不清楚，查阅资料可以看到详细流程如下：

AS_REQ: Client向KDC发起AS_REQ,请求凭据是Client hash加密的时间戳
AS_REP: KDC使用Client hash进行解密，如果结果正确就返回用krbtgt hash加密的TGT票据，TGT里面包含PAC,PAC包含Client的sid，Client所在的组。
TGS_REQ: Client凭借TGT票据向KDC发起针对特定服务的TGS_REQ请求
TGS_REP: KDC使用krbtgt hash进行解密，如果结果正确，就返回用服务hash 加密的TGS票据(这一步不管用户有没有访问服务的权限，只要TGT正确，就返回TGS票据)
AP_REQ: Client拿着TGS票据去请求服务
AP_REP: 服务使用自己的hash解密TGS票据。如果解密正确，就拿着PAC去KDC那边问Client有没有访问权限，域控解密PAC。获取Client的sid，以及所在的组，再根据该服务的ACL，判断Client是否有访问服务的权限。

分析得贼仔细，太强了。

总结

分析完Kerbroes认证流程后不难理解为什么NTLM协议的质询阶段很多师傅都是分析错的了,没动手抓包分析国，光看理论把Kerbroes和NTLM认证混淆了。

参考资料

内网学习之Kerberos协议

也无风雨也无晴