内网渗透-(黄金票据和白银票据)详解(一)

一、Kerberos协议

二、下面我们来具体分析Kerberos认证流程的每个步骤：

1、KRB_AS-REQ请求包分析

PA-ENC-TIMESTAMP

PA_PAC_REQUEST

2、 KRB_AS_REP回复包分析：

TGT认购权证

Logon Session Key

ticket

3、然后继续来讲相关的TGS的认证过程

KRB_TGS_REQ(请求)：

KRB_TGS_REP(应答)：

4、cilent访问服务端

KRB_AP_REQ(请求)：

KRB_AP_REP(应答)：

三、黄金票据的原理和条件

1原理

2条件

3.黄金票据的局限性

4.绕过黄金票据局限性

5.黄金票据的特点

6.黄金票据防御

四、实践

（1）权限提升：privilege::debug

（2）获得krbtgt账户的SID 、krbtgt:hash

(3)生成票据并利用

(4)测试

一、Kerberos协议

在学习黄金白银票据前，首先的了解一下什么是Kerberos认证

Kerberos是一种由MIT（麻省理工大学）提出的一种网络身份验证协议。它旨在通过使用密钥加密技术为客户端/服务器应用程序提供强身份验证。

在 Kerberos 认证中，最主要的问题是如何证明「你是你」的问题，如当一个 Client 去访问 Server 服务器上的某服务时，Server 如何判断 Client 是否有权限来访问自己主机上的服务，同时保证在这个过程中的通讯内容即使被拦截或篡改也不影响通讯的安全性，这正是 Kerberos 解决的问题。在域渗透过程中 Kerberos 协议的攻防也是很重要的存在。

Kerberos 主要是用在域环境下的身份认证协议。

内网渗透-Windows域环境的初识与搭建_域的登录模式和过程-CSDN博客

在Kerberos协议中主要是有三个角色的存在：

访问服务的客户端：Kerberos客户端是代表需要访问资源的用户进行操作的应用程序，例如打开文件、查询数据库或打印文档。每个Kerberos客户端在访问资源之前都会请求身份验证。
提供服务的服务端：域内提供服务的服务端，服务端都有一个独一的SPN。
‍提供认证服务的KDC(Key Distribution Center，密钥分发中心)：KDC密钥发行中心是一种网络服务，它向活动目录域内的用户和计算机提供会话票据和临时会话密钥，其服务帐户为krbtgt。KDC作为活动目录域服务ADDS的一部分运行在每个域控制器上。这里说一下krbtgt帐户，该用户是在创建活动目录时系统自动创建的一个账号，其作用是KDC密钥发行中心的服务账号，其密码是系统随机生成的，无法正常登陆主机。在后面的域学习中，会经常和krbtgt帐户打交道，关于该帐户的其他信息会在后面的文章中详细讲解。

其中KDC服务默认会安装在一个域的域控中，而Client和Server为域内的用户或者是服务，如HTTP服务，SQL服务。在Kerberos中Client是否有权限访问Server端的服务由KDC发放的票据来决定。

kerberos的简化认证认证过程如下图

AS_REQ: Client向KDC发起AS_REQ,请求凭据是Client hash加密的时间戳
AS_REP: KDC使用Client hash进行解密，如果结果正确就返回用krbtgt hash加密的TGT票据，TGT里面包含PAC,PAC包含Client的sid，Client所在的组。
TGS_REQ: Client凭借TGT票据向KDC发起针对特定服务的TGS_REQ请求
TGS_REP: KDC使用krbtgt hash进行解密，如果结果正确，就返回用服务hash 加密的TGS票据(这一步不管用户有没有访问服务的权限，只要TGT正确，就返回TGS票据)
AP_REQ: Client拿着TGS票据去请求服务
AP_REP: 服务使用自己的hash解密TGS票据。如果解密正确，就拿着PAC去KDC那边问Client有没有访问权限，域控解密PAC。获取Client的sid，以及所在的组，再根据该服务的ACL，判断Client是否有访问服务的权限。

（通俗版）Kerberos是一种基于票据Ticket的认证方式。客户端想要访问服务端的某个服务，首先需要购买服务端认可的 ST服务票据(Service Ticket)。也就是说，客户端在访问服务之前需要先买好票，等待服务验票之后才能访问。但是这张票并不能直接购买，需要一张 TGT认购权证（Ticket Granting Ticket)。也就是说，客户端在买票之前必须先获得一张TGT认购权证。TGT认购权证 和 ST服务票据 均是由KDC(密钥分发中心)发放；因为KDC是运行在域控制器上，所以说TGT认购权证和ST服务票据均是由域控发放。

