介绍

Kerberos 协议里实现了几种委派，委派允许服务模拟客户端用户与第二个服务进行交互，并具有客户端本身的特权和权限。

委派分为：

• 无约束委派

• 约束委派

• RBCD（基于资源的约束委派）

在本文中将重点了解不同类型的委派是如何工作的，包括一些特殊情况。还将介绍一些可以利用这些机制来利用域中的权限提升或设置持久性的场景。

在开始解释之前，假设大家已经了解 Kerberos 的基本概念。但如果像 TGT、TGS、KDC 或 Golden ticket 这样的词听起来还不太熟的话，那么我建议大家先去阅读本系列的第一章“ kerberos工作原理 ” 或任何相关的 Kerberos 资料。

进入正题。

服务、用户和计算机

首先，因为 Kerberos 为用户提供了一种针对域的服务进行身份验证的方法，并且委派是关于与服务交互的用户，这些服务又与其他服务交互，因此逻辑的第一个步骤是提供服务的定义、用户和它们之间的联系。

用户

通过 Microsoft 官方文档我们得知；用户是由Active Directory 中的用户帐户（或其子类）表示的代理。在 Active Directory 域中，可以找到不同类型的用户帐户：

• 普通用户帐户，可能是：

• 由人用来执行他们的日常任务。

• 用于仅执行特定任务，例如执行备份恢复。

• 计算机帐户，由域中的机器使用。这些可以被我们识别，因为它们的名称在 Active Directory 数据库中以“$”结尾。

从 Active Directory 的角度来看，计算机是用户，更具体地说，计算机是用户的一个子类。

计算机账户：

服务

一个服务：

• 由 Active Directory 中的SPN（服务主体名称）标识，它表示服务的名称和类别、所有者和主机。
• 作为一个进程在计算机（服务的主机）中执行。但服务不一定要运行才能为其获取 TGS。
• 在域用户（服务的所有者）的上下文中执行。服务通常在其主机的计算机帐户的上下文中运行，但不一定每次都是这样的。
• 可以由域的许多用户（比如 Kerberos、LDAP、SMB 或 MSSQL）使用，并且任何域用户都可以获得域中任何服务的 TGS。

服务委派

• 仅当其所有者有权执行委派时，服务才能执行委派。换句话说，如果这个用户具有委派能力，则其所有服务（和进程）都具有委派能力。
• 当服务与 KDC 交互的时候，它具有其所有者用户的身份。因为 KDC 只关心与之交互的用户，而不是进程。所以这意味着属于同一用户的任何进程都可以在 Kerberos 中执行相同的操作，无论它是否是服务。

Anti-Delegation 措施

• 设置存储在用户帐户的 User-Account-Control 属性中的 NotDelegated（或 ADS_UF_NOT_DELEGATED）标志。此标志将禁用该帐户的任何类型的委派。默认情况下，没有域帐户设置此标志。
• 将用户添加到 Windows Server 2012 R2 中引入的 受保护用户组。默认情况下，该组没有成员。另外，受保护用户组的成员无法：
• 使用 NTLM 身份验证。
• 在 Kerberos 预身份验证中使用 DES 或 RC4 加密。
• 使用任何类型的 Kerberos 委派进行委派。
• 续订 Kerberos TGT 超过最初的寿命四小时。

在后面的内容中，我们将假设委派对于不受委派保护的用户是无效的，所以为了清晰起见，示例会避免这个。

Protected Users Security Group

无约束委派（Unconstrained Delegation）

无约束委派是最简单的委派类型，它允许服务无限制地模拟任何经过身份验证的用户。在这种类型的委派中，服务为客户端用户获取一个有效的 TGT，这相当于成为 Kerberos 世界中（以及域中）的那个用户。

该服务如何为客户端用户获取 TGT？：

客户端将 TGT 发送到服务。

当客户端用户为无约束委派活动的服务请求 TGS 时，KDC 在 TGS 中包含一个（客户端用户的）TGT。

具体来说，它包含在使用服务所有者密钥加密的票据的部分中，所以在接收到 TGS 后，它可以访问客户端 TGT。

KDC 如何知道何时将 TGT 包含在 TGS 中？：

