集权攻击系列：如何利用PAC新特性对抗黄金票据？
黄金票据简介
黄金票据是一种常见的域内权限维持手段，这种攻击主要是利用了Kerberos认证过程中TGT票据由KRBTGT用户的hash加密的特性，在掌握KRBTGT用户密码之后可以通过签发一张高权限用户的TGT票据，再利用这个TGT向KDC获取域内服务的ST来实现对域的控制。那么这里的“高权限用户”是通过什么来判断的呢，答案就是PAC。
1.PAC的作用
PAC的结构如下图所示（MS-PAC）
整个结构详解可以参考daiker师傅的这篇文章，由于TGT是krbtgt用户的hash加密的，我们在wireshark抓包是看不到TGT的结构的，不过我们可以写了一个工具来解密TGT和PAC。
PAC解析后内容如下：
可以看到在没有更新之前PAC中一共由5种类型的INFO_BUFFER:
·KERB_VALIDATION_INFO（0x1）
·PAC_CLIENT_INFO(0x0A)
·UPN_DNS_INFO(0x0C)
·PAC_SERVER_CHECKSUM (0x06)
·PAC_PRIVSVR_CHECKSUM(0x07)
当用户通过Kerberos预认证之后，KDC会给用户返回TGT票据，在TGT票据中包含了用户的SID、组等信息。在后续的TGS请求中KDC会将TGT中的PAC直接复制到返回给用户的ST票据中，最终由服务向KDC申请验证该PAC来确认用户是否有权访问该服务。
通过上面的描述，可以看出PAC在Kerberos认证的权限校验过程起着非常关键的作用，在历史上也因为PAC的问题出现过非常严重的安全漏洞（如著名的ms14-068），然而这个过程在微软针对CVE-2021-422287漏洞修复更新之后发生了一些变化。
2.PAC_REQUESTOR
2021年11月9日，微软发布了针对CVE-2021-42287漏洞的修复补丁，跟据微软的文章描述，此次更新后，在PAC中添加了一个新属性PAC_REQUESTORKDC将会在PAC的PAC_REQUESTOR结构体填充原始请求者的SID，并且在TGS_REQ过程验证请求用户(cname)是否和PAC_REQUESTOR中的SID相匹配。我们用工具解析安装CVE-2021-42287补丁更新之后的域控返回的TGT。
考虑到更新之后票据的兼容问题，微软增加了一个注册表项
PACRequestorEnforcement来对验证规则进行控制，该注册表位于HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\KdcPACRequestorEnforcement的默认值为1，当该注册表项的值为0时表示不验证PAC_REQUESTOR, 值为1时表示如果PAC中存在PAC_REQUESTOR结构就验证，如果不存在就不验证，当值为2时所有PAC都需要验证PAC_REQUESTOR, 不包含PAC_REQUESTOR结构的PAC将会被拒绝。
微软将整个更新过程分为三个阶段：
1.初始部署阶段更新时间为2021年11月9日，在这个阶段增加了对PacRequestorEnforcement注册表项的支持，用户可以通过设置该注册表项对PAC新增属性的验证规则进行控制。
2.第二个部署阶段更新时间为2022年7月12日，在这个阶段的更新执行之后，PacRequestorEnforcement等于0的情况将不被支持，将这个注册表设置为0将等同于设置成1。
3.强制执行阶段安装了这次更新的域控将移除PacRequestorEnforcement注册表，也就是只支持带有PAC_REQUESTOR结构的TGT，并且和存在以下情况的域控不兼容
· 未安装 2021 年 11 月 9 日或更高版本更新的域控制器。
· 已安装 2021 年 11 月 9 日或更高版本更新，但尚未安装 2022 年 7 月 12 日更新的域控制器以及 PacRequestorEnforcement 注册表值为 0 的域控制器。
与此同时，这次更新也新增了新的系统日志，日志ID和对应的含义如下：
3.基于PAC更新的黄金票据检测
在这次更新之后，一些黑客工具也对此进行了相应的更新
不过需要注意这些工具（impacket、mimikatz、Rubeus）在生成黄金票据的过程中伪装的用户SID默认都是500。
大部分情况下，攻击者不会去修改默认的用户SID，如果在制作黄金票据时对应的用户名不存在或者其SID不是500的话，域控上将会触发event 38日志，如果使用的工具没有更新PAC结构的话将会触发event 37日志，通过这两条日志就可以对黄金票据攻击进行检测。
