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，攻击者可以接管整个域和森林。

我们来详细解释一下这些步骤。

枚举

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。TGT Intead，允许票据。相反，服务器可以使用自己的 TGT 为用户请求一个 TGS 票证据，并且服务器只能代表用户访问指定的服务器和服务。 例如，IIS 服务器只能代表用户访问 Web01 计算机器 client01 上的 cifsCIFS 和 eventsystem 服务。

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

受限委派可以通过选择“仅信任此计算机代表指定服务的委派”选项来配置。它有两个子选项，我们注意到选择了“使用任何身份验证协议”，如果我们选择“仅使用 Kerberos”，将会发生什么？稍后我们会解释。除了域计算机，服务帐户也可以配置受限委派。

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

那么，让我们来看看约束详细了解一下受限委托派的整个过程。

第步骤 1 步：1：用户到 IIS 服务器

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

第步骤 2 步：2：IIS 服务器到 DC

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

第步骤 3 步：3：DC 到 IIS 服务器

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

第步骤 4 步：4：IIS 服务器到 DC

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

第步骤 5 步：5：DC 到 IIS 服务器

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

第步骤 6 步：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$。

基于资源的约束委派

考虑配置约束受限委派需要在域控制器上的具有 SeEnableDelegationPrivielgeSeEnableDelegationPrivilege 权限，这意味着通常只有域管理员可以用户才能配置它。但是然而，配置基于资源的约束受限委派（RBCD）并不需要它这个权限，系统管理员可以为计算机器配置 RBCD。这意味着，资源本身可以决定信任谁。

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

需要配置 RBCD。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。S4U2Proxy。您可能对它们感到困惑，不用担心，我会向您解释。

S4U2自我

S4U2Self

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

滥

S4U2Self 利用 S4U2Self

计算机器帐户本在其自身上没有本地管理员权限。例如，我们可以捕获计算机器帐户的 TGT，但我们不能直接移动到具有以本地管理员权限的移动到计算机器。实际上有一个解决方法，您可以查看这篇文章：https://cyberstoph.org/posts/2021/06/abusing-kerberos-s4u2self-for-local-privilege-escalation/。我们之前获得了 ZeroPoint SecurityDc01$ 的课程 RTO 中也说明了一种方法，TGT，我们可以使用工具通过以下步骤将 Asn1EditorDc01 修改 S4U2Self 后返回计算机帐户的 TGS，将所有出现的机器账号替TGT 转换为 cifsCIFS 和TGS。

fqdn。例如

首先，将请确保我们现在无法访问 srv01$Dc01 替换为的 cifs 和 srv01.blackops.local。但这两种方法背后的理论是相同的，服务名称不会被验证并且是未加密的C$。

S4U2代理

S4U2Proxy

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

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

 

比较

无

非约束委派：

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

约束委派：

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

基于资源的约束委派：

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