Kerberos委派的利用

Kerberos 委托解决了双跳问题，但是，攻击者也可以滥用委托来获得远程代码执行并转移到其他机器上。 委托的概念可能很复杂，但我会尽力使其简单易懂！

非约束委派

Kerberos 委派使用户或服务能够代表另一个用户对另一个服务进行操作。 一个典型的场景是，用户向 IIS 服务器进行身份验证，然后 IIS 服务器代表用户向 MSSQL 服务器进行身份验证。

不受约束的委派可以分配给计算机或用户，但主要是计算机。 配置可以在域控制器上完成。 从系统管理员的角度来看，我们可以在委派选项卡上选择“信任此计算机以委派给任何服务（仅限 Kerberos）”选项来为域计算机配置无约束委派。

 

我们提到委托解决了双跳问题，那么无约束委托是如何解决的呢？ 如果一台计算机配置了无约束委派，当用户访问 IIS（前端服务）服务器时，KDC 还包括用户的 TGT 到 TGS 票证。 然后，IIS 服务器提取用户的 TGT 并将其缓存在内存中。 之后，IIS 服务器使用用户的 TGT 代表用户访问 MSSQL（后端服务）服务器。 但问题是由于用户的 TGT 缓存在 IIS 服务器的内存中，IIS 服务器可以使用用户的 TGT 代表用户对任何其他服务进行操作，这意味着用户被 IIS 服务器冒充。 如果 IIS 服务器受到威胁，攻击者可以从内存中提取所有 TGT 并冒充这些用户。 更糟糕的是，如果缓存了高权限用户的 TGT，例如域管理员的 TGT，攻击者就能够接管整个域和林。

让我们详细解释一下步骤！

第 1 步：用户到 DC

用户请求 TGT。

第 2 步：DC 到用户

用户获得 TGT。

第 3 步：用户到 DC

用户请求 TGS 票。

第 4 步：DC 到用户

用户获得 TGS 票。

第 5 步：用户到 IIS 服务器

用户发送 TGT 和 TGS 票据。

第 6 步：IIS 服务器到 DC

IIS 服务器使用用户的 TGT 向 DC 请求 TGS 票证以访问 MSSQL 服务器。

第 7 步：IIS 服务器到 MSSQL 服务器

IIS 服务器代表用户访问 MSSQL 服务器。

枚举

Powerview:

Get-NetComputer -Unconstrained | select dnshostname

域控制器总是配置无约束委派，但它没有帮助。

利用

1：妥协配置无约束委派的机器。

2：使用rubeus实时监控缓存的TGT（需要本地管理员权限）。

rubeus.exe monitor /interval:5 /nowrap

3：等待高权限用户访问本机服务，如smb share。 或者我们可以使用 spoolsample 通过 MS-RPRN RPC 接口将一台机器强制到这台机器上。

spoolsample.exe dc srv02

我们可以在任何 Windows 域机器上执行该命令。

4：将捕获的 TGT 保存为 kirbi 文件。

5：将工单导入当前会话。

6：访问内部资源，如\\dc\c$。 在这种情况下，我们得到了 dc 机器帐户的 TGT，机器帐户没有本地管理员权限，但有一种解决方法可以给我们 SYSTEM 权限（稍后会提到）。 既然是域控制器，我们可以使用DCSync权限来获取域管理员的hash来pwn域！

 

需要注意的是，非约束委派不仅可以跨域，还可以跨森林。但如果是跨森林的话，我们需要确保 TGTDelegation 是启用的，虽然默认是禁用的。我们需要在目标 DC 上执行命令

netdom trust <目标域> /domain:<本地域> /EnableTgtDelegation

 

约束委派

与无约束委托相比，约束委托更安全，因为服务器不再缓存用户的 TGT。 Intead，允许服务器用自己的 TGT 为用户请求 TGS 票证，并且服务器只能代表用户访问指定的服务器和服务。 例如，IIS 服务器只能代表用户访问机器 client01 上的 cifs 和 eventsystem 服务。

从系统管理员的角度来看，可以像这样配置约束委派，选择“信任此计算机仅委派给指定的服务”选项。 它有 2 个子选项，我们注意到选择了“使用任何身份验证协议”，如果我们选择“仅使用 Kerberos”会发生什么？ 我稍后会解释。 除了机器之外，服务帐户也可以配置约束委派。

 

在这种情况下，除了机器 client01 上的 cifs 服务外，还指定机器 client01 上的服务事件系统。 但它看起来并不令人兴奋，但不用担心！ 虽然指定了服务，但我们可以使用备用服务名称技巧来绕过它，因为服务名称不会被 S4U 验证并且它没有在票证中加密。

那么，让我们来看看约束委托的整个过程。

第 1 步：用户到 IIS 服务器

用户通过 NTLM 身份验证向 IIS 服务器进行身份验证，只要身份验证不是 Kerberos。

第 2 步：IIS 服务器到 DC

IIS 服务器利用 S4U2Self 请求 TGS 票证供用户访问自己（IIS 服务器）

第 3 步：DC 到 IIS 服务器

KDC 将可转发的 TGS 票证返回给 IIS 服务器

第 4 步：IIS 服务器到 DC

IIS 服务器利用 S4U2Proxy 请求 TGS 票证让用户访问 SQL 服务器

第 5 步：DC 到 IIS 服务器

KDC 将 TGS 票证返回给 IIS 服务器

第 6 步：IIS 服务器到 SQL Server

IIS 服务器代表用户使用可转发的 TGS 票证访问 SQL 服务。

枚举

