Kerberos域身份验证机制的分析

kerberos概念

Kerberos是一种网络身份验证协议，旨在通过密钥系统为客户端/服务器应用程序提供强大的身份验证服务。此身份验证过程的实现不依赖于主机操作系统的身份验证，不需要基于主机地址的信任，不需要网络上所有主机的物理安全性，并且假设可以任意读取，修改和插入网络上传输的数据包。

在上述情况下，Kerberos作为可信赖的第三方身份验证服务，通过传统的加密技术（例如:共享密钥）执行身份验证服务。

涉及域身份验证的角色

Kerberos的徽标是三个狗头，狗头代表以下三个字符

客户访问服务

提供服务的服务器

KDC（密钥配送中心）钥匙配送中心Kerberos测试工具简介

KDC服务默认情况下将在域中安装在域控件中，而客户端和服务器是域内的用户或服务，例如HTTP服务和SQL服务。客户是否有权访问Kerberos的服务器服务，取决于KDC（密钥配电中心）发行的收据。

Kerberos认证协议

TGT（票票）

身份身份验证服务授予的门票为（身份验证服务）。 TGT用于身份认证，并存储在内存中。默认有效期为10小时。门票可以通过TGT获得。 TGT是临时证书，伪造的TGT也称为金笔记。

比尔（服务器票/票）

是网络对象相互访问的凭据，伪造的ST \票证也称为银账单。

KDC（密钥配电中心）

负责管理票据，认证票据和分发票据，但KDC不是独立服务，它由以下服务组成：

AS（身份验证服务）:身份身份验证服务，为客户生成TGT（授予票务）服务。

TGS（授予服务机票）:票务授予服务，为客户的票务生成服务。

ad（帐户数据库）

一个类似于本机SAM的数据库，该数据库存储了所有客户的白名单。只有白名单上存在的客户才能成功申请TGT。

※补充：从物理角度来看，AD和KDC都是域控制器（域控制器）。

粗域身份验证过程

该过程的简要说明

①-②：来自Kerberos服务的客户请求，希望获得访问服务器的许可。当Kerberos收到这个消息时，他必须首先确定客户是否值得信赖，这是白名单黑名单的说法。

这就是AS（身份验证服务）服务所做的，通过在AD（帐户数据库）中存储黑名单和白名单来区分客户。

成功后，AS（身份验证服务）将TGT（授予票证票）返回客户。

③-④：客户端获得TGT（授予票证票）后，它继续向Kerberos请求，希望获得访问服务器的许可。 Kerberos再次收到了此消息。目前，通过客户端消息中的TGT，确定客户端已有此许可，并授予客户端访问服务器机票的权限。

⑤-⑥：客户端获得机票后，他最终可以成功访问服务器。该票仅适用于该服务器，其他服务器需要应用于TGS（授予服务票）。

详细描述

AS_REQ:客户端启动AS_REQ至KDC，请求凭据是客户端哈希加密的时间戳

AS_REP: KDC使用客户端进行解密。如果结果正确，它将返回使用KRBTGT哈希加密的TGT票。 TGT包含PAC，PAC包含用户客户端和用户客户端所在的组的SID。

TGS_REQ:客户端启动了带有TGT票证的特定服务器的TGS_REQ请求

TGS_REP: KDC使用KRBTGT哈希进行解密。如果结果正确，它将返回使用服务器哈希加密的TGS票证[票证]（此步骤无关紧要，如果用户是否可以访问服务器，只要TGT正确，它就会返回TGS Ticket [Ticket]）

AP_REQ:客户端将TGS票（票）带到请求服务器

AP_REP:服务器使用自己的哈希人解密TGS门票（门票）。如果解密是正确的，请将PAC带到KDC并询问客户是否具有访问权限，并且域控制将解密PAC。获取客户端的SID及其所在的组，然后确定客户端是否有权根据服务的ACL访问服务器。

域身份验证的详细过程

as_req as_rep

as_req

123456781。PVNOKERBEROS版本编号2。MSG型类型，AS_REQ对应于KRB_AS_REQ（0x0A）3。 PA_DATA主要指一些身份验证信息。一个包含几个用于身份验证的身份验证消息的列表，我们也可以身份验证器。每个身份验证消息都有类型和值。 4。req_bodykdc-options某些标志字段