如果为目标服务的所有者设置了 TrustedForDelegation（或ADS_UF_TRUSTED_FOR_DELEGATION）标志，KDC将包含TGT。此标志存储在Active Directory用户帐户的“用户帐户控制”属性中。

还要注意注意的是，为了修改用户的 TrustedForDelegation 标志，需要在域控制器上拥有SeEnableDelegationPrivilege权限。

如果委派的目标用户由于受保护用户组或 NotDelegate 标志而受到委派保护，则委派将不起作用。

SeEnableDelegationPrivilege 

示例：

下图展示了无约束委派中遵循的流程（为清晰起见，我们假设 User1 不受受保护用户或 NotDelegated 的委派保护，不然委派将失败）：

在这种情况下：

1. User1 为 UserZ 的 ServiceZ 请求一个TGS。
2. KDC 检查 UserZ 是否设置了 TrustedForDelegation 标志（是）。
3. KDC在 ServiceZ 的 TGS 中包含 User1 的 TGT 。
4. ServiceZ 接收包含 User1 的 TGT 的 TGS 并将其存储以供以后使用。

攻击者如何利用：

有几种可能的情况：

• 如果攻击者能够利用无约束委派来破坏托管服务的计算机，那么很有可能为这些服务的客户端找到 TGT。
• 如果攻击者能够破坏具有无约束委派权限的用户的帐户，则有可能从属于该用户的服务中获取 TGT。
• 在之前的任何一种情况下，如果攻击者可以说服特权帐户与其中一个“受控”服务进行交互，那么就有可能窃取其 TGT 并破坏域。
• 在拥有域控制权的情况下，持久化的一种方式可以是将无约束的委派授予我们控制的一组用户。

约束委派和 RBCD

除了无约束委派，还有两种委派：

• 约束委派

• RBCD（基于资源的约束委派）（在 Windows Server 2012 中引入）

在任何这些类型中，委派仅限于一些列入白名单的第三方服务。

Kerberos 如何创建服务白名单：

Kerberos 本身无法创建特殊票据来为特定的服务组实现委派。出于这个原因，微软实现了2个 Kerberos 扩展，允许它获得这种所需的行为：

• S4U2Proxy（用户代理服务）

• S4U2Self（用户自我服务）

S4U2代理：

什么是 S4U2Proxy？

S4U2Proxy 是一个扩展，它允许服务使用客户端用户发送的 TGS 来代表客户端用户从 KDC 为第三个服务获取新的 TGS。

KDC 如何知道用户/服务是否可以使用客户端的 TGS 为第三个服务订购 TGS ？

KDC 必须检查 2 个列表：

一方面，每个用户都有一个可以为哪些服务订购 TGS 的列表。此列表存储在用户帐户的 msDS-AllowedToDelegateTo 属性中。要修改此属性，需要在域控制器中具有 SeEnableDelegationPrivilege 权限。这是在约束委派中使用的列表。

另一方面，每个用户都有一个允许向TGS请求其任何服务的其他用户列表，此列表存储在 msDS-AllowedToActOnBehalfOfOtherIdentity 属性中。用户自己可以根据需要编辑自己的允许用户列表。这是 RBCD 中使用的列表。

所以 KDC 将检查以下条件以确定是否可以应用委派：

• 如果服务客户端不受委派保护（或受保护用户组的成员设置了 NotDelegated 标志），则 S4U2Proxy 将失败。
• 如果请求的服务在 msDS-AllowedToDelegateTo 中，则 KDC 将检查：
• 如果发送的TGS是可转发的（设置了 forwardable 标志），那么KDC将为请求的服务返回一个可转发的TGS（应用受约束的委派）。
• 否则 S4U2Proxy 将失败。
• 如果请求 TGS 的用户列在被请求的服务所有者帐户的 msDS-AllowedToActOnBehalfOfOtherIdentity 属性中，那么KDC将返回一个可转发的 TGS (应用RBCD)。 
• 否则 S4U2Proxy 将失败。

（ 在 RBCD 的情况下，发送的TGS不需要是可转发的 ）

TGS does not need to be forwardable

此外，如果用户可以为相同的目标服务应用约束委派和RBCD，则约束委派将优先；这意味着在这种情况下，如果发送的 TGS 无法转发，那么甚至不去尝试应用 RBCD, S4U2Proxy 就会失败。 