Kerberos协议其中有两个基础认证模块：AS_REQ & AS_REP 和 TGS_REQ & TGS_REP ，以及微软扩展的两个认证模块 S4U 和 PAC 。S4U是微软为了实现委派而扩展的模块，分为 S4U2Self 和 S4U2Proxy 。在Kerberos最初设计的流程里只说明了如何证明客户端的真实身份，但是并没有说明客户端是否有权限访问该服务，因为在域中不同权限的用户能够访问的资源是不同的。因此微软为了解决权限这个问题，引入了 PAC (Privilege Attribute Certificate，特权属性证书) 的概念。

二、下面我们来具体分析Kerberos认证流程的每个步骤：

AS-REQ & AS-REP

如图所示，是一个简易的AS-REQ&AS-REP请求过程图，便于我们直观的了解AS-REQ&AS-REP请求过程。

1、KRB_AS-REQ请求包分析

Client->AS：Client 先向 KDC 的 AS 发送 pA-ENC-TIMESTAMP（内容为Client hash加密的时间戳）

AS-REQ：当域内某个用户想要访问域内某个服务时，于是输入用户名和密码，本机就会向KDC的AS认证服务发送一个AS-REQ认证请求。该请求包中包含如下信息：

· 请求的用户名(cname)。

· 域名(realm)。

· Authenticator：一个抽象的概念，代表一个验证。这里是用户密钥加密的时间戳。

· 请求的服务名(sname)：AS-REQ这个阶段请求的服务都是krbtgt。

· 加密类型(etype)。

· 以及一些其他信息：如版本号，消息类型，票据有效时间，是否包含PAC，协商选项等。

用户向KDC发起AS_REQ,请求凭据是用户 hash加密的时间戳。请求凭据放在PA_DATA里面

在AS_REQ阶段主要用到的有两个

PA-ENC-TIMESTAMP

PA-DATA PA-ENC-TIMESTAMP：这个是预认证，就是用用户Hash加密时间戳，作为value发送给KDC的AS服务。然后KDC从活动目录中查询出用户的hash，使用用户Hash进行解密，获得时间戳，如果能解密，且时间戳在一定的范围内，则证明认证通过。由于是使用用户密码Hash加密的时间戳，所以也就造成了哈希传递攻击
PA_PAC_REQUEST

这个是启用PAC支持的扩展。PAC并不在原生的kerberos里面，是微软引进的扩展。详细的内容之后将有一篇文章详细介绍PAC。PAC包含在AS_REQ的响应body(AS_REP)。这里的value对应的是include=true或者include=false(KDC根据include的值来判断返回的票据中是否携带PAC)。

2、 KRB_AS_REP回复包分析：

AS->Client：AS根据用户名在AD中寻找是否在AD数据库中，然后根据Client的用户名提取到对应的Hash，接着pA-ENC-TIMESTAMP用对应Client用户名的Hash进行解密，如果结果正确则会返回如下：

1、返回当前KDC中krbtgt hash加密的TGT票据（TGT包含PAC，PAC包含Client的sid，Client所在的组），在通信数据包中显示的就是ticket字段

2、Authentication Service会生成一个随机数Session key（这个非常重要，作为kerberos中下一轮的认证密钥），返回给Client由Client的HASH加密的enc-part字段

KDC的AS认证服务在成功认证客户端的身份之后，发送AS-REP响应包给客户端。AS-REP响应包中主要包括如下信息：

· 请求的用户名(cname)。

· 域名(crealm)。

· TGT认购权证：包含明文的版本号，域名，请求的服务名，以及加密部分enc-part。加密部分用krbtgt密钥加密。加密部分包含Logon Session Key、用户名、域名、认证时间、认证到期时间和authorization-data。authorization-data中包含最重要的PAC特权属性证书(包含用户的RID，用户所在组的RID) 等。

· enc_Logon Session Key：使用用户密钥加密Logon Session Key后的值，其作用是用于确保客户端和KDC下阶段之间通信安全。也就是AS-REP中最外层的enc-part。

· 以及一些其他信息：如版本号，消息类型等。