Powerview:

Get-NetComputer -TrustedToAuth

(Service Account)

Get-NetUser -TrustedToAuth

开发

1：危害配置了约束委派的机器或用户。

2：为目标机器或服务帐户请求 TGT。

场景 1：我们已经拥有本地管理员权限，或者我们知道他们的凭据。

rubeus.exe asktgt /user:srv-1$ /aes256:[…] /nowrap

场景 2：我们没有本地管理员权限，也不知道他们的凭据。

rubeus.exe tgtdeleg /nowrap

3：将TGT另存为文件

Kali上

echo ‘<..ticket..>’ | base64 -d > xxx.kirbi

在Windows上

[System.IO.File]::WriteAllBytes(“C:\windows\temp\xxx.kirbi”,[System.Convert]::FromBase64String(“<..ticket..>”))

4：冒充特权用户并请求 TGS 票证以访问目标机器上的 CIFS 服务。 例如，特权用户可以是目标机器的本地管理员，有时我们甚至可以冒充域管理员。 但请注意，域用户可以配置为无法委派。 我提到服务名称不会被验证，所以即使目标服务是事件系统，我们也可以将其修改为 cifs 服务。

命令应该是

rubeus.exe /impersonateuser:<high privileged user> /msdsspn:<service>/<fqdn> /user:<user> /ticket:srv01.kirbi /altservice:cifs /nowrap /ptt

5：ticket被导入内存，所以我们可以在client01上访问C$。

 

 

基于资源的约束委派

考虑配置约束委派需要域控制器上的 SeEnableDelegationPrivielge 权限，这意味着通常只有域管理员可以配置它。但是，配置基于资源的约束委派（RBCD）不需要它，系统管理员可以为机器配置RBCD。这意味着，资源本身可以决定信任谁。

为了配置约束委派，IIS 服务器配置了 msDs-AllowedToDelegateTo 属性。 RBCD 通过在 MSSQL 服务器上添加 msDS-AllowedToActOnBehalfOfOtherIdentity 属性来工作。该属性应该是 IIS 服务器的 SID。

需要配置 RBCD。前端服务（这里是 IIS 服务器）应该有 SPN，因为前端服务需要在 S4U2Self 过程中请求 TGS 票证供用户访问自己。如果前端服务不是机器账号或者服务账号，没有意义

枚举

如果拥有的用户或机器拥有对另一台机器的 GenetricWrite（或更高权限）权限。

开发

1：新建机器账号。如果您已经拥有拥有机器的 SYSTEM 权限，那也没关系。

导入 PowerMad.ps1 脚本工具。

New-MachineAccount -MachineAccount rbcd -Password $(ConvertTo-SecureString ‘123123’) -AsPlainText -Force)

2: 将 AllowedToActOnBehalfOfOtherIdentity 属性添加到机器 SRV01（后端服务），该值应为 client01 的（前端服务）SID。

导入 Active Directory 模块

Set-ADComputer [back end server] -PrincipalsAllowedToDelegateToAccount -Server [DC IP] -Verbose

3：类似于约束委派部分的步骤。 利用 S4U 冒充高权限用户获取 TGS 票证以访问后端服务器的资源。 但首先，我们需要知道添加的计算机帐户的哈希密码。

rubeus.exe hash /domain:<domain> /user:rbcd$ /password:<password>

然后滥用S4U，访问后端服务器上的资源。

rubeus.exe s4u /user:rbcd$ /aes256:<…> /impersonateuser:<high privileged user> /msdsspn:<service>/<fqdn> /altservice:http,host,cifs /ptt

S4U

我们在约束委派和 RBCD 部分讨论了 S4U2Self 和 S4U2Proxy。您可能对它们感到困惑，不用担心，我会向您解释。

S4U2自我

它代表用户请求 TGS 票证以访问前端服务器。

滥用 S4U2Self

机器帐户本身没有本地管理员权限。例如，我们可以捕获机器帐户的 TGT，但我们不能直接移动到具有本地管理员权限的机器。实际上有一个解决方法，您可以查看这篇文章：https://cyberstoph.org/posts/2021/06/abusing-kerberos-s4u2self-for-local-privilege-escalation/。 ZeroPoint Security 的课程 RTO 中也说明了一种方法，我们可以使用工具 Asn1Editor 修改 S4U2Self 后返回的 TGS，将所有出现的机器账号替换为 cifs 和 fqdn。例如，将 srv01$ 替换为 cifs 和 srv01.blackops.local。但这两种方法背后的理论是相同的，服务名称不会被验证并且是未加密的。

S4U2代理

它代表用户请求 TGS 票证以访问后端服务。

那么为什么没有选择“仅使用 Kerberos”呢？如果选中，则使用 Kerberos 对前端服务（IIS 服务器）进行身份验证，S4U2Proxy 可以使用用户提供的可转发 TGS 票证。通过这种方式，我们需要用户交互来窃取用户的 TGS 票证。

比较

无约束委派：前端服务器配置无约束委派，它代表经过身份验证的用户请求访问域中的任何资源。

约束委派：前端服务器的 msDS-AllowedToDelegateTo 属性配置后端服务器的 SPN。前端服务器使用其身份 (TGT) 代表经过身份验证的用户请求访问指定后端服务器上的指定服务。模式是 A 信任 B。

基于资源的约束委派：后端服务器的 msDS-AllowedToActOnBehalfOfOtherIdentity 属性配置前端服务器的 SID。这意味着，后端服务器允许前端服务器代表其他用户访问自己的资源。模式是 B 信任 A。