这里有一个奇怪的地方是 S4U2Proxy 返回的 TGS，始终是可转发的。

S4U2Proxy 在约束委派中的例子：

为了阐明 S4U2Proxy 的使用，示例展示了通过应用约束委派解决委派的情况（为清晰起见，我们假设 User1 不受受保护用户组或 NotDelegated 的委派保护，不然我们的委派将失败）：

在这个例子中：

1. User1 将 TGS 发送到 ServiceZ。

2. UserZ 拥有的 ServiceZ 使用此 TGS 代表 User1 向 KDC 请求 ServiceX 的 TGS 。

3. KDC 检查：

1. ServiceX 被列在 UserZ 中的 msDS-AllowedToDelegateTo 是否为 yes。

2. 发送的 TGS 是否是可转发的，若是，则可以应用约束委派。

4. KDC 向 ServiceZ 返回 TGS，以代表 User1 与 ServiceX 交互。

5. ServiceZ 通过模拟 User1 使用新的 TGS 与 ServiceX 交互。

S4U2Proxy 在RBCD中的例子：

为了阐明 S4U2Proxy 的使用，示例展示了通过应用 RBCD 解决委派的情况（为清晰起见，我们假设 User1 不受受保护用户组或 NotDelegated 的委派保护，不然我们的委派将失败）： 

在这个例子中：

1. User1将 TGS 发送到ServiceZ。
2. UserZ 拥有的 ServiceZ 使用此 TGS代表 User1向 KDC 请求ServiceX 的 TGS 。
3. KDC 检查：
1. ServiceX 被列在 UserZ 中的 msDS-AllowedToDelegateTo 是否为NO，若是，则不能应用受约束的委派。
2. 如果 UserZ 被列在 UserX 的 msDS-AllowedToActOnBehalfOfOtherIdentity 中，则成为 ServiceX 的所有者（yes）；可以应用RBCD。
4. KDC 向 ServiceZ 返回 TGS 以代表 User1 与 ServiceX 交互。
5. ServiceZ 通过模拟 User1 使用新的 TGS 与 ServiceX 交互。

扩展：

使用 TGS 有一个有趣的技巧：只需更改目标服务名称，就可以为同一用户的任何服务使用相同的 TGS。

to use the same TGS for any service of the same user

这是因为：

• 服务名称写在票据的明文部分，任何人都可以修改。

• 同一用户的所有服务共享相同的 Kerberos 密钥，因此任何服务都可以正确解密同一用户的另一个服务的 TGS。

此技巧可用于绕过受约束委派使用的服务的白名单 ( msDS-AllowedToDelegateTo )。

示例：

在这个例子中：

1. User1 将 TGS 发送给 ServiceZ。
2. UserZ 拥有的 ServiceZ 使用这个 TGS 去请求 KDC 为 ServiceX 提供 TGS，该TGS由UserXY 代表 User1 拥有。
3. KDC 检查：
1. ServiceX 在UserZ 中的 msDS-AllowedToDelegateTo 是否为NO，若是，则不能应用受约束的委派。
2. UserZ 在 UserXY 中的 msDS-AllowedToActOnBehalfOfOtherIdentity 是否为NO，若是，则不能应用RBCD。
4. KDC 拒绝 ServiceZ 提出的请求。
5. ServiceZ 代表 User1 请求 KDC，为UserXY 拥有的另一个服务 ServiceY 提供一个TGS。 
6. KDC 检查：
1. ServiceY 在 UserZ 的 msDS-AllowedToDelegateTo 中是否为 yes。 
2. 发送的 TGS 是否是可转发的，若是，则可以应用约束委派。
7. KDC 将 TGS 返回给 ServiceZ 以代表 User1 与 ServiceY 交互。
8. ServiceZ ( UserZ ) 将 TGS 的目标服务从ServiceY 更改为ServiceX。
9. ServiceZ通过模拟 User1 使用修改后的 TGS 与 ServiceX 交互。

我们要注意这不是常规服务的正常操作过程，因为几乎没有服务会编辑 TGS 的服务名称来和其他服务联系，这种行为是攻击者的典型操作，攻击者试图使用这个技巧来绕过 KDC 施加的限制。