TGT认购权证

AS-REP响应包中的ticket便是TGT认购权证了。TGT认购权证中包含一些明文显示的信息，如版本号tkt-vno、域名realm、请求的服务名sname。但是TGT认购权证中最重要的还是加密部分，加密部分是使用krbtgt帐户密钥加密的。加密部分主要包含的内容有Logon Session Key、请求的用户名cname、域名crealm、认证时间authtime、认证到期时间endtime、authorization-data等信息。

最重要的还是authorization-data部分，这部分中包含客户端的身份权限等信息，这些信息包含在PAC中。

KDC生成PAC的过程如下：KDC在收到客户端发来的AS-REQ请求后，从请求中取出cname字段，然后查询活动目录数据库，找到sAMAccountName属性为cname字段的值的用户，用该用户的身份生成一个对应的PAC。

Logon Session Key

AS-REP响应包最外层的那部分便是加密的Login session Key了，其作用是用于确保客户端和KDC下阶段之间通信安全，它使用请求的用户密钥加密。

我们对最外层的enc-part部分进行解密，就可以看到是使用hack用户的密钥对其进行解密的。

解密结果如下：主要包含的内容是认证时间authtime、认证到期时间endtime、域名srealm、请求的服务名sname、协商标志flags等一些信息。需要说明的是，在TGT认购权证中也包含Logon Session Key ，作为下阶段的认证密钥。

ticket

这个ticket用于TGS_REQ的认证。是加密的，用户不可读取里面的内容。在AS_REQ请求里面是，是使用krbtgt的hash进行加密的，因此如果我们拥有krbtgt的hash就可以自己制作一个ticket，既黄金票据。

3、然后继续来讲相关的TGS的认证过程

KRB_TGS_REQ(请求)：

Client 接收到了加密后的ticket(TGT) 和 enc-part 之后，先对enc-part用自身密码HASH解密得到Session key，也就是上文中说的随机生成的Session key。

TGT是由KDC中krbtgt的Hash加密，所以Client 无法解密。

这时 Client 继续再用Session key加密的TimeStamp（authenticator，然后再和ticket(TGT) 一起发送给 KDC 中的 TGS（TicketGranting Server）票据授权服务器换取能够访问 Server 的票据。

然后这里面的ticket其实还是我们的TGT票据，这里的enc-part不是上面说的enc-part，这里的enc-part(TGT)

KRB_TGS_REP(应答)：

TGS 收到 Client 发送过来的ticket(TGT) 和 Session key 加密TimeStamp的 authenticator 之后，首先会检查自身是否存在 Client 所请求的服务。如果服务存在，则用 krbtgt的HASH来解密ticket(TGT)。

一般情况下 TGS 会检查 TGT 中的时间戳查看 TGT 是否过期，且原始地址是否和 TGT 中保存的地址相同。

验证成功之后将返回Client两个东西，一个是用 Session key 加密的enc-part，然后另一个是 Client要访问的Server的密码 HASH 加密的 TGS票据（要访问服务端的Hash）生成就是ST（TGS）票据，那么此时的ticket就是TGS了

这个过程其实跟我们请求TGT是一样的，我就不讲了，你可以看到一个ticket(TGS)和一个enc-part

enc-part这个部分同样是可以解密的，原因就是这里enc-part加密用的密钥，实际上就是上一轮AS_REP里面返回的Session key，从开始到现在这里的Session key一直都是一样的，作为下一轮通信的认证密钥。

4、cilent访问服务端

KRB_AP_REQ(请求)：

到此，客户端就可以用 ST 来向服务端发出申请了。客户端向服务器发送类型为 KRB_AP_REQ 类型的消息

发送的信息有如下两个，其实就跟上面的流程一样了

1、一个新生成的 Authenticator，包括客户ID 和时间戳，由Session key进行加密

2、TGS(ST)

KRB_AP_REP(应答)：

服务端接收后，用自己的 Hash 解密 ST，获取会话密钥，解密获得 Authenticator，和ST中的信息对比，来确定用户的身份。确定身份后，就拿着PAC去KDC那边问Client有没有访问权限，域控解密PAC。获取Client的sid，以及所在的组，再根据该服务的ACL，判断Client是否有访问服务的权限，到此完成整个认证流程（大多数服务并没有验证PAC这一步）。

