内网渗透测试：Kerberos 协议& Kerberos 认证原理

前言

如果你了解内网渗透，那么应该都对 IPC、黄金票据、白银票据、PTT、PTK
这些老生常谈的词汇再熟悉不过了，对其利用也应该是了如指掌了吧。但是如果你对其背后的所使用的原理还不太了解的话，那么这篇（系列）文章你一定不能错过。

在本篇文章中，我们将对 Kerberos 协议与 Kerberos 认证原理分模块进行详细的讲解，为下篇文章中讲解 Kerberos
认证原理的安全问题做下铺垫。

文中若有不当之处，还请各位大佬师傅们多多点评。

我的博客：https://whoamianony.top/

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 认证原理

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

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-OWjx8DIw-1692510457220)(https://image.3001.net/images/20210520/1621493474_60a606e26cf44ee31f36a.png!small)]

1. 首先 Client 向域控制器 DC 请求访问 Server，DC 通过去 AD 活动目录中查找依次区分 Client 来判断 Client 是否可信。

2. 认证通过后返回 TGT 给 Client，Client 得到 TGT（Ticket Granting Ticket）。

3. Client 继续拿着 TGT 请求 DC 访问 Server，TGS 通过 Client 消息中的 TGT，判断 Client 是否有访问权限。

4. 如果有，则给 Client 有访问 Server 的权限 Ticket，也叫 ST（Service Ticket）。

5. Client 得到 Ticket 后，再去访问 Server，且该 Ticket 只针对这一个 Server 有效。

6. 最终 Server 和 Client 建立通信。

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

• AS_REQ & AS_REP

• TGS_REQ & TGS_REP

• AP-REQ & AP-REP

AS_REQ & AS_REP

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

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-uoUepIBa-1692510457223)(https://image.3001.net/images/20210520/1621493474_60a606e2c71b0cff80e5e.png!small)]

当域内某个客户端用户 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-key AS、时间戳、Client-info
进行的加密。这个特定账户就是创建域控时自动生成的 Krbtgt 用户，然后将这两部分以及 PAC 等信息回复给 Client，即AS_REP。PAC
中包含的是用户的 SID、用户所在的组等一些信息。

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

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

TGS_REQ & TGS_REP

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

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-fUBwrHbg-1692510457225)(https://image.3001.net/images/20210520/1621493475_60a606e34f6d9dde0472a.png!small)]

客户端 Client 收到 AS 的回复AS_REP后分别获得了 TGT 和加密的 Session-Key AS。它会先用自己的 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 的认证，通过认证的客户端将与服务器建立连接。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-BsoK6vs6-1692510457227)(https://image.3001.net/images/20210520/1621493475_60a606e3b3a9ac3f10ea8.png!small)]

客户端 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 Attribute
Certificate）这个东西，这是微软为了访问控制而引进的一个扩展，即特权访问证书。

在上面的认证流程中，如果没有 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，这是白银票据成功的前提。

Kerberos 认证中的相关安全问题概述

Kerberos 认证并不是天衣无缝的，这其中也会有各种漏洞能够被我们利用，比如我们常说的
MS14-068、黄金票据、白银票据等就是基于Kerberos协议进行攻击的。下面我们便来大致介绍一下Kerberos 认证中的相关安全问题。

黄金票据（Golden ticket）

在 Windows 的kerberos认证过程中，Client 将自己的信息发送给 KDC，然后 KDC 使用 Krbtgt 用户的 NTLM-Hash
作为密钥进行加密，生成 TGT。那么如果获取到了 Krbtgt 的 NTLM-Hash 值，不就可以伪造任意的 TGT 了吗。因为 Krbtgt
只有域控制器上面才有，所以使用黄金凭据意味着你之前拿到过域控制器的权限，黄金凭据可以理解为一个后门。

先假设这么一种情况，原先已拿到的域内所有的账户 Hash，包括 Krbtgt
这个账户，由于有些原因导致你对域管权限丢失，但好在你还有一个普通域用户权限，碰巧管理员在域内加固时忘记重置 Krbtgt
密码，基于此条件，我们还能利用该票据重新获得域管理员权限。利用 Krbtgt 的 Hash 值可以伪造生成任意的
TGT，能够绕过对任意用户的账号策略，让用户成为任意组的成员，可用于 Kerberos 认证的任何服务。

白银票据（Silver ticket）

白银票据不同于黄金票据，白银票据的利用过程是伪造 TGS，通过已知的授权服务密码生成一张可以访问该服务的 TGT。因为在票据生成过程中不需要使用
KDC，所以可以绕过域控制器，很少留下日志。而黄金票据在利用过程中由 KDC 颁发 TGT，并且在生成伪造的 TGT 得 20 分钟内，TGS不会对该
TGT 的真伪进行效验。

白银票据依赖于服务账号的密码散列值，这不同于黄金票据利用需要使用 Krbtgt 账号的密码哈希值，因此更加隐蔽。

MS14-068

这里便用到了我们之前所讲到的 PAC 这个东西，PAC 是用来验证 Client 的访问权限的，它会被放在 TGT 里发送给 Client，然后由
Client 发送给 TGS。但也恰恰是这个 PAC 造成了MS14-068这个漏洞。

该漏洞是位于 kdcsvc.dll 域控制器的密钥分发中心（KDC）服务中的 Windows 漏洞，它允许经过身份验证的用户在其获得的票证 TGT
中插入任意的 PAC 。普通用户可以通过呈现具有改变了 PAC 的 TGT 来伪造票据获得管理员权限。

密码喷洒攻击（Password Spraying）

在实际渗透中，许多渗透测试人员和攻击者通常都会使用一种被称为 “密码喷洒”（Password
Spraying）的技术来进行测试和攻击。对密码进行喷洒式的攻击，这个叫法很形象，因为它属于自动化密码猜测的一种。这种针对所有用户的自动密码猜测通常是为了避免帐户被锁定，因为针对同一个用户的连续密码猜测会导致帐户被锁定。所以只有对所有用户同时执行特定的密码登录尝试，才能增加破解的概率，消除帐户被锁定的概率。普通的爆破就是用户名固定，爆破密码，但是密码喷洒，是用固定的密码去跑用户名。

AS-REP Roasting

我们前文说过，AS_REQ & AS_REP 认证的过程是 Kerberos
身份认证的第一步，该过程又被称为预身份验证。预身份验证主要是为了防止密码脱机爆破。

而如果域用户设置了选项 “Do not require Kerberos
preauthentication”（该选项默认没有开启）关闭了预身份验证的话，攻击者可以使用指定的用户去请求票据，向域控制器发送AS_REQ请求，此时域控会不作任何验证便将
TGT 票据和加密的 Session-key 等信息返回。因此攻击者就可以对获取到的加密 Session-key
进行离线破解，如果爆破成功，就能得到该指定用户的明文密码。

这种攻击方式被称作 AS-REP Roasting 攻击。

Ending…

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ZI13xKlU-1692510457230)(https://image.3001.net/images/20210520/1621493476_60a606e410268bbc024e4.jpg!small)]

本节中我们对 Kerberos 协议与 Kerberos 认证原理分模块进行详细的讲解。在下篇文章，我们将详细的讲解 Kerberos
认证原理的安全问题并演示相关的攻击研究。

文中若有不当之处，还请各位大佬师傅们多多点评。

参考：

https://daiker.gitbook.io/windows-protocol/kerberos/1#4-as-reproasting

https://daiker.gitbook.io/windows-protocol/kerberos/2#0x01-tgs_req

https://daiker.gitbook.io/windows-protocol/kerberos/3

https://www.jianshu.com/p/13758c310242

https://blog.csdn.net/qq_36119192/article/details/104731625

https://blog.csdn.net/qq_36119192/article/details/105088239

https://blog.csdn.net/qq_36119192/article/details/105076459

shu.com/p/13758c310242>

https://blog.csdn.net/qq_36119192/article/details/104731625

https://blog.csdn.net/qq_36119192/article/details/105088239

https://blog.csdn.net/qq_36119192/article/details/105076459

接下来我将给各位同学划分一张学习计划表！

学习计划

那么问题又来了，作为萌新小白，我应该先学什么，再学什么？
既然你都问的这么直白了，我就告诉你，零基础应该从什么开始学起：

阶段一：初级网络安全工程师

接下来我将给大家安排一个为期1个月的网络安全初级计划，当你学完后，你基本可以从事一份网络安全相关的工作，比如渗透测试、Web渗透、安全服务、安全分析等岗位；其中，如果你等保模块学的好，还可以从事等保工程师。

综合薪资区间6k~15k

1、网络安全理论知识（2天）
①了解行业相关背景，前景，确定发展方向。
②学习网络安全相关法律法规。
③网络安全运营的概念。
④等保简介、等保规定、流程和规范。（非常重要）

2、渗透测试基础（1周）
①渗透测试的流程、分类、标准
②信息收集技术：主动/被动信息搜集、Nmap工具、Google Hacking
③漏洞扫描、漏洞利用、原理，利用方法、工具（MSF）、绕过IDS和反病毒侦察
④主机攻防演练：MS17-010、MS08-067、MS10-046、MS12-20等

3、操作系统基础（1周）
①Windows系统常见功能和命令
②Kali Linux系统常见功能和命令
③操作系统安全（系统入侵排查/系统加固基础）

4、计算机网络基础（1周）
①计算机网络基础、协议和架构
②网络通信原理、OSI模型、数据转发流程
③常见协议解析（HTTP、TCP/IP、ARP等）
④网络攻击技术与网络安全防御技术
⑤Web漏洞原理与防御：主动/被动攻击、DDOS攻击、CVE漏洞复现

5、数据库基础操作（2天）
①数据库基础
②SQL语言基础
③数据库安全加固

6、Web渗透（1周）
①HTML、CSS和JavaScript简介
②OWASP Top10
③Web漏洞扫描工具
④Web渗透工具：Nmap、BurpSuite、SQLMap、其他（菜刀、漏扫等）

那么，到此为止，已经耗时1个月左右。你已经成功成为了一名“脚本小子”。那么你还想接着往下探索吗？

阶段二：中级or高级网络安全工程师（看自己能力）

综合薪资区间15k~30k

7、脚本编程学习（4周）
在网络安全领域。是否具备编程能力是“脚本小子”和真正网络安全工程师的本质区别。在实际的渗透测试过程中，面对复杂多变的网络环境，当常用工具不能满足实际需求的时候，往往需要对现有工具进行扩展，或者编写符合我们要求的工具、自动化脚本，这个时候就需要具备一定的编程能力。在分秒必争的CTF竞赛中，想要高效地使用自制的脚本工具来实现各种目的，更是需要拥有编程能力。

零基础入门的同学，我建议选择脚本语言Python/PHP/Go/Java中的一种，对常用库进行编程学习
搭建开发环境和选择IDE，PHP环境推荐Wamp和XAMPP，IDE强烈推荐Sublime；

Python编程学习，学习内容包含：语法、正则、文件、 网络、多线程等常用库，推荐《Python核心编程》，没必要看完

用Python编写漏洞的exp,然后写一个简单的网络爬虫

PHP基本语法学习并书写一个简单的博客系统

熟悉MVC架构，并试着学习一个PHP框架或者Python框架 (可选)

了解Bootstrap的布局或者CSS。

阶段三：顶级网络安全工程师

如果你对网络安全入门感兴趣，那么你需要的话可以点击这里👉网络安全重磅福利：入门&进阶全套282G学习资源包免费分享！

学习资料分享

当然，只给予计划不给予学习资料的行为无异于耍流氓，这里给大家整理了一份【282G】的网络安全工程师从入门到精通的学习资料包，可点击下方二维码链接领取哦。