S4U2Self：

S4U2Self 的目的是什么？

S4U2Self 的目的是允许对不支持 Kerberos 身份验证的服务使用委派，所以无法从客户端用户获取 TGS。

为了绕过这个限制，S4U2Self 允许服务代表另一个用户为自己请求 KDC 的 TGS；这也称为协议转换。

任何用户都可以使用 S4U2Self ？

不是。实际上，KDC 会根据用户帐户的某些特征（例如帐户的服务和 TrustedToAuthForDelegation 标志）对 S4U2Self 请求做出不同的响应。

TrustedToAuthForDelegation（或 ADS_UF_TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION）标志被包含在 User-Account-Control 用户帐户的属性，要修改此标志，需要在域控制器中具有 SeEnableDelegationPrivilege 权限。

User-Account-Control

为了应用 S4U2Self，KDC 将遵循以下规则：

• 如果用户帐户没有服务，那么 KDC 将不会返回 TGS。
• 如果模拟的目标用户不允许被委派（因为在受保护的用户组中或设置了 NotDelegated 标志），那么 KDC 将返回一个不带 forwardable 标志的TGS。TGS 如果还包含了 an incorrect service name，可以如上所示进行修改。
• 如果为用户设置了TrustedToAuthForDelegation标志，则 KDC 将返回带有可转发标志的 TGS 。
• 如果没有为用户设置 TrustedToAuthForDelegation 标志，那么 KDC 将返回一个不带 forwardable 标志的TGS。

 an incorrect service name

S4U2Self 示例：

示例展示了 S4U2Self 扩展的使用（为清晰起见，我们假设 User1 不受受保护用户组或 NotDelegated 的委派保护，否则 KDC 将返回不可转发的TGS）：

在这个例子中：

1. User 1在不使用 Kerberos 的情况下对 ServiceZ 执行身份验证。在这种情况下可以使用 NTLM 或其他协议。
2. UserZ拥有的ServiceZ代表User1为自己请求一个TGS。
3. KDC 检查：
1. UserZ是否是任何服务的所有者（yes）。
2. TrustedToAuthForDelegation 标志是否设置为 UserZ 帐户（yes）。
4. KDC 代表 User1 为自己返回一个可转发的 TGS 给 ServiceZ，它可以在 S4U2Proxy 中使用。

S4U2Self 和 S4U2Proxy 一起使用的例子：

这个示例展示了 S4U2Self 和 S4U2Proxy 共同使用时方式，在约束委派下（为清晰起见，我们假设User1不受受保护用户组或NotDelegated 的委派保护，否则委派将失败）：

在这个例子中：

1. User1 在不使用 Kerberos 的情况下对 ServiceZ 执行身份验证。在这种情况下可以使用 NTLM 或其他协议。
2. UserZ 的 ServiceZ 代表 User1 为自己请求一个 TGS。
3. KDC 检查：
1. UserZ 是否是任何服务的所有者（yes）。
2. TrustedToAuthForDelegation 标志是否设置为 UserZ 帐户（yes）。
4. KDC 代表 User1 为自己向 ServiceZ 返回一个可转发的TGS。
5. ServiceZ 使用此 TGS 代表 User1 向 KDC 请求 ServiceX 的 TGS。
6. KDC 检查：
1. ServiceX 被列在 UserZ 中的 msDS-AllowedToDelegateTo 是否为 yes。
2. 发送的 TGS 是否是可转发的（yes），若是，则可应用约束委派。
7. KDC 将可转发的 TGS 返回给 ServiceZ 以代表 User1与 ServiceX 交互。
8. ServiceZ 通过模拟 User1 使用新的 TGS 与 ServiceX 交互。

下面这个示例展示了 S4U2Self 和 S4U2Proxy 共同使用时方式，在RBCD下（为清晰起见，我们假设User1不受受保护用户组或NotDelegated 的委派保护，否则委派将失败）： 

在这个例子中：