as_rep

123456789101。msg-typeas_req的响应主体对应于krb_as_rep（0x0b）2。 Crealm域名3。CNAME用户名4。票务此票用于TGS_REQ身份验证。它是加密的，用户无法阅读。在AS_REQ请求中，使用KRBTGT哈希进行加密。因此，如果我们有Krbtgt的哈希，我们可以自己制作一张票，这是一张金色的票据。有关详细信息，请参阅相关的安全问题5。可以解密ENC_PART的这一部分。关键是用户哈希。解密后，获得加密键。加密中最重要的字段是会话密钥，该键用作下一阶段的身份验证密钥。

TGS_REQ TGS_REP

tgs_req

1234567891111。对于味精类型，TGS_REQ对应于KRB_TGS_REQ（0x0C）2。 PA-DATA普通TGS_REQ请求要求AP_REQ：这是必须携带TGS_REQ的部分。该部分将携带在AS_REP中获得的TGT票，并将其放置在此结构中。 KDC检查了TGT法案，如果账单正确，则返回TGS法案。 PA_FOR_USER：类型为S4U2Self，该值是指示用户身份的唯一标识符。这个唯一的标识符由用户名和域名组成。 S4U2Proxy必须扩展PA_FOR_USER结构，并指定服务代表用户（图片是管理员）来请求服务本身的Kerberos服务票。 PA_PAC_OPTIONS：值是以下标志声明（0），分支识别（1），转发到完整DC（2），基于资源的约束委托（3）的组合。 Microsoft的MS-SFU 2.2.5，S4U2Proxy必须扩展PA-PAC-OPTIONS结构。如果是基于资源的约束委托，则需要指定基于资源的约束委托位。 3。req_bodysname：这是要请求的服务。 TGS_REP获得的票证使用服务用户的哈希（Hash）进行加密。有一个更有趣的功能，如果指定的服务是KRBTGT，则可以将您获得的TGS账单用作TGT账单。 addtionticket：附件。在S4U2Proxy请求中，需要两个正常的TGT，并且需要在S4U2自行阶段获得的TG。然后将此TGS添加到addtionticket中。

tgs_rep

1234561。MSG-TYPEAS_REQ的响应主体对应于KRB_TGS_REQ（0x0d）2。票证用于AP_REQ身份验证。

内部的enc_part被加密，用户无法读取内部内容。在AS_REQ请求中，使用KRBTGT哈希进行加密，而在TGS_REQ中，它是使用要请求的服务哈希进行加密的。因此，如果我们拥有服务的哈希，我们可以自己制作一张票，这是银笔记。有关详细信息，请参阅相关的安全问题银法案。由于使用要请求的服务的哈希进行了加密，因此我们可以通过爆炸enc_part获得服务的哈希。有关详细信息，请参阅相关的安全问题Kerberoasting。 3。ENC_PART请注意，此ENC_PART不是票证中的enc_part，可以解密其中的一部分。关键是session_key在上一轮AS_REP中返回，即导入凭据中的session_key。解密后，获得加密密钥。加密密钥结构中最重要的字段也是session_key（但是此session_key与上一轮中的session_key不同），并用作下一阶段的身份验证密钥。

s4u2self

S4U2自己的过程如下图所示（先决条件是该服务已经具有通过KDC验证的TGT）

S4U2自己使服务能够代表用户获得服务本身的Kerberos服务门票。这允许服务获得用户的授权（可转发用户TGS票证），然后将其用于以后的身份验证（主要是稍后的S4U2Proxy），当用户在不使用Kerberos的情况下对服务进行身份验证时，该验证供您使用。这里非常重要的一点是，该服务代表用户获得服务本身的Kerberos门票。该服务不需要用户凭据。

s4u2proxy

S4U2Proxy的过程如下图所示

S4U2Proxy使服务1能够使用用户的授权（在S4U2自行阶段获得），然后使用此TGS（放置在addTionTicket中）来请求KDC的TGS访问服务2，并代表用户访问服务2，并且只能访问服务2。

委托

当Windows 2000服务器首次发布Active Directory时，Microsoft必须提供一种简单的机制来支持一个方案，其中用户通过Kerberos通过Kerberos对Web服务器进行身份验证，并且需要代表该用户在后端数据库服务器上更新记录。这通常称为“ Kerberos双跳问题”，需要委托，以便Web服务器在修改数据库记录时模拟用户。

