域渗透学习笔记四:域认证机制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协议

一个热爱域渗透/WAF绕过/免杀/代码审计/工具开发的憨批