PAC

PAC(Privilege Attribute Certificate)，特权属性证书 需要提供User的SID和所在组Group的SID

只看上述的就简单解释并不能很清晰的了解，那么想要知道PAC这个概念，我们首先理一下kerberos的流程

网上很多kerberos如下：

1：用户向KDC发起AS_REQ,请求凭据是用户hash加密的时间戳，KDC使用用户hash进行解密，如果结果正确返回用krbtgt hash加密的TGT票据

2：用户凭借TGT票据向KDC发起针对特定服务的TGS_REQ请求，KDC使用krbtgt hash进行解密，如果结果正确，就返回用服务hash 加密的TGS票据

3：用户拿着TGS票据去请求服务，服务使用自己的hash解密TGS票据。如果解密正确，就允许用户访问。

上面这个流程看起来没错，却忽略一个最重要的因素，那就是用户有没有权限访问该服务，在上面的流程里面，只要用户的hash正确，那么就可以拿到TGT，有了TGT，就可以拿到TGS，有了TGS，就可以访问服务，任何一个用户都可以访问任何服务。

为了解决上面的这个问题，微软引进了PAC，引进PAC之后的kerberos流程变成

1：用户向KDC发起AS_REQ,请求凭据是用户hash加密的时间戳，KDC使用用户hash进行解密，如果结果正确返回用krbtgt hash加密的TGT票据，TGT里面包含PAC,PAC包含用户的sid，用户所在的组。

2：用户凭借TGT票据向KDC发起针对特定服务的TGS_REQ请求，KDC使用krbtgt hash进行解密，如果结果正确，就返回用服务hash 加密的TGS票据(这一步不管用户有没有访问服务的权限，只要TGT正确，就返回TGS票据，这也是kerberoating能利用的原因，任何一个用户，只要hash正确，可以请求域内任何一个服务的TGS票据。

3：用户拿着TGS票据去请求服务，服务使用自己的hash解密TGS票据。如果解密正确，就拿着PAC去KDC那边询问用户有没有访问权限，域控解密PAC。获取用户的sid，以及所在的组，再判断用户是否有访问服务的权限，有访问权限(有些服务并没有验证PAC这一步，这也是白银票据能成功的前提，因为就算拥有用户hash，可以制作TGS，也不能制作PAC，PAC当然也验证不成功，但是有些服务不去验证PAC，这是白银票据成功的前提）就允许用户访问。

特别说明的是，PAC对于用户和服务全程都是透明的。只有KDC能制作和查看PAC。

上述那么一大段，边界骇客总结如下，建议还是先细细的看一遍然后再来看总结：

TGT票据中带PAC，PAC根据AS_REQ和 AS_REP的相关请求和结果生成
票据交换的时候不校验PAC内用户是否有权限访问服务
服务请求的时候才会去校验票据服务是否有权限
任何一个用户，只要hash正确，可以请求域内任何一个服务的TGS票据

漏洞原理
原理:在AD认证的过程中，如果存在一个机器账户，此账户的名称和AD机器名（下面
为test$）去掉$后相同，当我们请求了TGT以后删除此账户，如果利用此TGT
进行正常请求，由于没有这个用户，所以域控无法正确来解密此票据。但是域控有
一个机制，当数据库中未检索到这个账户，会寻找samaccountname为此账户的用
户，此时就可以利用 S4U2self 去请求DC秘钥加密的TS票据。

这里S4U2self 这个概念是：
在TGSREQ & TGSREP阶段，用户通过AS_REP拿到的TGT票据，去向KDC申请特定服务的访问权限，KDC校验TGT票据，如果校验通过的话，会向用户发送一个TGS票据，之后用户再拿着TGS去访问特定的服务。这一阶段，微软引进了两个扩展S4U2SELF和S4U2PROXY。
S4U2self 使得服务可以代表用户获得针对服务自身的kerberos服务票据。这使得服务可以获得用户的授权( 可转发 的用户TGS票据)，然后将其用于后期的认证(主要是后期的s4u2proxy)，这是为了在用户以不使用 Kerberos 的方式对服务进行身份验证的情况下使用。这里面很重要的一点是服务代表用户获得针对服务自身的kerberos票据这个过程，服务是不需要用户的凭据的

工具：https://github.com/cube0x0/noPac
noPac64.exe scan -domain god.org -user yuchen-pass Admin_123
noPac64.exe -domain god.org -user yuchen-pass Admin_123 /dc owa.god.org /mAccount demol /mPassword pAss123! /service cifs /ptt

MS14068成因：
补丁编号是KB3011780，域里面最严重的漏洞之一，它允许任意用户提升到域管权限。下面简要分析下该漏洞。
该漏洞最本质的地方在于Microsoft Windows Kerberos KDC无法正确检查Kerberos票证请求随附的特权属性证书（PAC）中的有效签名，这里面的签名就是上面提到的服务检验和以及KDC校验和。导致用户可以自己构造一张PAC。 签名原本的设计是要用到HMAC系列的checksum算法，也就是必须要有key的参与，我们没有krbtgt的hash以及服务的hash，就没有办法生成有效的签名，但是问题就出在，实现的时候允许所有的checksum算法都可以，包括MD5。那我们只需要把PAC 进行md5，就生成新的校验和。这也就意味着我们可以随意更改PAC的内容，完了之后再用md5 给他生成一个服务检验和以及KDC校验和。在MS14-068修补程序之后，Microsoft添加了一个附加的验证步骤，以确保校验和类型为KRBCHECKSUMHMAC_MD5。

PAC：由于MS14068只验证么用户是谁，没有验证用户能做什么引入的一个安全机制。
是用户申请TGT的时候由KDC回复的包含用户SID，用户组等的信息。此时和传统的
kerber认证相比，当服务端解密了用户的TGS会获取到用户的PAC拿去和KDC对比查
看用户具有权限（PAC不可伪造），但是有些服务不验证KDC所以能利用白银票价，
而所有正常的用户都能申请TGS，所以kerberosting能够利用成功。

此文重在自我理解，然后个人记录，没有连贯性，请谅解

参考：
https://www.anquanke.com/post/id/190261
https://www.anquanke.com/post/id/190625
https://www.anquanke.com/post/id/192810
https://mp.weixin.qq.com/s/OI9XiUGe4-1exmFOkV9ZVQ
https://www.geekby.site/2021/12/samaccountname-spoofing/