Kerberos&Ticket
Er… 仅仅是一个笔记
# Kerberos
什么是域 —— 域是一组有边界的计算机的集合
在 Active Directory(AD)中,域是指一个管理范围或网络区域,它包含了用户、计算机、组等对象。通过域,管理员可以统一管理用户权限和资源访问。
Kerberos 是一种基于加密 Ticket 的身份认证协议。
# kerberos 认证
参与 Kerberos 认证的有三个角色
- DC 域控
-
- 在 KDC(DC 中的一个组件:密钥分发中心)中又分为两个部分:Authentication Service (AS, 身份验证服务) 和 Ticket Granting Service (TGS, 票据授权服务),分别负责负责验证用户身份和发放服务票据
- client 客户端
-
- Kerberos 客户端是代表需要访问资源的用户进行操作的应用程序,例如打开文件、查询数据库或打印文档。每个 Kerberos 客户端在访问资源之前都会请求身份验证。
- server
-
- 域内提供服务的服务端,服务端都有一个独一的 SPN。
# SPN
SPN(Service Principal Name)是用于标识某个服务实例的名称,它通过在一个网络中的用户或计算机账户与该服务的实例之间建立映射来实现。它通常以特定的格式存在,帮助 Kerberos 客户端识别和验证网络中的服务。
SPN 的基本格式如下: <服务类型>/<主机名>:<端口号>
例如:
HTTP/server.example.com:80
代表运行在server.example.com
上的 HTTP 服务,端口为 80。MSSQLSvc/sqlserver.example.com:1433
代表运行在sqlserver.example.com
上的 SQL Server 服务,端口为 1433。
管理员可以使用 setspn
命令来管理 SPN:
1 | setspn -A HTTP/server.example.com DOMAIN\user |
这条命令为 DOMAIN\user
账户添加了一个 HTTP 服务的 SPN
# kerberos 认证流程
Kerberos 是一种基于票据 Ticket 的认证方式。客户端想要访问服务端的某个服务,首先需要购买服务端认可的 ST 服务票据 (Service Ticket)。也就是说,客户端在访问服务之前需要先买好票,等待服务验票之后才能访问。但是这张票并不能直接购买,需要一张 TGT 认购权证(Ticket Granting Ticket)。也就是说,客户端在买票之前必须先获得一张 TGT 认购权证。TGT 认购权证 和 ST 服务票据 均是由 KDC (密钥分发中心) 发放;因为 KDC 是运行在域控制器上,所以说 TGT 认购权证和 ST 服务票据均是由域控发放。
Kerberos 协议其中有两个基础认证模块:AS_REQ & AS_REP 和 TGS_REQ & TGS_REP ,以及微软扩展的两个认证模块 S4U 和 PAC 。S4U 是微软为了实现委派而扩展的模块,分为 S4U2Self 和 S4U2Proxy 。在 Kerberos 最初设计的流程里只说明了如何证明客户端的真实身份,但是并没有说明客户端是否有权限访问该服务,因为在域中不同权限的用户能够访问的资源是不同的。因此微软为了解决权限这个问题,引入了 PAC (Privilege Attribute Certificate,特权属性证书) 的概念。
# AS_REQ & AS_REP
1、KRB_AS-REQ 请求包分析
Client->AS:Client 先向 KDC 的 AS 发送 pA-ENC-TIMESTAMP(内容为 Client hash 加密的时间戳 )
**AS-REQ:** 当域内某个用户想要访问域内某个服务时,于是输入用户名和密码,本机就会向 KDC 的 AS 认证服务发送一个 AS-REQ 认证请求。该请求包中包含如下信息:
-
请求的用户名 (cname)。
-
域名 (realm)。
-
**Authenticator:** 一个抽象的概念,代表一个验证。这里是用户密钥加密的时间戳。
-
** 请求的服务名 (sname):**AS-REQ 这个阶段请求的服务都是 krbtgt。
-
加密类型 (etype)。
-
** 以及一些其他信息:** 如版本号,消息类型,票据有效时间,是否包含 PAC,协商选项等。
-
用户向 KDC 发起 AS_REQ, 请求凭据是用户 hash 加密的时间戳。请求凭据放在 PA_DATA 里面
krbtgt 是 Kerberos 中的一个特殊账户,用于存储和管理 Ticket Granting Ticket(TGT)。在 Kerberos 认证系统中,krbtgt 账户是一个系统级别的账户,用于生成 TGT 和使用自己的 hash(krbtgt hash)加密 TGT,并提供给用户进行身份验证和获取服务票据。那么如果攻击者获取到了这个 hash(krbtgt hash),那么就可以任意的伪造 TGT 了,也就是黄金票据,拥有了黄金票据就可以跳过 AS 验证了。
在 AS_REQ 阶段主要用到的有两个
PA-ENC-TIMESTAMP
-
- PA-DATA PA-ENC-TIMESTAMP:这个是预认证,就是用用户 Hash 加密时间戳,作为 value 发送给 KDC 的 AS 服务。然后 KDC 从活动目录中查询出用户的 hash,使用用户 Hash 进行解密,获得时间戳,如果能解密,且时间戳在一定的范围内,则证明认证通过。由于是使用用户密码 Hash 加密的时间戳,所以也就造成了哈希传递攻击
-
PA_PAC_REQUEST
-
- 这个是启用 PAC 支持的扩展。PAC 并不在原生的 kerberos 里面,是微软引进的扩展。PAC 包含在 AS_REQ 的响应 body (AS_REP)。这里的 value 对应的是 include=true 或者 include=false (KDC 根据 include 的值来判断返回的票据中是否携带 PAC)。
2、 KRB_AS_REP 回复包分析:
AS->Client:AS 根据用户名在 AD 中寻找是否在 AD 数据库中,然后根据 Client 的用户名提取到对应的 Hash,接着 pA-ENC-TIMESTAMP 用对应 Client 用户名的 Hash 进行解密,如果结果正确则会返回如下:
1、返回当前 KDC 中 krbtgt hash 加密的 TGT 票据 **(TGT 包含 PAC,PAC 包含 Client 的 sid,Client 所在的组)**,在通信数据包中显示的就是 ticket 字段
2、Authentication Service 会生成一个随机数 Session key(这个非常重要,作为 kerberos 中下一轮的认证密钥),返回给 Client 由 Client 的 HASH 加密的 enc-part 字段
KDC 的 AS 认证服务在成功认证客户端的身份之后,发送 AS-REP 响应包给客户端。AS-REP 响应包中主要包括如下信息:
-
请求的用户名 (cname)。
-
域名 (crealm)。
-
TGT 认购权证:包含明文的版本号,域名,请求的服务名,以及加密部分 enc-part。加密部分用 krbtgt 密钥加密。加密部分包含 Logon Session Key、用户名、域名、认证时间、认证到期时间和 authorization-data。authorization-data 中包含最重要的 PAC 特权属性证书 (包含用户的 RID,用户所在组的 RID) 等。
-
enc_Logon Session Key:使用用户密钥加密 Logon Session Key 后的值,其作用是用于确保客户端和 KDC 下阶段之间通信安全。也就是 AS-REP 中最外层的 enc-part。
-
以及一些其他信息:如版本号,消息类型等。
TGT 认购权证
AS-REP 响应包中的 ticket 便是 TGT 认购权证了。TGT 认购权证中包含一些明文显示的信息,如版本号 tkt-vno、域名 realm、请求的服务名 sname。但是 TGT 认购权证中最重要的还是加密部分,加密部分是使用 krbtgt 帐户密钥加密的。加密部分主要包含的内容有 Logon Session Key、请求的用户名 cname、域名 crealm、认证时间 authtime、认证到期时间 endtime、authorization-data 等信息。
最重要的还是 authorization-data 部分,这部分中包含客户端的身份权限等信息,这些信息包含在 PAC 中。
**KDC 生成 PAC 的过程如下:**KDC 在收到客户端发来的 AS-REQ 请求后,从请求中取出 cname 字段,然后查询活动目录数据库,找到 sAMAccountName 属性为 cname 字段的值的用户,用该用户的身份生成一个对应的 PAC。
Logon Session Key
AS-REP 响应包最外层的那部分便是加密的 Login session Key 了,其作用是用于确保客户端和 KDC 下阶段之间通信安全,它使用请求的用户密钥加密。
我们对最外层的 enc-part 部分进行解密,就可以看到是使用 hack 用户的密钥对其进行解密的。
解密结果如下:主要包含的内容是认证时间 authtime、认证到期时间 endtime、域名 srealm、请求的服务名 sname、协商标志 flags 等一些信息。需要说明的是,在 TGT 认购权证中也包含 Logon Session Key ,作为下阶段的认证密钥。
ticket
这个 ticket 用于 TGS_REQ 的认证。是加密的,用户不可读取里面的内容。在 AS_REQ 请求里面是,是使用 krbtgt 的 hash 进行加密的,因此如果我们拥有 krbtgt 的 hash 就可以自己制作一个 ticket,既黄金票据。
# TGS_REQ & TGS_REP
KRB_TGS_REQ (请求):
Client 接收到了加密后的 ticket (TGT) 和 enc-part 之后,先对 enc-part 用自身密码 HASH 解密得到 Session key,也就是上文中说的 随机生成的 Session key。
TGT 是由 KDC 中 krbtgt 的 Hash 加密,所以 Client 无法解密。
这时 Client 继续再用 Session key 加密的 TimeStamp(authenticator,然后再和 ticket (TGT) 一起发送给 KDC 中的 TGS(TicketGranting Server)票据授权服务器换取能够访问 Server 的票据。
然后这里面的 ticket 其实还是我们的 TGT 票据
KRB_TGS_REP (应答):
TGS 收到 Client 发送过来的 ticket (TGT) 和 Session key 加密 TimeStamp 的 authenticator 之后,首先会检查自身是否存在 Client 所请求的服务。如果服务存在,则用 krbtgt 的 HASH 来解密 ticket (TGT)。
一般情况下 TGS 会检查 TGT 中的时间戳查看 TGT 是否过期,且原始地址是否和 TGT 中保存的地址相同。
验证成功之后将返回 Client 两个东西,一个是用 Session key 加密的 enc-part,然后另一个是 Client 要访问的 Server 的密码 HASH 加密的 TGS 票据(要访问服务端的 Hash)生成就是 ST(TGS)票据,那么此时的 ticket 就是 TGS 了
这个过程其实跟我们请求 TGT 是一样的,你可以看到一个 ticket (TGS) 和一个 enc-part
enc-part 这个部分同样是可以解密的,原因就是这里 enc-part 加密用的密钥,实际上就是上一轮 AS_REP 里面返回的 Session key,从开始到现在这里的 Session key 一直都是一样的,作为下一轮通信的认证密钥。
# 票据攻击
黄金票据是伪造 TGT,白银票据则是伪造 ST
# 黄金票据(Golden ticket)
黄金票据伪造的是票据授予票据 (TGT),TGT=krbtgt hash (session key,client info,end time)。TGT 由 AS 返回给 client,然后 client 用 TGT 来向 TGS 验证自己的身份,而 client 是不知道 krbtgt hash 的,只有 AS 与 TGS 知道 krbtgt hash,所以要想伪造 TGT 就需要知道 krbtgt hash。所以攻击者伪造黄金票据 TGT 的前提是获得管理员访问域控制器的权限并抓取到 krbtgt hash。
而 session key 是由 AS 随机生成的,TGS 在收到 TGT 之前并不知道,所以可以伪造。client info 和 end time 也是可以自己定的。所以我们可以伪造由 client 发给 TGS 的 TGS REQ,进而获得 server ticket。
黄金票据常用于权限维持。 当我们获得域控的控制权限后,有可能获取域内所有用户的 hash,和 krbtgt 的 hash。这时,由于一些原因导致我们失去对目标的控制权,但是我们还留有一个普通用户的权限,并且 krbtgt 的密码没有更改,此时我们可以利用 krbtgt 用户的 ntlm hash 制作黄金票据伪造 tgt,重新获取域控的管理权限。
条件:
1、域名称
2、域的 SID 值
3、域的 KRBTGT 账号的 HASH
4、伪造任意用户名
(获取域的 SID 和 KRBTGT 账号的 NTLM HASH 的前提是需要已经拿到了域的权限)
黄金票据的特点
(1) KDC 中的 TGS 不通过读取 AD 来验证来自 client 的 TGS REQ 中的用户账户信息,知道 TGT 超过 20 分钟,这意味着攻击者可以使用禁用和删除帐户,甚至是在 Active Directory 中不存在的虚拟帐户。
(2) 由于 Kerberos 的策略是由 DC 上的 KDC 设置的,所以如果提供票据,则系统就会信任票据的有效性。也就是说,即使域策略声明 TGT 只有 10 小时有效,但将 TGT 中声明的有效期改为 10 年,那信任票据的有效性期会成为 10 年而不是 10 小时。
(3) 绕过了 SmartCard 身份验证要求,因为它绕过了 DC 在创建 TGT 之前执行的常规验证。
(4) 要求攻击者拥有 Active Directory 域的 KRBTGT 密码哈希值,从而伪造 TGT。
(5) Krbtgt hash 可用于生成一个有效的 TGT(使用 RC4),模拟任何用户访问 Active Directory 中的任何资源。
(6) 只要网络可以访问域,即使没有加入域,在主机上也可以生成和使用黄金票据。
黄金票据防御
(1) 限制域管理员登录到除域控制器和少数管理服务器以外的任何其他计算机,将所有其他权限委派给自定义管理员组。这可以降低攻击者访问域控制器的 Active Directory 的 ntds.dit 文件。而如果攻击者无法访问 AD 数据库(ntds.dit 文件),则其无法获取到 krbtgt hash。
(2) 增加更改 krbtgt 账户的密码的频率。
# 制作黄金票据
基本信息获取(SID, 所处域)
1 | 这里直接在域控制权上进行操作 |
获取 krbtgt 用户 hash
1 | 运行mimikatz.exe |
制作黄金票据(使用 mimikatz)
此时我们已经拥有 krbtgt 账号的 hash,接下来切换到普通机器,使用 mimikatz 制作黄金票据。
1 | Kerberos::purge |
票据传递
1 | kerberos::ptt ticket.kirbi |
此时一个通往域内任意服务的后门制作完成。
可以直接使用 psexec 工具获得交互权限
PsExec64.exe \\dc.cyber.com -s cmd.exe
也可以在域内创建隐藏用户。
net user qwerty$ Aa123456 /add /domain net group "domain admins" qwerty$ /domain
# 白银票据(Silver ticket)
如果说黄金票据是伪造的 TGT, 那么白银票据就是伪造的 ST。 在 Kerberos 认证的第三部,Client 带着 ST 和 Authenticator3 向 Server 上的某个服务进行请求,Server 接收到 Client 的请求之后,通过自己的 Master Key 解密 ST, 从而获得 Session Key。通过 Session Key 解密 Authenticator3, 进而验证对方的身份,验证成功就让 Client 访问 server 上的指定服务了。 所以我们只需要知道 Server 用户的 Hash 就可以伪造出一个 ST, 且不会经过 KDC, 但是伪造的门票只对部分服务起作用。
所需条件
1. 域名
2. 域 sid
3. 目标服务器名
4. 可利用的服务
5. 服务账号的 NTML HASH
6. 需要伪造的用户名
# 制作白银票据
基本信息获取(SID,所处域,服务器名,NTLM HASH)
1 | SID和所处域参考上面 |
制作白银票据(使用 mimikatz)
1 | klist purge 清除票据 |
# 金票和银票的区别
获取的权限不同
金票:伪造的 TGT,可以获取任意 Kerberos 的访问权限
银票:伪造的 ST,只能访问指定的服务,如 CIFS
认证流程不同
金票:同 KDC 交互,但不同 AS 交互
银票:不同 KDC 交互,直接访问 Server
加密方式不同
金票:由 krbtgt NTLM Hash 加密
银票:由服务账号 NTLM Hash 加密
- Title: Kerberos&Ticket
- Author: Fc04dB
- Created at : 2024-11-26 23:20:28
- Updated at : 2024-11-27 13:33:18
- Link: https://redefine.ohevan.com/2024/11/26/Kerberos-Ticket/
- License: This work is licensed under CC BY-NC-SA 4.0.