Kerberos中MS14068和金银票据的原理和利用方式是什么，针对这个问题，这篇文章详细介绍了相对应的分析和解答，希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。
下面具体说一下Kerberos曾经爆出的一个经典的漏洞MS14068和金银票据的原理和利用方式。MS14068是一个比较经典的漏洞，小编对金银票据以及增强型的金票据做一个说明。
MS14068是一个能够使普通用户提权到域控权限的权限提升漏洞。攻击者可以通过构造特定的请求包来达到提升权限的目的。首先我们来说一下利用方式。
实验环境：
域：YUNYING.LAB
域控：WindowsServer 2008 R2 x64(DC)
域内主机：Windows7 x64(s1):域帐户ts1
所需工具：
Pykek
mimikatz
攻击流程：
实验之前需要在域控主机查看是否安装了KB3011780补丁，可通过systeminfo来查看。
一、首先在域内主机s1上通过dir来访问域控的共享文件夹，示拒绝访问。
二、通过Pykek工具利用漏洞，我这里使用的是将python脚本编译之后的exe文件。
参数说明：
-u 域账号+@+域名称，这里是ts1+@+yunying.lab
-p 为当前用户的密码，即ts1的密码
-s为ts1的SID值，可以通过whoami/all来获取用户的SID值
-d为当前域的域控
脚本执行成功会在当前目录下生成一个ccache文件。
三、使用mimikatz导入生成的ccache文件，导入之前cmd下使用命令klist purge或者在mimikatz中使用kerberos::purge删除当前缓存的kerberos票据。
再次dir访问域控共享已经可以成功访问。
MS14068工具在使用过程中抓包可以看到s1和域控192.168.254.130（实质上是与安装在域控上的KDC）有KRB_AS_REQ、KRB_AS_REP、KRB_TGS_REQ、KRB_TGS_REP四次交互。
下面根据流程和工具源码来看漏洞是如何利用的：
KRB_AS_REQ
首先程序通过build_as_req函数构建AS_REQ，在这里可以看到，参数pac_request设置为false。
也就是说设置了这个参数之后会向KDC申请一张不包含PAC的TGT票据，这是微软默认的设计，在下列链接中有详细说明。
https://docs.microsoft.com/en-us/previous-versions/aa302203(v=msdn.10)#security-considerations
通过PCAP包可以更直观的看到在AS-REQ请求中的include-pac:False字段。这是造成这个漏洞的第一个因素。
KRB_AS_REP
在AS发起请求之后，KDC（AS）将返回一张不包含有PAC的TGT票据给Client。在这里是tgt_a。
抓包可以看到这个以268fdb开头的TGT票据。
KRB_TGS_REQ
攻击脚本使用了两个关键函数来实现这个过程，首先通过build构造PAC，然后通过build_tgs_req函数构造TGS-REQ的内容。
build_pac
当Client接收到AS返回的不带有PAC的TGT之后通过脚本中的build_pac函数开始构造PAC。
这里我们重点关注一下PAC中的chksum1和chksum2，也就是“PAC的引入”中提到的PAC的两个数字签名PAC_SERVER_CHECKSUM和PAC_PRIVSVR_CHECKSUM。
注意一下其中第一个参数server_key[0]和kdc_key[0]的值其实是程序指定的RSA_MD5，而Key的值为None，但原则上来说这个加密方式是应该由KDC来确定的。也就是说加密PAC_SERVER_CHECKSUM和PAC_PRIVSVR_CHECKSUM这两个数字签名的Key应该分别是Server密码HASH和KDC密码HASH，在这里却直接使Key为None，然后直接使用RSA_MD5方式加密。
这是漏洞形成的第二个因素，查看checksum函数即可验证这一点。
同时在这个过程中我们也需要关注一下user_sid这个参数，build_pac函数会将其分割，然后重新构造高权限的sid的值。在这里user_sid的值为S-1-5-21-4249968736-1423802980-663233003-1104，分割之后domain_sid为S-1-5-21-4249968736-1423802980-663233003，user_id为1104。
其中512、520、518、519分别为不同的组的sid号。513为DOMAIN USERS组。通过这种方式构造了包含高权限组SID的PAC。
build_tgs_req
在build_tgs_req函数的参数中，authorization_data对应的为build_pac生成的pac。
这里将PAC传入build_tgs_req之后使用subkey将其加密。
而通过下图可以看到subkey其实是函数generate_subkey生成的一串16位的随机数。
那现在为止出现的问题有：
A、在域中默认允许设置Include-pac的值为False（不能算漏洞，应该是微软对于某些特定场景的特殊考虑设计出的机制）；
B、PAC中的数字签名可以由Client端指定，并且Key的值可以为空；
C、PAC的加密方式也可以由Client指定，并且Key的值为generate_subkey函数生成的16位随机数；
D、构造的PAC中包含高权限组的SID内容。
也就是说通过这几点Client完全伪造了一个PAC发送给KDC，并且KDC通过Client端在请求中指定的加密算法来解密伪造的PAC以及校验数字签名，并验证通过。
通过抓包可以看到在这个过程中将接收的TGT（268fdb开头）和加密方式为ARCFOUR-HMAC-MD5的PAC内容。
KRB_TGS_REP
KDC在根据对伪造的PAC验证成功之后，返回给Client端一有新的TGT，并且这个TGT会将Pykek生成的PAC包含在其中，这里正常情况下返回的其实是一张用于发送给Server端做认证的ST票据。
当Pykek工具接收到新的TGT之后就将其保存生成ccache文件。也就是说这时Client已经获得了一张包含有高权限PAC内容的正常的TGT票据（564eab开头）。
使用Mimikatz利用TGT访问DC共享文件夹
这时我们通过mimikatz来导入票证，并且用dir \\dc.yunying.lab\c$来访问域控的共享文件夹。
抓包可以看到这时Client端发起了两次TGS-REQ请求，重点关注一下第一次，此时用的票据就是使用mimikatz导入的TGT，也就是上面KRB_TGS_REP过程中返回的那个tgt_b（564eab开头）。
请求之后返回了一张针对dc.yunying.lab（域控）的CIFS票据也就是正常流程中的ST（Service Ticket）票据（234062开头）：
这时在抓的包中发现并没有AP_REQ这个流程，是因为在Kerberos中AP_REQ这个过程放在了服务的第一次请求中，这里是放在SMB的Session Setup Request中（其他协议同理，比如HTTP协议是放在GET请求中）。
然后在SMB的Session Setup Response中做出响应，也就是AP-REP这个流程。
到此为止Client能够越权访问域控的共享文件夹。
此漏洞是一个14年的漏洞，多数产生在windowsserver 2008和windows server 2003的域环境中，所以安全补丁早已可以下载安装，用户可以通过在域控上安装KB3011780补丁来规避风险。
同时可以根据上文中提到的标记include-pac为False的特征来初步的筛选。
也可以通过windows日志来发现，如ID为4624登录到目标服务器、ID为5140表示网络共享对象被访问等等。
在这个漏洞中主要的问题是存在于KDC会根据客户端指定PAC中数字签名的加密算法，以及PAC的加密算法，来校验PAC的合法性。这使得攻击者可通过伪造PAC，修改PAC中的SID，导致KDC判断攻击者为高权限用户，从而导致权限提升漏洞的产生。
Golden Ticket（下面称为金票）是通过伪造的TGT（TicketGranting Ticket），因为只要有了高权限的TGT，那么就可以发送给TGS换取任意服务的ST。可以说有了金票就有了域内的最高权限。
制作金票的条件：
1、域名称
2、域的SID值
3、域的KRBTGT账户密码HASH
4、伪造用户名，可以是任意的
实验环境
域：YUNYING.LAB
域控：WindowsServer 2008 R2 x64(DC)
域内主机：Windows7 x64(s1):用户ts1
所需工具
Mimikatz
实验流程
金票的生成需要用到krbtgt的密码HASH值，可以通过mimikatz中的
lsadump::dcsync /domain:yunying.lab /user:krbtgt
命令获取krbtgt的值。如果已经通过其他方式获取到了KRBTGT HASH也可以直接进行下一步。
得到KRBTGT HASH之后使用mimikatz中的kerberos::golden功能生成金票golden.kiribi，即为伪造成功的TGT。
参数说明：
/admin：伪造的用户名
/domain：域名称
/sid：SID值，注意是去掉最后一个-后面的值
/krbtgt：krbtgt的HASH值
/ticket：生成的票据名称
金票的使用
通过mimikatz中的kerberos::ptt功能（Pass The Ticket）将golden.kiribi导入内存中。
已经可以通过dir成功访问域控的共享文件夹。
这样的方式导入的票据20分钟之内生效，如果过期再次导入就可以，并且可以伪造任意用户。
Silver Tickets（下面称银票）就是伪造的ST（Service Ticket），因为在TGT已经在PAC里限定了给Client授权的服务（通过SID的值），所以银票只能访问指定服务。
制作银票的条件：
1.域名称
2.域的SID值
3.域的服务账户的密码HASH（不是krbtgt，是域控）
4.伪造的用户名，可以是任意用户名，这里是silver
实验环境
域：YUNYING.LAB
域控：WindowsServer 2008 R2 x64(DC)
域内主机：Windows7 x64(s1):用户ts1
所需工具
Mimikatz
实验流程
首先我们需要知道服务账户的密码HASH，这里同样拿域控来举例，通过mimikatz查看当前域账号administrator的HASH值。注意，这里使用的不是Administrator账号的HASH，而是DC$的HASH。
这时得到了DC的HASH值，通过mimikatz生成银票。
参数说明：
/domain：当前域名称
/sid：SID值，和金票一样取前面一部分
/target：目标主机，这里是dc.yunying.lab
/service：服务名称，这里需要访问共享文件，所以是cifs
/rc4：目标主机的HASH值
/user：伪造的用户名
/ptt：表示的是Pass TheTicket攻击，是把生成的票据导入内存，也可以使用/ticket导出之后再使用kerberos::ptt来导入
这时通过klist查看当前会话的kerberos票据可以看到生成的票据。
使用dir \\dc.yunying.lab\c$访问DC的共享文件夹。
银票生成时没有KRBTGT的密码，所以不能伪造TGT票据，只能伪造由Server端密码加密的ST票据，只能访问指定的服务。
在Golden Ticket部分说明可利用krbtgt的密码HASH值生成金票，从而能够获取域控权限同时能够访问域内其他主机的任何服务。但是普通的金票不能够跨域使用，也就是说金票的权限被限制在当前域内。
为什么普通金票会被限制只能在当前域内使用？
在上一篇文章中说到了域树和域林的概念，同时说到YUNYING.LAB为其他两个域（NEWS.YUNYING.LAB和DEV.YUNYING.LAB）的根域，根域和其他域的最大的区别就是根域对整个域林都有控制权。而域正是根据Enterprise Admins组（下文会说明）来实现这样的权限划分。
实验环境
根域：YUNYING.LAB 域控：DC.YUNYING.LAB
子域：NEWS.YUNYING.LAB 域控：NEWSDC.NEWS.YUNYING.LAB
子域：DEV.YUNYING.LAB 域控：DEVDC.DEV.YUNYING.LAB
操作系统均为WindowsServer 2008 R2 x64
使用工具：
Mimikatz
实验流程：
首先使用mimikatz在NEWSDC（NEWS.YUNYING.LAB的域控）上生成普通的金票，真实环境会是在域内的主机中，这里方便演示所以在域控中，原理和结果是一样的。
kerberos::golden /admin:administrator /domain:news.yunying.lab /sid:SID /krbtgt:XXXXX /ptt
这里使用的是NEWS.YUNYING.LAB域的SID号，访问根域的DC共享文件夹被拒绝。
下面说明下具体原因。
Enterprise Admins组
EnterpriseAdmins组是域中用户的一个组，只存在于一个林中的根域中，这个组的成员，这里也就是YUNYING.LAB中的Administrator用户（不是本地的Administrator，是域中的Administrator）对域有完全管理控制权。
通过whoami命令在yunying.lab的域控上可以看到Enterprise Admins组的RID为519（最后三位）
Domain Admins组
可以看到在子域中是不存在EnterpriseAdmins组的，在一个子域中权限最高的组就是Domain Admins组。截图是news.yunying.lab这个子域中的Administrator用户，这个Administrator有当前域的最高权限。
通过whoami命令也可以看到在news.yunying.lab这个子域中没有EnterpriseAdmins组的SID号。
在子域中使用mimikatz创建的黄金票据不能跨域使用的原因也就在这里，通过whoami可以看到YUNYING.LAB中Enterprise Admins组的SID号是：
S-1-5-21-4249968736-1423802980-663233003-519
而NEWS.YUNYING.LAB域中的SID号是：
S-1-5-21-3641416521-285861825-2863956705-XXX
mimikatz通过/sid选项接收SID号然后在尾部拼接RID号（512,519等），拼接之后生成的EnterpriseAdmins组的完整SID是：
S-1-5-21-3641416521-285861825-2863956705-519
而这个SID在整个域林中都是不存在的，所以在子域中通过mimikatz生成的金票无法跨域或者是访问其他域的资源。在一个域林中，域控权限不是终点，根域的域控权限才是域渗透的终点。
普通的黄金票据被限制在当前域内，在2015年Black Hat USA中国外的研究者提出了突破域限制的增强版的黄金票据。通过域内主机在迁移时LDAP库中的SIDHistory属性中保存的上一个域的SID值制作可以跨域的金票。这里没有迁移，直接拿根域的SID号做演示。
如果知道根域的SID那么就可以通过子域的KRBTGT的HASH值，使用mimikatz创建具有 EnterpriseAdmins组权限（域林中的最高权限）的票据。环境与上文普通金票的生成相同。
首先我们通过klist purge删除当前会话的Kerberos票据，也可以在mimikatz里通过kerberos::purge来删除。
然后通过mimikatz重新生成包含根域SID的新的金票
kerberos::golden /admin:administrator /domain:news.yunying.lab /sid:XXX /sids:XXX /krbtgt:XXX /startoffset:0 /endin:600 /renewmax:10080 /ptt
Startoffset和endin分别代表偏移量和长度，renewmax表示生成的票据的最长时间
注意这里是不知道根域YUNYING.LAB的krbtgt的密码HASH的，使用的是子域NEWS.YUNYING.LAB中的KRBTGT的密码HASH。
然后再通过dir访问DC. YUNYING.LAB的共享文件夹，发现已经可以成功访问。
此时的这个票据票是拥有整个域林的控制权的。我们知道制作增强金票的条件是通过SIDHistory那防御方法就是在域内主机迁移时进行SIDHistory过滤，它会擦除SIDHistory属性中的内容。MS14068的利用方式和金银票据，主要用来提升和维持域内权限，通常情况下需要结合其他的域内攻击方式进行使用，比如获取了域控制器的NTLM HASH等内容时。
关于Kerberos中MS14068和金银票据的原理和利用方式是什么问题的解答就分享到这里了，希望以上内容可以对大家有一定的帮助，如果你还有很多疑惑没有解开，可以关注亿速云行业资讯频道了解更多相关知识。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