1. User1 在不使用 Kerberos 的情况下对 ServiceZ 执行身份验证。在这种情况下可以使用 NTLM 或其他协议。
2. UserZ 拥有的 ServiceZ 代表 User1 为自己请求 TGS。
3. KDC 检查：
1. UserZ 是否是任何服务的所有者（yes）。
2. TrustedToAuthForDelegation 标志设置是否为UserZ帐户（yes）。
4. KDC代表User1为自己向ServiceZ返回一个可转发的TGS。
5. ServiceZ使用此 TGS代表User1向 KDC 请求ServiceX的 TGS 。
6. KDC 检查：
1. ServiceX 被列在 UserZ 中的 msDS-AllowedToDelegateTo 是否为 NO，若是，则不能应用受约束的委派。
2. 如果 UserZ 列在 UserX 的 msDS-AllowedToActOnBehalfOfOtherIdentity 中，则成为 ServiceX 的所有者（yes）；可以应用RBCD。
7. KDC 将可转发的 TGS 返回给 ServiceZ 以代表 User1 与 ServiceX 交互。
8. ServiceZ 通过模拟 User1 使用新的 TGS 与 ServiceX 交互。

攻击者如何利用约束委派：

有几种可能的情况：

• 如果攻击者能够利用受约束委派来破坏托管服务的计算机，那么它可以获取每个服务的客户端的第三方服务的 TGS，并与它们交互。它还可以编辑这些TGS来更改目标服务，并与属于同一目标用户的其他服务进行交互。
• 如果攻击者能够攻击并利用具有约束委派权限的用户的帐户，那么它可以获取属于受害帐户的服务客户端的 TGS。另外，如果受感染的用户帐户激活了 TrustedToAuthForDelegation 标志，攻击者就可以使用 S4U2Self 直接向 KDC 请求客户端的 TGS。
• 在前文所述的任何场景中，对于每个 TGS，都可以修改服务名称，以增加攻击者可以交互的服务数量。

攻击者如何利用RBCD：

如果攻击者能够攻击成功并利用名为 UserX 的另一个帐户的 msDS-AllowedToActOnBehalfOfOtherIdentity 属性中列出的帐户 UserZ，则可以通过模拟链接使用 S4U2Self 和 S4U2Proxy 来访问 UserX 的服务。

以下是此场景的示例，展示了 UserZ 使用 S4U2Self 和 S4U2Proxy 通过模拟其所有者 UserX 与服务 ServiceX 交互（我们为了演示方便，假设 UserX 不受受保护用户组或NotDelegated 的委派保护）：

在这个例子中：

1. ServiceZ 的 所有者UserZ（攻击者），代表 UserX (S4U2Self) 为 ServiceZ 请求一个TGS。

2. KDC 检查：

1. UserZ 是否是任何服务的所有者（yes）。

2. TrustedToAuthForDelegation 标志设置是否为 UserZ 帐户（yes）。

3. KDC 代表 UserX 为 ServiceZ 返回一个不可转发的 TGS 给 UserZ。

4. UserZ 使用一个新的不可转发的TGS，代表 UserX 为 ServiceX 订购另一个 TGS（S4U2Proxy）。

5. KDC 检查：

1. ServiceX 被列在 UserZ 中的 msDS-AllowedToDelegateTo 是否为NO，若是，则不能应用受约束的委派。

2. 如果 UserZ 列在 UserX 的 msDS-AllowedToActOnBehalfOfOtherIdentity 中，则成为 ServiceX的所有者（yes）；可以应用RBCD。

6. KDC 将可转发的 TGS 返回给 ServiceZ 以代表 UserX 与 ServiceX 交互。

7. UserZ 通过模拟 UserX 使用新的 TGS 与ServiceX 交互。

还有一个可能性能作为一种持久化的方式；就是将RBCD 从任意用户配置到krbtgt帐户，然后这些任意用户将能够为任何用户生成 krbtgt 服务的TGS ，这意味着为域中的任何用户生成 TGT（因为 TGT 只是krbtgt服务的TGS ），类似于 Golden Ticket 攻击。

configure RBCD from arbitrary users to the krbtgt account

END

从此系列的文章可以看出，Kerberos具有巨大的攻击面，委派也具有三种不同的类型，在实战中，其中一些特性可能决定着入侵的成败，所以学习其中的原理非常重要。

在下一篇文章中，我会展示实际的委派攻击方式。

谢谢！