巴拉巴拉铺垫这莫多的知识点，我们俩来看一下黄金票据咋个弄：

三、黄金票据的原理和条件

1原理

黄金票据伪造的是票据授予票据(TGT)，TGT=krbtgt hash(session key,client info，end time)。TGT由AS返回给client，然后client用TGT来向TGS验证自己的身份，而client是不知道krbtgt hash的，只有AS与TGS知道krbtgt hash，所以要想伪造TGT就需要知道krbtgt hash。所以攻击者伪造黄金票据TGT的前提是获得管理员访问域控制器的权限并抓取到krbtgt hash。

而session key是由AS随机生成的，TGS在收到TGT之前并不知道，所以可以伪造。client info和end time也是可以自己定的。所以我们可以伪造由client发给TGS的TGS REQ，进而获得server ticket。

2条件

知道域名称、域SID值、krbtgt hash等。

3.黄金票据的局限性

在一个多域AD森林中，根域包含全森林管理组Enterprise Admins，而如果创建黄金票据的域不包含Enterprise Admins组，则黄金票据不会向林中的其他域提供管理权限，也就是说否则黄金票据不能跨域信任使用，标准的黄金票据仅限于其创建的子域。在单个域Active Directory林中，由于Enterprise Admins组会驻留在此域中，此时创建的黄金票据不存在上述局限性。

4.绕过黄金票据局限性

最新版本的Mimikatz支持将迁移域的SID历史记录添加到Enterprise Admins组的黄金票据中。这样，一旦某个域名的trbtgt hash被获取到，就可伪造用户登录到整个森林中的黄金票据，对AD森林中的任何域构成威胁。
而在Active Directory林中的信任之间启用SID筛选可以防止上述绕过黄金票据局限性的操作。

5.黄金票据的特点

（1） KDC中的TGS不通过读取AD来验证来自client的TGS REQ中的用户账户信息，知道TGT超过20分钟，这意味着攻击者可以使用禁用和删除帐户，甚至是在Active Directory中不存在的虚拟帐户。
（2）由于Kerberos的策略是由DC上的KDC设置的，所以如果提供票据，则系统就会信任票据的有效性。也就是说，即使域策略声明TGT只有10小时有效，但将TGT中声明的有效期改为10 年，那信任票据的有效性期会成为10年而不是10小时。
（3）绕过了SmartCard身份验证要求，因为它绕过了DC在创建TGT之前执行的常规验证。
（4）要求攻击者拥有Active Directory域的KRBTGT密码哈希值，从而伪造TGT。
（5） Krbtgt hash可用于生成一个有效的TGT（使用RC4），模拟任何用户访问Active Directory中的任何资源。
（6）只要网络可以访问域，即使没有加入域，在主机上也可以生成和使用黄金票据。

6.黄金票据防御

（1）限制域管理员登录到除域控制器和少数管理服务器以外的任何其他计算机，将所有其他权限委派给自定义管理员组。这可以降低攻击者访问域控制器的Active Directory的ntds.dit文件。而如果攻击者无法访问AD数据库（ntds.dit文件），则其无法获取到krbtgt hash。
（2）增加更改krbtgt账户的密码的频率。

四、实践

首先假设拿到了域控，然后从域控来导出hash，之后再进行TGT伪造的操作。
在域控下执行mimikatz命令：

（1）权限提升：privilege::debug

（2）获得krbtgt账户的SID 、krbtgt:hash

回到client，执行mimikatz命令：

lsadump::dcsync /domain /user:krbtgt /csv

(3)生成票据并利用

mimikatz "kerberos::golden /domain:<域名> /sid:<域SID> /aes256:<aes256_hmac> /user:<任意用户名>

(4)测试

拿到TGT就可以请求任何服务的权限，所以就不需要再单独指定需要哪一个服务了，只要目标服务支持Kerberos认证我们就可以进行访问，而且是具有一定的权限的。此处直接将票据导入内存，也可以将票据存到文件中然后在需要使用的时候再导入到内存中。

在cmd中使用klist命令可以查看当前票据，这个时候我们就可以访问文件共享等服务了。

这里有个思考题，其实我们都拿到了域控的账号和密码，为什么还要写黄金票据，请参考文章：

《内网安全攻防：渗透测试实战指南》读书笔记（八）：权限维持分析及防御_内网安全攻防:渗透测试实战指南》读书笔记-CSDN博客