要注意的一件事是，接受委托的用户只能是服务帐户或计算机用户。

无约束委托

示例：

服务（例如Jackson-PC $）配置为无限制的委托，因此Jackson-PC $可以接受任何用户的委派来请求所有其他服务。协议级别的实现是，如果用户委托Jackson-PC $访问某个服务，则用户将将TGT（In TGS）发送到Jackson-PC $，并将其缓存到LSASS，以方便将来使用。然后，Jackson-PC $模拟用户请求特定服务。

具有非受限委托的用户的用户accountControl属性具有标志位。 TrustedfordElegation。可以在转换AD AD USERACCOUNTCONTROL属性值中找到UserAccountControl位的含义（我们还将在LDAP文章中详细介绍它）。相应的trusted_for_delegation为0x80000，为524288。

约束委托

Microsoft很早就意识到，在Windows 2003上，无约束的委派不是特别安全，并发布了“约束”委派。

这包括一组Kerberos协议扩展，这是本文前面提到的S4U2Self和S4U2Proxy的两个扩展。配置后，受约束的委托将限制指定服务器可以代表用户执行的服务。这需要可见的元素特权（敏感，通常仅授予域管理员）才能配置服务域帐户并将帐户限制为单个域。

例子：

计算机用户（即Jackson-PC $）配置为有限的委托，因此Jackson-PC $可以接受任何用户的委派来请求特定服务。特定过程是，在收到用户的请求后，它首先代表用户获得了服务本身的透明kerberos服务票（S4U2Self），并请求KDC从KDC中访问特定的服务的可转发TGS（s4u2proxy），从KDC中访问特定的服务，并且只能访问特定的用户和特定服务的特定服务。

与无限制的委托相比，约束授权之间的最大差异是在配置时选择特定的服务，而不是所有服务。

配置为限制委托的UseraccountControl的用户AccountControl属性具有标志位可信度AauthfordElegation。关于对应于用户accountControl的每个位的含义，您可以看到转换AD AD USERACCOUNTCONTROL属性值，其中Trusted_to_to_auth_for_delegation对应于0x1000000，即167777216。

基于资源的约束委托

为了配置受约束的委托，您必须具有SigeAbledeleagelegation特权（此特权是敏感的，通常仅授予域管理员）。为了使用户/资源更加独立，在Windows Server 2012中引入了基于资源的约束委托。基于资源的约束委托允许将资源配置信任的帐户委派给他们。基于资源的约束代表团将委派控件交给拥有访问资源的管理员。

基于资源的约束委托只能在运行Windows Server 2012 R2和Windows Server 2012的域控制器上配置，但可以在混合模式森林中应用。这种约束委托的样式与传统约束委托非常相似，但具有相反的配置。

传统约束代表团在MSDS-AllowDodelegateTo属性中的帐户A上配置，并定义了从A到B的“传出”信任。

基于资源的约束委托委托在s-woldedtoactonbehalfofofofrofoffofrofentity属性中的帐户B上配置，并定义了从A到B的“传入”信任。

PAC

Microsoft引入的访问控制引入的扩展PAC。历史上已经看到了一个严重的漏洞，使普通用户可以晋升为域管理MS14068。

kerberos过程引入PAC

用户将AS_REQ启动到KDC，并且请求凭据是用户哈希加密的时间戳。 KDC使用用户哈希解密。如果结果是正确的，则返回使用KRBTGT哈希加密的TGT票证。 TGT包含PAC，PAC包含用户的SID和用户所在的组。

用户使用TGT启动了针对KDC的特定服务的TGS_REQ请求。 KDC使用KRBTGT哈希进行解密。 If the result is correct, it returns the ST\Ticket encrypted with the service hash (this step does not matter whether the user has access to the service or not, as long as the TGT is correct, it returns the ST\Ticket. This is also the reason why kerberoating can use: any user, as long as the hash is correct, can request the ST\Ticket of any service in the domain. For details, please refer to the Windows Intranet Protocol to learn the TGSREQ TGSREP在Kerberos文章中）

用户将ST \ Ticke索取服务，该服务使用自己的哈希解密ST \ Ticke。如果解密是正确的，请将PAC带到KDC，询问用户是否具有访问权限，并且域控制解密PAC。获取用户的SID和用户所在的组，然后确定用户是否有权访问服务。如果有访问权限，将允许用户访问用户（如果有用户哈希，您可以制作st \ ticket，但是您无法制作PAC，而PAC自然无法验证PAC，但是有些服务不能验证PAC，这是银账单成功的先决条件）。

尤其指出的是，在整个过程中，PAC对用户和服务都是看不见的。只有KDC可以制作和查看PAC。

相关的安全问题

as_req as_rep

pth \ ptk

连接到配置时，允许您使用哈希进行身份验证。不仅可以对帐户和密码进行身份验证。

由于在身份验证时使用用户哈希对时间戳进行加密，因此在使用密码登录时，您应首先将密码加密到验证之前。

因此，如果只有用户哈希，并且没有明确的文本密码，也可以执行身份验证。

无论是Rubeus还是Impacket，相关脚本都支持直接使用哈希进行身份验证。

12如果哈希是ntlm哈希，然后加密方法为rc4，如果哈希是aes键（使用sekurlsa:ekeys导出，则可以完成，即使在许多地方传递键并且不支持rc4 Encryptight方法，也可以使用键是一个好方法，即使键在许多地方传递。

用户名枚举

如果域中没有域帐户，则列举用户名

如果您有一个域帐户，则可以直接通过LDAP查询（在域机器提及系统权限之后，其机器帐户也是一个域帐户）

执行AS_REQ时，用户名存在，但是密码错误与用户名中不存在的相应软件包不同。通过此比较，您可以编写一个脚本来更改用户名枚举的cname值（https://daiker.gitbook.io/windows-protocol/kerberos/kerberos/1#2.-yong-hu-ming-ming-mei-ju）。

密码喷涂（密码喷涂）

当您已经拥有用户名时，您可以尝试破坏密码。

执行AS_REQ时，存在用户名，并且密码正确，并且存在带有用户名的相应软件包，但密码不正确。

在实际战斗中，“密码喷涂”技术将用于测试和攻击。由于对同一用户的连续密码猜测会导致帐户被锁定，因此只指定了一个唯一的密码，供所有用户同时登录，从而消除了锁定帐户的概率并提高了开裂的成功率。

AS-REPROASTING（用户明文密码爆炸）

用于域用户，该选项不需要Kerberos预先验证（不需要Kerberos预先验证）

目前，将AS_REQ请求发送到域控制器端口88，并重新组合接收到的AS_REP内容（encpart下的CIPER，因为此部分是使用用户哈希加密的会话- 我们可以通过执行离线爆炸来获得用户哈希，可以将其插入“ Kerberos 5 as-rep eType eType exy expy）中，并将其插入。您可以使用HashCat破解它，并最终获取用户的明文密码。

金笔记

确认客户端登录器的用户身份。通过锻造的TGT，您可以获取对由Krbtgt NTLM哈希加密的任何Kerberos的访问权限。

伪造条件

12341，域名2，域SID值3，域KRBTGT帐户哈希（意味着您已经具有域控制器权限）4。伪造任何用户名，可以是任意的。 In Kerberos authentication, after the Client passes AS (Authentication Service) authentication, the AS will give the Client a Logon Session Key and TGT, and the Logon Session Key will not be saved in KDC, and the NTLM Hash of krbtgt is fixed (this account generally does not change the password), so as long as you get the NTLM Hash of krbtgt, you can forge TGT and Logon Session Key to enter客户端和TGS之间互动的下一步。

获得金票后，您可以跳过验证并直接与KDC进行互动，而无需验证您的帐户和密码，因此您不必担心修改域密码。

TGS_REQ TGS_REP

PTT（通过票证）

kerbreos除了第一步AS_ERQ外，使用时间戳对用户哈希进行加密，其他步骤的验证是通过票证，可以是TGT（票证授予票证）或TGS票务（服务器票证/票证/票）。由于账单中的内容主要是Session_Key和票证（使用服务哈希进行加密，并且该服务包括KRBTGT），因此我们可以在下一阶段使用该账单作为验证。

kerberosting（服务哈希爆炸）

，因为tgs_rep中的票证中的enc_part（票证中的enc_part，而不是最外部的en